Workloads OU: cuenta de aplicación - AWS Guía prescriptiva

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.

Workloads OU: cuenta de aplicación

Influya en el futuro de la arquitectura de referencia de AWS seguridad (AWSSRA) realizando una breve encuesta.

El siguiente diagrama ilustra los servicios de seguridad de AWS que están configurados en la cuenta de la aplicación (junto con la propia aplicación).

Servicios de seguridad para la cuenta de la aplicación

La cuenta de aplicación aloja la infraestructura y los servicios principales para ejecutar y mantener una aplicación empresarial. La cuenta de aplicación y la OU Workloads cumplen algunos objetivos de seguridad principales. En primer lugar, debe crear una cuenta independiente para cada aplicación a fin de establecer límites y controles entre las cargas de trabajo y evitar problemas relacionados con la combinación de funciones, permisos, datos y claves de cifrado. Desea proporcionar un contenedor de cuentas independiente en el que el equipo de aplicaciones pueda disponer de amplios derechos para gestionar su propia infraestructura sin que ello afecte a los demás. A continuación, añada un nivel de protección al proporcionar un mecanismo para que el equipo de operaciones de seguridad supervise y recopile los datos de seguridad. Utilice un registro organizativo y despliegues locales de los servicios de seguridad de cuentas (Amazon GuardDuty, AWS Config, AWS Security Hub, Amazon EventBridge, AWS IAM Access Analyzer), configurados y supervisados por el equipo de seguridad. Por último, permite a su empresa establecer los controles de forma centralizada. Para alinear la cuenta de la aplicación con la estructura de seguridad más amplia, se convierte en miembro de la unidad organizativa Workloads, a través de la cual hereda los permisos, restricciones y barreras de servicio adecuados.

Consideraciones de diseño
  • En su organización es probable que tenga más de una aplicación empresarial. La OU Workloads está diseñada para albergar la mayoría de las cargas de trabajo específicas de su empresa, incluidos los entornos de producción y no producción. Estas cargas de trabajo pueden ser una combinación de aplicaciones comerciales off-the-shelf (COTS) y sus propias aplicaciones y servicios de datos personalizados desarrollados internamente. Existen pocos patrones para organizar las diferentes aplicaciones empresariales junto con sus entornos de desarrollo. Un patrón consiste en tener varias unidades organizativas secundarias basadas en su entorno de desarrollo, como las de producción, puesta en escena, pruebas y desarrollo, y utilizar cuentas de AWS secundarias independientes en esas unidades organizativas que pertenezcan a distintas aplicaciones. Otro patrón común es tener unidades organizativas secundarias independientes por aplicación y, a continuación, utilizar cuentas de AWS secundarias independientes para los entornos de desarrollo individuales. La estructura exacta de la unidad organizativa y de la cuenta depende del diseño de la aplicación y de los equipos que gestionen esas aplicaciones. Tenga en cuenta los controles de seguridad que desee aplicar, ya sean específicos del entorno o de la aplicación, ya que es más fácil implementar esos controles como SCP en las unidades organizativas. Para obtener más información sobre la organización de unidades organizativas orientadas a cargas de trabajo, consulte la sección Organización de unidades organizativas orientadas a cargas de trabajo del documento técnico de AWS Cómo organizar su entorno de AWS mediante varias cuentas.

Aplicación VPC

La nube privada virtual (VPC) de la cuenta de la aplicación necesita acceso entrante (para los servicios web simples que está modelando) y acceso saliente (para las necesidades de las aplicaciones o las necesidades de los servicios de AWS). De forma predeterminada, los recursos de una VPC se pueden enrutar entre sí. Hay dos subredes privadas: una para alojar las instancias EC2 (capa de aplicación) y otra para Amazon Aurora (capa de base de datos). La segmentación de la red entre diferentes niveles, como el nivel de aplicación y el nivel de base de datos, se logra mediante grupos de seguridad de VPC, que restringen el tráfico a nivel de instancia. Para garantizar la resiliencia, la carga de trabajo abarca dos o más zonas de disponibilidad y utiliza dos subredes por zona.

