in

Introducción a AWS IAM

1r XTV

Introducción a AWS IAM

Una descripción general del servicio de administración de acceso e identidad de AWS

Evan Kozliner

23 de oct de 2020·8 min de lectura

1*r XTV

Lo primero que sorprende (y frustra) a muchas personas que se trasladan a entornos basados ​​en la nube es lo complicados que pueden ser los permisos. Por lo general, después de años de aclimatarse a ser el Dios … sudo– de cualquier código que haya estado escribiendo anteriormente, se le presenta un entorno en el que casi todo está bloqueado de forma predeterminada.

Esta publicación se centrará en aliviar algunos de losaNo dude en enseñarle las partes más importantes de IAM, el servicio de administración de identidad y acceso para Amazon Web Services, además de presentar algunas de las mejores prácticas conocidas. En publicaciones futuras planeo construir a partir de esta.

Asegúrese de leer esta publicación de seguimiento, si está interesado en ver todos los elementos de IAM que analizo en esta publicación en acción.

Cuentas y recursos

El mundo de AWS comienza con cuentas y recursos dentro de esas cuentas. IAM existe principalmente para proteger los recursos de su cuenta de problemas como:

  • Actores malintencionados que intentan hacer cosas no deseadas en su cuenta de AWS (por ejemplo, robar sus datos de sus depósitos de S3).
  • Usuarios / aplicaciones dentro de su empresa que eliminan accidentalmente recursos o realizan acciones que de otro modo no deberían poder hacer.

Cuentas:

La barrera lógica entre usuarios de AWS. Muy claro:

  • Correspondencia 1–1 con 12 dígitos ID de la cuenta p.ej 123456789012.
  • Como práctica recomendada, una organización tendrá varias cuentas de AWS [1]. IAM se usa a menudo para administrar permisos entre cuentas de AWS dentro de una organización.
  • Vinculado a una dirección de correo electrónico, tarjeta de crédito; cuentas son como se le factura.

Recursos:

Los recursos son objetos persistentes en su cuenta que desea usar, como balanceadores de carga o instancias EC2.

  • Los recursos siempre tienen un ARN (nombre de recurso de Amazon) que los identifica de forma única. Por ejemplo, para un usuario de IAM, un ARN podría tener el siguiente aspecto:
