Protección de datos en AWS HealthOmics - AWS HealthOmics
Cifrado en reposoCifrado en tránsito

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Protección de datos en AWS HealthOmics

El AWS modelo de se aplica a protección de datos en AWS HealthOmics. Como se describe en este modelo, AWS es responsable de proteger la infraestructura global en la que se ejecutan todos los Nube de AWS. Eres responsable de mantener el control sobre el contenido alojado en esta infraestructura. También eres 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, consulta las Preguntas frecuentes sobre la privacidad de datos. Para obtener información sobre la protección de datos en Europa, consulta 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:

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

  • Se utiliza SSL/TLS para comunicarse con AWS los recursos. 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. Para obtener información sobre el uso de CloudTrail senderos para capturar AWS actividades, consulte Cómo trabajar con CloudTrail senderos en la Guía del AWS CloudTrail usuario.

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

  • Utiliza 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-3 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, consulta Estándar de procesamiento de la información federal (FIPS) 140-3.

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 AWS HealthOmics u otros Servicios de AWS mediante la consola, la API o AWS SDKs. AWS CLI Cualquier dato que ingrese en etiquetas o campos de texto 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

Para proteger los datos confidenciales de los clientes en reposo, AWS HealthOmics proporciona cifrado de forma predeterminada mediante una clave de AWS Key Management Service (AWS KMS) propiedad del servicio. También se admiten las claves administradas por el cliente. Para obtener más información sobre la clave gestionada por el cliente, consulta Amazon Key Management Service.

Todos los almacenes de HealthOmics datos (almacenamiento y análisis) admiten el uso de claves administradas por el cliente. La configuración de cifrado no se puede cambiar una vez creado un almacén de datos. Si un almacén de datos utiliza una Clave propiedad de AWS, se indicará como AWS_OWNED_KMS_KEY y no verá la clave específica utilizada para el cifrado en reposo.

En el caso de los HealthOmics flujos de trabajo, el sistema de archivos temporales no admite las claves administradas por el cliente; sin embargo, todos los datos en reposo se cifran automáticamente mediante el algoritmo de cifrado por bloques XTS-AES-256 para cifrar el sistema de archivos. El usuario y el rol de IAM utilizados para iniciar la ejecución de un flujo de trabajo también deben tener acceso a las claves utilizadas para los depósitos de entrada y salida del flujo de trabajo. AWS KMS Los flujos de trabajo no utilizan concesiones y el AWS KMS cifrado se limita a los buckets de entrada y salida de Amazon S3. La función de IAM utilizada tanto para el flujo de trabajo APIs debe tener acceso a las AWS KMS claves utilizadas, así como a los buckets de entrada y salida de Amazon S3. Puede utilizar las funciones y permisos de IAM para controlar el acceso o las políticas. AWS KMS Para obtener más información, consulte Autenticación y control de acceso para AWS KMS.

Cuando se utiliza AWS Lake Formation con HealthOmics Analytics, los permisos de descifrado asociados a Lake Formation también se otorgan a los buckets de entrada y salida de Amazon S3. Puede encontrar más información sobre cómo se AWS Lake Formation gestionan los permisos en la AWS Lake Formation documentación.

HealthOmics Analytics concede a Lake Formation kms: Decrypt permisos para leer los datos cifrados de un bucket de Amazon S3. Siempre que tenga permisos para consultar los datos a través de Lake Formation, podrá leer los datos cifrados. El acceso a los datos se controla mediante el control de acceso a los datos en Lake Formation, no mediante una política clave de KMS. Para obtener más información, consulte las solicitudes de servicio de AWS AWS integradas en la documentación de Lake Formation.

Claves propiedad de AWS

De forma predeterminada, se HealthOmics utiliza Claves propiedad de AWS para cifrar automáticamente los datos en reposo, ya que estos datos pueden contener información confidencial, como información de identificación personal (PII) o información de salud protegida (PHI). Claves propiedad de AWS no se almacenan en su cuenta. Forman parte de un conjunto de claves de KMS que AWS posee y administra para su uso en varias cuentas de AWS.

