Cómo acceder a su cuenta de AWS

(Nicolo Marchesi) (3 de diciembre de 2020)

Cómo acceder a su cuenta de AWS

Hola. Acaba de crear su primera cuenta de AWS y no puede esperar para sumergirse en todos los emocionantes servicios y tecnologías que AWS tiene para ofrecerle para comenzar a crear la próxima gran novedad. Pero, espere un segundo … ¿va a iniciar sesión con las credenciales de su cuenta raíz? ¿O es mejor generar un nuevo usuario? ¿O tal vez usar un rol?

Reduzca la velocidad un minuto y, al final de la publicación del blog, le prometo que podrá elegir la mejor manera para acceder a su cuenta de AWS de forma segura .

Tenga cuidado, sin embargo, consideraremos el acceso a una sola cuenta de AWS, ya que cubriremos las estrategias de múltiples cuentas la próxima vez . Tenemos que caminar antes de que podamos ejecutar, ¿verdad?

Cuentas y recursos

Cada increíble viaje con AWS comienza con cuentas y recursos, y una cuenta es como una caja vacía.

Las cosas que puede poner dentro de su cuenta pueden ser cualquier cosa relacionada con los servicios de AWS, por ejemplo, redes, máquinas virtuales, contenedores, etc.

Pero la parte más crucial es que de forma predeterminada, ninguna cuenta comparte ningún recurso, por lo que nada puede entrar o salir entre dos cuentas de AWS diferentes. Y esto es excelente para dividir sus cargas de trabajo y asegurarse de que solo las personas adecuadas accedan a todo.

IAM – Identidad & Administración de acceso

Dentro de cada cuenta, IAM está ahí para proteger los recursos dentro de su cuenta al administrar qué entidades pueden realizar algunas acciones en esos recursos:

  • QUIÉN – qué identidades
  • QUÉ – pueden realizar algunas acciones
  • DONDE: en algunos recursos
  • CÓMO – y cumplí algunas condiciones

Las defino como 4W , y por ahora, necesitaremos enfocarnos solo en los primeros 3.

Al principio, el usuario root

Cuando inició sesión después de crear la cuenta de AWS, usó esa cuenta usuario raíz .

Eso es diferente de los otros que puede crear porque:

  • Creado en el registro de la cuenta
  • Usted puede iniciar sesión con la dirección de correo electrónico y la contraseña que utilizó para crear la cuenta
  • Puede acceder a la información de facturación
  • Tiene acceso sin restricciones a todos los recursos de su cuenta

Este usuario es muy importante y debes protegerlo de la mejor manera posible. Es un superadministrador de esteroides, ya que puede ver la información de facturación además de poder hacer todo con todos sus recursos.

Entonces, lo primero que debe hacer debe ser:

  • Habilite la autenticación multifactor (MFA) y guarde el código QR en un lugar seguro
  • Elimine todas las claves de acceso relacionadas con este usuario para deshabilitar el acceso mediante programación (¡no necesitaría esto de todos modos!)

Y lo siguiente debería ser decidir cómo accederá a esta cuenta a partir de ahora.

Desde dentro de AWS

Centrémonos por ahora en lo que AWS nos brinda sin depender de terceros. Esto es especialmente útil si nos centramos en esta cuenta única porque necesitamos dominar los tres componentes básicos de IAM: usuario, grupos y roles.

Usuarios

¿Recuerdas al usuario root? Los usuarios de IAM son el mismo tipo de entidad pero diferente del usuario raíz. No tienen permisos de facturación predeterminados ni acceso de administrador (a menos que usted les dé … lo cual no debería).

Con un usuario, podemos crear una entidad que pueda iniciar sesión en la consola web de AWS o con acceso programático a través de un conjunto de credenciales (una clave de acceso y una clave de acceso secreta) que son fijas y no cambiarán con el tiempo. Junto con claves SSH / HTTPS para AWS CodeCommit o Credenciales para espacios de claves de Amazon (para Apache Cassandra)

  • Credenciales de inicio de sesión para la consola web
  • Credenciales de acceso y clave secreta para acceso programático para API, CLI y SDK
  • Claves SSH / HTTPS para AWS CodeCommit
  • Credenciales para Amazon Keyspaces (para Apache Cassandra)

Acceso granular

Es completamente posible con un usuario de IAM habilitar una o más claves de acceso dependiendo de cómo desee que se comporte ese usuario.Por ejemplo:

  • Un analista de datos que necesita verificar solo los análisis en la consola web pero sin necesidad de acceso mediante programación
  • Un DevOps sin servidor que necesita realizar acciones en el consola y utilizar la CLI para proporcionar algunos recursos necesitará ambos accesos
  • Un desarrollador que trabaje en un único repositorio y no necesite interactuar con los recursos de AWS tendrá claves SSH / HTTPS para AWS CodeCommit.

Tenga en cuenta que comparte credenciales de usuario de IAM es un gran no-no, ya que es el primer paso para perder las credenciales y la gobernanza y exponerse a las amenazas de seguridad.

