A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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ções semelhantes


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 Ementa r A disciplina oferece aos alunos uma visão ampla dos diversos aspectos que envolvem a segurança de um sistema computacional de uma organização, com foco nos SGBDs. Segurança física e lógica dos SGBDs. Montagem de uma auditoria. Falhas prováveis que podem ser encontrados nos SGBDs. A internet e sua vulnerabilidade aos SGBDs.

3 Segurança em Banco de Dados 3 Objetivo da Disciplina r Estimular o conhecimento sobre segurança da informação. r Desenvolver uma política de segurança para SGBDs. r Conhecer técnicas de ataque aos SGBDs. r Aplicar a auditoria aos banco de dados. r Analisar as soluções possíveis, considerando as diversas variáveis que podem dificultar ou facilitar a implantação de segurança nos SGBDs.

4 Segurança em Banco de Dados 4 Ementa: r 1 ESTRATÉGIAS PARA SEGURANÇA DA INFORMAÇÂO m Fundamentos sobre segurança m Segurança na Web m A Informação – porque necessita de segurança? r 2 SEGURANÇA NOS SGBDs r 2.1 O papel do DBA na segurança dos SGBDs r 2.2 Backup e Recovery r 2.3 Infra estrutura adequada visando a segurança dos SGBDs r 2.4 Controle de acesso discreto e mandatório r 2.5 Roles

5 Segurança em Banco de Dados 5 r 2.6 Proteção de usuários x proteção de objetos do SGBD r 2.7 Comandos SQLs para segurança r 2.8 Regras de Autorização r 3 POLÍTICAS DE SEGURANÇA PARA OS SGBDs r 3.1 O que é uma política de segurança r 3.2 Montagem de uma política de segurança eficaz r 4 ROUBO DE DADOS r 4.1 Quem está sujeito a perda (roubo) de dados 4.2 Cases

6 Segurança em Banco de Dados 6 r 5 A WEB E A SEGURANÇA DOS SGBDs r 5.1 Diferenças da segurança de banco de dados na Web r 5.2 Prováveis ataques r 5.3 Montagem de um plano para dificultar os ataques r 6 AUDITORIA r 6.1 Auditoria nos SGBDs r 6.2 Opções de auditoria r 6.3 Audit Trail

7 Segurança em Banco de Dados 7 r Bibliografia Indicada m DATE, C. J. Introdução a sistemas de banco de dados. Rio de Janeiro: Elsevier, m ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de dados: fundamentos e aplicações. 4. ed. São Paulo: Pearson Education, m SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. Tradução da 5ª Edição. São Paulo: Campus, r Bibliografia Opcional m CHESWICK, R. W.; BELLOVIN, S. M.; RUBIN, A. D. Firewalls e segurança na Internet. 2. ed., p.

8 Segurança em Banco de Dados 8 Segurança em banco de dados

9 Segurança em Banco de Dados 9 O banco de dados de uma empresa contém uma grande quantidade de dados e geralmente um grande número de usuários. A maioria destes usuários não tem a necessidade de acessar todos os dados. Assim, permitir o acesso irrestrito a todos os dados pode ser indesejável e o SGBD deve prover mecanismos para controlar este acesso. O banco de dados de uma empresa contém uma grande quantidade de dados e geralmente um grande número de usuários. A maioria destes usuários não tem a necessidade de acessar todos os dados. Assim, permitir o acesso irrestrito a todos os dados pode ser indesejável e o SGBD deve prover mecanismos para controlar este acesso.

10 Segurança em Banco de Dados 10 Controle de acesso discricionário

11 Segurança em Banco de Dados 11 SGBDs controlam o acesso aos dados através do controle de acesso discricionário. Esse controle é baseado no conceito de direitos de acesso ou privilégios e a maneira de conceder estes privilégios aos usuários. Um privilégio permite que um usuário acesse o dado de certa maneira (por exemplo, lendo ou escrevendo o dado). Um usuário que cria um objeto automaticamente adquire todos os direitos sobre o mesmo. A partir de então, o banco de dados guarda todos os privilégios que são concedidos a outros usuários e desta forma, garante que apenas os usuários autorizados possam acessar este objeto.

12 Segurança em Banco de Dados 12 Em praticamente todos os bancos de dados, o controle de acesso discricionário é implementado através do uso dos comandos GRANT e REVOKE. O comando GRANT concede privilégios sobre os objetos do banco de dados (tabelas e visões, dentre outros) a outros usuários enquanto que o comando REVOKE revoga os privilégios concedidos. Para um melhor entendimento do mecanismo de acesso discricionário, é importante compreender a definição de privilégios, objetos e usuários:

13 Segurança em Banco de Dados 13 Usuários: são as pessoas que estão representadas por um nome de autorização. Os usuários podem ser classificados em grupos de acordo com um perfil ou nível de autorização. Um usuário que pertence a um grupo, implicitamente, recebe os privilégios relacionados ao grupo que ele pertence; Privilégio: define uma permissão individual associada a um nome autorizado, habilitando-o a acessar ou modificar um recurso do banco de dados. Os privilégios também podem ser concedidos a grupos de usuários; Objetos: os usuários necessitam de privilégios para acessar os objetos guardados no banco de dados. Os privilégios variam de acordo com a natureza do objeto. Por exemplo, uma tabela possui uma lista de privilégios diferente das visões. São exemplos de objetos: tabelas, visões, índices, triggers, entre outros.

