¿Cuál es el significado y la diferencia entre sujeto, usuario y director?

173

En el contexto de los marcos de seguridad, algunos términos comúnmente aparecen sujeto , usuario y principal , de los cuales no he podido encontrar una definición clara y la diferencia entre ellos.

Entonces, ¿qué significan exactamente estos términos y por qué son necesarias estas distinciones de sujeto y principal ?

java spring-security terminology security ams
fuente

Respuestas:

277

Estos son jerárquicos en la forma en que el género, la especie y el individuo son jerárquicos.

  • Asunto : en un contexto de seguridad, un sujeto es cualquier entidad que solicita acceso a un objeto . Estos son términos genéricos utilizados para denotar la cosa que solicita acceso y la cosa contra la que se realiza la solicitud. Cuando inicia sesión en una aplicación, usted es el sujeto y la aplicación es el objeto. Cuando alguien toca a su puerta, el visitante es el sujeto que solicita el acceso y su hogar es el objeto al que se solicita el acceso.
  • Principal : un subconjunto de temas representado por una cuenta, rol u otro identificador único. Cuando llegamos al nivel de detalles de implementación, los principales son las claves únicas que usamos en las listas de control de acceso. Pueden representar usuarios humanos, automatización, aplicaciones, conexiones, etc.
  • Usuario : un subconjunto de principal que generalmente se refiere a un operador humano. La distinción se desdibuja con el tiempo porque las palabras "usuario" o "ID de usuario" se intercambian comúnmente con "cuenta". Sin embargo, cuando necesita hacer la distinción entre la amplia clase de cosas que son principales y el subconjunto de estas que son operadores interactivos que conducen las transacciones de una manera no determinista, "usuario" es la palabra correcta.

Sujeto / Objeto hereda de los mismos términos que se usan en la gramática. En una oración, el sujeto es el actor y el objeto es la cosa sobre la que se actúa. En este sentido, el uso ha existido desde antes de que se inventaran las computadoras. En un contexto de seguridad, un sujeto es cualquier cosa que pueda hacer una solicitud. Como se señaló anteriormente, esto no tiene por qué limitarse a la seguridad de TI, por lo que es una clasificación muy amplia. Lo interesante es que sujeto implica objeto. Sin un objeto, no hay sujeto.

Los directores son lo que los sujetos resuelven. Cuando presenta su tarjeta de crédito, usted es el sujeto y el número de cuenta es el principal. En otros contextos, su identificación de usuario o identificación emitida por el estado es su principal. Pero los principios pueden asociarse con muchos tipos de temas que no son personas. Cuando las aplicaciones solicitan funciones a nivel de sistema, el principal puede ser el firmante de un módulo de código ejecutable firmado, pero incluso en ese caso el usuario que dirige la solicitud sigue siendo el sujeto.

El usuario es más específico que el sujeto o el director, ya que generalmente se refiere a un operador interactivo. Es por eso que tenemos una interfaz gráfica de usuario y no una interfaz principal gráfica. Un usuario es una instancia de sujeto que se resuelve en un principal . Un solo usuario puede resolver cualquier cantidad de principales, pero se espera que cualquier principal resuelva a un único usuario (suponiendo que las personas observen el requisito de no compartir ID). En el ejemplo anterior, el firmante de un módulo de código ejecutable definitivamente no es el usuario, pero es un principal válido. El operador interactivo que intenta cargar el módulo es el usuario.

Como se señaló en los comentarios, incluso las fuentes autorizadas no están de acuerdo con estos términos. Busqué NIST, SANS, IEEE, MITRE y varias fuentes "cuasiautoritarias" como guías de examen de seguridad mientras preparaba esta respuesta. No encontré ninguna fuente única que fuera al menos cuasi autoritaria cubriera los tres términos y todos difirieran significativamente en su uso. Esta es mi opinión sobre cómo se deben usar los términos , pero desde un punto de vista práctico, cuando estás estudiando un manual en medio de la noche, las definiciones tienden a ser lo que el vendedor o el escritor dicen que son. Esperemos que las respuestas aquí proporcionen información suficiente para navegar por las aguas y analizar cualquier documento de seguridad utilizando estos términos.

