A segurança do servidor depende principalmente de quão corretamente você pode configurar as permissões de acesso nos objetos. Fornecer permissões excessivas a um usuário pode causar muitos problemas. Não, um usuário não usará seus erros. Em vez disso, qualquer hacker ou eu faremos isso. Nesse caso, você pode esquecer suas tabelas com dados ou todo o banco de dados.
Por alguma razão, a segurança do banco de dados é a proteção externa, como um hacker. No entanto, isso acontece muito raramente. Sou programador em uma grande empresa e um administrador nem pensa em proteger as portas do servidor, onde tudo está aberto. Há um monte de bancos de dados, programas e até mesmo um servidor FTP em um único servidor e nunca foi hackeado nos últimos 5 anos. Felizmente, convenci o administrador a implantar o servidor WEB em um hardware separado. Caso contrário, se alguém souber o endereço IP do nosso servidor principal, qualquer preguiçoso poderá hackeá-lo. Nem o banco de dados nem o Windows foram corrigidos por vários anos.
No entanto, problemas internos surgem todos os dias devido a uma política de segurança incorreta. Todos os usuários fazem login com direitos de administrador e podem criar o que quiserem. Este é um problema real porque as permissões excessivas permitem que os preguiçosos mostrem seu completo analfabetismo. Portanto, consideraremos a segurança independentemente de onde a ameaça venha – de um hacker ou de um usuário.
Neste artigo, consideraremos todos os fundamentos necessários de proteção de segurança contra hackers e usuários. Escolhi o MS SQL Server como exemplo porque contém tudo o que está disponível em outros bancos de dados (Oracle, MySQL, etc.) e possui recursos adicionais de gerenciamento de segurança. Alguém pode pensar que isso torna a MS mais íngreme. No entanto, às vezes, recursos adicionais podem ser excessivos, causando problemas.
Funções de servidor
No Windows e em outros sistemas operacionais, existem grupos e usuários para gerenciar permissões. Podemos combinar usuários em um grupo e conceder direitos a todos eles de uma vez, o que é muito mais fácil do que atribuir direitos a cada usuário individualmente. Para esses fins, em bancos de dados, existe o conceito “papel”.
Suponha que 100 usuários tenham permissões para ler dados de uma tabela específica. Fornecer a cada usuário essa permissão é um incômodo. É muito mais simples criar uma função que tenha permissão de leitura e, em seguida, adicionar todos os usuários necessários a ela. O resultado é semelhante ao agrupamento.
No SQL Server, existem dois tipos de funções:servidor e banco de dados. As funções de servidor são predefinidas e não podem ser alteradas.
Abra a ramificação de função de Servidor/Segurança no Enterprise Manager para que você possa ver uma lista de funções disponíveis na parte direita da janela. A descrição define o que o usuário pode fazer com a função correspondente.
Funções de servidor no MS SQL Server e na janela do gerenciador de funções
Para adicionar um usuário existente a uma função, clique duas vezes na linha da função. Na janela exibida, você pode adicionar usuários à função ou excluí-los. A guia Permissão descreve em detalhes o que cada usuário pode fazer.
Usuários
Para gerenciar usuários, abra a ramificação Segurança/Logins no Enterprise Manager. Na parte direita, você verá uma lista de todos os usuários do servidor. Por padrão, o acesso é concedido a administradores de domínio e contas de login internas, como sa.
Para adicionar um novo usuário, clique com o botão direito do mouse em qualquer lugar vazio na parte direita da janela e selecione Novo login no menu que aparece. No topo da janela, selecione um nome de usuário. Se você precisar escolher um domínio ou usuário de computador existente, clique no botão (…) à direita do campo de entrada e você verá a caixa de pesquisa de usuário no domínio.
Adicionar um novo usuário
Abaixo, você pode selecionar o tipo de autenticação – Windows ou SQL Server. Se você selecionar Windows, não precisará especificar uma senha porque o servidor a buscará no sistema. No entanto, você pode alternar entre Conceder acesso (permitir acesso) ou Negar acesso (proibir). Neste último caso, o usuário será cadastrado no banco de dados, mas não poderá se conectar – é proibido.
Se você selecionar a autenticação do SQL Server, precisará definir uma senha, pois nesse caso ela será armazenada nas tabelas de sistema do servidor de banco de dados. Observe que, mesmo que apenas a autenticação do Windows seja especificada nas configurações do servidor, você pode criar registros do servidor SQL, mas não poderá fazer login no sistema com esses registros.
Na guia Funções de Servidor, você pode especificar qual função de servidor será concedida a um usuário. Portanto, mesmo no estágio de criação, você pode adicionar usuários às funções necessárias.
Acesso do usuário aos bancos de dados
Na guia Acesso ao Banco de Dados, especifique os bancos de dados com os quais o usuário pode trabalhar. Aqui, a janela é dividida em duas partes:na metade superior, você pode selecionar o banco de dados ao qual o acesso é permitido e, na lista inferior, você pode selecionar a função do banco de dados. Essa função no banco de dados definirá as permissões do usuário. Várias funções podem ser concedidas a um usuário.
Crie uma conta qq, que terá acesso ao banco de dados Northwind. Este é um banco de dados de teste padrão criado ao implantar o servidor.
Salve as alterações.
Agora, abra a ramificação Databases/Northwind/Users e veja a lista de usuários que têm permissão para acessar o banco de dados selecionado. Observe que há a conta qq aqui. Não há conta em outros bancos de dados porque o acesso a eles para nosso novo usuário é proibido.
Funções do banco de dados
Cada banco de dados pode ter seus próprios papéis, que definem as permissões de acesso aos objetos. Muitos administradores não gostam de se preocupar com essas permissões. Assim, eles instalam o público padrão embutido, que permite quase tudo. Se houver falta de permissões para a função pública, basta adicionar um usuário à função de servidor Administrador do Sistema. Nesse caso, o banco de dados fica vulnerável.
Cada usuário deve receber suas próprias e necessárias permissões. O que não é permitido deve ser proibido. As funções que já existem no servidor não devem ser usadas porque suas permissões estão abertas a todos. Recomenda-se até mesmo excluí-los todos, especialmente o público.
Criando uma função
Para criar uma nova função de banco de dados, clique com o botão direito do mouse na ramificação Bancos de Dados/Nome do Banco de Dados/Funções. No menu exibido, selecione Nova função de banco de dados. A janela Propriedades da Função de Banco de Dados – Nova Função é aberta. Na parte superior da janela, digite o nome da função.
Por exemplo, queremos criar uma função para contadores. Para fazer isso, digite Buh no campo Nome.
Criando uma função de banco de dados
Abaixo, selecione um tipo de função, por exemplo, um padrão padrão. No centro da janela, há uma lista de usuários que serão adicionados à função. Até agora, a lista está vazia. No entanto, se clicarmos em Adicionar, adicionaremos usuários, por exemplo, à conta qq criada anteriormente. Não há mais nada a ser feito na fase de criação de um papel. Salve as alterações clicando em OK.
Permissões de acesso
Agora, vamos ver como podemos definir permissões. Clique duas vezes na função Buh criada para abrir a janela para edição. Observe que o botão Permissão está disponível agora. Somente quando a função estiver cadastrada no banco de dados, poderemos alterar seus direitos. Clique neste botão para abrir a janela Propriedades da Função de Banco de Dados.
Definindo permissões de acesso para funções
Na parte superior da janela, há uma lista de funções de banco de dados para que você possa alternar rapidamente entre elas. Agora, a função Buh está selecionada. No centro da janela, há uma grande grade com as seguintes colunas:
- Objeto – nomes de objetos;
- Proprietário – um proprietário de um objeto;
- SELECT – permissão para visualizar dados ou executar a instrução SELECT. Está disponível apenas para tabelas e visualizações;
- INSERT – permissão para adicionar dados ou executar a instrução INSERT. Está disponível apenas para tabelas e visualizações;
- UPDATE – permissão para modificar dados ou executar a instrução UPDATE. Está disponível apenas para tabelas e visualizações;
- Permissão DELETE para excluir dados ou executar a instrução DELETE. Está disponível apenas para tabelas e visualizações;
- EXEC – permissão para executar procedimentos e funções armazenados. Está disponível apenas para procedimentos e funções armazenados;
- DRI (integridade referencial declarativa). Está disponível apenas para tabelas, visualizações e funções.
Não há permissões para a nova função. Para poder visualizar uma tabela, por exemplo, Categorias, marque a caixa na interseção da linha Categorias e a coluna SELECT. Você verá uma marca verde na caixa, o que significa uma permissão. O segundo clique muda o visto para a cruz vermelha e significa proibição. Isso pode ser necessário se você conceder uma permissão ao usuário e adicioná-lo a outra função, onde o acesso à ação selecionada é permitido. O terceiro clique remove quaisquer permissões na ação e deixa a caixa vazia. Isso significa que não há acesso; no entanto, ele pode ser delegado se o usuário for adicionado a outra função com as permissões no objeto ou as permissões forem especificadas explicitamente.
Se você selecionar uma linha com o objeto da tabela ou visualização, o botão Colunas ficará disponível na parte inferior da janela. Suponha que você selecionou a tabela e clicou neste botão. A janela é aberta, na qual você pode definir permissões para colunas de tabela individuais.
Definindo permissões de coluna
Esta é realmente uma grande possibilidade, pois algumas colunas responsáveis pela integridade do banco de dados não devem ser alteradas por usuários ou hackers. É melhor proibir as operações UPDATE ou SELECT (se possível) para essas colunas.
Individualismo
As funções são convenientes de usar quando é necessário combinar usuários semelhantes. Por exemplo, vários contadores precisam ter acesso a tabelas financeiras. Conceder permissões a cada contador é demorado. É muito mais fácil criar uma função para o contador, conceder permissões a ele e adicionar todas as contas contábeis a essa função.
No entanto, há casos em que as permissões devem ser exclusivas para um usuário ou, além das permissões concedidas pela função, é necessário conceder permissões adicionais. Por exemplo, um dos contadores precisa ter acesso às tabelas do departamento de recursos humanos. Nesse caso, é melhor adicionar permissões diretamente ao contador em vez de criar uma nova função.
Exploramos os papéis primeiro para nos acostumarmos com eles. Na maioria dos casos, há uma conta separada para contadores, uma conta separada para economistas etc. Nesse caso, a maioria das pessoas se conecta ao servidor usando uma conta. Assim, controlar quem faz o que é impossível. É melhor usar permissões individuais quando necessário, enquanto cada usuário deve ter sua própria conta.
Permissões em tabelas
Vamos ver como podemos conceder permissões em objetos específicos, por exemplo, em tabelas.
Selecione a ramificação Databases/Northwind/Tables na árvore de objetos. Na parte direita, uma lista de todas as tabelas é aberta. Clique com o botão direito do mouse em qualquer tabela e selecione Todas as tarefas/Gerenciar permissões. A janela Propriedades de Permissão é aberta, que é semelhante à janela Propriedades da Função de Banco de Dados com a lista de usuários em vez da lista de objetos. O objeto é uma tabela em que clicamos e seu nome será listado no menu suspenso da janela. Agora, precisamos definir permissões neste objeto para diferentes usuários.
Definindo permissões em uma tabela
A lista de permissões é a seguinte:visualizar, atualizar, adicionar, excluir, executar e gerenciar. Se você clicar no botão Colunas, a janela será aberta para definir permissões no objeto no nível dos campos da tabela para um usuário específico.
Visualizações
Temos duas mesas. Uma delas armazena a lista de funcionários, enquanto outra tabela contém informações sobre o número de horas trabalhadas por mês e os salários recebidos (salários oficiais e ocultos).
Suponha que um funcionário do fisco venha até você e peça para mostrar os salários dos trabalhadores. Além disso, eles perguntam se você pagou todos os impostos. Quais ações você precisa realizar do seu lado?
A primeira proposta veio da terceira linha – criar um novo usuário que tenha permissão para ler tabelas, incluindo uma lista de funcionários e salários. Além disso, você não deve esquecer de fechar a coluna com o salário oculto. Na verdade, a solução está correta, mas absolutamente ineficaz.
A melhor opção é criar uma view, uma consulta SQL que seleciona dados. No banco de dados, parece uma tabela. Você pode selecionar dados SQL usando consultas e conceder permissões. Acontece que a consulta será executada em relação à consulta.
Para criar uma visualização, execute a seguinte consulta:
CREATE VIEW salary AS SELECT fields for a tax official FROM Employees, Wages WHERE joins
Agora, há um novo objeto Wage na ramificação Databases/Northwind/Views. Se você clicar com o botão direito do mouse e selecionar Todas as tarefas/Gerenciar permissões, a janela para concessão de permissões será aberta. Defina uma permissão para o fiscal e salve-a. Para revisar o conteúdo da visualização, execute a consulta:
SELECT * FROM salary
Como você pode ver, há um acesso a uma tabela simples. O funcionário fiscal também pensará que vê dados reais. No entanto, na verdade, essa consulta conterá apenas os dados de que precisamos.
Na vida real, o fiscal não pode ser enganado tão facilmente porque eles não são tolos. No entanto, este exemplo mostra que a exibição pode ser um método de segurança perfeito. Podemos exibir os dados que os usuários precisam e nada mais. Ao mesmo tempo, temos todas as ferramentas para gerenciar permissões na view sem afetar as permissões de acesso nas tabelas.
Assim, diferentes visualizações para as mesmas tabelas podem mostrar dados diferentes. Se você quiser mostrar uma coluna adicional, adicione as visualizações à consulta. Nesse caso, não há necessidade de alterar as permissões.
Visualizações do sistema
Em cada banco de dados, pode haver visualizações do sistema criadas pelo servidor automaticamente. Eu não recomendo conceder permissão a eles porque eles podem mostrar algumas informações adicionais, que podem ajudar um hacker a definir permissões ou simplesmente destruir dados. As visualizações do sistema começam com o prefixo sys e System é especificado na coluna Type da lista.
Procedimentos e funções
Servidores de banco de dados modernos oferecem suporte a procedimentos e funções armazenados. Este é um código PL/SQL ou Transact-SQL dependendo do banco de dados que é executado no servidor de banco de dados. Usando esses procedimentos, podemos realizar qualquer operação no servidor ou simplesmente selecionar dados, como na view. Podemos definir permissões em cada procedimento.
Ao revisar os papéis, já vimos os procedimentos na lista de objetos nos quais você pode definir permissões e apenas a coluna EXEC está disponível nessas linhas porque os procedimentos só podem ser executados.
Os procedimentos e funções armazenados são armazenados em um banco de dados específico. Para ver os procedimentos do banco de dados Northwind, selecione a ramificação Databases/Northwind/Stored Procedures. Existem muitos procedimentos do sistema, cujos nomes começam com o prefixo dt_ e System é especificado na coluna Type. Recomenda-se não conceder acesso a esses procedimentos, se possível. Você pode ver funções na ramificação de funções definidas pelo usuário/Bancos de dados/Northwind.
Para alterar as permissões em procedimentos e funções, clique com o botão direito do mouse em seu nome e selecione Todas as tarefas/Gerenciar permissões no menu. Na janela que aparece, você pode alterar apenas a coluna EXEC para procedimentos e as colunas EXEC e DRI para funções.
Política de permissão
Alguns administradores definem permissões com base na função existente, por exemplo, pública. Isso não é verdade porque, nessa função, pode haver permissões que os usuários não precisam. Assim, tente definir uma nova permissão.
Quanto a mim, sempre crio uma nova função e concedo um conjunto mínimo de permissões. Se os usuários solicitarem mais permissões e elas forem realmente necessárias, eu adiciono mais permissões. Se você permitir tudo por padrão, não há garantia de que no futuro direitos desnecessários e perigosos serão excluídos.
Outro problema para definir menos permissões é um hábito. Os usuários podem se acostumar com o fato de que muitas permissões são concedidas a eles e a proibição causará um grave escândalo. Ninguém gosta quando seus direitos são violados.
Tabelas/bancos de dados
Os bancos de dados armazenam suas configurações e propriedades ocultas em tabelas e bancos de dados do sistema. Eles não diferem de outros objetos de banco de dados e as permissões podem ser definidas neles. Em nenhum caso, não permita que os usuários acessem essas tabelas sem uma necessidade especial.
No SQL Server, os dados importantes do sistema são armazenados nos bancos de dados master e msdb. Assim, esses bancos de dados devem ser protegidos. No Oracle, cada banco de dados existe como um objeto separado e as tabelas do sistema são armazenadas junto com as dos usuários.
Quase todos os servidores de banco de dados oferecem a instalação de bancos de dados de teste que podem ser usados para aprender ou testar o sistema. Se você os tiver, exclua - porque um acesso público está definido para esses bancos de dados. Se um hacker souber nomes ou propriedades de qualquer objeto existente no sistema, isso simplificará muito sua tarefa.
Ao se conectar a um banco de dados de teste, você pode executar alguns comandos no servidor e danificar o sistema operacional ou um banco de dados em funcionamento. Nenhum material adicional deve estar no sistema. Além disso, essas tabelas/bancos de dados têm permissões bastante altas, mesmo para um convidado.
Resumo
Apesar de termos usado o MS SQL Server como exemplo, os conceitos de permissões, funções e autenticação existem em todos os bancos de dados.
Conhecendo todas as regras que consideramos, a única coisa que você precisa é explorar a peculiaridade de seu uso em seu banco de dados.