14 Segurança em Banco de Dados 14 Comando GRANT

15 Segurança em Banco de Dados 15 A sintaxe do comando GRANT é a seguinte: GRANT privilégios ON objeto TO usuários [WITH GRANT OPTION] Onde: Privilégios: denota, por modelar: o SELECT: o direito de leitura sobre as colunas da tabela especificada; o INSERT: o direito de inserir linhas; o UPDATE (nome-da-coluna,...): o direito alterar valores na coluna especificada da tabela indicada como objeto;

16 Segurança em Banco de Dados 16 o DELETE: o direito de excluir linhas de uma tabela especificada como objeto; o INDEX: direito de criar um novo índice sobre a tabela. Este privilégio aplica-se somente a tabelas; Objeto: geralmente uma tabela ou visão; Usuários: usuário ou lista de usuários que receberão o privilégio.

17 Segurança em Banco de Dados 17 Se um usuário recebe o privilégio com a opção GRANT OPTION, ele pode passar esse privilégio para outro usuário através do comando GRANT. Um usuário que cria uma tabela automaticamente herda todos os privilégios aplicáveis à tabela juntamente com o direito de conceder estes privilégios para outros usuários. O usuário que cria uma visão tem os mesmos privilégios sobre ela. Apenas o dono de um esquema (um esquema é a descrição do banco de dados) pode executar os comandos de definição de dados CREATE, ALTER e DROP do mesmo. O direito de executar estes comandos não pode ser concedido ou revogado.

18 Segurança em Banco de Dados 18 Exemplos do uso do comando GRANT

19 Segurança em Banco de Dados 19 GRANT SELECT, INSERT ON tb_cep TO user1; GRANT SELECT ON tb_cep TO PUBLIC; GRANT SELECT ON funcionario to admuser WITH GRANT OPTION; GRANT ALL ON tb_cep TO admuser WITH GRANT OPTION;

20 Segurança em Banco de Dados 20 O comando Revoke

21 Segurança em Banco de Dados 21 Para revogar privilégios concedidos utiliza-se o comando REVOKE. Sua sintaxe é: REVOKE privilégios ON objeto FROM usuários { RESTRICT | CASCADE }

22 Segurança em Banco de Dados 22 Exemplos do uso do comando REVOKE

23 Segurança em Banco de Dados 23 REVOKE SELECT ON tb_cep FROM PUBLIC; REVOKE SELECT ON funcionario FROM admuser RESTRICT; REVOKE ALL ON tb_cep FROM admuser CASCADE;

24 Segurança em Banco de Dados 24 A opção de RESTRIC significa que o comando recusa remover a tabela se existirem objetos dependentes. Este é o padrão no banco de dados DB2. Já a opção CASCADE remove automaticamente os objetos que dependem da tabela (como visões), ou seja, faz uma remoção em cascata.

25 Segurança em Banco de Dados 25 Gráfico de autorização

26 Segurança em Banco de Dados 26 O efeito de uma série de comandos GRANT pode ser descrito através de um gráfico de autorização no quais os nós são usuários e as setas/arcos indicam como os privilégios são passados. Por exemplo, existe uma seta do usuário1 para o usuário2 se usuário1 executou um comando GRANT passando um privilégio para o usuário2. A seta será rotulada com o descritor para este comando GRANT. Para os comandos da Listagem 3 foi criado o gráfico de autorização apresentado na Figura 1:

27 Segurança em Banco de Dados 27 Note que o usuário Jose é o criador da tabela Item e herda o privilégio SELECT do SGBD. Esta operação é demonstrada pela introdução de um nó de sistema (SYSTEM), desenhando uma seta deste nó para o nó de Jose (Ação 1). Vera recebe os privilégios de Jose (Ação 2). Subseqüentemente Rob recebe o mesmo privilégio através de Vera (Ação 3). Como o gráfico claramente indica, o GRANT de Artur para Rob e de Rob para Artur (do mesmo privilégio) cria um ciclo (Ação 4).

28 Segurança em Banco de Dados 28 Listagem 3. Concedendo e revogando privilégios. GRANT SELECT ON Item TO Artur WITH GRANT OPTION; (executed by Jose) GRANT SELECT ON Item TO Vera WITH GRANT OPTION; (executed by Jose) GRANT SELECT ON Item TO Rob WITH GRANT OPTION; (executed by Vera) GRANT SELECT ON Item TO Rob WITH GRANT OPTION; (executed by Artur)

29 Segurança em Banco de Dados 29 GRANT SELECT ON Item TO Artur WITH GRANT OPTION; (executed by Rob) REVOKE SELECT ON Item FROM Artur CASCADE ; (executed by Jose)

30 Segurança em Banco de Dados 30 Figura 01

31 Segurança em Banco de Dados 31 Dados Criptografados

32 Segurança em Banco de Dados 32 Como sabemos, os aspectos de segurança em uma rede são fundamentais para garantia de confiabilidade e execução dos serviços. A tecnologia de banco de dados trabalha com vários fatores para garantir a integridade e segurança dos dados. Além do acesso discricionário, existem outros fatores que podem auxiliar na segurança de um banco de dados. Um destes fatores diz respeito à criptografia dos dados como veremos no tópico a seguir.

