Policy Based Management PBM Targets Facets - PDF
Policy Based Management PBM Targets Facets
Download "Policy Based Management PBM Targets Facets"
Igor Bennert Branco
1 SEGURANÇA GESTÃO DE POLÍTICAS Uma das opções que surgiram no SQL Server 2008, bastante apreciada pelos DBA, é o Policy Based Management (PBM). Inicialmente denominado Declarative Management Framework, é um sistema de gestão baseado em políticas, muito idêntico ao sistema de políticas de grupo do Windows. O PBM permite ao DBA criar políticas de SQL Server e, posteriormente, implementá las e distribuí las por vários servidores. As políticas podem ser agendadas para correr periodicamente ou a pedido. Além disso, a política pode simplesmente registar a sua violação ou, de forma pró ativa, evitar a concretização de uma ação, fazendo o roll back da transação e assinalando um erro. Vejamos um exemplo da utilização do PBM: uma empresa do ramo da Distribuição tem uma sede com um sistema central e trinta delegações, cada uma com o seu servidor a correr o SQL Server e a replicar os seus dados para o servidor da sede. O DBA necessita de realizar uma alteração para que todos os servidores do grupo obedeçam a uma determinada configuração. Até ao SQL Server 2005, a única hipótese seria entrar em cada servidor e fazer a verificação manualmente ou através de um script. Com o PBM, podemos garantir essa configuração em todos os servidores. Outro exemplo ainda: a mesma companhia estabeleceu que nenhum servidor pode ter a correr o SQL Mail muito facilmente se pode criar uma política que assegure o cumprimento dessa restrição. As políticas são facilmente exportáveis para outros servidores num ambiente multisservidor. No entanto, o PBM é restrito ao motor de base de dados, não estendendo a sua influência a outros componentes, como, por exemplo, o Analysis Services ou o Reporting Services. A ferramenta usada para trabalhar com o PBM é o SSMS, através do qual é possível criar políticas que previnam alterações violadoras das suas normas, fazer o alerta e o subsequente registo de violação de normas. No entanto, antes de vermos como se criam as políticas, existem alguns conceitos que temos de compreender: Targets (objetos) São entidades sobre as quais se aplicam as políticas. Essas entidades podem ser servidores, bases de dados, tabelas, logins ou qualquer outro objeto ao qual se possa aplicar uma política; Facets (facetas) É um conjunto de propriedades lógicas que caracterizam o comportamento de certos tipos de targets. As facetas estão predefinidas no SQL Server e expõem condições que podem ser testadas dentro de uma política. O número e as características das propriedades que existem numa faceta só podem ser alterados por quem a criou. Um tipo de target pode implementar uma ou mais facetas e uma faceta pode ser implementada por
2 230 SQL SERVER 2014 CURSO COMPLETO um ou mais tipos de targets. Algumas facetas só podem ser implementadas em versões específicas do SQL Server; por exemplo, a propriedade Database Mail da faceta Surface Area Configuration só pode ser aplicada às versões 2005 e Como exemplo de uma faceta, temos Login, que apresenta condições para testar se um login está bloqueado, qual a base de dados predefinida, qual a última alteração da palavra passe, etc.; Para uma lista completa de todas as facetas e suas propriedades consulte SQL Server 2014 Books Online. Conditions (condições) São expressões booleanas e atestam o estado de uma faceta. Uma condição testa um atributo para se assegurar de que cumpre um critério predefinido; Policies (políticas) Uma política define uma ou mais condições a serem aplicadas a um servidor. Os DBA definem políticas de modo a assegurar que certas condições são cumpridas. Agora que já definimos o que é uma política e quais são os seus aspetos fundamentais, vejamos um exemplo de criação de uma política. Existem duas possibilidades para criar as condições que iremos usar nas políticas: através da opção Conditions no nó Management do Object Explorer ou aquando da criação de uma política. Neste exemplo vamos recorrer à segunda possibilidade: 1) No Object Explorer, expandir os nós Management e Policy Management, clicar com o botão direito do rato em Policies e selecionar New policy (Figura 7.18). FIGURA 7.18 Nova política 2) Surge uma janela na qual vamos ter de preencher vários critérios, dois deles assinalados como obrigatórios: o nome e a condição. 3) No campo Name, escrever NomedeTabelas ; de seguida, clicar na combo box do campo Check condition e selecionar New Condition (Figura 7.19).
3 SEGURANÇA 231 FIGURA 7.19 Nova política: escolha/criação de condições Como já foi referido, podemos criar uma nova condição nesta altura ou através da opção Conditions do nó Management do Object Explorer. No caso de a condição já existir, deveríamos selecioná la na lista de condições existentes. 4) Ao selecionar a opção de criar uma nova condição (New condition ), surge a janela Create New Condition (Figura 7.20). FIGURA 7.20 Nova condição
4 232 SQL SERVER 2014 CURSO COMPLETO 5) Temos, então, de introduzir o nome da condição que no nosso exemplo será CondicaoNomeTabelas e, de seguida, escolher o tipo de faceta que queremos usar; para isso, clicamos na combo box respetiva e, na janela de seleção, escolhemos Multipart Name. 6) Na janela Expression, vamos escolher a expressão que vai reger a nossa condição (Figura 7.21). Assim: Na primeira linha, no campo Field, selecionamos LIKE no campo Operator e escrevemos tbl% em Value; Na segunda linha, escolhemos AND no campo AndOr, no campo Field e escrevemos programador em Value; Na terceira linha, escolhemos OR no campo AndOr, no campo Field e escrevemos teste em Value. FIGURA 7.21 Construir a expressão através da grelha de expressões 7) É também possível criar grupos de expressões. No nosso exemplo temos de agrupar ambos os dado que a lógica estaria incorreta se não o fizéssemos. Para efetuar esse agrupamento: selecionar as duas últimas linhas, clicar com o botão direito do rato sobre as linhas selecionadas e, no menu, escolher Group Clauses (Figura 7.22). FIGURA 7.22 Agrupar as cláusulas da expressão 8) Após estar tudo preenchido, premimos o botão OK, o que nos levará novamente à janela Create New Policy (Figura 7.23). 9) No campo Against targets temos todos os possíveis targets associados à faceta escolhida aquando da criação da condição no nosso caso Multipart Name. Como neste exemplo só queremos controlar o nome das tabelas, vamos selecionar Table na check box respetiva (Figura 7.24).
5 SEGURANÇA 233 FIGURA 7.23 Criação de política FIGURA 7.24 Seleção do target 10) Como queremos aplicar a política a uma só base de dados, vamos abrir a combo box correspondente a in Every e selecionar New condition, o que fará abrir novamente a janela correspondente à nova condição. Aqui vamos definir a condição de seleção da base de dados à qual queremos atribuir a política (Figura 7.25). Assim: no campo Field, selecionamos = no campo Operator e escrevemos Vendas em Value; no final, premimos OK. 11) Voltando à janela de criação de políticas, na seleção do target vamos ter um resultado como o da Figura 7.26.
6 234 SQL SERVER 2014 CURSO COMPLETO FIGURA 7.25 Seleção da base de dados FIGURA 7.26 Política com targets definidos 12) Agora falta nos definir quando é que a política será aplicada. No campo Evaluation Mode temos quatro opções: On demand A política é aplicada apenas quando tal é solicitado pelo DBA. Esta é a opção predefinida; On change: prevent As alterações serão canceladas caso não estejam em conformidade com a política;
7 SEGURANÇA 235 On change: log only Caso haja violação da política, será criada uma entrada no registo. Assim, o processo continuará sem indicação de erro, sendo, no entanto, criada a entrada nas tabelas de histórico da base de dados msdb. Esse registo pode ser consultado no histórico de políticas no menu de contexto das políticas; On schedule A política será verificada periodicamente e será criado um registo por cada violação da política. 13) No nosso exemplo vamos escolher On change: prevent para bloquear qualquer tentativa de violação da política. Por predefinição, esta política corre em qualquer servidor em que seja aplicada; no caso de querermos aplicá la a um servidor específico, podemos criar uma condição de seleção em Server restriction. 14) Não esquecer de selecionar a check box Enabled (ver Figura 7.26), que está inativa se a opção selecionada no campo Evaluation Mode for On demand. 15) Para finalizar a criação das políticas, selecionamos a página Description (Figura 7.27). Aqui podemos acrescentar informação que queiramos mostrar caso haja violação da política. É também possível acrescentar um link como parte da política de erros, link esse que será mostrado juntamente com a mensagem e que poderá encaminhar o utilizador para um documento explicativo de procedimentos, ou algo do género. FIGURA 7.27 Descrição da política e texto de aviso
8 236 SQL SERVER 2014 CURSO COMPLETO Após a criação das políticas, há que testar o seu funcionamento; para isso, corremos o seguinte código: use Vendas GO CREATE TABLE encomendas (Enc_no INT NOT NULL, Data_enc DATETIME2 NOT NULL, Artigo_enc VARCHAR(50) NOT NULL, Qtd_enc FLOAT NOT NULL, Valor_enc DECIMAL(2) NULL) GO Após a execução do código devemos obter o seguinte resultado: Policy 'NomedeTabelas' has been violated by 'SQLSERVER:\SQL\SERVIDOR\ Databases\Vendas\Tables\dbo.encomendas'. This transaction will be rolled back. Policy condition: LIKE 'tbl%' AND = 'programador' = 'teste')' Policy description: '' Additional help: ' Violou a politica de criação de nomes de tabelas - prefixo tbl obrigatório' : '' Statement: 'CREATE TABLE encomendas (Enc_no INT NOT NULL, Data_enc DATETIME2 NOT NULL, Artigo_enc VARCHAR(50) NOT NULL, Qtd_enc FLOAT NOT NULL, Valor_enc...'. Msg 3609, Level 16, State 1, Procedure sp_syspolicy_dispatch_event, Line 65 The transaction ended in the trigger. The batch has been aborted. 7.6 ENCRIPTAÇÃO DE BASES DE DADOS A segurança ao nível do servidor é, normalmente, da responsabilidade de um administrador de sistemas; no entanto, uma base de dados é, por norma, um dos produtos mais importantes que uma empresa possui. Habitualmente, o DBA deixa os problemas de segurança de dados para o administrador do sistema, que tem de se preocupar com as firewalls, o antivírus, etc. Contudo, o SQL Server oferece ao DBA uma proteção suplementar da base de dados: a sua encriptação. Mas porquê encriptar a base de dados se o sistema estiver bem protegido? A resposta é simples: defesa em profundidade. A defesa em profundidade é um conceito que foi desenvolvido pela Agência Nacional de Segurança dos Estados Unidos (conhecida pela sigla NSA) e que consiste em proteger um sistema contra quaisquer ataques através de métodos variáveis. É, no fundo, uma tática de defesa por camadas, em que o atacante sempre que consegue ultrapassar
9 SEGURANÇA 237 uma camada vai encontrar uma outra que o fará demorar mais tempo até conseguir atingir o objetivo, permitindo assim ao defensor ganhar tempo para evitar o ataque. Sabemos que é possível evitar ataques a uma base de dados, mas o que acontece se, por exemplo, alguém conseguir deitar a mão a um suporte de cópia de segurança, uma tape? É simples restaurar a base de dados e aceder aos dados. O SQL Server oferece nos uma solução: a encriptação da base de dados através de chaves e a proteção dessas chaves através de um certificado digital. O SQL Server oferece nos dois níveis de encriptação: ao nível de base de dados e ao nível de coluna. Ambos têm em comum o facto de usarem a hierarquia de chave criptográfica, que analisaremos de seguida HIERARQUIA DE CHAVE CRIPTOGRÁFICA No topo da hierarquia vamos encontrar a API Windows Data Protection (Windows DPAPI), que protege a hierarquia da chave ao nível do sistema operativo, e também a Service Master Key (SMK) para a instância do SQL Server. A SMK protege igualmente a Database Master Key (DMK), que está armazenada ao nível do utilizador da base de dados e que protege os certificados e as chaves assimétricas. Estas, por sua vez, protegem as chaves simétricas, que têm à sua responsabilidade os dados do utilizador (Figura 7.28). FIGURA 7.28 Hierarquia de chave criptográfica (adaptado de: Microsoft MSDN; legenda: Pwd = password [palavra passe])
10 238 SQL SERVER 2014 CURSO COMPLETO Esta hierarquia permite ao servidor abrir as chaves e desencriptar os dados, com encriptação ao nível tanto de base de dados, como de coluna. A diferença principal é que, no caso de usarmos encriptação ao nível de coluna, todas as chaves situadas abaixo do DMK podem ser protegidas por palavra passe, em vez por outra chave. Isto quebra a cadeia de encriptação e obriga o utilizador a introduzir uma palavra passe. Numa encriptação ao nível de base de dados (Transparent Data Encryption TDE) toda a cadeia tem de ser mantida para que o servidor possa, automaticamente, fornecer o acesso aos dados SERVICE MASTER KEY A Service Master Key (SMK) é a chave principal que regula tudo, isto é, todas as chaves e certificados do SQL Server. É uma chave simétrica criada automaticamente durante a instalação do programa. Caso esta chave esteja comprometida, toda a segurança do SQL Server ficará igualmente em risco. É de extrema importância executar uma cópia de segurança da SMK para, no caso de se corromper por qualquer razão, ser possível repô la. A operação de backup da SMK é feita através da seguinte instrução: BACKUP SERVICE MASTER KEY TO FILE = 'C:\BACKUPS\SMK_BACKUP.DAT' ENCRYPTION BY PASSWORD = 'a4xz9$lj=5hd%'; No nosso exemplo, a SMK é copiada para o ficheiro SMK_BACKUP.DAT, armazenado na pasta C:\BACKUPS, e encriptada pela chave indicada. A chave de encriptação é necessária se precisarmos de restaurar a SMK. Na eventualidade de necessitarmos de restaurar ou regenerar a SMK, o SQL Server vai tentar desencriptar e encriptar todas as chaves da hierarquia de chave criptográfica. Se uma dessas operações falhar, todo o processo estará condenado ao fracasso. Ainda assim, para aceder aos dados podemos usar a instrução ALTER SERVICE MASTER KEY, com a opção FORCE; no entanto, esta opção vai provocar a perda de dados. A sintaxe de ALTER MASTER KEY é a seguinte: ALTER SERVICE MASTER KEY [ { <opção_regenerar> <opção_recover> } ] [ { ADD DROP } ENCRYPTION BY MACHINE KEY ] < opção_regenerar > ::= [ FORCE ] REGENERATE < opção_recover > ::= { WITH OLD_ACCOUNT = 'conta_windows', OLD_PASSWORD = 'palavra_passe' } { WITH NEW_ACCOUNT = 'conta_windows', NEW_PASSWORD = 'palavra_passe' }