Máster Interuniversitario en Seguridad de las TIC (MISTIC)
Identidad Digital – 2on semestre, Curso 2019/2020
Primera Prueba de Evaluación Continuada (PEC1)
Ejercicio 1 (2.5 puntos)
Actualmente la autenticación mediante contraseña es el método más utilizado para permitir el
acceso a los servicios remotos. La seguridad de este método depende de varios factores: la
propia contraseña, cómo se envía, cómo se verifica, cómo el sistema remoto lo almacena, cómo
se gestiona el acceso a las contraseñas, el acceso a las copias de seguridad, etc. En este caso
nos centraremos en estudiar posibles ataques y soluciones en la gestión de las contraseñas.
Responde las siguientes preguntas:
a) (0,75 puntos) Asumiendo que tenemos un sistema que implementa un mecanismo de “Shadow
Passwords”, explica brevemente en qué consisten los siguientes ataques contra la seguridad de
las contraseñas (Password Cracking) comentando las ventajas y desventajas de cada uno de
ellos:
(1) ataque de fuerza bruta
Este tipo de ataques consiste en prueba y error, probando varias combinaciones hasta lograr la
correcta, creando diccionarios con palabras de uso común.
Ventajas: una posible ventaja de la utilización de este método seria que los usuarios
generalmente no usan contraseñas con un alto grado de complejidad.
Desventajas: en este método hay varias desventajas, puesto que para el descifrado de
contraseñas se tiene:
• El que un sistema bloque un usuario de manera temporal por intento fallido.
• Limitar una longitud mínima de la contraseña.
• La exigencia a los usuarios la creación de claves complejas.
(2) ataque de diccionario
Consiste en crear de diccionarios de palabras conocidas, incluso en diferentes idiomas, para ser
probadas de manera consecutiva para tratar de romper barreras de acceso a un sistema.
Ventajas: como lo dicho en los ataques de fuerza bruta, la mayor desventaja es el usuario, ya que
a este le resulta muy difícil recordar contraseñas de alta complejidad.
1 de 17
Desventajas:
• Si la contraseña es de alta complejidad este método puede tardar desde horas, a días y
hasta años en descifrar la contraseña.
• La utilización de captchas para que el usuario demuestre si es humano y no un programa.
(3) ataque de lookup table
Es una tabla que almacena un par, que son una palabra inicial y una final, tablas creadas
especialmente para hallar coincidencias de un hash como resultado de aplicar una función
resumen.
Ventajas:
• Sencillo y rápido, esto depende de la complejidad de la contraseña.
• Usada para verificar la robustez de las contraseñas ingresadas por los usuarios.
Desventajas:
• Cuanto mayor es la tabla, mayor probabilidad de colisión, y menor el número de
contraseñas cubiertas.
• Si la longitud de la contraseña es grande la probabilidad de que se descifre es enorme,
esto es usar contraseñas robustez.
b) (0,75 puntos) Explica qué es una “Rainbow Table” y qué ventajas ofrece su utilización.
Proporciona un ejemplo sencillo de cómo encontraríamos una cierta contraseña a partir de un
cierto hash usando una “Rainbow Table”. Para simplificar, ahora suponed que la Rainbow Table
de un atacante no tiene colisiones y cada contraseña válida se encuentra almacenada una sola
vez en la tabla. Asumiendo que cada contraseña ocupa 8 bytes, deriva una ecuación para el
número total de bytes que ocuparía la tabla, en función de la longitud de la cadena k y el número
posible de contraseñas N.
Es una tabla que almacena un par, una palabra al inicio y otra al final, que permite almacenar de
una forma óptima el resultado previamente calculado de la generación de claves y su hash. La
ventaja de su utilización puede ser para medir la robustez de la seguridad de las claves de los
usuarios.
Ejemplo “Rainbow Table”:
Tenemos la siguiente tabla.
c1 h1 c2 h2 c3 h3
20 0719 19 1484 84 1824
21 1956 56 1215 15 0539
22 1192 92 1712 12 0832
23 0428 28 0607 7 0651
24 1664 64 1104 4 0944
Si tomamos palabra inicial y final nos queda.
2 de 17
c1 h3
20 1824
21 0539
22 0832
23 0651
24 0944
Por lo tanto si tomamos el valor conocido de una clave fuese 1712, el valor no está en la tabla si
realizamos la operación hash reducción a este valor podríamos encontrar la clave de 1712.
Entonces se aplica la reducción a 1712 no da el resultado 12, a este valor aplicamos hash nos
daría el resultado 0832 que ya es un valor conocido en la tabla por tanto el ya sabemos que el
valor que buscamos estaría en la fila 22, así tenemos el punto de partida, si hacemos hash a 22
no da el valor de 1192 si aplicamos la reducción nos daría 92 si aplicamos hash nos daría 1712,
por lo tanto encontraríamos el valor de la clave que seria 92.
Asumiendo que cada contraseña ocupa 8 bytes, deriva una ecuación para el número total de
bytes que ocuparía la tabla, en función de la longitud de la cadena k y el número posible de
contraseñas N.
Si 8 bytes ocupa una contraseña entonces:
N= 2^64 = 1.8*10^19 claves
La longitud de la cadena tomando en cuenta que el tamaño del hash sería de 8 bytes.
Entonces:
k=(1.8*10^19) * (1.8*10^19)=3.24*10^19 bytes
c) (0,5 puntos) Para acabar, explicad en qué consiste la técnica de Key Stretching y comentad
en detalle el funcionamiento del algoritmo PBKDF2. Una vez entendido su funcionamiento,
suponed que la función de hashing empleada por el algoritmo PBKDF2 es la función SHA-1, que
devuelve 20 bytes de salida. Ahora imaginad que queréis proteger una contraseña. Contestad a la
siguiente pregunta:
La técnica de Key Stretching, consiste en aplicar el algoritmo PBKDF2, para estirar una clave de
baja longitud que el usuario la ingreso, esto evita que por ejemplo ataques de fuerza bruta tengan
éxito.
¿Qué sería más seguro?
• Alternativa-1: Ejecutar el algoritmo PBKDF2 durante 100 iteraciones, generando una
contraseña protegida de 200 bytes.
• Alternativa-2: Llamar al algoritmo PBKDF2 durante 1000 iteraciones, manteniendo el
tamaño de la contraseña protegida en solo 20 bytes (SHA-1).
La alternativa 2 ya que a mayor número de iteraciones como pueda tolerar el servidor, para mejorar
la seguridad, por otra parte para que esto surta efecto tiene que ir de la mano una buena política de
contraseñas.
d) (0,5 puntos) Aunque el uso de contraseñas es un método muy simple para verificar la identidad
de un usuario, la realidad es que es un mecanismo extremadamente débil; a modo de ejemplo, un
3 de 17
usuario no autorizado puede fácilmente averiguar la contraseña de otro usuario mediante ataques
de diccionario en muchos sistemas. Para paliar este déficit, muchas aplicaciones emplean
sistemas de autentificación multifactor (MFA). Primero, explique en qué consiste la autentificación
multifactor (MFA). Segundo, comente brevemente qué tipo de soporte MFA ofrece Amazon Web
Services (AWS).
Es un sistema que requiere más de una forma de autenticación para verficar la identidad de un
usuario, el objetivo es una defensa por capas y hacer más difícil el ingreso no autorizado de un
intruso.
Por ejemplo, una persona desliza una tarjeta e ingresa un PIN, otra es cuando se ingresa un clave
y el sistema envía un sms al número de celular ingresado para este proceso.
El soporte que ofrece Amazon Web Services (AWS), se radica en un YubiKey (YubiKey es un
dispositivo de autenticación de hardware que admite contraseñas de un solo uso, criptografía de clave
pública y autenticación) como MFA.
AWS le pedirá su nombre de usuario y contraseña (el primer factor: lo que conoce), así como un
desafío de autenticación para su YubiKey (el segundo factor: lo que tiene) cuando inicie sesión en
la consola de administración de AWS. Puede completar el desafío de autenticación correctamente
solo con tocar el botón o disco dorado en su YubiKey.
4 de 17
Ejercicio 2 (2.5 puntos)
Como se ha visto, la autenticación mediante contraseña es el método más utilizado para permitir
el acceso a los servicios remotos. La seguridad de este método depende de varios factores: la
propia contraseña, cómo se envía, cómo se verifica, cómo el sistema remoto lo almacena, cómo
se gestiona el acceso a las contraseñas, el acceso a las copias de seguridad, etc.
a) (0,5 puntos) Actualmente la mayoría de los sistemas utilizan el mecanismo de "Shadow
Passwords" para garantizar la seguridad de las contraseñas. Explicad brevemente como funciona
este mecanismo. Además, comentad en que consisten el “salt” y el “pepper” (usados juntamente
con el mecanismo de “shadow passwords”) y cómo se utilizan para evitar ataques basados en
lookup tables o rainbow tables.
El mecanismo de "Shadow Passwords", especialmente utilizadas en Unix de manera que ya se
crea un fichero con claves ocultas estas no están abiertas al público como en sistemas antiguos
de linux por ejemplo: /etc/passwd que es legible para todos, en las nuevas distribuciones de linux
incluye el fichero /etc/shadow que solo puede leer el usuario root (super administrador de linux).
El “salt” y el “pepper” consiste en una clave se encripta con un salt, esto es que aparte de un hash
el salt realiza un hash del pasword.
El “pepper” este interviene dificultando el ataque de fuerza bruta, sobre todo si es acompañado
por el salt, a diferencia del salt este se almacena separado en un lugar más seguro.
Ahora nos centraremos en la seguridad de las contraseñas en sí y para ello, habrá que realizar las
siguientes actividades suponiendo que disponemos del siguiente alfabeto de 81 caracteres:
• Alfabeto: a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D
E F G H I J K L M N O P Q R S T U V W X Y Z 1 2 3 4 5 6 7 8 9 0 $ %
& / = + @ # - ; ( ) ? ¿ ¡ [ ] ^ _
Usaremos el script adjuntado con la PEC (hay que darle permisos de ejecución). Este script
permite realizar un ataque de fuerza bruta para encontrar una contraseña de tres caracteres sobre
el alfabeto anteriormente indicado. El programa tiene como 1er parámetro de entrada el "Salt" y
como 2o parámetro el hash de la contraseña.
Por ejemplo: ./script Zx ZxQHKS9g1v2kU
Dará como salida: acb
IMPORTANTE: Este “script” se tiene que ejecutar (habrá que añadir permisos de ejecución) en
una consola de comandos y utiliza "OpenSSL". En Debian esta herramienta ya está instalada por
defecto.
Responded a las siguientes preguntas:
b) (0,5 puntos) Ejecutad el script proporcionado para encontrar la contraseña de la tarea b.1
usando el alfabeto proporcionado e indicad el tiempo empleado. Para calcular el tiempo se
recomienda utilizar el comando “time” y el valor “user” que este comando proporciona.
Posteriormente modificad el script proporcionado para encontrar la contraseña de 4 caracteres de
la tarea b.2. En este último caso, explicad qué habéis hecho y adjuntad el código del script
modificado.
Tarea Número de Salt Hash Contraseña Contraseña Tiempo
Caracteres
b.1 3 XY XY3cF1R3ZfMzQ UnO 17m34.613s
b.2 4 YZ YZjATSX1nDk.s TrEs 362m49.749s
5 de 17
El scritp se modificó de la siguiente manera:
#script de ataque de fuerza bruta de 4 caracteres
#!/bin/bash
space1="a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U
V W X Y Z 1 2 3 4 5 6 7 8 9 0 $ % & / = + @ # - ; ( ) ? ¿ ¡ [ ] ^ _"
if [ $# -le 1 ]
then
echo "Usage: " $0 SALT PASSWORD_CODED
exit
fi
for i in $space1
do
for j in $space1
do
for k in $space1
do
for l in $space1
do
variable=$(openssl passwd -crypt -salt "$1" "$i$j$k$l")
if [ "$variable" = $2 ]
then
echo password found: $i$j$k$l
exit
fi
done
done
done
done
c) (0,5 puntos) Calculad todas las combinaciones posibles que se deberían comprobar para
encontrar contraseñas de 3, 4, 5, 6, 7 y 8 caracteres asumiendo el alfabeto anteriormente
indicado. Además, estimad el tiempo que sería necesario para realizar todas esas
comprobaciones en (a) la máquina utilizada y (b) un supercomputador. Comentad los resultados
obtenidos.
Para 3: 531441 combinaciones
Para 4: 43046721 combinaciones
Para 5: 3486784401 combinaciones
Para 6: 282429536481 combinaciones
Para 7: 2.2876792e+13 combinaciones
Para 8: 1.8530202e+15 combinaciones
(a) La máquina utilizada para 3 y 4 caracteres fue un servidor con distribución Ubuntu Linux
14.04.2 con un procesador Intel(R) Xeon(R) CPU E5430 @ 2.66GHz, 4 núcleos, con memoria
de 4 GB
Tiempo para 3 caracteres fue de 17m34.613s
Tiempo para 4 caracteres fue de 362m49.749s
Tiempo estimado para 5 caracteres es de 488 horas 42 minutos
Tiempo estimado para 6 caracteres es de 39584 horas 42 minutos
6 de 17
Tiempo estimado para 7 caracteres es de 3206360 horas 38 minutos
Tiempo estimado para 8 caracteres es de 259715218 horas 15 minutos
b) Un supercomputador:
Trinity - Cray XC40, Xeon E5-2698v3 16C 2.3GHz, Intel Xeon Phi 7250 68C 1.4GHz, Aries
interconnect, Cray/HPEDOE/NNSA/LANL/SNL United States, 979.072 núcleos, de 20158.7
TFlop/s.
La comparación seria en el número aproximada de combinaciones.
[Link] combinaciones en 17m34.613s
1.053646e+13 combinaciones en 362m49.749s
8.5345324e+14 combinaciones en 488 horas 42 minutos
6.9129713e+16 combinaciones en 39584 horas 42 minutos
5.5995066e+18 combinaciones en 3206360 horas 38 minutos
4.5356005e+20 combinaciones en 259715218 horas 15 minutos
d) (1 punto) Modificad el script para encontrar las dos contraseñas de 8 caracteres que se indican
en la tabla que viene a continuación. Explicad qué habéis hecho y adjuntad el código del script
modificado. Aviso: No se admitirán soluciones que usen herramientas de terceros ya
existentes como el password cracker “john the ripper” o similar.
Tarea Número de Salt Hash Contraseña Contraseña Tiempo
Caracteres
d.1 8 ab abM7jk8UhwkF. *7¡Vamos! 898m47.462s
d.2 8 ba batEx7yN5Rua.
El scritp se modifico de la siguiente manera:
#script de ataque de fuerza bruta de 3 caracteres
#!/bin/bash
if [ $# -le 1 ]
then
echo "Usage: " $0 SALT PASSWORD_CODED
exit
fi
while read line
do
variable=$(openssl passwd -apr1 -salt "$1" "$i$j$k$l$m$n$o$p")
if [ "$variable" = $2 ]
then
echo password found: $i$j$k$l$m$n$o$p
exit
fi
echo -e "$line\n"
done < [Link]
7 de 17
Ejercicio 3 (2.5 puntos)
El control de acceso basado en roles (RBAC) es utilizado en la actualidad por la mayor parte de las
empresas con más de 500 empleados. Es muy versátil y contrasta con la rigidez de los métodos
tradicionales de control de acceso, que conceden o revocan el acceso de los usuarios objeto por
objeto. En RBAC, se pueden añadir, modificar y eliminar roles de forma dinámica a medida que
evolucionan las necesidades de la empresa, sin tener que actualizar individualmente los privilegios
para cada usuario. El propósito de este ejercicio es entender cómo funciona RBAC.
Debido a la proliferación de múltiples implementaciones de RBAC en la industria, el NIST inició un
proceso de estandarización de RBAC que culminó en 2004 en la aprobación de un estándar por el
International Committee for Information Technology Standards (INCITS).
Para realizar este ejercicio, nos basaremos en el modelo original de RBAC propuesto por Sandhu
et al. conocido como RBAC-96 (“Role -based access control models”, IEEE Computer 29 (2): 38-
47, Feb. 1996). En este esquema, se proponen cuatro modelos de referencia RBAC, cada uno de
ellos incrementando el número de requisitos y propiedades:
• RBAC0 — modelo básico;
• RBAC1 — RBAC0 + jerarquías de roles;
• RBAC2 — RBAC0 + restricciones incluyendo exclusividad;
• RBAC3 — RBAC1 + RBAC2;
Siendo RBAC3 la implementación más completa.
a) (0.5 puntos) Describid brevemente cada uno de los cuatros modelos de referencia e indicad sus
diferencias.
RBAC0 modelo básico.- Incluye a usuarios, rol y competencia, donde el rol es múltiple, el usuario
es el operador de un sistema o programa.
El rol es un puente entre usuarios y competencias, cada usuario puede tener más de un privilegio o
permiso al mismo tiempo, una conexión de usuarios con múltiples funciones, entonces un usuario
tiene múltiples permisos para múltiples roles.
RBAC1 — RBAC0 + jerarquías de roles.- refleja una estructura jerárquica de una organización, este
diseño permite agrupar y clasificar roles lo que significa de alguna manera la gestión de autoridad.
Las relaciones entre roles puede dividirse en relaciones generales de sucesión y relaciones de
sucesión restringida.
RBAC2 — RBAC0 + restricciones incluyendo exclusividad.- En donde existen políticas de alto
nivel dando :
Exclusividad de roles.-
• Un usuario solo un rol, permisos a un solo rol.
• Varios usuarios con diferentes roles no comparten permisos.
Cardinalidad.-
• Número máximo de usuarios por rol, roles a usuario, permisos a roles.
8 de 17
Prerrequisitos.-
• Roles prerrequisitos.
• Atender que RBA2 no aplica jerarquía.
RBAC3 — RBAC1 + RBAC2.- Consolidado es una gestión de la autoridad más completa, se basa
en la suma de todos los modelos anteriores, el administrador asigna roles directamente a grupo de
usuarios, cada usuario del grupo puede tener el rol, también al salir se eliminan automáticamente
todos los roles del usuario sin gestión manual del administrador.
De acuerdo al grupo de usuarios, puede dividirse en grupos de usuarios de arriba a abajo y grupos
de usuarios ordinarios.
Grupos de usuarios con relaciones jerárquicas superiores.- Un ejemplo es departamento y el puesto.
Grupo general.- Sin jerarquía la estructura orgánica no es importante, significa que puede haber una
división, cargos varios.
b) (0.5 puntos) Suponed la siguiente asignación de usuarios a roles y de permisos a roles:
Rol Permiso
Usuario Rol ADM (crear, base de datos)
Sally Administrador (ADM) ADM (borrar, base de datos)
Bob Auditor (AUT), usuario (USR) ADM (borrar, tablas)
Harry Analista (ANA), usuario (USR) ADM (modificar, tablas)
Eve Usuario (USR) AUT (auditar, base de datos)
AUT (registrar, consulta)
AUT (copiar, base de datos)
ANA (combinar, tablas)
ANA (crear, procedimiento almacenado)
ANA (eliminar, procedimiento almacenado)
ANA (cancelar, consulta)
USR (ejecutar, procedimiento almacenado)
USR (ejecutar, consulta)
Escribid la matriz resultante de control de acceso. Muy brevemente, recordad que una matriz de
control de acceso es una matriz que describe los “permisos” de los “sujetos” (usuarios y procesos)
sobre los “objetos”. Esto es, cada fila corresponde con un “sujeto” y cada columna con un “objeto”.
Dada una matriz de control de acceso M, cada celda de la matriz contiene los “permisos” px,…,py
que el “sujeto” si tiene sobre el “objeto” oj, esto es, M[si, oj] = {px, py, …, pz}.
Objeto ADM AUT ANA USR
Sujeto
Sally crear, borrar, base de datos
borrar y modificar tablas
Bob auditar y copiar, base ejecutar, procedimiento almacenado
de datos ejecutar consulta
registrar, consulta
Harry combinar, tablas ejecutar, procedimiento almacenado
crear, almacenar ejecutar, consulta
procedimiento
almacenado
cancelar,
consulta
9 de 17
Eve ejecutar, procedimiento almacenado
ejecutar consulta
c) (0,5 puntos) En la práctica muchas operaciones son comunes para un gran número de roles.
Para simplificar el proceso de asignación de roles, RBAC1 introdujo el concepto de jerarquía de
roles. Considerad la siguiente jerarquía de roles (Diagrama de Hasse) y sus respectivas
asignaciones de permisos a roles:
Nefrólogo (N) Cardiólogo (C)
Rol Permiso
P P1 — (leer, historia clínica)
Especialista (E) Infermero (I) E P2 — (diagnosticar, paciente)
Herencia
E P3 — (recetar, medicinas)
I P4 — (suministrar, medicinas)
Profesional Salud (P) E P5 — (ordenar, pruebas diagnósticas
específicas)
N P6 — (tratar, insuficiencia renal)
C P7 — (tratar, infarto de miocardio)
Dada la siguiente asignación de usuarios a roles: (Alice, I), (Carlos, P), (Steve, N), (Hiroki, C),
indica con una “X” qué permisos tiene cada usuario en la siguiente matriz:
P1 P2 P3 P4 P5 P6 P7
Alice X
Carlos X
Steve X X X X
Hiroki X X X X
d) (0.5 puntos) La “Separación de Deberes” (“Separation of Duties”) es una clase de
restricciones a las actividades humanas que impiden que un solo usuario realice la ejecución de
todas las tareas críticas. La "Separación de Deberes" puede ser dos tipos: estática o dinámica.
Comente cuáles son las diferencias principales existentes entre ambos tipos de restricciones y
ponga un ejemplo de cada uno.
Estática: Define entrega de roles que son mutuamente excluyentes, que le mismo usuario no sea
juez y parte de la misma operación o transacción.
Por ejemplo, RBAC puede garantizar que los usuarios no puedan ser miembros tanto del rol de
compra como del rol de aprobación. Así se asegura de que la misma persona no pueda comprar y
aprobar la compra.
Dinámica: Permite que la misma persona tenga roles de operaciones diferentes pero sucesivos,
pero tiene restricción de una operación o transacción vinculada. Solo se puede aprobar
transacciones de terceros.
Por ejemplo: Dar a un usuario dos roles uno de creador y otro de autorizador con la excepción que
nadie puede autorizar los pagos que él o ella haya creador.
e) (0.5 puntos) Una manera conveniente de expresar las restricciones en RBAC es mediante una
serie de funciones, como por ejemplo, las siguientes:
• smer({r1,...,rm}, t), que sirve para especificar que un determinado usuario no pueda
tener asignados t o más roles del conjunto de roles {r1,...,rm};
10 de 17
• ss-dmer({r1,...,rm}, t), que sirve para evitar que un usuario pueda tener asignados a
la vez t o más roles del conjunto de roles {r1,...,rm} en una misma sesión.
• card(r, t), que sirve para especificar que sólo t usuarios como máximo puedan activar
un mismo rol r simultáneamente en el tiempo.
• ssod({p1,...,pm}, k), que sirve para establecer que para realizar una determinada tarea
hagan falta como mínimo k usuarios que conjuntamente dispongan de todos los permisos
del conjunto {p1,...,pm};
y combinarlas con operadores lógicos como la conjunción (“Ù”) o la disyunción (“Ú”) entre otros.
Dado el siguiente conjunto de restricciones, describa con sus palabras qué hacen:
Restricción Descripción
ssod({poperar, p diagnosticar}, 2) Dos usuarios tienen permisos de operar, diagnosticar
Para realizar en conjunto una tarea o función.
smer({Director, Auditor}, 1) Ù En este caso un usuario puede tener el rol de:
smer({Médico, Enfermero}, 1) Director y Médico.
Director y Enfermero.
Auditor y Médico.
Auditor y Enfermero.
Cada caso por separado no a su vez.
ss-dmer({Médico, Auditor}, 2) En este caso los dos usuarios tienen dos roles, pero
cuando un usuario entra al sistema con el un rol el
otro se desactiva y así no tiene los dos roles en la
misma sesión.
card(Cirujano, 3) Que puede haber varios usuarios con el mismo rol, pero
no pueden iniciar sesión más de tres usuarios a la vez
con este mismo rol.
11 de 17
Ejercicio 4 (2.5 puntos)
RBAC es seguramente el tipo de control de acceso más extendido en la actualidad debido a la
mejor flexibilidad que ofrece en comparación con otros modelos más antiguos como DAC o MAC.
No obstante, la tendencia futura será, muy posiblemente, sustituir RBAC por el más moderno
ABAC (Attribute Based Access Control).
ABAC y XACML ([Link] a menudo
van de la mano. XACML es un estándar que describe un “Access Control Framework” y
proporciona:
(1) un lenguaje para poder definir de forma estructurada políticas de acceso en formato XML
(legible por la máquina encargada de realizar el control de acceso);
(2) un lenguaje (también en XML) para facilitar el diálogo request/response que se mantiene
durante el control de acceso;
(3) una arquitectura formada por los varios componentes que intervienen en un sistema de
control de acceso.
Centrándonos en este último punto, a continuación, se muestra un esquema visual de la
arquitectura XACML 3.0 donde se ven los diversos componentes que participan y las
interacciones existentes entre ellos:
a) (0.5 puntos) Indicad brevemente la tarea que realizan cada uno de los componentes que
forman parte de la arquitectura XACML
Siguiendo el esquema:
1. Creación de las políticas y conjuntos de políticas en el PAP dejándolas disponibles al PDP.
2. El access requester solicita acceso al PEP.
3. El PEP envía la solicitud de acceso al context handler.
4. El context handler construye una solicitud y se la envía el PDP.
5. El PDP solicita atributos del sujeto, recurso, acción y entorno al context handler.
6. El context handler solicita los atributos a un PIP.
7. El PIP obtiene los atributos solicitados.
8. El PIP retorna los atributos solicitados al context handler.
9. El context handler envía los atributos solicitados y opcionalmente el recurso al PDP.
10. El PDP evalúa las políticas.
11. El PDP retorna la respuesta de contexto al context handler incluyendo la decisión de
autorización.
12. El context handler traduce la respuesta de contexto al formato de respuesta nativo del PEP.
13. El context handler retorna la respuesta al PEP.
14. El PEP hace cumplir las obligaciones (operaciones especificadas en las políticas que deben
ser realizadas por el PEP al momento hacer cumplir la decisión de autorización) que implican
las políticas que se están controlando.
12 de 17
15. Si la decisión indica que el acceso es permitido, el PEP permite el acceso al recurso de lo
contrario el acceso es denegado.
b) (0.5 puntos) Suponed que un agente de la ley, en este caso un agente especial del FBI
(atributo-agencia=FBI, atributo-cargo=agente_especial) quiere acceder al informe clasificado
“Area51” ubicado en la biblioteca del Pentágono. Suponed también, que esa biblioteca se basa en
XACML para realizar el control de acceso a los informes clasificados y que tienen una política de
seguridad que indica que “los agentes especiales no pueden acceder a los informes
catalogados como OVNI si no han pasado más de 50 años desde su creación”. Basándose
en la arquitectura anterior, explicad por pasos qué mensajes se intercambian entre los diversos
componentes y qué decisiones se toman en cada componente desde el momento que el agente
especial quiere acceder al informe clasificado hasta que el sistema le permite o no conseguirlo.
Importante: La explicación puede ser a bastante alto nivel, del estilo:
- El Requester le envía a Componente-A su identidad e indica que quiere acceso al recurso “X”.
- Componente-A hace XXXX y envía XXXX a Componente-B
- Etc.
• El Requester envía la solicitud acceso al Componente-A indicando su identidad y le indica
que quiere acceso al informe clasificado “Area51” (recurso).
• El Componente-A envía la solicitud de acceso al context handler donde el agente del FBI
(atributo) necesita acceder al informe clasificado “Area51” con el formato respectivo, donde
incluye los atributos, el recurso, la acción y entorno al Componente-B.
• El Componente-B solicita atributos, recurso, acción y entorno al context handler el mismo
que solicita los atributos al Componente-C.
• El Componente-C obtiene los atributos solicitados y los retorna al context handler.
• El context handler envía los atributos solicitados y opcionalmente el recurso al
Componente-B.
• El Componente-B evalúa la petición de acceso al informe clasificado “Area51” con la
política “los agentes especiales no pueden acceder a los informes catalogados como
OVNI si no han pasado más de 50 años desde su creación” y da respuesta al context
handler incluyendo la decisión de autorización.
• El context handler traduce la respuesta de contexto al formato de respuesta nativo al
Componente-A.
• El Componente-A hace cumplir las obligaciones que implican las políticas que se están
controlando.
• Si la decisión indica que el acceso es permitido, el Componente-A permite el acceso al
recurso de lo contrario el acceso es denegado.
c) (0.5 puntos) A continuación se proporciona una política de seguridad siguiendo la
especificación XACML 3.0. Explicad en detalle qué es lo que hace esta política. Aviso: aparte de
lo que hace “en general” la política, tenéis que explicar que es lo que hace cada parte de la
política.
Descripción de la política en general.- Política de acceso a un sistema a leer los documentos si
solamente es miembro del FBI o de la CIA.
13 de 17
Declaración de la política, donde se asigna el nombre para el PDP, la versión, el algoritmo que se
usará
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="1"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
Version="1.0">
Describe de texto de la política
<Description>My First Policy </Description>
<Target></Target>
Regla en esta política.
<Rule Effect="Permit" RuleId="Rule Permit #1">
<Target>
<AnyOf>
<AllOf>
El objetivo de la regla es similar al objetivo de la política, detalla un valor específico que el sujeto
en la solicitud de decisión.
El elemento <Match> especifica una función coincidente en el atributo MatchId, un valor literal de
"[Link] y un puntero a un atributo de sujeto específico en el contexto de
solicitud mediante el <AttributeDesignator>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue
DataType="[Link]
</AttributeValue>
Atributo que identifica el recurso al que se solicita el acceso.
Categoría que contiene el atributo único del recurso al que le sujeto solicita el acceso
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="[Link] MustBePresent="true">
</AttributeDesignator>
</Match>
Elemento que contiene atributos de la acción que el sujeto desea asumir el recurso, describe la
acción de lectura.
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="[Link]
</AttributeValue>
Atributo que identifica una acción para la que se solicita el acceso.
Este identificador indica atributos de la acción que se solicita dentro del contexto de una categoría.
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
DataType="[Link] MustBePresent="true">
</AttributeDesignator>
14 de 17
</Match>
</AllOf>
</AnyOf>
</Target>
Condición que usa una función para identificar un miembro del grupo puede tener acceso a los
documentos
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue
DataType="[Link]
</AttributeValue>
<AttributeValue
DataType="[Link]
</AttributeValue>
</Apply>
Atributo que identifica una acción para la que se solicita el acceso.
Este identificador indica atributos al grupo que solicita acceso a una categoría.
<AttributeDesignator
AttributeId="group"
Category="urn:oasis:names:tc:xacml:3.0:group"
DataType="[Link] MustBePresent="true">
</AttributeDesignator>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="Rule Deny #1"></Rule>
</Policy>
d) (0.5 puntos) Modificad la política de seguridad anterior para que se pueda actualizar (update) el
recurso [Link] sólo si el usuario pertenece al mismo tiempo a los grupos
“fbi” y “cia”. En el caso que no pertenezca a ambos grupos o pertenezca a ellos, pero también a
alguno más, no podrá realizar la actualización.
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="2"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
<Description>My First Policy</Description>
<Target></Target>
<Rule Effect="Permit" RuleId="primary-group-customer-rule">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue
DataType="[Link]
<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="[Link] MustBePresent="true"></AttributeDesignator>
</Match>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="[Link]
<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
DataType="[Link] MustBePresent="true"></AttributeDesignator>
</Match>
</AllOf>
15 de 17
</AnyOf>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-subset">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="[Link]
</Apply>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="[Link]
</Apply>
<AttributeDesignator AttributeId="group" Category="urn:oasis:names:tc:xacml:3.0:group"
DataType="[Link] MustBePresent="true"></AttributeDesignator>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="deny-rule"></Rule>
</Policy>
e) (0.5 puntos) Definid brevemente qué es un “access request” dentro del contexto de XACML.
Asumiendo la política de seguridad definida en los apartados c y d, proporcionad el código de un
“access request” siguiendo la especificación XACML 3.0 que permita a “Mulder” (acess-subject)
que es del grupo “fbi” y “cia”, poder hacer un “update” (action) en la url
[Link] (resource).
Access request: evalúa la petición de XACML sobre cualquier política, y responde de acuerdo
estándar de XACML con la desición de PDP.
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false"
ReturnPolicyIdList="false">
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="false">
<AttributeValue DataType="[Link]
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" IncludeInResult="false">
<AttributeValue DataType="[Link]
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="false">
<AttributeValue
DataType="[Link]
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:group">
<Attribute AttributeId="group" IncludeInResult="false">
<AttributeValue DataType="[Link]
<AttributeValue DataType="[Link]
</Attribute>
</Attributes>
</Request>
Referencias
Dana Elfenbaum.(2019). Top 500 list. Cómo leer un archivo línea por lí[Link] de
[Link]
16 de 17
devnull.(2017). El [Link]. COMBINACIONES Y BITS DE [Link] de
[Link]
Erich Strohmaier.(2019). Top 500 list. Top-ranked systems. Recuperado de
[Link]
Manish Verma.(2004). IBM Developer. Control information access with XACML,[Link]
Electronic Library [Link] de [Link]
xacml/[Link]
Universidad Indiana.(2018). ARCHIVED: In high-performance computing, what are Rmax and
Rpeak?. Indiana,USA. This is document bbzo in the Knowledge Base. Recuperado de
[Link]
(2013). Pushpalanka's [Link] information access with XACML,[Link] with XACML
3.0
policies for fine-grained [Link]. Recuperado de
[Link]
17 de 17