Segurança em Banco de Dados 1 Prof: Thiago Moraes Martins Bacharel em Sistemas de Informa ç ão P ó s-Gradua ç ão Software Livre Aplicado P ó s-Gradua ç.

Apresentação em tema: "Segurança em Banco de Dados 1 Prof: Thiago Moraes Martins Bacharel em Sistemas de Informa ç ão P ó s-Gradua ç ão Software Livre Aplicado P ó s-Gradua ç."— Transcrição da apresentação:

1 Segurança em Banco de Dados 1 Prof: Thiago Moraes Martins Bacharel em Sistemas de Informa ç ão P ó s-Gradua ç ão Software Livre Aplicado P ó s-Gradua ç ão Analista de Sistemas P ó s-Gradua ç ão Metodologia do Ensino Superior Mestrado Engenharia de Software (Andamento) Certificado ITIL Certificado COBIT Certificado CWSP

2 Segurança em Banco de Dados 2 Refactoring de Banco de Dados

3 Segurança em Banco de Dados 3 Para que serve: As técnicas de refactoring de banco de dados permitem evoluir de forma segura o design de um esquema em pequenos passos. Além disso, elas ainda podem ser utilizadas para apoiar o desenvolvimento de software evolutivo. Em que situação o tema útil: Além de serem muito úteis na migração de bancos de dados legados, as técnicas apresentadas neste artigo permitem alterações em esquemas que já estejam em produção. Sendo esta uma das grandes dificuldades das empresas de desenvolvimento de software

4 Segurança em Banco de Dados 4 As empresas de desenvolvimento de software têm evoluído constantemente. Muitas delas devem isto às novas e modernas metodologias ágeis que defendem a construção do software de maneira incremental e iterativa. Entretanto, disponibilizar sistemas de informação com qualidade em ciclos cada vez menores, ainda é uma missão desafiadora para muitas delas. Isto porque, é preciso garantir que a cada entrega, o sistema não perderá as suas funcionalidades e continuará sem erros. Além do mais, estas metodologias não prevêem a mesma iteratividade para o banco de dados. Para finalizar, algumas destas empresas ainda utilizam bancos de dados legados e não migram para sistemas mais novos por diversos motivos, dentre eles:

5 Segurança em Banco de Dados 5 - Complexidade; - Alto custo; - Mudança de cultura da empresa; - Falta de conhecimento dos desenvolvedores; - Mudanças de paradigmas dos DBAs.

6 Segurança em Banco de Dados 6 O antes e o depois Os consultores de informática: Pramod J. Sadalage e Scott W. Ambler criaram algumas técnicas para refatoração de banco de dados. Estas técnicas têm como base os mesmos objetivos das metodologias ágeis: minimizar o risco pelo desenvolvimento de software em períodos curtos, chamados de iteração, os quais duram de uma a quatro semanas. Cada iteração é como um projeto de software em miniatura, incluindo todas as tarefas necessárias para implantá-lo: planejamento, análise de requisitos, projeto, codificação, teste e documentação.

7 Segurança em Banco de Dados 7 É neste cenário que surge a figura do DBA ágil. Diferente do DBA comum, este participa de todas as iterações do projeto, planejando o esquema do banco de dados e apoiando a equipe de desenvolvimento.

8 Segurança em Banco de Dados 8 Figura 1. Modelo Cascata.

9 Segurança em Banco de Dados 9 O que é Refactoring? Outra conseqüência é a melhora no entendimento do código, o que facilita a manutenção e evita a inclusão de defeitos. É fundamental que o sistema de software possua testes automatizados para realizar refatorações. Dessa forma será possível garantir que o comportamento externo não foi alterado.

10 Segurança em Banco de Dados 10 O que é Refactoring de Banco de Dados? Refactoring de Banco de Dados não é mágica! Consiste em simples mudanças no esquema do banco de dados (tabelas, views, trigger, procedures, etc.) que melhoram o design sem alterar a semântica e o significado dos dados que já estão persistidos. O processo de refactoring de banco de dados define a forma de evoluir de maneira segura um esquema em pequenos passos (incremental e evolutivamente). Ela também fornece uma estratégia coerente para organizações que querem migrar seus bancos de dados legados para outros mais modernos.

11 Segurança em Banco de Dados 11 Figura 2. Modelo Espiral.

12 Segurança em Banco de Dados 12 Conceitualmente, refactoring de banco de dados é mais difícil que refactoring de código. Isto porque, refactoring de código precisa apenas manter a semântica comportamental, enquanto refactoring de banco de dados, além de ter esta obrigação, ainda precisa assegurar a semântica informacional. A complexidade de um projeto de refactoring de banco de dados pode ser ainda maior em ambientes onde a arquitetura de acesso aos dados é altamente acoplada, como o exemplo da Figura 3.

13 Segurança em Banco de Dados 13 Figura 3. Modelo complexo de arquitetura de acesso aos dados.

14 Segurança em Banco de Dados 14 Por outro lado, algumas empresas têm o privilégio de possuir uma arquitetura mais simples, onde apenas uma aplicação acessa o banco de dados, permitindo assim, a refatoração de ambos em paralelo. Estas aplicações são conhecidas como “standalone” ou sistemas “stovepipe”.

