• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Integridade de dados e administração de segurança em SGBDs
 

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

on

  • 5,277 views

 

Statistics

Views

Total Views
5,277
Views on SlideShare
5,277
Embed Views
0

Actions

Likes
0
Downloads
130
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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
    • Conteúdo Introdução integridade e consistência de dados Segurança de dados Disponibilidade de dados Prof. Daniel dos Santos Kaster © 2010 2
    • 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
    • Introdução “O cofre não pode ser mais caro do que o tem dentro.” Prof. Daniel dos Santos Kaster © 2010 4
    • Existe diferença entre desenvolver e desenvolver! Prof. Daniel dos Santos Kaster © 2010 5
    • Existe diferença entre desenvolver e desenvolver! Desenvolver um aplicativo Prof. Daniel dos Santos Kaster © 2010 6
    • Existe diferença entre desenvolver e desenvolver! Desenvolver um aplicativo Desenvolver um aplicativo que funcione Prof. Daniel dos Santos Kaster © 2010 7
    • 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
    • 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
    • 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
    • Conteúdo Introdução ✓ integridade e consistência de dados Segurança de dados Disponibilidade de dados Prof. Daniel dos Santos Kaster © 2010 11
    • 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
    • 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
    • Integridade de identidade Garantem a unicidade de elementos em um conjunto de elementos Prof. Daniel dos Santos Kaster © 2010 14
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Boas práticas no uso de transações Prof. Daniel dos Santos Kaster © 2010 30
    • Boas práticas no uso de transações Usá-las!!! Prof. Daniel dos Santos Kaster © 2010 31
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • “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
    • 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
    • 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
    • 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
    • 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
    • Visões materializadas são suas amigas! O seu SGBD suporta visões materializadas? Prof. Daniel dos Santos Kaster © 2010 43
    • 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
    • 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
    • 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
    • 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
    • Conteúdo Introdução ✓ integridade e consistência de dados ✓ Segurança de dados Disponibilidade de dados Prof. Daniel dos Santos Kaster © 2010 48
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Segurança de SGBD Autenticação Definição de privilégios Criptografia Auditoria Prof. Daniel dos Santos Kaster © 2010 61
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Conteúdo Introdução ✓ integridade e consistência de dados ✓ Segurança de dados ✓ Disponibilidade de dados Prof. Daniel dos Santos Kaster © 2010 73
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Storages Exemplo: Dell CX4-960 SAN Prof. Daniel dos Santos Kaster © 2010 80
    • 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
    • Storages 5 a 960 drives (até 950TB!!!) 1 drive flash, com desempenho equivalente a 30 Fibre Channel Prof. Daniel dos Santos Kaster © 2010 82
    • 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
    • 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
    • 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