Prácticas recomendadas de seguridad en AWS para empresas: 16 controles

La seguridad en AWS para empresas suele quedarse corta porque el conjunto completo de controles conlleva un coste real y recurrente. Los CISO, los líderes de la nube y los equipos de FinOps pueden saber qué servicios habilitar, pero aun así limitan la monitorización, el registro, las copias de seguridad o los controles de red a las cuentas de producción o a una sola región cuando el presupuesto no cubre todo el patrimonio.

El Modelo de Responsabilidad Compartida de AWS significa que AWS protege la infraestructura de nube subyacente, mientras que su organización protege sus identidades, cargas de trabajo, configuraciones y datos. Esta guía cubre áreas de programa medibles, incluidos los riesgos de identidad como las claves de acceso, la gobernanza, la protección de datos, el cifrado en reposo, la detección, la infraestructura, la resiliencia y la respuesta. Estas prácticas recomendadas de seguridad en AWS respaldan controles de seguridad más sólidos y una postura de seguridad medible en todo el patrimonio. La guía complementa el Pilar de Seguridad del AWS Well-Architected Framework con consideraciones de costes e implementación a nivel de cuenta. Spendbase colabora con empresas en la revisión de la postura de seguridad y la reducción de costes en AWS, incluyendo formas de reducir su factura de AWS para que los controles más sólidos sean más fáciles de mantener. Comencemos con los patrones de fallo que exponen con mayor frecuencia los entornos empresariales.

Puntos clave

• La seguridad en AWS para empresas depende de una cobertura total del patrimonio en todas las cuentas, regiones, cargas de trabajo y copias de recuperación, no solo en los entornos de producción.
• Establezca una zona de aterrizaje (landing zone) multi-cuenta, federe el acceso humano, elimine las claves de acceso de larga duración, aplique el principio de mínimo privilegio y proteja las credenciales raíz con MFA resistente al phishing.
• Centralice el registro a prueba de manipulaciones, la detección de amenazas, la gestión de vulnerabilidades, la clasificación de datos, el cifrado, la gestión de secretos y los controles preventivos de red.
• Trate la seguridad como un programa operativo con propietarios asignados, SLA medibles, revisiones continuas de cumplimiento, simulacros de respuesta a incidentes y rutas de recuperación de copias de seguridad probadas.
• Modele tanto los cargos por servicios de AWS como los costes operativos, y luego implemente los controles por fases para que una cobertura más sólida siga siendo financieramente sostenible.
• Puede desplazarse hasta nuestra autoevaluación al final de este artículo para descubrir cómo puede realizarla ahora mismo.

Cómo se quiebra realmente la seguridad en AWS para empresas

La seguridad en AWS para empresas suele fallar en los límites entre cuentas, equipos y procesos operativos. Un rol de IAM amplio permite el movimiento lateral, una instantánea pública expone datos sensibles o una región sin monitorizar da tiempo a un atacante para operar sin ser detectado.

En El Modelo de Responsabilidad Compartida de AWS define qué protecciones proporciona AWS para la infraestructura de la nube y cuáles debe operar su organización. Su organización sigue siendo responsable de las identidades, las configuraciones, los datos, las cargas de trabajo y la respuesta. Por lo tanto, las prácticas recomendadas de seguridad eficaces en AWS cubren la gestión de identidades y accesos, la detección, la protección de la infraestructura, la protección de datos, la respuesta a incidentes y la gobernanza. El Marco bien diseñado de AWS, incluido su Pilar de Seguridad, proporciona un marco de trabajo útil. Los controles a continuación determinan si esa orientación mejora su postura de seguridad en la práctica.

Construya una zona de aterrizaje (landing zone) multi-cuenta antes de que la complejidad de AWS tome el control

Lo que es: Separe las herramientas de seguridad, el archivo de registros, las redes, la producción, la no producción, los entornos de prueba (sandboxes) y las cargas de trabajo suspendidas en cuentas distintas. Esta estructura también aclara la propiedad para la Gestión de Identidades y Accesos.

Cómo realizarlo: Cree una estructura de unidades organizativas (OU) bajo una única Organización de AWS y, a continuación, migre las cargas de trabajo cuenta por cuenta. Comience con los entornos de no producción para que los equipos puedan resolver los problemas de cuentas, redes y despliegue antes de trasladar los sistemas críticos.

Cómo lograrlo: Utilice AWS Organizations y AWS Control Tower para establecer directrices de control, Account Factory o Account Factory para Terraform (AFT) para el aprovisionamiento repetible, y AWS RAM para compartir redes y servicios gestionados de forma centralizada.

Qué previene: Que una credencial de desarrollo comprometida llegue a producción, conflictos de IAM entre equipos y una concentración excesiva de roles y recursos en una sola cuenta.

Impacto empresarial: Las cuentas separadas reducen el radio de explosión, simplifican la imputación de costes (chargeback), reducen el alcance de las auditorías y aceleran el aislamiento de incidentes. La contrapartida es un trabajo real de migración y aprovisionamiento, que a menudo requiere varias semanas de ingeniería de plataforma.

Lo que es: Elimine las credenciales raíz permanentes de las cuentas miembro y exija autenticación multifactor resistente al phishing para los administradores humanos.

Cómo realizarlo: Utilice la gestión centralizada de accesos raíz, conserve un acceso cuidadosamente controlado para el usuario raíz en la cuenta de gestión y almacene las credenciales de emergencia (break-glass) y las claves físicas FIDO2 en una ubicación segura. Exija un control dual para su retirada y registre cada uso.

Cómo lograrlo: Combine AWS Organizations, la gestión de accesos raíz de IAM, llaves de seguridad FIDO2 o passkeys, y alertas de AWS CloudTrail para inicios de sesión de raíz y acciones raíz privilegiadas.

Qué previene: La toma de control de la cuenta a través de una credencial raíz filtrada, incluidos los intentos de desactivar el registro, eliminar usuarios o destruir los controles de seguridad.

Impacto empresarial: Esto ofrece una gran reducción de riesgos con un bajo coste de servicio continuo. Sus gastos principales son las llaves físicas, el almacenamiento seguro, las pruebas y la gestión de procesos.

Federe el acceso humano y elimine las claves de acceso de larga duración

Lo que es: Los empleados se autentican a través del proveedor de identidad corporativo y reciben sesiones de AWS de corta duración. Las aplicaciones asumen roles en lugar de almacenar claves de acceso estáticas.

Cómo realizarlo: Conecte IAM Identity Center a Microsoft Entra ID, Okta o Ping. Asigne grupos a conjuntos de permisos, automatice los cambios de incorporación, traslado y salida de empleados, realice un inventario de los usuarios y claves de acceso de IAM, asigne la propiedad y elimine las claves de acceso no utilizadas.

Cómo lograrlo: Utilice IAM Identity Center, informes de credenciales, OIDC para CI/CD, perfiles de instancia de EC2 y EKS Pod Identity o IRSA para cargas de trabajo de Kubernetes.

Qué previene: La filtración de claves a través de repositorios, ordenadores portátiles, sistemas de compilación, registros y cuentas de antiguos empleados. La eliminación de las claves de acceso de larga duración también limita el valor de las credenciales robadas.

Impacto empresarial: Las revisiones de acceso se vuelven más sencillas y los cambios de empleados fluyen a través de los procesos de identidad existentes. Los scripts y aplicaciones que dependen de claves de acceso estáticas requieren una migración y pruebas planificadas.

Aplique el principio de mínimo privilegio con políticas que se adapten a todos los equipos

Lo que es: Aplique el principio de mínimo privilegio, otorgando a cada identidad solo el acceso requerido para su función. Los controles a nivel de toda la organización también deben evitar que las políticas individuales de IAM los eludan.

Cómo realizarlo: Comience con las SCP en modo de auditoría, revise los permisos no utilizados, genere políticas a partir de la actividad de CloudTrail y agregue comprobaciones de políticas a los pipelines de infraestructura. Utilice solicitudes de acceso de autoservicio para que los desarrolladores puedan obtener permisos aprobados sin excepciones informales.

Cómo lograrlo: Combine políticas de control de servicios (SCP), políticas de control de recursos (RCP), límites de permisos e IAM Access Analyzer para el acceso no utilizado, el acceso externo y la validación de políticas personalizadas.

Qué previene: La escalada de privilegios y el movimiento lateral después de que un atacante comprometa una identidad de bajo privilegio.

Impacto empresarial: El mínimo privilegio reduce la fricción de los desarrolladores cuando las solicitudes son previsibles y están documentadas. Requiere la propiedad de las políticas, tiempo de revisión y una aplicación gradual en lugar de un despliegue repentino que lo deniegue todo.

Establezca un perímetro de datos en AWS y controle el tráfico saliente

Lo que es: Restrinja el acceso a identidades, recursos, redes de confianza y destinos aprobados. Esto constituye una parte fundamental de la seguridad de la red.

Cómo realizarlo: Superponga las SCP con políticas de control de recursos y políticas de endpoints de VPC. Dirija el tráfico saliente a través de rutas inspeccionadas, defina dominios aprobados y restrinja el acceso NAT en lugar de permitir que cada subred privada acceda a Internet.

Cómo lograrlo: Utilice SCP, RCP, políticas de endpoints de VPC, AWS Network Firewall, filtrado de dominios y enrutamiento NAT restrictivo.

Qué previene: La filtración de datos a buckets controlados por atacantes, el acceso no autorizado entre cuentas y el uso indebido de credenciales válidas desde ubicaciones no fiables.

Impacto empresarial: Un perímetro de datos reduce el daño que puede causar una identidad comprometida. Pruebe las políticas por etapas, ya que las restricciones demasiado amplias pueden interrumpir las API de los proveedores, los repositorios de parches y las integraciones legítimas.

Cifre los datos en todas partes y gestione las claves de KMS correctamente

Lo que es: Cifre los datos en reposo y en tránsito en EBS, S3, RDS, Aurora y snapshots confidenciales. Este es un control de protección de datos fundamental.

Cómo realizarlo: Habilite los valores predeterminados de cifrado de EBS a nivel de cuenta, requiera cifrado del lado del servidor para los buckets de Amazon S3 y seleccione el cifrado al crear recursos de RDS o Aurora. Utilice claves de KMS administradas por el cliente para datos regulados, políticas de claves con ámbito definido y rotación automática.

Cómo lograrlo: Utilice AWS Key Management Service (KMS), certificados de ACM, S3 aws:SecureTransport políticas y CloudHSM cuando se apliquen mayores garantías o requisitos normativos específicos.

Qué previene: Exposición por snapshots robados, AMIs copiadas, volúmenes abandonados y tráfico interceptado.

Impacto empresarial: El cifrado respalda los requisitos normativos comunes, pero las solicitudes de KMS de gran volumen pueden aumentar los costos. El almacenamiento en caché de claves de datos puede reducir las llamadas repetidas a la API cuando la carga de trabajo lo admita.

Centralice la gestión de secretos y rote las credenciales automáticamente

Lo que es: Mantenga las contraseñas de las bases de datos, los tokens de API y las credenciales de las aplicaciones fuera del código fuente, las imágenes, las AMIs, los logs y los archivos de compilación.

Cómo realizarlo: Escanee los repositorios y las imágenes de contenedores, elimine los secretos expuestos, mígrelos a un almacenamiento administrado y otorgue acceso a las aplicaciones a través de roles de IAM. Habilite la rotación para las credenciales de bases de datos y otros secretos compatibles.

Cómo lograrlo: Utilice AWS Secrets Manager para secretos confidenciales y SSM Parameter Store para configuraciones de menor sensibilidad.

Qué previene: Robo de credenciales del historial de Git, capas de imágenes, logs, archivos de soporte y artefactos de compilación.

