Firebird protecao de metadata

Download Firebird protecao de metadata

Post on 11-Jun-2015

345 views

Category:

Documents

0 download

TRANSCRIPT

Protegendo sua base de dados Interbase ou FirebirdReceita de bolo para proteger meta-dados do seu banco de dados Interbase/Firebird dos olheiros de planto. Este artigo tem particular importncia aqueles que desenvolvem softwares para terceiros, pois permitir estes que possam distribuir livremente seus softwares baseados em banco de dados Firebird sem preocupar-se com aquelas pessoas que aproveitam cdigo de terceiros e promovem seus sistemas baseando-se nos cdigos obtidos, isto o que chamamos de pirataria indstrial.Entendendo o ProblemaO administrador de um servidor Interbase/FireBird, o tal SYSDBA tem privilgios especiais para acessar todos os objetos deste servidor, inclusive obter o cdigo fonte de cada um deles, esse cdigo fonte chamado de script DML ou Metadados. O tpico administrador de sistemas, recorre ao script meta-dados para muitas utilidades : alterar regras estabelecidas, criar novos objetos a partir de outro objeto, ver furos de segurana dentre muitas outras cosas. Esse um timo recurso do Firebird, porm cria um problema para aqueles que desenvolvem programas para terceiros. Uma empresa pode investir muito tempo e esforo de desenvolvimento usando o Firebird e quando for distribui-lo seus clientes, estar distribuindo tambm o codigo fonte de seu banco de dados, ento todo o "know-how" tecnolgico por trs de sua base de dados podem ser recuperados por quem tiver acesso ele. Imagine a situao de seu banco de dados cair na mo de seu concorrente, j pensou? Seu concorrente absorveria todo o seu "know-how", descobriria todos os segredos de sua base de dados, a saber : ! as triggers que harmoniosamente disparam procedimentos automaticamente, como por exemplo requisies de compra de material, cancelamento de dbitos, etc...; ! as views que juntam tabelas diferentes produzindo uma viso nica de um ou vrios processos; ! as stored procedures que guardam procedimentos para serem executados no lado do servidor, aumentando assustadoramente a velocidade em operaes como calcular folha de pagamento, controlar nveis de estoque, etc... Diante dessa situao, surge a seguinte pergunta: Como proteger o cdigo fonte (Metadados) dos objetos criados no Firebird ? Antes de partirmos para a resposta, entendamos primeiro a forma em que os objetos do Firebird so armazenados.Os objetos do Firebird observados de um outro nguloQuando voce cria um objeto no Firebird atravs de comandos SQL, o seu objeto registrado em tabelas de sistema. Tabelas de Sistema so tabelas que ficam escondidas do usurio normal e s podem ser acessadas pelo administrador (SYSDBA). Essas tabelas possuem a tarefa de registrar todas as informaes lgicas sobre o banco de dados e o relacionamento de cada objeto criado com os demais objetos. Analisada as informaes nessas tabelas ento formado o nexo entre todas as atividades do sistema, o grau de parentesco dos dados, relacionamento de chaves, tipagem, permisses, etc.... Tome por exemplo o seguinte cdigo de stored procedure: CREATE PROCEDURE "SP_VERSION" RETURNS( "VERSION" VARCHAR(30)) AS BEGIN VERSION='1.0BR'; SUSPEND; END As tabelas de sistema iro registrar esse objeto "stored procedure" na tabela RDB$PROCEDURES com informaes relevantes tal como : nome, quantidade de parmetros de entrada e sada, proprietrio, permisses, dependncias com outros objetos, etc... Alm da tabela de sistema RDB$PROCEDURES que guardam as "stored procedures", temos tambm RDB$TRIGGERS guardando as "triggers" e RDB$RELATIONS guardando as "views". Essas 3 tabelas em si guardam o ovo de ouro dos desenvolvedores, pois aquelas VIEWS com JOINS enormes, aquelas regras to bem estruturadas com TRIGGERS, ou todos os procedimentos internos to bem entesourados nas PROCEDURES so quase que todo o projeto do desenvolvedor, o resto foi apenas a criao de aplicativos com telas para acrescentar, acessar e processar tais objetos partir da mesa do usurio.Enfim, como proteger o Metadados dos objetos criados no Firebird ?Acontece que as 3 tabelas supracitadas: RDB$PROCEDURES, RDB$TRIGGERS e RDB$RELATIONS tambm guardam dentro de s script's DML's que geraram cada objeto dentro do banco de dados. Essas tabelas possuem dois campos que nos interessam : Um campo do tipo BLOB subtype 1, isto , um MEMO onde fica o script DML cujo contedo puro texto. E outro campo, desta vez no formato binrio (Blob subtype 2) tambm conhecido como BLR (Binary Language Representation) que contm o mesmo objeto s que pr-compilado. Todo nosso problema com o campo memo-textual onde fica guardado o script DML, pois este quando lido descobre o cdigo fonte de nosso objeto. lendo este campo que aplicativos como IBConsole, IBExpert,... conseguem fazer uma engeria reversa nos objetos e obter o codigo fonte. O campo do tipo BLR no deve ser tocado ou mexido pois isso faria com que o codigo pr-compilado no correspondesse ao respectivo script DML, o que acabaria sendo um desastre pois apenas o cdigo pr-compilado BLR executado no Firebird.Logo, se pararmos para pensar um pouco.... e se eu substitui-se esse campo do tipo MEMO com um texto qualquer e no mexesse no campo BLR? EUREKA! Os programas que recuperam scripts DML recuperariam apenas o texto que eu desejar, e isso no faria tais objetos perderem sua funcionalidade. Como j diria o Chaves : isso! isso! isso!... Assim voc pode dar adeus a espionagem indstrial. Os exemplos que irei passar a seguir, iro substituir o meta-dados de stored procedures,views e triggers por NULL (nulos), isto , sem nenhum cdigo fonte. Porm nada impede que voce possa substituir a palavra NULL por algo mais elegante como "Protegido por lei de copyright". O exemplo abaixo tambm funciona para o Interbase, porm se voce for substituir a palavra NULL por outro texto, ter de tomar o seguinte cuidado : o Firebird aceita um simples update de um campo Memo (blob subtype 1) por uma string sem nenhuma restrio, no entanto, para fazer isso no Interbase seria preciso uma UDF para converter string para blob-memo (algo do tipo StringToBlob).Mos obra : Aviso aos despreocupados : Como est escrito na Bblia dos programadores : "Felizes os pessmistas, pois estes fazem backup". Ao executar os procedimentos logo adiante atente-se para o fato de que voce perder todos os scripts DML de sua base de dados (stored procedures, triggers e views), ento no esquea da palavra mgica que pode salvar seu emprego : backup !.Escondendo o script DML de stored procedures (procedimentos armazenados) Como j foi dito antes, as stored procedures ficam armazenadas na tabela RDB$PROCEDURES, essa tabela possui um registro para cada stored procedure existente e contm informaes como nmeros de parmetros de entrada e sada, proprietrio da tabela, codigo fonte, codigo binrio prcompilado,etc... O campo que nesta tabela nos interessa o campo RDB$PROCEDURE_SOURCE que contm o codigo fonte DML da stored procedure. No toque e no mexa no campo RDB$PROCEDURE_BLR que contm o cdigo pr-compilado, seno a funcionalidade da stored procedure vai pro espao, isto , deixaria de funcionar. Ento vamos ao comando SQL : UPDATE rdb$procedures SET rdb$procedure_source = NULL WHERE ((rdb$system_flag = 0) OR (rdb$system_flag IS NULL)) Segundo consta nos manuais do Interbase (o qual o Firebird derivado), a coluna rdb$system_flag igual a 0 (zero) indica ao Firebird que o objeto, isto , a stored procedure foi criada pelo usurio com comandos normais usando SQL, isto , determina a existncia de cdigo fonte. Imagino que todos os rdb$system_flag seriam igual a zero, a menos que a uma stored procedure tenha sido criada apenas para uso interno do prprio Firebird.Escondendo o script DML de triggers (gatilhos) Semelhante a stored procedures, as triggers tambm possuem sua prpria tabela de sistema e esta se chama RDB$TRIGGERS, e o campo que guarda o codigo fonte e binrio so respectivamente RDB$TRIGGER_SOURCE e RDB$TRIGGER_BLR. O campo que nos interessa apenas o RDB$TRIGGER_SOURCE: UPDATE rdb$triggers SET rdb$trigger_source = NULL WHERE ((rdb$system_flag = 0) OR (rdb$system_flag IS NULL)) AND (rdb$trigger_name NOT IN (SELECT rdb$trigger_name FROM rdb$check_constraints)) Novamente, usaremos o campo rdb$system_flag para apenas mexermos nas triggers que ns mesmos criamos, imagino que deva haver algumas que pertencem ao prprio Firebird que no devem ser tocadas. A parte grifada em vermelho para no mexer naquelas triggers que so auto-geradas pelo Firebird quando adicionamos uma restrio a um campo, o tal CHECK CONSTRAINT. Esses "CONSTRAINT" vo gerar triggers internas, eu pessoalmente no apagaria o cdigo fonte destes, mas se voce desejar faze-lo basta remover a parte em vermelho.Escondendo o script DML de views (vises) As views tambm possuem sua prpria tabela de sistema e ela se chama RDB$RELATIONS, e como os seus companheiros de banco de dados : stored procedures e triggers, tambm possuem o campo RDB$VIEW_SOURCE para armazenar o codigo fonte, e o campo RDB$VIEW_BLR para armazenar o codigo pr-compilado do objeto. O processo para se eliminar o codigo fonte das views praticamente o mesmo que fizemos com os outros objetos : UPDATE rdb$relations SET rdb$view_source = NULL WHERE (rdb$system_flag = 0)Funciona ? Quando for executar os procedimentos descritos acima, ir notar que ainda ser possivel recuperar os cabealhos dos scripts DML, no entanto, tente analisar o codigo at o final e perceber que o contedo do script no estar l. Por exemplo, o cabealho de uma stored procedure sempre estar disponvel porm o contedo da mesma no ir aparecer simplesmente porque no existe.Cuidados com cpias de segurana (Backup e Restore)Lembre-se de que quando seus clientes forem fazer uma cpia de segurana de suas bases de dados que eles no estaro fazendo cpias de segurana das triggers, views e stored procedures, apenas os dados em s estaro sendo copiados, isto : tabelas, indices, constraints, domains, relacionamentos e todos os outros objetos com excesso de triggers, views e stored procedures que j lhe falei.Suponhamos que um cliente ligue para voc e diga que vai precisar restaurar uma cpia de segurana (backup), o que voc far ento ? Voce dever ento recriar manualmente as triggers, views e stored procedures aps a restaurao dos dados, isto poder ser feito atravs de um aplicativo permite acessar remotamente a mquina do usurio como por exemplo o VNC, ou ento atravs do prprio IBConsole sobre a internet. Para facilitar ainda mais sua vida bom voce preparar um programa que crie ou atualize tais objetos e em seguida remova os meta-dados novamente sem precisar de nenhuma interveno humana. Nota do Autor : Este pequeno documento d uma viso interessante sobre os objetos do Firebird. Elas no so uma maneira de hackear o banco de dados, pois as informaes obtidas acima constam na documentao do prprio Interbase 6 (do qual o Firebird deriva-se), porm pode acontecer que fique desatualizado com as futuras verses do FiredBird (atualmente Firebird 1.0.826), portanto tenha sempre a mo o cdigo fonte original de seu banco de dados. Referencias: Documentao: InterBase 6 Open SourceAutor : Gladiston Santana Data : 05-Jul-2002 Revisto em: 01-Out-2002Artigo Original Gladiston Santana (Colaborador da CFLP) Comunidade Firebird de Lngua Portuguesa Visite a Comunidade em: http://www.comunidade-firebird.org A Comunidade Firebird de Lngua Portuguesa foi autorizada pelo Autor do Original para divulgar este trabalho