Los servicios de AWS se pueden utilizar Claves propiedad de AWS para proteger sus datos. No puede ver, administrar Claves propiedad de AWS, acceder a su uso ni auditarlo. Sin embargo, no es necesario que realice ninguna acción ni que cambie programas para proteger las claves que cifran sus datos.

No se le cobra una cuota mensual ni una cuota de uso por su uso Claves propiedad de AWS, y estas no se tienen en cuenta para las cuotas de AWS KMS de su cuenta. Para obtener más información, consulte Claves administradas por AWS.

Claves administradas por el cliente

HealthOmics admite el uso de claves simétricas administradas por el cliente que usted crea, posee y administra para agregar una segunda capa de cifrado sobre el cifrado existente propiedad de AWS. Como usted tiene el control total de dicho cifrado, puede realizar tareas como las siguientes:

  • Establecer y mantener políticas de claves, políticas de IAM y concesiones

  • Rotar el material criptográfico

  • Habilitar y deshabilitar políticas de claves

  • Agregar etiquetas.

  • Crear alias de clave

  • Programar la eliminación de claves

También puede utilizarla CloudTrail para realizar un seguimiento de las solicitudes que se HealthOmics envían AWS KMS en su nombre. Se aplican cargos adicionales de AWS KMS . Para obtener más información, consulta las claves gestionadas por el cliente.

Creación de una clave administrada por el cliente

Puede crear una clave simétrica administrada por el cliente mediante la consola de administración de AWS o la AWS KMS APIs.

Siga los pasos para crear claves simétricas administradas por el cliente de la Guía para desarrolladores de AWS Key Management Service.

Las políticas de clave controlan el acceso a la clave administrada por el cliente. Cada clave administrada por el cliente debe tener exactamente una política de clave, que contiene instrucciones que determinan quién puede usar la clave y cómo puede utilizarla. Al crear una clave administrada por el cliente, puede especificar una política de claves. Para obtener más información, consulte Administrar el acceso a las claves administradas por el cliente en la Guía para desarrolladores de AWS Key Management Service.

Para usar una clave administrada por el cliente con sus recursos de HealthOmics análisis, la persona que realiza la llamada debe incluir kms: CreateGrant operations en la política clave. Esto permite que el sistema utilice un token FAS para crear una concesión a una clave gestionada por el cliente que controle el acceso a una clave KMS específica. Esta clave permite al usuario acceder a las operaciones de kms:grant que necesite. HealthOmics Consulte Uso de subvenciones para obtener más información.

En el caso del HealthOmics análisis, se deben permitir las siguientes operaciones de API para la persona que realiza la llamada:

  • kms: CreateGrant añade concesiones a una clave específica administrada por el cliente, lo que permite el acceso a las operaciones de concesión en HealthOmics Analytics.

  • kms: DescribeKey proporciona los detalles de la clave gestionada por el cliente necesarios para validar la clave. Esto es necesario para todas las operaciones.

  • kms: GenerateDataKey proporciona acceso a los recursos de cifrado en reposo para todas las operaciones de escritura. Además, esta acción proporciona detalles de la clave administrada por el cliente que el servicio puede usar para validar que la persona que llama tiene acceso para usar la clave.

  • KMS:Decrypt proporciona acceso a las operaciones de lectura o búsqueda de recursos cifrados.

Para utilizar una clave gestionada por el cliente con sus recursos HealthOmics de almacenamiento, la política de claves debe permitir al director de HealthOmics servicio y al principal que realiza la llamada. Esto permite que el servicio valide que la persona que llama tiene acceso a la clave y utiliza la entidad principal de servicio para gestionar la tienda mediante la clave gestionada por el cliente. En cuanto al HealthOmics almacenamiento, la política de claves del director del servicio debe permitir las siguientes operaciones de API:

  • kms: DescribeKey proporciona los detalles de la clave administrada por el cliente necesarios para validar la clave. Esto es necesario para todas las operaciones.

  • kms: GenerateDataKey proporciona acceso a los recursos de cifrado en reposo para todas las operaciones de escritura. Además, esta acción proporciona detalles de la clave administrada por el cliente que el servicio puede usar para validar que la persona que llama tiene acceso para usar la clave.

  • KMS:Decrypt proporciona acceso a las operaciones de lectura o búsqueda de recursos cifrados.