Impacto empresarial: La rotación automatizada elimina una fuente común de deuda técnica. Los equipos aún deben actualizar las aplicaciones que esperan credenciales en archivos o variables de entorno estáticas.

Segmente las redes y prefiera la conectividad privada

Lo que es: Ubique el cómputo y las bases de datos en subredes privadas, exponga solo balanceadores de carga controlados y separe los sistemas por nivel y sensibilidad dentro de una Virtual Private Cloud (VPC).

Cómo realizarlo: Reemplace las reglas CIDR amplias con referencias estrechas a grupos de seguridad. Utilice endpoints de VPC de gateway e interfaz para los servicios de AWS, Transit Gateway para el enrutamiento centralizado y PrivateLink para conexiones de socios aprobados.

Cómo lograrlo: Combine niveles de subredes públicas, privadas e aisladas con grupos de seguridad, listas de control de acceso que los complementen, Transit Gateway, PrivateLink y AWS Network Firewall.

Qué previene: Acceso directo a Internet a bases de datos y servicios internos, además de movimiento este-oeste tras un compromiso inicial.

Impacto empresarial: La conectividad privada reduce la superficie de ataque, pero los endpoints de interfaz, Transit Gateway y el procesamiento de datos añaden cargos recurrentes. Incluya esos costos en los estándares de la plataforma antes de aplicar el diseño.

Centralice el registro y haga que los registros de auditoría sean a prueba de manipulaciones

Lo que es: Envíe registros de auditoría de toda la organización a una cuenta de Log Archive dedicada que las cuentas de carga de trabajo no puedan modificar. Las pruebas inmutables también protegen el conjunto más amplio de controles de seguridad.

Cómo realizarlo: Configure un rastro de AWS CloudTrail multi-región en toda la organización. Agregue eventos de datos confidenciales de S3 y Lambda, VPC Flow Logs, registro de AWS Config en toda la organización y retención de CloudWatch definida. Aplique S3 Object Lock en modo de cumplimiento.

Qué previene: Atacantes que eliminan pruebas después de un compromiso o que dejan a los investigadores sin una línea de tiempo de actividad confiable.

Impacto empresarial: Los logs inmutables mejoran el análisis forense, las pruebas de auditoría y el análisis de brechas. El registro es uno de los costos de seguridad recurrentes más altos, por lo que debe conservar los datos recientes en almacenamiento activo y archivar los registros más antiguos.

Ejecute detección continua de amenazas con operaciones de seguridad unificadas

Lo que es: Detecte actividades sospechosas en cuentas y regiones, y luego dirija los hallazgos a un único proceso de respuesta. La detección centralizada de amenazas facilita la identificación de brechas de cobertura.

Cómo realizarlo: Habilite Amazon GuardDuty en toda la organización a través de un administrador delegado. Active los planes de protección relevantes para S3, EKS, RDS, Lambda, malware y actividad en tiempo de ejecución. Centralice los hallazgos en Security Hub y envíe alertas de alta gravedad a un SIEM.

Cómo lograrlo: Utilice GuardDuty, Security Hub, Inspector, Macie, EventBridge, Lambda, remediación de SSM e investigaciones de Detective.

Qué previene: Uso indebido de credenciales, actividad de comando y control, criptominería, acceso malicioso a datos y largos períodos de actividad no detectada.

Impacto empresarial: La detección sin una respuesta dotada de personal solo crea volumen de alertas. Presupueste para el uso del servicio, el enrutamiento SIEM, el tiempo de investigación y la capacidad de guardia.

Gestione las vulnerabilidades y aplique parches a las cargas de trabajo según un SLA definido

Lo que es: Establezca la gestión de vulnerabilidades escaneando EC2, ECR y Lambda continuamente, y luego conecte los hallazgos con plazos de remediación basados en la gravedad.

Cómo realizarlo: Establezca umbrales de compilación de CI, defina líneas base de Systems Manager Patch Manager, programe ventanas de mantenimiento y reemplace las cargas de trabajo inmutables en lugar de aplicar parches manualmente a los hosts en ejecución.

Cómo lograrlo: Utilice Amazon Inspector, escaneo mejorado de ECR, Systems Manager, EC2 Image Builder y AMIs de oro.

Qué previene: Explotación de vulnerabilidades conocidas en hosts, imágenes, dependencias y funciones.

Impacto empresarial: Realice un seguimiento del tiempo medio de remediación por gravedad. Sin propietarios y plazos claros, los escáneres producen un backlog ignorado en lugar de una reducción medible del riesgo.

Clasifique los datos confidenciales y evite la exposición pública

Lo que es: Identifique los datos confidenciales y dificulte la creación o el mantenimiento del acceso público. Incluya buckets de Amazon S3, snapshots, bases de datos y otros recursos en la revisión de exposición.

Cómo realizarlo: Aplique S3 Block Public Access a nivel de cuenta a través de una SCP. Utilice Macie para descubrir PII, PHI y datos de pago, revise los hallazgos de acceso externo de IAM Access Analyzer y aplique etiquetas de recursos que admitan ABAC.

Cómo lograrlo: Combine Macie, controles de S3, comprobaciones de línea base de configuración de AWS Config, estándares de etiquetado y políticas de ABAC.

Qué previene: Buckets públicos, snapshots expuestos, bases de datos abiertas e incertidumbre sobre qué datos regulados contenía un recurso comprometido.

Impacto empresarial: La clasificación mejora el alcance del cumplimiento y el análisis de brechas. Los costos de Macie dependen del volumen de datos, por lo que el descubrimiento dirigido y el muestreo pueden ser más prácticos que el escaneo continuo de cada objeto.

Proteja el borde y la capa de aplicación con controles WAF y DDoS

Lo que es: Filtre y limite la tasa de tráfico antes de que llegue a las aplicaciones públicas.

Cómo realizarlo: Coloque CloudFront y Route 53 frente a los servicios públicos. Adjunte grupos de reglas administradas de AWS WAF y reglas basadas en tasas, comience en modo de conteo, ajuste según el tráfico real y luego aplique el bloqueo.