33 Segurança em Banco de Dados 33 Verificando o tráfego na rede

34 Segurança em Banco de Dados 34 O funcionamento de uma rede consiste basicamente em envio e recebimento de dados. Qualquer informação que trafegue pela rede, seja uma mensagem de correio eletrônico, um arquivo de texto ou um comando de consulta qualquer, é dividida em pequenas unidades de dados chamadas pacotes. Além de uma parte do conteúdo da mensagem original, cada pacote recebe informações adicionais que incluem o endereço IP de destino e o conteúdo do pacote. Para verificar o conteúdo de um pacote de informações em uma LAN basta o usuário ter o acesso interno a ela e possuir um programa específico para realizar esta captura. Com isso se torna simples localizar e visualizar o conteúdo de um pacote.

35 Segurança em Banco de Dados 35 Capturando pacotes de informações

36 Segurança em Banco de Dados 36 Buscando encontrar e analisar o movimento dos pacotes de informações referentes aos comandos e informações do nosso banco de dados utilizou-se um software chamado Ethereal (). O Ethereal (Figura 2) é um analisador de tráfego de rede com uma interface intuitiva e simples capaz de capturar pacotes específicos relacionados a um endereço IP ou um cliente de rede que esteja efetuando transações ativas. Este software não só permite ver os pacotes que são destinados ao nosso computador como os que são destinados aos restantes (e que em geral o nosso computador ignora). Este tipo de aplicação costuma ser chamado de analisador de protocolos ou também de sniffer.

37 Segurança em Banco de Dados 37

38 Segurança em Banco de Dados 38 A análise feita sobre um componente de tráfego de rede foi estabelecida através da captura de um pacote de informação no exato momento de sua movimentação pela rede. Com isso, foi possível executar uma análise prévia dos resultados e dos comandos emitidos pelo cliente para o banco de dados, nesse exemplo, chamado de DBCRIPT. O usuário utilizado para a conexão de exemplo foi db2admin com a senha criptografia. Na Listagem 8 podemos observar uma descrição de uma parte do pacote de informações capturado durante o teste. Este pacote de informações esta trafegando sem qualquer tipo de criptografia.

39 Segurança em Banco de Dados 39 Listagem 8. Pacote de dados sem criptografia. DBCRIPT D! db2admin NULLID SYSSH200 SYSLVL01 criptÐogrÐafiaÐ $ WITH HOLD ÿ ]ÐC W$ MSELECT A.ID_APLICACAO, C.COD_ RESTRICAO, B.* FROM APLICACOES A LEFT JOIN RESTRICOES_APLIC B INNER JOIN RESTRICOES C ON B.ID_RESTRICAO = C.ID_ RESTRICAO AND C.TIPO_RESTRICAO IN (‘Q’, ‘D’) ON A.ID_APLICACAO = B.ID_APLICACAO WHERE A.ID_APLICACAO = ? ORDER BY A.ID_ APLICACAO, C.COD_RESTRICAO ÿ SÐA M D! DBSM NULLID SYSSH200 SYSLVL01 !F/ aÐQ / [ MSELECT A.ID_APLICACAO, C.COD_RESTRICAO, B.* FROM APLICACOES A LEFT JOIN RESTRICOES_APLIC B INNER JOIN RESTRICOES

40 Segurança em Banco de Dados 40 Considere as informações abaixo para entender a Listagem 8. Nome do Banco de Dados Usuário do Banco de Dados Senha do Usuário do Banco de Dados

41 Segurança em Banco de Dados 41 Comando executado

42 Segurança em Banco de Dados 42 Conforme a legenda acima, podemos observar que este pacote contém informações vitais para a segurança de uma empresa. Normalmente estes pacotes de informações transitam livremente sem nenhum tipo de segurança. Basta um simples software de captura e uma análise superficial para podermos ter em mãos dados confidenciais e importantes do dia a dia da empresa. Podemos também recuperar facilmente um usuário que tem permissão total para modificações no banco de dados.

43 Segurança em Banco de Dados 43 Ativando criptografia no DB2

44 Segurança em Banco de Dados 44 O DB2 possui um parâmetro que permite ao DBA aplicar mais segurança nestes pacotes de informações com a ativação de criptografia. Para isso é preciso alterar as configurações do banco de dados. Basta aplicar o comando DB2 GET DBM CFG e alterar o parâmetro Database manager authentication como podemos observar abaixo: Database Manager Configuration Database manager authentication (AUTHENTICATION) = SERVER_ENCRYPT

45 Segurança em Banco de Dados 45 Depois de efetuado a configuração do parâmetro de autenticação, é preciso modificar as opções de segurança em cada máquina cliente que possui acesso ao banco de dados. Para isso, basta acessarmos o Assistente de Configuração de Banco de Dados do DB2 e selecionarmos a opção Autenticação do Servidor (SERVER) e Ativar criptografia (ver Figura 3).

46 Segurança em Banco de Dados 46 Figura 3. tela assistente

47 Segurança em Banco de Dados 47 Depois de efetuadas as modificações no banco, repetimos o mesmo processo de captura de pacotes com o mesmo comando executado da mesma máquina cliente. O resultado pode ser visto na Listagem 9. Listagem 9. Pacote de dados com criptografia. °ÐA ª A n ÙÅÉ 14 / $ t GØÄÂòaÕã mÕÂÄðó ZâØÓðøðñõ JÐ D m ¢ ! $ ܶ òjêáý‹6çàöN¼·ÏWåjFÒ]êÞ¸³ ‰Ó Ô hÐC b C ^„‚ò‰¢£ñ„‚ò?‡…£ððððóòÂöð 14 / $ t $-