15 Segurança em Banco de Dados 15 Por que utilizar Refactoring de Banco de Dados? 1. Reparar bancos de dados legados: permite evoluir de forma segura o design do esquema em pequenos passos, tornando-se uma técnica importante para a melhoria do patrimônio legado dentro das organizações. Esta é, sem duvidas, muito menos arriscada do que a abordagem conhecida como “big bang”, onde as melhorias são aplicadas de uma só vez em produção. Além disso, é muito melhor do que “vamos migrar e ver no que dá”; 2 Apoiar o desenvolvimento de software: usando estas técnicas pode-se apoiar no processo de desenvolvimento de softwares evolutivos, incluindo Rational Unified Process (RUP),

16 Segurança em Banco de Dados 16 O que deve ser refatorado? - Tabela genérica: quando uma tabela está sendo usado para armazenar vários tipos de entidades, é provável que exista uma falha de projeto. Um exemplo é a tabela de pessoa, onde são inseridas informações de clientes e de fornecedores. O problema é que cliente e fornecedor têm as suas diferenças, e desta forma, a tabela conterá colunas que só serão preenchidas quando o tipo da pessoa for um ou outro; - Coluna genérica: desta mesma forma, se uma coluna está sendo usada para vários fins, é provável que exista um código extra para identificar os dados contidos nela.

17 Segurança em Banco de Dados 17 Um exemplo é uma coluna da tabela de pessoa usada para armazenar data de nascimento de um cliente ou a data de admissão de um empregado. A única forma saber se o dado contido nesta coluna é uma data de admissão ou uma data de nascimento, é verificando outra coluna que identifique a pessoa. Agora suponha que seja necessário adicionar a data de nascimento do empregado, se for criado uma nova coluna, a tabela ficará ainda mais redundante; -Dados redundantes: os dados redundantes é um problema grave nos bancos de dados operacionais, pois quando os dados são armazenados em vários locais, a possibilidade de inconsistência é muito grande. É comum, por exemplo, ter informações de clientes armazenadas em locais diferentes, e no momento em que estes dados necessitarem de manutenção será difícil saber qual deles é o correto;

18 Segurança em Banco de Dados 18 - Dados redundantes: os dados redundantes é um problema grave nos bancos de dados operacionais, pois quando os dados são armazenados em vários locais, a possibilidade de inconsistência é muito grande. É comum, por exemplo, ter informações de clientes armazenadas em locais diferentes, e no momento em que estes dados necessitarem de manutenção será difícil saber qual deles é o correto;

19 Segurança em Banco de Dados 19 -Tabelas com muitas linhas: tabelas muito grandes são fortes candidatas a causar problemas de desempenho. O exemplo mais comum é a tabela de movimento de estoque, onde são armazenadas todas as movimentações dos produtos. Neste caso, o correto seria criar tabelas de histórico para guardar os dados antigos, deixando a vista apenas os registros de determinado período; -Modelo intocável: se você tem medo de alterar o modelo do seu banco de dados é porque certamente ele precisa ser refeito. O medo da mudança é uma boa indicação de que você tem sérios riscos técnicos em suas mãos, que só vão piorar ao longo do tempo.

20 Segurança em Banco de Dados 20 Antes de começar Antes de começar um projeto de refactoring de banco de dados, leve em consideração as recomendações a seguir: Verifique se o refactoring é mesmo necessário, pois talvez a estrutura do modelo atual esteja correta. É comum os desenvolvedores discordarem, ou simplesmente não compreender o projeto existente de um banco de dados. Este mal-entendido poderá levá-los a acreditar que o projeto precisa ser alterado quando ele realmente não precisa.

21 Segurança em Banco de Dados 21 O DBA deve ter um bom conhecimento do esquema do banco de dados, e em casos de haver sistemas externos acessando-o, ele deve saber quem contatar para discutir questões técnicas e tomar as medidas cabíveis. Além disso, o DBA, por ter participado de diversos projetos relacionados ao esquema do banco de dados, conhece o panorama global da empresa, possuindo uma visão importante que pode não estar aparente do ponto de vista dos desenvolvedores;

22 Segurança em Banco de Dados 22 - É preciso ter em mente que nenhuma estrutura deve ser tão rígida a ponto de ser inalterável, isto porque, pequenas melhorias sempre irão acontecer; - Divida o seu projeto de refactoring em pequenas etapas para facilitar o controle e a compreensão de todos os profissionais envolvidos. Entretanto, isto exigirá um controle rigoroso sobre o versionamento das alterações. Por exemplo: imagine que em uma etapa qualquer, você altere o nome da coluna de uma tabela, e algumas semanas depois, seja necessário mover a mesma coluna para outra tabela. Se estas alterações não forem aplicadas no momento adequado e não estiverem versionadas, a última refatoração poderá ser executada antes da primeira;

23 Segurança em Banco de Dados 23 -Evite duplicações de código SQL. Utilize um framework de persistência para encapsular o acesso ao banco de dados.