El siguiente ejemplo muestra una declaración de política que permite al director de un servicio crear e interactuar con un almacén de HealthOmics secuencias o referencias cifrado mediante la clave gestionada por el cliente:

JSON
{
    "Version": "2012-10-17",
    "Statement": [
{
    "Effect": "Allow",
    "Principal": {
        "Service": "omics.amazonaws.com"
    },
    "Action": [
        "kms:Decrypt",
        "kms:DescribeKey",
        "kms:Encrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*"
        }
    ]
}

El siguiente ejemplo muestra una política que crea permisos para que un almacén de datos descifre los datos de un bucket de Amazon S3.

JSON
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "omics:GetReference", 
                "omics:GetReferenceMetadata"
            ],
            "Resource": [
                "arn:AWS:omics:{{region}}:{{accountId}}:referenceStore/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:AWS:s3:::[[s3path]]/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": [
                "arn:AWS:kms:{{region}}:{111122223333}:key/{{key_id}}"
            ],
            "Condition": {
              "StringEquals": {
                  "kms:ViaService": [
                    "s3.{{region}}.amazonAWS.com"
                  ]
              }
           }
        }
    ]
}

Permisos de IAM necesarios para usar una clave administrada por el cliente

Al crear un recurso, como un almacén de datos AWS KMS cifrado mediante una clave administrada por el cliente, se requieren permisos tanto para la política de claves como para la política de IAM para el usuario o rol de IAM.

Puede usar la clave de ViaService condición kms: para limitar el uso de la clave KMS únicamente a las solicitudes que se originen en. HealthOmics

Para obtener más información sobre las políticas clave, consulte Habilitar las políticas de IAM en la Guía para desarrolladores de AWS Key Management Service.

Permisos de la API de análisis

Para el HealthOmics análisis, el usuario o rol de IAM que crea las tiendas debe tener los permisos kms: CreateGrant kms:GenerateDataKey, kms: Decrypt y, además de kms: DescribeKey los permisos necesarios HealthOmics .

Permisos de la API de almacenamiento

Para el HealthOmics almacenamiento APIs, el usuario o rol de IAM que invoca las siguientes operaciones de API requiere los permisos que se indican:

CreateReferenceStore, CreateSequenceStore

Para crear un almacén, la persona que llama a IAM debe tener kms:DescribeKey los permisos necesarios y los permisos necesarios. HealthOmics El director del HealthOmics servicio llama kms:GenerateDataKeyWithoutPlaintext para realizar comprobaciones de validación de acceso para cargar y acceder a los datos.

StartReadSetImportJob, StartReferenceImportJob

Para iniciar los trabajos de importación de datos, la persona que llama a IAM debe tener kms:Decrypt kms:GenerateDataKey permisos para la clave de KMS en el almacén de importación y kms:Decrypt permisos en el depósito de Amazon S3 que contiene los objetos que se van a importar. Además, el rol transferido a la llamada debe tener kms:Decrypt permisos en el bucket de Amazon S3 que contiene los objetos que se van a importar. La persona que llama a IAM también debe tener permisos para transferir la función al trabajo.

CreateMultipartReadSetUpload, UploadReadSetPart, CompleteMultipartReadSetUpload

Para completar una carga en varias partes, la persona que llama a IAM debe tener kms:Decrypt y crear, kms:GenerateDataKey cargar y completar la carga en varias partes.

StartReadSetExportJob

