É mais seguro percorrer um terceiro banco de dados para conectar dois bancos de dados usando o mesmo login?

Temos a seguinte configuração:

• Banco de dados de produção múltipla contendo dados particulares, 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 efetua 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 visualizações específicas e procedimentos armazenados do banco de dados privado.

Isso é realmente mais seguro do que apenas conectar o banco de dados público diretamente aos privados?

Parece que o banco de dados intermediário está lá apenas para complicar as coisas, pois o mesmo login é usado para acessar dados em todos os bancos de dados e já está limitado apenas às visualizações / SPs necessárias nos bancos de dados privados. Espero removê-lo.

Uma coisa salta aqui:

Todo o processo usa o mesmo conjunto de credenciais de login

Problema

Portanto, o hipotético userX (se algum pacote de ferramentas usando o Excel ou o IIS AppPool Identity) pode ver algumas visualizações e códigos. Não importa em qual banco de dados essas visualizações e códigos estejam, porque o userX está configurado em três bancos de dados de qualquer maneira.

No entanto, você perde o encadeamento de propriedade como este.

Vamos dizer WebDB.dbo.SomeProcchamadas PrivateDB.dbo.SomeTable. O UserX requer permissões nos dois objetos. Se isso estava sendo OneDB.WebGUI.SomeProcusado OneDB.dbo.SomeTable, apenas as OneDB.WebGUI.SomeProcpermissões necessárias. Permissões em objetos referenciados com o mesmo proprietário não são verificadas.

Nota: Não examinei muito profundamente o encadeamento de propriedade entre bancos de dados . Sei apenas velho liso "encadeamento de propriedade" bem

Agora, de acordo com os comentários, você realmente tem 2 bancos de dados que podem ser combinados. Não 3, o que foi originalmente implícito. No entanto, o intermediário e a trama podem ser combinados.

Os outros bancos de dados "privados" talvez possam ser combinados, mas esse será um problema separado. Veja o link inferior para uma discussão mais completa de "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 idéia melhor.

Parece que você usou "Banco de Dados" onde deve usar "Esquema" (no sentido do SQL Server, não no MySQL). Eu teria um esquema WebGUI, um auxiliar ou um esquema comum (para substituir o banco de dados intermediário) e um esquema da área de trabalho. Dessa forma, você separa as permissões com base nos clientes e apenas possui um banco de dados

Com um banco de dados (além de "encadeamento de propriedade"), você também pode começar a considerar as visualizações indexadas, SCHEMABINDING (eu sempre o uso) e coisas que não podem ser feitas com bancos de dados separados

Para mais informações sobre esquemas, consulte estas perguntas:

• Design de esquema - melhores práticas?
• Sobre uso / uso correto de esquemas?

Por fim, parece não haver razão para ter bancos de dados separados com base na "integridade transacional não necessária". Consulte 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 a partir da LAN interna externa (ou apenas por meio de uma VPN), esse esquema adiciona segurança, pois alguém que usa as credenciais do site terá acesso limitado apenas ao servidor de banco de dados privado (e terá mais trabalho a obter na sua rede interna - tempo que pode ser útil para descobrir a intrusão e fechar o buraco).

Caso contrário, acho que não acrescenta nada, exceto complexidade.

EDITAR:

Parece que eu interpretei mal sua pergunta, então vamos ver se entendi direito agora: o IntermDb é um banco de dados vazio apenas para conectar-se 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 criar um perfil do acesso ao PrivateDB de forma mais lenta (e fazer com que os desenvolvedores do WebApp trabalhem mais). O SQL Profiler pode filtrar usando DB_ID ...

No segundo caso, sustento 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 na mesma instância SQL e o logon usado para todos os 3 bancos de dados são os mesmos e só podem acessar modos de exibição específicos e procedimentos armazenados no banco de dados privado ".

Ter o intermediário significa que o invasor precisaria cavar no seu código para saber a existência de um IntermDB - e precisar cavar seu código para saber que existe um PrivateDB.

Se você colocar o PrivateDB em outro servidor interno da LAN / WAN da organização (se possível), poderá dar tempo suficiente para o administrador detectar e bloquear a tentativa de invasão. Se você usar sinônimos, esse movimento será suave, pois tudo o que você tem é reconstruí-los para o código existente e ir para o lugar certo.

Além disso, você obtém outras vantagens: como todo código precisa passar pelo IntermDB para acessar dados no PrivateDB, nenhum desenvolvedor seria tentado 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.