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.
Características de seguridad integradas del ADDF
El Marco de Datos de Conducción Autónoma (ADDF) cuenta con varias características de seguridad integradas. De forma predeterminada, estas características se han diseñado para ayudarlo a configurar un marco seguro y ayudar a su organización a cumplir los requisitos de seguridad empresariales más comunes.
Las siguientes son las características de seguridad integradas:
-
Política de privilegio mínimo personalizada para rol de implementación de AWS CDK
-
Política de privilegio mínimo para el archivo deployspec del módulo
-
Compatibilidad con el límite de permisos para el rol de AWS CodeBuild de CodeSeeder
-
Permisos de privilegio mínimo para implementaciones con varias cuentas
Privilegio mínimo para el código de módulo del ADDF
El privilegio mínimo es la práctica recomendada de seguridad que consiste en conceder los permisos mínimos necesarios para realizar una tarea. Para obtener más información, consulte Aplicar permisos de privilegio mínimo. Los módulos que proporciona el ADDF siguen de forma rigurosa el principio de privilegio mínimo en su código y en los recursos implementados, de la siguiente manera:
-
Todas las políticas de AWS Identity and Access Management (IAM) que se generan para un módulo de ADDF cuentan con los permisos mínimos necesarios para cada caso de uso.
-
Los Servicios de AWS se configuran e implementan de acuerdo con el principio de privilegio mínimo. Los módulos que proporciona el ADDF solo utilizan los servicios y las características de servicio necesarios para el caso de uso específico.
Infraestructura como código
El ADDF, como marco, se ha diseñado para implementar los módulos de ADDF como infraestructura como código (IaC). La IaC elimina los procesos de implementación manual y ayuda a prevenir errores y configuraciones incorrectas, que pueden resultar de procesos manuales.
El ADDF se ha diseñado para orquestar e implementar módulos mediante cualquier marco de IaC común. Esto incluye, entre otros:
Puede utilizar diferentes marcos de IaC para escribir distintos módulos y, luego, utilizar el ADDF para implementarlos.
El marco de IaC predeterminado que utilizan los módulos de ADDF es AWS CDK. AWS CDK es una abstracción de alto nivel orientada a objetos que se puede utilizar para definir recursos de AWS imperativamente. AWS CDK ya aplica las prácticas recomendadas de seguridad de forma predeterminada para varios servicios y escenarios. Mediante el uso de AWS CDK, se reduce el riesgo de errores de configuración de seguridad.
Controles de seguridad automatizados para la IaC
La utilidad cdk-nag
Política de privilegio mínimo personalizada para rol de implementación de AWS CDK
El ADDF hace un uso extensivo de AWS CDK v2. Es necesario que arranque todas las Cuentas de AWS en AWS CDK del ADDF. Para obtener más información, consulte Proceso de arranque (documentación de AWS CDK).
De forma predeterminada, AWS CDK asigna AdministratorAccess, la política administrada por AWS permisiva, al rol de implementación de AWS CDK creado en cuentas de arranque. El nombre completo de este rol es cdk-[CDK_QUALIFIER]-cfn-exec-role-[AWS_ACCOUNT_ID]-[REGION]. AWS CDK utiliza este rol para implementar recursos en la Cuenta de AWS de arranque como parte del proceso de implementación de AWS CDK.
En función de los requisitos de seguridad de su organización, la política AdministratorAccess puede ser demasiado permisiva. Como parte del proceso de arranque de AWS CDK, puede personalizar la política y los permisos según sus necesidades. Puede cambiar la política al reiniciar el arranque de la cuenta con una política recién definida mediante el parámetro --cloudformation-execution-policies. Para obtener más información, consulte Personalización del proceso de arranque (documentación de AWS CDK).
nota
Si bien esta característica de seguridad no es específica del ADDF, aparece en esta sección porque puede aumentar la seguridad general de la implementación del ADDF.
Política de privilegio mínimo para el archivo deployspec del módulo
Cada módulo contiene un archivo de especificaciones de la implementación que se denomina deployspec.yaml. Este archivo define las instrucciones de implementación del módulo. CodeSeeder lo utiliza para implementar el módulo definido en la cuenta de destino mediante AWS CodeBuild. CodeSeeder asigna un rol de servicio predeterminado a CodeBuild para implementar los recursos, como se indica en el archivo de especificaciones de la implementación. Este rol de servicio se ha diseñado en función del principio de privilegio mínimo. Incluye todos los permisos necesarios para la implementación de aplicaciones de AWS CDK, ya que todos los módulos que proporciona el ADDF se crean como aplicaciones de AWS CDK.
Sin embargo, si necesita ejecutar algún comando de etapa fuera de AWS CDK, debe crear una política de IAM personalizada en lugar de utilizar el rol de servicio predeterminado para CodeBuild. Por ejemplo, si utiliza un marco de implementación de IaC que no sea AWS CDK, como Terraform, debe crear una política de IAM que conceda los permisos suficientes para que funcione ese marco específico. Otro escenario que requiere una política de IAM específica es cuando incluye llamadas a AWS Command Line Interface (AWS CLI) directas a otros Servicios de AWS en los comandos de etapa install, pre_build, build o post_build. Por ejemplo, necesita una política personalizada si su módulo incluye un comando de Amazon Simple Storage Service (Amazon S3) para cargar archivos a un bucket de S3. La política de IAM personalizada proporciona un control detallado para cualquier comando de AWS fuera de la implementación de AWS CDK. Para ver un ejemplo de política de IAM personalizada, consulte ModuleStack
Cifrado de datos
El ADDF almacena y procesa datos potencialmente confidenciales. A fin de ayudar a proteger estos datos, los módulos que proporciona el ADDF, SeedFarmer, CodeSeeder cifran los datos en reposo y en tránsito para todos los Servicios de AWS utilizados (a menos que se indique explícitamente lo contrario para los módulos de la carpeta demo-only).
Almacenamiento de credenciales mediante Secrets Manager
ADDF gestiona varios secretos para diferentes servicios, como Docker Hub, JupyterHub y Amazon Redshift. ADDF utiliza AWS Secrets Manager para almacenar cualquier secreto relacionado con el ADDF. Esto lo ayuda a eliminar los datos confidenciales del código fuente.
Los secretos de Secrets Manager solo se almacenan en las cuentas de destino, según sea necesario para que la cuenta funcione de forma correcta. De forma predeterminada, la cuenta de cadena de herramientas no contiene secretos.
Revisiones de seguridad de SeedFarmer y CodeSeeder
SeedFarmer
Compatibilidad con el límite de permisos para el rol de AWS CodeBuild de CodeSeeder
Los límites de permisos de IAM son un mecanismo de seguridad común que define los permisos máximos que una política basada en identidades puede conceder a una entidad de IAM. SeedFarmer y CodeSeeder permiten adjuntar un límite de permisos de IAM para cada cuenta de destino. El límite de permisos limita los permisos máximos de cualquier rol de servicio que utiliza CodeBuild cuando CodeSeeder implementa módulos. Un equipo de seguridad debe crear los límites de permisos de IAM fuera del ADDF. Los archivos adjuntos de la política de límite de permisos de IAM se aceptan como un atributo dentro del archivo de manifiesto de la implementación del ADDF, deployment.yaml. Para obtener más información, consulte Compatibilidad con el límite de permisos
El flujo de trabajo es el siguiente:
-
Su equipo de seguridad define y crea un límite de permisos de IAM en función de sus requisitos de seguridad. El límite de permisos de IAM debe crearse de forma individual en cada Cuenta de AWS del ADDF. El resultado es una lista de nombre de recurso de Amazon (ARN) de la política de límite de permisos.
-
El equipo de seguridad comparte la lista de ARN de la política con su equipo de desarrolladores del ADDF.
-
El equipo de desarrolladores del ADDF integra la lista de ARN de la política en el archivo de manifiesto. Para ver un ejemplo de esta integración, consulte sample-permissionboundary.yaml
(GitHub) y Manifiesto de implementación (documentación de SeedFarmer). -
Tras una implementación exitosa, el límite de permisos se adjunta a todos los roles de servicio que CodeBuild utiliza para implementar los módulos.
-
El equipo de seguridad monitorea que los límites de permisos se apliquen según sea necesario.
Arquitectura de varias cuentas de AWS
Tal como se define en el pilar de seguridad del Marco de AWS Well-Architected, se considera una práctica recomendada separar los recursos y las cargas de trabajo en varias Cuentas de AWS, en función de los requisitos de su organización. Esto se debe a que una Cuenta de AWS actúa como límite de aislamiento. Para obtener más información, consulte Administración y separación de Cuenta de AWS. La implementación de este concepto se denomina arquitectura de varias cuentas. Un diseño adecuado de la arquitectura de varias cuentas de AWS permite categorizar la carga de trabajo y reduce el alcance del impacto en caso de una brecha de seguridad, en comparación con una arquitectura de una sola cuenta.
El ADDF admite de forma nativa arquitecturas de varias cuentas de AWS. Puede distribuir sus módulos de ADDF entre tantas Cuentas de AWS según sea necesario para cumplir con los requisitos de seguridad y separación de funciones de su organización. Puede implementar el ADDF en una sola Cuenta de AWS, al combinar la cadena de herramientas y las funciones de la cuenta de destino. Como alternativa, puede crear cuentas de destino individuales para los módulos o grupos de módulos del ADDF.
La única restricción que debe tener en cuenta es que un módulo de ADDF representa la unidad de implementación más pequeña de cada Cuenta de AWS.
En el caso de los entornos de producción, se recomienda utilizar una arquitectura de varias cuentas compuesta por una cuenta de cadena de herramientas y al menos una cuenta de destino. Para obtener más información, consulte Arquitectura del ADDF.
Permisos de privilegio mínimo para implementaciones con varias cuentas
Si utiliza una arquitectura de varias cuentas, SeedFarmer necesita acceder a las cuentas de destino para realizar las siguientes tres acciones:
-
Escribir los metadatos del módulo de ADDF en la cuenta de cadena de herramientas y en las cuentas de destino.
-
Leer los metadatos del módulo de ADDF de la cuenta de cadena de herramientas y de las cuentas de destino.
-
Iniciar trabajos de AWS CodeBuild en las cuentas de destino, con el fin de implementar o actualizar los módulos.
En la siguiente figura, se muestran las relaciones entre cuentas, incluidas las operaciones para asumir roles de AWS Identity and Access Management (IAM) específicos del ADDF.
Estas acciones entre cuentas se logran mediante el uso de operaciones de asunción de roles bien definidas.
-
El rol de IAM de la cadena de herramientas del ADDF se implementa en la cuenta de cadena de herramientas. SeedFarmer asume este rol. Este rol tiene permisos para realizar una acción
iam:AssumeRoley puede asumir el rol de IAM de implementación del ADDF en cada cuenta de destino. Además, el rol de IAM de la cadena de herramientas del ADDF puede ejecutar operaciones de Almacén de parámetros de AWS Systems Manager locales. -
El rol de IAM de implementación del ADDF se implementa en cada cuenta de destino. Este rol solo se puede asumir desde la cuenta de cadena de herramientas mediante el rol de IAM de la cadena de herramientas del ADDF. Este rol tiene permisos para ejecutar operaciones de Almacén de parámetros de AWS Systems Manager locales y ejecutar acciones de AWS CodeBuild que inician y describen los trabajos de CodeBuild a través de CodeSeeder.
Estos roles de IAM específicos del ADDF se crean como parte del proceso de arranque del ADDF. Para obtener más información, consulte Cuenta de AWS de arranque en la Guía de implementación del ADDF
Todos los permisos entre cuentas se configuran de acuerdo con el principio de privilegio mínimo. Si una cuenta de destino se ve comprometida, el impacto en las demás Cuentas de AWS del ADDF es mínimo o nulo.
En el caso de una arquitectura de una sola cuenta para el ADDF, las relaciones del rol siguen siendo las mismas. Simplemente se comprimen en una sola Cuenta de AWS.
