Conceptos básicos

IAM: gestión de identidades y accesos

Iniciar sesión en la consola de AWS

Nada más acceder a la consola, IAM se convierte en su punto de referencia en materia de seguridad. En primer lugar, se definen las entidades: los usuarios representan a las personas o aplicaciones que necesitan acceso directo, mientras que los roles corresponden a identidades temporales que se "asumen" para ejecutar una tarea concreta, sin almacenar claves a largo plazo. En lugar de asignar derechos de administrador de forma arbitraria, se crean políticas JSON que especifican exactamente las acciones autorizadas, por ejemplo, explorar un bucket de S3 o iniciar una instancia de EC2, y se asocian estas políticas a los grupos de usuarios o a los roles adecuados.

Para reforzar la protección, se da prioridad sistemáticamente a las claves de acceso temporales emitidas por AWS STS, en lugar de las claves IAM de larga duración: estos tokens solo son válidos durante unos minutos o unas horas. También se impondrá la autenticación multifactorial (MFA) en las cuentas sensibles, en particular la cuenta root y todos los roles de administración...

AWS Organizations y SCP: organizar varias cuentas de forma eficaz

A medida que aumenta su uso de AWS, concentrar todos sus proyectos en una sola cuenta acaba resultando inmanejable. Entre los entornos de desarrollo, pruebas y producción y los servicios transversales como el registro de eventos o la seguridad, resulta imposible separar claramente quién gasta qué y quién accede a qué recursos. Por eso, AWS pone a su disposición AWS Organizations, un servicio que permite agrupar varias cuentas bajo una misma entidad, cada una estructurada en unidades organizativas (OU) y protegida por políticas de control de servicios (SCP). El siguiente esquema ilustra la configuración típica: una cuenta de gestión en la parte superior, seguida de las OU "Development", "Test" y "Production", cada una de las cuales alberga varias cuentas secundarias, y cada OU está sujeta a una SCP específica.

Infraestructura como código: ¿por qué automatizar en lugar de hacer clic?

En los inicios de AWS, crear un servidor web apenas requería más que hacer clic en "Launch Instance" en la consola. Esa simplicidad, aparentemente liberadora, esconde una trampa: en cuanto se repite la operación en tres regiones, cinco entornos y una decena de cuentas, la consola se convierte en un laberinto. Se nos olvida una etiqueta “Owner” aquí, abrimos sin querer el puerto 22 a todo el mundo allá y nos encontramos sin una forma sencilla de volver a hacer exactamente lo mismo que acabamos de implementar manualmente. Para romper este ciclo surgió la Infrastructure as Code o IaC. La idea consiste en tomar los "clics" que realizamos en la interfaz gráfica, transformarlos en archivos de texto que describan el estado deseado de la infraestructura y, a continuación, encargar a un motor de orquestación que materialice dicho estado.

La definición de IaC se resume en tres puntos: en primer lugar, cada recurso (VPC, bucket de S3, rol de IAM, clúster de EKS) existe en forma de una declaración legible, versionable y comparable entre versiones (basta con un simple diff para visualizar los cambios), al igual que cualquier archivo fuente. En segundo lugar, todo despliegue se realiza según el modelo "plan / apply": se compara el estado deseado (descrito en el código) con el estado real, y la herramienta genera la lista de cambios necesarios antes de aplicarlos. Por último, cualquier modificación sigue el mismo ciclo que el código de la aplicación: commit...

Seguridad y cumplimiento normativo: sentar unas bases sólidas

Una vez descrita su infraestructura en código y distribuidos sus recursos en varias cuentas bien gestionadas, queda por asegurar el conjunto: esa es la misión de la seguridad y el cumplimiento normativo. En AWS, estos dos aspectos se complementan mutuamente: el cumplimiento normativo exige un nivel de seguridad cuantificable; la seguridad proporciona las pruebas necesarias para sus auditorías. El objetivo no es solo cumplir con los requisitos de SOC 2 o ISO 27001, sino prevenir un incidente antes de que se convierta en una crisis de confianza.