Cómo lograrlo: Utilice AWS WAF, CloudFront, Shield Standard, Shield Advanced, controles de bots y análisis de tráfico.

Qué previene: Riesgos de OWASP, relleno de credenciales, scraping y ataques DDoS en la capa de aplicación.

Impacto empresarial: Shield Advanced debe reflejar los ingresos en riesgo y los requisitos de disponibilidad. Su costo de suscripción es significativo, por lo que no es una compra predeterminada para cada carga de trabajo.

Asegurar la CI/CD y la cadena de suministro de software

Lo que es: Tratar los sistemas de compilación como infraestructura de producción privilegiada, ya que pueden realizar despliegues en cuentas sensibles.

Cómo realizarlo: Utilizar roles de despliegue federados por OIDC con permisos específicos del entorno. Verificar las dependencias, almacenar los paquetes aprobados en CodeArtifact, firmar artefactos y contenedores, y analizar los cambios de infraestructura antes de su despliegue.

Cómo lograrlo: Utilizar AWS Signer, verificación de ECR, CodeArtifact, CloudFormation Guard, cfn-nag, Checkov y comprobaciones de políticas de IAM.

Qué previene: Dependencias comprometidas, pasos de compilación envenenados, artefactos sin firmar y cambios de infraestructura inseguros.

Impacto empresarial: Comenzar con puertas de advertencia y, a continuación, pasar los hallazgos graves a bloqueantes a medida que los equipos se adapten. La aplicación gradual mejora la adopción sin debilitar el estándar final.

Hacer que las copias de seguridad sean inmutables y probar cada ruta de recuperación

Lo que es: Mantener copias de recuperación que un atacante con acceso de administrador de producción no pueda eliminar ni alterar.

Cómo realizarlo: Aplicar políticas de organización de AWS Backup, copiar copias de seguridad entre cuentas y regiones, y utilizar el bloqueo de bóveda o bóvedas aisladas de forma lógica. Proteger los datos de S3 con control de versiones, Object Lock, controles de retención y cifrado.

Qué previene: Ransomware, usuarios internos destructivos y procesos de copia de seguridad que parecen correctos pero fallan durante la restauración.

Impacto empresarial: Realizar simulacros de restauración al menos trimestralmente y documentar los resultados medidos de RTO y RPO. Los costes de almacenamiento, replicación y transferencia son reales, pero recortar este presupuesto puede aumentar el riesgo de interrupciones.

Institucionalizar la respuesta ante incidentes y el cumplimiento normativo continuo

Lo que es: Mantener procedimientos de respuesta ensayados y revisar los controles de seguridad después del despliegue y de cambios importantes.

Cómo realizarlo: Crear un plan de respuesta ante incidentes con manuales de estrategia para el compromiso de credenciales, exposición de datos públicos, ransomware y uso indebido por parte de personal interno. Preaprovisionar una cuenta forense y roles de incidentes, realizar ejercicios teóricos dos veces al año y automatizar la recopilación de pruebas.

Cómo lograrlo: Utilizar Amazon Detective, AWS Security Incident Response, paquetes de conformidad de AWS Config, Audit Manager y revisiones anuales con AWS Well-Architected Tool y su Pilar de Seguridad.

Qué previene: Respuesta lenta, desviación de la configuración, pruebas de auditoría incompletas y decisiones improvisadas durante un evento de seguridad.

Impacto empresarial: Las revisiones periódicas reducen el trabajo de preparación de las auditorías y mantienen el resto de los controles funcionando según lo diseñado. El programa de seguridad debe revisarse anualmente y tras cambios arquitectónicos importantes.

Lo que realmente cuesta implementar la seguridad de AWS para empresas

La seguridad de AWS para empresas cuesta más que activar unos pocos servicios en la consola. Su factura incluye los cargos de AWS basados en el uso, la ingeniería de infraestructura en la nube, el trabajo de migración, las operaciones de seguridad, la respuesta ante incidentes, la preparación de auditorías y el tiempo necesario para mantener la eficacia de los controles.

La pregunta correcta no es: “¿Cuánto cuesta GuardDuty?”. Pregunte en su lugar:, “¿Cuánto costará la cobertura completa en cada cuenta, región, carga de trabajo, origen de registros y copia de recuperación?” Un despliegue limitado solo a producción puede parecer asequible, pero deja sin supervisar las cuentas de desarrollo, las regiones secundarias o las rutas de datos sensibles.

Separar los cargos de AWS de los costes operativos de seguridad

Los servicios de seguridad de AWS suelen escalar con el tamaño y la actividad de su entorno. Las cuentas, las regiones, el volumen de registros, los datos analizados, el recuento de recursos, las solicitudes de API, el tráfico, los hallazgos, los periodos de retención y las copias de seguridad pueden afectar al importe final.

Su modelo financiero debe separar los cargos directos de la nube de los costes operativos internos. También debe tener en cuenta la protección de datos, la propiedad de los mismos y el esfuerzo necesario para mantener la eficacia de cada control. De lo contrario, el presupuesto de seguridad parecerá menor de lo que realmente es el programa.

Categoría de costes	Qué impulsa el coste	Presión presupuestaria típica
Identidad y gobernanza	Llaves MFA, migración de cuentas, diseño de políticas, revisiones de acceso, claves de acceso	Tiempo de ingeniería y procesos
Registro y monitorización	Eventos de CloudTrail, VPC Flow Logs, registros de Config, retención, consultas	Tasas de almacenamiento, ingesta y SIEM
Detección y análisis	Orígenes de datos de GuardDuty, recursos de Security Hub, análisis de Inspector, descubrimiento de Macie	Número de recursos y volumen de datos
Protección de red	Puntos de enlace de VPC, Transit Gateway, Network Firewall, NAT, tráfico inspeccionado	Cargos por hora y procesamiento de datos
Cifrado y secretos	Solicitudes de KMS, claves administradas por el cliente, entradas y rotación de Secrets Manager	Volumen de solicitudes y recuento de secretos
Protección del perímetro	Solicitudes de WAF, reglas administradas, Bot Control, Shield Advanced	Tráfico público y necesidades de suscripción
Resiliencia de las copias de seguridad	Almacenamiento, replicación, transferencia entre regiones, pruebas de restauración	Requisitos de retención y recuperación

