Amazon AWS: cuentas, IAM, una VPC con VPN a la oficina y un servidor que no llega al recurso compartido

Qué vas a conseguir

Una presencia en AWS que un responsable de sistemas puede defender en una auditoría: cuentas separadas por uso, acceso con las mismas identidades de Entra ID que el resto de la empresa, ninguna puerta RDP o SSH abierta a Internet, copias que se comprueban y un aviso antes de que la factura dé un susto. Y el ticket de conectividad más habitual entre la nube y la oficina, resuelto con la AWS CLI.

Antes de empezar

• Una cuenta de AWS que será la cuenta de administración de la organización. Sin cargas de trabajo.
• Permiso de Administrador de aplicaciones (o superior) en Entra ID para crear la aplicación empresarial.
• La AWS CLI v2 y el plugin de Session Manager instalados en tu equipo.
• El rango de la oficina (aquí 192.168.10.0/24) y la IP pública del cortafuegos de la sede.
• Un rango para AWS que no se solape con nada de la empresa (aquí 10.40.0.0/16).

1. Organizaciones, cuentas y la cuenta raíz

• AWS Organizations con unidades organizativas sencillas: Seguridad (registros y auditoría), Producción y Pruebas. Una cuenta por entorno.
• Políticas de control de servicios (SCP) mínimas desde el primer día: impedir que una cuenta abandone la organización, limitar las regiones a las que usáis (por ejemplo eu-west-1 y eu-south-2) y proteger el CloudTrail de organización (en la cuenta de Seguridad) para que nadie lo apague.
• La cuenta raíz no se usa: MFA con llave física, sin claves de acceso, y la dirección de correo es una lista del equipo, no la de una persona. Con la gestión centralizada del acceso raíz de Organizations puedes eliminar las credenciales raíz de las cuentas miembro.

Nadie trabaja con usuarios IAM con claves de larga duración. Un proceso usa un rol (perfil de instancia, OIDC desde el pipeline): las claves olvidadas en un portátil o un repositorio son la causa más común de incidentes en AWS.

2. Acceso con Entra ID: IAM Identity Center

En Entra ID se añade la aplicación de la galería AWS IAM Identity Center (SAML) y en AWS se cambia el origen de identidades. El aprovisionamiento SCIM crea en AWS los usuarios y grupos que asignes a la aplicación, y los desactiva cuando alguien se va.

• Se asignan grupos, nunca personas sueltas. El alta y la baja se hacen en Entra ID, y el acceso condicional y la MFA de Entra se aplican también a AWS.
• Desde la terminal: aws configure sso una vez y aws sso login --profile prod-ops cada día. Credenciales temporales, sin claves guardadas.

3. La red: VPC privada y VPN a la oficina

• VPC 10.40.0.0/16 con subredes privadas en dos zonas de disponibilidad (10.40.1.0/24, 10.40.2.0/24) para los servidores y una pública pequeña solo si hace falta un NAT Gateway para salir a Internet.
• Puerta de enlace privada virtual (VGW) unida a la VPC, una puerta de enlace de cliente con la IP pública del cortafuegos de la sede y una conexión VPN de sitio a sitio. AWS siempre da dos túneles: configura los dos en el cortafuegos.
• Rutas estáticas en la conexión VPN (192.168.10.0/24) o BGP si el cortafuegos lo soporta, y propagación de rutas activada en las tablas de rutas de las subredes privadas.
• Los grupos de seguridad se escriben por origen: el del servidor admite el tráfico de la oficina en los puertos que necesita la aplicación, y nada desde 0.0.0.0/0.

4. Un servidor sin RDP abierto: Session Manager

La instancia EC2 vive en la subred privada, sin IP pública y sin el puerto 3389 en su grupo de seguridad. Se administra con AWS Systems Manager:

• Perfil de instancia con la política AmazonSSMManagedInstanceCore. El agente de SSM ya viene en las AMI de Windows Server y Amazon Linux.
• Si la subred no sale a Internet, puntos de conexión de VPC de interfaz para ssm, ssmmessages y ec2messages.

