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 (AWS SRA) realizando una breve encuesta |
El siguiente diagrama ilustra los servicios AWS de seguridad que están configurados en la cuenta de la aplicación (junto con la propia 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 unidad organizativa 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 CSPM, Amazon EventBridge, 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 de servicio, las restricciones y las barreras de protección adecuados.
Consideración del 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 varios elementos secundarios en OUs función del entorno de desarrollo, como los de producción, puesta en escena, pruebas y desarrollo, y utilizar elementos secundarios separados para Cuentas de AWS los OUs que pertenezcan a distintas aplicaciones. Otro patrón común es tener un elemento secundario diferente para OUs cada aplicación y, a continuación, utilizar un elemento secundario diferente Cuentas de AWS para los entornos de desarrollo individuales. La estructura exacta de la unidad organizativa y la estructura contable dependen del diseño de la aplicación y de los equipos que gestionen esas aplicaciones. Tenga en cuenta los controles de seguridad que desea aplicar, ya sean específicos del entorno o de la aplicación, ya que es más fácil implementar esos controles a medida que avanzan. SCPs OUs Para obtener más información sobre la organización orientada a las cargas de trabajo OUs, consulte la OUs sección Aplicaciones del documento AWS técnico Cómo organizar el entorno mediante varias cuentas. AWS
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 o necesidades de la aplicación). Servicio de AWS De forma predeterminada, los recursos de una VPC se pueden enrutar entre sí. Hay dos subredes privadas: una para alojar las EC2 instancias (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.
Consideración del diseño
Puede usar Traffic Mirroring para copiar el tráfico de red desde una interfaz de red elástica de EC2 instancias. 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 EC2 instancias que puedan estar funcionando 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 otra. Servicios de AWS(En la cuenta de aplicación, la AWS SRA emplea puntos de enlace de VPC AWS KMS para AWS Systems Manager Amazon S3 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 punto final de Servicios de AWS VPC compatibles y con tecnología 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 otras. Servicios de AWS El tráfico entre tu VPC y la otra Servicio de AWS no sale de la red de Amazon.
Otra ventaja del uso de puntos de enlace de VPC es permitir la configuración de políticas de puntos de conexión. 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 final, AWS adjunta una política de IAM predeterminada que te permita un acceso total al servicio. Una política de punto de enlace no invalida ni reemplaza las políticas de usuario de IAM ni las políticas específicas de servicios (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 AWS los principales pueden comunicarse con los recursos o servicios.
Amazon EC2
Las EC2 instancias de Amazon
Úselo por separado VPCs (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 EC2 API de Amazon desde tu subred privada sin usar una puerta de enlace de Internet, usa AWS PrivateLink. Restrinja el acceso a sus instancias mediante grupos de seguridad. Usa los registros de flujo de VPC para monitorear el tráfico que llega a tus instancias. Usa el administrador de sesiones, una funcionalidad que ofrece AWS Systems Manager, para acceder a tus 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 los datos. Puede configurarlos 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 AWS SRA
AWS Nitro Enclaves
AWS Nitro Enclaves
La certificación criptográfica es un proceso que se utiliza para probar la identidad de un enclave. El proceso de certificación se lleva a cabo a través del Hypervisor Nitro, que produce un documento de certificación firmado para que el enclave demuestre su identidad a otro tercero o servicio. Los documentos de certificación contienen detalles clave del enclave, como la clave pública del enclave, los códigos hash de la imagen y las aplicaciones del enclave, etc.
Con AWS Certificate Manager (ACM) para Nitro Enclaves, puede utilizar certificados públicos y privados. SSL/TLS certificates with your web applications and web servers running on EC2 instances with Nitro Enclaves. SSL/TLS certificates are used to secure network communications and to establish the identity of websites over the internet and resources on private networks. ACM for Nitro Enclaves removes the time-consuming and error-prone manual process of purchasing, uploading, and renewing SSL/TLS ACM for Nitro Enclaves crea claves privadas seguras, distribuye el certificado y su clave privada en su enclave y gestiona las renovaciones de los certificados. Con ACM para Nitro Enclaves, la clave privada del certificado permanece aislada en el enclave, lo que impide que la instancia y sus usuarios accedan a ella. Para obtener más información, consulte AWS Certificate Manager la sección sobre Nitro Enclaves en la documentación de Nitro Enclaves.
Equilibrador de carga de aplicación
Los balanceadores de carga de aplicaciones
AWS Certificate Manager (ACM) se integra de forma nativa con los balanceadores de carga de aplicaciones, y la AWS SRA usa el 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. AWS Private CAEn la AWS SRA, la CA privada raíz de ACM está alojada en la cuenta de Security Tooling y se puede compartir con toda la AWS organización o con una entidad específica Cuentas de AWS para emitir certificados de entidad final, tal y como se ha descrito anteriormente en la sección de cuentas de Security Tooling.
-
En el caso de los certificados públicos, puede utilizar ACM para generarlos y gestionarlos, incluida la rotación automática. Como alternativa, puede generar sus propios certificados mediante SSL/TLS herramientas para crear una solicitud de firma de certificado (CSR), conseguir que una entidad de certificación (CA) firme la CSR para producir 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 niveles de defensa adicionales, puede implementar AWS WAF políticas 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 Deplying defense in depth using Reglas administradas de AWS for AWS WAF
.
AWS Private CA
AWS Private Certificate Authority(AWS Private CA) 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 AWS SRA, AWS Private CA se aloja en la cuenta de Security Tooling y se comparte con la cuenta de la aplicación mediante el uso de. AWS RAM Esto permite a los desarrolladores de una cuenta de aplicación solicitar un certificado a una entidad emisora de certificados privada compartida. El hecho de compartir información CAs en toda la organización o entre ellas Cuentas de AWS ayuda a reducir el coste y la complejidad de crear y gestionar los duplicados CAs en todos sus ámbitos Cuentas de AWS. Cuando utiliza ACM para emitir certificados privados desde una entidad de certificación compartida, el certificado se genera localmente en la cuenta solicitante y ACM proporciona una gestión y renovación completas del ciclo de vida.
Amazon Inspector
La AWS SRA utiliza Amazon Inspector
Amazon Inspector se coloca en la cuenta de la aplicación porque proporciona servicios de gestión de vulnerabilidades a EC2 las instancias de esta cuenta. Además, Amazon Inspector informa sobre las rutas de red no deseadas hacia y desde EC2 las instancias.
Amazon Inspector en las cuentas de los miembros se gestiona de forma centralizada mediante la cuenta de administrador delegado. En la AWS SRA, 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 agregados de las conclusiones 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 AWS organización.
Consideración del diseño
Puede utilizar el Administrador de parches, una función de AWS Systems Manager, para activar la aplicación de parches bajo demanda y corregir las vulnerabilidades de seguridad críticas de Amazon Inspector o de otro tipo. Patch Manager le ayuda a corregir esas vulnerabilidades sin tener que esperar a que se aplique el programa habitual de parches. La corrección se lleva a cabo mediante el manual de automatización de Systems Manager. Para obtener más información, consulte la serie de blogs de dos partes Automatice la gestión y la corrección de vulnerabilidades AWS con Amazon Inspector
AWS Systems Manager
AWS Systems Manager
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.AWS Systems Manager El agente (SSM Agent) es un software de Amazon que se puede instalar y configurar en una EC2 instancia, 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 AWS SRA utiliza Session Manager, una capacidad de Systems Manager, para proporcionar una experiencia de CLI y shell interactiva y basada en navegador. Esto proporciona una administración de instancias segura y auditable sin necesidad de abrir los puertos de entrada, mantener los hosts bastiones ni administrar las claves SSH. La AWS SRA utiliza Patch Manager, una función de Systems Manager, para aplicar parches a las EC2 instancias tanto de los sistemas operativos como de las aplicaciones.
La AWS SRA también utiliza la automatización, una capacidad de Systems Manager, para simplificar las tareas comunes de mantenimiento e implementación de las EC2 instancias de Amazon y otros AWS recursos. 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 Amazon Machine Images (AMIs) de gran calidad y la recuperación de instancias inalcanzables. EC2 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 quieres que un rol de IAM tenga permisos para reiniciar EC2 instancias específicas tras la actualización de los parches, pero no quieres conceder el permiso directamente a ese rol, puedes crear un manual de automatización y conceder permisos al rol para que solo ejecute el runbook.
Consideraciones sobre el diseño
-
Systems Manager se basa en los metadatos de la EC2 instancia para funcionar correctamente. 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 y IMDSv2).
-
El agente SSM debe comunicarse con diferentes Servicios de AWS recursos, como Amazon EC2 Messages, 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 AWS SRA utiliza puntos finales de VPC para que el agente SSM establezca rutas de red privadas a varias. Servicios de AWS
-
Con Automation, puede compartir las prácticas recomendadas con los demás miembros de su organización. Puede crear las mejores prácticas para la administración de recursos en los manuales de ejecución y compartirlos entre grupos. Regiones de AWS También puede restringir los valores permitidos para los parámetros del runbook. Para estos casos de uso, puede que tengas 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. 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 EC2 las instancias a escala. Para obtener detalles sobre la implementación, consulte la documentación de Systems Manager.
Amazon Aurora
En la AWS SRA, Amazon Aurora
Consideración del 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 EC2 instancias 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
AWS KMS
La AWS SRA ilustra el modelo de distribución recomendado para la administración de claves, en el que AWS KMS key residen en el mismo lugar que el recurso que Cuenta de AWS 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 que son 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.
Consideración del diseño
En un modelo distribuido, la responsabilidad AWS KMS clave de la administración recae en el equipo de aplicaciones. Sin embargo, su equipo de seguridad central puede ser responsable del gobierno 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 la clave AKMS.
-
Hay una alta tasa de errores de descifrado.
AWS CloudHSM
AWS CloudHSM
Consideración del diseño
Si tiene requisitos estrictos para el nivel 3 de FIPS 140-2, también puede optar por configurarlo AWS KMS para usar el AWS CloudHSM clúster como almacén de claves personalizado en lugar de usar el almacén de claves de KMS nativo. De este modo, se beneficia de la integración entre los sistemas Servicios de AWS que cifran sus datos AWS KMS y, al mismo tiempo, es responsable de proteger sus claves de HSMs KMS. Esto combina un único propietario HSMs bajo su control con la facilidad de uso e integración de. AWS KMS Para administrar su AWS CloudHSM infraestructura, debe emplear una infraestructura de clave pública (PKI) y contar con un equipo con experiencia en la administración. HSMs
AWS Secrets Manager
AWS Secrets Manager
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 puede administrar mediante el uso. AWS KMS Secrets Manager también se integra con los servicios de AWS registro y supervisión para una auditoría centralizada.
Secrets Manager utiliza el cifrado de sobres con AWS KMS keys claves de datos para proteger cada valor secreto. Al crear un secreto, puede elegir cualquier clave simétrica gestionada por el cliente en la región Cuenta de AWS y, si lo prefiere, puede utilizar la clave AWS gestionada para Secrets Manager.
Como práctica recomendada, puedes supervisar tus datos secretos para registrar cualquier cambio que se produzca 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 admite actualmente dos Servicios de AWS que le permiten monitorear su organización y 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 Secrets Manager APIs. Además, CloudTrail captura otros eventos relacionados (ajenos a la API) que podrían afectar a la seguridad o el cumplimiento de normas Cuenta de AWS o que podrían ayudarle 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 detectivescos mediante el seguimiento y la supervisión de los cambios en los secretos de Secrets Manager. Estos cambios incluyen la descripción de un secreto, la configuración de rotación, las etiquetas y la relación con otras AWS fuentes, como la clave de cifrado KMS o las AWS Lambda funciones 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 AWS Config, para que enrute eventos secretos específicos para que se adopten medidas de notificación o corrección.
En la AWS SRA, 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 EC2 instancias 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.
Consideración del 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
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 Amazon Cognito JavaScript SDKs para añadir páginas de registro e inicio de sesión de usuarios a sus aplicaciones. Amazon Cognito Sync es una Servicio de AWS biblioteca de clientes que permite la sincronización entre dispositivos de los datos de usuario relacionados con la aplicación.
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 usuario 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 AWS Lambda función 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 Lambda. Puede agregar los desafíos de autenticación, migrar usuarios, y personalizar los mensajes de verificación. Para obtener información sobre 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. Todos los inquilinos de la aplicación las comparten.
Amazon Verified Permissions
Amazon Verified Permissions
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 los permisos verificados y conectarlos a ellos para enviar sus registros de autorización y administración de políticas. 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 AWS
blog 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 AWS blog Control de acceso basado en políticas en el desarrollo de aplicaciones con Amazon
En la AWS SRA, 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 la aplicación brinda la oportunidad de ilustrar los principios de defensa estratificados que AWS permiten. Tenga en cuenta la seguridad de las EC2 instancias que constituyen el núcleo de una aplicación de ejemplo sencilla representada en la AWS SRA y verá cómo se Servicios de AWS trabaja en conjunto en una defensa por capas. Este enfoque se ajusta a la visión estructural de los servicios de AWS seguridad, tal como se describe en la sección Aplicar los servicios de seguridad en toda la AWS organización, que aparece anteriormente en esta guía.
-
La capa más interna son las instancias. EC2 Como se mencionó anteriormente, EC2 las instancias incluyen muchas funciones de seguridad nativas de forma predeterminada o como opciones. Algunos ejemplos incluyen IMDSv2el 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 EC2 instancias. Servicios como Amazon Inspector
le AWS Systems Manager permiten monitorear, informar y tomar medidas correctivas en estas configuraciones. Amazon Inspector supervisa el software en busca de vulnerabilidades y Systems Manager le ayuda a mantener la seguridad y la conformidad 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 AWS de red. Además de utilizar las características de seguridad de Amazon VPC, la AWS SRA también utiliza puntos de enlace de la VPC para proporcionar conectividad privada entre la VPC y la compatible Servicios de AWS, 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 EC2 instancias, el software, la red y las funciones y los recursos de IAM se supervisan aún más mediante Cuenta de AWS servicios específicos AWS Security Hub CSPM, como AWS Security Hub Amazon,, GuardDuty AWS CloudTrail AWS Config, IAM Access Analyzer y Amazon Macie.
-
Por último, más allá de la cuenta de la aplicación, AWS RAM ayuda a controlar qué recursos se comparten con otras cuentas, y las políticas de control de los servicios de IAM ayudan a aplicar permisos coherentes en toda la organización. AWS