Visibilidade de Estruturas do Banco de Dados SQL Server
19/01/2016
0
Uso atualmente SQL Server 2014, mas acredito que dicas vindas de versões anteriores devam servir.
Meu problema é primeiramente a falta de entendimento sobre questão de visibilidade e segurança. E o segundo é a aplicação disto. Então vamos lá:
Eu desenvolvo uma aplicação usando SQL Server que gostaria de saber como faço para implementar segurança de visibilidade de regra de negócios e de tabelas, view para que quando distribuir o banco de dados junto da aplicação, não consigam ver como foi construída a estrutura toda e a regra de negócios, mas tem permissão arpa todo resto como deletar, selecionar, incluir, etc. Por dentro da aplicação eu envio uma conexão de um usuário chamado "meuconvidado", por exemplo e a senha dele única. Mas para quem esta construindo o banco de dados tem visibilidade e aceso total. Como fazer isto ? Gostaria de bons exemplos passo a passo. Eu acredito que deve haver uma maneira sobre o arquivo mdb de implementar isto.
Agradeço qualquer ajuda que resolva esta questão.
Meu problema é primeiramente a falta de entendimento sobre questão de visibilidade e segurança. E o segundo é a aplicação disto. Então vamos lá:
Eu desenvolvo uma aplicação usando SQL Server que gostaria de saber como faço para implementar segurança de visibilidade de regra de negócios e de tabelas, view para que quando distribuir o banco de dados junto da aplicação, não consigam ver como foi construída a estrutura toda e a regra de negócios, mas tem permissão arpa todo resto como deletar, selecionar, incluir, etc. Por dentro da aplicação eu envio uma conexão de um usuário chamado "meuconvidado", por exemplo e a senha dele única. Mas para quem esta construindo o banco de dados tem visibilidade e aceso total. Como fazer isto ? Gostaria de bons exemplos passo a passo. Eu acredito que deve haver uma maneira sobre o arquivo mdb de implementar isto.
Agradeço qualquer ajuda que resolva esta questão.
Guilherme Wiethaus
Curtir tópico
+ 0
Responder
Post mais votado
19/01/2016
Guilherme,
Sua questão é confusa, mas, vou tentar ajudar...
"Eu desenvolvo uma aplicação usando SQL Server que gostaria de saber como faço para implementar segurança de visibilidade de regra de negócios e de tabelas, view para que quando distribuir o banco de dados junto da aplicação, não consigam ver como foi construída a estrutura toda e a regra de negócios, mas tem permissão arpa todo resto como deletar, selecionar, incluir, etc."
Dependendo a complexidade do seu modelo de dados, mesmo que exista acesso total ao banco de dados pelo cliente, pode ser impossível para ele compreender algo, sem algum tipo de documentação de apoio. Por exemplo : existem softwares de ERP que contém milhares de tabelas, como nomes não amigáveis ( normalmente códigos ). Somente com o dicionário de dados do sistema e a documentação do modelo, é possível ter uma "noção" do que está acontecendo ali. Então, a primeira dica é : não distribua qualquer material técnico com a descrição do modelo para o cliente.
Quanto a questão da visibilidade de "regras de negócio", esse assunto é controverso... De qualquer modo, as melhores práticas dizem que as regras de negócio devem ficar encapsuladas dentro da aplicação. Temos, portanto, a segunda dica : minimize a colocação de regras de negócio no banco.
A terceira dica, tem a ver com o escopo LEGAL de acesso dos usuários. Vão existir usuários com perfil de administrador da base e usuários com perfil mais simples de acesso aos dados. A questão que você precisa definir é ( no seu contrato com o cliente ): de quem é a responsabilidade pela manutenção do servidor de banco de dados.
Se for sua, assuma tudo... desde a instalação do Sql Server. Fazendo isso, você não vai precisar se preocupar com nenhuma dessas questões.
Contudo, se a responsabilidade pela infraestrutura for do cliente, formate as condições de uso do seu sistema, de modo a garantir ( claramente ) a responsabilidade de cada parte.
Nos meus sistemas, utilizo esse modelo : questões de infraestrutura são de responsabilidade sempre do cliente. Se ele, por qualquer motivo, cometer alguma ação fora do definido no contrato, tenho direito aos devidos ressarcimento. Isso, claro, não lhe garante nada do ponto de vista prático... mas pode lhe evitar várias dores de cabeça no futuro.
Sendo assim, estenda o escopo desses controles, também às questões legais... lembrando que direito de uso não é direito de propriedade !
"Por dentro da aplicação eu envio uma conexão de um usuário chamado "meuconvidado", por exemplo e a senha dele única. Mas para quem esta construindo o banco de dados tem visibilidade e aceso total. Como fazer isto ? Gostaria de bons exemplos passo a passo. Eu acredito que deve haver uma maneira sobre o arquivo mdb de implementar isto."
Definidas as questões anteriores, fica mais fácil, entender essa parte...
Não existe "quem está construindo o banco de dados"... existe, sim, um usuário autorizado a rodar TODOS os scripts de configuração do seu ambiente, desde a criação até as manutenções incrementais.
Esse usuário é diferente do usuário da aplicação e diferente dos usuários administrativos do cliente.
Explico melhor : você pode ter dois perfis de usuários ( do banco de dados ) no seu sistema. Os usuários da aplicação ( com seus devidos direitos funcionais de acesso ) e um usuário administrativo SEU, específico, para que você rode os scripts necessários para configurar seu banco de dados.
Repare que esse último pode ser o "SA", mas em ambiente maiores e complexos, com certeza não será ! Então, você vai precisar de um usuário devidamente autorizado para os ajustes na SUA estrutura.
Teoricamente é isso, ou algo muito parecido com isso...
Na prática, é impossível lhe dizer como fazer... pois são muitas variáveis e combinações possíveis.
Estude o modelo geral de usuários, grupos e permissões do Sql Server. Entendendo as definições gerais do ambiente, você vais conseguir implementar o que precisa !
Boa sorte !
Sua questão é confusa, mas, vou tentar ajudar...
"Eu desenvolvo uma aplicação usando SQL Server que gostaria de saber como faço para implementar segurança de visibilidade de regra de negócios e de tabelas, view para que quando distribuir o banco de dados junto da aplicação, não consigam ver como foi construída a estrutura toda e a regra de negócios, mas tem permissão arpa todo resto como deletar, selecionar, incluir, etc."
Dependendo a complexidade do seu modelo de dados, mesmo que exista acesso total ao banco de dados pelo cliente, pode ser impossível para ele compreender algo, sem algum tipo de documentação de apoio. Por exemplo : existem softwares de ERP que contém milhares de tabelas, como nomes não amigáveis ( normalmente códigos ). Somente com o dicionário de dados do sistema e a documentação do modelo, é possível ter uma "noção" do que está acontecendo ali. Então, a primeira dica é : não distribua qualquer material técnico com a descrição do modelo para o cliente.
Quanto a questão da visibilidade de "regras de negócio", esse assunto é controverso... De qualquer modo, as melhores práticas dizem que as regras de negócio devem ficar encapsuladas dentro da aplicação. Temos, portanto, a segunda dica : minimize a colocação de regras de negócio no banco.
A terceira dica, tem a ver com o escopo LEGAL de acesso dos usuários. Vão existir usuários com perfil de administrador da base e usuários com perfil mais simples de acesso aos dados. A questão que você precisa definir é ( no seu contrato com o cliente ): de quem é a responsabilidade pela manutenção do servidor de banco de dados.
Se for sua, assuma tudo... desde a instalação do Sql Server. Fazendo isso, você não vai precisar se preocupar com nenhuma dessas questões.
Contudo, se a responsabilidade pela infraestrutura for do cliente, formate as condições de uso do seu sistema, de modo a garantir ( claramente ) a responsabilidade de cada parte.
Nos meus sistemas, utilizo esse modelo : questões de infraestrutura são de responsabilidade sempre do cliente. Se ele, por qualquer motivo, cometer alguma ação fora do definido no contrato, tenho direito aos devidos ressarcimento. Isso, claro, não lhe garante nada do ponto de vista prático... mas pode lhe evitar várias dores de cabeça no futuro.
Sendo assim, estenda o escopo desses controles, também às questões legais... lembrando que direito de uso não é direito de propriedade !
"Por dentro da aplicação eu envio uma conexão de um usuário chamado "meuconvidado", por exemplo e a senha dele única. Mas para quem esta construindo o banco de dados tem visibilidade e aceso total. Como fazer isto ? Gostaria de bons exemplos passo a passo. Eu acredito que deve haver uma maneira sobre o arquivo mdb de implementar isto."
Definidas as questões anteriores, fica mais fácil, entender essa parte...
Não existe "quem está construindo o banco de dados"... existe, sim, um usuário autorizado a rodar TODOS os scripts de configuração do seu ambiente, desde a criação até as manutenções incrementais.
Esse usuário é diferente do usuário da aplicação e diferente dos usuários administrativos do cliente.
Explico melhor : você pode ter dois perfis de usuários ( do banco de dados ) no seu sistema. Os usuários da aplicação ( com seus devidos direitos funcionais de acesso ) e um usuário administrativo SEU, específico, para que você rode os scripts necessários para configurar seu banco de dados.
Repare que esse último pode ser o "SA", mas em ambiente maiores e complexos, com certeza não será ! Então, você vai precisar de um usuário devidamente autorizado para os ajustes na SUA estrutura.
Teoricamente é isso, ou algo muito parecido com isso...
Na prática, é impossível lhe dizer como fazer... pois são muitas variáveis e combinações possíveis.
Estude o modelo geral de usuários, grupos e permissões do Sql Server. Entendendo as definições gerais do ambiente, você vais conseguir implementar o que precisa !
Boa sorte !
Marcos P
Responder
Mais Posts
19/01/2016
Alex Lekao
Embora nao ser a minha praia, achei a explicação do Marcos excelente.
acompanhando para conhecimento.
acompanhando para conhecimento.
Responder
19/01/2016
Guilherme Wiethaus
Obrigado pela resposta Marcos. Entendi algumas coisas, porem existem uma tecnologia própria no banco que som nele é possível realizar dentro de triggers e storedproc que não seriam possíveis dentro da aplicação. Boa parte da regra de negócio esta encapsulada na aplicação. O banco de dados apenas trata algumas peculiaridades de registros e tratamento dos mesmos. Algumas chaves do projeto estão dentro do banco e não quero disponibilizar de forma que alguém de má fé venha a utilizar isto. eu levei quase, somando ao total 5 a 8 anos para aperfeiçoar algumas coisas e funcionar adequadamente e este trabalho não quero jogar na mãos de outros.
O banco de dados tem centenas de tabelas com relacionamentos bem complexos, dezenas de stored, centenas de trigger e mais outrs dezenas de funções.
o que eu precisava, na real era algum usuário o bloqueio que se o arquivo mdb fosse parar na mãos de outros ele não conseguiria visualizar as estruturas no mínimo das proc, trigger e func. Existe algum método bacana para impedir no mínimo isto ou dificultar.
Nesta parte de segurança e exibição sou leigo mas tenho conhecimentos sólidos na parte complexa de algoritmos e soluções.
Agradeço mais uma vez ao esforço de contribuir ao conhecimento.
O banco de dados tem centenas de tabelas com relacionamentos bem complexos, dezenas de stored, centenas de trigger e mais outrs dezenas de funções.
o que eu precisava, na real era algum usuário o bloqueio que se o arquivo mdb fosse parar na mãos de outros ele não conseguiria visualizar as estruturas no mínimo das proc, trigger e func. Existe algum método bacana para impedir no mínimo isto ou dificultar.
Nesta parte de segurança e exibição sou leigo mas tenho conhecimentos sólidos na parte complexa de algoritmos e soluções.
Agradeço mais uma vez ao esforço de contribuir ao conhecimento.
Responder
19/01/2016
Marcos P
Muitas vezes fui tentado a achar modelos malucos de proteção, incluindo hard-locks, algoritmos de criptografia real-time e outras maluquices. Percebi que, muitas vezes, damos mais valor ao que desenvolvemos do que realmente elas tem, pois, no ambiente corporativo, temos, normalmente, apenas uma pequena parte de participação em todo o contexto.
Não acredito muito em "milagres" tecnológicos... acho difícil você estar 100% seguro em relação ao seu ambiente, sem degradar a performance ou complicar a arquitetura.
Hoje, prefiro ir por outra linha... formatar adequadamente os termos do contrato, me prevenindo sobre aspectos relacionados à propriedade.
Vale, também, partir para a linha de registro de propriedade que no Brasil, como tudo, não é uma maravilha... mas pode lhe dar algum respaldo.
Não acredito muito em "milagres" tecnológicos... acho difícil você estar 100% seguro em relação ao seu ambiente, sem degradar a performance ou complicar a arquitetura.
Hoje, prefiro ir por outra linha... formatar adequadamente os termos do contrato, me prevenindo sobre aspectos relacionados à propriedade.
Vale, também, partir para a linha de registro de propriedade que no Brasil, como tudo, não é uma maravilha... mas pode lhe dar algum respaldo.
Responder
19/01/2016
Guilherme Wiethaus
Muito bem explanado Marcos. Vou levar fortemente em consideração o que me foi colocado. Vou acabar perdendo muito tempo a qual posso resolver com uma simples caneta, papel e acordo entre as partes. Estou desenvolvendo todo um sistema, já de anos, levando como hobbies e profissional, mas quando amadurecer ai sim pode ser lançado. Eu levei muitos anos me desenvolvendo para chegar aqui e acho que vale a pena lançar o sistema que são poucos no mercado. Agradeço pela ajuda e vou seguir escrevendo os sistema me preocupando menos com esta questão, pois senão a coisa não sai.
Responder
19/01/2016
Marcos P
Exato...
A definição genérica de "sistema" é : um conjunto integrado de elementos que contribuem para um mesmo fim !
Sendo assim,considere que o modelo de comercialização do software também é uma parte do sistema que você vai oferecer ao mercado.
Pensando desse modo, você terá condições de desenvolver um modelo que atenda a todas sua necessidades...
Boa sorte e, precisando, estamos por aqui.
A definição genérica de "sistema" é : um conjunto integrado de elementos que contribuem para um mesmo fim !
Sendo assim,considere que o modelo de comercialização do software também é uma parte do sistema que você vai oferecer ao mercado.
Pensando desse modo, você terá condições de desenvolver um modelo que atenda a todas sua necessidades...
Boa sorte e, precisando, estamos por aqui.
Responder
18/07/2016
Guilherme Wiethaus
A questão é que se eu for distribuir isto na web como share para teste como poderei distribuir que boa parte da regra de negócio está no banco e não tenho como proteger isto aos olhares dos usuários.
Responder
Clique aqui para fazer login e interagir na Comunidade :)