48 Segurança em Banco de Dados 48 Como podemos observar, os dados em questão estão completamente ilegíveis, pois já estão atuando com a criptografia ativa. Com isso, tende-se a dificultar as possibilidades de qualquer tipo de invasão ou de obtenção de informações confidenciais dentro e fora da empresa.

49 Segurança em Banco de Dados 49 Conclusão No teste realizado, monitoramos apenas alguns minutos do gargalo de entrada do banco de dados DBCRIPT e geramos apenas alguns arquivos de exemplo para análise. O mais interessante neste teste foi a facilidade de obtenção de um usuário e uma senha para acesso ao banco de dados. Esta aparece com a forma um pouco “confusa”, mas mesmo assim pode-se chegar à senha correta com facilidade. Verifique se o servidor de banco de dados que você utiliza fornece criptografia para trânsito de dados e não deixe de usar esse recurso fundamental para a segurança das informações de sua empresa.

50 Segurança em Banco de Dados 50 O uso do ethereal é simples e intuitivo – siga o roteiro abaixo para realizar seus primeiros passos com o aplicativo: 1)Baixe o instalador em A instalação não solicita nenhum tipo de configuração e é baseada em ‘next-next-next’ (se você marcou a opção ‘Start WinPcap service at startup, será necessário reiniciar o micro); 2) Inicie o aplicativo e selecione a interface de conexão (placa ou conexão de rede). Para isso, clique no menu Capture-Interfaces (Figura 4). Em seguida, clique no botão ‘Capture’ da placa de rede correspondente (Figura 5);

51 Segurança em Banco de Dados 51

52 Segurança em Banco de Dados 52 3) Uma janela com o status do tráfego de dados pela rede será aberta (Figura 6). Deixe a janela rodando durante algum tempo e clique em ‘Stop’;

53 Segurança em Banco de Dados 53 4) Por último o aplicativo exibirá os pacotes capturados na janela principal, divididos em três categorias. Para visualizar os dados de um pacote, clique em uma das linhas no painel superior (que exibe o cabeçalho do pacote) e visualize o conteúdo do pacote no terceiro painel. Observe que o pacote aparece em dois formatos: byte e ascii (Figura 7). Veja também que o cabeçalho do pacote exibe diversas informações importantes, tais como endereço IP de origem, endereço IP de destino, protocolo e tipo da aplicação que enviou o pacote (na coluna info).

54 Segurança em Banco de Dados 54

55 Segurança em Banco de Dados 55 Exemplo de Role no Sql Server 2005

56 Segurança em Banco de Dados 56 m Verificando propriedades do login SA.

57 Segurança em Banco de Dados 57 m O seu Server Roles está apontado para o fixed sysadmin.

58 Segurança em Banco de Dados 58 Databases Roles - São aplicados ao usuário Server Roles - São aplicados aos logins Os logins possuem permissões administrativas no servidor e os usuários possuem permissões nos objetos do banco de dados.

59 Segurança em Banco de Dados 59 m Criando um novo Login.

60 Segurança em Banco de Dados 60

61 Segurança em Banco de Dados 61 m O sysadmin é um role especial, pois toda vez que é colocado o login como sysadmin, ele automaticamente se torna um db_owner para todos os bancos, pois este é um login que se pode fazer tudo. m Desta forma tem uma relação entre os fixed Server roles conforme abaixo com os database role db_owner que é o mais poderoso.

62 Segurança em Banco de Dados 62 Criação do login John e mapeando o mesmo ao usuário J

63 Segurança em Banco de Dados 63 - Server Roles são utilizados para servidores. - Database Role são utilizados para banco de dados. - Existem 10 database role por padrão conforme figura acima, que são denominados fixed database role. m Associar o usuário ao banco de dados DB_PERM

64 Segurança em Banco de Dados 64 - Cada database role possui uma permissão já por padrão. Os database role são relativos ao usuário e não ao login, pois o login utiliza os server roles. - Um pouco sobre cada um dos database role: m db_accessadmin O usuário tem permissão de criação ou não de login. m db_backupoperator O usuário pode fazer backup/restore. m db_datareader Permite ao usuário efetuar apenas o comando select, ou seja, somente leitura do banco de dados. m db_datawriter Permite ao usuário efetuar gravações como update, delete e insert. m db_ddladmin Pemite a criação de objetos como o create table, drop view, alter procedure, ou seja, criação de objetos de DDL. m db_denydatareader Nega a permissão de leitura ao banco de dados.

