OFF - PROTEGER DADOS
Bom, partindo do princÃpio:
1. - Um bom projeto de banco de dados é capaz por sà mesmo de administrar todas as suas informações. Dessa forma, com [Ô]apenas[Ô] o banco de dados, qualquer um desenvolve os aplicativos, com ou sem conhecimento de programação. Isso implica em que de fato a base de dados bem formada é sempre muito mais relevante do que qualquer código fonte.
2. - [Ô]Proteger[Ô] uma base de dados contra engenharia reversa é uma funcionalidade que, nativamente, não existe em nenhum mecanismo, seja SQL Server, Oracle, MySQL etc.
3. - Criptografia não resolve o problema de forma alguma, aliás, passa bem longe disso. A criptografia ajuda a proteger os dados, e não a base de dados.
4. - De fato, ainda que uma aplicação seja de sua autoria, os dados administrados por essa aplicação são de propriedade do cliente. Isso, contudo, não significa que ele possa acessar o banco de dados por outros meios que não sejam a sua aplicação. Isso quer dizer [Ô]apenas[Ô] que nem você nem sua aplicação podem tornar públicas as informações salvas pelo cliente.
Bom, agora que os pontos acima foram colocados, vamos ao foco em questão: Proteger a idéia que está contida pela estrutura da base de dados. Como foi dito, nenhum mecanismo dispõe de funcionalidades nativas para esse fim em especial. No entanto, há várias ações que podem reduzir substancialmente as chances dessa ocorrência, seja por conta do trabalho que implica, seja pela necessidade de ferramentas que requerem conhecimento mais especializado. Vamos á elas:
A. - Embarcar na aplicação uma base de dados que não requeira service (Serverless Database). Há vários mecanismos de dados que não necessitam de servidor, como, por exemplo, o SQL Server Compact, o SQLite, o db4o, o MS-Access e o dBase, só para citar alguns. Inicialmente, ao dispensar um servidor, a base de dados passa á ser acessada apenas por meio do aplicativo. Sem outros acessos aos dados e ás estruturas, a base está menos vulnerável á cópias. é necessário considerer fatores como, por exemplo, a popularidade do mecanismo, assim, por exemplo, uma base de dados MS-Access poderá ser acessada por qualquer instalação posterior do MS-Office. Para aumentar a segurança, então, utiliza-se a senha de pasta ou a senha de arquivo, ou até ambas.
B. - Gerir você mesmo o servidor de dados, dispensando impreterivelmente as contas-padrão e de sistema. Você pode instalar o servidor de dados em uma instância que não seja acessÃvel por contas de sistema ou contas-padrão. Apenas você e seu aplicativo conseguem acesso á essa instância, não-integrada ao AD.
C. - Este procedimento é bem mais simples, e bastante eficiente: Depois de checar que a aplicação funciona 100% como esperado, complique! Nós temos a tendência, como humanos, de lidar com tabelas, consultas e campos mediante seus nomes. Isso simplifica a compreensão e facilita a manutenção. Assim, por exemplo, podemos ter uma tabela chamada [Ô]Clientes[Ô] com os campos [Ô]Nome[Ô], [Ô]Nascimento[Ô] e [Ô]RG[Ô]. Fácil de interpretar, portanto. Agora, o passo seguinte é usar uma série de [Ô]Replaces[Ô], no código fonte e no script de dados. Se a mesma tabela se chamasse [Ô]C01BCA8CA76D4554B3A8EC0F340239AC[Ô] e possuisse os campos [Ô]95643DBA3520401987C7835104336997[Ô], [Ô]6F4828A9D00D4090BC15E59A29BCE808[Ô] e [Ô]D6BE4EA3B2AE4AF88FD58353AB103169[Ô], seria bem mais complicado para interpretar e portanto, de proceder á engenharia reversa, mas no entanto, a aplicação (que já foi homologada) funcionaria exatamente da mesma forma, mantendo funcionalidade, desempenho e fiabilidade originais.
Há muitos outros meios, além de inúmeros procedimentos, que ajudam no sentido de proteger a idéia contida em uma base de dados. Isso seria material mais do que suficiente para encher alguns livros, e não é o escopo do forum. Mas acho que somente o pouco que foi dito consegue levar alguma luz á questão.
1. - Um bom projeto de banco de dados é capaz por sà mesmo de administrar todas as suas informações. Dessa forma, com [Ô]apenas[Ô] o banco de dados, qualquer um desenvolve os aplicativos, com ou sem conhecimento de programação. Isso implica em que de fato a base de dados bem formada é sempre muito mais relevante do que qualquer código fonte.
2. - [Ô]Proteger[Ô] uma base de dados contra engenharia reversa é uma funcionalidade que, nativamente, não existe em nenhum mecanismo, seja SQL Server, Oracle, MySQL etc.
3. - Criptografia não resolve o problema de forma alguma, aliás, passa bem longe disso. A criptografia ajuda a proteger os dados, e não a base de dados.
4. - De fato, ainda que uma aplicação seja de sua autoria, os dados administrados por essa aplicação são de propriedade do cliente. Isso, contudo, não significa que ele possa acessar o banco de dados por outros meios que não sejam a sua aplicação. Isso quer dizer [Ô]apenas[Ô] que nem você nem sua aplicação podem tornar públicas as informações salvas pelo cliente.
Bom, agora que os pontos acima foram colocados, vamos ao foco em questão: Proteger a idéia que está contida pela estrutura da base de dados. Como foi dito, nenhum mecanismo dispõe de funcionalidades nativas para esse fim em especial. No entanto, há várias ações que podem reduzir substancialmente as chances dessa ocorrência, seja por conta do trabalho que implica, seja pela necessidade de ferramentas que requerem conhecimento mais especializado. Vamos á elas:
A. - Embarcar na aplicação uma base de dados que não requeira service (Serverless Database). Há vários mecanismos de dados que não necessitam de servidor, como, por exemplo, o SQL Server Compact, o SQLite, o db4o, o MS-Access e o dBase, só para citar alguns. Inicialmente, ao dispensar um servidor, a base de dados passa á ser acessada apenas por meio do aplicativo. Sem outros acessos aos dados e ás estruturas, a base está menos vulnerável á cópias. é necessário considerer fatores como, por exemplo, a popularidade do mecanismo, assim, por exemplo, uma base de dados MS-Access poderá ser acessada por qualquer instalação posterior do MS-Office. Para aumentar a segurança, então, utiliza-se a senha de pasta ou a senha de arquivo, ou até ambas.
B. - Gerir você mesmo o servidor de dados, dispensando impreterivelmente as contas-padrão e de sistema. Você pode instalar o servidor de dados em uma instância que não seja acessÃvel por contas de sistema ou contas-padrão. Apenas você e seu aplicativo conseguem acesso á essa instância, não-integrada ao AD.
C. - Este procedimento é bem mais simples, e bastante eficiente: Depois de checar que a aplicação funciona 100% como esperado, complique! Nós temos a tendência, como humanos, de lidar com tabelas, consultas e campos mediante seus nomes. Isso simplifica a compreensão e facilita a manutenção. Assim, por exemplo, podemos ter uma tabela chamada [Ô]Clientes[Ô] com os campos [Ô]Nome[Ô], [Ô]Nascimento[Ô] e [Ô]RG[Ô]. Fácil de interpretar, portanto. Agora, o passo seguinte é usar uma série de [Ô]Replaces[Ô], no código fonte e no script de dados. Se a mesma tabela se chamasse [Ô]C01BCA8CA76D4554B3A8EC0F340239AC[Ô] e possuisse os campos [Ô]95643DBA3520401987C7835104336997[Ô], [Ô]6F4828A9D00D4090BC15E59A29BCE808[Ô] e [Ô]D6BE4EA3B2AE4AF88FD58353AB103169[Ô], seria bem mais complicado para interpretar e portanto, de proceder á engenharia reversa, mas no entanto, a aplicação (que já foi homologada) funcionaria exatamente da mesma forma, mantendo funcionalidade, desempenho e fiabilidade originais.
Há muitos outros meios, além de inúmeros procedimentos, que ajudam no sentido de proteger a idéia contida em uma base de dados. Isso seria material mais do que suficiente para encher alguns livros, e não é o escopo do forum. Mas acho que somente o pouco que foi dito consegue levar alguma luz á questão.
Tópico encerrado , respostas não são mais permitidas