Consideraciones de diseño
  • Puede usar Traffic Mirroring para copiar el tráfico de red desde una interfaz de red elástica de instancias EC2. A continuación, puede enviar el tráfico a los dispositivos out-of-band de seguridad y supervisión para inspeccionar el contenido, supervisar las amenazas o solucionar problemas. Por ejemplo, es posible que desee supervisar el tráfico que sale de la VPC o el tráfico cuyo origen está fuera de la VPC. En este caso, reflejará todo el tráfico, excepto el tráfico que pasa dentro de su VPC, y lo enviará a un único dispositivo de supervisión. Los registros de flujo de Amazon VPC no capturan el tráfico reflejado; por lo general, solo capturan información de los encabezados de los paquetes. La duplicación del tráfico proporciona una visión más profunda del tráfico de la red al permitirle analizar el contenido real del tráfico, incluida la carga útil. Habilite la duplicación de tráfico solo para la interfaz de red elástica de las instancias EC2 que puedan funcionar como parte de cargas de trabajo confidenciales o para las que espere necesitar un diagnóstico detallado en caso de que se produzca un problema.

Puntos de conexión de VPC

Los puntos finales de VPC proporcionan otro nivel de control de seguridad, además de escalabilidad y confiabilidad. Úselos para conectar la VPC de su aplicación a otros servicios de AWS. (En la cuenta de aplicación, la SRA de AWS emplea puntos de enlace de VPC para AWS KMS, AWS Systems Manager y Amazon S3). Los puntos de conexión son dispositivos virtuales. Son componentes de VPC escalados horizontalmente, redundantes y de alta disponibilidad. Permiten la comunicación entre instancias de su VPC y servicios sin imponer riesgos de disponibilidad o restricciones de ancho de banda en el tráfico de red. Puede usar un punto de enlace de VPC para conectar de forma privada su VPC a los servicios de AWS compatibles y a los servicios de puntos de enlace de VPC con tecnología de AWS PrivateLink sin necesidad de una puerta de enlace a Internet, un dispositivo NAT, una conexión VPN o una conexión AWS Direct Connect. Las instancias de su VPC no requieren direcciones IP públicas para comunicarse con otros servicios de AWS. El tráfico entre su VPC y el otro servicio de AWS no sale de la red de Amazon. 

Otra ventaja del uso de puntos finales de VPC es permitir la configuración de políticas de puntos finales. Una política de punto de conexión de VPC es una política de recursos de IAM que puede asociar a un punto de conexión cuando crea o modifica el punto de conexión. Si no adjuntas una política de IAM al crear un punto de conexión, AWS te adjunta una política de IAM predeterminada que te permite el acceso total al servicio. Una política de puntos finales no anula ni sustituye a las políticas de IAM ni a las políticas específicas de un servicio (como las políticas de bucket de S3). Se trata de una política de IAM independiente para controlar el acceso desde el punto final al servicio especificado. De esta forma, añade otro nivel de control sobre el cual los directores de AWS pueden comunicarse con los recursos o servicios.

Amazon EC2

Las instancias de Amazon EC2 que componen nuestra aplicación utilizan la versión 2 del Instance Metadata Service (IMDSv2). IMDSv2 añade protecciones para cuatro tipos de vulnerabilidades que podrían utilizarse para intentar acceder al IMDS: firewalls de aplicaciones web, proxies inversos abiertos, vulnerabilidades de falsificación de solicitudes del lado del servidor (SSRF), firewalls abiertos de capa 3 y NAT. Para obtener más información, consulte la entrada del blog Mejore la defensa contra los firewalls abiertos, los proxies inversos y las vulnerabilidades de la SSRF con mejoras en el servicio de metadatos de instancias de EC2.

Utilice VPC independientes (como subconjunto de los límites de las cuentas) para aislar la infraestructura por segmentos de carga de trabajo. Utilice subredes para aislar los niveles de la aplicación (por ejemplo, web, aplicación y base de datos) en una VPC individual. Utilice subredes privadas para las instancias si no se debe acceder a ellas directamente desde Internet. Para llamar a la API Amazon EC2 desde su subred privada sin utilizar una puerta de enlace a Internet, utilice AWS. PrivateLink Restrinja el acceso a sus instancias mediante grupos de seguridad. Utilice registros de flujo de VPC para monitorear el tráfico que llegue a sus instancias. Utilice Session Manager, una función de AWS Systems Manager, para acceder a sus instancias de forma remota en lugar de abrir los puertos SSH entrantes y administrar las claves SSH. Utilice volúmenes independientes de Amazon Elastic Block Store (Amazon EBS) para el sistema operativo y sus datos. Puede configurar su cuenta de AWS para aplicar el cifrado de los nuevos volúmenes y copias instantáneas de EBS que cree. 

Ejemplo de implementación

