Wilson Montenegro
Enrique Alexis Lopez Araujo
JESUS SONCO CABEZAS
Juan Manuel Hincapié
Diego Fernando Ramos Aguirre
Angel Alberto Briceño Obregón
Kevin Parra Lopez
Mario Alexander Vargas Celis
Juan Ronald Montiel Sandoval
Enrique Alexis Lopez Araujo
María Elizabeth Puentes Puente
Wilbert J Galano Batista
Juan Ronald Montiel Sandoval
Enrique Alexis Lopez Araujo
Erick Bonilla
Sebastian Baez Ramos
Sergio Brandon De Lucio Chavero
Ruben Galindo
Jhon Freddy Tavera Blandon
Julio César Velásquez Mejía
Mauro Nava
Jeisson Espinosa
Yerson Rojas
Alejandro Castaño Vargas
Anotado todo lo que creamos para después borrarlo 😅
Para el tema de grupo, roles y politicas, no necesitas borrar los recursos ya que estos no se cobran dentro de IAM 💚
Creo que nos enseña las malas practicas que no debemos hacer en IAM😅 Al menos eso entendí en el ++minuto 5:35++
Creación de política de seguridad desde AWS.
La recomendación es no crear políticas basadas en los usuarios sino por el contrario asignar políticas a grupos y agregar los usuarios a los grupos, por temas de facilidad en el control de los servicios cuando la cantidad de usuarios es significativa
Podemos adjuntar un usuario a varios grupos
Gracias por el aporte.
Estas son algunas de las prácticas más recomendadas para la administración de cuentas en IAM:
Principio de mínimo privilegio: Otorga solo los permisos necesarios para realizar una tarea específica. No des permisos administrativos completos a menos que sea absolutamente necesario.
Usa grupos o roles de IAM: En lugar de asignar permisos a usuarios individuales, asigna permisos a grupos o roles de IAM y luego agrega usuarios a esos grupos o roles.
No uses las credenciales de la cuenta raíz para el trabajo del día a día: Las credenciales de la cuenta raíz tienen acceso completo a todos los recursos en la cuenta y no se pueden revocar ni limitar. Es mejor usarlas lo menos posible y, en su lugar, usar usuarios de IAM.
Habilita la autenticación de dos factores (MFA): Esto agrega una capa adicional de seguridad a tus cuentas de usuario.
Rota regularmente las claves de seguridad: Al igual que las contraseñas, las claves de seguridad (como las claves de acceso de AWS) deben cambiarse regularmente.
Usa políticas de contraseñas para asegurar que los usuarios sigan las prácticas recomendadas de contraseñas: Esto incluye el uso de contraseñas complejas, el cambio de contraseñas regularmente y el no reutilizar contraseñas antiguas.
Revisa regularmente los permisos de IAM: Verifica regularmente quién tiene acceso a qué para asegurarte de que solo las personas correctas tienen acceso a los recursos apropiados.
Usa roles de IAM para aplicaciones y servicios que necesiten acceso a AWS: Esto incluye servicios de AWS como EC2 y Lambda, así como aplicaciones en tus servidores que necesiten acceso a recursos de AWS.
Registra y monitorea la actividad en tu cuenta: Utiliza AWS CloudTrail para registrar, auditar y monitorear la actividad en tu cuenta.
Aunque la mayoría de estos ejercicios lo vimos en cursos pasados, no sé, este como que no me terminar de llenar, los otros cursos dejaron la vara muy alta
Aquí tienes algunas prácticas recomendadas y ejercicios para trabajar con políticas IAM en AWS.
🏋️ Prácticas con Políticas IAM en AWS
📌 1. Crear una Política Personalizada en IAM
Objetivo: Crear una política que permita a un usuario ver pero no modificar los recursos en Amazon S3.
Pasos:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetObject" ], "Resource": [ "arn:aws:s3:::mi-bucket", "arn:aws:s3:::mi-bucket/*" ] } ] }
"S3ReadOnlyPolicy".📌 2. Crear una Política de Acceso Restringido a una Región
Objetivo: Permitir que un usuario solo cree instancias EC2 en la región us-east-1.
Pasos:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-1" } } } ] }
📌 3. Crear una Política de Acceso Basado en Horarios
Objetivo: Permitir que un usuario acceda a la consola de AWS solo en horarios laborales (Ejemplo: de 8 AM a 6 PM UTC).
Pasos:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "NumericGreaterThan": { "aws:CurrentTime": "18:00:00" }, "NumericLessThan": { "aws:CurrentTime": "08:00:00" } } } ] }
📌 4. Crear una Política para Bloquear la Eliminación de Recursos Críticos
Objetivo: Evitar que los usuarios eliminen instancias EC2, pero permitirles iniciarlas y detenerlas.
Pasos:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "ec2:TerminateInstances" ], "Resource": "*" } ] }
✅ Buenas Prácticas al Trabajar con IAM
✔ Aplicar el principio de menor privilegio: Asignar solo los permisos necesarios. ✔ Usar roles en lugar de usuarios con claves de acceso permanentes. ✔ Habilitar MFA (Autenticación Multifactor) para usuarios críticos. ✔ Revisar permisos regularmente con AWS IAM Access Analyzer. ✔ Monitorear con AWS CloudTrail para detectar accesos sospechosos.
🚀 ¡Ahora puedes poner en práctica el manejo de políticas IAM en AWS! 🔐
Dónde puedo encontrar las Best Practicies para IAM?
Hola @juan mira te comparto este documento donde encontraras mas sobre best practices in IAM
¿Como funciona la colisión de permisos si un usuario pertenece a mas de un grupo?
Dónde están las Best Practicies para IAM?
Hola @juan mira te comparto este documento donde encontraras mas sobre best practices in IAM
Es pregunta. vi que al usuario alexis practica se adjunto a 2 grupos (developer, y administradores) pero tomó los permisos de developer que solo tenia de reaadOnly, si entendi bien, el usuario va a tomar la politica de menos permisos aunque tenga permisos de semiDios en otro grupo???
Hola, Erick. Lo que pasó fue que el profesor eliminó al usuario "alexispractica" del grupo "administrator", por ende pierde los permisos de dicho grupo. Posteriormente, crea un grupo de "developers" con la política de "IAMReadOnlyAccess" y agrega al usuario "alexispractica" al grupo "developers". En el minuto 8:02 puedes observar en la ventana derecha (donde está logueado el usuario "alexispractica") que el grupo "administrators" no tiene ningún usuario y que el grupo "developers" tiene un usuario.
Al final el usuario solo estaba en el grupo de developers
Cuando un usuario en AWS se agrega a múltiples grupos, hereda las políticas de acceso de todos esos grupos. Si un grupo tiene una política que permite cierta acción y otro grupo tiene una política que la deniega, se aplicará la regla de "deny takes precedence" (la negación tiene prioridad). Es decir, si un grupo otorga acceso y otro grupo lo niega, el acceso será denegado. Esto es esencial para la gestión de permisos y seguridad en la infraestructura en la nube de AWS.
Con las actualizaciones de AWS y la clase es algo confuso crear los usuarios y los grupos, con sus respectivos permisos y políticas. Pero se puede
Hubiera sido genial que en las prácticas se hablen de los precios estimados que cada servicio puede tener.
Seria util tenerlo. Pero AWS ofrece una herramienta llamada Cost Explorer
Información resumida de esta clase #EstudiantesDePlatzi
No es buena idea crear políticas para usuarios, lo mejor es crear grupos y a estos grupos aplicarles las políticas
Las políticas puedo crearlas de manera muy visual dentro de AWS
Depende de la jeraquia de los usuarios, es bueno hacer politicas de grupo, si el permiso es muy especifico seria bueno utilizar politicas :)
Este aporte lo dió el profe en un comentario, pero siento que le falta visibilidad.
Buenas prácticas de AWS Identity and Access Management (IAM):