T.Rob
fuente
3
¿Cuál es el beneficio de dividir las cosas en Asunto, Principal, Usuario, su complejidad adicional? ¿Qué beneficio obtenemos de esta complejidad adicional?
enms.
19
La capacidad de elegir el nivel correcto de especificidad. Es el mismo beneficio que obtenemos al poder hacer una distinción entre un destino y una cola o tema. La capacidad de elegir entre diferentes niveles de especificidad en una taxonomía permite una precisión de expresión que comunica mejor la intención de un escritor a un lector. Cuando programamos tenemos el lujo / la maldición de que la CPU interpretará nuestras instrucciones de una sola manera y nos vemos obligados a usar su nivel de precisión. Pero en el lenguaje humano necesitamos matices y precisión para transmitir el significado de manera eficiente.
T.Rob
1
T.Rob, increíble, pero ¿podría aclarar "Usuario - subconjunto de principal"? Si John es el sujeto y la "cuenta # 123" es su principal, ¿quién es el usuario? ¿Hay dos John's? Como Género> Especie> Individual es cada vez más específico, John (usuario) debería ser más específico que John (sujeto). ¿O me estoy perdiendo algo?
amarillo suave
1
Considere dos principios donde # 123 es John y # 124 se refiere a una cuenta de servicio. Probablemente deseamos tratar estos aspectos diferentes con respecto a la política de contraseña, la capacidad de inicio de sesión, etc. Los principales del tipo 'usuario' están sujetos a la complejidad de la contraseña y a las políticas de caducidad, mientras que los principales del tipo 'cuenta de servicio' ni siquiera pueden tener una contraseña. Cuando comenzamos a clasificar los tipos de principal, creamos subconjuntos. ¿Eso ayuda? ¿O acabo de remover más barro?
T.Rob
Si, eso ayuda. Entonces, concretamente, ¿alguna corrección a lo siguiente? Es posible que desee copiarlo y pegarlo en un editor como Notepad ++ y poner un salto de línea antes de cada John (SO no permite los saltos de línea en los comentarios): John (human) SUBJECT > username_1 PRINCIPAL > password_1 USER John (human) SUBJECT > username_1 PRINCIPAL > password_2 USER John (human) SUBJECT > username_1 PRINCIPAL > smartcard_1 USER John (human) SUBJECT > username_1 PRINCIPAL > cellphone_1 USER
amarillo claro
19

Creo que la terminología está tomada de JAAS .

Cuando una aplicación utiliza la autenticación JAAS para autenticar al usuario (u otra entidad como un servicio), se crea un Asunto como resultado. El propósito del Asunto es representar al usuario autenticado. Un Asunto se compone de un conjunto de Directores , donde cada Principal representa una identidad para ese usuario. Por ejemplo, un Sujeto podría tener un nombre Principal ("Susan Smith") y un Número de Seguro Social Principal ("987-65-4321"), distinguiendo así a este Sujeto de otros Sujetos.

Aravind Yarram
fuente
2
He visto esta definición antes, es demasiado densa, ¿puede explicarla, especialmente cómo un usuario es diferente de un director, por qué se usa el término sujeto y no solo usuario? Si estos términos tienen un significado más allá de JAAS, quiero familiarizarme con ese significado, si estos términos son invenciones de JAAS, entonces supongo que los ingenieros de Sun que lo crearon eligieron nombres pobres para lo que significan estos conceptos. Le he hecho a algunos programadores estas preguntas y no he podido obtener respuestas claras, cada uno parece tener una comprensión diferente de estos términos.
enms.
Parece que un director es solo una forma de identificar un sujeto. Dicho de otra manera, cualquier Principal teóricamente podría servir como clave principal en su base de datos de usuarios.
Platinum Azure
3
El léxico es anterior a JAAS por asomo. JAAS solo reutiliza parte de él y, a veces, de formas no estándar. Parte del problema que provocó esta pregunta es que los conceptos se aprenden de los contextos en los que se usa la terminología y luego se reutilizan de maneras ligeramente diferentes. Cuando las fuentes autorizadas son difíciles de encontrar o simplemente se ignoran, los significados cambian con el tiempo. Cuando se trata de seguridad donde la precisión es un requisito absoluto, esta deriva hacia la ambigüedad degrada nuestra capacidad de construir e implementar diseños seguros.
T.Rob
@ T.Rob, ¿tiene títulos en papel o referencias autorizadas que pueda compartir?
enms.
Desafortunadamente, incluso las fuentes autorizadas no están de acuerdo. SANS no define principal o sujeto en absoluto bit.ly/hl4rUP y NIST bit.ly/fE7NJs define sujeto específicamente como persona. Otras fuentes "autorizadas" son igualmente vagas, lo que, considerando la importancia de la claridad en este campo, es bastante decepcionante. El IEE tiene un glosario, pero solo puede leerlo con membresía o suscripción, por lo que tiene un uso limitado en una discusión con una amplia audiencia. Basé mi respuesta en parte en la Guía del examen CISSP de Shon Harris.
T.Rob
12

El sujeto es la entidad que solicita un servicio. Puede ser un usuario o un proceso. Probablemente por eso se eligió el nombre Asunto en lugar de usuario.

Cuando un sujeto intenta acceder a un servicio, primero debe autenticarse. La autenticación exitosa termina con la carga de los Principios de seguridad para ese Asunto. Por ejemplo, en un sistema de control de acceso basado en roles, un usuario autenticado (conectado) generalmente tendrá dos principios: userId y roleId. En tales sistemas, los privilegios (es decir, quién puede acceder a qué) se especifican tanto para los roles como para los usuarios. Durante la autorización (es decir, verificar si se debe permitir el servicio solicitado), el sistema de seguridad verificará la accesibilidad de los dos principales.

