c# database security entity-framework row-level-security

c# - Seguridad de nivel de fila con Entity Framework



database security (5)

He estado tratando de considerar cómo Row Level Security podría implementarse con Entity Framework. La idea es tener un agnóstico de base de datos que ofrezca métodos para restringir las filas provenientes de ObjectContext.

Algunas de mis ideas iniciales han implicado modificar las clases parciales creadas por la herramienta EDMGEN y eso ha ofrecido un apoyo limitado. Los usuarios aún pueden sortear esta solución utilizando sus propias declaraciones eSQL y un QueryObject.

He estado buscando una solución integral que existiría por encima de los proveedores de bases de datos para que permanezca agnóstica.

El lugar donde agregas seguridad realmente depende de contra quién intentas protegerte.

Si, por ejemplo, está asegurando un sitio web, entonces agregar el filtrado en el contexto sería suficiente, porque los "usuarios" en este caso están en el sitio web. No tienen más remedio que pasar por su contexto, ya que escribiría la aplicación completamente contra el contexto.

En tu caso, parece que los "usuarios" contra los que intentas protegerte son los desarrolladores. Eso es bastante más difícil. Si los desarrolladores no tienen acceso para realizar modificaciones en la base de datos, entonces deberá poner la seguridad en el nivel de la base de datos. Ninguna cantidad de acceso de eSQL podrá moverse por la base de datos diciendo "no".

Lo que intentas lograr es, por definición, imposible.

Si la seguridad no es manejada explícitamente por la aplicación de base de datos subyacente (SQL Server, Oracle, lo que sea) entonces las herramientas estándar como SQL Management Studio soplarán justo después.

Lo mejor que puede hacer es hacer cumplir la seguridad de nivel de fila por los usuarios de la aplicación SÓLO si esos usuarios no tienen acceso a la base de datos a través de otro mecanismo.

Seguro que puedes hacerlo. Lo importante es bloquear el acceso directo al contexto del objeto (evitando que los usuarios construyan su propio ObjectQuery), y en su lugar darle al cliente una puerta de enlace más estrecha dentro de la cual acceder y mutar las entidades. Lo hacemos con el patrón de repositorio de entidades . Puede encontrar una implementación de ejemplo de este patrón para el marco de entidad en esta publicación de blog . Nuevamente, la clave es bloquear el acceso al contexto del objeto. Tenga en cuenta que la clase de contexto del objeto es parcial. Por lo tanto, debe poder evitar los medios "no autorizados" de instanciarlo, es decir, fuera de su conjunto de repositorio.

Sin embargo, hay sutilezas a considerar. Si implementa seguridad de vista a nivel de fila en un tipo de entidad determinado a través del patrón de repositorio, entonces debe considerar otros medios por los que un cliente podría acceder a las mismas entidades. Por ejemplo, a través de las relaciones de navegación. Es posible que deba establecer algunas de esas relaciones como privadas, lo que puede hacer en su modelo. También tiene la opción de especificar una consulta personalizada o un procedimiento almacenado para cargar / guardar entidades. Los procedimientos almacenados tienden a ser específicos del servidor de bases de datos, pero el SQL se puede escribir de forma genérica.

Si bien no estoy de acuerdo en que esto no se puede hacer con Entity Framework, estoy de acuerdo con los comentarios de "hazlo en el servidor de BD" en la medida en que debas implementar defensa en profundidad .

Encontré una manera de hacerlo usando Postgres y una extensión llamada Veil . En realidad, funciona (diseñado para) usar Views para todas las operaciones (seleccionar, actualizar, eliminar, insertar) y verificar los permisos en las cláusulas WHERE . Pero Veil solo agrega las matemáticas para administrar eficientemente la información de los permisos en la memoria en lugar de consultarla en todo momento. Así que con Veil, aunque se conecte directamente a DBMS, solo tiene acceso a nivel de fila otorgado por usted.

Modifico mi estilo con veil de alguna manera, por ejemplo, comencé a usar Triggers lugar de Views para aplicar restricciones de permisos.

Te recomiendo que estudies esta solución y trates de aplicarla aquí.

es decir: realiza una consulta de select * from table y obtiene exactamente lo que pretende (nivel de fila hablando).