Escenarios de arquitectura segura

Escenario: Una instancia de EC2 ejecuta una aplicación web que necesita leer objetos de un bucket de S3 específico. El equipo de seguridad exige que no se almacenen credenciales de larga duración en la instancia y que el acceso siga el principio de mínimo privilegio. Solución: Cree un IAM role con una política que permita únicamente s3:GetObject sobre el ARN del bucket específico. Asocie el rol a la instancia de EC2 mediante un instance profile. La aplicación utiliza el servicio de metadatos de instancia (IMDS) para obtener automáticamente credenciales temporales; no es necesario almacenar claves.

Escenario: Una empresa almacena información personal identificable (PII) de sus clientes en una base de datos PostgreSQL de RDS. El equipo de cumplimiento exige cifrado en reposo y la posibilidad de auditar el uso de las claves. Solución: Habilite el cifrado de RDS mediante AWS KMS con una Customer Managed Key (CMK). La CMK permite al equipo de seguridad controlar la rotación de claves, consultar su uso en CloudTrail y revocar el acceso si es necesario. Nota: el cifrado debe habilitarse al crear la instancia de RDS; no puede cifrar una instancia de RDS existente y sin cifrar directamente. Para cifrar una base de datos existente, cree una snapshot, cópiela con el cifrado habilitado y restáurela a partir de la snapshot cifrada.

Escenario: Un desarrollador hizo público accidentalmente un bucket de S3, exponiendo datos de clientes. El equipo de seguridad quiere garantizar que ningún bucket de S3 de la cuenta pueda hacerse público, aunque un desarrollador lo intente. Solución: Habilite S3 Block Public Access a nivel de cuenta. Esta configuración prevalece sobre cualquier política de bucket o ACL que conceda acceso público, independientemente de lo que configuren los distintos equipos. Combínela con una regla de AWS Config (s3-bucket-public-read-prohibited) para detectar continuamente los buckets que no cumplen las normas y generar alertas.

Escenario: Una empresa quiere garantizar que su base de datos de RDS solo sea accesible desde sus servidores de aplicaciones y no desde Internet. Solución: Coloque RDS en una subred privada sin ninguna ruta a un gateway de Internet. Cree un grupo de seguridad para RDS que solo permita tráfico entrante en el puerto 5432 (PostgreSQL) desde el grupo de seguridad de los servidores de aplicaciones, no desde ningún rango de direcciones IP. Así, aunque un servidor de aplicaciones se vea comprometido, el atacante no podrá acceder a la base de datos desde fuera de la VPC, y el movimiento lateral quedará limitado por las reglas de los grupos de seguridad.

Escenario: Actualmente, el código de la aplicación contiene las credenciales de la base de datos codificadas directamente en los archivos de configuración. La auditoría de seguridad lo considera un riesgo crítico. Solución: Almacene las credenciales en AWS Secrets Manager y configure la rotación automática (Secrets Manager cuenta con funciones de rotación integradas de Lambda para RDS). Actualice la aplicación para que obtenga las credenciales de Secrets Manager durante la ejecución mediante el SDK. La aplicación obtiene automáticamente credenciales nuevas sin necesidad de realizar un despliegue en cada rotación. Habilite la plantilla de rotación de secretos de RDS para realizar una rotación de credenciales totalmente gestionada y sin tiempo de inactividad.

Escenario: Una empresa quiere detectar si las credenciales de una cuenta de AWS se han visto comprometidas y se están utilizando desde ubicaciones inesperadas. Solución: Habilite Amazon GuardDuty en todas las regiones. GuardDuty analiza eventos de CloudTrail, registros de flujo de VPC y registros de DNS mediante aprendizaje automático para detectar anomalías: llamadas a la API desde ubicaciones geográficas inusuales, patrones de minería de Bitcoin en EC2, comunicación con nodos de salida de Tor o patrones de exfiltración de credenciales. GuardDuty genera hallazgos que pueden activar reglas de EventBridge para notificar automáticamente al equipo de seguridad mediante SNS o crear un ticket de soporte.

