Protección de los datos en Amazon Security Lake

El modelo de se aplica a protección de datos en Amazon Security Lake. Como se describe en este modelo, AWS es responsable de proteger la infraestructura global en la que se ejecutan todos los Nube de AWS. Usted es responsable de mantener el control sobre el contenido alojado en esta infraestructura. Usted también es responsable de las tareas de administración y configuración de seguridad para los Servicios de AWS que utiliza. Para obtener más información sobre la privacidad de los datos, consulte las Preguntas frecuentes sobre la privacidad de datos. Para obtener información sobre la protección de datos en Europa, consulte la publicación de blog sobre el Modelo de responsabilidad compartida de AWS y GDPR en el Blog de seguridad de AWS .

Con fines de protección de datos, le recomendamos que proteja Cuenta de AWS las credenciales y configure los usuarios individuales con AWS IAM Identity Center o AWS Identity and Access Management (IAM). De esta manera, solo se otorgan a cada usuario los permisos necesarios para cumplir sus obligaciones laborales. También recomendamos proteger sus datos de la siguiente manera:

• Utilice la autenticación multifactor (MFA) en cada cuenta.

• Utilice SSL/TLS para comunicarse con los recursos. AWS Se recomienda el uso de TLS 1.2 y recomendamos TLS 1.3.

• Configure la API y el registro de actividad de los usuarios con. AWS CloudTrail

• Utilice soluciones de AWS cifrado, junto con todos los controles de seguridad predeterminados Servicios de AWS.

• Utilice servicios de seguridad administrados avanzados, como Amazon Macie, que lo ayuden a detectar y proteger los datos confidenciales almacenados en Amazon S3.

• Si necesita módulos criptográficos validados por FIPS 140-2 para acceder a AWS través de una interfaz de línea de comandos o una API, utilice un punto final FIPS. Para obtener más información sobre los puntos de conexión de FIPS disponibles, consulte Estándar de procesamiento de la información federal (FIPS) 140-2.

Se recomienda encarecidamente no introducir nunca información confidencial o sensible, como, por ejemplo, direcciones de correo electrónico de clientes, en etiquetas o campos de formato libre, tales como el campo Nombre. Esto incluye cuando trabaja con Security Lake o con otros dispositivos Servicios de AWS mediante la consola, la API o los SDK. AWS CLI AWS Cualquier dato que ingrese en etiquetas o campos de formato libre utilizados para nombres se puede emplear para los registros de facturación o diagnóstico. Si proporciona una URL a un servidor externo, recomendamos encarecidamente que no incluya la información de las credenciales en la URL para validar la solicitud para ese servidor.

Cifrado en reposo

Amazon Security Lake almacena de forma segura sus datos en reposo mediante soluciones de AWS cifrado. El registro de seguridad sin procesar y los datos de eventos se almacenan en un bucket de Amazon Simple Storage Service (Amazon S3) de varios usuarios en una cuenta que administra Security Lake. Security Lake cifra estos datos sin procesar con una clave AWS propia de AWS Key Management Service (AWS KMS). AWS Las claves propias son un conjunto de AWS KMS claves que un AWS servicio, en este caso Security Lake, posee y administra para su uso en varias cuentas. AWS

Security Lake ejecuta trabajos de extracción, transformación y carga (ETL) en datos de registro y eventos sin procesar. Los datos procesados permanecen cifrados en la cuenta de servicio de Security Lake.

Una vez finalizadas las tareas de ETL, Security Lake crea depósitos de S3 de un solo usuario en su cuenta (un depósito por cada uno en el Región de AWS que haya activado Security Lake). Los datos se almacenan en el bucket de S3 multiinquilino solo de forma temporal hasta que Security Lake pueda entregarlos de forma fiable a los buckets de S3 de un solo inquilino. Los buckets de un solo inquino incluyen una política basada en los recursos que permite a Security Lake escribir datos de registro y eventos en los buckets. Para cifrar los datos de su depósito de S3, puede elegir una clave de cifrado gestionada por S3 o una clave gestionada por el cliente (de). AWS KMS Ambas opciones utilizan el cifrado simétrico.

Uso de una clave KMS para el cifrado de datos

De forma predeterminada, los datos que envía Security Lake a su bucket se cifran mediante el sistema de Amazon de cifrado del lado del servidor con claves de cifrado administradas mediante Amazon S3 (SSE-S3). Para proporcionar una capa de seguridad que administre directamente, puede utilizar el cifrado con AWS KMS claves del lado del servidor (SSE-KMS) para sus datos de Security Lake.