La biblioteca de códigos SRA de AWS proporciona un ejemplo de implementación del cifrado Amazon EBS predeterminado en Amazon EC2. Demuestra cómo puede habilitar el cifrado de Amazon EBS predeterminado a nivel de cuenta en cada cuenta y región de AWS de la organización de AWS.

Application Load Balancers

Los balanceadores de carga de aplicaciones distribuyen el tráfico entrante de las aplicaciones entre varios destinos, como las instancias EC2, en varias zonas de disponibilidad. En la SRA de AWS, el grupo objetivo del balanceador de carga son las instancias EC2 de la aplicación. La SRA de AWS utiliza agentes de escucha HTTPS para garantizar que el canal de comunicación esté cifrado. El Application Load Balancer utiliza un certificado de servidor para finalizar la conexión front-end y, a continuación, para descifrar las solicitudes de los clientes antes de enviarlas a los destinos.

AWS Certificate Manager (ACM) se integra de forma nativa con los balanceadores de carga de aplicaciones, y la SRA de AWS usa ACM para generar y administrar los certificados públicos X.509 (servidor TLS) necesarios. Puede aplicar TLS 1.2 y cifrados seguros para las conexiones front-end mediante la política de seguridad de Application Load Balancer. Para obtener más información, consulte la Documentación de Elastic Load Balancing

Consideraciones sobre el diseño
  • Para situaciones comunes, como aplicaciones estrictamente internas que requieren un certificado TLS privado en el Application Load Balancer, puede usar ACM en esta cuenta para generar un certificado privado desde. Autoridad de certificación privada de AWS En la SRA de AWS, la CA privada raíz de ACM se aloja en la cuenta de Security Tooling y se puede compartir con toda la organización de AWS o con cuentas de AWS específicas para emitir certificados de entidad final, como se describió anteriormente en la sección de cuentas de Security Tooling. 

  • En el caso de los certificados públicos, puede usar ACM para generarlos y administrarlos, incluida la rotación automática. Como alternativa, puede generar sus propios certificados mediante las herramientas SSL/TLS para crear una solicitud de firma de certificados (CSR), conseguir que una autoridad de certificación (CA) firme la CSR para generar un certificado y, a continuación, importar el certificado a ACM o cargar el certificado en IAM para usarlo con Application Load Balancer. Si importa un certificado a ACM, debe controlar la fecha de caducidad del certificado y renovarlo antes de que caduque. 

  • Para obtener niveles de defensa adicionales, puede implementar políticas de AWS WAF para proteger el Application Load Balancer. Contar con políticas periféricas, políticas de aplicaciones e incluso capas de aplicación de políticas privadas o internas aumenta la visibilidad de las solicitudes de comunicación y proporciona una aplicación unificada de las políticas. Para obtener más información, consulte la entrada del blog Implementación de la defensa en profundidad mediante AWS Managed Rules for AWS WAF.

Autoridad de certificación privada de AWS

AWS Private Certificate Authority(Autoridad de certificación privada de AWS) se usa en la cuenta de la aplicación para generar certificados privados que se utilizarán con un Application Load Balancer. Es habitual que los balanceadores de carga de aplicaciones ofrezcan contenido seguro a través de TLS. Esto requiere que los certificados TLS estén instalados en Application Load Balancer. Para las aplicaciones que son estrictamente internas, los certificados TLS privados pueden proporcionar el canal seguro.

En la SRA de AWS, Autoridad de certificación privada de AWS se aloja en la cuenta de herramientas de seguridad y se comparte en la cuenta de la aplicación mediante la RAM de AWS. Esto permite a los desarrolladores de una cuenta de aplicación solicitar un certificado a una entidad emisora de certificados privada compartida. Compartir las CA en su organización o entre las cuentas de AWS ayuda a reducir el costo y la complejidad de crear y administrar las CA duplicadas en todas sus cuentas de AWS. Cuando utiliza ACM para emitir certificados privados desde una entidad emisora de certificados compartida, el certificado se genera localmente en la cuenta solicitante, y ACM se encarga de gestionar y renovar todo el ciclo de vida.

Amazon Inspector

La SRA de AWS utiliza Amazon Inspector para detectar y escanear automáticamente las instancias de EC2 y las imágenes de contenedores que se encuentran en el Amazon Elastic Container Registry (Amazon ECR) para detectar vulnerabilidades de software y exposición no intencionada a la red.

Amazon Inspector se coloca en la cuenta de la aplicación porque proporciona servicios de gestión de vulnerabilidades a las instancias EC2 de esta cuenta. Además, Amazon Inspector informa sobre las rutas de red no deseadas hacia y desde las instancias EC2.

