Notas de estudio personales.
Fuentes: Microsoft Learn, Auth0 Docs, AWS IAM Docs, NIST, Cloud Security Alliance, TechTarget.
- Fundamentos
- Autenticación — AuthN
- Autorización — AuthZ
- Modelos de Control de Acceso
- Identity Providers y Directorios
- Protocolos de Identidad
- Tokens y Sesiones
- Federación y SSO
- Ciclo de Vida de la Identidad
- Privilegios y Acceso Mínimo
- Auditoría y Monitoreo
- Amenazas Comunes
- Conceptos Avanzados
IAM (Identity & Access Management) = Marco de políticas, procesos y tecnologías que gestiona identidades digitales y controla el acceso a los recursos de una organización.
Ejemplo: el conjunto de herramientas y reglas que define quién puede entrar al sistema, a qué puede acceder y qué puede hacer.
Identidad = Representación digital única de una entidad dentro de un sistema. Puede ser una persona, una aplicación, un dispositivo o un servicio.
Ejemplo:
tobi@empresa.comes la identidad digital de Tobi dentro de esa organización.
Principal = Cualquier entidad que puede solicitar acceso a un recurso. Puede ser humana o no humana.
Ejemplo: tanto el usuario que hace login en la consola como la función Lambda que llama a una API son principals.
Credencial = Dato o conjunto de datos que una entidad presenta para demostrar su identidad.
Ejemplo: una contraseña, un certificado digital, una clave SSH o un token son credenciales.
Recurso = Cualquier objeto al que se quiere controlar el acceso: archivos, APIs, bases de datos, consolas, servicios en la nube.
Ejemplo: un bucket de S3, un endpoint
/api/admino una base de datos de producción son recursos.
Permiso = Acción específica autorizada sobre un recurso concreto.
Ejemplo: el permiso
s3:GetObjectpermite leer objetos de S3, pero no borrarlos ni listar el bucket.
Política (Policy) = Conjunto de reglas que define qué acciones están permitidas o denegadas, sobre qué recursos, y bajo qué condiciones.
Ejemplo: "el rol
soportepuede leer tickets pero no eliminarlos ni cambiar su estado" es una política.
Rol = Conjunto de permisos agrupados bajo un nombre. Se asigna a usuarios o entidades en lugar de asignar permisos uno por uno.
Ejemplo: el rol
desarrolladortiene acceso a repositorios y pipelines, pero no a facturación ni producción.
Grupo = Conjunto de usuarios que comparten los mismos permisos o roles. Facilita la administración a escala.
Ejemplo: en vez de asignar acceso al CRM a 30 personas individualmente, se crea el grupo
ventascon ese acceso y simplemente se agrega a cada persona al grupo.
Atributo = Propiedad o característica de una identidad, recurso o contexto, usada para tomar decisiones de acceso.
Ejemplo:
departamento=legal,nivel_clearance=3oubicacion=argson atributos que puede usar un sistema para decidir si dar o negar acceso.
Claim = Afirmación sobre una identidad que viaja dentro de un token. Puede ser el nombre, el rol, el email, el departamento, etc.
Ejemplo: un JWT puede contener el claim
"role": "admin", que indica que quien lo presenta tiene permisos de administrador.
Cuenta de servicio (Service Account) = Identidad creada para ser usada por una aplicación o proceso automatizado, no por una persona.
Ejemplo: una función de Cloud Run tiene una cuenta de servicio con permisos para escribir en Pub/Sub. Ningún humano usa esas credenciales directamente.
Cuenta privilegiada = Cuenta con acceso elevado o administrativo sobre sistemas críticos.
Ejemplo: la cuenta
rooten Linux o una cuenta conAdministratorAccessen AWS son cuentas privilegiadas.
Las tres A del IAM (AAA)
- Authentication (AuthN) = verificar quién es el que solicita acceso.
- Authorization (AuthZ) = determinar qué puede hacer esa entidad.
- Auditing / Accounting = registrar y revisar todo lo que se hizo.
Estos tres pilares son la base de cualquier sistema IAM. Sin auditoría, no hay trazabilidad; sin ella, el cumplimiento normativo es imposible.
Autenticación (AuthN) = Proceso de verificar que una entidad es quien dice ser. Responde la pregunta: ¿sos quien decís ser?
Ejemplo: ingresar usuario y contraseña en Gmail es autenticación. Gmail verifica que esas credenciales existen y corresponden a esa cuenta antes de dar acceso.
Factor de autenticación = Tipo de evidencia usada para verificar la identidad.
Existen cuatro categorías:
- Conocimiento (algo que sabés): contraseña, PIN, pregunta secreta.
- Posesión (algo que tenés): OTP, token físico, smartphone con app autenticadora.
- Inherencia (algo que sos): huella dactilar, reconocimiento facial, iris.
- Contexto (dónde estás): IP corporativa, geolocalización, red de confianza.
MFA (Multi-Factor Authentication) = Autenticación que combina dos o más factores de categorías distintas. Si un factor es comprometido, el resto actúa como barrera.
Ejemplo: contraseña (conocimiento) + código de Google Authenticator (posesión). Aunque alguien robe tu contraseña, no puede entrar sin el segundo factor.
2FA (Two-Factor Authentication) = Caso específico de MFA con exactamente dos factores. Más seguro que una contraseña sola, pero no tan robusto como esquemas con más factores.
Ejemplo: contraseña + código enviado por SMS.
OTP (One-Time Password) = Contraseña de un solo uso, válida por un tiempo limitado o para una única operación.
Ejemplo: el código de 6 dígitos que envía el banco por SMS y expira en 5 minutos.
TOTP (Time-based OTP) = Variante de OTP generada en base al tiempo actual. El servidor y el cliente comparten un secreto y calculan el mismo código de forma sincronizada cada 30 segundos.
Ejemplo: los códigos de Authy o Google Authenticator son TOTP. Se regeneran automáticamente.
Passwordless Authentication = Autenticación sin contraseña, usando otros factores como biometría, magic links o passkeys.
Ejemplo: recibir un link de un solo uso por email para iniciar sesión, sin necesidad de recordar una contraseña.
Passkey = Credencial criptográfica que reemplaza la contraseña. Usa un par de claves pública/privada junto con biometría o PIN local. La clave privada nunca sale del dispositivo, lo que la hace resistente al phishing.
Ejemplo: iniciar sesión en GitHub con huella digital, sin contraseña. El sitio nunca ve la clave privada.
FIDO2 / WebAuthn = Estándar moderno para autenticación sin contraseña basado en criptografía de clave pública. Es la base técnica detrás de los passkeys.
Ejemplo: registrás tu huella en un sitio compatible con WebAuthn. La próxima vez que entrás, tu dispositivo firma el desafío del servidor localmente, sin enviar nada sensible.
Autenticación basada en riesgo (Risk-Based / Adaptive Authentication) = El sistema evalúa el nivel de riesgo de cada intento de login y decide dinámicamente si pedir factores adicionales, basándose en comportamiento, ubicación, dispositivo, hora, etc.
Ejemplo: hacés login desde el mismo dispositivo y ciudad de siempre → acceso normal. Login desde un país diferente a las 3am → el sistema pide MFA automáticamente.
Certificado digital = Documento electrónico firmado por una CA que vincula una clave pública con una identidad específica.
Ejemplo: cuando accedés a
https://banco.com, el servidor presenta su certificado para demostrar que es quién dice ser y no un impostor.
PKI (Public Key Infrastructure) = Sistema de gestión de certificados, claves y Autoridades de Certificación que permite autenticación y comunicación segura mediante criptografía asimétrica.
Ejemplo: toda la infraestructura de HTTPS en internet está construida sobre PKI.
CA (Certificate Authority) = Entidad de confianza que emite y firma certificados digitales, garantizando que pertenecen a quien dicen pertenecer.
Ejemplo: Let's Encrypt es una CA pública gratuita. Las empresas también pueden tener una CA interna para emitir certificados corporativos.
Error HTTP 401 Unauthorized = Respuesta que indica que la autenticación falló o no fue provista. A pesar del nombre, significa "no autenticado".
Ejemplo: llamar a una API privada sin incluir un token en el header devuelve
401.
Autorización (AuthZ) = Proceso de determinar si una identidad ya autenticada tiene permiso para realizar una acción sobre un recurso. Responde la pregunta: ¿qué tenés permitido hacer? Siempre ocurre después de la autenticación.
Ejemplo: estás logueado (autenticado), pero al intentar acceder al panel de admin, el sistema verifica si tu rol tiene ese permiso (autorización).
Diferencia fundamental AuthN vs AuthZ
AuthN = verifica quién sos.
AuthZ = verifica qué podés hacer.
Podés estar autenticado pero no autorizado. No podés estar autorizado sin haberte autenticado primero.
Deny-by-default = Principio por el cual todo acceso está denegado hasta que una regla explícita lo permita. Es el punto de partida más seguro.
Ejemplo: AWS deniega todas las acciones a un usuario nuevo. Hay que asignarle políticas explícitamente para que pueda hacer algo.
Deny explícito = En la mayoría de los sistemas IAM, un Deny explícito tiene siempre prioridad sobre cualquier Allow, sin excepción.
Ejemplo: un usuario tiene acceso a S3 por su grupo, pero existe una política individual que le deniega S3 explícitamente. El Deny gana.
Scope = En OAuth 2.0, define el conjunto específico de permisos que una aplicación solicita sobre los recursos del usuario.
Ejemplo: una app de música pide scope
read:librarypara ver tu lista, pero nodelete:library. El usuario aprueba exactamente esos permisos, nada más.
Entitlement = Derecho concreto que tiene una identidad para acceder a un recurso o ejecutar una acción. Puede derivar de un rol, una política directa o una membresía de grupo.
Ejemplo: "el usuario tiene entitlement para ver facturas del mes actual" puede venir de pertenecer al grupo
contabilidad.
Error HTTP 403 Forbidden = Respuesta que indica que la autenticación fue exitosa, pero el acceso fue denegado por falta de permisos.
Ejemplo: estás logueado, pero intentás acceder a
/adminsin tener el rol necesario. El servidor devuelve403.
DAC (Discretionary Access Control) = El dueño del recurso decide quién puede acceder y con qué permisos. Flexible pero difícil de auditar a escala.
Ejemplo: en Google Drive vos decidís quién puede ver o editar cada archivo. Eso es DAC.
MAC (Mandatory Access Control) = El sistema define las reglas de acceso en base a clasificaciones de seguridad. Ni el dueño del recurso puede cambiarlas. Diseñado para entornos de alta seguridad.
Ejemplo: en sistemas militares, un documento "Top Secret" solo puede ser leído por usuarios con esa habilitación. El dueño del documento no puede delegarlo.
RBAC (Role-Based Access Control) = Los permisos se asignan a roles, y los usuarios acceden a recursos a través de esos roles. Es el modelo más usado en entornos empresariales por su balance entre simplicidad y escalabilidad.
Ejemplo: el rol
soportepuede ver tickets pero no borrarlos. El roladminpuede hacer todo. Un usuario puede tener múltiples roles.
Usuario → tiene Rol → Rol tiene Permisos → Permisos sobre Recursos
ABAC (Attribute-Based Access Control) = Las decisiones de acceso se basan en atributos del usuario, del recurso y del entorno, evaluados en tiempo real. Más granular y dinámico que RBAC.
Ejemplo: "puede ver el contrato si trabaja en el departamento legal Y el contrato está marcado como interno Y es horario laboral".
ReBAC (Relationship-Based Access Control) = El acceso se define en función de la relación entre el usuario y el recurso, no solo por su rol o atributos.
Ejemplo: podés editar un documento de Google Drive si sos su propietario o si alguien te lo compartió. Esa relación determina el acceso.
PBAC (Policy-Based Access Control) = Generalización de ABAC donde el control de acceso se define mediante políticas expresivas y centralizadas que combinan roles, atributos y condiciones.
Ejemplo: AWS IAM usa PBAC. Las políticas en JSON definen acciones permitidas o denegadas, sobre qué recursos, bajo qué condiciones.
IdP (Identity Provider) = Sistema responsable de autenticar a los usuarios y emitir afirmaciones sobre su identidad hacia otras aplicaciones. Es la fuente de verdad sobre quién es un usuario.
Ejemplo: cuando entrás a una app con "Iniciar sesión con Google", Google es el IdP: autentica tu identidad y le dice a la app quién sos.
SP (Service Provider) = Aplicación o sistema que confía en un IdP para autenticar a sus usuarios. Delega la verificación de identidad en lugar de gestionarla internamente.
Ejemplo: Salesforce es un SP. No gestiona contraseñas propias; confía en que el IdP corporativo ya autenticó al usuario.
Directorio de identidades = Base de datos centralizada que almacena y gestiona información sobre usuarios, grupos, credenciales y atributos. Es el libro de registros de las identidades.
Ejemplo: Active Directory almacena todos los usuarios, grupos, equipos y políticas de una red Windows.
Active Directory (AD) = Servicio de directorio de Microsoft para entornos Windows. Gestiona usuarios, computadoras, grupos y políticas de seguridad de toda una organización.
Ejemplo: cuando hacés login en tu PC corporativa, AD es quien verifica tus credenciales y determina a qué recursos de red tenés acceso.
LDAP (Lightweight Directory Access Protocol) = Protocolo estándar para consultar y modificar servicios de directorio. Active Directory usa LDAP como protocolo subyacente.
Ejemplo: una aplicación web empresarial usa LDAP para verificar si un usuario existe en AD y obtener sus grupos antes de darle acceso.
Azure AD / Microsoft Entra ID = Servicio de identidad cloud de Microsoft. Es la versión moderna de AD basada en la nube, compatible con OIDC, SAML y OAuth 2.0.
Ejemplo: empresas que usan Microsoft 365 gestionan el acceso a Teams, SharePoint y apps SaaS a través de Azure AD.
Domain Controller (DC) = Servidor en un entorno Active Directory que procesa las solicitudes de autenticación y aplica las políticas del dominio.
Ejemplo: cuando un usuario hace login en la red corporativa, su equipo se comunica con el DC para verificar credenciales.
SAML 2.0 (Security Assertion Markup Language) = Protocolo basado en XML para intercambiar datos de autenticación y autorización entre un IdP y un SP. Diseñado para SSO en entornos empresariales.
Ejemplo: una empresa usa SAML para que sus empleados accedan a Salesforce con credenciales corporativas de AD, sin crear cuentas separadas.
Flujo básico:
1. Usuario accede al SP (ej: Salesforce)
2. SP genera una AuthnRequest y redirige al IdP
3. IdP autentica al usuario
4. IdP envía una Assertion XML firmada al SP
5. SP valida la firma y concede acceso
OAuth 2.0 = Framework de autorización que permite a una aplicación acceder a recursos en nombre de un usuario sin que ese usuario comparta sus credenciales. No es un protocolo de autenticación.
Ejemplo: cuando una app de fitness pide acceso a tu Google Calendar, no le das tu contraseña de Google. OAuth le otorga un token con acceso limitado y específico.
Roles en OAuth 2.0:
| Rol | Función |
|---|---|
| Resource Owner | El usuario que otorga el permiso |
| Client | La app que solicita acceso |
| Authorization Server | Quien emite el token |
| Resource Server | Quien protege el recurso |
OpenID Connect (OIDC) = Capa de autenticación construida sobre OAuth 2.0. Agrega un ID Token (JWT) con información del usuario autenticado. Responde la pregunta que OAuth no puede solo: ¿quién es el usuario?
Ejemplo: "Iniciar sesión con Google" usa OIDC. OAuth gestiona el acceso; OIDC identifica al usuario.
OAuth 2.0 vs OIDC
OAuth 2.0 = responde "esta app puede acceder a tus fotos".
OIDC = responde "esta app puede acceder a tus fotos, y sabemos que sos vos quien autorizó eso".
Kerberos = Protocolo de autenticación de red que usa tickets criptográficos para autenticar usuarios y servicios sin transmitir contraseñas. Es el protocolo subyacente de Active Directory.
Ejemplo: hacés login en tu PC corporativa Windows y luego accedés a una carpeta de red sin que te pidan contraseña de nuevo. Kerberos gestionó eso internamente.
RADIUS (Remote Authentication Dial-In User Service) = Protocolo de autenticación para gestionar acceso a redes. Muy usado en VPNs, WiFi empresarial y equipos de red.
Ejemplo: al conectarte a la VPN corporativa, el servidor RADIUS verifica tus credenciales antes de darte acceso a la red interna.
SCIM (System for Cross-domain Identity Management) = Protocolo estándar REST para automatizar el provisioning y deprovisioning de usuarios entre sistemas. Define endpoints y un schema común para representar usuarios y grupos.
Ejemplo: cuando RRHH crea un empleado en Workday, SCIM propaga automáticamente esa identidad a Slack, GitHub y Salesforce, sin intervención manual.
WS-Federation = Protocolo de federación de identidades de Microsoft, usado principalmente con AD FS en entornos legacy.
Ejemplo: organizaciones antiguas con infraestructura Windows que integran aplicaciones .NET con AD FS suelen usar WS-Federation.
Token = String que representa una identidad o conjunto de permisos. El cliente lo presenta en cada solicitud para demostrar que fue autenticado y/o autorizado.
Ejemplo: tras hacer login en una API, el servidor devuelve un token. Cada llamada posterior incluye ese token en el header para no tener que autenticar de nuevo.
JWT (JSON Web Token) = Estándar de token autocontenido y firmado digitalmente. Tiene tres partes separadas por puntos: header.payload.signature.
Ejemplo:
eyJhbGci...eyJzdWIi...SflKxes un JWT. Decodificado revela datos comosub,roles,exp.
El servidor valida el token verificando la firma, sin consultar ninguna base de datos (stateless). Si alguien modifica el payload, la firma no coincide y el token es rechazado.
Access Token = Token de corta duración que el cliente usa para acceder a recursos protegidos. Contiene los scopes otorgados.
Ejemplo: tras autenticarte, la app recibe un access token válido por 1 hora para llamar a la API.
Refresh Token = Token de larga duración usado para obtener un nuevo access token cuando el anterior expira, sin que el usuario tenga que volver a hacer login.
Ejemplo: seguís usando la app durante días sin re-autenticarte porque en segundo plano renueva el access token con el refresh token.
ID Token = Token emitido por OIDC en formato JWT que contiene información del usuario autenticado. No se usa para acceder a recursos, sino para saber quién es el usuario.
Ejemplo: el ID token contiene
"email": "tobi@empresa.com"y"name": "Tobi". La app lo usa para mostrar el perfil del usuario logueado.
Opaque Token = Token sin información legible internamente. Es solo una referencia. Para validarlo, el servidor debe consultarlo contra una base de datos o un endpoint de introspección.
Ejemplo: un token de sesión como
a3f8e2b1c9...no revela nada. El servidor lo busca en su base de datos para saber a quién corresponde.
Token Introspection = Endpoint que permite a un servidor verificar si un opaque token es válido y obtener sus metadatos (quién lo emitió, qué scopes tiene, si está activo).
Ejemplo: una API llama a
POST /introspectcon el token. El Authorization Server responde con el estado y los permisos del token.
Bearer Token = Esquema de autenticación HTTP donde el token se envía en el header Authorization: Bearer <token>. Quien tenga el token tiene el acceso, sin verificación adicional del portador.
Ejemplo:
Authorization: Bearer eyJhbGci...es el header estándar de las APIs autenticadas.
Sesión = Estado temporal del lado del servidor que mantiene el contexto de un usuario autenticado. Se identifica con un session ID guardado en una cookie.
Ejemplo: hacés login en un sitio, cerrás el navegador, lo abrís de nuevo y seguís logueado porque el servidor mantiene tu sesión activa.
JWT vs Opaque Token
JWT = stateless, autocontenido, el servidor valida localmente. Difícil de revocar antes de que expire.
Opaque = stateful, referencia externa, fácil de revocar al instante, pero requiere una consulta al servidor en cada request.
Sesión vs Token
Sesión = estado en el servidor. Revocación inmediata. No escala bien en sistemas distribuidos.
Token = estado en el cliente. Escala bien. Difícil de revocar antes de la expiración.
PKCE (Proof Key for Code Exchange) = Extensión de seguridad para OAuth 2.0 en clientes públicos como apps mobile o SPAs. Evita que un código de autorización interceptado pueda ser usado por un atacante.
Ejemplo: una app mobile genera un
code_verifiersecreto antes del flow. Aunque alguien intercepte el código de autorización en el callback, no puede canjearlo sin ese secreto.
Federación de identidades = Mecanismo por el cual dos o más dominios u organizaciones establecen confianza mutua para compartir identidades, sin que el usuario tenga que crear credenciales nuevas en cada sistema.
Ejemplo: sos empleado de Empresa A y necesitás acceder a un sistema de Empresa B. Con federación, B confía en la autenticación de A.
SSO (Single Sign-On) = El usuario se autentica una sola vez ante el IdP y accede a múltiples aplicaciones sin volver a ingresar credenciales. Las apps confían en el IdP como fuente de verdad.
Ejemplo: llegás a la oficina, hacés login una sola vez, y luego podés entrar a Gmail, Slack, GitHub y Jira sin volver a escribir contraseña.
SLO (Single Log-Out) = Extensión de SSO que propaga el cierre de sesión a todas las apps de la federación cuando el usuario cierra sesión en una de ellas.
Ejemplo: cerrás sesión en el portal corporativo y automáticamente también cerrás sesión en todas las apps federadas al mismo IdP.
Trust (relación de confianza) = Configuración explícita entre un IdP y un SP que establece que el SP aceptará y confiará en las afirmaciones de identidad emitidas por ese IdP.
Ejemplo: para que Salesforce acepte el SSO corporativo, hay que configurar la relación de confianza subiendo el certificado del IdP a Salesforce.
SSO vs Federación
SSO = una autenticación para muchas apps dentro del mismo dominio de confianza.
Federación = extender esa confianza a dominios externos u organizaciones distintas.
Identity Lifecycle Management = Conjunto de procesos para gestionar el ciclo completo de una identidad: desde su creación hasta su eliminación, incluyendo todos los cambios de rol y permisos intermedios.
Provisioning → Acceso activo → Cambio de rol → Deprovisioning
Provisioning = Proceso de crear una identidad y asignarle los accesos necesarios cuando alguien ingresa a una organización o sistema.
Ejemplo: cuando entra un empleado nuevo, se crea su cuenta en AD, se lo agrega al grupo de su equipo y se le asigna acceso a las herramientas que necesita.
Deprovisioning = Proceso de revocar accesos y desactivar o eliminar una identidad cuando ya no es necesaria.
Ejemplo: cuando un empleado renuncia, se deshabilita su cuenta, se revocan sus tokens activos y se le quita acceso a todos los sistemas.
Joiner / Mover / Leaver = Framework estándar para los tres eventos principales del ciclo de vida de una identidad.
- Joiner (nuevo ingreso) = crear identidad, asignar accesos base.
- Mover (cambio de rol o área) = ajustar permisos, revocar los que ya no corresponden.
- Leaver (salida) = revocar todo acceso, deshabilitar la cuenta de inmediato.
El mayor riesgo suele estar en Mover y Leaver: los accesos viejos raramente se limpian a tiempo sin automatización.
Just-in-Time Provisioning (JIT Provisioning) = El usuario es creado automáticamente en una aplicación la primera vez que accede mediante SSO, usando los datos enviados por el IdP. No requiere intervención manual previa.
Ejemplo: un empleado nuevo accede por primera vez a Slack con SSO corporativo. Slack crea automáticamente su cuenta con nombre, email y equipo.
Access Review / Recertification = Proceso periódico donde managers o dueños de sistemas revisan y confirman, o revocan, los accesos de sus usuarios.
Ejemplo: cada trimestre, los líderes de equipo reciben una lista de accesos de sus empleados y deben aprobar o revocar cada uno. Los no certificados se revocan automáticamente.
Orphan Account = Cuenta que ya no tiene un usuario real asociado porque la persona se fue o cambió de rol y la cuenta no fue desactivada.
Ejemplo: un ex-empleado que se fue hace 6 meses pero cuya cuenta de GitHub sigue activa es una orphan account.
Dormant Account = Cuenta que existe pero no ha sido utilizada en un período largo de tiempo.
Ejemplo: una cuenta de AWS que no hizo login en 90 días es dormant y debería ser revisada o desactivada.
Principio de Menor Privilegio (PoLP) = Cada entidad debe tener únicamente los permisos mínimos necesarios para cumplir su función, y nada más. Limita el daño si una credencial es comprometida.
Ejemplo: una función Lambda que solo lee de DynamoDB no debería tener permisos de escritura ni acceso a S3.
Need-to-Know = Complemento del PoLP: el usuario solo puede acceder a la información específica que necesita para su tarea, aunque tenga el nivel de acceso correcto.
Ejemplo: un analista de soporte puede ver tickets de clientes, pero solo los de su área, no todos los tickets del sistema.
PAM (Privileged Access Management) = Conjunto de herramientas y procesos para gestionar, monitorear y auditar el acceso de cuentas con privilegios elevados.
Funcionalidades clave:
- Password Vaulting = las contraseñas privilegiadas se almacenan cifradas y se rotan automáticamente.
- Session Recording = las sesiones privilegiadas se graban para auditoría.
- JIT Access = el acceso se otorga temporalmente, solo cuando se necesita.
Ejemplo: un DBA no tiene acceso permanente a producción. Cuando necesita hacer mantenimiento, solicita acceso por 2 horas, el PAM registra la sesión y revoca el acceso al terminar.
JIT Access (Just-in-Time Access) = El acceso privilegiado se otorga solo cuando se necesita y por un tiempo definido. Evita el acceso permanente a sistemas críticos.
Ejemplo: en vez de tener rol de admin de producción siempre activo, lo solicitás, lo tenés por 30 minutos, hacés lo que necesitás, y expira automáticamente.
Zero Standing Privileges (ZSP) = Modelo donde ningún usuario tiene permisos privilegiados de forma permanente. Todo el acceso elevado es JIT.
Ejemplo: ningún miembro del equipo tiene rol admin permanente en producción. Cuando se necesita, se solicita, se aprueba, y se otorga temporalmente.
SoD (Segregación de Funciones) = Ninguna persona debe tener control completo sobre un proceso crítico de extremo a extremo. Las responsabilidades se dividen para prevenir fraude o errores.
Ejemplo: quien puede crear un proveedor en el sistema de pagos no debería ser la misma persona que aprueba y ejecuta los pagos.
4-Eyes Principle = Acciones críticas requieren la aprobación explícita de al menos dos personas antes de ejecutarse.
Ejemplo: para hacer un deploy a producción o ejecutar un cambio en infraestructura crítica, se necesita que otra persona lo apruebe primero.
Auditoría (Auditing / Accounting) = Registro sistemático de todas las acciones de autenticación, autorización y acceso realizadas por usuarios y sistemas. Es la tercera A del IAM.
Ejemplo: cada vez que alguien hace login, asume un rol, accede a un recurso o intenta algo que no tiene permiso, el sistema lo registra con timestamp, IP y resultado.
Audit Log / Access Log = Registro cronológico de eventos de acceso e identidad. Es la base para forensics, detección de anomalías y cumplimiento normativo.
Ejemplo: CloudTrail en AWS registra cada llamada a la API con quién la hizo, desde dónde, qué hizo y cuándo.
SIEM (Security Information and Event Management) = Plataforma que centraliza, correlaciona y analiza logs de múltiples sistemas para detectar amenazas y generar alertas.
Ejemplo: Splunk o Microsoft Sentinel reciben logs de AD, VPN, endpoints y apps, y detectan automáticamente patrones anómalos como múltiples logins fallidos seguidos de uno exitoso desde otra IP.
UEBA (User and Entity Behavior Analytics) = Sistema que establece una línea base del comportamiento normal de usuarios y entidades, y detecta anomalías que podrían indicar una amenaza.
Ejemplo: si un usuario que siempre trabaja de 9 a 18 en Buenos Aires hace login a las 3am desde Rusia y descarga 10GB de datos, UEBA genera una alerta de alta criticidad.
Compliance (Cumplimiento normativo) = Adherencia a regulaciones, estándares y leyes que imponen requisitos sobre cómo se gestionan las identidades y los accesos.
Estándares relevantes para IAM:
- SOX = controles sobre accesos a sistemas financieros.
- GDPR = protección de datos personales, derecho al olvido.
- HIPAA = protección de datos de salud.
- PCI DSS = seguridad en el manejo de datos de tarjetas de pago.
- ISO 27001 = marco general de seguridad de la información.
Credential Stuffing = Ataque automatizado que usa listas de usuario/contraseña filtradas de otras brechas, aprovechando que la gente reutiliza credenciales en múltiples servicios.
Mitigación: MFA, detección de intentos masivos, bloqueo por comportamiento anómalo.
Password Spraying = En vez de atacar una sola cuenta con muchas contraseñas (lo que activa bloqueos), se prueba una contraseña común contra miles de cuentas distintas.
Ejemplo: probar
Empresa2024!contra todos los usuarios del directorio corporativo.
Mitigación: MFA, políticas de contraseñas robustas, alertas de intentos distribuidos.
Phishing = Engaño para que un usuario entregue sus credenciales o haga clic en un link malicioso que captura tokens o instala malware.
Ejemplo: un email falso de IT pidiendo "verificar tu cuenta" en un sitio que parece legítimo pero captura las credenciales.
Mitigación: MFA resistente a phishing (passkeys/FIDO2), filtros de email, capacitación.
Adversary-in-the-Middle (AiTM) = El atacante actúa como proxy entre el usuario y el servicio legítimo, capturando credenciales y tokens de sesión en tiempo real, incluso con MFA activo.
Ejemplo: herramientas como Evilginx2 actúan como proxy reverso transparente. El usuario completa el MFA con éxito, pero el atacante captura el token de sesión válido.
Mitigación: MFA basado en FIDO2/passkeys (vinculado al dominio), Conditional Access.
Token Hijacking = Robo de un token válido para suplantar al usuario legítimo sin necesitar sus credenciales.
Ejemplo: malware en el equipo roba las cookies de sesión del navegador y las replica desde otro dispositivo.
Mitigación: tokens de vida corta, HTTPS, detección de sesiones desde IPs o dispositivos anómalos.
Privilege Escalation = Obtener más permisos de los asignados, explotando vulnerabilidades del sistema o configuraciones incorrectas de IAM.
Ejemplo: un usuario con permisos básicos descubre que puede asumir un rol de admin por un error en las políticas IAM.
Mitigación: PoLP, revisiones periódicas de políticas, logging de AssumeRole.
MFA Fatigue = El atacante tiene la contraseña de la víctima y genera notificaciones de MFA masivas esperando que el usuario apruebe una por accidente o agotamiento.
Ejemplo: el atacante envía 50 solicitudes de push MFA a las 2am hasta que el usuario, confundido, aprueba una.
Mitigación: MFA resistente a phishing (FIDO2), number matching en notificaciones push, límite de intentos.
Insider Threat = Abuso de acceso legítimo por parte de alguien dentro de la organización: empleado, contratista o ex-empleado.
Ejemplo: un empleado descarga una base de datos completa de clientes antes de renunciar.
Mitigación: SoD, UEBA, PAM, deprovisioning inmediato al desvincularse.
OAuth Abuse / Consent Phishing = Engañar al usuario para que autorice una app maliciosa usando el flujo legítimo de OAuth, obteniendo acceso persistente sin robar contraseñas.
Ejemplo: un email con un link lleva a una pantalla real de Google OAuth pidiendo permisos para una app maliciosa. El usuario la aprueba creyendo que es legítima.
Mitigación: revisar periódicamente OAuth grants, restringir qué apps pueden conectarse.
Kerberoasting = Ataque contra Active Directory que extrae tickets de servicio (TGS) de Kerberos para cuentas de servicio y los rompe offline para obtener contraseñas.
Mitigación: contraseñas largas y aleatorias en cuentas de servicio, usar Managed Service Accounts (gMSA).
Pass-the-Hash / Pass-the-Ticket = Usar el hash NTLM de una contraseña o un ticket de Kerberos robado para autenticarse en otros sistemas sin conocer la contraseña real.
Mitigación: Credential Guard, no reutilizar cuentas admin en múltiples sistemas, monitoreo de autenticaciones laterales.
Zero Trust = Modelo de seguridad que elimina la confianza implícita basada en la red. Asume que la brecha ya ocurrió. Ningún usuario, dispositivo o red es confiable por defecto. Todo se verifica siempre.
Los tres principios de Zero Trust:
- Verificar explícitamente: autenticar y autorizar en base a todos los datos disponibles.
- Usar acceso de menor privilegio: limitar al mínimo necesario, con JIT y políticas dinámicas.
- Asumir la brecha: minimizar el radio de explosión, segmentar, monitorear todo.
Ejemplo: en vez de "si estás en la VPN sos confiable", Zero Trust verifica identidad, estado del dispositivo, ubicación y comportamiento en cada request, sin importar la red.
Conditional Access = Política que define condiciones bajo las cuales se permite, deniega o modifica el acceso. Es la implementación práctica de Zero Trust para el acceso a aplicaciones.
Ejemplo: "si el usuario accede desde un dispositivo no gestionado fuera del país, requerir MFA y solo dar acceso de lectura, sin descargas".
IGA (Identity Governance and Administration) = Plataforma para gestionar identidades a escala empresarial: automatización de provisioning, access reviews, detección de violaciones de SoD, auditoría y cumplimiento normativo.
Ejemplo: una plataforma IGA detecta que un usuario tiene dos roles que violan SoD (puede crear y aprobar pagos) y genera una tarea de remediación automática.
CASB (Cloud Access Security Broker) = Punto de control de seguridad entre los usuarios y los servicios cloud. Proporciona visibilidad y aplica políticas sobre el uso de apps cloud, autorizadas o no.
Ejemplo: un CASB detecta que un empleado sube documentos corporativos a su Dropbox personal y lo bloquea o genera una alerta.
Non-Human Identity (NHI) = Identidades de entidades que no son personas: aplicaciones, APIs, pipelines CI/CD, funciones serverless, bots. Requieren el mismo nivel de seguridad que las identidades humanas.
Ejemplo: una GitHub Action que hace deploy a AWS tiene una identidad (IAM Role). Si tiene permisos excesivos, es un riesgo tan real como una cuenta humana comprometida.
Secrets Management = Gestión segura de credenciales no humanas: API keys, contraseñas de servicios, certificados, tokens, claves de cifrado.
Ejemplo: en vez de hardcodear una API key en el código, la app la obtiene en tiempo de ejecución desde AWS Secrets Manager o HashiCorp Vault, que también la rota automáticamente.
PEP / PDP / PAP = Arquitectura estándar para sistemas de decisión de acceso.
- PEP (Policy Enforcement Point) = intercepta el request y aplica la decisión.
- PDP (Policy Decision Point) = evalúa las políticas y devuelve allow/deny.
- PAP (Policy Administration Point) = gestiona y almacena las políticas.
Ejemplo: un API Gateway actúa como PEP: intercepta el request, consulta al PDP si el usuario tiene permiso, y aplica la decisión.
Device Trust / Device Identity = El dispositivo desde el que se accede también tiene una identidad verificable. Su estado (actualizado, gestionado, compliant) influye en la decisión de acceso.
Ejemplo: Conditional Access requiere que el dispositivo esté registrado en el MDM corporativo y sea "compliant" antes de permitir acceso a aplicaciones.
MDM (Mobile Device Management) = Plataforma para gestionar y aplicar políticas de seguridad en dispositivos móviles y endpoints corporativos.
Ejemplo: el MDM garantiza que todos los celulares corporativos tengan cifrado habilitado, PIN configurado y las últimas actualizaciones de seguridad instaladas.
SCP (Service Control Policy) = En AWS Organizations, políticas que establecen los límites máximos de permisos para cuentas o unidades organizacionales. Actúan como guardrails: aunque una política IAM permita algo, si el SCP lo deniega, queda denegado.
Ejemplo: un SCP que impide que cualquier cuenta de la organización deshabilite CloudTrail, sin importar los permisos del usuario que lo intente.
Permission Boundary = En AWS, política que define el máximo de permisos efectivos que puede tener una identidad. Los permisos reales son la intersección entre los permisos asignados y el boundary.
Ejemplo: una Permission Boundary permite como máximo S3 y DynamoDB. Aunque el rol tenga acceso a EC2 en sus políticas, ese permiso queda bloqueado.
ITDR (Identity Threat Detection and Response) = Disciplina y conjunto de herramientas orientadas a detectar y responder a amenazas específicamente relacionadas con identidades: cuentas comprometidas, escalada de privilegios, movimientos laterales.
Ejemplo: ITDR detecta que una cuenta de servicio legacy que no soporta MFA está siendo usada desde una IP desconocida y genera una alerta de alta prioridad.
Notas en progreso — actualizadas mientras avanzo.