65 Segurança em Banco de Dados 65 m db_denydatawriter Nega a permissão de gravação ao banco de dados. m db_owner É um recurso especial, pois toda vez que colocar o usuário como db_owner, o mesmo pode fazer todo o tipo de operação no banco de dados. m db_securityadmin É relacionado as permissões de GRANT, DENY, REVOKE. m Public É igual ao db_owner, são 2 roles especiais. O public é um role especial que não é possível ser removido. Pois toda a vez que um login do SQL Server é mapeado ao banco de dados, como por exemplo, o login John está sendo mapeado ao usuário J, ele automaticamente pertence ao role public. O role public pertence a todos os banco de dados e por padrão ele não possui nenhuma permissão.

66 Segurança em Banco de Dados 66 m db_denydatawriter Nega a permissão de gravação ao banco de dados. m db_owner É um recurso especial, pois toda vez que colocar o usuário como db_owner, o mesmo pode fazer todo o tipo de operação no banco de dados. m db_securityadmin É relacionado as permissões de GRANT, DENY, REVOKE. m Public É igual ao db_owner, são 2 roles especiais. O public é um role especial que não é possível ser removido. Pois toda a vez que um login do SQL Server é mapeado ao banco de dados, como por exemplo, o login John está sendo mapeado ao usuário J, ele automaticamente pertence ao role public. O role public pertence a todos os banco de dados e por padrão ele não possui nenhuma permissão.

67 Segurança em Banco de Dados 67 m Exibindo o usuário J criado. m Obs.: Conforme figura anterior, o usuário J não foi associado a nenhuma role, a não ser a padrão public que não possui permissão.

68 Segurança em Banco de Dados 68 Criação do login Mary e mapeando o mesmo ao usuário M

69 Segurança em Banco de Dados 69

70 Segurança em Banco de Dados 70 m Associar o usuário ao banco de dados DB_PERM

71 Segurança em Banco de Dados 71 m Não será marcado nenhum fixed Server role.

72 Segurança em Banco de Dados 72 m Login John e Mary Usuário J e M »AMBOS NÃO POSSUEM PERMISSÃO ALGUMA!

73 Segurança em Banco de Dados 73 m Crie 3 abas clicando no botão Query e efetue a autenticação de cada aba aos usuários criados. m Aba 01 -> Usuário SA m Aba 02 -> Usuário John m Aba 03 -> Usuário Mary m Digite o comando SQL para apontar para o banco DB_PERM conforme abaixo. Deverá ser feito para cada uma das abas.

74 Segurança em Banco de Dados 74 m Com o usuário SA funciona perfeitamente o SELECT, pois o login SA faz parte do fixed role sysadmin que é mapeado ao usúário db_owner em todos os bancos de dados. m Desta forma, todos os usuários que estiverem dentro do ROLE SA, conseguirão efetuar o select.

75 Segurança em Banco de Dados 75 m Efetuando o mesmo select com o John e Mary, o mesmo possui apresenta erro.

76 Segurança em Banco de Dados 76 m Após a criação do ROLE e atribuição do GRANT de SELECT, o usuário SA continua conseguindo executar a consulta.

77 Segurança em Banco de Dados 77 m O usuário J (John) ainda não consegue efetuar a consulta select, pois o mesmo não está ainda dentro do ROLE.

78 Segurança em Banco de Dados 78 m O usuário M (Mary) ainda não consegue efetuar a consulta select, pois o mesmo não está ainda dentro do ROLE.

79 Segurança em Banco de Dados 79 m Após a inclusão do usuário J (John) ao ROLE, o mesmo já consegue efetuar a consulta.

80 Segurança em Banco de Dados 80 m Como J (John) já está dentro do grupo, o mesmo já consegue efetuar a consulta.

81 Segurança em Banco de Dados 81 m Após a inclusão do usuário M (Mary) ao ROLE, o mesmo já consegue efetuar a consulta.

82 Segurança em Banco de Dados 82 m Como M (Mary) já está dentro do grupo, o mesmo já consegue efetuar a consulta.

83 Segurança em Banco de Dados 83 m Todo o usuário que estiver dentro do grupo SALES, terá permissão correspondente ao ROLE atribuído. m Porém, pode ser feito também uma permissão individual dentro do grupo. Desta forma, qual permissão prevalecerá? A permissão do grupo ou a permissão individual?

84 Segurança em Banco de Dados 84 m Em caso de conflito de restrições, a que vale é a mais restritiva. m No caso anterior, atribuímos a permissão do ROLE a permissão de SELECT para todos os usuários que estavam no grupo. Se eu efetuar a negação de SELECT a um usuário específico, o mesmo não poderá efetuar a consulta e sim somente os outros usuários do grupo. m Veja a negação da permissão de SELECT para o usuário J.

85 Segurança em Banco de Dados 85 m O usuário J (John) não consegue mais efetuar a consulta.

86 Segurança em Banco de Dados 86 m O usuário M (Mary) ainda consegue efetuar a consulta, pois não possui ainda nenhuma negação.

87 Segurança em Banco de Dados 87 m Removendo o usuário M (Mary) do grupo SALES.

88 Segurança em Banco de Dados 88 m Como o usuário M (Mary) não está mais no grupo SALES, a mesma não tem permissão mais de SELECT.

89 Segurança em Banco de Dados 89 m Visualizando informações do usuário J (John).

90 Segurança em Banco de Dados 90 m Visualizando informações do usuário M (Mary).