La cuenta de administrador delegado gestiona de forma centralizada Amazon Inspector en las cuentas de los miembros. En la SRA de AWS, la cuenta Security Tooling es la cuenta de administrador delegado. La cuenta de administrador delegado puede gestionar las conclusiones, los datos y determinados ajustes de los miembros de la organización. Esto incluye ver los detalles de los resultados agregados de todas las cuentas de los miembros, habilitar o deshabilitar los escaneos de las cuentas de los miembros y revisar los recursos escaneados dentro de la organización de AWS. 

Consideraciones de diseño

Amazon Systems Manager

AWS Systems Manager es un servicio de AWS que puede utilizar para ver los datos operativos de varios servicios de AWS y automatizar las tareas operativas en todos sus recursos de AWS. Con flujos de trabajo y manuales de aprobación automatizados, puede trabajar para reducir los errores humanos y simplificar las tareas de mantenimiento e implementación en los recursos de AWS.

Además de estas capacidades generales de automatización, Systems Manager admite una serie de funciones de seguridad preventivas, de detección y con capacidad de respuesta. El agente AWS Systems Manager (SSM Agent) es un software de Amazon que se puede instalar y configurar en una instancia EC2, un servidor local o una máquina virtual (VM). El SSM Agent posibilita que Systems Manager actualice, administre y configure estos recursos. Systems Manager le ayuda a mantener la seguridad y el cumplimiento mediante el análisis de estas instancias gestionadas y la notificación (o la adopción de medidas correctivas) sobre cualquier infracción que detecte en sus políticas de parches, configuración y personalizadas. 

La SRA de AWS utiliza Session Manager, una capacidad de Systems Manager, para proporcionar una experiencia de CLI y shell interactiva y basada en el navegador. Esto proporciona una administración de instancias segura y auditable sin necesidad de abrir puertos de entrada, mantener los hosts bastiones ni administrar las claves SSH. La SRA de AWS utiliza Patch Manager, una capacidad de Systems Manager, para aplicar parches a las instancias de EC2 tanto para los sistemas operativos como para las aplicaciones. 

La SRA de AWS también utiliza la automatización, una capacidad de Systems Manager, para simplificar las tareas habituales de mantenimiento e implementación de las instancias de Amazon EC2 y otros recursos de AWS. Automation puede simplificar tareas de TI habituales, como cambiar el estado de uno o más nodos (mediante la automatización de la aprobación) y administrar los estados de los nodos de acuerdo con una programación. Systems Manager incluye características que lo ayudan a indicar grupos grandes de instancias como destino mediante el uso de etiquetas, así como controles de velocidad que le permitan implementar cambios de acuerdo con los límites que defina. La automatización ofrece automatizaciones con un solo clic para simplificar tareas complejas, como la creación de imágenes de máquinas de Amazon (AMI) de gran calidad y la recuperación de instancias EC2 inalcanzables. Además, puede mejorar la seguridad operativa dando a los roles de IAM acceso a manuales específicos para realizar determinadas funciones, sin necesidad de conceder permisos directos a esos roles. Por ejemplo, si desea que un rol de IAM tenga permisos para reiniciar instancias de EC2 específicas tras la actualización de los parches, pero no quiere conceder el permiso directamente a ese rol, puede crear un manual de automatización y conceder permisos al rol para que solo ejecute el runbook.

Consideraciones sobre el diseño
  • Systems Manager utiliza metadatos de las instancias EC2 para funcionar de forma correcta. Systems Manager puede acceder a los metadatos de la instancia mediante la versión 1 o la versión 2 del Servicio de metadatos de la instancia (IMDSv1 e IMDSv2). 

  • El agente SSM debe comunicarse con diferentes servicios y recursos de AWS, como los mensajes de Amazon EC2, Systems Manager y Amazon S3. Para que se produzca esta comunicación, la subred requiere conectividad a Internet saliente o el aprovisionamiento de los puntos finales de VPC adecuados. La SRA de AWS utiliza puntos de enlace de VPC para que el agente de SSM establezca rutas de red privadas a varios servicios de AWS. 

  • Con Automation, puede compartir las prácticas recomendadas con los demás miembros de su organización. Puede crear prácticas recomendadas para la administración de recursos en los manuales de ejecución y compartirlos entre las regiones y los grupos de AWS. También puede restringir los valores permitidos para los parámetros del runbook. Para estos casos de uso, es posible que tenga que crear manuales de automatización en una cuenta central, como Security Tooling o Shared Services, y compartirlos con el resto de la organización de AWS. Los casos de uso más comunes incluyen la capacidad de implementar parches y actualizaciones de seguridad de forma centralizada, corregir las desviaciones en las configuraciones de VPC o las políticas de bucket de S3 y administrar las instancias de EC2 a escala. Para obtener detalles sobre la implementación, consulte la documentación de Systems Manager.

