Integridade de dados e administração de segurança em SGBDs

6.513 visualizações

Publicada em

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
6.513
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
192
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Integridade de dados e administração de segurança em SGBDs

  1. 1. Semana da Computação UFSCar 31/05 a 02/jun de 2010 Integridade de dados e administração de segurança em SGBDs Prof. Daniel dos Santos Kaster Dept. Computação – Universidade Estadual de Londrina (UEL) dskaster@uel.br Prof. Daniel dos Santos Kaster © 2010 1
  2. 2. Conteúdo Introdução integridade e consistência de dados Segurança de dados Disponibilidade de dados Prof. Daniel dos Santos Kaster © 2010 2
  3. 3. Introdução Na era da informação, os dados são a porção mais valiosa das organizações. Portanto, é preciso que estejam seguros e disponíveis. Além disso, o acesso aos dados precisa ser eficiente, porém controlado, garantindo a integridade. Prof. Daniel dos Santos Kaster © 2010 3
  4. 4. Introdução “O cofre não pode ser mais caro do que o tem dentro.” Prof. Daniel dos Santos Kaster © 2010 4
  5. 5. Existe diferença entre desenvolver e desenvolver! Prof. Daniel dos Santos Kaster © 2010 5
  6. 6. Existe diferença entre desenvolver e desenvolver! Desenvolver um aplicativo Prof. Daniel dos Santos Kaster © 2010 6
  7. 7. Existe diferença entre desenvolver e desenvolver! Desenvolver um aplicativo Desenvolver um aplicativo que funcione Prof. Daniel dos Santos Kaster © 2010 7
  8. 8. Existe diferença entre desenvolver e desenvolver! Desenvolver um aplicativo Desenvolver um aplicativo que funcione Desenvolver um aplicativo que funcione e seja robusto com relação ao seu uso típico Prof. Daniel dos Santos Kaster © 2010 8
  9. 9. Existe diferença entre desenvolver e desenvolver! Desenvolver um aplicativo Desenvolver um aplicativo que funcione Desenvolver um aplicativo que funcione e seja robusto com relação ao seu uso típico Desenvolver um aplicativo que funcione e seja robusto com relação ao seu uso típico e tentativas de uso malicioso Prof. Daniel dos Santos Kaster © 2010 9
  10. 10. Existe diferença entre desenvolver e desenvolver! Desenvolver um aplicativo Desenvolver um aplicativo que funcione Desenvolver um aplicativo que funcione e seja robusto com relação ao seu uso típico Desenvolver um aplicativo que funcione e seja robusto com relação ao seu uso típico e tentativas de uso malicioso Desenvolver um aplicativo que funcione e seja robusto com relação ao seu uso típico e tentativas de uso malicioso e tenha alta disponibilidade Prof. Daniel dos Santos Kaster © 2010 10
  11. 11. Conteúdo Introdução ✓ integridade e consistência de dados Segurança de dados Disponibilidade de dados Prof. Daniel dos Santos Kaster © 2010 11
  12. 12. Integridade e consistência de dados Integridade – Os dados armazenados devem respeitar as regras do modelo de dados projetado para a aplicação Prof. Daniel dos Santos Kaster © 2010 12
  13. 13. Integridade e consistência de dados Integridade – Os dados armazenados devem respeitar as regras do modelo de dados projetado para a aplicação Consistência – Os dados têm que estar consistentes com relação aos “objetos” reais aos quais correspondem no momento em questão Prof. Daniel dos Santos Kaster © 2010 13
  14. 14. Integridade de identidade Garantem a unicidade de elementos em um conjunto de elementos Prof. Daniel dos Santos Kaster © 2010 14
  15. 15. Integridade de identidade Garantem a unicidade de elementos em um conjunto de elementos Boas práticas – Partir das restrições de unicidade inerentes ao problema Prof. Daniel dos Santos Kaster © 2010 15
  16. 16. Integridade de identidade Garantem a unicidade de elementos em um conjunto de elementos Boas práticas – Partir das restrições de unicidade inerentes ao problema – Garantir todas a unicidade de todas as chaves candidatas Prof. Daniel dos Santos Kaster © 2010 16
  17. 17. Integridade de identidade Garantem a unicidade de elementos em um conjunto de elementos Boas práticas – Partir das restrições de unicidade inerentes ao problema – Garantir todas a unicidade de todas as chaves candidatas – Usar chaves artificiais de forma adequada (geradores e sequências) Prof. Daniel dos Santos Kaster © 2010 17
  18. 18. Integridade de identidade Garantem a unicidade de elementos em um conjunto de elementos Boas práticas – Partir das restrições de unicidade inerentes ao problema – Garantir todas a unicidade de todas as chaves candidatas – Usar chaves artificiais de forma adequada (geradores e sequências) – Cuidado ao lidar com tipos de dados que admitem variações (p. ex. maiúsculas e minúsculas) Prof. Daniel dos Santos Kaster © 2010 18
  19. 19. Integridade de associações Elementos do problema em geral são representados de forma fragmentada no modelo de dados. As associações entre tais fragmentos tem que ser consistente. Prof. Daniel dos Santos Kaster © 2010 19
  20. 20. Integridade de associações Elementos do problema em geral são representados de forma fragmentada no modelo de dados. As associações entre tais fragmentos tem que ser consistente. Boas práticas – Cuidado com afirmações do tipo: “se os dados sempre são inseridos corretamente, por que gastar tempo verificando as associações?” Prof. Daniel dos Santos Kaster © 2010 20
  21. 21. Integridade de associações Elementos do problema em geral são representados de forma fragmentada no modelo de dados. As associações entre tais fragmentos tem que ser consistente. Boas práticas – Cuidado com afirmações do tipo: “se os dados sempre são inseridos corretamente, por que gastar tempo verificando as associações?” – Modelar adequadamente a propagação de atualizações nas associações Prof. Daniel dos Santos Kaster © 2010 21
  22. 22. Integridade de domínio de dados Todo dado tem um domínio especificado na aplicação que deve ser respeitado A maior parte do trabalho de análise de dados, em geral, compreende tratar inconsistências Prof. Daniel dos Santos Kaster © 2010 22
  23. 23. Integridade de domínio de dados Todo dado tem um domínio especificado na aplicação que deve ser respeitado A maior parte do trabalho de análise de dados, em geral, compreende tratar inconsistências Boas práticas – Se o domínio é restrito, utilizar referências ou verificações CHECK Prof. Daniel dos Santos Kaster © 2010 23
  24. 24. Integridade de domínio de dados Todo dado tem um domínio especificado na aplicação que deve ser respeitado A maior parte do trabalho de análise de dados, em geral, compreende tratar inconsistências Boas práticas – Se o domínio é restrito, utilizar referências ou verificações CHECK – Definir tipos específicos de dados de acordo com a necessidade Prof. Daniel dos Santos Kaster © 2010 24
  25. 25. Integridade de domínio de dados Todo dado tem um domínio especificado na aplicação que deve ser respeitado A maior parte do trabalho de análise de dados, em geral, compreende tratar inconsistências Boas práticas – Se o domínio é restrito, utilizar referências ou verificações CHECK – Definir tipos específicos de dados de acordo com a necessidade – Usar as restrições de atributos adequadamente Prof. Daniel dos Santos Kaster © 2010 25
  26. 26. Integridade de restrições complexas Algumas aplicações possuem restrições complexas que devem ser respeitadas Dúvida comum: “tratar restrições complexas no banco de dados ou na aplicação?” Prof. Daniel dos Santos Kaster © 2010 26
  27. 27. Integridade de restrições complexas Algumas aplicações possuem restrições complexas que devem ser respeitadas Dúvida comum: “tratar restrições complexas no banco de dados ou na aplicação?” Boas práticas – Uso de assertions ou triggers Prof. Daniel dos Santos Kaster © 2010 27
  28. 28. Uso adequado de transações Transação: é a unidade lógica de processamento em bancos de dados que engloba uma ou mais operações de acesso ao banco de dados (consulta ou atualização) Prof. Daniel dos Santos Kaster © 2010 28
  29. 29. Uso adequado de transações Transação: é a unidade lógica de processamento em bancos de dados que engloba uma ou mais operações de acesso ao banco de dados (consulta ou atualização) Propriedades ACID: Atomicidade: ou tudo é executado, ou nada; Consistência: leva o banco de dados de um estado consistente a outro estado consistente; Isolamento: a execução de uma transação não é afetada pela execução de outras transações; Durabilidade: as alterações feitas por uma transação comitada são armazenadas no banco de dados. Prof. Daniel dos Santos Kaster © 2010 29
  30. 30. Boas práticas no uso de transações Prof. Daniel dos Santos Kaster © 2010 30
  31. 31. Boas práticas no uso de transações Usá-las!!! Prof. Daniel dos Santos Kaster © 2010 31
  32. 32. Boas práticas no uso de transações Usá-las!!! Atenção ao armazenar informações de objetos fragmentadas em vários objetos do banco de dados Prof. Daniel dos Santos Kaster © 2010 32
  33. 33. Boas práticas no uso de transações Usá-las!!! Atenção ao armazenar informações de objetos fragmentadas em vários objetos do banco de dados Definir adequadamente o nível de isolamento Prof. Daniel dos Santos Kaster © 2010 33
  34. 34. Níveis de isolamento O padrão SQL define níveis de isolamento, considerando três fenômenos que devem ser evitados em transações concorrentes: dirty read: uma transação lê um dado de uma transação concorrente não comitada; nonrepeatable read: uma transação faz uma nova leitura em um dado e obtém um valor diferente, modificado por outra transação que comitou após a leitura inicial; phantom read: uma transação re-executa uma consulta retornando um conjunto de tuplas e obtém um conjunto diferente, afetado por uma transação comitada após a consulta inicial. Prof. Daniel dos Santos Kaster © 2010 34
  35. 35. Níveis de isolamento Os 4 níveis de isolamento definidos no padrão SQL e seus comportamentos são os seguintes: Dirty Nonrepeatable Phantom read read read Read uncommitted Sim Sim Sim Read committed Não Sim Sim Repeatable read Não Não Sim Serializable Não Não Não Prof. Daniel dos Santos Kaster © 2010 35
  36. 36. Boas práticas no uso de transações Usá-las!!! Atenção ao armazenar informações de objetos fragmentadas em vários objetos do banco de dados Definir adequadamente o nível de isolamento Usar savepoints em muitos casos facilita Prof. Daniel dos Santos Kaster © 2010 36
  37. 37. Boas práticas no uso de transações Usá-las!!! Atenção ao armazenar informações de objetos fragmentadas em vários objetos do banco de dados Definir adequadamente o nível de isolamento Usar savepoints em muitos casos facilita Usar bloqueios explícitos quando for o caso LOCK TABLE; SELECT FOR UPDATE/SHARE Prof. Daniel dos Santos Kaster © 2010 37
  38. 38. “To denormalize, or not to denormalize: that is the question” Um banco de dados normalizado minimiza problemas de integridade e otimiza atualizações – As alterações são feitas em relações simples e tipicamente pequenas. Porém, afeta o desempenho de consultas – Para retornar um conjunto de dados associados é preciso realizar mais junções A pergunta é: quando desnormalizar? Prof. Daniel dos Santos Kaster © 2010 38
  39. 39. Tipos comuns de desnormalização Tabelas prejoined Tabelas de relatórios Tabelas particionadas ou replicadas Replicação de atributos frequentemente consultados Prof. Daniel dos Santos Kaster © 2010 39
  40. 40. Existem boas práticas para desnormalização? :-) Um banco de dados só deve ser desnormalizado quando a necessidade de desempenho é determinante na aplicação. Deve-se refletir sobre as seguintes questões: – O sistema pode alcançar um desempenho aceitável sem ser desnormalizado? – O desempenho do sistema depois da desnormalização ainda será inaceitável? – O sistema será menos confiável após a desnormalização? Prof. Daniel dos Santos Kaster © 2010 40
  41. 41. Se for realmente necessário desnormalizar, documente! Toda decisão de desnormalização deve ser documentada. Não tente criar um modelo conceitual desnormalizado. O modelo conceitual deve ser normalizado, com documentação sobre as decisões de desnormalização no modelo físico. Prof. Daniel dos Santos Kaster © 2010 41
  42. 42. Boa prática: usar visões materializadas Uma visão é uma tabela computada a partir de tabelas armazenadas de acordo com uma instrução de seleção – Uma visão computada é gerada a cada acesso – Uma visão materializada é gerada e armazenada no banco Exige atualização mediante atualizações nas tabelas base Rápido acesso aos resultados, pois já estão computados Prof. Daniel dos Santos Kaster © 2010 42
  43. 43. Visões materializadas são suas amigas! O seu SGBD suporta visões materializadas? Prof. Daniel dos Santos Kaster © 2010 43
  44. 44. Visões materializadas são suas amigas! O seu SGBD suporta visões materializadas? – O otimizador de consultas pode usar a visão materializada para reescrever consultas Prof. Daniel dos Santos Kaster © 2010 44
  45. 45. Visões materializadas são suas amigas! O seu SGBD suporta visões materializadas? – O otimizador de consultas pode usar a visão materializada para reescrever consultas – As aplicações podem estar em produção Prof. Daniel dos Santos Kaster © 2010 45
  46. 46. Visões materializadas são suas amigas! O seu SGBD suporta visões materializadas? – O otimizador de consultas pode usar a visão materializada para reescrever consultas – As aplicações podem estar em produção O seu SGBD não suporta? Prof. Daniel dos Santos Kaster © 2010 46
  47. 47. Visões materializadas são suas amigas! O seu SGBD suporta visões materializadas? – O otimizador de consultas pode usar a visão materializada para reescrever consultas – As aplicações podem estar em produção O seu SGBD não suporta? – Que tal ajudar a desenvolver? ;-) Prof. Daniel dos Santos Kaster © 2010 47
  48. 48. Conteúdo Introdução ✓ integridade e consistência de dados ✓ Segurança de dados Disponibilidade de dados Prof. Daniel dos Santos Kaster © 2010 48
  49. 49. Gerência de usuários Tem que estar de acordo com a política de segurança da organização. É preciso definir padrões de acesso e de recursos que garantam a integridade dos dados e a segurança de dados confidenciais. Prof. Daniel dos Santos Kaster © 2010 49
  50. 50. Mecanismos de controle de acesso Há dois tipos básicos de mecanismos de controle de acesso: – Discricionário: concessão de privilégios a usuários sobre objetos do banco de dados – Mandatório: definição de níveis de segurança para usuários e objetos para implementar a política de segurança da organização Prof. Daniel dos Santos Kaster © 2010 50
  51. 51. Controle de acesso discricionário Concessão de privilégios em nível de: Conta (ou sistema): create, alter, drop Objetos: select, insert, delete, update, execute Conjuntos de privilégios são agrupados em atribuições para facilitar a administração CREATE ROLE Prof. Daniel dos Santos Kaster © 2010 51
  52. 52. Concessão/revogação de privilégios Privilégios de sistema Grant <privilegio_sist>|<role> to <user>|<role> [with admin option]; Revoke <privilegio_sist>|<role> from <user>; GRANT create table TO jward; GRANT connect TO jward WITH ADMIN OPTION; Prof. Daniel dos Santos Kaster © 2010 52
  53. 53. Concessão/revogação de privilégios Privilégios de objetos Grant <privilegio_obj> (<atributo>) on <esquema>.<objeto> to <user>|<role> [with grant option]; Revoke <privilegio_sist> on <esquema>.<objeto> from <user>; GRANT select,insert ON jward.projetos TO public; GRANT select, update(nome) ON jward.empregado TO willy WITH GRANT OPTION; Prof. Daniel dos Santos Kaster © 2010 53
  54. 54. Controle de acesso mandatório Cada usuário ou objeto está classificado em um nível Modelo Bell-LaPadula Níveis: Top Secret (TS), Secret (S), Confidential (C) e Unclassified (U) Raras aplicações comerciais – Oracle Label Security Prof. Daniel dos Santos Kaster © 2010 54
  55. 55. Fluxo de informações no controle de acesso mandatório Um usuário U pode ler um objeto O somente se classe(S) >= classe(O) Prof. Daniel dos Santos Kaster © 2010 55
  56. 56. Fluxo de informações no controle de acesso mandatório Um usuário U pode ler um objeto O somente se classe(S) >= classe(O) Um usuário U pode escrever um objeto O somente se classe(S) <= classe(O) Evita fluxo de informações de níveis de segurança superiores para níveis inferiores Prof. Daniel dos Santos Kaster © 2010 56
  57. 57. Fluxo de informações no controle de acesso mandatório Um usuário U pode ler um objeto O somente se classe(S) >= classe(O) Um usuário U pode escrever um objeto O somente se classe(S) <= classe(O) Evita fluxo de informações de níveis de segurança superiores para níveis inferiores – Atributos/tuplas sem permissão podem aparecer com null ou “poli-instanciados” Prof. Daniel dos Santos Kaster © 2010 57
  58. 58. Segurança de dados A segurança de um sistema só é efetiva se está implantada em todos os seus níveis – Segurança física – Segurança de sistema operacional – Segurança do SGBD – Segurança da rede – Segurança da aplicação Prof. Daniel dos Santos Kaster © 2010 58
  59. 59. Segurança física O nível mais básico de segurança é a segurança física do servidor de banco de dados Acessos ao console devem ser restritos A informação está nos dispositivos físicos que devem ser resguardados – Cuidado com as mídias de backup! Prof. Daniel dos Santos Kaster © 2010 59
  60. 60. Segurança de sistema operacional Aplicar atualizações e patches do sistema operacional Executar os processos do banco de dados com uma conta própria – Restrição de acesso à conta que possui os arquivos do banco – Proteção dos arquivos do banco Auditoria de logs – Utilizar um servidor de log Prof. Daniel dos Santos Kaster © 2010 60
  61. 61. Segurança de SGBD Autenticação Definição de privilégios Criptografia Auditoria Prof. Daniel dos Santos Kaster © 2010 61
  62. 62. Mecanismos de autenticação Mecanismos de autenticação – Autenticação Interna: um usuário do banco por usuário da aplicação; – Autenticação Externa: um usuário do banco por usuário da aplicação com autenticação externa; – Autenticação via Aplicação: um usuário do banco para todos os usuários da aplicação; Prof. Daniel dos Santos Kaster © 2010 62
  63. 63. Mecanismos de autenticação Autenticação Interna – Prós Distinção de que usuários estão conectados Auditoria consistente – Contras DBA tem que criar os usuários Usuários podem conectar diretamente ao banco Prof. Daniel dos Santos Kaster © 2010 63
  64. 64. Mecanismos de autenticação Autenticação Externa – Prós Os mesmos da autenticação interna Criação de usuários fica a cargo do administrador de sistemas Os usuários utilizam uma única conta para usar vários sistemas – Contras É mais difícil de configurar Violações de contas de rede comprometem a segurança do banco Prof. Daniel dos Santos Kaster © 2010 64
  65. 65. Mecanismos de autenticação Autenticação via Aplicação – Prós Bom para muitos usuários em operações não críticas – Contras O controle de acesso tem que ser garantido pela aplicação Auditoria tem que ser implementada na aplicação Prof. Daniel dos Santos Kaster © 2010 65
  66. 66. Boas práticas para autenticação de usuários Utilizar senhas criptografadas Utilizar funções de reforço de senha Desabilitar contas desnecessárias e/ou sem senha Definir adequadamente os privilégios de sistema e de acesso ao catálogo do banco Prof. Daniel dos Santos Kaster © 2010 66
  67. 67. Segurança de rede Utilizar tráfego criptografado de senhas Desabilitar serviços e compartilhamentos que não forem estritamente necessários Não colocar arquivos do banco em compartilhamentos publicados Colocar o servidor de banco de dados atrás de um firewall Utilizar VPN (Virtual Private Networks) quando um canal seguro for necessário Controlar o acesso dos usuários internos da organização Prof. Daniel dos Santos Kaster © 2010 67
  68. 68. Segurança de aplicação Validar as entradas dos usuários para evitar a injeção de SQL Toda entrada de dados é suspeita! Boas práticas – Usar funções de scape de caracteres especiais – Fornecer dados por meio de parâmetros para as instruções SQL (binding) Prof. Daniel dos Santos Kaster © 2010 68
  69. 69. Mais boas práticas de segurança de aplicação Utilizar usuários com privilégios distintos para conexão com o banco de dados de acordo com o nível de acesso na aplicação Nunca fazer conexão da aplicação como usuário privilegiado Utilizar tráfego criptografado de informações Tratar adequadamente erros e warnings emitidos pelo banco Prof. Daniel dos Santos Kaster © 2010 69
  70. 70. Auditoria de acesso aos dados É fundamental adotar uma política adequada de monitoramento dos acessos aos dados – Identificar situações atípicas. – Detectar ações mal intencionadas. – Detectar falhas de segurança. Prof. Daniel dos Santos Kaster © 2010 70
  71. 71. Esquemas de auditoria Alguns SGBDs fornecem pacotes de funcionalidades para auditoria Ex: instrução AUDIT no Oracle Implementar triggers de auditoria Implementar scripts de verificação periódica de consistência Prof. Daniel dos Santos Kaster © 2010 71
  72. 72. Auditar é chato, mas necessário! Há também outras fontes fundamentais para a auditoria – Arquivos de log do SGBD – Arquivos de log do SO As aplicações também devem gerar informações de auditoria e suporte! Auditoria em excesso pode causar degradação desnecessária de desempenho do SGBD e dificuldade de interpretação dos resultados Prof. Daniel dos Santos Kaster © 2010 72
  73. 73. Conteúdo Introdução ✓ integridade e consistência de dados ✓ Segurança de dados ✓ Disponibilidade de dados Prof. Daniel dos Santos Kaster © 2010 73
  74. 74. Garantir a disponibilidade do sistema Disponibilidade é a condição em que um recurso pode ser acessado pelos seus consumidores Disponibilidade e desempenho são diferentes e devem ser tratadas pelo DBA como assuntos distintos Disponibilidade compreende gerenciabilidade, recuperabilidade e confiabilidade Prof. Daniel dos Santos Kaster © 2010 74
  75. 75. Garantir a disponibilidade do sistema (cont.) Questões – Qual é o custo de downtime da organização? – “Quanto” de disponibilidade é o suficiente? Com o advento da internet, o uptime de muitas organizações tornou-se contínuo Eventuais problemas são possíveis e não acontecem somente com os outros – Falhas de instância, hardware, energia, ... – Falhas catastróficas – Falhas humanas Prof. Daniel dos Santos Kaster © 2010 75
  76. 76. Redundância é importante! Redundância é importante! – redundância é importante! redundância é importante! – redundância é importante! redundância é importante! redundância é importante! Prof. Daniel dos Santos Kaster © 2010 76
  77. 77. Disponibilidade de armazenamento Há várias alternativas – Discos isolados – RAID – Storages É preciso encontrar a melhor relação custo- benefício Prof. Daniel dos Santos Kaster © 2010 77
  78. 78. RAID A taxa de aumento da performance dos discos rígidos tem sido consideravelmente inferior ao das memórias e dos microprocessadores (limitações mecânicas). O conceito de RAID (Redundant Array of Inexpensive/Independent Disks) consiste em organizar conjuntos de discos para uso em paralelo para reduzir esta lacuna de desempenho. Desempenho (stripping) Redundância (espelhamento/paridade) Prof. Daniel dos Santos Kaster © 2010 78
  79. 79. Storages Uma Storage Area Network (SAN) é uma arquitetura para conectar dispositivos de armazenamento, tais como arrays de discos e jukeboxes, de forma que para o sistema operacional apareçam como se estivessem localmente conectados. – Protocolos mais utilizados SCSI paralelo (tradicional) Fibre channel (rede gigabit sobre cabos óticos ou par trançado) iSCSI – SCSI serial sobre TCP/IP Prof. Daniel dos Santos Kaster © 2010 79
  80. 80. Storages Exemplo: Dell CX4-960 SAN Prof. Daniel dos Santos Kaster © 2010 80
  81. 81. Storages Novas portas podem ser adicionadas ao array Portas 4Gbit Fibre Channel e 1Gbit iSCSI em um único array Capacidade de conexão de até 512 servidores Fibre Channel iSCSI Prof. Daniel dos Santos Kaster © 2010 81
  82. 82. Storages 5 a 960 drives (até 950TB!!!) 1 drive flash, com desempenho equivalente a 30 Fibre Channel Prof. Daniel dos Santos Kaster © 2010 82
  83. 83. Só Jesus salva! Então faça backup! Algumas vezes a única forma de recuperar o sistema de uma falha é restabelecer o backup do sistema É tarefa do DBA definir e implementar uma política adequada de backup – Backup completo – Backup incremental – Arquivamento dos arquivos de log de transações Prof. Daniel dos Santos Kaster © 2010 83
  84. 84. Procedimentos de backup Definir a periodicidade do backup e agendar Definir estratégia de verificação da integridade do backup Definir a metodologia de recuperação do backup Tempo de recuperação faz parte do contrato! ;-) Definir a estratégia de descarte, quando usada Testar regularmente o sistema e arquivos de backup Prof. Daniel dos Santos Kaster © 2010 84
  85. 85. Semana da Computação UFSCar 31/05 a 02/jun de 2010 Até que en Fim! :-) Perguntas? Prof. Daniel dos Santos Kaster Dept. Computação – Universidade Estadual de Londrina (UEL) dskaster@uel.br Prof. Daniel dos Santos Kaster © 2010 85

×