evoluÇÃo da seguranÇa no sgbd microsoft sql server...
TRANSCRIPT
EVOLUÇÃO DA SEGURANÇA NO SGBD MICROSOFT SQL SERVER
Análise Comparativa: SQL Server 2000, 2005 e 2008
IREMAR NUNES DE LIMA 1
RAQUEL CARDOSO LEMOS 2
Resumo: Este trabalho apresenta os principais mecanismos de segurança utilizados pelo
SGBD Microsoft SQL Server, juntamente com a constante evolução do produto, no que
tange a área de segurança dos dados. A evolução do produto na área de segurança é
demonstrada por meio de uma análise comparativa do SQL Server 2000, 2005 e 2008.
Palavras-chave: Banco de Dados, SGBD, Microsoft SQL Server, segurança.
1 Mestre em informática e professor do centro universitário Newton Paiva ([email protected]). 2 Graduanda em Sistemas de Informação ([email protected]).
2
1 INTRODUÇÃO
A informação pode ser considerada um dos principais ativos de uma empresa, sendo utilizada
como um fator decisório na tomada de decisão. Informações são extraídas a partir da
manipulação dos dados, e, para ter uma informação confiável é necessário fornecer o
armazenamento e o controle eficaz desses dados.
Segundo Allen G. Taylor (TAYLOR, 2001), ao armazenarmos dados importantes devemos
considerar quatro fatores essenciais, sendo eles: rapidez e facilidade no armazenamento dos
dados; confiabilidade no local em que os dados são armazenados; recuperação rápida e fácil
dos dados, e por último, facilidade na manipulação dos dados, com a finalidade de filtrar
apenas os dados desejados.
Os Sistemas Gerenciadores de Banco de Dados (SGBD) atendem esses quatro requisitos no
armazenamento de dados. Segundo Júlio Battisti (BATTISTI, 2005), não existe aplicação que
não dependa dos dados, que, na maioria das vezes, são armazenados e manipulados com o
auxilio de um SGBD.
Devido à grande importância que os dados representam — e a utilização cada vez mais
freqüente de SGBD’s — faz-se necessário que os Bancos de Dados utilizem mecanismos para
garantir a segurança dos dados, e, conseqüentemente, da informação, tendo como pré-
requisitos a integridade, a confidencialidade e a disponibilidade.
Dessa forma, esse artigo tem como objetivo apresentar os mecanismos de segurança do
SGBD Microsoft SQL Server e suas melhorias; fazer um paralelo entre as versões 2000, 2005
3
e 2008, e analisar as diferenças e semelhanças no que tange a área de segurança da
informação.
O presente trabalho se justifica, portanto, devido à importância dos dados e conseqüentemente
da informação para uma organização. Na atualidade, a informação pode ser considerada como
um fator crítico para a sobrevivência de uma empresa, pois influencia diretamente na tomada
de decisão.
O processo de informatização trouxe consigo um novo cenário, no qual é requerido que as
bases de dados sejam bem estruturadas e organizadas, com o objetivo de fornecer informações
confiáveis no momento preciso. A tecnologia permitiu uma forma mais eficiente de gerenciar
os dados, mas com isso trouxe também novos riscos, sendo necessário prover mecanismos
para garantir a segurança da informação.
A segurança da informação tem como objetivo controlar o acesso à informação e não permitir
o uso não-autorizado. Hoje, a segurança da informação pode ser considerada uma área crítica
dentro de uma empresa, pois a informação esta sujeita a uma série de riscos. Ataques de
crackers (black hat hackers), de engenharia social, vírus, worms, negação de serviço,
espionagem eletrônica são noticiadas pela imprensa todos os dias (ISSA, 2006).
Além disso, a necessidade de manter o ambiente dos dados seguros não é somente
influenciada pelos riscos de ataques e roubo de informações, há também fatores externos que
influenciam diretamente na implementação de medidas de segurança, como exigências do
Banco Central e de leis, como é o caso da Lei Sarbanes Oxley (SOX).
4
Se a informação é considerada um ativo essencial para a vida de uma organização, e as
informações são provenientes dos dados, que por sua vez são, na maioria dos casos,
armazenados em um Banco de Dados, é essencial que seja implementado mecanismos de
segurança nos SGBD’s, com o objetivo de promover segurança no acesso às informações. Em
relação à segurança no acesso às informações, Battisti explica:
Falando de uma maneira simples, a segurança no acesso às informações significa que o usuário deve ser capaz de acessar os dados necessários com nível de acesso suficiente (e não mais que suficiente), para que o usuário realize o seu trabalho. (BATTISTI, 2005, p.282).
Segundo Elmasri e Navathe (2005), a segurança em banco de dados é uma área bastante
ampla, que abrange diversas questões, como: fatores legais e éticos, relacionados ao direito de
acesso a determinados tipos de informação; questões políticas, como quais informações não
devem ser disponibilizadas publicamente; e questões ligadas à política de segurança de uma
organização.
Sendo assim, a implantação de medidas de segurança nos bancos de dados é necessária, pois
os dados estão sujeitos a constantes ameaças, as quais podem resultar na degradação dos
objetivos de segurança, como integridade, disponibilidade e confidencialidade. Segundo
Elmasri e Navathe (2005), a integridade refere-se à exigência de que a informação seja
protegida contra alteração imprópria. A disponibilidade refere-se a tornar os objetos
disponíveis para o usuário que tenha direito a eles. Já a confidencialidade tem como objetivo
garantir que apenas pessoas autorizadas tenham acesso à informação.
Portanto, para proteger os dados e garantir os três princípios básicos da segurança
(disponibilidade, integridade e confidencialidade) em um banco de dados, quatro tipos de
medidas podem ser implementadas: controle de acesso; controle de inferência; controle de
5
fluxo e criptografia. Para atendimento às exigências externas é necessário também a
implementação de mecanismos de auditorias sobre operações nos bancos de dados.
Há diversos SGBD’s disponíveis no mercado, e cada qual possui mecanismos específicos
para garantir o gerenciamento da segurança dos dados. A escolha do SGBD da Microsoft,
para o presente artigo, se deve ao fato da popularidade do produto, sendo utilizado por
diversas aplicações de pequenas, médias e grandes empresas.
O restante do artigo está estruturado em quatro seções, sendo elas: A seção 2 abrange o
tratamento da segurança no Microsoft SQL Server 2000, 2005 e 2008, descrevendo os modos
de autenticação, os objetos relacionados à segurança, o tratamento da auditoria e a criptografia
de dados; a seção 3 que apresenta a análise comparativa dos mecanismos de segurança nas
três versões abordados do Microsoft SQL Server, a evolução do produto no quesito de
segurança, além das principais diferenças e semelhanças entre as versões; e por último, a
seção 4 que apresenta a conclusão do trabalho.
2 SEGURANÇA NO SGBD MICROSOFT SQL SERVER
A segurança em um SGBD é uma área bastante crítica, que envolve vários fatores como
questões políticas, éticas, legais e empresariais. Segundo Stanek (STANEK,2006), quando se
projeta a segurança de bancos de dados é necessário ter alguns objetivos principais, como o
equilíbrio entre a necessidade de acesso dos usuários aos dados e a proteção ao acesso não-
autorizado a eles; a restrição de permissões aos bancos de dados, possibilitando que os
6
usuários tenham somente o nível necessário para executar suas atividades; e também a
necessidade de fechar outras brechas de segurança que possam existir.
A política de segurança de um SGBD deve fornecer meios eficazes de proteger os dados das
principais ameaças, como perda de disponibilidade, integridade e confiabilidade. Segundo
Elmasri e Navathe (2005), para se proteger um banco de dados contra as ameaças devem ser
utilizadas medidas de controle de acesso, criptografia de dados, e auditorias. Assim, esta
seção tem como objetivo apresentar como é o tratamento da segurança no SGBD Microsoft
SQL Server, juntamente com os mecanismos existentes para o controle da segurança dos
dados.
2.1 Controle de acesso
O SGBD Microsoft SQL Server possui um modelo de segurança baseado na hierarquia de
objetos, implementando a segurança em camadas e trabalhando com o conceito de principals
e securables. Segundo Hotek (HOTEK,2009), principals são as entidades que são utilizadas
para se autenticar em uma instância/banco de dados, enquanto os securables são os objetos
dos bancos, nos quais os principals possuem permissões.
Segundo Stanek (STANEK,2006), os principals do SQL Server são distribuídos em três
níveis: nível do Windows, nível do SQL Server e nível do Banco de dados. A tabela 1
representa os principals existentes mais conhecidos, separados por níveis, conforme sugere
Stanek.
7
TABELA 1 – Principals do SQL Server mais utilizados Nível Principals incluídos. Windows Conta de domínio do Windows.
Conta de usuário local Grupo de usuários do Windows.
SQL Server SQL Server Role SQL Server Login.
Banco de dados Usuário do banco de dados Role do banco de dados Role de aplicação
Fonte: STANEK,2006, p. 236.
Os principals de segurança recebem permissões específicas para acessar os securables,
também conhecidos como “alcançáveis”. Segundo a Microsoft3, os securables são os recursos
para os quais o SGBD SQL Server regula o acesso, ou seja, são os objetos em que os
principals recebem permissões, incluindo a própria instância do SQL Server. Os securables
são separados em três escopos: escopo de servidor, escopo de banco de dados e escopo de
esquema. Esses securables estão demonstrados na tabela 2, juntamente com os escopos nos
quais estão localizados.
Apesar do SQL Server 2000 também trabalhar com a idéia da implementação de segurança
em camadas e utilização de hierarquia de objetos, o conceito de principals e securables não
era explicitamente utilizado, não sendo, portanto, conhecido. Porém, esse conceito passou a
ser extensamente utilizado no SQL Server 2005, e mantido no SQL Server 2008.
Segundo Battisti (BATTISTI, 2000), no SGBD Microsoft SQL Server 2000, o escopo de
segurança abrange basicamente quatro conceitos, sendo eles: Logins; User Accounts; Roles e
Permissios. Entende-se por login a credencial necessária para um usuário ter acesso ao
servidor/instância de banco de dados. User Accounts abrange as questões de acesso de um 3 http://msdn.microsoft.com/en-us/library/ms190401.aspx.
8
login a um banco de dados da instância. As Roles podem ser definidas como grupos de
usuários. Já as permissions são referentes às ações que podem ser executadas por um
determinado login em uma instância ou em um banco de dados.
TABELA 2 – Securables do SQL Server segundo a Microsoft. Escopo Securables incluídos Servidor Endepoint
Login Database
Banco de dados User Role Application role Assembly Message Type Route Service Remote Service Fulltext Catalog Certificate Asymmetric Key Symmetric Key Contract Schema
Esquemas Type XML Schema Collection Aggregate Constraint Function Procedure Queue Statistic Synonym Table View
Fonte: http://msdn.microsoft.com
Há várias diferenças existentes entre as versões do SQL Server (2000, 2005 e 2008), no que
tange a área de segurança dos dados, mas ambas as versões implementam a segurança em
camadas, na qual há vários níveis de acesso, por meio de uma hierarquia de objetos. As
camadas de segurança do SQL Server podem ser resumidas da seguinte forma:
9
WindowsNetwork Authentication
SQL ServerLogin Authentication
SQL Server LoginDatabase User Authentication
Solicitação de conexão de rede com o SQL Server
Solicitação de autenticação de login ao SQL Server
Solicitação de autenticação a um banco de dados de usuário
Figura 1 - As principais camadas de segurança
Fonte: WAYMIRE e SAETELL, 2001, p.127.
Como demonstrado na figura 1, a camada de autenticação de rede, de autenticação de login e
de autenticação de usuário são as camadas básicas de segurança que o SGBD SQL Server
utiliza, não se restringindo apenas a elas. As camadas de segurança serão aprofundadas no
tópico seguinte.
2.1.1 Camadas de acesso
Conforme dito anteriormente, o SGBD SQL Server implementa a segurança em camadas,
possuindo vários níveis de segurança de acesso aos dados. A primeira camada de segurança é
a de rede, na qual é possível configurar os protocolos de acesso utilizados pelo SQL Server.
10
Segundo a Microsoft4, para conectar-se ao SGBD SQL Server é preciso que seja habilitado
pelo menos um protocolo de rede. O SQL Server trabalha com os protocolos TCP/IP, Shared
Memory, Named Pipes e VIA. Desde a versão do SQL Server 2005, os protocolos de rede
podem ser habilitados pelo utilitário SQL Server Configuration Manager.
Nessa primeira camada de acesso, há também o mecanismo conhecido como TCP endpoints.
Segundo Hotek (HOTEK,2009), os endepoints são responsáveis por fornecer o controle sobre
a capacidade de conexão dos aplicativos a uma instância do SQL Server, determinando os
métodos de comunicação aceitáveis, e funcionando de maneira similar aos firewalls de uma
rede.
Segundo Hotek (HOTEK,2009), nas versões anteriores ao SQL Server 2008, qualquer
aplicativo podia se conectar a um servidor executando o SQL Server e transmitir qualquer
tipo de pedido. Com o mecanismo de TCP endpoints implementado no SQL Server 2008,
para que um aplicativo se conecte a um endepoint é necessário que o endepoint possua o
estado started, no qual indica que o endepoint está ativo e captando conexões, que o
aplicativo tenha permissão para se conectar no endepoint, e que o “tráfego que está indo para
o endepoint corresponda ao transporte e à carga útil correta” (HOTEK, 2009, p.293). A tabela
3 mostra o transporte e a carga útil aceita por um endpoint. Segundo Hotek (HOTEK,2009), a
combinação de um transporte com uma carga útil de endpoint permite que o SQL Server filtre
o “tráfego aceitável antes mesmo que o comando chegue à instância do SQL Server”
(HOTEK,2009, p.292).
TABELA 3 – Transporte e carga útil do endpoint Transporte Carga útil
4 http://msdn.microsoft.com/pt-br/library/ms187892.aspx
11
TCP TSQL TCP SERVICE_BROKER TCP DATABASE_MIRRORING HTTP SOAP
Fonte: HOTEK,2009, p.292.
O segundo nível de segurança é realizado no processo de conexão de um usuário com uma
instância de banco de dados. Segundo Battisti (BATTISTI, 2005), para que um usuário tenha
acesso a uma instância é necessário que o mesmo informe suas credenciais para autenticação.
O SQL Server trabalha com dois modos de autenticação, podendo ser o SQL Server e
Windows ou o Windows only.
No modo de autenticação Windows only é utilizado às contas de usuários locais, as contas de
domínio e os grupos de autenticação do Windows, que tenham permissão de acesso ao SQL
Server, para estabelecer a conexão com a instância de banco de dados. Quando a conexão de
um usuário na instância é feita por meio de uma conta do Windows, a identidade do usuário e
a validação do acesso são verificadas pelo sistema operacional. Segundo a Microsoft5, a
autenticação do Windows é considerada mais segura, devendo ser utilizada sempre que
possível, pois utiliza os protocolos de segurança do sistema operacional, como o protocolo
Kerberos, além de prover meios para impor políticas de segurança, suporte ao bloqueio de
contas e permitir a definição de termos para expiração de senhas.
Quando é utilizado o modo SQL Server e Windows, conhecido também como modo misto, é
possível estabelecer conexão com a instância de banco de dados por meio da autenticação do
Windows, abordada anteriormente, ou pela autenticação do SQL Server. Na autenticação do
SQL Server os logins são criados na instância, e não são relacionados às contas do Windows.
Os logins e as respectivas senhas são criados, armazenados e administrados no próprio SQL
5 http://msdn.microsoft.com/pt-br/library/ms144284.aspx
12
Server. No modo de autenticação do SQL Server, os usuários sempre devem fornecer o login
e a senha no momento da conexão, e é o SQL Server que valida às credenciais fornecidas.
Segundo a Microsoft, a autenticação do SQL Server possui algumas desvantagens, como o
fato de apresentar um modo de conexão menos seguro para a instância, não ser possível
utilizar o protocolo de segurança Kerberos, usado nas conexões que utilizam autenticação
Windows, e maior trabalho para administrar os logins. No SQL Server 2000 ainda há o fato
da autenticação do SQL Server não fornecer mecanismos para impor restrições de senhas,
baseados nas políticas de segurança do Windows, como acontece nas versões 2005 e 2008, o
que pode acarretar em vulnerabilidades no controle de acesso dos usuários.
A conexão de um usuário, juntamente com a autenticação de acesso, em um servidor SQL
Server é apenas a primeira barreira de segurança que é implementada. O estabelecimento de
uma conexão no servidor não significa que o usuário terá acesso aos bancos de dados. Para
que um usuário tenha acesso a um banco de dados do servidor é necessário que o login
utilizado tenha permissão para acessar o banco. Essa permissão de acesso é definida como
User Accounts, ou contas de usuários. Se o login não tiver um usuário criado no banco de
dados no qual é requerido o acesso, a conexão do login ao banco será negada pelo SQL
Server.
Segundo Waymire e Sawtwell (WAYMIRE; SAETELL, 2001), a camada final de segurança
no controle de acesso do SQL Server são as permissões. Por padrão o SQL Server nega acesso
a todos os objetos de um banco de dados. Portanto, não basta apenas ter uma conta de usuário
no banco de dados para que uma pessoa possa acessar os objetos e realizar operações sobre os
13
dados. Após estabelecer conexão com o banco de dados é necessário que o usuário tenha
permissões para acessar e manipular os objetos de acordo com a necessidade do negócio.
Segundo Hotek (HOTEK,2009), é possível conceder permissão a qualquer securable do SQL
Server. Conforme explicado anteriormente, os securables, conhecidos também como
alcançáveis, são os objetos para os quais é concedido permissões para os pincipals. No SQL
Server 2000 as permissões eram concedidas diretamente para os objetos de um banco de
dados. A partir da versão SQL Server 2005 é possível atribuir permissões por escopos, como
sugere Mike Hotek:
O SQL Server 2005 e posteriores definem vários escopos nos quais você pode atribuir permissões. Um alcançável pode ser um banco de dados, esquema ou um objeto. Como você concede permissões para um alcançável, pode atribuir permissões para um alcançável em qualquer escopo. A concessão de uma permissão em um banco de dados faz com que ela seja concedida implicitamente para todos os esquemas dentro de um banco de dados e, por isso, para todos os objetos dentro de todos os esquemas. A concessão de uma permissão para um esquema faz com que a permissão seja concedida implicitamente em todos os objetos dentro de um esquema. (HOTEK, 2009, p.313).
A atribuição de permissão por escopo, em vez de apenas por objetos, permite maior
flexibilidade no gerenciamento de permissões no SQL Server. Se um determinado usuário
necessita de permissões iguais em vários objetos, é muito mais simples e rápido atribuir
permissão em um escopo mais elevado, como de banco de dados ou de esquemas, em vez de
conceder permissões separadas por objetos.
Em se tratando de mecanismos de segurança, cabe ressaltar também o conceito de esquema,
conhecido também como schemas, que é relativamente novo, sendo implementado
inicialmente no SQL Server 2005. Um esquema, segundo Hotek (HOTEK,2009), é a primeira
14
camada de segurança dentro de um banco de dados que deve ser planejada. Os esquemas
podem ser definidos como um contêiner de objetos dentro do banco de dados. Segundo Hotek
(HOTEK, 2009), um esquema deve “representar um cluster funcional dentro de uma
aplicação”, permitindo que as permissões sejam gerenciadas de maneira mais eficaz.
Uma grande vantagem da aplicação de esquemas é o gerenciamento dos objetos e seus
respectivos proprietários. No SQL Server, segundo Battisti (BATTISTI, 2005), um objeto não
pode existir sem um proprietário. Nas versões anteriores ao SQL Server 2005, os objetos
pertenciam a um usuário especifico do banco de dados, o que gerava um problema no
gerenciamento dos usuários, pois, segundo Stanek (STANEK, 2006), não era possível
remover um usuário de um banco de dados sem antes transferir a posse de cada objeto
pertencente ao usuário que se deseja remover, o que alterava o nome completo do objeto,
podendo ocorrer problemas nas querys que utilizavam os determinados objetos. A partir do
SQL Server 2005 os proprietários dos objetos dos bancos de dados passaram a ser os
esquemas, com isso é possível eliminar usuários sem afetar o nome dos objetos, evitando,
assim, prováveis problemas nas querys das aplicações.
Outro mecanismo existente no SQL Server, que pode ser utilizado para gerenciar as
permissões dos principals nos securables, são os roles, ou papéis. O conceito de roles no
SGBD Microsoft SQL Server é muito próximo do conceito de grupos utilizado no sistema
operacional Microsoft Windows. Segundo Stanek (STANEK, 2006), os roles permitem
agrupar de maneira conveniente os vários usuários com as mesmas permissões. Em vez de
atribuir permissões a usuários individuas, ou principals, as permissões são atribuídas aos
roles. Dessa maneira, como sugere Stanek (STANEK, 2006), os usuários recebem o conjunto
de permissões requeridas, tendo seus principals adicionados no role apropriado.
15
O SQL Server possui roles em nível de instância e em nível de banco de dados. Os roles em
nível de instância, segundo Hotek (HOTEK, 2009), possuem capacidade de administração da
instância e são referidas como roles fixa de servidor, por não ser possível modificar as
permissões no role e nem adicionar roles novas em nível de servidor. Segundo Stanek
(STANEK, 2006), os principals que estão localizados na role de servidor podem realizar
qualquer tarefa permitida pela role.
Assim como os roles em nível de servidor, os roles em nível de banco de dados permitem
conceder um conjunto de permissões para os principals que fazem parte do role. É possível
criar novos roles em nível de banco de dados, o que não acontece nos roles em nível de
servidor. A Tabela 4 mostra os roles em nível de servidor, já a tabela 5 representa os roles
fixos em nível de banco de dados.
TABELA 4 – Roles fixas da instância SQL Server Role Os membros podem fazer. Bulkadmin Administrar operações de BCP e inserção em massa. Dbcreator Criar bancos de dados. Diskamin Gerenciar recursos de disco. Securityadmin Criar, alterar e eliminar logins, mas não podem alterar senhas. Serveradmin Executar as mesmas ações de diskadmin e processadmin, além de
gerenciar endpoints, alterar configurações de instância e encerrar a instância.
Setupadmin Gerenciar servidores vinculados. Sysadmin Executar qualquer ação dentro da instância. Os membros não podem ser
impedidos de acessar qualquer objeto ou de executar qualquer ação. Fonte: HOTEK,2009, p.305.
Os métodos de controle de acesso aos dados, discutidos nessa seção, são ferramentas
poderosas, mas por si só podem não ser capazes de fornecer toda a estrutura necessária para
proteger os dados que são armazenados e controlados por um SGBD. No tópico seguinte, será
16
abordado um poderoso mecanismo para a proteção de dados, disponível no SGBD Microsoft
SQL Server: a criptografia.
TABELA 5 – Roles fixas de bancos de dados do SQL Server Role Os membros podem fazer. db_accessadmim Adicionar ou remover usuários no banco de dados. db_backupoperator Permite apenas o backup do banco de dados. db_datareader Executar SELECT em todas as tabelas, views e roles. db_datawriter Executar INSERT, UPDATE, DELETE E MERGE em todas as tabelas
. db_ddladmin Executar instruções DDL (linguagem de definição de dados). db_denydataread Impedir SELECT em todas as tabelas, views e roles. db_denydatawriter Impedir Executar INSERT, UPDATE, DELETE E MERGE em todas
as tabelas dentro do banco de dados. db_owner O proprietário do banco de dados que tem controle total sobre o banco
de dados e todos os objetos nele contidos. db_securityadmin Gerenciar a partição como membros das roles e permissões associadas,
mas não podem gerenciar a partição como membro da role db_owner. Public Grupo padrão em todo banco de dados a que todos usuários pertencem.
Fonte: HOTEK,2009, p.307.
2.2 Criptografia de dados
A criptografia é um mecanismo utilizado para aumentar a proteção dos dados sensíveis, que
devem permanecer confidências, como senhas, números de cartões de crédito, entre outros.
Segundo a Microsoft 6, a criptografia consiste no processo de confundir os dados por meio da
utilização de chaves e senhas, que são gerados com a utilização de algoritmos específicos,
tornando os dados inteligíveis sem o uso da chave de descriptografia ou a senha
correspondente.
6 http://msdn.microsoft.com/pt-br/library/bb510663.aspx
17
Segundo a Microsoft, o SQL Server permiti utilizar criptografia para conexões, dados e
procedimentos armazenados, utilizando criptografia hierárquica e infra-estrutura de
gerenciamento de chaves. A hierarquia de criptografia utilizada possui o seu funcionamento
baseado em camadas, na qual, segundo a Microsoft7, “cada camada criptografa a camada
abaixo dela usando uma combinação de certificados, chaves assimétricas e chaves
simétricas.” A figura 2 mostra o funcionamento da hierarquia de criptografia utilizada pelo
SQL Server.
Para o entendimento da hierarquia de criptografia utilizada pelo SQL Server, é necessário ter
em mente que esse SGBD utiliza alguns mecanismos para realizar a criptografias dos dados,
como chaves simétricas, chaves assimétricas, certificados e criptografia transparente dos
dados.
Segundo Hotek (HOTEK,2009), as chaves simétricas utilizam apenas uma senha para
realizar tanto a criptografia como a descriptografia dos dados. A grande vantagem desse
modelo de dados é o ganho de performance, porém oferece menos segurança do que o modelo
baseado em chaves assimétricas.
Nas chaves assimétricas, segundo a Microsoft8, é utilizada uma senha (chave pública) para
criptografar dados, e outra senha (chave privada) para realizar a descriptografia dos dados. Já
os certificados são considerados um caso especial de chave assimétrica. Segundo Hotek
(HOTEK,2009), tanto os certificados como as chaves assimétricas são baseados no padrão
x.509 e possuem aplicação equivalente. A principal diferença entre eles é que as chaves
assimétricas são geradas por um servidor dentro da própria empresa, não sendo possível
realizar backups ou movimentação da chave de um sistema para outro, já os certificados,
7 http://msdn.microsoft.com/pt-br/library/ms189586.aspx 8 http://msdn.microsoft.com/pt-br/library/bb964742.aspx
18
segundo a Microsoft, podem ser emitidos por uma autoridade certificadora (CA) e
posteriormente importado para o SQL Server, ou gerado dentro da própria instância do SQL
Server. Os certificados, segundo Hotek (HOTEK,2009), permitem a realização de backup e
restauração, possibilitando a movimentação de banco de dados criptografados.
Figura 2 - Hierarquia de criptografia no SQL Server, segundo a Microsoft.
19
Fonte: http://msdn.microsoft.com/pt-br/library/bb964742.aspx
O SGBD Microsoft SQL Server possui dois aplicativos principais para chave, sendo a SMK e
a DMK. Segundo a Microsoft, a SMK (chave mestra de serviço) é uma chave simétrica
gerada na primeira inicialização da instância do SQL Server, sendo utilizada para a
criptografia de senhas, de credenciais e da DMK (chave mestra de banco de dados). A SMK é
criptografada com a API de proteção do Windows, conhecida como DPAPI. Já a DMK,
segundo a Microsoft, é uma chave simétrica utilizada para proteger as chaves privadas dos
certificados e as chaves assimétricas localizadas no banco de dados.
Além da utilização de chaves simétricas, assimétricas e certificados, o SQL Server 2008
introduziu também um novo mecanismo utilizado para a criptografia de dados, conhecido
como criptografia de dados transparentes (TDE). Segundo Hotek (HOTEK,2009), a TDE é
utilizada para criptografar dados “em repouso”, realizando a criptografia e a descriptografia
em tempo real, permitindo que os arquivo de dados e de log de transação, juntamente com os
arquivos de backup, sejam criptografados.
Segundo Hotek (HOTEK,2009), a TDE utiliza uma chave de criptografia, localizada dentro
do registro de inicialização do banco de dados, para o seu funcionamento. Para a criptografia
da chave TDE é utilizado um certificado armazenado no banco de dados master. Sem o
certificado armazenado no banco de dados master não é possível obter acesso ao conteúdo
dos arquivos de dados, log, ou até mesmo do backup de um banco de dados do SQL Server.
Quando a TDE é implementada em uma instância do banco de dados, é necessário que se
mantenha sempre um backup do certificado e da chave de criptografia armazenado em um
20
local seguro, pois, segundo a Microsoft, a restauração de um backup efetuado em uma
instância que utiliza TDE só é possível por meio da utilização do certificado e da chave
privada correspondentes.
Apesar de a criptografia ser um mecanismo bastante eficiente para a proteção de dados,
principalmente quando há falhas de segurança nas camadas de acesso, ela não deve ser
utilizada de maneira exagerada, pois apesar do aumento da segurança proporcionada, a
implantação desse mecanismo pode consumir muitos recursos do servidor, principalmente
CPU, ocasionando problemas de desempenho nos bancos de dados.
2.3 Auditoria no SQL Server
Os mecanismos de auditoria podem ser implantados por diversos motivos, seja para atender
fatores externos, como é o caso da Lei Sarbanes Oxley (SOX), ou para auxiliar na
manutenção dos princípios básicos da segurança da informação, como a integridade dos
dados. Por meio de mecanismos de auditoria é possível controlar alterações, verificar
tentativas de acesso bem e mal sucedidas, e até mesmo monitorar falhas e mensagens de erros
nos bancos de dados. A presente seção tem como objetivo descrever os mecanismos
existentes no SGBD SQL Server, que podem ser utilizados para a realização de auditorias
sobre os bancos de dados.
Um mecanismo de auditoria, disponível em todas as versões do SQL Server abordadas nesse
artigo, que pode ser bastante útil são as triggers de DDL (linguagem de definição de dados) e
21
de DML (linguagem de manipulação de dados). As triggers, conhecidas também como
gatilhos, são mecanismos utilizados para “disparar” uma ação decorrente de algum evento no
banco de dados. Segundo Hotek (HOTEK,2009), além de permitir que se armazene comandos
executados nos bancos, como CREATE, DROP E ALTER, para que se possa auditar
posteriormente, as triggers podem ser utilizadas também para impedir a execução de
determinadas comandos de DDL, fornecendo uma maneira de impedir que a integridade dos
dados seja afetada.
Antes do SQL Server 2008, segundo Hotek (HOTEK, 2009), era necessário a utilização de
vários recursos para fornecer um mecanismo eficiente de auditoria. As alterações nos dados e
nos bancos eram auditadas por meio das triggers, a auditoria de instruções SELECT era feita
pelo SQL Trace, e a auditoria de logins bem e mal sucedidos era efetuada por meio das
propriedades de segurança da instância, salvando as informações no “errorlog” do SQL
Server.
Segundo Hotek (HOTEK, 2009), o SQL Server 2008 implementa uma especificação de
auditoria, na qual possui a combinação de todos os recursos de auditorias das versões
anteriores. Nessa especificação de auditoria é criado um objeto de auditoria, em nível de
servidor, que define a localização dos registros da trilha de auditoria. Ao objeto de auditoria
são vinculadas as especificações de auditoria da instância e do banco de dados. O SQL Server
2008 permite a criação de especificação de auditoria em nível de instância e especificações de
auditoria para eventos específicos de banco de dados.
22
Segundo a Microsoft9, as especificações de auditoria disponível no SQL Server 2008 podem
ser categorizadas no nível de instância, no nível de banco de dados, ou no nível de auditoria.
No nível de instância, podem ser auditadas as operações do servidor, como logon e logoff e
alterações de gerenciamento. No nível de banco de dados, podem ser auditadas as ações
especificas sobre o banco de dados, como criação de objetos, execução de instruções de
SELECT, DELETE, UPDATE, entre outras ações. Já no nível de auditoria, é possível auditar
as ações sobre o próprio processo de auditoria, como a criação de auditoria de servidor
(CREATE SERVER AUDIT).
Outro mecanismo de auditoria disponível no SQL Server é a auditoria C2. Segundo Hotek
(HOTEK, 2009), a auditoria C2 é uma especificação de auditoria do Departamento de Defesa
dos EUA, que permite fazer a “auditoria de cada tentativa bem ou mal sucedida de acesso a
um objeto de banco de dados.” (HOTEK,2009, p.327). Em se tratando da auditória C2, Holtek
explica:
Quando a auditoria C2 está ativada, um arquivo de log de auditoria é gravado no diretório de dados padrão, com um tamanho de memória de 200 megabytes (MB). O SQL Server continua a gerar arquivos de memória até terminar o espaço em disco, fazendo com isso a instância ser encerrada. Com a auditoria C2 ativada, os registros de auditoria são gravados obrigatoriamente. Se o sistema estive muito ocupado, os pedidos dos usuários serão cancelados para liberar recursos para gravar a trilha de auditoria. (HOTEK,2009, p.327).
Devido à demanda necessária de recursos para a implantação da auditoria C2, como espaço
em disco, aumento no uso de CPU e de I/O no servidor, a mesma deve ser utilizada apenas
como última alternativa, quando é realmente necessário auditar todas as tentativas de acesso
aos objetos dos bancos de dados. Caso contrário, deve-se verificar se um nível mais baixo de
auditoria não atende a necessidade do negócio. No mecanismo de auditoria C2, o SGBD
considera que a auditoria é mais importante do que uma transação, e, segundo Hotek 9 http://msdn.microsoft.com/pt-br/library/cc280663.aspx
23
(HOTEK, 2009), se o sistema ficar muito sobrecarregado, o SQL Server dará prioridade na
gravação da auditoria, ao invés da execução de uma transação de usuário no banco de dados.
3 ANÁLISE COMPARATIVA
O SGBD Microsoft SQL Server vem sofrendo constantes modificações na área de segurança.
A cada nova versão que é lançada, se torna mais perceptível a preocupação da Microsoft com
a proteção dos dados armazenados no SQL Server.
A partir da versão do SQL Server 2005, a Microsoft acoplou a iniciativa de “Computação
Confiável” ao produto. Segundo a Microsoft10, a “Computação Confiável” tem como
objetivo promover a melhora da segurança, da privacidade, da integridade e da confiabilidade
dos negócios. Para se adequar à iniciativa da “Computação confiável” promovida pela
Microsoft, a versão do SQL Server 2005 implantou várias estratégias de segurança, como:
“seguro por design”, “seguro por padrão”, e “seguro por instalação”.
O termo “seguro por design” significa que o SGBD SQL Server foi concebido tendo a
segurança como foco principal, sendo tratada na própria arquitetura do sistema. Em se tratado
de “seguro por padrão” e “seguro por instalação”, o SQL Server garante que durante a
instalação de uma nova instância todas as opções de configurações sejam configuradas
corretamente, garantido a segurança do SGBD.
10 http://www.microsoft.com/brasil/servidores/sql/2005/productinfo/securityfeatures1.mspx
24
Durante a instalação, por exemplo, desde a versão 2005, o “SQL Server desativa cada recurso
desnecessário para o funcionamento do mecanismo do banco de dados” (HOTEK, 2009,
p.299). Caso seja necessário, os mecanismos podem ser ativados manualmente. Outra
importante modificação, ocorrida no SQL Server 2005 e mantida no SQL Server 2008, foi a
implantação de mecanismo para a imposição de restrições de senhas no modo de autenticação
do SQL Server, baseados nas políticas de segurança do sistema operacional Windows.
Segundo a Microsoft11, no SQL Server 2008 o grupo de administradores do sistema
operacional, o BUILTIN\Administrador, deixou, por padrão, de ter acesso administrativo nas
instâncias. Na versão 2008, houve também extensão da utilização do protocolo kerberos, que
passou a incluir pipes nomeados e protocolos de memória compartilhada.
Quando se compara o modelo de segurança do SQL Server 2000, 2005 e 2008, é possível
perceber várias modificações, seja nas camadas de segurança, no uso de criptografia, ou nos
mecanismos utilizados para a auditoria das instâncias e dos bancos de dados. As tabelas 6, 7 e
8 fornecem uma visão geral das modificações mais significativas na área de segurança do
SGBD Microsoft SQL Server.
TABELA 6 – Evolução nas camadas de Acesso no SQL Server.
Categoria Mecanismo SQL 2000
SQL 2005
SQL 2008 Comentários
Rede
Protocolos X X X Todas as versões utilizam protocolos de rede.
Endepoints - X X
Apenas a versão 2008 permite controlar o acesso por meio da combinação do transporte e da carga útil do endepoint.
Autenticação Windowns X X X
O protocolo de autenticação kerberos está presente apenas a partir do SQL Server 2005.
11 http://msdn.microsoft.com/pt-br/library/cc280562.aspx
25
SQL Server X X X
A partir da versão 2005 é possível impor restrições de senhas, baseadas nas políticas de segurança do Windows.
Permissões
Por objeto X X X Todas as versões do SQL abordadas permitem a concessão de permissões por objetos.
Por escopo - X X
A partir do SQL Server 2005 é possível atribuir permissões por escopos, e não somente por objetos.
Esquemas - X X
O conceito de esquema foi implementado no SQL Server 2005, e mantido no SQL Server 2008. É um poderoso mecanismo para o controle de permissões.
Roles X X X Presente nas três versões. Fonte: Própria autoria. TABELA 7 – Evolução na criptografia de dados.
Categoria Mecanismo SQL 2000
12
SQL 2005
SQL 2008 Comentários
Criptografia
Chave simétrica - X X
As chaves simétricas foram implementadas na versão 2005 e mantidas no SQL Server 2008.
Chave assimétrica - X X
As chaves assimétricas foram implementada na versão 2005 e mantida no SQL Server 2008.
Certificado - X X Os certificados foram implementada na versão 2005 e mantidos no SQL Server 2008.
DMK - X X
A DMK (Chave mestra de banco de dados) surgiu no SQL Server 2005, e foi mantido no SQL Server 2008.
SDK - X X A SMK (Chave mestra de serviço) surgiu no SQL Server 2005, e foi mantido no SQL Server 2008.
TDE - - X Mecanismo existente apenas no SQL Server 2008.
Fonte: Própria autoria.
12 Não foi encontrada, na bibliografia, nenhuma referência a mecanismos de criptografia de dados existente no SQL Server 2000.
26
Além das modificações já citadas, o SQL Server também sofreu constantes mudanças no
controle da área de superfície. Uma das novidades no lançamento do SQL Server 2005 foi o
utilitário Surface Area Configuration, que permite o gerenciamento e configuração de vários
mecanismos, que são desabilitados por padrão durante a instalação de uma instância do SQL
Server, como consultas ad hoc distribuídas e execução de comandos xp_cmdshell. O Surface
Area Configuration, porém, foi descontinuado na versão do SQL Server 2008, e o controle da
área de superfície passou a ser utilizada pela execução da procedure sp_configure, conforme
explica Mike Hotek:
A funcionalidade que era fornecida pelo Surface Area Configuration for Connections agora é executada com o SQL Server Configuration Manager. A funcionalidade fornecida pelo Surface Area Configuration for features não mudou; a interface GUI para sp_configure foi apenas removida. (HOTEK, 2009, p.301).
TABELA 8 - Evolução da auditória do SQL Server.
Categoria Mecanismo SQL 2000
SQL 2005
SQL 2008 Comentários
Auditoria
Triggers de DDL X X X
É possível implementar a auditoria utilizando as triggers de DDL (Liguagem de definição de dados) em todas as versões abordadas.
Triggers de DML X X X
É possível implementar a auditoria utilizando as triggers de DML (Liguagem de manipulação de dados) em todas as versões abordadas.
SQL Trace X X X
Mecanismo que permite a coleta de informações de uma instância do SQL Server. Pode ser utilizado para auditar execução de instruções SQL, como SELECT.
Auditoria de logons X X X
Disponível em propriedades de segurança da instância, e se mecanismo apresenta quatro opções de auditoria de logons: “nenhum”, no qual é desativada a auditoria de logons; somente logins com falhas; somente logons bem sucedidos; e a opção de registrar tanto logons com
27
falhas como os bem sucedidos.
Especificação de auditoria _ _ X
Novo mecanismo de auditoria do SQL Server 2008, que combina todos os recursos de auditória das versões anteriores.
Auditoria C2 X X X
Mecanismo de auditoria existente desde a versão 2000, mas que não é muito utilizada. Com esse mecanismo é possível auditar toda tentativa de acesso aos objetos de uma instância.
Fonte: Própria autoria.
Analisando a evolução dos mecanismos de segurança presentes nas versões do SQL Server
abordadas (SQL Server 2000, 2005 e 2008), é possível perceber que muitos mecanismos se
mantiveram presentes, sofrendo modificações significativas, enquanto outros foram
acrescentados para ampliar a segurança do SGBD. Uma das modificações mais significativas
no escopo de segurança no SGBD SQL Server, nas versões estudadas, foram os mecanismos
de criptografia dos dados, implementados a partir da versão 2005.
4 CONCLUSÃO
Um Sistema Gerenciador de Banco de Dados (SGBD) tem como principal função o
armazenamento e o controle eficaz dos dados, que serão manipulados e transformados em
informação. A informação de uma empresa é considerada um dos principais ativos, podendo
representar um fator de sucesso para o negócio. Como a informação é gerada a partir dos
dados, que, na maioria dos casos, estão armazenados em um banco de dados, é necessário que
os SGBD’s forneçam mecanismos eficazes de segurança.
28
Quando se pensa na área de segurança de um Sistema Gerenciador de Banco de Dados
(SGBD), e conseqüentemente na segurança dos dados, deve-se ter em mente a adequação aos
objetivos fundamentais de segurança, como integridade, disponibilidade e confiabilidade,
além do cumprimento a normas e leis externas, como, por exemplo, a SOX.
Para a adequação dos objetivos de segurança e cumprimento das leis e normas externas, é
exigido dos SGBD’s mecanismos de segurança que possibilitem a autenticação de conexão
com bancos e dados, permitam o controle de acesso, protejam os dados considerados
confidencias e possibilitem auditar as principais operações sobre os dados. Conforme visto no
decorrer do presente trabalho, o SGBD Microsoft SQL Server, em suas últimas versões,
fornece mecanismos que se adéquam a todas as exigências de segurança.
Por meio da análise dos mecanismos de segurança presentes no SQL Server 2000, 2005 e
2008, é possível perceber a preocupação constante da Microsoft com a segurança dos dados, e
a evolução crescente do produto nessa área. A cada nova versão lançada, há sempre novas
features de segurança, que possibilitam a implementação de medidas de segurança mais
eficazes, e permitem um melhor gerenciamento da segurança nas instâncias de banco de
dados.
A área de segurança é de extrema importância, e a aplicação da mesma nos bancos de dados
não é diferente. Apesar do SGBD Microsoft SQL Server, principalmente a versão 2008,
oferecer diversos mecanismos para a proteção dos dados, é necessário que os administrados
dos bancos de dados os implementem e os gerenciem adequadamente, para que se possa tirar
o máximo proveito dos mecanismos disponíveis.
29
Concluindo, é importante ressaltar que apesar das constantes melhorias no SQL Server,
sempre haverá a possibilidade de haver falhas de segurança, e conseqüentemente invasões,
seja devido a uma má administração da segurança nos servidores de banco de dados, ou por
vulnerabilidades descobertas no produto. É necessário que os administradores gerenciem de
forma correta os bancos de dados, e que a Microsoft fique atenta a possíveis falhas, e lance
sempre atualizações de correções para as possíveis ameaças descobertas.
30
REFERÊNCIAS
BATTISTI, Júlio. SQL Server 2005: administração & desenvolvimento: curso completo. Rio de Janeiro: 7 Letras, 2005. xxvi, 990 p. TAYLOR, Allen G. SQL para dummies. Rio de Janeiro: Campus, 2001. 409 p. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4.ed. Rio de Janeiro: Pearson, 2005. 724p. Introdução a segurança da Informação. Modulo Security, 2001, 65 p. Curso básico de Segurança da Informação. HOTEK, Mike. Kit de treinamento MCTS (Exame 70-432): Microsoft SQL Server 2008: Implementação e Manutenção. Porto Alegre: Bookman, 2010, 664 p. SATANEK, William R. Microsoft SQL Server 2005: Guia de bolso do Administrador. Porto Alegre: Bookman, 2006, 576 p. WAYMIRE, Richard; SAWTELL, Rick. Aprenda em 21 dias Microsoft SQL Server 2000. Rio de Janeiro: campus, 2001, 765 p. BATTISTI, Júlio. SQL Server 2000: administração & desenvolvimento: curso completo. Rio de Janeiro: Axel Books, 2001, 793 p.