arn:aws:iam::123456789012:user/Development/product_1234/*

Observe cómo la identificación de la cuenta 123456789012está presente en el ARN, así como el tipo de recurso (este recurso es un IAM user).

Identidades

La característica principal de IAM son las identidades, un tipo de recurso de AWS. Los servicios de AWS siempre exponen las API a las que puede llamar con alguna identidad; esto le dice a AWS quién es usted (autenticación) y si tiene permiso para hacer lo que está haciendo (autorización).

Hay dos formas principales de identidades en IAM: usuarios y roles.

Usuarios

La intención de un usuario en IAM es similar a la de otros sitios web como Facebook. Cuando crea una cuenta de AWS por primera vez, se le asigna un usuario raíz que tiene acceso completo a su cuenta. [2]. Luego, se le ofrece la opción, muy sugerida, de crear más usuarios y roles.

Algunas notas sobre los usuarios:

  • Los usuarios, a diferencia de los roles, tienen un nombre de usuario y una contraseña. Estos son larga vida credenciales que pueden conservarse durante un período de tiempo prolongado y utilizarse para iniciar sesión en la consola de AWS.
  • A menudo, está destinado a brindar a las personas acceso a la consola de AWS o las API. Sin embargo, como mejores prácticas, debe utilizar roles en lugar de usuarios siempre que sea posible. Esto es para limitar el riesgo de que se extravíen las credenciales de larga duración y de que un atacante acceda a su cuenta de AWS.
  • Los usuarios reciben claves de acceso. Las claves de acceso se pueden utilizar para llamar a los servicios de AWS a través de la CLI o SDK. Como un nombre de usuario / contraseña, las claves de acceso son de larga duración. Se verán más aleatorizados y se pueden usar junto con la CLI creando un archivo llamado ~/.aws/credentials con contenido similar al siguiente:
[personal]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Puede utilizar un perfil de credenciales con la CLI con el --profile opción en la CLI:

> aws s3 ls --profile personal2017-11-30 16:20:55 some-s3-bucket
2017-10-31 20:05:17 some-other-s3-bucket
...

Roles

Al igual que los usuarios, los roles son una identidad que se utiliza para acceder a las API y los recursos de AWS. Sin embargo, los roles se utilizan generalmente para otorgar temporal credenciales a una cuenta de AWS. Además, estas credenciales temporales se pueden configurar para confiar en terceros u otros servicios de AWS.

Los roles se utilizan de forma ubicua en AWS:

  • Una instancia EC2 que necesita acceder a los recursos de AWS utilizará un rol de instancia para comandar otros servicios / recursos de AWS según la lógica de su aplicación.
  • Otras cuentas de AWS que necesitan acceso a los recursos de su cuenta a veces asumir un rol en su cuenta para obtener acceso a través de la API de asumir roles de STS. Para permitirles hacer esto, puede otorgar permisos en un rol para alguna identidad en otra cuenta a través de una política de confianza (más sobre esto más adelante).
  • Una característica fundamental de AWS es su capacidad para realizar acciones en su nombre. Sin embargo, los servicios de AWS se implementan normalmente como cuentas de AWS; esto significa que, de forma predeterminada, no tienen acceso a los recursos de su cuenta. En consecuencia, a menudo requerirán que cree y les otorgue acceso a un «rol de servicio» en su cuenta para que puedan tomar medidas. en su nombre. El ajuste de escala automático en EC2, por ejemplo, necesitará permisos para activar y desactivar las instancias de EC2.
  • Los terceros, como JumpCloud, utilizarán roles para otorgar a los usuarios administrados fuera de AWS acceso a los recursos de AWS. Este proceso se conoce como federación.

Políticas

Finalmente, cuando usted (ejecutándose como una identidad) llama a una API de AWS, IAM determinará si la llamada es válida mediante la evaluación de una o más políticas. Hay dos tipos principales de políticas: políticas de identidad y políticas de recursos.

Políticas de identidad

Las políticas de identidad determinan lo que se le permite hacer a una identidad determinada (rol / usuario). Las políticas de identidad pueden ser administradas por AWS (estas políticas administradas serán creadas previamente en su cuenta) o por usted.

A continuación, se muestra un ejemplo de una política de identidad más simple:

  • Las API a las que se puede llamar se denominan Actions en IAM. Varias API pueden integrarse en una sola acción, pero, la mayoría de las veces, las acciones solo corresponden a una única API.
  • La política es una lista blanca; esto significa que, por defecto, las acciones son no permitido. Un explícito Allow se da para 2 acciones: CreateRole y CreateUser. Para obtener un desglose completo de cómo se evalúa la lógica de la política dentro de una cuenta de AWS, consulte este documento.
  • La mayoría de las llamadas a API en AWS se pueden restringir para que solo se permitan en recursos específicos, como se ha mencionado anteriormente. Puede decir que esto ha sucedido porque el Resources la sección no es una *. Esto significa que una solicitud que utilice esta identidad solo tendrá éxito en los recursos con esos ARN específicos. Por ejemplo, solo puede crear un rol con el ARN arn:aws:iam::123456789012:role/some-role utilizando esta política. Reducir el alcance a los recursos individuales es una práctica recomendada que evita muchos agujeros de seguridad. Tomemos, por ejemplo, el truco de Capital One de 2019. Capital One otorgó a su firewall permisos S3 excesivos, lo que, una vez que fue engañado a través de SSRF, permitió a los atacantes robar datos de más de 100 millones de personas.
  • Las políticas de identidad por sí solas, sin políticas de recursos, solo funcionarán dentro de la misma cuenta de AWS.
  • Se admiten comodines. La segunda declaración de esta política está relacionada con los registros de Cloudwatch y proporciona Acceso completo a los registros de Cloudwatch (cualquier API que abran y para cualquier recurso).

Cualquier identidad dada puede tener múltiples políticas adjuntas; cuando este es el caso, la identidad obtiene el OR lógico de las políticas que se le aplican, donde un explícito Deny sobrescribirá un explícito Allow .

Creo que la sintaxis es bastante sencilla, pero, para profundizar en la sintaxis de las políticas, lea los documentos.

También hay un generador de políticas de EMR que le recomiendo que utilice para crearlas más rápido aquí: https://awspolicygen.s3.amazonaws.com/policygen.html

Políticas de recursos

Cuando un recurso es actuó sobre por algún director, si ese recurso es un depósito de S3 que obtiene objetos de él o un rol de IAM que alguien está tratando de asumir, su política de recursos entrará en vigencia. Estos pueden parecer redundantes al principio, ya que puede aplicar políticas de identidad a recursos específicos, pero a menudo puede ser útil establecer una política en su recurso en lugar de las identidades que lo llaman.

Estas políticas de recursos también cumplen una función fundamental a la hora de permitir el acceso a los recursos entre cuentas. Las políticas de identidad por sí solas no pueden permitir el acceso entre cuentas, ya que el límite de permisos entre las cuentas de AWS es mucho más estricto que dentro de una sola cuenta.

Examinemos una política de recursos para un rol. Tenga en cuenta que las políticas de recursos sobre roles también se conocen como políticas de confianza, porque permiten que otros asuman el rol.

  • Directores son un nombre para la persona que llama que intenta acceder a un recurso. Esta política incluye en la lista blanca el servicio, EC2, así como otros dos roles en la cuenta. 123456789012 asumir este papel. Los principales son un superconjunto de identidades normales, que pueden incluir cosas como servicios de AWS o usuarios federados de otras aplicaciones.
  • Notará que cuando especifica un principal para alguna regla, debe especificar qué tipo de principal es. Hay varios tipos de principios, pero dos de los más comunes son Service y AWS . El primero permite que un servicio de AWS, como EC2, acceda a este rol, y el segundo permite que las identidades de una cuenta de AWS específica accedan al rol.
  • Dependiendo del servicio, las políticas de recursos varían ampliamente. Algunas políticas de recursos son más estrictas que otras o habilitan funciones diferentes. En el Servicio de administración de claves, por ejemplo, debe otorgar permisos de usuario raíz de su cuenta en la política de recursos de una clave antes de que las políticas de identidad puedan otorgar acceso a esa clave. Los depósitos de S3 tienen controles de seguridad adicionales, como listas de control de acceso. Siempre intente comprender cómo el recurso con el que está trabajando administra los permisos individualmente: no asuma que dos tipos de recursos administran los permisos de la misma manera.

En la mayoría de los recursos, las políticas de recursos son opcionales. Si no están presentes, se ignoran, como verá a continuación.

Lógica de evaluación de políticas simplificada

Para cerrar, quiero ofrecer un diagrama simple para visualizar lo que pedido las políticas de las que hablamos se evalúan en.

En aras de la simplicidad, omití la lógica de evaluación completa y solo incluí políticas comunes a continuación. Le recomiendo que lea la documentación pública para obtener una vista más detallada de la evaluación de políticas, incluidas políticas más esotéricas como políticas de sesión y límites de permisos.

1*8OAVGkgrpeNHjjHecdXcDg

IAM es uno de los principales componentes básicos de AWS. Espero que esto le haya servido para presentarle los principales temas que encontrará al usarlo.

Si desea comprender IAM un poco más en profundidad, ¡asegúrese de leer también mi publicación de seguimiento!

Si tiene más preguntas o simplemente quiere chatear, puede contactarme a través de mi, evankozliner@gmail.com o enviarme un mensaje a Gorjeo.

Notas

[1] La arquitectura de una organización de múltiples cuentas está más allá del alcance de esta publicación, pero, si está interesado, recomendaría este video a continuación y esta introducción.

[2] El usuario root es realmente distinto de los usuarios de IAM. Hay ciertas tareas que solo un usuario root puede ejecutar.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

bandera homosexual lluvia 11410

Cómo saber si una cuenta o un perfil en la aplicación Grindr es falso

Entrega de correo electrónico | Oráculo