No lo hace No quiere que su cuenta de producción se borre por completo en favor de un conjunto completo de mineros de bitcoin, ¿verdad?

Hacer cumplir la seguridad

Otra característica interesante de los usuarios de AWS IAM es poder hacer cumplir la contraseña complejidad (que por defecto es bastante alta con una longitud entre 8 y 128 caracteres cters, un mínimo de 3 caracteres especiales y que no sean idénticos a su nombre de cuenta de AWS o dirección de correo electrónico) y el tiempo de vencimiento de la contraseña para garantizar que después de cierto tiempo sus usuarios cambiarán la contraseña.

En la parte superior de eso, puede habilitar MFA con varios dispositivos:

  • Un dispositivo MFA virtual con una aplicación de autenticación instalada en su dispositivo móvil o computadora
  • Una clave de seguridad U2F como una YubiKey o cualquier otro dispositivo U2F compatible
  • Otro dispositivo de hardware MFA como el token de Gemalto

En general, existe un enfoque granular, ya que puede tener medios específicos para cada usuario de IAM .

Cuándo usar

Si tiene muy pocos usuarios (entre 1 a 5) con permisos precisos vinculados a cada uno, los usuarios de IAM pueden ahorrar algo de tiempo en la configuración inicial y el acceso a la consola. Tenga cuidado con las credenciales estáticas porque son problemas de seguridad importantes, por lo que debe manejar con extremo cuidado. O utilice la AWS CLI get-session-token para generar credenciales temporales a partir de las estáticas.

Grupos

No es una entidad en sí, pero los grupos de IAM están ahí para agrupar a los usuarios de IAM y otorgue el mismo conjunto de permisos a un grupo de usuarios. Esto suaviza un poco los aspectos ásperos de los usuarios de IAM, pero en general se aplican las mismas cosas que hemos visto para los usuarios de IAM.

Algo bueno a tener en cuenta es que un usuario de IAM aún puede tener políticas personales mientras esté asociado con un grupo, con el permiso resultante es igual a la fusión del grupo y los personales.

Esta debería ser más la excepción que el flujo de trabajo típico. Con demasiados permisos individuales, creamos muchas políticas que no se pueden mantener y perdemos la descripción general de los permisos en la cuenta.

Cuándo usar

Si tiene pocos usuarios (entre 5 y 15), los grupos de IAM pueden evitar algunas de las molestias de administrar y configurar cada usuario de IAM. Pero se aplica la misma consideración que a los usuarios de IAM, así que, si es posible, evítelos a menos que solo esté trabajando en una sola cuenta.

Roles

Y aquí estamos con los roles de AWS. Los roles de IAM pueden tener permisos (al igual que los usuarios) e iniciar sesión en la consola (nuevamente, como usuarios…). En lugar de estar asociado exclusivamente con una persona, cualquiera que lo necesite puede asumir un rol.

Entonces una persona usa la gorra del rol que quiere asumir, y

El logo del rol de IAM acaba de ganar mucho más sentido, ¿verdad?

Credenciales temporales

Otra diferencia clave con los usuarios de IAM es que los roles de IAM no tienen credenciales estáticas. Cuando alguien asume los roles, se genera y proporciona un conjunto de credenciales temporales . Es posible personalizar cuánto tiempo durarán esas credenciales y restringir aún más el acceso si es necesario.

El tiempo se puede configurar desde 900 segundos (15 minutos) hasta 12 horas, pero en mi opinión, establecer una hora- el vencimiento prolongado es la mejor compensación entre seguridad y rendimiento.

Monitoreo de CloudTrail

Mencionaré esto porque algunas personas no usan roles porque piensan que no pueden auditar lo que los roles pueden hacer. La verdad es que puedes y debes. Al habilitar la supervisión de Cloudtrail, puede ver todas las acciones realizadas dentro de su cuenta, por lo que siempre puede saber qué está pasando.

Cuenta cruzada

Esto se discutirá con más detalle en otro blog post, ya que nos centramos en cuentas únicas, pero por ahora, tenga en cuenta que las funciones de IAM se pueden utilizar para dar acceso a otras funciones de IAM o usuarios de IAM.

Y eso es increíblemente útil.

Punto de entrada requerido

Y ahora las desventajas. Lamentablemente, no puede otorgar acceso directo a la consola y credenciales temporales a una función de IAM. Primero, debe haber configurado un usuario o un rol federado (más sobre esto en algunos párrafos) para otorgar acceso a un rol de IAM.

Cuándo usar

Siempre. El único hecho de que las funciones de IAM son no vinculados con credenciales estáticas los convierte en la mejor manera de acceder a su nube. Combínelos con la capacidad de monitorear las acciones de los roles de IAM y hacer cumplir la seguridad incluso con MFA. El único inconveniente es que es un poco más de configuración, pero en mi opinión es un precio bajo a pagar.

Desde fuera de AWS