Para iniciar un trabajo de exportación de datos, la persona que llama a IAM debe tener kms:Decrypt permiso para exportar la clave KMS del almacén kms:GenerateDataKey y kms:Decrypt permisos en el depósito de Amazon S3 que recibe los objetos. Además, el rol transferido a la llamada debe tener kms:Decrypt permisos en el bucket de Amazon S3 que recibe los objetos. La persona que llama a IAM también debe tener permisos para transferir la función al trabajo.

StartReadsetActivationJob

Para iniciar un trabajo de activación de un conjunto de lectura, la persona que llama a IAM debe tener los objetos kms:Decrypt y kms:GenerateDataKey permisos para utilizarlos.

GetReference, GetReadSet

Para leer los objetos del almacén, la persona que llama a IAM debe tener kms:Decrypt permiso para acceder a los objetos.

Lea el conjunto S3 GetObject

Para leer objetos del almacén mediante la GetObject API de Amazon S3, la persona que llama a IAM debe tener kms:Decrypt permiso para los objetos. Establezca este permiso tanto para la clave administrada por el cliente como para las Clave propiedad de AWS configuraciones.

Cómo se HealthOmics utilizan las subvenciones en AWS KMS

HealthOmics Analytics requiere una subvención para usar la clave de KMS administrada por el cliente. Las subvenciones no son obligatorias ni se utilizan para los HealthOmics flujos de trabajo. HealthOmics Storage utiliza la clave gestionada por el cliente directamente del director del servicio, por lo que no utilice una concesión. Cuando crea un almacén de análisis cifrado con una clave administrada por el cliente, HealthOmics Analytics crea una subvención en su nombre mediante el envío de una CreateGrantsolicitud a AWS KMS. Las subvenciones en AWS KMS se utilizan para dar HealthOmics acceso a una clave de KMS en una cuenta de cliente.

No se recomienda revocar o retirar las subvenciones que HealthOmics Analytics crea en su nombre. Si revoca o retira la concesión que le da HealthOmics permiso para usar las claves de AWS KMS de su cuenta, HealthOmics no puede acceder a estos datos, cifra los nuevos recursos introducidos en el almacén de datos o los descifra cuando se extraen.

Cuando revoca o retira una subvención HealthOmics, el cambio se produce inmediatamente. Para revocar los derechos de acceso, le recomendamos que elimine el almacén de datos en lugar de revocar la concesión. Al eliminar el almacén de datos, HealthOmics retira las concesiones en tu nombre.

Supervisar sus claves de cifrado para AWS HealthOmics

Puedes utilizarla CloudTrail para realizar un seguimiento de las solicitudes que se AWS HealthOmics envían AWS KMS en tu nombre cuando utilizas una clave gestionada por el cliente. Las entradas del CloudTrail registro muestran HealthOmics .AmazonAWS.com en el campo UserAgent para distinguir claramente las solicitudes realizadas por. HealthOmics

Los siguientes ejemplos son CloudTrail eventos para CreateGrant descifrar y supervisar las AWS KMS operaciones solicitadas para acceder DescribeKey HealthOmics a los datos cifrados por la clave gestionada por el cliente. GenerateDataKey

A continuación, también se muestra cómo permitir que los HealthOmics análisis accedan a una clave de KMS proporcionada por el cliente, lo que permite HealthOmics utilizar esa clave de KMS para cifrar todos los datos de los clientes en reposo. CreateGrant

