Eventualmente pode ser necessário implementarmos algumas regras de negócios diretamente em nossas bases de dados. Isto normalmente ocorre quando se tem um sistema um pouco maior, eventualmente um ERP, onde vários módulos se conectam através do mesmo banco de dados, inclusive fazendo uso de um mesmo conjunto de dados, funções, procedures, views, etc. Desta forma conseguimos concentrar parte da codificação, evitando replicar códigos que seriam utilziados por vários módulos. Isto de certa forma traz um pouco mais de legibilidade e até mesmo um pouco mais de desempenho em alguns casos.

O revés neste tipo de caso, onde trechos importantes de códigos ficam armazenados diretamente no banco de dados, pode ocorrer quando algum tipo de acesso não autorizado ocorre. Este possível invasor poderia ter acesso não só ha informações, a princípio sigilosas, mas também às regras de negócios presentes na base de dados. E isto pode comprometer o sistema como um todo, facilitando até mesmo a sua engenharia reversa.

Na maioria dos "clientes" de bancos de dados podemos perceber que ao acessar uma view, uma procedure ou uma function estas ferramentas nos exibem a estrutura deste recurso, a codificação original deste elemento. Isto é sem sombra de dúvidas um atrativo ao desenvolvedor. Mas nas mãos de um eventual invasor isto pode ser bastante negativo. Isto ocorre também com o Firebird, foco desta dica de hoje. Mas como podemos ter um controle mais adequado com relação a este tipo de situação?

Especificamente com relação ao Firebird, a codificação das views, procedures e functions ficam armazenadas em campos específicos de tabelas internas. Na verdade isto ocorre também com a maioria dos outros bancos de dados, mas vamos focar especificamente no Firebird por hoje. Por exemplo, o código das consultas (views) fica armazenado no campo "RDB$VIEW_SOURCE" da tabela interna "RDB$RELATIONS". Já a estrutura do código das procedures fica armazenados no campo "RDB$PROCEDURE_SOURCE" da tabela interna "RDB$PROCEDURES". Por fim, o campo "RDB$FUNCTION_SOURCE" armazena o código das funções (functions) na tabela "RDB$FUNCTIONS". Desta forma podemos utilizar o artifício de "setar" estes campos com valor "NULL" para ao menos complicar um pouco eventuais tentativas de engenharia reversa. A ações principais destes elementos, sejam as views, procedures ou functions não ficaram prejudicadas, já que o código responsável por suas execuções ficam armazenados em campos diferentes, em formato binário. Assim, ainda que "ocultemos" nossos códigos internos ao banco de dados as suas funções originais seguiram normalmente. Mas lembre-se sempre de armazenar o código orignal fora do banco de dados, em local seguro, como um backup para quando for necessário a refatoração deste código.

O vídeo abaixo ilustra o que foi exposto.

Espero que esta dica seja útil.

Artigos relacionados