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

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

Prof: Thiago Moraes Martins

Apresentações semelhantes


Apresentação em tema: "Prof: Thiago Moraes Martins"— Transcrição da apresentação:

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 Ementa 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 Objetivo da Disciplina
Estimular o conhecimento sobre segurança da informação. Desenvolver uma política de segurança para SGBDs. Conhecer técnicas de ataque aos SGBDs. Aplicar a auditoria aos banco de dados. 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 1 ESTRATÉGIAS PARA SEGURANÇA DA INFORMAÇÂO
Ementa: 1 ESTRATÉGIAS PARA SEGURANÇA DA INFORMAÇÂO Fundamentos sobre segurança Segurança na Web A Informação – porque necessita de segurança? 2 SEGURANÇA NOS SGBDs 2.1 O papel do DBA na segurança dos SGBDs 2.2 Backup e Recovery 2.3 Infra estrutura adequada visando a segurança dos SGBDs 2.4 Controle de acesso discreto e mandatório 2.5 Roles

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

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

7 Bibliografia Indicada
DATE, C. J. Introdução a sistemas de banco de dados. Rio de Janeiro: Elsevier, 2003. ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de dados: fundamentos e aplicações. 4. ed. São Paulo: Pearson Education, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. Tradução da 5ª Edição. São Paulo: Campus, 2006. Bibliografia Opcional 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

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 Controle de acesso discricionário

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 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 • 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 Comando GRANT

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 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 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 Exemplos do uso do comando GRANT

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 O comando Revoke

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

22 Exemplos do uso do comando REVOKE

23 REVOKE SELECT ON tb_cep FROM PUBLIC;
REVOKE SELECT ON funcionario FROM admuser RESTRICT; REVOKE ALL ON tb_cep FROM admuser CASCADE;

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 Gráfico de autorização

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 • 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 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; GRANT SELECT ON Item TO Rob WITH GRANT OPTION; (executed by Vera) (executed by Artur)

29 GRANT SELECT ON Item TO Artur WITH GRANT OPTION;
(executed by Rob) REVOKE SELECT ON Item FROM Artur CASCADE ; (executed by Jose)

30 Figura 01