La consola de Security Lake no admite SSE-KMS. Para usar SSE-KMS con la API o CLI de Security Lake, primero debe crear una clave KMS o usar una clave existente. Es preciso adjuntar una política a la clave que determine qué usuarios pueden utilizar la clave para cifrar y descifrar datos de Security Lake.

Si usa una clave administrada por el cliente para cifrar los datos que están escritos en su bucket de S3, no podrá elegir una clave multirregional. En el caso de las claves administradas por el cliente, Security Lake crea una concesión en su nombre enviando una solicitud CreateGrant a AWS KMS. Las concesiones in AWS KMS se utilizan para dar a Security Lake acceso a una clave KMS de la cuenta de un cliente.

Security Lake necesita la concesión para utilizar la clave administrada por el cliente para las siguientes operaciones internas:

• Envíe GenerateDataKey solicitudes AWS KMS para generar claves de datos cifradas por su clave administrada por el cliente.

• Envíe RetireGrant las solicitudes a AWS KMS. Al realizar actualizaciones en su lago de datos, esta operación permite retirar la subvención que se agregó a la clave de AWS KMS para el procesamiento de ETL.

Security Lake no necesita permisos de Decrypt. Cuando los usuarios autorizados de la clave leen datos de Security Lake, S3 administrar el descifrado y los usuarios autorizados pueden leer datos ya sin cifrado. Sin embargo, un suscriptor necesita permisos Decrypt para consumir los datos de origen. Para obtener más información acerca de los permisos de suscriptor, consulte Administración del acceso a los datos para los suscriptores de Security Lake.

Si desea utilizar una clave de KMS existente para cifrar los datos de Security Lake, debe modificar la política de claves de la clave de KMS. La política clave debe permitir que la función de IAM asociada a la ubicación del lago de datos de Lake Formation utilice la clave KMS para descifrar los datos. Para obtener instrucciones sobre cómo cambiar la política de claves de una clave de KMS, consulte Cambiar una política de claves en la Guía para AWS Key Management Service desarrolladores.

Su clave de KMS puede aceptar solicitudes de concesión, lo que permite a Security Lake acceder a la clave, siempre que cree una política de claves o utilice una política de claves existente con los permisos adecuados. Para obtener instrucciones sobre cómo crear una política de claves, consulte Creación de una política de claves en la Guía para desarrolladores de AWS Key Management Service .

Adjunte la siguiente política de claves a la clave de KMS:

{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/ExampleRole"}
  "Action": [
    "kms:CreateGrant",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Permisos de IAM necesarios cuando se utiliza una clave administrada por el cliente

Consulte la sección Primeros pasos: requisitos previos para obtener una descripción general de los roles de IAM que debe crear para usar Security Lake.

Al añadir un origen personalizado o un suscriptor, Security Lake crea roles de IAM en su cuenta. Estos roles están diseñados para compartirse con otras identidades de IAM. Permiten que un origen personalizado escriba datos en el lago de datos y que un suscriptor consuma datos del lago de datos. Una política AWS administrada denominada AmazonSecurityLakePermissionsBoundary establece los límites de los permisos para estas funciones.

Cifrado de colas de Amazon SQS

Al crear el lago de datos, Security Lake crea dos colas de Amazon Simple Queue Service (Amazon SQS) sin cifrar en la cuenta de administrador de Security Lake delegada. Debe cifrar estas colas para proteger los datos. El cifrado del servidor (SSE) predeterminado proporcionado por Amazon Simple Queue Service no es suficiente. Debe crear una clave gestionada por el cliente en AWS Key Management Service (AWS KMS) para cifrar las colas y conceder al servicio Amazon S3 los permisos principales para trabajar con las colas cifradas. Para obtener instrucciones sobre la concesión de estos permisos, consulte ¿Por qué no se envían las notificaciones de eventos de Amazon S3 a una cola de Amazon SQS que utiliza cifrado del lado del servidor? en el Knowledge Center. AWS

Dado que Security Lake AWS Lambda admite tareas de extracción, transferencia y carga (ETL) en sus datos, también debe conceder permisos a Lambda para gestionar los mensajes de las colas de Amazon SQS. Para obtener información, consulte Permisos del rol de ejecución en la Guía para desarrolladores de AWS Lambda .

Cifrado en tránsito

Security Lake cifra todos los datos en tránsito entre los servicios. AWS Security Lake protege los datos en tránsito, a medida que viajan hacia y desde el servicio, cifrando automáticamente todos los datos entre redes mediante el protocolo de cifrado seguridad de la capa de transporte (TLS) 1.2. Las solicitudes HTTPS directas enviadas a las API de Security Lake se firman mediante el Algoritmo AWS Signature versión 4 para establecer una conexión segura.