Escenario: Una aplicación web que se ejecuta detrás de un ALB está recibiendo ataques de inyección SQL. La aplicación no se puede modificar de inmediato. Solución: Asocie AWS WAF al ALB. Implemente el grupo de reglas AWS Managed Rules for Common Threats (Core Rule Set y el grupo de reglas de SQL Database), que incluye detección preconfigurada de inyección SQL. WAF inspecciona las solicitudes HTTP antes de que lleguen al ALB y bloquea las solicitudes que coincidan con patrones de ataque; no se requiere modificar el código de la aplicación. Habilite también el registro de WAF en Kinesis Firehose para realizar análisis de seguridad.

Escenario: Una cuenta central de seguridad necesita acceso de solo lectura a todas las cuentas de cargas de trabajo de una AWS Organisation para realizar auditorías de seguridad. Solución: En cada cuenta de carga de trabajo, cree un IAM role con una política de confianza que permita a la cuenta de seguridad (mediante su ID de cuenta) asumirlo. Asocie una política de solo lectura (por ejemplo, la política gestionada por AWS SecurityAudit). El equipo de seguridad de la cuenta central utiliza STS AssumeRole para asumir temporalmente el rol en cada cuenta de carga de trabajo. Esto sigue el principio de mínimo privilegio: no se crean usuarios de IAM permanentes en las cuentas de carga de trabajo.

Escenario: Una empresa utiliza AWS Organizations y quiere impedir que cualquier cuenta de una OU que no sea de producción lance instancias GPU costosas. Solución: Cree una Service Control Policy (SCP) que deniegue ec2:RunInstances para las familias de instancias GPU (p3, p4, g4 y g5) y asóciela a la OU que no sea de producción. Las SCP se aplican incluso a los usuarios root y a los usuarios de IAM con nivel de administrador de las cuentas miembro; actúan como barreras de protección que ninguna identidad de la cuenta puede anular. Esto evita gastos elevados accidentales o maliciosos en las cuentas de desarrollo y pruebas.

Escenario: Una empresa de servicios financieros debe demostrar a los auditores que todas las llamadas a las API de AWS se registran, no pueden manipularse y se conservan durante 7 años. Solución: Cree un trail de AWS CloudTrail multirregional que entregue los registros a un bucket de S3 dedicado en una cuenta de registro. Habilite Log File Integrity Validation (archivos de resumen criptográficos que detectan la manipulación de registros). Establezca una política de Object Lock de S3 en modo Compliance, con un periodo de retención de 7 años, en el bucket de registro. Así se garantiza que los registros no puedan eliminarse ni modificarse, ni siquiera por el usuario root, durante el periodo de retención requerido.

Escenario: Las instancias de EC2 de una VPC privada necesitan acceder a S3 sin que el tráfico atraviese la Internet pública. Actualmente se utiliza un NAT Gateway y los costes son elevados debido a las tarifas de procesamiento de datos del NAT Gateway. Solución: Cree un S3 Gateway VPC Endpoint. Añada una entrada de ruta a la tabla de rutas de la subred privada que dirija la lista de prefijos de S3 al endpoint. El tráfico hacia S3 permanecerá completamente dentro de la red troncal de AWS; no se necesitará un NAT Gateway ni un gateway de Internet. Los S3 Gateway Endpoints son gratuitos (a diferencia de los Interface Endpoints, que tienen un coste por hora y por AZ). Esto también mejora la seguridad al eliminar el acceso a S3 de la ruta a través de Internet pública.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha trabajado con escenarios que abarcan: roles de IAM y perfiles de instancia para acceder a EC2 sin credenciales, Secrets Manager para la rotación automática de credenciales de bases de datos, AWS WAF para bloquear ataques de inyección sin cambios en el código y CloudTrail con S3 Object Lock para registros de cumplimiento a prueba de manipulaciones. A continuación, abordaremos escenarios de arquitecturas resilientes y de alta disponibilidad.