La factura directa de AWS es solo una parte del total. Los equipos también necesitan tiempo para la reestructuración de cuentas, la migración de IAM, las pruebas de políticas, los cambios en las aplicaciones, los simulacros teóricos, la remediación de vulnerabilidades y la recopilación de pruebas.

Por ejemplo, reemplazar las claves de acceso estáticas puede tener un coste de servicio mínimo, pero consumir semanas de trabajo a los equipos de ingeniería. Mover las cargas de trabajo a subredes privadas puede reducir la exposición, pero puede requerir nuevas rutas, puntos de enlace de VPC, reglas de firewall y conectividad con socios. Esos costes de mano de obra pertenecen al caso de negocio.

Un control de seguridad que no tiene propietario, destino de alertas o programa de revisión es un control inacabado, incluso cuando el servicio de AWS está habilitado.

### El registro y la detección se convierten en los mayores costes recurrentes

El registro centralizado suele ser el primer aumento importante después de que una empresa estandariza su arquitectura de seguridad. AWS CloudTrail para toda la organización, VPC Flow Logs, AWS Config, eventos de datos de S3, eventos de datos de Lambda y registros de aplicaciones pueden generar un gran volumen de registros.

Las opciones de retención son importantes. Mantener cada registro en CloudWatch Logs durante años rara vez es el diseño más económico. Muchas organizaciones conservan los registros recientes en un almacenamiento con capacidad de búsqueda y luego transfieren los datos más antiguos a buckets de Amazon S3 y almacenamiento de archivo con políticas de retención y Object Lock. Los requisitos regulatorios deben determinar el periodo de retención, no la conveniencia.

El mismo principio se aplica a la detección de amenazas. El precio de Amazon GuardDuty depende de las fuentes de datos analizadas y de la actividad de la carga de trabajo, incluidos los registros de servicios, las vCPU, las cargas de trabajo en tiempo de ejecución y los datos analizados en busca de malware. Eso significa que dos organizaciones con el mismo número de cuentas de AWS pueden recibir facturas muy diferentes.

Security Hub ofrece ahora un modelo de precios simplificado que combina los aspectos esenciales de Security Hub, Amazon Inspector y Cloud Security Posture Management en una estructura por recurso con análisis ilimitados bajo el plan aplicable. El ejemplo de precios de AWS utiliza 1.210 unidades de recursos a $3.75 por recurso, lo que genera un ejemplo mensual de $4,537.50. Considere esa cifra como una ilustración, no como un presupuesto empresarial, ya que la combinación de recursos y la región afectan al resultado. Revise el actual modelo de precios de AWS Security Hub antes de aprobar un despliegue.

La detección también genera costes operativos. Los hallazgos deben llegar a un SIEM, a un sistema de tickets o a una rotación de guardia. Alguien debe investigar los falsos positivos, ajustar las reglas, cerrar los hallazgos y confirmar que la remediación automatizada no interrumpió una carga de trabajo legítima.

Por lo tanto, una previsión útil incluye:

• El número de cuentas y regiones habilitadas.
• Los recursos cubiertos por cada plan de detección y escaneo.
• El volumen de eventos de CloudTrail, de red, de aplicaciones y de datos.
• El porcentaje de hallazgos enviados a un SIEM externo.
• El número de analistas o ingenieros asignados a la respuesta.
• Los periodos previstos de retención y archivo.

Activar todos los detectores sin financiar la respuesta es similar a instalar alarmas de humo sin que nadie esté asignado a revisarlas.

Los controles de red, cifrado y perímetro conllevan concesiones visibles

La conectividad privada puede añadir costes recurrentes significativos. Los endpoints de VPC de interfaz tienen costes por hora y de procesamiento de datos. Transit Gateway añade cargos por conexión y procesamiento, mientras que Network Firewall y el tráfico NAT inspeccionado añaden más gastos de capacidad y procesamiento. Juntos, estos servicios dan forma al coste de la seguridad de la red.

Estos servicios no son un desperdicio automático. Pueden reducir la exposición pública, simplificar los estándares de enrutamiento y limitar las rutas disponibles para la filtración de datos. Sin embargo, debe modelar los patrones de tráfico antes de hacerlos obligatorios para cada cuenta. Una carga de trabajo interna pequeña puede necesitar un diseño diferente al de una plataforma de análisis de gran volumen.

Los costes de cifrado suelen aparecer a través de las solicitudes de KMS más que por la decisión básica de utilizar el cifrado en reposo. Las cargas de trabajo que llaman a AWS Key Management Service para cada objeto o transacción pueden generar grandes volúmenes de solicitudes. El almacenamiento en caché de claves de datos y los patrones lógicos de cifrado de sobres pueden reducir las llamadas repetidas sin debilitar la protección.

Secrets Manager genera un coste recurrente por secreto almacenado y añade cargos por las llamadas a la API. Ese gasto suele ser modesto en comparación con el esfuerzo de ingeniería necesario para rotar las credenciales manualmente o investigar una contraseña filtrada. Aun así, los secretos inactivos deben eliminarse y las aplicaciones deben solicitar secretos en tiempo de ejecución a través de roles en lugar de copiarlos en los artefactos de compilación.

Para los buckets de Amazon S3, el cifrado en el servidor en sí no suele ser el principal factor de coste. Las solicitudes de claves relacionadas, la replicación, el almacenamiento y el procesamiento de datos pueden afectar al total. Para las aplicaciones públicas, los costes de WAF dependen del volumen de solicitudes y de las capacidades seleccionadas. Las reglas gestionadas, las reglas basadas en tasas, Bot Control y el registro pueden afectar al total. Shield Advanced añade un compromiso de suscripción significativo, así que base esa decisión en la exposición de los ingresos, los objetivos de disponibilidad y el coste del soporte de incidentes.