91 Segurança em Banco de Dados 91 m O comando abaixo retorna os membros de um determinado ROLE.

92 Segurança em Banco de Dados 92

93 Segurança em Banco de Dados 93 m Contextualização

94 Segurança em Banco de Dados 94

95 Segurança em Banco de Dados 95 m Auditoria

96 Segurança em Banco de Dados 96

97 Segurança em Banco de Dados 97

98 Segurança em Banco de Dados 98

99 Segurança em Banco de Dados 99

100 Segurança em Banco de Dados 100 m Introdução

101 Segurança em Banco de Dados 101 m Recurso Sql Server Audit

102 Segurança em Banco de Dados 102

103 Segurança em Banco de Dados 103 m Server Audit Specification

104 Segurança em Banco de Dados 104 m Database Audit Specification

105 Segurança em Banco de Dados 105 m Target

106 Segurança em Banco de Dados 106 m Uso do Sql Server Audit

107 Segurança em Banco de Dados 107 m Criando Sql Server Audit

108 Segurança em Banco de Dados 108 m Criando Sql Specification

109 Segurança em Banco de Dados 109

110 Segurança em Banco de Dados 110 m Testando a Auditoria

111 Segurança em Banco de Dados 111 m Editando a Auditoria

112 Segurança em Banco de Dados 112 m Auditoria aplicada a Rollback

113 Segurança em Banco de Dados 113 m Carregando os dados de auditoria em uma tabela

114 Segurança em Banco de Dados 114

115 Segurança em Banco de Dados 115

116 Segurança em Banco de Dados 116 m Considerações

117 Segurança em Banco de Dados 117 Segurança no SQL Server 2005

118 Segurança em Banco de Dados 118 Integridade e segurança são duas dentre as muitas razões para o armazenamento de informações em um banco de dados. Entende-se por integridade não somente a garantia de que um dado está fisicamente armazenado no banco de dados, mas de que o dado foi inserido, alterado, apagado ou acessado somente por aqueles que possuem permissões adequadas. Entende-se por segurança o controle de usuários, objetos e os relacionamentos de permissões existentes entre eles. É função de um sistema gerenciador de banco de dados fornecer um modelo de segurança capaz de garantir a integridade lógica e segurança dos dados armazenados. É de responsabilidade do administrador de banco de dados conhecer este modelo e suas formas de implementação.

119 Segurança em Banco de Dados 119 No modelo de segurança do SQL Server O SQL Server 2005 é aderente ao conceito de “trustworth computing” da Microsoft que segue as seguintes linhas de pensamento: Seguro na arquitetura: a Microsoft esforçou-se para diminuir a área de ataque do SQL Server 2005 através da análise dos vetores de ataques mais comuns; Seguro por padrão: uma instalação padrão do SQL Server 2005 não implementa todas as funcionalidades e alguns serviços não são instalados. Alguns exemplos são: a stored procedure XP_CMDSHELL que vem desabilitada por padrão e, a base de teste AdventureWorks (que substitui as bases Pubs e Northwind) que também não é instalada por padrão. Seguro na instalação: o SQL Server 2005 agregou ferramentas para a configuração de segurança, monitoramento e auditoria do banco. Dentre as novas ferramentas estão o Surface Area Configuration - que permite configurar funcionalidades e serviços ativos no SQL Server 2005 – triggers de auditoria e políticas de senha para usuários SQL.

120 Segurança em Banco de Dados 120 O SQL Server 2005 implementa um novo modelo de segurança baseado na hierarquia de objetos e fundamentado em três conceitos: Principals: é qualquer entidade autenticada que pode possuir permissões para acessar um objeto no sistema de banco de dados. Principals podem existir em três níveis: Windows, SQL Server e banco de dados. A Tabela 1 apresenta os principals do SQL Server Tabela 1. Principal

121 Segurança em Banco de Dados 121 Securables: objetos que recebem permissões são chamados de Securables. Securables são, organizados de forma hierárquica em grupos (Scopes). Os três escopos dos objetos securables são: Server, database e schema (ver Tabela 2). Tabela 2. Securables e escopos

122 Segurança em Banco de Dados 122 Permissions: permissões são as regras que controlam o nível de acesso que os principais possuem nos securables. Permissões podem ser dadas, revogadas ou proibidas. O SQL Server 2005 mantém os comandos GRANT, REVOKE e DENY para o controle de permissões dos principais nos securables. Alem destes comandos, outros novos comandos foram inseridos e estão apresentados na Tabela 3. Tabela 3. Novas permissões do SQL Server 2005

123 Segurança em Banco de Dados 123 Surface Area Configuration

124 Segurança em Banco de Dados 124 Surface Area Configuration (SAC) é a nova ferramenta de gerenciamento de segurança do SQL Server O SAC permite maior controle de segurança sobre serviços, conexões e funcionalidades do SQL Server 2005 e pode ser acessado através do grupo Configuration Tool no grupo de programas do SQL Server O SAC está dividido em “Configurações de Serviços e Conexões” e “Funcionalidades”. Através das Configurações de Serviços e Conexões é possível desabilitar/habilitar serviços do SQL Server 2005 como Database Engine, SQL Server Agent, Full Text Search e SQL Server Browser. Também é possível configurar as permissões de conexões como somente local, TCP/IP, named pipes ou TCP/IP e named Pipes. A Figura 1 apresenta a tela de configuração do Surface Area Configuration for Services and Connections.