Amazon Aurora

En la SRA de AWS, Amazon Aurora y Amazon S3 forman el nivel de datos lógicos. Aurora es un motor de base de datos relacional completamente administrado compatible con MySQL y PostgreSQL. Una aplicación que se ejecuta en las instancias EC2 se comunica con Aurora y Amazon S3 según sea necesario. Aurora se configura con un clúster de base de datos dentro de un grupo de subredes de base de datos. 

Consideraciones de diseño
  • Como en muchos servicios de bases de datos, la seguridad de Aurora se administra en tres niveles. Para controlar quién puede realizar acciones de administración de Amazon Relational Database Service (Amazon RDS) en clústeres e instancias de base de datos Aurora, utilice IAM. Para controlar qué dispositivos e instancias de EC2 pueden abrir conexiones al punto final del clúster y al puerto de la instancia de base de datos para los clústeres de base de datos Aurora en una VPC, utilice un grupo de seguridad de VPC. Para autenticar los inicios de sesión y los permisos de un clúster de base de datos Aurora, puede adoptar el mismo enfoque que con una instancia de base de datos independiente de MySQL o PostgreSQL, o puede utilizar la autenticación de bases de datos de IAM para Aurora MySQL Compatible Edition. Con este último enfoque, se autentica en su clúster de base de datos compatible con Aurora MySQL mediante un rol de IAM y un token de autenticación.

Amazon S3

Amazon S3 es un servicio de almacenamiento de objetos que ofrece escalabilidad, disponibilidad de datos, seguridad y rendimiento líderes del sector. Es la columna vertebral de los datos de muchas aplicaciones creadas en AWS, y los permisos y controles de seguridad adecuados son fundamentales para proteger los datos confidenciales. Para obtener información sobre las prácticas recomendadas de seguridad para Amazon S3, consulte la documentación, las charlas técnicas en línea y las publicaciones de blog más detalladas. La mejor práctica más importante es bloquear el acceso excesivamente permisivo (especialmente el acceso público) a los buckets de S3.

AWS KMS

La SRA de AWS ilustra el modelo de distribución recomendado para la administración de claves, en el que la clave de KMS reside en la misma cuenta de AWS que el recurso que se va a cifrar. Por este motivo, AWS KMS se utiliza en la cuenta de la aplicación además de estar incluido en la cuenta de herramientas de seguridad. En la cuenta de la aplicación, AWS KMS se usa para administrar las claves específicas de los recursos de la aplicación. Puede establecer una separación de funciones mediante políticas clave para conceder permisos de uso de las claves a las funciones de las aplicaciones locales y restringir los permisos de administración y supervisión a los custodios de las claves. 

Consideraciones de diseño
  • En un modelo distribuido, la responsabilidad de la administración de claves de AWS KMS recae en el equipo de aplicaciones. Sin embargo, su equipo de seguridad central puede ser responsable de la gobernanza y la supervisión de eventos criptográficos importantes, como los siguientes:

    • El material clave importado de una clave KMS se acerca a su fecha de vencimiento.

    • El material clave de una clave KMS se rotó automáticamente.

    • Se ha eliminado una clave KMS.

    • Hay una alta tasa de errores de descifrado.

AWS CloudHSM

AWS CloudHSM proporciona módulos de seguridad de hardware (HSM) gestionados en la nube de AWS. Le permite generar y usar sus propias claves de cifrado en AWS mediante el uso de HSM validados por FIPS 140-2 de nivel 3 a los que puede controlar el acceso. Puede usar CloudHSM para descargar el procesamiento SSL/TLS de sus servidores web. Esto reduce la carga del servidor web y proporciona seguridad adicional al almacenar la clave privada del servidor web en CloudHSM. También puede implementar un HSM desde CloudHSM en la VPC entrante de la cuenta de red para almacenar sus claves privadas y firmar las solicitudes de certificado si necesita actuar como autoridad de certificación emisora. 

