¿Cómo puede un sujeto leer y escribir solo en sus objetos de propiedad?

Question

¿Cómo puede un sujeto leer y escribir solo en sus objetos de propiedad?

#1 de Avraam Mavridis (1 votos)
#2 de Saladin (0 votos)
#3 de David Brossard (0 votos)
#4 de rook (-1 votos)

4

Parece que en RBAC, un sujeto crea una sesión con un rol activo, estos roles se usan para determinar qué permisos y acciones se pueden tomar. Esto parece estar bien para la mayoría de nuestra organización hasta que llegue a Sujetos con el rol de cliente. Los clientes solo deberían poder leer las cosas que poseen, a diferencia de otros roles que tendrían lectura / escritura (o cualquier otra acción) en cosas del mismo tipo.

No estoy seguro de cuál es la mejor manera de implementar esto utilizando RBAC. ¿Debería la sesión contener también el tema? Algunas referencias sugieren que no.

Nota: es posible que esté siendo demasiado purista, pero estoy comprobando lo que me estoy perdiendo. He considerado la ruta PostgreSQL donde un usuario es un rol, y luego el rol activo en la sesión es el usuario. ¿Cuáles son mis opciones para restringir un rol para ver solo cosas no por tipo sino por propiedad?

authorization access-control rbac

pregunta xenoterracide 13.02.2013 - 05:10

fuente

4 respuestas

Lea otras preguntas en las etiquetas authorization access-control rbac

herramienta de auditoría WPA2 Security Onion: las alertas de Snorby muestran la IP de origen de la red local (pública y privada)

score 1 · Answer 1

Creo que esto se puede implementar usando Capacidades. Cada sujeto tiene un conjunto de pares (o, r) donde o es el objeto y r son los derechos. Por ejemplo, si el Cliente1 puede leer el archivo1 y leer-escribir en el archivo2, puede tener una lista de Capacidades como esa:

Customer1 = {(file1, {read}), (file2, {read, write})}

Si muchos clientes tienen los mismos derechos, puede usar grupos para limitar el almacenamiento que se usa para guardar esta información.

Pero luego debe asegurarse de que los sujetos no puedan modificar la lista de Capacidades.

score 0 · Answer 2

Bueno, lo que puedes hacer es definir un contenedor de algún tipo; asigne el subconjunto de sus derechos de objetos igual al nivel de permiso / acceso del sujeto. Suena trivial pero sé que funciona. Puede visualizarse en forma de matriz de control de acceso otro rol cuando intenta acceder a objetos de otro nivel de confianza; provocaría un error de permiso.

ver esto enlace

o mejor matriz de control de acceso de owasp en google

score 0 · Answer 3

Usted está golpeando las limitaciones de RBAC. Además de considerar las capacidades sugeridas por Avraam Mavridis, considere usar el control de acceso basado en atributos ( ABAC ), que amplía las posibilidades de RBAC al incluir atributos adicionales (metadatos) como atributos de usuario (ubicación, autorización, ciudadanía) y metadatos de recursos (clasificación, propiedad ...).

XACML es el estándar OASIS que implementa ABAC. Con XACML, puede escribir fácilmente una regla de relación que diría:

solo permite el acceso a un recurso si y solo si el ID del solicitante == ID del propietario.

Mejor aún, puede volver a escribir la regla de manera negativa, ya que ser el propietario puede no ser suficiente para acceder a un recurso, pero no ser el propietario es suficiente para denegar el acceso:

denegar el acceso a un recurso si el identificador del solicitante! = ID del propietario

score -1 · Answer 4

Por coherencia dentro de un sistema RBAC, todos los recursos deben contener información de propiedad. El objeto Session Sate usualmente contiene información usada para hacer cumplir las reglas de control de acceso. Las sesiones se crean (o modifican) tras la autenticación y la desautorización. Las reglas sobre quién puede autenticarse y a qué recursos tienen acceso están controladas por el Superusuario. Es lógico pensar que todas las sesiones solo pueden ser modificadas por el sistema en base a las intenciones del Superusuario. Un usuario normal nunca debería poder modificar el estado de la sesión y cambiar la clave principal de su registro de usuario.

Ahora pensemos en un escenario. Un empleado está actualmente conectado al sistema. Son despedidos por la dirección. El superusuario elimina esta cuenta, y su estado de sesión debe ser destruido y sus privilegios deben ser revocados inmediatamente. El Superusuario posee el objeto de sesión y lo destruye a petición. El usuario no controla cuándo ha iniciado sesión, si esto fuera cierto, podría dañar otros datos que pertenezcan a esa cuenta de usuario.