Qué permisos dar a un empleado nuevo en AWS (y cuáles no)

Entra alguien nuevo en la empresa y necesita "acceso a AWS". Lo rápido es crear un usuario, darle AdministratorAccess y seguir con el día. Es también lo que convierte un error de un becario, o una contraseña robada, en una cuenta vacía o en una factura de miles de euros. Casi todos los sustos con AWS en empresas pequeñas empiezan con alguien que tenía muchos más permisos de los que necesitaba.

La regla es sencilla: cada persona puede hacer solo lo que necesita para su trabajo, y nada más. Se llama mínimo privilegio y no exige saber de seguridad. Exige pensar un minuto en qué va a hacer esa persona: ¿mirar? ¿encender y apagar máquinas? ¿crear y borrar cosas? Con esa respuesta, AWS ya tiene los permisos preparados y solo hay que elegirlos.

Esta guía usa grupos en lugar de dar permisos a cada usuario uno por uno. Es la diferencia entre decidir una vez por cada función y decidir cada vez que entra alguien.

Paso a paso

1. Decide qué función tiene la persona

   Antes de tocar la consola, contesta a una pregunta: ¿qué tiene que hacer esta persona en AWS? Para una empresa pequeña, casi todo encaja en tres funciones:

   • Ver: mirar el estado de las máquinas, consultar la factura, leer registros. Es lo que necesita quien da soporte, quien lleva las cuentas o un jefe que quiere "ver cómo va".
   • Operar: además de ver, encender, apagar y reiniciar máquinas, hacer instantáneas, restaurar. Es lo que necesita quien lleva el día a día del servidor.
   • Administrar: crear y borrar máquinas, cambiar redes, gestionar usuarios. Esto solo lo necesitan una o dos personas, y deberían ser las que más saben.

   Si dudas entre dos, empieza por la de menos permisos. Subir es un clic; descubrir que alguien borró algo que no debía, no.

2. Crea los tres grupos en IAM

   Abre IAM, menú de la izquierda Grupos de usuarios, botón Crear grupo. Haz tres, con nombres que entienda cualquiera: ver, operar y administrar. Al crear cada grupo, en el bloque Adjuntar políticas de permisos busca y marca la política que le toca:

   • Grupo ver: ReadOnlyAccess. Permite consultar cualquier servicio sin cambiar nada. Si solo quieres que vean la factura, existe AWSBillingReadOnlyAccess, más limitada.
   • Grupo operar: ReadOnlyAccess y además una política propia con las acciones de arrancar, parar y reiniciar (siguiente paso). Para Lightsail no hay una política gestionada intermedia, así que la escribirás tú; para EC2 tampoco hay una que solo encienda y apague.
   • Grupo administrar: PowerUserAccess, que permite casi todo salvo gestionar usuarios y permisos. Deja AdministratorAccess para una única persona, la que también tiene la cuenta raíz guardada.

   Los grupos se crean una vez. A partir de ahí, dar acceso a alguien es meterlo en el grupo adecuado.

3. Escribe la política del grupo "operar"

   En IAM, Políticas, Crear política. Pulsa la pestaña JSON y pega esto, que permite encender, apagar y reiniciar máquinas de Lightsail y EC2, y hacer instantáneas, pero no crear ni borrar máquinas:

   {
     "Version": "2012-10-17",
     "Statement": [
       { "Effect": "Allow", "Action": [
           "lightsail:StartInstance", "lightsail:StopInstance", "lightsail:RebootInstance",
           "lightsail:CreateInstanceSnapshot",
           "ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances",
           "ec2:CreateSnapshot"
         ], "Resource": "*" }
     ]
   }

   Pulsa Siguiente, llámala operar-maquinas y créala. Después, en Grupos de usuarios, entra en operar, pestaña Permisos, Agregar permisos, Adjuntar políticas, y marca operar-maquinas.

   Fíjate en que no aparece ninguna acción con "Delete" ni "Terminate". Es la diferencia entre poder apagar una máquina y poder hacerla desaparecer. Si quieres limitarlo además a unas máquinas concretas, en Resource puedes poner el identificador de cada una en vez del asterisco; para EC2 es sencillo, para Lightsail hay que usar el ARN de cada instancia.

4. Crea el usuario y mételo en un grupo

   IAM, Usuarios, Crear usuario. Nombre: el de la persona (maria.lopez), nunca algo compartido como soporte. Marca Proporcionar acceso a la consola de administración de AWS, elige Quiero crear un usuario de IAM y deja marcado que debe cambiar la contraseña al iniciar sesión.

   En la pantalla de permisos elige Agregar usuario al grupo y marca solo el grupo que decidiste en el paso 1. No adjuntes políticas directamente al usuario: dentro de seis meses nadie recordará por qué tiene ese permiso suelto. Crea el usuario y apunta la dirección de inicio de sesión (lleva el número de tu cuenta) para enviársela junto con la contraseña temporal por canales distintos: la dirección por correo, la contraseña en persona o por un mensaje que caduque.

   Si la persona no va a usar programas que hablen con AWS, no crees claves de acceso. Se pueden añadir el día que hagan falta.

5. Haz obligatorio el doble factor

   Pide a la persona que, en su primer acceso, vaya al menú de su nombre, Credenciales de seguridad, y asigne un dispositivo MFA con la aplicación del móvil. Pero no lo dejes a la buena voluntad: en IAM, Políticas, crea una política que deniegue todo salvo configurar MFA cuando el usuario no ha entrado con doble factor, y adjúntala a los tres grupos. AWS la tiene como ejemplo en su documentación con el nombre "permitir a los usuarios gestionar su propio MFA"; copia el JSON de ahí tal cual.

   El efecto: quien entra sin MFA solo ve la pantalla para activarlo. Todo lo demás aparece bloqueado hasta que lo hace. Es la única forma de que de verdad lo tenga todo el mundo.

6. Revisa lo que no debe tener nadie

   Antes de dar por cerrado el alta, repasa en IAM, Usuarios, columna de políticas adjuntas:

   • AdministratorAccess en más de una o dos personas: sobra. Nadie que solo opere máquinas lo necesita.
   • IAMFullAccess en alguien que no gestiona usuarios: con ese permiso puede darse a sí mismo cualquier otro.
   • Permisos adjuntos directamente al usuario en vez de a través de grupos: muévelos al grupo o bórralos.
   • Claves de acceso en usuarios de personas que no programan nada.

   Si encuentras algo de esto en usuarios antiguos, aprovecha para corregirlo. Es el momento en que más fácil resulta.

7. Prepara la baja desde el primer día

   El día que alguien se marcha, su acceso a AWS debe desaparecer el mismo día, antes de que entregue el ordenador. En IAM, Usuarios, selecciona el usuario: primero desactiva el acceso a la consola y las claves de acceso (pestaña Credenciales de seguridad), espera una o dos semanas para comprobar que nada dependía de esa persona, y luego elimina el usuario.

   Apúntalo en la lista de tareas de salida junto con el correo y las llaves de la oficina. Y una vez al trimestre, descarga el Informe de credenciales de IAM: te dice de cada usuario cuándo entró por última vez, si tiene MFA y si sus claves se usan. Un usuario que no entra desde hace tres meses es un usuario que probablemente ya no debería existir.

Qué puede salir mal