31 Dados Criptografados

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 Verificando o tráfego na rede

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 Capturando pacotes de informações

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

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 Listagem 8. Pacote de dados sem criptografia.
DBCRIPT D! db2admin NULLID SYSSH 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 SYSSH SYSLVL !F/ aÐQ / [ MSELECT A.ID_APLICACAO, C.COD_RESTRICAO, B.* FROM APLICACOES A LEFT JOIN RESTRICOES_APLIC B INNER JOIN RESTRICOES

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 Comando executado

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 Ativando criptografia no DB2

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 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 Figura 3. tela assistente

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 /

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 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 O uso do ethereal é simples e intuitivo – siga o roteiro abaixo para realizar seus primeiros
passos com o aplicativo: 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

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 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

55 Exemplo de Role no Sql Server 2005

56 Verificando propriedades do login SA.

57 O seu Server Roles está apontado para o fixed sysadmin.

58 - São aplicados ao usuário Server Roles - São aplicados aos logins
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 Criando um novo Login.

60

61 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. Desta forma tem uma relação entre os fixed Server roles conforme abaixo com os database role db_owner que é o mais poderoso.

62 Criação do login John e mapeando o mesmo ao usuário J

63 - Server Roles são utilizados para servidores.
Associar o usuário ao banco de dados DB_PERM - 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.

64 - Um pouco sobre cada um dos database role:
- 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: db_accessadmin O usuário tem permissão de criação ou não de login. db_backupoperator O usuário pode fazer backup/restore. db_datareader Permite ao usuário efetuar apenas o comando select, ou seja, somente leitura do banco de dados. db_datawriter Permite ao usuário efetuar gravações como update, delete e insert. db_ddladmin Pemite a criação de objetos como o create table, drop view, alter procedure, ou seja, criação de objetos de DDL. db_denydatareader Nega a permissão de leitura ao banco de dados.

65 db_denydatawriter db_owner db_securityadmin Public
Nega a permissão de gravação ao banco de dados. 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. db_securityadmin É relacionado as permissões de GRANT, DENY, REVOKE. 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 db_denydatawriter db_owner db_securityadmin Public
Nega a permissão de gravação ao banco de dados. 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. db_securityadmin É relacionado as permissões de GRANT, DENY, REVOKE. 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 Exibindo o usuário J criado.
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 Criação do login Mary e mapeando o mesmo ao usuário M

69

70 Associar o usuário ao banco de dados DB_PERM

71 Não será marcado nenhum fixed Server role.

72 Login John e Mary Usuário J e M
AMBOS NÃO POSSUEM PERMISSÃO ALGUMA!

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

74 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. Desta forma, todos os usuários que estiverem dentro do ROLE SA, conseguirão efetuar o select.

75 Efetuando o mesmo select com o John e Mary, o mesmo possui apresenta erro.

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

77 O usuário J (John) ainda não consegue efetuar a consulta select, pois o mesmo não está ainda dentro do ROLE.

78 O usuário M (Mary) ainda não consegue efetuar a consulta select, pois o mesmo não está ainda dentro do ROLE.

79 Após a inclusão do usuário J (John) ao ROLE, o mesmo já consegue efetuar a consulta.

80 Como J (John) já está dentro do grupo, o mesmo já consegue efetuar a consulta.

81 Após a inclusão do usuário M (Mary) ao ROLE, o mesmo já consegue efetuar a consulta.

82 Como M (Mary) já está dentro do grupo, o mesmo já consegue efetuar a consulta.

83 Todo o usuário que estiver dentro do grupo SALES, terá permissão correspondente ao ROLE atribuído.
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 Em caso de conflito de restrições, a que vale é a mais restritiva.
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. Veja a negação da permissão de SELECT para o usuário J.

85 O usuário J (John) não consegue mais efetuar a consulta.

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

87 Removendo o usuário M (Mary) do grupo SALES.

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

89 Visualizando informações do usuário J (John).

90 Visualizando informações do usuário M (Mary).

91 O comando abaixo retorna os membros de um determinado ROLE.

92

93 Contextualização

94

95 Auditoria

96

97

98

99

100 Introdução

101 Recurso Sql Server Audit

102

103 Server Audit Specification

104 Database Audit Specification

105 Target

106 Uso do Sql Server Audit

107 Criando Sql Server Audit

108 Criando Sql Specification

109

110 Testando a Auditoria

111 Editando a Auditoria

112 Auditoria aplicada a Rollback

113 Carregando os dados de auditoria em uma tabela

114

115

116 Considerações

117 Segurança no SQL Server 2005

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 No modelo de segurança do SQL Server 2005
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 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 2005. Tabela 1. Principal

121 Securables: objetos que recebem permissões são chamados de Securables
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 • 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 Surface Area Configuration

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 Figura 1. Surface Area Configuration for Services e Connections.

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 Figura 2. Surface Área Configuration for Features.

128 Políticas de senha para usuários SQL
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 2003. 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.

129 Tabela 4. Opções do comando CREATE LOGIN.

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 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 Triggers de DDL

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 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 Figura 3. Eventos que disparam Triggers de auditoria.

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 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)) --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 (getdate(), @data.value(‘(/event_instance/loginname)[1]’, ’nvarchar(100)’), @data.value(‘(/event_instance/eventtype)[1]’, ‘nvarchar(100)’), @data.value(‘(/event_instance/objectname)[1]’, ‘nvarchar(2000)’)) ;

138 -- 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 horario usuario evento objeto :44: geekmobile\carlos create_login foo :44: geekmobile\carlos drop_login foo

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 SQL Injection em ambientes Web

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

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 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 Tabela 1 – Passagem de parâmetros SQL injection
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 esperado Parâmetros informados SQL resultante Comantário Campo_login Campo_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 Considerações Finais 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.

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 "Prof: Thiago Moraes Martins"

Apresentações semelhantes


Anúncios Google