#100DíasdeAWS | Día 4 | Identity And Access Management

Aquí estamos en el Día 4 del blog diario #100daysofAWS!

Esperamos que algunos de ustedes sigan aquí!

Después de las tres publicaciones anteriores, hemos decidido centrarnos en un servicio que sin duda será uno de los más importantes de toda esta lista de 100 servicios clave de AWS. Esto se debe a lo vital que es tener una red troncal de seguridad sólida cuando se utiliza la nube de AWS, y este servicio se llama IAM.

IAM es un servicio global y gratuito de AWS que otorga permisos a los usuarios para permitir un alto nivel de control de quién accede tanto dentro como fuera de su equipo.

Cuando inicia una cuenta de AWS por primera vez, solo puede iniciar sesión y explorar los servicios como usuario raíz, que tiene permiso total para hacer lo que quiera. IAM le brinda la capacidad de bloquear la cuenta de usuario raíz (preferiblemente también con autenticación de múltiples factores) y usar una función de administrador en su lugar. ¡Esto reduce enormemente la probabilidad de que un actor malicioso comprometa la cuenta raíz y cause estragos en ella, al minar bitcoins a su costa!

IAM es la mejor manera de manejar y administrar el acceso a los servicios de AWS que requiere de una manera segura y práctica. Hay muchas maneras diferentes de hacer esto, pero hoy vamos a tocar las características clave de IAM y resaltar la importancia de algo llamado el principio de privilegio mínimo cuando se usa AWS.

El principio de privilegio mínimo es el siguiente: no desea otorgar a ninguno de los usuarios de su cuenta de AWS más libertad de la que necesitan para desempeñar su función de manera efectiva.

Ni mas ni menos

Esta práctica garantiza un alto nivel de seguridad cuando se trata de mitigar el riesgo potencial con los usuarios de su cuenta y, cuando se vincula con algo como CloudTrail, le brinda información detallada sobre quién puede y está haciendo qué en su cuenta.

IAM hace esto al permitirle asignar permisos en forma de políticas a un Rol, Usuario o Grupo para dictar lo que pueden y no pueden hacer en su cuenta.

Primero, analicemos los diferentes niveles a los que puede aplicar políticas dentro de IAM, conocidos como Identidades.

Roles: Los roles de IAM permiten el acceso a usuarios o incluso servicios que normalmente no tienen acceso. Esta es una estrategia de acceso a corto plazo que se utilizará de forma temporal para realizar llamadas a la API, por ejemplo, dando acceso a EC2 a un depósito en S3.
Usuarios: Los usuarios de IAM son personas que realizan ciertos trabajos dentro de su organización, por ejemplo, administrador de base de datos o asistente de nómina. Usted crea un usuario y le asigna credenciales de seguridad individuales para brindarle acceso a los servicios de AWS a más largo plazo. Un buen ejemplo de esto sería un administrador de base de datos, que podría tener acceso completo a DynamoDB, pero no podría acceder a ningún otro servicio, por ejemplo, EC2 para acceder a un servidor.
Grupos: Esto se explica por sí mismo y los grupos contienen una colección de usuarios con un grupo compartido de permisos. Esto podría ser un grupo de personal de recursos humanos o un grupo de desarrolladores de back-end en una empresa, por ejemplo.
Usuarios Federados: Son identikits externos a su directorio corporativo de AWS a quienes les otorga credenciales de seguridad temporales.

Tener estas identidades diferentes para las que puede aplicar roles le brinda un alto grado de control granular sobre quién puede acceder a qué y por cuánto tiempo, lo que garantiza la seguridad.

Hablemos ahora de las políticas antes de pasar a algunas de las mejores prácticas de IAM.

Permiso y Políticas

IAM le permite describir explícitamente lo que una entidad principal puede hacer en una cuenta. Una entidad principal puede ser una persona o un servicio que se haya autenticado mediante un usuario, una función o un usuario federado de IAM.

Puede administrar el acceso en su cuenta eligiendo la política administrada por AWS o las políticas administradas por el cliente (en línea) y asociándolas a una identidad o un servicio.

Una política en IAM es un objeto que básicamente define el permiso en un formato definido. Cuando se realiza una llamada a la API, las políticas deciden si se permite o no la solicitud.

Las políticas están escritas en JSON, por ejemplo, esta política permite que una instancia EC2 adjunte o desconecte volúmenes de EBS:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AttachVolume",
                "ec2:DetachVolume"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*",
                "arn:aws:ec2:*:*:instance/*"
            ],
            "Condition": {
                "ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
            }
        }
    ]
}

¡Vamos a romper esta política de aspecto aterrador!

Version: Esta es la versión del idioma de la política. Obviamente, esto no se actualiza con tanta frecuencia y realmente no vale la pena preocuparse demasiado.
Statement: Es el contenedor del elemento de política y puede tener varias declaraciones por política.
SID (Identificador de estado de cuenta): Esta es una forma de etiquetar opcionalmente sus estados de cuenta.
Effect: ¿Permitirá o denegará la política?.
Principal: Como mencionamos anteriormente, una entidad principal puede ser una persona o un servicio que se haya autenticado mediante un usuario, rol o usuario federado de IAM.
Action: Enumera un conjunto de acciones que la política deniega o permite.
Resource: Es simplemente el recurso al que se aplica.
Condition (opcional): Son circunstancias en las que la política otorga permiso.

¡No se preocupe si no puede escribir JSON! AWS tiene su propio Generador de políticas y hay cientos (posiblemente miles) de políticas administradas por AWS que puede comenzar a usar de inmediato.

Finalmente, algunas mejores prácticas al usar IAM, tomadas de la documentación de AWS, con enlaces a alguna literatura sobre cada punto importante:

Si bien no fue una inmersión profunda, esperamos que le brinde un buen punto de partida cuando se trata de aprender un poco sobre la administración de acceso e identidad en AWS.

Avísame si tienes alguna pregunta, que tengas un gran día y ¡sigue construyendo!

Post Original Jack Lavelle

#100DíasdeAWS | Día 4 | Identity And Access Management

Comments

100 Días de AWS

#100DíasdeAWS | Día 3 | DynamoDB

More from this blog

#244: Inteligencia Artificial Generativa sobre Amazon EKS

#243: Certificaciones de IA/ML de AWS

#242: Opciones costo-eficientes para aplicaciones de IA Generativa

#241: IA Generativa - Comienza tu aprendizaje

#240: Hablemos de AWS Step Functions

Ni mas ni menos

Command Palette

Comments

100 Días de AWS

#100DíasdeAWS | Día 3 | DynamoDB

More from this blog

Ni mas ni menos