Administración de acceso

01

¿Quién eres y qué puedes hacer? Autenticación y autorización

Piensa en cuando entras en el edificio de tu empresa. En la entrada, tu credencial demuestra que eres tú. Luego, en cada piso, esa misma credencial se vuelve a revisar para ver si puedes pasar. Lo primero es la autenticación (comprobar quién eres) y lo segundo, la autorización (decidir si puedes hacer eso). La nube funciona igual, con los mismos dos pasos.

A quien envía una solicitud se le llama entidad principal de seguridad (security principal), o simplemente entidad principal. Y no son solo personas: un programa que hace copias de seguridad cada noche o un servidor que procesa pedidos también llaman al almacenamiento y a las bases de datos de la nube, así que también son entidades principales. Las personas demuestran quiénes son con una contraseña y un segundo factor; los programas, con claves o credenciales temporales (capítulo 4). Prueba a cambiar la situación en la escena de abajo.

En el estándar HTTP, el 401 significa un fallo de autenticación (dime otra vez quién eres) y el 403, un fallo de autorización (sé quién eres, pero no te lo permito). Sin embargo, las API de la nube no siempre respetan esa división: algunas devuelven 403 en los dos casos y otras, 401 en los dos. Por eso, más que el número de estado, mira el código y el mensaje de error para saber en qué puerta se bloqueó.

La cuenta más poderosa es la que no se usa

La cuenta de nivel superior que se crea al abrir una cuenta en la nube (la cuenta raíz o principal, el administrador máximo) lo puede hacer todo, hasta cambiar los datos de pago o cerrar la cuenta. Por eso se protege con MFA y se guarda bajo llave, y el trabajo del día a día se hace con otras cuentas con permisos repartidos. Si alguien se hace con esa cuenta, ninguna configuración de permisos sirve de nada.

Ya viste la puerta que comprueba quién eres. Pero si tus empleados usan decenas de apps, ¿hay que levantar esa puerta en cada una?

02

Una sola identidad: SSO, federación, MFA y acceso condicional

Si cada app tiene su propia cuenta y contraseña, las contraseñas se multiplican y la gente acaba reutilizando la misma. Cuando alguien deja la empresa, hay que ir app por app borrando su cuenta, y si se te escapa una sola, esa puerta sigue abierta. Por eso las identidades se reúnen en un único proveedor de identidad (IdP). Inicias sesión una sola vez en el IdP, y las apps te dejan entrar porque confían en la prueba (token) que este emite. Eso es el inicio de sesión único (SSO, Single Sign-On).

Si tu empresa ya usa un directorio corporativo, no hace falta volver a crear a las personas en la nube: puedes hacer que la nube confíe en ese directorio. Confiar así en la verificación de identidad de otra organización se llama federación, y los estándares para intercambiar esas pruebas son SAML 2.0 y OIDC (OpenID Connect).

Una contraseña no basta: MFA

Las contraseñas se filtran con facilidad, por phishing o porque se reutilizaron en otro sitio que sufrió una filtración. La MFA (autenticación multifactor) añade a la contraseña una segunda comprobación con algo que tienes (una app en el teléfono, una llave de seguridad) o algo que eres (tu huella). Pero no toda la MFA es igual de fuerte, y aquí es donde mucha gente se confunde: un SMS o los 6 dígitos de una app de autenticación se pueden teclear tal cual en un sitio falso, mientras que las llaves de seguridad y las claves de acceso (passkeys, FIDO2) solo funcionan en el sitio auténtico, así que resisten el phishing.

Decidir según el contexto: acceso condicional

No hace falta comprobar con la misma intensidad en cada inicio de sesión. Si alguien entra desde la oficina con el portátil de la empresa, puedes dejarlo pasar sin más; si entra desde un país y un dispositivo que nunca se habían visto, puedes pedirle MFA o bloquearlo. Decidir «permitir / permitir tras una verificación extra / bloquear» según señales como el usuario, la ubicación, el dispositivo y el riesgo es el acceso condicional. Para poder poner esas condiciones en un solo lugar, las identidades tienen que estar reunidas en un solo lugar (el IdP).

Ya está claro quién eres. Ahora viene la segunda puerta, «¿puedes hacer esto?». Vamos a leer las políticas que lo deciden.

03

Cómo leer una política: quién, qué, dónde y con qué condición

Los permisos se dan con políticas. Cada proveedor les da una forma distinta, pero los campos que contiene una política son casi los mismos: quién (la entidad principal), qué (la acción), dónde (el recurso), con qué condición (la condición) y si es un permiso o una denegación.

Permitir | Quién: grupo de desarrolladores
         | Qué: leer objetos, escribir objetos
         | Dónde: todos los objetos del bucket de desarrollo
         | Condición: solo si se inició sesión con MFA

Cuando llega una solicitud, el sistema reúne todas las políticas que se le aplican y las compara. Las reglas del veredicto caben en tres líneas.

En la escena de abajo, adjunta y quita la política de permiso y la de denegación.

Dos lugares donde adjuntar políticas: la identidad y el recurso

Una política se puede adjuntar a una identidad, como una persona, un grupo o un rol («esta persona puede hacer esto»), o a un recurso, como un almacenamiento («en este bucket puede entrar tal persona»). Las políticas del lado del recurso siempre llevan el campo «quién». Son especialmente importantes cuando dejas entrar a entidades principales de otra cuenta u organización, así que las veremos aparte en el capítulo 5.

No las des persona por persona: grupos y roles

Si adjuntas las políticas a cada persona, en cuanto crece el equipo se vuelve imposible de administrar. Reunir a quienes hacen el mismo trabajo en un grupo y adjuntar la política al grupo, o crear paquetes de permisos como «solo lectura» u «operador de base de datos» en forma de roles, se llama control de acceso basado en roles (RBAC). Si además usas atributos como las etiquetas como condición, por ejemplo «solo los recursos con la misma etiqueta de proyecto», se llama control de acceso basado en atributos (ABAC).

Las políticas no son solo para personas. ¿Cómo le das permisos a un programa que trabaja toda la noche sin que nadie esté delante?