125 Segurança em Banco de Dados 125 Figura 1. Surface Area Configuration for Services e Connections.

126 Segurança em Banco de Dados 126 A configuração de funcionalidades permite habilitar ou desabilitar funcionalidades específicas do SQL Server As funcionalidades que podem ser configuradas são: AD hoc remote queries, execução de código.Net no SQL Server, conexão dedicada do administrador, database mail, suporte nativo a XML Web Services, automação OLE, SQL Mail, assistente WEB e xp_cmshell. Todas essas funcionalidades vêem desabilitadas na instalação padrão do SQL Server 2005 reforçando o conceito de seguro por padrão. A Figura 2 apresenta a tela de configuração do Surface Área Configuration for Features.

127 Segurança em Banco de Dados 127 Figura 2. Surface Área Configuration for Features.

128 Segurança em Banco de Dados 128 O SQL Server 2005 continua a suportar os dois modelos de autenticação existentes no SQL Server 2000: Windows e SQL. Na autenticação Windows o usuário e senha, incluindo a sua complexidade e expiração, são gerenciados pelo controlador de domínio. Na autenticação SQL o usuário e a senha são gerenciados pelo próprio SQL Server. Até a versão do SQL Server 2000 não era possível aplicar políticas de controle de senha nos usuários SQL. O SQL Server 2005 permite que as mesmas políticas de senhas existentes no domínio Windows sejam aplicadas aos usuários SQL. Esta funcionalidade é possível através da API NetValidate-PasswordPolicy(), disponível somente no Windows O comando utilizado para a criação de um usuário SQL é o CREATE LOGIN. Este comando substitui o comando SP_ADDLOGIN, que continua a existir por questões de compatibilidade. O comando CREATE LOGIN pode ser utilizado para a adição de logins com Segurança Integrada (autenticação Windows) e SQL Server Authentication. Quando o comando CREATE LOGIN é utilizado para a adição de usuários SQL, estão disponíveis as configurações listadas na Tabela 4. Políticas de senha para usuários SQL

129 Segurança em Banco de Dados 129 Tabela 4. Opções do comando CREATE LOGIN.

130 Segurança em Banco de Dados 130 A Listagem 1 ilustra a criação de um login SQL com política de senha e a obrigatoriedade de troca de senha no primeiro login. listagem 1. criação de um login com política de senha. create login [foobar] with must_change, check_expiration=on, check_policy=on command(s) completed successfully.

131 Segurança em Banco de Dados 131 Quando a senha de um usuário expira, utiliza-se o comando ALTER LOGIN para a liberação da senha. A Listagem 2 apresenta o comando que deve ser executado para a liberação da senha do usuário. listagem 2. liberação de um login bloqueado. alter login [foobar] with password= unlock command(s) completed successfully.

132 Segurança em Banco de Dados 132 Triggers de DDL

133 Segurança em Banco de Dados 133 Triggers de DDL (ver Nota 1) assim como todas as triggers, executam comandos na ocorrência de um evento específico. No entanto, triggers de DDL respondem a eventos de CREATE, ALTER ou DROP que ocorrem tanto no escopo do servidor de banco de dados quanto no escopo do database. Elas podem ser utilizadas para evitar, registrar ou proibir a execução de comandos DDL no servidor de banco de dados. Dois escopos são possíveis para execução das DDL Triggers: Server: abrange o servidor como um todo; Database: atua no database.

134 Segurança em Banco de Dados 134 Nota 1. DDL – Data Definition Language Linguagem de definição de dados. Utilizada para a criação, alteração e exclusão de objetos em servidores de banco de dados. Os eventos que podem ocorrer no nível do servidor estão organizados no grupo DDL_SERVER_LEVEL_EVENTS e os eventos que podem ocorrer no nível do banco de dados são organizados no grupo DDL_DATABASE_LEVEL_EVENTS. A Figura 3 apresenta os dois grupos e seus respectivos eventos.

135 Segurança em Banco de Dados 135 Figura 3. Eventos que disparam Triggers de auditoria.

136 Segurança em Banco de Dados 136 A sintaxe de criação de uma DDL Trigger é muito parecida com a criação de triggers: uma das mudanças é a utilização da opção ON ALL SERVER ou ON DATABASE que especifica se o escopo da trigger é no servidor ou somente no banco de dados. O script da Listagem 3 cria um DDL trigger para armazenar todos os eventos de CREATE, ALTER ou DROP LOGIN que venham a ocorrer no servidor SQL Server 2005.

137 Segurança em Banco de Dados 137 listagem 3. criação de uma ddl trigger. use master go -- cria tabela de log create table tb_ddl_trigger_log (horario datetime, usuario nvarchar(100), evento nvarchar(100), objeto nvarchar(255)) go --cria trigger que responderá a eventos relacionados --a login (create,alter e drop login) create trigger tg_ddl_trigger_log on all server for ddl_login_events as xml = eventdata() insert tb_ddl_trigger_log (horario, usuario, evento, objeto) values ‘nvarchar(2000)’)) ; go

