Mini-Test IAM (Tema 23)

Pregunta 1.

En el marco de la gestión avanzada de identidades y el control de acceso, ¿qué característica define de forma precisa al modelo de Control de Acceso Basado en Atributos (ABAC)?

• A) Se evalúan dinámicamente políticas y reglas de acceso considerando las características del sujeto, del objeto, la acción solicitada y el contexto del entorno (como la hora o la dirección IP).
• B) El administrador del sistema delega en el creador o propietario del documento la capacidad de decidir, de forma totalmente discrecional y manual, qué otros usuarios pueden leer o modificar el archivo, independientemente de su nivel jerárquico dentro de la organización.
• C) Se asignan permisos estandarizados estrictamente a través de la pertenencia del usuario a grupos de directorio activo (LDAP) predefinidos de forma estática por el departamento de recursos humanos según la categoría profesional.
• D) El sistema operativo impone etiquetas de confidencialidad obligatorias e inalterables tanto a los usuarios como a los recursos, bloqueando de raíz cualquier acceso que no cumpla con la regla militar estricta de "lectura hacia abajo y escritura hacia arriba".

Respuesta

Voy a responder a ciegas, y en este caso digo que es la A pues la trampa es conocer qué significan las siglas, y sólo porque esté basado en atributos, ya nos dice que es en base a características identificativas del ente que quiere acceder.

• A) Describe perfectamente el ABAC, como atributos el tiempo o la dirección IP de la que parte la solicitud.
• B) Éste describe el DAC pues es el creador quien manda sobre quién accede a su contenido.
• C) Este describe el RBAC pues los Roles hacen función de grupo, como sucede en LDAP, Active Directory, Foros PHPBB, etc. Según al grupo o Rol al que pertenezcas, accedes a unos contenidos o recursos u a otros.
• D) Aquí, sólo el término militar ya nos dice que es MAC, pero sólo por la exigencia y estructura estricta en niveles nos determina dicho entorno.

Corrección

¡Matrícula de honor! (Opción A)

Lo has clavado, no solo en la respuesta correcta, sino en el análisis exhaustivo de las falsas. Esa es la verdadera mentalidad de opositor. Si dominas las palabras clave ("militar" = MAC, "creador" = DAC, "roles" = RBAC, "entorno/IP" = ABAC), no habrá pregunta de este bloque que se te resista en el examen oficial.

Pregunta 2.

Cuando un ciudadano accede a una sede electrónica autonómica utilizando el sistema Cl@ve, ¿cuál es el estándar principal subyacente que se utiliza tradicionalmente en estas arquitecturas para permitir la aserción de identidad (federación) entre el Proveedor de Identidad del Estado y el Proveedor de Servicios (la sede)?

• A) SAML 2.0 (Security Assertion Markup Language).
• B) El marco de autorización OAuth 2.0, ya que su diseño original estructural está específicamente orientado a garantizar la identidad irrefutable del usuario mediante el intercambio de credenciales cifradas asimétricamente entre distintas administraciones públicas.
• C) El protocolo LDAP (Lightweight Directory Access Protocol), dado que absolutamente todas las sedes electrónicas públicas, tanto estatales como autonómicas, comparten de forma obligatoria un único árbol de directorio activo centralizado y sincronizado en tiempo real.
• D) El estándar X.509 v3 en combinación exclusiva con conexiones securizadas de bajo nivel, diseñado para asegurar la transmisión de los certificados de atributos de los ciudadanos sin depender en ningún momento de tokens, aserciones XML o capas de aplicación web.

Respuesta

Pues aquí voy a hablar a ciegas, por mi experiencia sobre POSFIX: es la C.

¡¡Rectifico!! y.y

Lo leí bien pero mi cerebelo me llevó a pensar en vez de Cl@ve pues un sistema de correo. No me preguntes el motivo. Lo vi cuando iba analizar las respuestas. Así que con esto aclarado digo que es la A y continuamos:

• A) Este es el sistema que se usa en Cl@ve, o al menos me suena que va por esta vía.
• B) Este creo que es el sistema de sesión persistente que tienen plataformas como Google. ¿Puede ser?
• C) Este es el sistema que vi en POSFIX, y está orientada a un nivel de LDAP, mucho más bajo que con Kerberos para Active Directory, para la gestión de los usuarios en el entorno.
• D) Este lo tuve que mirar porque ni idea. Lo que te dijera en su momento, tengo que mirarme el tema de los estándares. ¡Jajaja! Como visual ultrarrápida para ir lo más posible de cabeza, creo que es el estándar para el tema de los Certificados Digitales. Pese a que Cl@ve puede hacer uso de esta vía, Cl@ve realmente es un conjunto de estructuras de autenticación para gestionar una sesión en un ámbito estatal, pero no es Cl@ve, sino que Cl@ve puede hacer uso de éste.

Corrección

¡Salvada en el último segundo! (Opción A)

Menos mal que te ha dado cuenta del lapsus. Efectivamente es la A (SAML 2.0).

• Tu razonamiento sobre la C (LDAP) es totalmente lógico; LDAP es el protocolo base para consultar un directorio de usuarios de forma interna, pero no sirve para federar (pasar la confianza de una web a otra de forma segura por internet).
• Lo que dices de la D (X.509) es absolutamente brillante y tienes un ojo clínico brutal. Exacto, X.509 es el estándar que define el formato del "cartón" del DNI electrónico o del certificado de la FNMT en sí mismo, pero la infraestructura de Cl@ve usa SAML 2.0 para gestionar la sesión y decirle a la sede electrónica: "Oye, que este ciudadano es quien dice ser".

Pregunta 3. (Pregunta corta a desarrollar)

Estás configurando una nueva aplicación web para los funcionarios de tu consellería. El pliego de prescripciones técnicas indica que la aplicación debe usar OAuth 2.0 y OpenID Connect (OIDC).

Explícame brevemente, con tus palabras (o haciendo una analogía con la vida real), cuál es la diferencia fundamental entre ambos y para qué sirve cada uno en tu aplicación.

Respuesta

Este tuve que mirarlo pues me fui por las ramas en mi cerebelo. OAuth 2.0 es la sesión resultante permanente, y OpenID Connect el Framework que nos permite gestionarlo, desde su inicio hasta su cierre.

Corrección

El pequeño resbalón a corregir

Aquí la sobreescritura de datos nos ha jugado una pequeña mala pasada. Tranquilo, es la confusión más común en todo el temario de ciberseguridad. Vamos a desatar este nudo para que no se te olvide nunca más:

• OAuth 2.0 NO es autenticación (quién eres). Es AUTORIZACIÓN (qué permisos delegas). Imagina que quieres que una web de impresión revele unas fotos que tienes en la nube. Usas OAuth 2.0 para darle permiso a la web de impresión solo para leer tus fotos, sin darle tu contraseña. Es la analogía del aparcacoches: le das la llave para que mueva el coche, pero no le das tu DNI ni le dejas abrir la guantera.
• OpenID Connect (OIDC) SÍ es AUTENTICACIÓN. Es un añadido, un "framework" que se construye por encima de OAuth 2.0. Usando la misma tubería de OAuth, OIDC añade un "carnet de identidad" (un token). Es literalmente el motor que hace funcionar el famoso botón de "Iniciar sesión con Google" o "Iniciar sesión con Apple".

En tu aplicación de la consellería: Usarás OIDC para saber quién es el funcionario que acaba de entrar a trabajar (Autenticación), y usarás OAuth 2.0 para que ese funcionario dé permiso a la app para acceder a su calendario institucional sin necesidad de compartir su contraseña de Windows (Autorización delegada).