CompTIA SY0-701: Gestión de Identidad y Acceso — Guía de estudio

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Forma parte de la CompTIA Security+ SY0-701 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de CompTIA, o realiza tests cronometrados en ExamRoll.io.

La Gestión de Identidad y Acceso (IAM) es la disciplina que garantiza que los sujetos correctos (usuarios, servicios y dispositivos) obtengan el acceso adecuado a los recursos correctos en el momento oportuno, y solo durante el tiempo necesario. Se basa en dos pilares conceptualmente distintos que con frecuencia, y peligrosamente, se confunden: la autenticación, que demuestra quién es un sujeto, y la autorización, que determina qué puede hacer ese sujeto autenticado. Un usuario que inicia sesión en una estación de trabajo con su huella dactilar se ha autenticado; si ese usuario puede abrir la base de datos de nóminas es una cuestión de autorización. Cualquier diseño de control que desdibuje la diferencia entre ambos invita a una brecha de seguridad.

Factores de Autenticación y Autenticación Multifactor

Los factores de autenticación se agrupan tradicionalmente en cinco categorías: algo que sabes (contraseñas, PIN), algo que tienes (tarjetas inteligentes, tokens de hardware, teléfonos con aplicaciones TOTP), algo que eres (huella dactilar, retina, geometría facial), un lugar donde estás (geolocalización o contexto basado en la red) y algo que haces (biometría conductual como la cadencia de tecleo). La autenticación multifactor (MFA) requiere evidencia de al menos dos categorías diferentes. Una contraseña combinada con una pregunta de seguridad no es MFA, ya que ambos son “algo que sabes”. Una contraseña combinada con un código TOTP de Google Authenticator sí es MFA.

Los tokens de hardware se presentan en varias formas. Las llaves de seguridad FIDO2/WebAuthn como las YubiKeys utilizan criptografía asimétrica: la clave privada nunca abandona el dispositivo y el servidor solo almacena una clave pública, lo que frustra los ataques de phishing y de repetición. Los tokens HOTP generan contraseñas de un solo uso a partir de un contador; los tokens TOTP las generan a partir de la hora actual utilizando una construcción HMAC-SHA1:

TOTP = HMAC-SHA1(shared_secret, floor(current_unix_time / 30))

Las tarjetas inteligentes, comúnmente tarjetas PIV o CAC en entornos gubernamentales, almacenan un certificado X.509 y una clave privada en un chip resistente a la manipulación. La presentación de la tarjeta, combinada con un PIN, satisface dos factores y permite la autenticación basada en certificados en sistemas como Active Directory a través de Kerberos PKINIT.

La MFA es el control individual más eficaz contra el robo de credenciales. Cuando los usuarios informan de inicios de sesión desde direcciones IP que no originaron, restablecer las contraseñas ataca el síntoma; exigir la MFA ataca la causa raíz, porque una contraseña robada por sí sola se vuelve insuficiente.

Inicio de Sesión Único y Federación

El inicio de sesión único (SSO) permite a un usuario autenticarse una vez y acceder a múltiples aplicaciones sin volver a introducir sus credenciales. La Federación extiende este concepto a través de fronteras organizativas o de confianza: el proveedor de identidad (IdP) de un usuario en un dominio responde por el usuario ante un proveedor de servicios (SP) en otro. El error más común aquí es tratar SAML y OAuth como si fueran intercambiables; resuelven problemas diferentes.

SAML 2.0 es un protocolo basado en XML diseñado para el SSO empresarial y las aserciones de autenticación. Cuando un usuario solicita una aplicación SaaS, el SP redirige el navegador al IdP, que autentica al usuario y devuelve una aserción SAML firmada que contiene atributos de identidad. Este es el mecanismo estándar para permitir que los empleados accedan a aplicaciones en la nube como Salesforce o Workday utilizando las credenciales corporativas de Active Directory.

OAuth 2.0 es un marco de autorización, no un protocolo de autenticación. Otorga a una aplicación de terceros acceso delegado a un recurso en nombre del usuario a través de tokens de acceso. Permitir que una aplicación publique en tu feed de Twitter es un flujo de OAuth. OpenID Connect (OIDC) es una capa de identidad construida sobre OAuth 2.0 que añade un id_token (un JWT) que proporciona aserciones de autenticación; esto es lo que hace posible el “Iniciar sesión con Google”.

Una trampa crítica: el SSO y la federación reducen la proliferación de credenciales, pero no eliminan la necesidad de MFA. De hecho, concentran el riesgo: una sola credencial de SSO comprometida ahora desbloquea todas las aplicaciones federadas. La MFA debe exigirse en el IdP, y las cuentas con privilegios deberían requerir una autenticación escalonada (“step-up”) incluso después del SSO.

Modelos de Control de Acceso

Una vez establecida la identidad, un modelo de control de acceso rige las decisiones de autorización. El Control de Acceso Discrecional (DAC) permite a los propietarios de los recursos establecer permisos, generalmente a través de listas de control de acceso (ACLs). El Control de Acceso Obligatorio (MAC) impone políticas de forma centralizada basándose en etiquetas y niveles de autorización (“clearances”), algo común en sistemas militares e implementado por marcos como SELinux. El Control de Acceso Basado en Roles (RBAC) asigna permisos a roles y usuarios a roles: un rol de “Analista de Facturación” conlleva un conjunto de permisos definido, y los usuarios heredan los permisos por su pertenencia al rol. El Control de Acceso Basado en Atributos (ABAC) evalúa políticas en función de los atributos del sujeto, el recurso, la acción y el entorno, lo que permite reglas como “permitir el acceso de lectura a los archivos de RR. HH. solo durante el horario laboral desde dispositivos gestionados por la empresa”.