Por lo tanto, desde la perspectiva de la autorización, los principales son las entidades reales para las cuales se permite o no se permite el acceso. El sujeto es solo un usuario / hilo / proceso que contiene algunos principios.

rahulmohan
fuente
¿Cuál es el beneficio de tener múltiples principios por materia?
enms.
66
Se me ocurren dos beneficios: (1) Considerar al usuario Alice con los principales UserId ("Alice"), Role ("Manager"), Department ("Sales") accediendo a un servicio (el Objeto). El control de acceso al servicio se puede especificar como "Permitir rol (Gerente)" o "No permitir para departamento (Ventas)", etc. en lugar de especificar si Alice puede acceder o no. Este tipo de sistemas de control de acceso es más fácil de administrar ya que el administrador de seguridad no necesita especificar privilegios de acceso para TODOS los usuarios para TODOS los servicios.
rahulmohan
44
(2) En un sistema empresarial, los usuarios generalmente deben autenticarse con múltiples sistemas antes de que se pueda ejecutar algún servicio compuesto. Podría suceder que cada uno de esos sistemas tenga sus propios mecanismos de control de acceso que requieren detalles diferentes: un sistema usa SSN y otro usa userId. Por lo tanto, el mismo sujeto debe poseer los dos principios para que pueda acceder a ambos
rahulmohan
1
Tengo el presentimiento de que el 99% de la confusión con esta terminología podría resolverse con una oración similar a "un director es básicamente un grupo".
Trejkaz
1
?! ... ¿por qué dices que un director es un grupo?
Rafael
10

Como T.Rob explicó, Asunto es cualquier entidad que solicita acceso a un objeto. A partir de ese punto, he encontrado un comentario en javax.security.auth. Código de tema que he encontrado MUY útil y fácil de entender:

"Los sujetos pueden tener múltiples identidades. Cada identidad se representa como un Principal dentro del Sujeto. Los principales simplemente unen los nombres a un Sujeto. Por ejemplo, un Sujeto que resulta ser una persona, Alice, podría tener dos Principios: uno que une" Alice Bar ", el nombre en su licencia de conducir, para el Asunto, y otro que une," 999-99-9999 ", el número en su tarjeta de identificación de estudiante, para el Asunto. Ambos Directores se refieren al mismo Asunto aunque cada uno tiene un nombre diferente ".

Espero eso ayude.

Rafael
fuente
7

Este es el enlace para la explicación a continuación de la documentación de Oracle JAVA SE.

Sujetos, directores, autenticación y credenciales Para autorizar el acceso a los recursos, las aplicaciones primero deben autenticar el origen de la solicitud. El marco JAAS define el término sujeto para representar el origen de una solicitud. Un sujeto puede ser cualquier entidad, como una persona o un servicio. Un sujeto está representado por la clase javax.security.auth.Subject .

La autenticación representa el proceso mediante el cual se verifica la identidad de un sujeto y debe realizarse de manera segura; de lo contrario, un autor puede hacerse pasar por otros para obtener acceso a un sistema. La autenticación generalmente involucra al sujeto que demuestra alguna forma de evidencia para demostrar su identidad. Dicha evidencia puede ser información que solo el sujeto probablemente conocería o tendría (como una contraseña o huella digital), o puede ser información que solo el sujeto podría producir (como datos firmados utilizando una clave privada).

Una vez autenticado, un Asunto se rellena con identidades asociadas o Principales (de tipo java.security.Principal ). Un sujeto puede tener muchos directores. Por ejemplo, una persona puede tener un nombre Principal ("John Doe") y un SSN Principal ("123-45-6789"), que lo distingue de otros Sujetos.

Además de los principales asociados, un sujeto puede poseer atributos relacionados con la seguridad, que se denominan credenciales . Una credencial puede contener información utilizada para autenticar el sujeto a nuevos servicios. Dichas credenciales incluyen contraseñas, tickets Kerberos y certificados de clave pública. Las credenciales también pueden contener datos que permiten al sujeto realizar ciertas actividades. Las claves criptográficas, por ejemplo, representan credenciales que permiten al sujeto firmar o cifrar datos. Las clases de credenciales públicas y privadas no son parte de la API principal de J2SE. Cualquier clase, por lo tanto, puede representar una credencial.

fgul
fuente
Aunque estoy de acuerdo con la respuesta de T.Rob, esta de Aram, que dice "un sujeto puede ser cualquier entidad", sugiere ERM: el modelo de entidad-relación que sustenta la mayoría de las bases de datos. En ese modelo, "entidad" corresponde a "sujeto" en el contexto de seguridad, pero dependiendo de lo que esté modelando, podría ser el principal (cuenta bancaria, SSN #) o usuario (John Smith), como se sugiere en Marinus ' responder. Wikipedia: en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
mellow-yellow
0

de acuerdo con Rahulmohan, creo que, antes de que se realice la Autenticación, después de que la Autenticación sea principal, en sentido diferente, un sujeto puede tener muchas funciones principales.

ChinaJavaDeveloper
fuente