Amazon Web Services - IAM 🔒👤: La perspectiva desde Proyectos personales ☁️📊
- Brayan Neciosup
- 25 sept
- 4 Min. de lectura
Cuando hablamos de AWS siempre nos preguntamos: ¿Donde puedo empezar?, ¿Como es su jerarquía inicial para proyectos personales?. La respuesta es sencilla, siempre empezaremos en el servicio de primera línea Identity and Access Management (IAM).
💡La Cuenta Root: La Llave Maestra
Al registrarte en AWS, creas una cuenta con tu correo electrónico y un método de pago (tarjeta de crédito o débito). Esta cuenta es la Root Account, y representa la llave maestra de toda tu infraestructura.
Uso recomendado:
Configurar el método de facturación y pagos.
Habilitar o deshabilitar servicios globales.
Atender situaciones de emergencia.
Buenas prácticas:
Activa MFA (Multi-Factor Authentication).
Usa una contraseña robusta.
No la utilices para el trabajo diario ni para operar servicios.
👤 Sub-Superusuario IAM
Para proyectos personales siempre debemos crear un "sub-superusuario" en el servicio de IAM, esto debido a las buenas prácticas que debemos seguir como Data Engineers en este proveedor de nube, donde los pasos debes ser:
Crea un usuario IAM con la política AdministratorAccess.
Este será tu usuario de trabajo diario.
Accede a la consola con:
https://<account-id>.signin.aws.amazon.com/console
Account ID + IAM username + password.
Activa también MFA.
👥 Grupos de Usuarios IAM
Dentro de IAM encontramos varios apartados clave que, como Data Engineers, debemos dominar. Entre los más importantes están Grupos y Usuarios.
Grupos IAM: funcionan como contenedores que agrupan usuarios con permisos similares, facilitando la administración y el mantenimiento de una jerarquía clara en los proyectos.
Usuarios IAM: representan las credenciales individuales con las que cada persona accede a la consola de AWS.
Si en algún momento creamos usuarios de forma individual, siempre podemos incorporarlos posteriormente a un grupo ya existente para mantener el orden. La recomendación es organizar los usuarios en grupos según su función, por ejemplo:
Developers → PowerUserAccess
Testers → ReadOnlyAccess
Admins → AdministratorAccess
Cada grupo hereda permisos, lo que permite simular un equipo real dentro de un proyecto personal.
👥 Usuarios IAM
Al crear usuarios dentro de IAM, el objetivo es otorgar a cada persona o aplicación los permisos necesarios para cumplir una función específica. El proceso recomendado es el siguiente:
Definir un nombre de usuarioAsigna un nombre único que identifique claramente a la persona o aplicación.
Elegir el tipo de identidad
Identity Center: utilizado principalmente en entornos organizacionales.
Usuario de IAM: opción estándar para cuentas personales. Permite generar una contraseña automática o personalizada para el acceso a la consola de AWS.
Asignar permisosExisten tres métodos para conceder permisos:
Agregar al grupo: incorpora el nuevo usuario a un grupo existente para heredar las políticas de ese grupo.
Copiar permisos: replica los permisos de otro usuario ya configurado con un perfil similar.
Adjuntar políticas directamente: aplica políticas predefinidas de AWS o crea una política personalizada. En estas políticas se especifica el servicio, el tipo de acción (lectura, creación, modificación o eliminación) y las condiciones de acceso.
🎭 Roles IAM
Los roles IAM definen permisos temporales que permiten a uno o varios usuarios o incluso a servicios realizar acciones específicas sobre distintos recursos de AWS. A diferencia de los usuarios IAM, los roles no tienen credenciales permanentes, sino que se asumen dinámicamente según las necesidades.
Al crear un rol, es fundamental especificar el tipo de entidad que lo asumirá, eligiendo entre:
Servicio de AWS (por ejemplo, EC2, Lambda, Glue).
Otra cuenta de AWS (para escenarios cross-account).
Identidad web (OpenID Connect).
Federación SAML 2.0.
Política de confianza personalizada (para requisitos avanzados).
En la práctica, la mayoría de los roles se crean para asignarlos a un servicio de AWS o a una cuenta de AWS, permitiendo que esos servicios accedan a otros recursos de manera segura y controlada.
💡 Casos de uso comunes:
Un servicio de AWS, como Glue o Lambda, que necesita permisos para leer o escribir en Amazon S3.
Conceder accesos federados a usuarios externos o identidades provenientes de otros sistemas de autenticación.
📏 Políticas IAM
Las políticas IAM permiten definir reglas precisas de acceso, modificación y visualización sobre los distintos servicios de AWS.Estas políticas son el mecanismo central para controlar qué acciones puede realizar un usuario, grupo o rol y sobre qué recursos.
Pueden ser prediseñadas por AWS (políticas administradas) o personalizadas, donde especificas los servicios, las acciones permitidas (leer, crear, modificar, eliminar) y las condiciones bajo las cuales se aplican.
Se pueden asignar a usuarios individuales, grupos de usuarios o roles, facilitando una gestión de permisos flexible y escalable.
En resumen, las políticas IAM actúan como el contrato de seguridad que determina exactamente quién puede hacer qué dentro de tu entorno AWS.
🏁 Flujo Recomendado
Proteger la cuenta Root (MFA).
Crear un usuario IAM administrador o sub-superusuario (admin-personal).
Crear grupos IAM por rol en la organizacion (es opcional, pero una practica recomendada).
Crear usuarios dentro de esos grupos (es opcional, podemos crear usuarios sin asignar a un grupo de usuarios).
Usar roles para accesos temporales entre servicios o cuentas de aws.
Las políticas personalizables serán para casos específicos, en caso aws no brinde políticas que requeramos
🌳 Jerarquía AWS - Proyectos Personales
📌 Conclusión
Root: exclusivamente para gobernanza y billing.
Usuarios y Grupos: para personas o aplicaciones con acceso permanente.
Roles: para servicios o accesos temporales entre cuentas o recursos.
Políticas: para definir reglas personalizadas de acceso, modificación o visualización sobre servicios de AWS.
Esta estructura no solo fortalece la seguridad, sino que también te permite simular una organización empresarial dentro de tu propia cuenta personal de AWS, aplicando las mejores prácticas desde el primer día.
Asimismo, en el siguiente post hablaré sobre el modo organizacional de AWS, donde entra en juego AWS Organizations para administrar múltiples cuentas, unidades organizativas (OUs) y Service Control Policies (SCPs) que extienden la gobernanza a nivel empresarial.
Comentarios