No tienes la obligación de crear tus propias subvenciones. HealthOmics crea una subvención en su nombre mediante el envío de una CreateGrant solicitud a AWS KMS. Las concesiones in se AWS KMS utilizan para dar HealthOmics acceso a una AWS KMS clave de la cuenta de un cliente.

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "xx:test",
        "arn": "arn:AWS:sts::555555555555:assumed-role/user-admin/test",
        "accountId": "xx",
        "accessKeyId": "xxx",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "xxxx",
                "arn": "arn:AWS:iam::555555555555:role/user-admin",
                "accountId": "555555555555",
                "userName": "user-admin"
            },
            "webIdFederationData": {},
            "attributes": {
                "creationDate": "2022-11-11T01:36:17Z",
                "mfaAuthenticated": "false"
            }
        },
        "invokedBy": "apigateway.amazonAWS.com"
    },
    "eventTime": "2022-11-11T02:34:41Z",
    "eventSource": "kms.amazonAWS.com",
    "eventName": "CreateGrant",
    "AWSRegion": "us-west-2",
    "sourceIPAddress": "apigateway.amazonAWS.com",
    "userAgent": "apigateway.amazonAWS.com",
    "requestParameters": {
        "granteePrincipal": "AWS Internal",
        "keyId": "arn:AWS:kms:us-west-2:555555555555:key/a6e87d77-cc3e-4a98-a354-e4c275d775ef",
        "operations": [
            "CreateGrant",
            "RetireGrant",
            "Decrypt",
            "GenerateDataKey"
        ]
    },
    "responseElements": {
        "grantId": "4869b81e0e1db234342842af9f5531d692a76edaff03e94f4645d493f4620ed7",
        "keyId": "arn:AWS:kms:us-west-2:245126421963:key/xx-cc3e-4a98-a354-e4c275d775ef"
    },
    "requestID": "d31d23d6-b6ce-41b3-bbca-6e0757f7c59a",
    "eventID": "3a746636-20ef-426b-861f-e77efc56e23c",
    "readOnly": false,
    "resources": [
        {
            "accountId": "245126421963",
            "type": "AWS::KMS::Key",
            "ARN": "arn:AWS:kms:us-west-2:245126421963:key/xx-cc3e-4a98-a354-e4c275d775ef"
        }
    ],
    "eventType": "AWSApiCall",
    "managementEvent": true,
    "recipientAccountId": "245126421963",
    "eventCategory": "Management"
}

El siguiente ejemplo muestra cómo se utiliza GenerateDataKey para garantizar que el usuario tenga los permisos necesarios para cifrar los datos antes de almacenarlos.

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "EXAMPLEUSER",
        "arn": "arn:AWS:sts::111122223333:assumed-role/Sampleuser01",
        "accountId": "111122223333",
        "accessKeyId": "EXAMPLEKEYID",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "EXAMPLEROLE",
                "arn": "arn:AWS:iam::111122223333:role/Sampleuser01",
                "accountId": "111122223333",
                "userName": "Sampleuser01"
            },
            "webIdFederationData": {},
            "attributes": {
                "creationDate": "2021-06-30T21:17:06Z",
                "mfaAuthenticated": "false"
            }
        },
        "invokedBy": "omics.amazonAWS.com"
    },
    "eventTime": "2021-06-30T21:17:37Z",
    "eventSource": "kms.amazonAWS.com",
    "eventName": "GenerateDataKey",
    "AWSRegion": "us-east-1",
    "sourceIPAddress": "omics.amazonAWS.com",
    "userAgent": "omics.amazonAWS.com",
    "requestParameters": {
        "keySpec": "AES_256",
        "keyId": "arn:AWS:kms:us-east-1:111122223333:key/EXAMPLE_KEY_ARN"
    },
    "responseElements": null,
    "requestID": "EXAMPLE_ID_01",
    "eventID": "EXAMPLE_ID_02",
    "readOnly": true,
    "resources": [
        {
            "accountId": "111122223333",
            "type": "AWS::KMS::Key",
            "ARN": "arn:AWS:kms:us-east-1:111122223333:key/EXAMPLE_KEY_ARN"
        }
    ],
    "eventType": "AWSApiCall",
    "managementEvent": true,
    "recipientAccountId": "111122223333",
    "eventCategory": "Management"
}

Más información

Los siguientes recursos proporcionan más información sobre el cifrado de datos en reposo.

Para obtener más información sobre los conceptos básicos de AWS Key Management Service, consulte la AWS KMS documentación.

Para obtener más información sobre las prácticas recomendadas de seguridad, AWS KMS consulte la documentación.

Cifrado en tránsito

AWS HealthOmics utiliza TLS 1.2+ para cifrar los datos en tránsito a través de los puntos finales públicos y a través de los servicios de backend.