Consideraciones de diseño
  • Si tiene requisitos estrictos para el nivel 3 de FIPS 140-2, también puede optar por configurar AWS KMS para que utilice el clúster de CloudHSM como almacén de claves personalizado en lugar de utilizar el almacén de claves de KMS nativo. De este modo, se beneficia de la integración entre AWS KMS y los servicios de AWS que cifran sus datos y, al mismo tiempo, es responsable de los HSM que protegen sus claves de KMS. Esto combina los HSM de un solo inquilino bajo su control con la facilidad de uso e integración de AWS KMS. Para administrar su infraestructura de CloudHSM, debe emplear una infraestructura de clave pública (PKI) y contar con un equipo con experiencia en la administración de HSM.

AWS Secrets Manager

AWS Secrets Manager lo ayuda a proteger las credenciales (secretos) que necesita para acceder a sus aplicaciones, servicios y recursos de TI. El servicio le permite rotar, administrar y recuperar de manera eficiente las credenciales de las bases de datos, las claves de API y otros secretos a lo largo de su ciclo de vida. Puedes sustituir las credenciales codificadas de tu código por una llamada a la API a Secrets Manager para recuperar el secreto mediante programación. Esto ayuda a garantizar que alguien que esté examinando tu código no pueda comprometer el secreto, ya que el secreto ya no existe en el código. Además, Secrets Manager le ayuda a mover sus aplicaciones entre entornos (desarrollo, preproducción, producción). En lugar de cambiar el código, puede asegurarse de que en el entorno esté disponible un secreto con el nombre y la referencia adecuados. Esto promueve la coherencia y la reutilización del código de la aplicación en diferentes entornos y, al mismo tiempo, requiere menos cambios e interacciones humanas una vez probado el código. 

Con Secrets Manager, puede gestionar el acceso a los secretos mediante políticas de IAM detalladas y políticas basadas en recursos. Puede ayudar a proteger los secretos cifrándolos con claves de cifrado que administra mediante AWS KMS. Secrets Manager también se integra con los servicios de registro y supervisión de AWS para una auditoría centralizada. 

Secrets Manager utiliza el cifrado de sobres con claves de datos y claves de AWS KMS para proteger cada valor secreto. Al crear un secreto, puede elegir cualquier clave simétrica administrada por el cliente en la cuenta y región de AWS, o puede usar la clave administrada por AWS para Secrets Manager. 

Como práctica recomendada, puede supervisar sus datos secretos para registrar cualquier cambio en ellos. Esto le ayuda a garantizar que se pueda investigar cualquier uso o cambio inesperado. Los cambios no deseados se pueden revertir. Secrets Manager actualmente es compatible con dos servicios de AWS que le permiten supervisar su organización y su actividad: AWS CloudTrail y AWS Config. CloudTrail captura todas las llamadas a la API de Secrets Manager como eventos, incluidas las llamadas desde la consola de Secrets Manager y las llamadas en código a las API de Secrets Manager. Además, CloudTrail captura otros eventos relacionados (ajenos a la API) que podrían afectar a la seguridad o el cumplimiento de su cuenta de AWS o que podrían ayudarlo a solucionar problemas operativos. Entre ellos se incluyen determinados eventos de rotación de secretos y la eliminación de versiones secretas. AWS Config puede proporcionar controles de detección mediante el seguimiento y la supervisión de los cambios en los secretos de Secrets Manager. Estos cambios incluyen la descripción del secreto, la configuración de rotación, las etiquetas y la relación con otras fuentes de AWS, como la clave de cifrado de KMS o las funciones de AWS Lambda utilizadas para la rotación del secreto. También puede configurar Amazon EventBridge, que recibe notificaciones de cambios en la configuración y la conformidad de AWS Config, para que dirija determinados eventos secretos a efectos de notificación o corrección. 

En la SRA de AWS, Secrets Manager se encuentra en la cuenta de la aplicación para respaldar los casos de uso de aplicaciones locales y administrar los secretos cercanos a su uso. Aquí, se adjunta un perfil de instancia a las instancias de EC2 de la cuenta de la aplicación. Luego, se pueden configurar secretos separados en Secrets Manager para permitir que ese perfil de instancia recupere secretos; por ejemplo, para unirse al dominio de Active Directory o LDAP correspondiente y acceder a la base de datos Aurora. Secrets Manager se integra con Amazon RDS para administrar las credenciales de los usuarios al crear, modificar o restaurar una instancia de base de datos de Amazon RDS o un clúster de base de datos Multi-AZ. Esto le ayuda a gestionar la creación y rotación de claves y sustituye las credenciales codificadas de su código por llamadas programáticas a la API a Secrets Manager.