24 Segurança em Banco de Dados 24 Qual a melhor estratégia de refatoração? 1. Avaliação do impacto: antes de fazer qualquer alteração na estrutura, deve-se avaliar o tamanho do impacto, tanto interno quanto externo, ou seja, descobrir todas as views, triggers, procedures, constraints e sistemas que serão afetados com a mudança; 2. Definição do período de transição: após fazer a avaliação acima, será possível definir com maior precisão o período de transição. Entretanto, deve-se fazer um controle rigoroso para garantir que os prazos estabelecidos serão seguidos; 3. Criação e execução de testes: antes de alterar o modelo é preciso garantir que atualmente ele está funcionando. Crie testes automatizados para facilitar a identificação e correção dos impactos causados pelas refatorações;

25 Segurança em Banco de Dados 25 4. Executar a refatoração: crie os scripts necessários para aplicar a refatoração e adicione os comentários nas colunas, tabelas e triggers que serão removidas após o período de transição; 5. Execute os testes: antes de anunciar as refatorações feitas, é preciso garantir que nada do que estava funcionando deixou de funcionar. Para isto, execute os testes criados antes da refatoração e caso algum deles falhe, faça as correções necessárias; 6. Alteração das dependências internas e externas: se for possível, faça as alterações necessárias nos objetos internos (triggers, procedures, etc.) e externos (sistemas, outros bancos de dados, etc.) em paralelo. Caso contrário, prefira iniciar as alterações pelos objetos internos, já que estão mais próximos do seu domínio.

26 Segurança em Banco de Dados 26 Categorias de refatoração de banco de dados As técnicas de refactoring de banco de dados estão divididas em categorias. Neste artigo serão abordadas as cinco principais. São elas: 1.Estrutural; 2.Qualidade dos dados; 3.Integridade referencial; 4.Arquitetura; 5.Métodos.

27 Segurança em Banco de Dados 27 Estrutural A categoria estrutural engloba mudanças em estruturas de tabelas e/ou views, como: - Renomear colunas, tabelas, views, functions e procedures; - Introduzir colunas calculadas para melhorar a performance dos sistemas; - Introduzir surrogate keys para aumentar a consistência dos dados; - Mesclar colunas e tabelas para evitar redundâncias; - Mover coluna para outra tabela; - Particionar tabelas com muitas colunas para melhorar a coesão do esquema do banco de dados;

28 Segurança em Banco de Dados 28 -Substituir associações um para muitos por tabelas associativas. -Ao implementar a refactoring estrutural, leve em consideração alguns impedimentos comuns que certamente aparecerão. Dentre os quais se podem listar: - Triggers circulares: em quase todas as refactorings que alteram a estrutura do modelo, é comum o uso de triggers para controlar o sincronismo dos dados. Em alguns casos, podem-se ter duas ou mais triggers, uma disparando a outra. E se não houver um controle rigoroso, elas entrarão num loop infinito comprometendo o desempenho do banco de dados; - Objetos do banco que acessam a tabela: é muito comum, durante este tipo de refatoração, deixar para trás alguns objetos que fazem referências às tabelas alteradas. Exemplos: views, triggers, stored procedures, etc.

29 Segurança em Banco de Dados 29 Qualidade de dados As implementações feitas nesta categoria visam melhorar a qualidade das informações contidas no banco de dados. São elas: - Adicionar tabelas de consulta; - Padronização de siglas; - Aplicar tipos padrões para evitar, por exemplo, que em uma tabela uma informação seja do tipo varchar e em outra ela seja do tipo numérico; - Adicionar ou remover chaves estrangeiras; - Adicionar ou remover valores padrões em colunas; - Mover dados de uma tabela para outra.

30 Segurança em Banco de Dados 30 Integridade referencial As implementações feitas nesta categoria visam garantir a integridade dos dados. São elas: - Adicionar ou remover chave estrangeira; - Adicionar trigger para coluna calculada; - Adicionar exclusão em cascata; - Adicionar trigger para armazenar em log as alterações.

31 Segurança em Banco de Dados 31 - Adicionar métodos CRUD (procedures para inserção, consulta, atualização e exclusão); - Adicionar encapsulamento à tabela através de views; - Adicionar métodos de cálculos; - Adicionar tabelas apenas para leituras; - Migrar métodos dos sistemas externos para o banco de dados. Arquitetura As implementações feitas nesta categoria visam melhorar de forma global as interações entre os programas externos e o banco de dados. São elas:

32 Segurança em Banco de Dados 32 Métodos Como o próprio nome sugere, as refatorações desta categoria têm por objetivo melhorar a qualidade de stored procedures, triggers ou funções armazenadas no banco de dados. Por razões de simplicidade, Ambler se refere a estes três tipos de funcionalidade simplesmente como métodos. As implementações comuns desta categoria são: - Adicionar ou remover parâmetros dos métodos; - Renomear métodos; - Reordenar os parâmetros dos métodos; - Substituir vários métodos por um método genérico; - Substituir um método genérico por vários outros métodos.

33 Segurança em Banco de Dados 33 FIM