Las copias de seguridad y el cumplimiento convierten la seguridad en un compromiso a largo plazo

Las copias de seguridad inmutables requieren algo más que una instantánea programada. Las copias entre cuentas y entre regiones aumentan los costes de almacenamiento y transferencia, mientras que una retención más larga mantiene esos cargos activos. S3 Versioning, Object Lock, la replicación y las pruebas de recuperación añaden más almacenamiento y trabajo operativo a lo largo del ciclo de vida de copia de seguridad y recuperación.

Sin embargo, una copia de seguridad que nunca se ha restaurado es una suposición, no un plan de recuperación. Los ejercicios de restauración trimestrales requieren tiempo de ingeniería, entornos de prueba, propietarios de aplicaciones y resultados documentados de RTO y RPO. Esos ejercicios exponen los fallos mientras aún se pueden solucionar.

El cumplimiento también conlleva un coste de mano de obra. Los paquetes de conformidad de AWS Config, Audit Manager, la evidencia centralizada y las revisiones de acceso recurrentes reducen el trabajo manual, pero no eliminan la propiedad. Los estándares de cumplimiento varían según la organización, y cada control necesita un equipo responsable, un proceso de excepción y una cadencia de revisión. Las auditorías de seguridad añaden otra demanda recurrente de evidencia y revisión.

Presupueste estas categorías por separado:

1. Coste de construcción: diseño de zonas de aterrizaje, migraciones, desarrollo de políticas y cambios en las aplicaciones.
2. Coste de ejecución: servicios de AWS, ingesta de SIEM, almacenamiento, licencias y cobertura de guardia.
3. Coste de aseguramiento: auditorías, pruebas de penetración, simulacros de restauración, ejercicios de mesa, gestión de vulnerabilidades y revisiones independientes.
4. Coste de cambio: nuevas regiones, adquisiciones, lanzamientos de cargas de trabajo y cambios de arquitectura importantes.

La cifra resultante variará según el patrimonio. Una empresa más pequeña con un volumen de registros modesto puede gastar poco en servicios pero más en la ingeniería inicial. Una gran plataforma multirregión puede gastar mucho en procesamiento de datos, retención, ingesta de SIEM y personal de respuesta.

Reducir la tarifa efectiva de AWS puede facilitar el mantenimiento de una cobertura total de control sin recortar servicios ni acortar la retención. Las soluciones de Spendbase Descuentos AWS pueden ayudar a los equipos financieros a revisar esa aritmética junto con su cobertura de seguridad, de modo que los ahorros respalden los controles en lugar de convertirse en una razón para limitarlos.

Elabore la previsión a partir de datos reales de cuentas y uso, luego pruebe tres escenarios: cobertura mínima de cumplimiento, cobertura empresarial recomendada y cobertura total para cargas de trabajo de alto riesgo. Esa comparación ofrece al CISO y al CFO una opción práctica, en lugar de forzar las decisiones de seguridad en una solicitud de presupuesto vaga de todo o nada.

Despliegue la lista de verificación de seguridad de AWS en 90 días

Un entorno de AWS seguro debe mejorar a través de hitos planificados, no mediante una carrera de auditoría apresurada. AWS recomienda un viaje por fases alineado con el Marco bien diseñado de AWS, comenzando con la estructura de cuentas y la gestión de identidades y accesos, para luego añadir controles en capas, protección de datos, automatización y preparación ante incidentes.

Utilice estas mejores prácticas de seguridad de AWS en una lista de verificación de 90 días primero para una carga de trabajo crítica. Una vez que los patrones funcionen, expándalos a través de infraestructura como código en el resto de su organización. Este enfoque genera un progreso mensurable sin esperar a que cambien todas las cuentas, regiones y aplicaciones a la vez.

Días 1 al 30: Establecer la identidad, la visibilidad y la propiedad

El primer mes debería cerrar los riesgos que podrían dar a un atacante un acceso amplio o dejar a su equipo sin evidencia fiable. Asigne un patrocinador ejecutivo, un propietario técnico y un propietario para cada control de seguridad. Luego, registre cada cuenta de AWS, región, carga de trabajo, almacén de datos, usuario de IAM, claves de acceso e integración externa.

Comience con la gobernanza de cuentas. Confirme que todas las cuentas pertenecen a una organización de AWS, identifique la cuenta de administración y cree cuentas dedicadas para herramientas de seguridad y archivo de registros. Si su zona de aterrizaje está incompleta, defina la estructura de OU y aplique las primeras directrices de Control Tower antes de mover las cargas de trabajo de producción.

A continuación, proteja el acceso privilegiado, especialmente el usuario root:

1. Elimine las credenciales de usuario root innecesarias de las cuentas de miembros mediante la gestión centralizada de acceso root.
2. Exija autenticación multifactor para cada principal humano, con claves de seguridad FIDO2 o claves de paso para administradores e identidades de acceso de emergencia.
3. Conecte IAM Identity Center con su proveedor de identidad corporativo.
4. Reemplace los usuarios de IAM y las claves de acceso de larga duración por conjuntos de permisos, roles de IAM y sesiones federadas de corta duración.
5. Revise cada rol con privilegios, asigne un propietario y documente su uso aprobado.

No espere hasta el final del mes para establecer la trazabilidad. Cree un rastro de AWS CloudTrail para toda la organización y para varias regiones, y envíe los registros a un bucket de S3 en la cuenta de archivo de registros (Log Archive). Restrinja el acceso de las cargas de trabajo a ese bucket, defina períodos de retención y aplique Object Lock cuando los requisitos normativos exijan registros inmutables.

Habilite el registro de AWS Config en las cuentas y regiones involucradas. Utilice los hallazgos de AWS Config para establecer una base de referencia para recursos públicos, almacenamiento no cifrado, grupos de seguridad sin restricciones, registros desactivados y etiquetas faltantes. La guía de seguridad en la nube de AWS también enfatiza la identidad, el monitoreo, la protección de la infraestructura y la seguridad de los datos como partes conectadas del programa.