Consideraciones de diseño
  • En general, configure y administre Secrets Manager en la cuenta que esté más cerca de donde se usarán los secretos. Este enfoque aprovecha el conocimiento local del caso de uso y proporciona velocidad y flexibilidad a los equipos de desarrollo de aplicaciones. En el caso de información estrictamente controlada en la que pueda resultar adecuado un nivel de control adicional, Secrets Manager puede gestionar los secretos de forma centralizada en la cuenta de Security Tooling.

Amazon Cognito

Amazon Cognito le permite añadir el registro, el inicio de sesión y el control de acceso de los usuarios a sus aplicaciones web y móviles de forma rápida y eficaz. Amazon Cognito se amplía a millones de usuarios y admite el inicio de sesión con proveedores de identidad social, como Apple, Facebook, Google y Amazon, y con proveedores de identidad empresarial mediante SAML 2.0 y OpenID Connect. Los dos componentes principales de Amazon Cognito son los grupos de usuarios y los grupos de identidades. Los grupos de usuarios son directorios de usuarios que proporcionan opciones de registro e inicio de sesión para los usuarios de la aplicación. Los grupos de identidades permiten conceder a los usuarios acceso a otros servicios de AWS. Puede utilizar los grupos de identidades y los grupos de usuarios juntos o por separado. Para ver los escenarios de uso más comunes, consulte la documentación de Amazon Cognito.

Amazon Cognito proporciona una interfaz de usuario integrada y personalizable para el registro e inicio de sesión de los usuarios. Puede usar Android, iOS y JavaScript los SDK de Amazon Cognito para añadir páginas de registro e inicio de sesión de usuarios a sus aplicaciones. Amazon Cognito Sync es una biblioteca de servicios y clientes de AWS que permite la sincronización entre dispositivos de los datos de usuario relacionados con las aplicaciones.  

Amazon Cognito admite la autenticación multifactorial y el cifrado de los datos en reposo y en tránsito. Los grupos de usuarios de Amazon Cognito ofrecen funciones de seguridad avanzadas para ayudar a proteger el acceso a las cuentas de la aplicación. Estas funciones de seguridad avanzadas proporcionan una autenticación adaptativa basada en los riesgos y la protección contra el uso de credenciales comprometidas.  

Consideraciones sobre el diseño
  • Puede crear una función de AWS Lambda y, a continuación, activarla durante las operaciones del grupo de usuarios, como el registro, la confirmación y el inicio de sesión (autenticación) de los usuarios con un activador de AWS Lambda. Puede agregar los desafíos de autenticación, migrar usuarios, y personalizar los mensajes de verificación. Para conocer las operaciones comunes y el flujo de usuarios, consulte la documentación de Amazon Cognito. Amazon Cognito llama a las funciones de Lambda de forma sincrónica. 

  • Puede usar los grupos de usuarios de Amazon Cognito para proteger aplicaciones pequeñas y de varios inquilinos. Un caso de uso común del diseño multiusuario es ejecutar cargas de trabajo para poder probar varias versiones de una aplicación. El diseño de varios inquilinos también es útil para probar una sola aplicación con diferentes conjuntos de datos, lo que permite el uso completo de los recursos del clúster. Sin embargo, asegúrese de que el número de inquilinos y el volumen esperado coincidan con las cuotas de servicio de Amazon Cognito correspondientes. Estas cuotas se comparten entre todos los inquilinos de la aplicación.

Amazon Verified Permissions

Amazon Verified Permissions es un servicio escalable de administración de permisos y autorización detallado para las aplicaciones que cree. Los desarrolladores y administradores pueden usar Cedar, un lenguaje de políticas de código abierto diseñado específicamente y centrado en la seguridad, con funciones y atributos para definir controles de acceso más detallados, sensibles al contexto y basados en políticas. Los desarrolladores pueden crear aplicaciones más seguras con mayor rapidez mediante la externalización de la autorización y la centralización de la gestión y la administración de las políticas. Los permisos verificados incluyen definiciones de esquemas, gramática de las declaraciones de políticas y un razonamiento automatizado que abarca millones de permisos, para que pueda aplicar los principios predeterminados de denegación y mínimo privilegio. El servicio también incluye una herramienta de simulación de evaluación que le ayuda a poner a prueba sus decisiones de autorización y sus políticas de autor. Estas funciones facilitan la implementación de un modelo de autorización exhaustivo y detallado para respaldar sus objetivos de confianza cero. Verified Permissions centraliza los permisos en un almacén de políticas y ayuda a los desarrolladores a utilizarlos para autorizar las acciones de los usuarios en sus aplicaciones.