Y ahora, veamos qué podemos hacer cuando entrar en el campo de las identidades corporativas. Me refiero a utilizar un proveedor de identidades como fuente de identidades e iniciar sesión con nuestro correo electrónico y contraseña corporativos.

Federación

Pero, ¿qué queremos decir con federación? Por un lado, tenemos al proveedor de identidad. Estos sistemas contienen un directorio de usuarios y algún software que puede comunicarse a través de protocolos de federación específicos. Todos los datos de nuestros usuarios residen como Identidades .

Por otro lado, está su AWS Cuenta como Consumidor de identidad . Mantiene una referencia a las identidades sin guardarlas. Por este lado, generalmente tenemos niveles de autorización mucho más granulares (¡gracias, IAM!).

Entonces, la federation es la relación de confianza que hace que el consumidor de identidades pueda hacer referencia a las identidades en el proveedor de identidades.

Federación SAML

La definición más común para Security Assertion Markup Language (SAML ) es un estándar abierto para el intercambio de datos de autenticación y autorización entre partes. Esto significa que podemos usar nuestras identidades para iniciar sesión en AWS e incluso obtener credenciales temporales asumiendo roles. Es un enfoque generalista que puede aplicar a casi todos los proveedores de identidad.

La relación de confianza

Para configurar la federación entre las dos partes, necesitamos crear y administrar un Proveedor de identidad de IAM . Esto es necesario porque representa al proveedor de identidad real y contiene el secreto compartido que permite que las dos partes se comuniquen. Además, dentro de cada rol que queremos que asuman nuestros usuarios, definiremos una política de confianza para permitir entidades relacionadas con IAM Proveedor de identidad para asumir el rol:

Gestión personalizada

La cuestión es que, al principio, gestionar la federación por sí mismo puede resultar complicado y llevar mucho tiempo. Hay algunos conceptos que se deben comprender bien y es necesario crear un montón de entidades, relaciones y cosas personalizadas para que esto suceda. Para tener una idea, puede encontrar un ejemplo de tutorial completo aquí .

Cuándo usar

En general, este es un enfoque excelente y probado en batalla que funcionará en casi todos los casos. Aún así, la administración personalizada de identidades puede ser difícil y llevar mucho tiempo para personas sin experiencia.

Los casos de uso típicos son si desea administrarlo usted mismo por motivos de seguridad o cumplimiento. No tiene acceso a su organización de AWS o AWS SSO aún no es compatible con su proveedor de identidad.

AWS SSO

Este es el servicio de SSO administrado y basado en la nube que permite conecte su proveedor de identidad con su cuenta de AWS.

AWS Organization

Para configurar AWS SSO, deberá configurar AWS Organizations y, por ahora, puede pensar en ello para administrar varias cuentas de AWS. Para ser breve, debe saber que la configuración de una organización de AWS necesita amplios permisos (es decir, el usuario raíz).

Almacenamiento de identidad interno

De forma predeterminada, AWS SSO proporciona un directorio para almacenar su información de usuario y credenciales para servir como proveedor de identidad directamente. Es genial si aún no tiene un proveedor de identidad o no quiere tomarse la molestia de configurar uno.

Almacenamiento de identidad externo

Pero suponga que su organización ya usa algunos Directorio de usuarios, como Microsoft Active Directory. En ese caso, puede conectarlo a AWS SSO, eliminando la necesidad de mantener dos directorios distintos con aprovisionamiento automático .

Sin embargo, tenga en cuenta que esta característica solo es compatible con un conjunto limitado de proveedores de identidad:

Autenticación multifactor

Con AWS SSO, puede configurar un dispositivo MFA para sus usuarios dentro del servicio. En este momento, es compatible con aplicaciones Authenticator como Google Authenticator y claves de seguridad como Yubikey. La solución interna es interesante, pero carece de compatibilidad con MFA si se configura en un proveedor de identidad externo.

Cuándo usar

Es el estándar sugerido por AWS y puede ser la forma predeterminada a seguir si no está seguro de cómo proceder. Aún así, hay al menos un par de requisitos que debe marcar para aprovechar al máximo esta solución:

ya configuró su organización de AWS, y tienes acceso a la cuenta root. Desea mantener sus identidades dentro de AWS SSO o utilizar un proveedor de identidades compatible con el aprovisionamiento automático.

Notas finales

Por lo tanto, hemos establecido las bases para acceder a una sola cuenta de AWS, y ahora debería tener los elementos para elegir el mejor método para su caso de uso específico. Usaremos esto para cubrir el terreno de la administración de múltiples cuentas y las organizaciones de AWS en la próxima publicación del blog.

Leapp

Como última nota, recomiendo encarecidamente a todos que utilicen alguna herramienta que les ayuda a almacenar todos los datos necesarios para conectarse a su cuenta de AWS. Mi equipo y yo estamos desarrollando una herramienta de código abierto que admita todos estos casos de uso, así que no dude en consultar:

Noovolari / leapp

Leapp es su compañero diario para acceder a su nube; diseñado para trabajar con las API, CLI y SDK de Cloud Providers. Es …

github.com

Deja una respuesta

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