Para el día 30, su equipo debería tener un inventario por escrito, una revisión de accesos, registros de auditoría centralizados, métricas de cobertura de MFA y una lista de excepciones de alto riesgo. Incluya las claves de acceso actuales en el inventario y reporte la postura de seguridad inicial. El objetivo aún no es el cumplimiento perfecto del principio de privilegio mínimo. El objetivo es saber quién puede actuar, a qué puede acceder y dónde se encuentran las evidencias.

Días 31 al 60: Añada detección, barreras de políticas y controles de datos

El segundo mes transforma la visibilidad en protección activa y detección de amenazas. Comience con la detección a nivel de toda la organización y luego conecte los hallazgos con una persona o sistema que pueda responder. Un hallazgo sin propietario es solo un elemento más en una consola.

Habilite Amazon GuardDuty a través de un administrador delegado en la cuenta de herramientas de seguridad (Security Tooling). Active los planes de protección que coincidan con su patrimonio, incluida la cobertura pertinente para S3, EKS, RDS, Lambda, malware y actividad en tiempo de ejecución. Centralice los hallazgos de Amazon GuardDuty en AWS Security Hub, y luego dirija los eventos de alta gravedad a su SIEM, sistema de tickets o proceso de guardia a través de EventBridge.

Añada la gestión de vulnerabilidades durante esta misma fase. Habilite Amazon Inspector para EC2, ECR y Lambda según corresponda. Defina acuerdos de nivel de servicio (SLA) para la remediación, como plazos más cortos para vulnerabilidades críticas expuestas a Internet. Conecte los hallazgos de Inspector con los flujos de trabajo de ingeniería e integre las comprobaciones de contenedores o infraestructura en el pipeline de compilación.

Ahora introduzca barreras preventivas (guardrails):

• Use SCP (políticas de control de servicios) para bloquear regiones no aprobadas y evitar que las cuentas desactiven AWS CloudTrail, GuardDuty, AWS Config u otros controles requeridos.
• Aplique límites de permisos (permissions boundaries) a los roles que puedan crear o delegar accesos.
• Utilice IAM Access Analyzer para identificar permisos no utilizados, accesos externos y políticas de confianza inseguras.
• Aplique S3 Block Public Access a nivel de cuenta, con una política organizativa que impida que los equipos lo desactiven.
• Exija el cifrado en reposo para el almacenamiento, incluido el cifrado en el lado del servidor para Amazon S3, y exija TLS para las transferencias de datos sensibles.

La protección de datos necesita un inventario, no solo una declaración de intenciones. Utilice Amazon Macie para identificar información confidencial en buckets de Amazon S3 seleccionados y luego clasifique los datos según su impacto comercial y normativo. Revise semanalmente los hallazgos de acceso público hasta que el backlog esté bajo control. Para cargas de trabajo reguladas, utilice claves KMS administradas por el cliente con políticas de clave restrictivas y una separación clara entre los administradores de claves y los usuarios de datos. Valide esas decisiones frente a los estándares de cumplimiento y requisitos normativos aplicables.

Añada el monitoreo de conformidad de AWS Config al proceso de control de datos, junto con la clasificación de datos sensibles y las revisiones de cifrado. El perímetro de datos también debe formar parte de esta fase. Restrinja el acceso entre cuentas con SCP y políticas de control de recursos. Revise las políticas de los endpoints de VPC, restrinja las rutas NAT y envíe el tráfico saliente sensible a través de rutas de inspección aprobadas. Pruebe cada restricción con las integraciones de proveedores conocidos antes de aplicarla de manera generalizada.

Para el día 60, debería tener hallazgos centralizados, SLA de vulnerabilidades documentados, políticas preventivas probadas y una lista priorizada de almacenes de datos sensibles. Valide el cifrado en reposo para cargas de trabajo críticas y registre las excepciones. Mantenga las nuevas reglas en modo de auditoría o monitoreo siempre que sea posible. Paselas a modo de ejecución (enforcement) después de que los propietarios de las aplicaciones confirmen que el tráfico legítimo y las rutas de despliegue siguen funcionando.

Días 61 al 90: Refuerce la recuperación, las aplicaciones y la respuesta

El último mes se centra en los controles que reducen el impacto de un incidente. La detección puede mostrar que una cuenta está comprometida, pero la recuperación y la respuesta determinan hasta dónde se propaga el evento y con qué rapidez se reanudan las operaciones.

Proteja las aplicaciones públicas con CloudFront, Route 53 y AWS WAF. Asocie grupos de reglas administrados y reglas basadas en tasas, y comience en modo de conteo para que su equipo pueda medir los falsos positivos. Después del ajuste, aplique el bloqueo para patrones de ataque confirmados. Base las decisiones de Shield Advanced en la exposición de ingresos, los requisitos de disponibilidad y las necesidades de respuesta, en lugar de aplicar el mismo nivel de gasto a todas las aplicaciones.

Revise la seguridad de red y las rutas de red para la carga de trabajo crítica. Ubique el cómputo y las bases de datos en subredes privadas, reemplace las reglas CIDR amplias con referencias a grupos de seguridad y utilice endpoints de VPC para el acceso a servicios de AWS cuando el diseño lo admita. Confirme que el acceso administrativo utilice rutas controladas, como un enfoque de Systems Manager sin bastión, en lugar de puertos de gestión entrantes abiertos.

A continuación, independice las copias de seguridad y la recuperación de la administración de producción. Cree políticas de AWS Backup que copien los puntos de recuperación en una cuenta y región independientes. Utilice bóvedas bloqueadas (vault lock) o lógicamente aisladas (air-gapped) para los sistemas que requieran protección frente a un administrador que ya haya tomado el control de la producción. Aplique S3 Versioning y Object Lock cuando la recuperación a nivel de objeto sea importante.