138 Segurança em Banco de Dados testa o funcionamento da trigger create login foo with password=’foobar’; drop login foo go -- seleciona os dados da tabela de log para -- visualizar os eventos de login select * from tb_ddl_trigger_log go horario usuario evento objeto :44: geekmobile\carlos create_login foo :44: geekmobile\carlos drop_login foo

139 Segurança em Banco de Dados 139 O evento DDL é capturado no escopo da trigger por uma função chamada EVENTDATA(), que retorna dados no formato XML. Para se obter os valores desejados, declarase uma variável do tipo XML e o resultado da função EVENTDATA() é armazenado nesta variável. Os valores de LoginName, tipo de evento e nome do objeto são obtidos através da pesquisa, utilizando-se Xquery, na

140 Segurança em Banco de Dados 140 SQL Injection em ambientes Web

141 Segurança em Banco de Dados 141 Em um cenário onde existem informações armazenadas em bancos de dados e que podem ser acessados via web, tem-se a possibilidade do ataque do tipo SQL injection. SQL injection é um tipo de ataque muito simples, que baseia-se na execução de comandos SQL, sejam comandos de manipulação de dados - DML (select, insert, update, delete) ou comandos de definição de dados - DDL (create, drop, alter). Estes comandos são executados através das entradas de formulários web, ou seja, no local destinado para digitação de informações pelo usuário, onde são passados comandos SQL, que por falhas nas aplicações acabam por resultar em alterações no banco de dados ou no acesso indevido à aplicação. A figura 1 apresenta um exemplo clássico de tal prática numa tela de autenticação:

142 Segurança em Banco de Dados 142

143 Segurança em Banco de Dados 143 O problema ocorre devido a autenticação do usuário ser validada internamente pela aplicação com a seguinte instrução, que verifica se existe um usuário com o respectivo login e senha: SELECT * FROM tabela_usuarios WHERE login = 'campo_login' AND senha = 'campo_senha'

144 Segurança em Banco de Dados 144 Normalmente, seriam digitados o login e a senha, que resultaria em uma consulta ao banco de dados para verificar se os mesmos conferem mas na figura acima foi passado parte de um comando SQL no campo reservado para senha, que internamente resultará na seguinte instrução: SELECT * FROM tabela_usuarios WHERE login = '123' AND senha = ' ' or '1' = '1'

145 Segurança em Banco de Dados 145 Observe que o comando passado no campo da senha fez com que independente do login e senha informados, a condição seja sempre verdadeira, permitindo assim o acesso do usuário à aplicação sem o mesmo possuir a devida permissão. Existem diversas possibilidades de comandos que podem ser executados indevidamente através da passagem de parâmetros, onde alguns exemplos podem ser observados na tabela 1: SQL esperadoParâmetros informadosSQL resultante Comant á rio Campo_loginCampo_senha SELECT * FROM tabela_usuarios WHERE login = 'campo_login' AND senha = 'campo_senha' marcos ’ ;-- SELECT * FROM tabela_usuarios WHERE login = 'marcos';--' AND senha = 'campo_senha' Se o usu á rio j á souber o login (no caso, login do usu á rio marcos) então consegue logar sem senha, j á que os caracteres “ -- “ são coment á rios no SQL ' OR 1=1 -- SELECT * FROM tabela_usuarios WHERE login = '' OR 1=1--' AND senha = 'campo_senha' Neste caso, não é necess á rio saber nem o login nem a senha, pois a condi ç ão “ OR 1=1 ” sempre vai ser satisfeita e todos os comandos posteriores são comentados pelos carecteres “ -- ” 123'; DROP TABLE produtos; - - SELECT * FROM tabela_usuarios WHERE login = '123'; DROP TABLE produtos;-- ' AND senha = 'campo_senha' Este caso é muito parecido com o primeiro mas um comando para apagar uma tabela é executado antes do coment á rio. Na verdade aqui o objetivo era somente apagar a tabela, por isso foi passado um login qualquer. Tabela 1 – Passagem de parâmetros SQL injection

146 Segurança em Banco de Dados 146 Sistemas Desktop e Web ainda permanecem como alvos vulneráveis, apesar da disponibilidade de ferramentas e de procedimentos que dificultam a ocorrência de ataques. A fragilidade desses sistemas muitas vezes é potencializada pelo desconhecimento que os programadores possuem sobre a programação segura e também sobre os cenários nos quais esses ataques ocorreram e foram bem sucedidos. Considerações Finais

147 Segurança em Banco de Dados 147 Trabalho em grupo Tema: Auditoria no SQL SERVER 2005 O trabalho deverá ser feito em grupo de 4 ou 5 pessoas; Cada grupo deverá preparar sua própria apresentação em PPT; O tempo de apresentação é de 20 a 30 minutos. O trabalho deverá seguir as normas da ABNT; Poderá ser consultada qualquer fonte desejada, porém nada deverá ser copiado e SIM escrito com suas próprias palavras o entendimento sobre o assunto. Qualquer tipo de CÓPIA invalidará o trabalho. Deverá conter no mínimo 7 e no máximo 10 páginas; Data de Entrega: Ainda será definida. Pontuação 15 Pontos da parte escrita 5 Pontos de apresentação


Carregar ppt "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ções semelhantes


Anúncios Google