Puede conectar su aplicación al servicio a través de la API para autorizar las solicitudes de acceso de los usuarios. Para cada solicitud de autorización, el servicio recupera las políticas pertinentes y las evalúa para determinar si un usuario puede realizar una acción en un recurso, en función de las entradas del contexto, como los usuarios, las funciones, la pertenencia a un grupo y los atributos. Puede configurar y conectar permisos verificados para enviar sus registros de autorización y administración de políticas a AWS CloudTrail. Si utiliza Amazon Cognito como almacén de identidades, puede integrarlo con Verified Permissions y utilizar el identificador y los tokens de acceso que Amazon Cognito devuelve en las decisiones de autorización de sus aplicaciones. Usted proporciona los tokens de Amazon Cognito a Verified Permissions, que utiliza los atributos que contienen los tokens para representar al principal e identificar sus derechos. Para obtener más información sobre esta integración, consulte la entrada del blog de AWS sobre cómo simplificar la autorización detallada con Amazon Verified Permissions y Amazon Cognito.

Los permisos verificados le ayudan a definir el control de acceso basado en políticas (PBAC). El PBAC es un modelo de control de acceso que utiliza permisos expresados como políticas para determinar quién puede acceder a qué recursos de una aplicación. El PBAC combina el control de acceso basado en roles (RBAC) y el control de acceso basado en atributos (ABAC), lo que da como resultado un modelo de control de acceso más potente y flexible. Para obtener más información sobre el PBAC y sobre cómo diseñar un modelo de autorización mediante permisos verificados, consulte la entrada del blog de AWS Control de acceso basado en políticas en el desarrollo de aplicaciones con permisos verificados de Amazon.

En la SRA de AWS, los permisos verificados se encuentran en la cuenta de la aplicación para facilitar la administración de permisos de las aplicaciones mediante su integración con Amazon Cognito.

Defensa por capas

La cuenta de aplicación brinda la oportunidad de ilustrar los principios de defensa por capas que AWS habilita. Tenga en cuenta la seguridad de las instancias de EC2 que constituyen el núcleo de una aplicación de ejemplo sencilla representada en la SRA de AWS y podrá ver la forma en que los servicios de AWS funcionan juntos en una defensa por capas. Este enfoque se ajusta a la visión estructural de los servicios de seguridad de AWS, tal como se describe en la sección Aplicar servicios de seguridad en toda la organización de AWS que aparece anteriormente en esta guía.

  • La capa más interna son las instancias de EC2. Como se mencionó anteriormente, las instancias EC2 incluyen muchas funciones de seguridad nativas de forma predeterminada o como opciones. Algunos ejemplos incluyen IMDSv2, el sistema Nitro y el cifrado de almacenamiento de Amazon EBS.

  • La segunda capa de protección se centra en el sistema operativo y el software que se ejecutan en las instancias EC2. Servicios como Amazon Inspector y AWS Systems Manager le permiten supervisar estas configuraciones, generar informes y tomar medidas correctivas en relación con ellas. El Inspector supervisa el software en busca de vulnerabilidades y Systems Manager lo ayuda a trabajar para mantener la seguridad y el cumplimiento mediante el análisis de las instancias gestionadas para comprobar el estado de los parches y la configuración y, a continuación, informar y tomar las medidas correctivas que especifique.

  • Las instancias y el software que se ejecuta en ellas forman parte de su infraestructura de red de AWS. Además de utilizar las características de seguridad de Amazon VPC, la SRA de AWS también utiliza los puntos de enlace de la VPC para proporcionar conectividad privada entre la VPC y los servicios de AWS compatibles, y para proporcionar un mecanismo para colocar las políticas de acceso en los límites de la red.

  • La actividad y la configuración de las instancias de EC2, el software, la red y las funciones y los recursos de IAM se supervisan aún más mediante servicios de AWS centrados en las cuentas, como AWS Security Hub, Amazon, GuardDuty AWS, AWS CloudTrail Config, AWS IAM Access Analyzer y Amazon Macie.

  • Por último, más allá de la cuenta de la aplicación, la RAM de AWS ayuda a controlar qué recursos se comparten con otras cuentas, y las políticas de control de servicios de IAM le ayudan a aplicar permisos coherentes en toda la organización de AWS.