Tenemos la siguiente configuración:
- Base de datos de producción múltiple que contiene datos privados que utiliza el software de escritorio
- Una base de datos web para un sitio web público que necesita algunos datos de las bases de datos privadas.
- Una base de datos intermedia que contiene algunas vistas y procedimientos almacenados que extraen datos de las bases de datos privadas.
Actualmente, el sitio web inicia sesión en la base de datos web, y la base de datos web se conecta a la base de datos intermedia para extraer datos o ejecutar procedimientos almacenados en las bases de datos de producción. Todas las bases de datos están en la misma instancia de SQL, y todo el proceso utiliza la misma cuenta de usuario.
La cuenta de usuario tiene acceso completo a la base de datos web y a la base de datos intermedia, pero solo puede acceder a vistas específicas y procedimientos almacenados de una base de datos privada
¿Es esto realmente más seguro que simplemente hacer que la base de datos pública se conecte directamente a las privadas?
Parece que la base de datos intermediaria solo está ahí para complicar las cosas, ya que el mismo inicio de sesión se usa para acceder a los datos en todas las bases de datos, y ya está limitado solo a las vistas / SP que necesita en las bases de datos privadas. Espero eliminarlo.
fuente
Respuestas:
Una cosa salta aquí:
Problema
Por lo tanto, el usuario X hipotético (ya sea un saco de carne con Excel o IIS AppPool Identity) puede ver algunas vistas y códigos. No importa en qué base de datos se encuentren estas vistas y el código porque userX está configurado en 3 bases de datos de todos modos.
Sin embargo, pierdes la propiedad encadenando así.
Digamos
WebDB.dbo.SomeProcllamadasPrivateDB.dbo.SomeTable. UserX requiere permisos en ambos objetos. Si esto estabaOneDB.WebGUI.SomeProcusandoOneDB.dbo.SomeTable, solo losOneDB.WebGUI.SomeProcpermisos necesarios. No se verifican los permisos en objetos referenciados con el mismo propietario.Nota: No he analizado demasiado el encadenamiento de propiedad de bases de datos cruzadas . Sólo sé viejo y simple "encadenamiento de propiedad" , así
Ahora, según los comentarios, realmente tiene 2 bases de datos que se pueden combinar. No 3, lo que originalmente estaba implícito. Sin embargo, el intermedio y la web se pueden combinar.
Las otras bases de datos "privadas" tal vez se puedan combinar, pero eso será un problema separado. Vea el enlace inferior para una discusión más completa de "una base de datos o muchas"
¿Solución?
Si las bases de datos adicionales son solo contenedores de código, entonces los esquemas son una mejor idea.
Esto suena como si hubiera usado "Base de datos" donde debería usar "Esquema" (en el sentido de SQL Server, no en el sentido de MySQL). Tendría un esquema WebGUI, un esquema auxiliar o común (para reemplazar la base de datos intermedia) y un esquema de escritorio. De esta manera, separa los permisos en función de los clientes y solo tiene una base de datos
Con una base de datos (además de "encadenamiento de propiedad") también puede comenzar a considerar vistas indexadas, SCHEMABINDING (lo uso siempre) y tal que no se puede hacer con bases de datos separadas
Para obtener más información sobre los esquemas, consulte estas preguntas:
Finalmente, no parece haber ninguna razón para tener bases de datos separadas basadas en "no se requiere integridad transaccional". Consulte esta pregunta para explicar esto: Criterios de decisión sobre cuándo usar un esquema no dbo frente a una nueva Base de datos
fuente
La respuesta es, depende. Si no se accede a la base de datos privada desde una LAN interna externa (o solo a través de una VPN), este esquema agrega seguridad ya que alguien que use las credenciales del sitio web tendría un acceso limitado a ese servidor de base de datos privado (y tendrá algo más de trabajo para obtener en su red interna: tiempo que puede ser útil para descubrir la intrusión y cerrar el agujero).
Si no, no creo que agregue nada excepto la complejidad.
EDITAR:
Parece que he leído mal su pregunta, así que veamos si entendí correctamente ahora: IntermDb es una base de datos vacía solo para conectarse a PrivateDB O es una base de datos que tiene vistas / procedimientos propios que se conectan a PrivateDB para recuperar datos ?
En el primer caso, WTF? Arrancarla. No tiene valor, a menos que alguien quiera auditarlo para acceder al perfil de PrivateDB de una manera más perezosa (y hacer que los desarrolladores de WebApp trabajen más). SQL Profiler puede filtrar usando DB_ID ...
En el segundo caso, sostengo mi respuesta anterior.
EDITAR: "Todavía no veo cómo esto es más seguro que conectar la base de datos privada directamente a la base de datos pública ya que las 3 bases de datos en la misma instancia de SQL y el inicio de sesión utilizado para las 3 bases de datos es el mismo, y solo puedo acceder vistas específicas y procedimientos almacenados en la base de datos privada de todos modos ".
Tener el intermediario significa que el invasor tendría que cavar en su código para saber la existencia de un IntermDB, y tiene que cavar su código para saber que existe un PrivateDB.
Si coloca su PrivateDB en otro servidor interno de su organización LAN / WAN (si es posible), puede dar suficiente tiempo para que el administrador detecte y bloquee el intento de invasión. Si usa sinónimos, este movimiento es fluido ya que todo lo que tiene es reconstruirlos al código existente, vaya al lugar correcto.
También obtiene otras ventajas: dado que todo el código tiene que pasar a través de IntermDB para acceder a los datos en PrivateDB, ningún desarrollador se vería tentado a intentar evitarlo , y ese intento se puede detectar fácilmente en SQL Server Profiler como el DB_ID de la solicitud de datos de PrivateDb sería WebAppDb.
fuente