›aws sso login --profile prod-ops›aws ssm describe-instance-information --profile prod-ops --query "InstanceInformationList[].[InstanceId,ComputerName,PingStatus]" --output texti-0a1b2c3d4e5f60718	srv-app01.contoso.local	Online›aws ssm start-session --profile prod-ops --target i-0a1b2c3d4e5f60718 --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=13389"Starting session with SessionId: javier.ruiz-0f1e2d3c4b5a69788Port 13389 opened for sessionId javier.ruiz-0f1e2d3c4b5a69788.Waiting for connections...# ahora el cliente de Escritorio remoto se conecta a localhost:13389

Sin --document-name, la sesión abre PowerShell o bash en el servidor. Todo queda registrado en CloudTrail.

5. Copias y coste

AWS Backup: un plan con copia diaria (retención 35 días) y mensual (12 meses), una selección de recursos por etiqueta (backup=diario) y copia a un almacén de otra cuenta. Vault Lock en modo cumplimiento impide borrar las copias antes de tiempo, también a un administrador comprometido.

Para el coste, dos piezas (y Cost Anomaly Detection para los picos a mitad de mes):

• Etiquetas obligatorias (proyecto, entorno, responsable) y activadas como etiquetas de asignación de costes en la consola de Facturación; si no se activan, no aparecen en Cost Explorer.
• AWS Budgets con avisos sobre el gasto real y el previsto.

6. El ticket: "el servidor no llega al recurso compartido de la oficina"

srv-app01 necesita leer \\srv-fs01\intercambio en la sede y falla. Se recorre el camino en orden: túnel, rutas, grupo de seguridad, y el otro extremo.

›aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0c1d2e3f4a5b6c7d8 --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,LastStatusChange]" --output text198.51.100.21	UP	2026-10-27T22:14:05+00:00198.51.100.22	DOWN	2026-10-27T22:13:58+00:00›aws ec2 describe-route-tables --filters Name=association.subnet-id,Values=subnet-0a9b8c7d6e5f40312 --query "RouteTables[0].Routes[].[DestinationCidrBlock,GatewayId,NatGatewayId,State]" --output text10.40.0.0/16	local	None	active0.0.0.0/0	None	nat-0f9e8d7c6b5a40321	active›aws ec2 describe-route-tables --filters Name=association.subnet-id,Values=subnet-0a9b8c7d6e5f40312 --query "RouteTables[0].[RouteTableId,PropagatingVgws]" --output textrtb-0d4c3b2a1f0e9d8c7# no hay ruta a 192.168.10.0/24 y la tabla no propaga desde la VGW›aws ec2 enable-vgw-route-propagation --route-table-id rtb-0d4c3b2a1f0e9d8c7 --gateway-id vgw-0b1a2c3d4e5f60789

• Túneles: con uno arriba hay servicio; el otro caído se corrige en el cortafuegos, pero no es la causa.
• Rutas: aquí estaba el problema. La tabla se recreó la semana anterior y nadie volvió a activar la propagación, así que el tráfico hacia la oficina salía por el NAT. Tras activarla aparece 192.168.10.0/24 con destino la VGW.
• Grupo de seguridad: la salida por defecto lo permite todo; si se restringió, necesita TCP 445 hacia 192.168.10.0/24.
• El otro extremo: el cortafuegos de la sede tiene que conocer 10.40.0.0/16 por el túnel y permitir SMB desde ahí. Desde una sesión de SSM, Test-NetConnection srv-fs01 -Port 445 lo confirma de punta a punta.

7. Lo que revisas cada mes

• Hallazgos de Security Hub e IAM Access Analyzer: accesos externos, roles sin uso, claves de acceso que no deberían existir.
• Trabajos de AWS Backup fallidos y una restauración de prueba al trimestre.
• Estado de los dos túneles VPN y el informe de Cost Explorer agrupado por la etiqueta proyecto, con los recursos sin etiquetar.

Siguientes pasos

• La guía de Terraform para que cuentas, VPC y servidores salgan de un repositorio revisado.
• La guía de Backup y DR/BCP para encajar AWS Backup en el plan de continuidad de la empresa.
• La guía de Fortinet FortiGate para el lado de la oficina de la VPN.
• La guía de Kubernetes cuando las aplicaciones pasen de un servidor a contenedores (EKS).

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.