Temos a seguinte configuração:
- Banco de dados de produção múltipla contendo dados privados que são usados pelo software de desktop
- Um banco de dados da web para um site público que precisa de alguns dados dos bancos de dados privados
- Um banco de dados intermediário que contém algumas visualizações e procedimentos armazenados que extraem dados dos bancos de dados privados
Atualmente, o site faz login no banco de dados da web e o banco de dados da web se conecta ao banco de dados intermediário para extrair dados ou executar procedimentos armazenados nos bancos de dados de produção. Todos os bancos de dados estão na mesma instância SQL e todo o processo usa a mesma conta de usuário.
A conta do usuário tem acesso total ao banco de dados da web e ao banco de dados intermediário, mas só pode acessar exibições específicas e procedimentos armazenados de um banco de dados privado
Isso é realmente mais seguro do que apenas fazer com que o banco de dados público se conecte diretamente aos privados?
Parece que o banco de dados intermediário só existe para complicar as coisas, pois o mesmo login é usado para acessar os dados em todos os bancos de dados e já está limitado apenas às visualizações / SPs que precisa nos bancos de dados privados. Eu estou esperando para removê-lo.
Uma coisa salta à vista aqui:
Problema
Portanto, o usuário X hipotético (seja algum saco de carne usando o Excel ou IIS AppPool Identity) pode ver algumas exibições e códigos. Não importa em qual banco de dados essas visualizações e códigos estão, porque userX está configurado em 3 bancos de dados de qualquer maneira.
No entanto, você perde o encadeamento de propriedade dessa maneira.
Digamos
WebDB.dbo.SomeProcchamadasPrivateDB.dbo.SomeTable. UserX requer permissões em ambos os objetos. Se isso estavaOneDB.WebGUI.SomeProcusandoOneDB.dbo.SomeTable, apenas asOneDB.WebGUI.SomeProcpermissões necessárias. As permissões em objetos referenciados com o mesmo proprietário não são verificadas.Observação: não examinei muito profundamente o encadeamento de propriedade entre bancos de dados . Eu só conheço bem o velho e simples " encadeamento de propriedade"
Agora, de acordo com os comentários, você realmente tem 2 bancos de dados que podem ser combinados. Não 3 que foi originalmente implícito. No entanto, o intermediário e a teia podem ser combinados.
Os outros bancos de dados "privados" talvez possam ser combinados, mas isso será um problema separado. Veja o link inferior para uma discussão mais completa sobre "um banco de dados ou muitos"
Solução?
Se os bancos de dados extras forem apenas contêineres de código, os esquemas serão uma ideia melhor.
Parece que você usou "Banco de dados" onde deveria usar "Esquema" (no sentido do SQL Server, não no sentido do MySQL). Eu teria um esquema WebGUI, um esquema auxiliar ou comum (para substituir o banco de dados intermediário) e um esquema de área de trabalho. Assim você separa as permissões com base nos clientes e tem apenas um banco de dados
Com um banco de dados (além do "encadeamento de propriedade"), você também pode começar a considerar exibições indexadas, SCHEMABINDING (eu sempre uso) e coisas que não podem ser feitas com bancos de dados separados
Para saber mais sobre esquemas, consulte estas perguntas:
Finalmente, parece não haver razão para ter bancos de dados separados com base em "integridade transacional não necessária". Veja esta pergunta para explicar isso: Critérios de decisão sobre quando usar um esquema não dbo versus um novo banco de dados
A resposta é: depende. Se o banco de dados privado não for acessado de fora da LAN interna (ou apenas por meio de uma VPN), esse esquema adiciona segurança, pois alguém usando as credenciais do WebSite teria apenas acesso limitado a esse servidor de banco de dados privado (e terá mais trabalho para obter em sua rede interna - tempo que pode ser útil para descobrir a intrusão e fechar o buraco).
Se não, acho que não acrescenta nada, exceto complexidade.
EDITAR:
Parece que interpretei mal sua pergunta, então vamos ver se entendi corretamente agora: o IntermDb é um banco de dados vazio apenas para se conectar ao PrivateDB OU é um banco de dados que possui visualizações/procedimentos próprios que se conectam ao PrivateDB para recuperar dados ?
No primeiro caso, WTF? Arrancá-la. É inútil, a menos que alguém queira auditá-lo para acessar o perfil do PrivateDB de uma maneira mais preguiçosa (e fazer com que os desenvolvedores do WebApp trabalhem mais). SQL Profiler pode filtrar usando DB_ID...
No segundo caso, mantenho minha resposta anterior.
EDIT: "Ainda não vejo como isso é mais seguro do que conectar o banco de dados privado diretamente ao banco de dados público, pois todos os 3 bancos de dados estão na mesma instância SQL e o login usado para todos os 3 bancos de dados é o mesmo e só pode acessar exibições específicas e procedimentos armazenados no banco de dados privado de qualquer maneira".
Ter o intermediário significa que o invasor teria que cavar seu código para saber a existência de um IntermDB - e teria que cavar seu código nele para saber que existe um PrivateDB.
Se você colocar seu PrivateDB em outro servidor interno à LAN/WAN da sua organização (se possível), isso pode dar tempo suficiente para o administrador detectar e bloquear a tentativa de invasão. Se você usar sinônimos, esse movimento é suave, pois tudo o que você tem é reconstruí-los no código existente, vá para o lugar certo.
Além disso, você ganha outras vantagens: como todo o código precisa passar pelo IntermDB para acessar os dados no PrivateDB, nenhum desenvolvedor ficaria tentado a tentar ignorá -lo - e essa tentativa pode ser facilmente identificada no SQL Server Profiler como o DB_ID da solicitação de dados do PrivateDb seria WebAppDb.