Superpuesto a cada modelo está el principio de privilegio mínimo: los sujetos reciben únicamente el acceso mínimo necesario para realizar su función, y nada más. Como complemento está la separación de funciones, que impide que un solo individuo controle un proceso sensible en su totalidad: la persona que solicita un pago no debería ser también quien lo aprueba.

Los controles de acceso prácticos incluyen ACLs de sistema de archivos, ACLs de red en routers y firewalls, y restricciones horarias que permiten el inicio de sesión solo durante las horas autorizadas. Una entrada de ACL de Windows que concede acceso de solo lectura a un recurso compartido de finanzas podría verse así:

icacls C:\Finance /grant "Domain\Finance-RO:(OI)(CI)R"

Gestión de Acceso Privilegiado

Las cuentas con privilegios (administradores de dominio, root, administradores de sistemas de bases de datos, cuentas raíz de la nube, cuentas de servicio) son las joyas de la corona de cualquier entorno. La Gestión de Acceso Privilegiado (PAM), con sistemas como CyberArk, BeyondTrust o HashiCorp Vault, impone controles sobre estas cuentas: las credenciales se guardan en una bóveda (vaulted) y se rotan automáticamente, las sesiones se graban, el checkout (la solicitud de uso) requiere una justificación y a menudo aprobación, y las contraseñas son frecuentemente de un solo uso o efímeras.

El acceso Just-in-Time (JIT) eleva los privilegios solo durante el tiempo que dura una tarea específica, eliminando los derechos de administrador permanentes. Un desarrollador que necesita ejecutar una migración de base de datos recibe una credencial con un tiempo limitado que expira automáticamente después de 30 minutos; no existe una cuenta privilegiada persistente que pueda ser robada. Privileged Identity Management (PIM) en Azure AD implementa este patrón de forma nativa, exigiendo flujos de trabajo de aprobación y una nueva autenticación con MFA antes de la elevación de privilegios.

Las cuentas de servicio presentan un desafío particular. A menudo tienen privilegios excesivos, sus contraseñas rara vez se rotan y su uso casi nunca se audita. Las Cuentas de Servicio Administradas (MSAs) y las Cuentas de Servicio Administradas de Grupo (gMSAs) en Active Directory automatizan la rotación de contraseñas y eliminan por completo la necesidad de que los humanos conozcan las credenciales de las cuentas de servicio.

Servicios de Directorio y Aprovisionamiento

Active Directory (AD) sigue siendo el almacén de identidades (identity store) on-premises dominante. Los usuarios, equipos y grupos se organizan en Unidades Organizativas (OUs), y los Objetos de Directiva de Grupo (GPOs) aplican configuraciones y ajustes de seguridad de forma jerárquica. Las relaciones de confianza (trusts) de AD extienden la autenticación a través de dominios y bosques. Azure Active Directory (Entra ID) extiende estos conceptos a la nube, añadiendo políticas de acceso condicional, puntuación de riesgo para la protección de la identidad e integración transparente con miles de aplicaciones SaaS.

LDAP (Lightweight Directory Access Protocol) es el protocolo subyacente para consultar los servicios de directorio. RADIUS centraliza la autenticación para el acceso a la red: la autenticación para VPN, Wi-Fi y redes cableadas con 802.1X se realiza comúnmente contra un servidor RADIUS respaldado por AD. TACACS+ cumple una función similar para la administración de dispositivos de red, con el beneficio añadido de separar la autenticación, la autorización y la contabilidad (accounting) en fases distintas.

El aprovisionamiento y desaprovisionamiento de usuarios debe estar estrechamente vinculado a los procesos de RR. HH. El fallo más persistente en IAM es la cuenta huérfana: una cuenta de Active Directory de un exempleado que permanece activa semanas o meses después de su salida. El aprovisionamiento automatizado a través de SCIM (System for Cross-domain Identity Management) o conectores de RR. HH. a AD, combinado con listas de verificación (checklists) de desaprovisionamiento obligatorias, cierra esta brecha.

Escenario Práctico: Credenciales Comprometidas a través de una Cuenta Huérfana

El equipo de TI de una empresa de manufactura descubrió un acceso inusual fuera del horario laboral a su sistema ERP desde una cuenta de servicio que había sido creada para un proyecto de integración ya descontinuado. La cuenta tenía derechos de usuario de dominio y nunca había sido revisada durante las revisiones de acceso trimestrales porque no estaba asociada a un empleado con nombre. Un atacante que había comprado las credenciales en un volcado de datos (dump) de la dark web usó la cuenta para enumerar recursos compartidos de archivos, exfiltrar datos de precios y establecer una persistencia (foothold) a través de una tarea programada. La brecha de seguridad solo se descubrió cuando el proveedor del ERP marcó patrones anómalos en las llamadas a la API. La causa raíz fue un proceso de desaprovisionamiento fallido: la integración se dio de baja, pero la cuenta nunca se deshabilitó. Implementar un sistema PAM con descubrimiento automatizado de cuentas huérfanas y ciclos de revisión obligatorios habría sacado a la luz la cuenta mucho antes de que fuera explotada.

← Gobernanza · Todos los dominios · Amenazas →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →