SQL Seguranca Art Rumos

Segurana do Microsoft SQL Server
Base MS SQL 2000+SP3 com referncias s verses 7 e 2005

Base MS SQL Server 2000+SP3 com referncias s verses 7 e 2005 A segurana dever ser uma das maiores se no mesmo a maior preocupao de um administrador de bases de dados (DBA DataBase Administrator), como tal nunca dever ser descurada ou abordada de nimo leve. A segurana, dever ser tida em conta e vista como uma prioridade, logo desde o incio do desenho do sistema. O administrador tem a preocupao, em preservar os dados e a sua integridade dos ataques externos e internos. Os dados de uma empresa tem que ser preservados, para que no possam ser, destrudos, corrompidos ou passados a empresas concorrentes. Ao traar um plano de segurana, o administrador dever em primeiro lugar identificar que utilizadores da organizao tem acesso a que informao e que tipo de actividades podem ter sobre os dados. Dividindo posteriormente os acessos por grupos de nveis de utilizao equivalente. Este artigo abordar de uma forma simples e resumida como est desenhado e funciona o modelo de segurana do Microsoft SQL Server, bem como indicar algumas boas prticas de como segurar o acesso a bases de dados e fornecer alguns scripts teis. Arquitectura A arquitectura de segurana deste Sistema de Gesto de Bases de Dados (SGBD) foi desenhada para funcionar em camadas, sendo baseada em utilizadores e grupos de utilizadores. As camadas podem ser s ao nvel do SGBD, ou ir ao Sistema Operativo (SO) e pessoa que tem uma conta de utilizador. A arquitectura de camadas tal como foi desenhada, ajuda a reduzir a possibilidade de um ataque ser bem sucedido, aumentando a possibilidade de o mesmo ser detectado e identificado. A arquitectura assenta nos seguintes componentes: Logins, Utilizadores, Permisses e Roles.
Esquema 1 A validao dos acessos no SQL Server feita por dois nveis e de forma hierrquica. Em primeiro temos a autenticao do login ao nvel do motor do SGBD. A autenticao pode ser SQL Server ou Windows. Aps a autenticao, ocorrer o processo de autorizao que se passa ao nvel da base de dados respectiva e seus objectos.
Nome Doc.: Ult. Actualizao:
Seguranca_Art_Rumos.doc 2007-08-14
Autor: Pgina:
Paulo Gonalves Pal_soft@hotmail.com 1/10
proibida a reproduo deste documento, no todo ou em parte, sem prvia autorizao da origem

Esquema 2 Uma regra bsica : atribuir o mnimo nmero de privilgios possvel. Se um dado utilizador na sua funo, no necessita de ter acesso a certos dados, no o poder ter. Os utilizadores s devero ter acesso ao que realmente necessitam para a funo que desempenham Autenticao Na autenticao, feita a identificao de quem est a tentar aceder ao SGBD, verificando unicamente se o utilizador em questo tem autorizao para se conectar ou no. Caso o utilizador possua acesso ao SGBD (autenticao bem sucedida) ento s estabelecida uma sesso entre ambos (utilizador e sgbd). A configurao do SQL Server assenta em dois modelos de autenticao. Podemos ter uma das seguintes autenticaes: - SQL Server (SQL Server Authentication) e/ou Windows (Windows Authentication). A cada um dos tipos de autenticao esto associados tipos de login distintos. Independente do modo que esteja configurado, poderemos sempre logarmos nos utilizando Windows authentication (ter que se passar as credenciais no momento do login). Do ponto de vista de performance aps a validao do login, no h qualquer diferena em escolher entre qualquer um dos modos. Quem define qual o tipo de acesso que um utilizador ter o Administrador do SGBD. Os modos de autenticao so definidos na instalao do SGBD, podendo ser alterados em qualquer altura aps a sua instalao (a mudana requer paragem de servios = indisponibilidade do ambiente). No processo de estabelecimento de um ligao ao SGBD, o motor verifica se o login (login name) fornecido, est autorizado a aceder SQL Server. Ao aceder ao SQL Server, caso no seja fornecido um login name e uma password, ou optar por autenticao Windows, o motor vai interpretar que se encontra perante um pedido de autenticao Windows.
Autor: Pgina:

Figura 1 (MS SQL Server 7/2000)
Figura 2 (MS SQL Server 2005) Windows Authentication: Quando um SQL Server est configurado para Windows Authentication, os acessos so dados a contas/grupos Windows. Este mtodo ser o mais vantajoso dos dois. Nestes casos o utilizador no necessita de ter um login adicional para se ligar ao SQL Server, utilizando assim o seu login de inicio de sesso Windows. Neste tipo de autenticao no possvel criar acessos SQL Server. Este modo de autenticao, tira partido do mecanismo de segurana do Windows, permitindo partilhar as credenciais (username e password) com o SQL Server. Quando o utilizador tenta aceder ao SQL Server, o SGBD vai solicitar e obter os dados do utilizador e a sua password da sesso Windows em que se encontra. Ser o mtodo mais seguro, pois no h a necessidade de enviar os logins e as passwords pela rede. Sempre que h mudana de password na conta de sistema o utilizador no ter que o alterar no SQL Server. Permite adicionar grupos j existentes levando consigo todos os utilizadores que lhe pertencem. Permite tirar partido de configuraes de sistema para os logins, como por exemplo o expirar da password e permite ainda auditar e fazer log das operaes da conta. SQL Authentication: Quando este mtodo de autenticao est implementado, estamos perante uma situao de modo misto (mixed mode). Nesta situao o administrador ter que definir e criar logins e passwords para os seus utilizadores SQL. Os utilizadores SQL, j tero que fornecer o login e a password sempre que tiverem necessidade de se conectarem ao SGBD. Este modo s dever ser escolhido em situaes de, retro compatibilidade, ambientes mistos em que os utilizadores no so provenientes de plataforma Windows ou quando o SQL Server estiver instalado num Windows 9x. Apesar de no ser muito aconselhvel, pois pode provocar equvocos, um login SQL Server pode ter o mesmo nome que um utilizador de sistema. Autorizao
Nome Doc.: Ult. Actualizao: Seguranca_Art_Rumos.doc 2007-08-14 Autor: Pgina: Paulo Gonalves Pal_soft@hotmail.com 3/10

O administrador de bases de dados, tem entre outras a responsabilidade de atribuir permisses especficas ao binmio utilizador/base de dados. da responsabilidade do administrador a criao dos acessos (logins) ao SGBD e que tipo de aco/manipulao pode determinado login (perfil de acesso) ter sobre uma base de dados. Da mesma forma que s um login vlido se consegue ligar ao SGBD, s uma conta (user account) vlida consegue conectar-se a uma base de dados. As permisses de objectos bem a quem pertencem so controladas ao niver da conta de utilizador, estando os logins SQL Server associados a estas contas. Aps a autenticao ter sido concluda com sucesso, passa-se ao segundo passo que a autorizao (verificao das credenciais/permisses) do utilizador na base de dados a que pretende aceder. O utilizador para aceder a uma determinada base de dados dever ter permisses atribudas sobre a mesma, caso contrrio s consegue estabelecer uma conectividade ao nvel do sgbd nunca chegando a ter acesso aos dados. So os logins, bem como os roles a que estes pertenam que identificam um utilizador nas bases de dados e que indicam quais as operaes que podem efectuar e a que objectos que podem aceder, executar, etc. Quando h um grupo de utilizadores que tenham um conjunto de permisses iguais, os mesmos podem (devem) ser agrupados segundo as suas regras comuns de acesso dentro de um Role especifico a uma base de dados. Os roles servem para se associar vrios utilizadores que possuem um mesmo conjunto de acessos base, podendo depois cada utilizador ter extenses (e at restries) ao role em que est inserido. As contas dos utilizadores e as regras em que possam estar inseridas (roles), so especficas de uma base de dados. So os logins e/ou roles, que tem definidos quais as operaes que determinado utilizador (ou grupo de utilizadores) pode efectuar sobre uma base de dados, bem como a que informao que pode ter acesso. No SQL Server, os roles so armazenados como sendo utilizadores especiais. O SQL Server 2005 mantem os logins tal como os conhecemos das verses 7 e 2000, mas com ele surgem dois novos tipos de login. Os novos tipos so: - Logins mapeados a chaves asimtricas; Logins mapeados a certificados digitais. Desde que uma chave assimtrica ou um certificado digital, estejam guardados no SGBD, podem ser utilizados como logins. No muito comum a utilizao destes tipos de login no SQL Server. O SQL Server 2005 introduz tambm uma nova sintaxe para manipular os logins, como o so as instrues, CREATE, DROP, e ALTER LOGIN. Por uma questo de retrocompatibilidade, as stored procedures de sistema existentes nas anteriores verses (7 e 2000) do SGBD so mantidas, contudo no permitiro acesso s novas funcionalidades que os logins possuem. Roles: Por defeito o SQL Server possui um conjunto de roles predefinidos, ao nvel do SGBD e das bases de dados. Os roles que se encontram predefinidos, de uma forma geral servem para funes administrativas comuns quer ao nvel do servidor (fixed server roles) como da bases de dados (fixed database roles). Os roles fixos, permitem de um forma simples e facil atribuir vrias permisses administrativas a utilizadores. Alem dos roles predefinidos e ao nvel das bases de dados, podem criar-se roles medida (user defined database roles).
Autor: Pgina:

Figura 3 (Fixed database roles no SQL Server 7/2000) In SQL Server 7 e 2000 o role de base de dados public est seleccionado por defeito e no poder ser removido. Caso se tente remover aparecer uma mensagem Members cannot be dropped from public. No SQL Server 2005 o role public como obrigatrio j nem aparece. Os restantes roles aparecem todos e mantm-se as suas funes.
Figura 4 (Fixed database roles no SQL Server 2005) Um utilizador pode pertencer a um ou mais roles. A conta guest est definida na base de dados de sistema master. O SQL Server bloqueia qualquer tentativa de remoo inadvertida da conta guest. Caso se removesse a conta guest da master somente a conta sa user teria acesso ao SQL Server. A conta guest permite a que utilizadores no registados em bases de dados tenham acesso master mas como guest. Claro que os direitos deste utilizador so muito reduzidos e podem somente ver os objectos que a base de dados possui. A conta guest membro do role public. Assim para evitar que qualquer utilizador no registado nas bases de dados lhes possa aceder, basta remover a conta guest de todas as bases de dados para alem da master. Se a conta guest no existir, o SQL Server nega o acesso base de dados. Os Fixed Server Roles, so a base dos privilgios administrativos ao nvel do SGBD. So independentes de base de dados e referem-se exclusivamente ao motor. Tabela 1. Tabela 1 Fixed Server Roles Role Dbcreator Diskadmin Funo Utilizadores com autorizao de criao de bases de dados, podendo criar ou altera-los. Utilizadores com privilgios de administradores relativos gesto do file system associado s vrias bases de dados e ao SGBD.
Autor: Pgina:

Fixed Server Roles Role Funo
processadmin Utilizadores com privilgios de administradores de processos do SQL Server. securityadmin Utilizadores com privilgios de administradores de segurana, podendo fazer a gesto e auditarem os acessos. serveradmin setupadmin Sysadmin Bulkadmin Utilizadores com privilgios de administradores do SGBD, podendo alterar as configuraes do servidor de bases de dados. Utilizadores com privilgios para instalarem/actualizarem o SGBD. Utilizadores com privilgios de administradores geral do SGBD, podendo efectuar qualquer tipo de operao. Utilizadores com privilgios de administradores carregamentos massivos de informao (Bulk Insert). das operaes de
Os Fixed Database Roles, so a base dos privilgios administrativos ao nvel da base de dados. So restritivos base de dados em que se encontram definidos. Tabela 2. Tabela 2. Fixed Database Roles Role public db_owner db_accessadmin db_ddladmin db_securityadmin Funo Acesso padro de utilizador a bases de dados. Todos os utilizadores de uma base de dados possuem este role por defeito. Utilizador com privilgios para executar qualquer operao na base de dados. o dono da base de dados. Utilizador com privilgios para adicionar ou remover acessos de, outros utilizadores, grupos e roles na base de dados. Utilizador com privilgios para adicionar, modificar ou eliminar objectos na base de dados. o arquitecto da base de dados. Utilizador com privilgios para atribuir, retirar ou restringir permisses sobre os objectos existentes.
db_backupoperator Utilizador com privilgios para efectuar backups da base de dados. db_datareader db_datawriter Utilizador com privilgios para ler os dados de todas as tabelas existentes na base de dados. Utilizador com privilgios de escrita sobre a base de dados. Pode adicionar, alterar ou remover dados de todas as tabelas.
db_denydatareader Utilizador sem acesso de leitura a qualquer tabela da base de dados. db_denydatawriter Utilizador sem acesso de escrita sobre os dados da base de dados. No pode adicionar alterar ou remover dados.
Os User Defined Database Roles (Application Roles no 2005), devero representar regras de acesso a dados de um determinado grupo de utilizadores dentro de uma dada base de dados. Tem bastantes vantagens, pois podemos fazer uma segregao do acesso aos dados muito mais correcta. Permite que quando seja necessrio implementar uma alterao para um

determinado grupo, se alter no role sendo automaticamente reflectido nos acessos dos utilizadores membros do role. Aps a criao e atribuio de permisses ao role, a aplicao cliente activa o role em runtime para receber as permisses que estejam associadas. Este tipo de roles, simplifica muito o trabalho do DBA. Uma vez criado(s) o(s) role(s) o DBA deixa de ter necessidade que se preocupar em gerir as permisses dos utilizadores de aplicaes, basta adicionar os users ao role. A gesto das permisses para os utilizadores feita ao nvel do role. Notas sobre este tipo de roles: Por defeito no existem nas bases de dados. So especficos base de dados onde esto definidos Em 2005 os Application roles necessitam de ser activados em run-time, pelas aplicaes que lhes esto associadas recorrendo a password. Em 2005 as permisses associadas aos Application roles sobrepem-se sobre as que possam estar associadas aos utilizadores individuais. Em 2005 aps um role ser activado pela aplicao num dada base de dados e caso haja necessidade de interagir com outra base de dados, a segunda base de dados ter que ter a conta guest activa. Lista de stored procedures teis gesto de logins e utilizadores: sp_addlogin, sp_droplogin, sp_grantlogin, sp_password , sp_revokelogin, etc. Lista de stored procedures teis gesto de logins e application roles: sp_addlogin, sp_denylogin, sp_droplogin, sp_grantlogin, etc. sp_addapprole, sp_approlepassword, sp_dropapprole, sp_setapprole, etc.
Esquema 3 Permisses: As permisses permitem que um indivduo possa fazer qualquer interaco ao nvel da base de dados. Existem permisses ao nvel dos objectos e das instrues executadas. As permisses ao nvel dos objectos controlam quem pode aceder e manipular dados nas tabelas e views, bem como quem pode executar procedimentos (stored procedures). Permisses ao nvel das instrues que podem ser executadas, controlam quem pode criar ou eliminar (drop) objectos da base de dados (tabelas, views, procedimentos, etc). Um utilizador s poder executar instrues sobre objectos dentro da base de dados, se tiver as permisses apropriadas. Atribuio (grant) e remoo (revoke) de permisses a utilizadores e roles (fixed e aplication) das bases de dados. Para a gesto das permisses ao nvel do utilizador ou da role comum falar-se de Grant (atribuir), Revoke (remover) e Deny (negar). As gesto das permisses poder ir desde a base de dados at ao nvel da coluna. Acessos ao nvel da linha (row level security) no podem ser atribudos. O Row level security s poder ser simulado recorrendo a views especificas de utilizador.

Grant: - atribui permisses especficas (Select, Execute, etc.) sobre objectos da base de dados, a utilizadores ou roles. Revoke: - remove privilgios anteriormente atribudos. Deny: - nega permisses especficas (Select, Execute, etc.) sobre objectos da base de dados, a utilizadores ou roles. A melhor abordagem passar por deixar certas instrues somente possveis de serem executadas pelo sa (membro do role sysadmin). Na tabela 3 est uma lista de instrues que podero ser atribudas ou removidas aos utilizadores ou roles. Tabela 3 Instruo CREATE DATABASE CREATE DEFAULT CREATE RULE CREATE TABLE CREATE VIEW CREATE PROCEDURE BACKUP DATABASE Funo Cria bases de dados, permitida ao sa ou membros da master Permite criar valores por defeito em colunas ou tabelas Semelhante ao default, mas com regras de preenchimento (rules) Permite cria tabelas Permite criar views Permite criar procedimentos (stored procedures) Permite efectuar backups da base de dados
BACKUP TRANSACTION Permite efectuar backups de transaccionais Validao das permisses: Dentro de cada base de dados, cabe ao responsvel pela segurana atribuir permisses aos vrios logins e aos roles. As permisses iro permitir ou restringir a execuo de aces. Qualquer comando efectuado contra a base de dados por parte de um utilizador, s ser aceite pela base de dados se o referido utilizador estiver logado na base de dados em questo. O SQL Server executa as seguintes etapas ao validar as permisses: 1. Quando o utilizador executa uma aco (ex.: executa uma instruo Transact-SQL como o SELECT), ou escolhe uma qualquer opo dentro de uma aplicao cliente, as instrues geradas so enviadas, ao SQL Server em Transact-SQL. 2. Por cada instruo Transact-SQL recebida, o SQL Server, verifica se o utilizador em questo tem permisso para executar uma instruo. 3. Aps verificar se o utilizador tem permisses, o SQL Server executa uma das duas aces a seguir: i. Se o utilizador no possuir as permisses adequadas, retornado um erro. ii. Se o utilizador possuir as permisses adequadas, a instruo (aco) ser executada. Planear a segurana: O plano de segurana dever ter identificado todos os utilizadores da organizao com acesso aos dados e em cada um deles ter indicao de a que informao que podem aceder. Para elaborar o plano de segurana basta fazer o seguinte: 1. Ter uma lista d os objectos e actividades constantes numa base de dados a segurar. 2. Ter uma lista dos utilizadores devidamente identificados. 3. Identificar grupos de utilizadores idnticos dentro da organizao. 4. Fazer uma lista dos utilizadores e grupos. 5. Cruzar as listas do ponto 1 com ponto 4, identificando que utilizadores/grupos podem aceder a que grupos de informao e que actividades podem ter sobre eles. Boas prticas

Aps terminar a instalao do MS SQL Server, dever-se- alterar a palavra passe da conta sa. Isto porque por defeito a conta sa no tem a password protegida. Os logins so guardados na base de dados master (em master.dbo.syslogins). Dever ser efectuado o backup da master, sempre que um login adicionado. Por vrias razes, sempre que possvel deve utilizar-se windows authentication (ver seco). Caso tenha que se utilizar o mixed mode, ter que se ter o cuidado de verificar o grau de complexidade das passwords, incluindo a prpria sa. As passwords devero ser um misto de maisculas, minsculas, caracteres especiais e nmeros. Evitar ter ficheiros guardados com as passwords de acesso aos SGBDs. Caso haja necessidade de ter esta informao em ficheiro, devero cifrar o ficheiro. Dar o role sysadmin ao menor n possvel de pessoas. Definir bem quem administra o qu. Criar um par de contas Windows para correr os servios SQL. Uma conta para correr o servio relativo ao motor e outra para o agente. Sempre que possvel, as contas ou grupos existentes por defeito, Domain Administrator, Network Service account, etc, devero ter os seus acessos e privilgios removidos da administrao do SQL Server. Isto porque qualquer processo estranho ao SQL Server que esteja a correr com uma destas contas, ganha automaticamente privilgios de administrao. Desactivar a conta guest do Windows e remove-la das bases de dados de produo. Interligao entre os Recursos Humanos e a gesto de bases de dados, permitindo assim a pronta remoo de utilizadores que deixem a empresa. Evitar deixar o servidor visvel na rede. Evitar ter servidores SQL acessveis directamente pela Internet. Caso seja mesmo necessrio garantir que ficam atrs de firewalls e que esto devidamente seguros. No caso de se ter uma autenticao mista, devero alterar a stored procedure de sistema sp_password, para que esta possa verificar se a password inserida ou no forte. No permitir que aplicaes acedam directamente aos dados. O acesso poder ser feito recorrendo a stored procedures, dando acesso de execute sobre os mesmos aos utilizadores ou roles da aplicao. Desta forma conseguimos que a estrutura interna da base de dados no seja conhecida dos utilizadores. Se tivermos que dar permisses de select ento que sejam sobre views. Negar a permisso de execuo a algumas stored procedures de sistema, aos utilizadores e aos roles que no sejam membros do sysadmin. Algumas das stored porcedures seriam xp_cmdshell (permite execuo de instrues ao nvel do SO) e todas as sp_OA* (permite lanar processos que sejam inprocess ao SQL). Restringir o acesso fsico ao servidor SQL. Fechar a consola do servidor sempre que no esteja a ser utilizada. Nos linked servers sempre que possvel utilizar delegation nas contas de acesso entre os servidores. Desta forma conseguimos sempre saber quem que relamente est a fazer
Autor: Pgina:

determinada aco. Quando se mapeia os acessos dos utilizadores entre linked servers o servidor final s ir conhecer a conta utilizada para mapear o acesso. Activar o audit de login no SQL Server level e no SO. Examinar com frequncia o resultado do audit, para os logins falhados para tentar detectar possveis tentativas de intruso. Para determinar as permisses totais de um utilizador Windows a um dado objecto: 1. Descobrir qual o grupo Windows do utilizador 2. Descobrir quais so os roles de que esse utilizador e/ou o seu grupo sejam membros 3. Fazer queryies tabela syspermissions para detectar as permisses adicionais. Estar sempre actualizado em relao a service packs e patches de segurana. Instalar os service packs e patches finais medida que forem saindo. Consultar com frequncia os sites: http://www.microsoft.com/security/ http://www.microsoft.com/technet/prodtechnol/sql/2000/downloads/default.mspx http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/default.mspx A segurana tem que ser parte integrante do processo de desenho da base de dados ou da definio do SGBD. No se deve esperar que esteja tudo implementado e a funcionar, para depois se pensar na segurana. Ferramentas teis Todas as fornecidas pela Microsft Log Explorer Lumigent (www.lumigent.com) Excelente em caso de recuperao de dados aps catstrofes. SQLDiff Bom para migraes de ambientes permite fazer comparaes de tudo. SQLPrompt um gadget til para quem faz muitos scripts Etc Scripts teis Script utilizado para extrair os logins com as respectivas passwords encriptadas de um SGBD. Script que lista todos as bases de dados seus roles e utilizadores membros, num SGBD.
Autor: Pgina:

SQL Seguranca Art Rumos

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SQL Seguranca Art Rumos

Hochgeladen von

Copyright:

Verfügbare Formate

Segurana do Microsoft SQL Server

Base MS SQL 2000+SP3 com referncias s verses 7 e 2005

Segurana do Microsoft SQL Server

Nome Doc.: Ult. Actualizao:

Paulo Gonalves Pal_soft@hotmail.com 1/10

Segurana do Microsoft SQL Server

Nome Doc.: Ult. Actualizao:

Paulo Gonalves Pal_soft@hotmail.com 2/10

Segurana do Microsoft SQL Server

Figura 1 (MS SQL Server 7/2000)

Segurana do Microsoft SQL Server

Nome Doc.: Ult. Actualizao:

Paulo Gonalves Pal_soft@hotmail.com 4/10

Segurana do Microsoft SQL Server

Nome Doc.: Ult. Actualizao:

Paulo Gonalves Pal_soft@hotmail.com 5/10

Segurana do Microsoft SQL Server

Fixed Server Roles Role Funo

Segurana do Microsoft SQL Server

Segurana do Microsoft SQL Server

Segurana do Microsoft SQL Server

Nome Doc.: Ult. Actualizao:

Paulo Gonalves Pal_soft@hotmail.com 9/10

Segurana do Microsoft SQL Server

Nome Doc.: Ult. Actualizao:

Paulo Gonalves Pal_soft@hotmail.com 10/10

Das könnte Ihnen auch gefallen