Una política de copias de seguridad está incompleta hasta que alguien restaura los datos. Realice un ejercicio de restauración antes del día 90 y mida el tiempo real de recuperación, la ventana de pérdida de datos, los fallos de dependencia y los pasos manuales. Actualice el manual de procedimientos (runbook) mientras los hallazgos estén recientes.

Prepare un plan de respuesta a incidentes para casos de compromiso de credenciales, exposición de datos públicos, ransomware y uso indebido por parte de personal interno. Preconfigure roles de incidentes, una cuenta forense, permisos de recopilación de pruebas y vías de comunicación. Realice un ejercicio de simulación de mesa (tabletop) basado en el plan de respuesta a incidentes con los propietarios de seguridad, plataforma, legal, cumplimiento y negocio. ¿Pueden aislar una cuenta sin destruir pruebas? ¿Pueden revocar un rol sin detener todos los servicios críticos?

Por último, automatice los controles que hayan superado las pruebas. Almacene las políticas de Organizations, los conjuntos de permisos de IAM, las reglas de AWS Config, las configuraciones de WAF, los planes de respaldo y los estándares de registro en repositorios con control de versiones. Utilice Terraform, CloudFormation u otro sistema aprobado de infraestructura como código para aplicarlos de manera uniforme. Cada excepción debe tener un propietario, una fecha de vencimiento y una razón comercial documentada.

Al final de los 90 días, informe sobre resultados medibles:

• Cobertura de MFA para usuarios humanos y administradores.
• Porcentaje de cuentas y regiones que envían registros de forma centralizada.
• Número de claves de acceso de larga duración activas.
• Hallazgos críticos y de alta gravedad que han superado su SLA de remediación.
• Porcentaje de almacenes de datos críticos cifrados y clasificados.
• Resultados exitosos de restauración de copias de seguridad frente a los objetivos RTO y RPO establecidos.
• Excepciones de seguridad abiertas y sus fechas de vencimiento.

A partir de ahí, el despliegue debe continuar como un ciclo operativo repetible. Comience con una carga de trabajo crítica, demuestre la efectividad de los controles y expándase mediante infraestructura como código. Esto mantiene las prácticas recomendadas de seguridad de AWS vinculadas a una propiedad real, una cobertura medible y al costo operativo del entorno.

Preguntas frecuentes

¿Cuáles son los controles de seguridad de AWS más importantes para las empresas?

Comience con la gobernanza de múltiples cuentas, identidad centralizada, protección del usuario raíz, MFA, privilegio mínimo y registro de auditoría en toda la organización. Añada detección, protección de datos, gestión de vulnerabilidades, copias de seguridad resilientes y respuesta a incidentes ensayada como parte de un programa por capas.

¿Se deben habilitar los controles de seguridad de AWS en cada cuenta y región?

Sí, las brechas de seguridad en cuentas de desarrollo, regiones secundarias o rutas de datos no supervisadas pueden proporcionar a los atacantes un punto de entrada o un lugar para operar sin ser detectados. La cobertura debe coincidir con los requisitos de riesgo y cumplimiento de la organización, con excepciones documentadas que tengan propietarios y fechas de vencimiento.

¿Cómo pueden las empresas reducir los costos de seguridad en AWS sin debilitar la protección?

Separe los cargos directos de AWS de los costos de ingeniería y operativos, luego modele el uso por cuenta, región, recurso, volumen de datos y período de retención. Utilice los niveles de registro adecuados, archive los registros más antiguos, elimine los secretos inactivos, optimice el uso de KMS y revise las tarifas negociadas o los descuentos en lugar de recortar la cobertura esencial.

¿Con qué frecuencia se deben probar la recuperación de copias de seguridad y la respuesta a incidentes de AWS?

Realice simulacros de restauración de copias de seguridad al menos trimestralmente y mida los resultados reales de RTO y RPO. Lleve a cabo ejercicios teóricos de respuesta a incidentes dos veces al año, con revisiones adicionales después de cambios importantes en la arquitectura o en la organización.

¿Qué debería ofrecer una implementación de seguridad de AWS de 90 días?

Para el día 30, establezca la propiedad, el inventario, MFA, el acceso federado y los registros de auditoría centralizados. Para el día 60, agregue detección, SLA de vulnerabilidades, barreras preventivas y controles de datos; para el día 90, refuerce las aplicaciones y las redes, pruebe la recuperación, ensaye la respuesta y reporte resultados medibles.

Conclusión

Las mejores prácticas de seguridad de AWS para empresas son un programa operativo, no un proyecto de configuración de una sola vez. El programa asigna propietarios y ciclos de revisión a los controles de identidad, la evidencia de AWS CloudTrail, los hallazgos de AWS Config, los datos protegidos y la preparación para la recuperación. También mantiene al usuario raíz estrictamente controlado y conserva un plan de respuesta a incidentes que los equipos ensayan.

Su siguiente paso es reservar una revisión de seguridad de AWS gratuita centrada en una carga de trabajo crítica. Posiciónela como una evaluación estructurada alineada con el Marco de Bien Arquitectado de AWS (AWS Well-Architected Framework), que tenga en cuenta los estándares de cumplimiento aplicables. La revisión debe producir problemas clasificados como de riesgo alto y riesgo medio, en lugar de un resultado simple de aprobado o reprobado. También puede verificar si su organización califica para créditos de AWS, y luego explorar la reducción continua de costos de AWS a través de tarifas de facturación negociadas y optimización del uso.

La revisión identifica qué corregir. Los créditos y descuentos ayudan a pagar la remediación, de modo que la cobertura de seguridad no se limita a las cuentas de producción o a una sola región. Antes de la publicación, verifique los requisitos de elegibilidad, los límites de crédito, las tasas de descuento y el posicionamiento exacto de la revisión frente a los términos actuales de Spendbase y AWS.

Prueba de autoevaluación

Puede realizar nuestra autoevaluación para comprender dónde verificar la seguridad de su AWS.