Seguridad a nivel de tabla o fila en ASP.NET MVC 5 y Entity Framework 6

1

Ya hice esta pregunta en Stack Overflow , pero nadie respondió, así que quizás sea un lugar más apropiado para discutirlo. Por favor, avíseme si me equivoco y no puedo aceptar preguntas duplicadas en redes diferentes.

Estoy usando ASP.NET MVC 5, Entity Framework 6 y SQL Server 2008 para construir mi aplicación web Intranet. Se han asignado dos necesidades de seguridad para este proyecto y no puedo cambiarlas.

  1. Los inicios de sesión de la aplicación en la base de datos deben tener permisos limitados. Recuerde que es una aplicación de Intranet y se instalará en el servidor del cliente. Tendrán el inicio de sesión en la base de datos, pero todavía no queremos que puedan jugar. El enfoque sugerido para implementar este requisito fue utilizar los inicios de sesión de base de datos para la autenticación de la aplicación. En otras palabras, cada usuario tendrá su propia base de datos de inicio de sesión. La aplicación no tiene ningún inicio de sesión predeterminado, por lo que cuando el usuario intenta iniciar sesión en la aplicación, el controlador de autenticación intenta usar esa credencial de inicio de sesión para conectarse a la base de datos. En caso de éxito, el usuario se autenticará en la aplicación, de lo contrario, la acción de inicio de sesión fallará.

  2. Autorización a nivel de fila. Cada usuario y, por lo tanto, el inicio de sesión en la base de datos no solo tendrá permisos limitados en las tablas sino también en las filas. Creo que puedo implementar esta necesidad solo en la aplicación y olvidarme de la base de datos.

Estoy tan confundido, cualquier orientación y experiencia personal sobre estos requisitos es bienvenida. Creo que necesito tener un sistema de autenticación que funcione de esta manera y pueda usar los inicios de sesión de la base de datos. ¿Puedo anular MS Identity ? ¿Y qué más necesita este proyecto ??

    
pregunta Akbari 01.06.2015 - 09:51
fuente

2 respuestas

1

Publicaré una solución alternativa a la que se propone en "Conceder permisos de nivel de fila en SQL Server de MSDN": enlace .

En mi solución, tiene una tabla meta para cada tabla donde se requieren permisos de nivel de fila. Me gusta llamar a esa tabla meta como una tabla ACL (Lista de control de acceso). Entonces, como ejemplo, su tabla de destino se llama Contactos, luego crea otra llamada de tabla Contacts_ACL. Ahora en esa tabla, puse Contact_Id, User_Id y Permission (o Permission_Id si tenemos una tabla de Permisos separada).

create table Contact (
    contact_id INT PRIMARY KEY,
    ...
);

create table Contact_ACL (
    contact_id INT REFERENCES Contact(contact_id),
    username varchar(100),
    permission varchar(20)
);

Hago esto porque creo que los procedimientos almacenados son una exageración para algo que es muy simple (autorización). También impone un mantenimiento de código adicional como todo lo que cambia la tabla base, tiene que cambiar las vistas y los procedimientos almacenados.

Aquí hay un ejemplo de consulta LINQ para recuperar cosas:

from contact in Contact
join acl in Contact_ACL on contact.contact_id equals acl.contact_id
where acl.username == <username>
select new {
    contact.contact_id,
    ...,
    acl.permission
}
    
respondido por el Parth Shah 05.06.2015 - 06:12
fuente
0

Necesita algo llamado enmascaramiento dinámico de datos .

La empresa para la que trabajo, Axiomatics (descargo de responsabilidad: trabajo para esa empresa), tiene una solución basada en políticas que logra el filtrado y el enmascaramiento de datos. Significa que, según las políticas y los atributos, es posible definir lo que un usuario puede SELECCIONAR / INSERTAR / ELIMINAR ...

La forma en que funciona es que define una política, por ejemplo:

  • El usuario con el rol == doctor puede hacer la acción == SELECCIONAR en la tabla == MEDICALRECORD si y solo si userId == asignarDoctor.

Luego, entre la aplicación y la base de datos, implementa un proxy que interceptará el flujo y adjuntará la declaración de filtro SQL relevante (normalmente una cláusula WHERE), por ejemplo:

  • SQL interceptado: SELECT * FROM medicalrecords
  • Se generó la cláusula WHERE: WHERE medicalrecords.assignedDoctor='Alice'
  • Sentencia de SQL final enviada a la base de datos: SELECT * FROM medicalrecords WHERE medicalrecords.assignedDoctor='Alice'

Las políticas están en un formato estándar llamado y habilitar atributo- control de acceso basado (también conocido como ).

Los siguientes enlaces pueden serte útiles:

respondido por el David Brossard 01.06.2015 - 16:37
fuente

Lea otras preguntas en las etiquetas