Segurança do banco de dados

Question

Quais aspectos devem ser considerados para se ter um banco de dados seguro?

Além de evitar sqlInjection , o que mais deve ser considerado? O que deve não ser feito?

    

Answer 1

Desligue e limpe os discos .... várias vezes. Um pouco menos extremo é

Primeiramente, proteja o servidor, o armazenamento, a rede e o nível do sistema operacional

1. O servidor de banco de dados deve ter portas abertas mínimas (por exemplo, apenas SSH na porta 22 e o ouvinte em 1521). Também cuidado com as conexões de saída. O banco de dados pode fazer solicitações HTTP, enviar e-mails e todo tipo de coisa ... o que você provavelmente não quer em um ambiente seguro.
2. Ninguém deve ter acesso ao servidor de banco de dados. Na verdade, o DBA mais experiente provavelmente precisa de acesso, e um vice, caso o DBA Sênior esteja doente ou não esteja disponível. Você pode querer auditar todo o acesso. Você pode querer forçar os DBAs a solicitar acesso de um administrador de sistema antes que eles possam acessar o servidor. Você provavelmente deseja bloquear onde eles podem acessá-lo (ou seja, PC de trabalho específico) e possivelmente vezes também.
3. A Criptografia transparente de dados deve ser usada para que todos os dados no banco de dados sejam criptografados antes que eles atinjam os arquivos. Então, mesmo que alguém receba os discos ou os backups, eles não poderão lê-los
4. Você pode querer criptografar o tráfego de rede entre o banco de dados e o aplicativo.

Em seguida, você deseja bloquear o acesso ao banco de dados do usuário

1. Geralmente, o acesso dos proprietários do esquema deve ser necessário apenas para instalação / atualização. Além disso, o esquema deve ser bloqueado.
2. é mais seguro separar uma camada de aplicativo no banco de dados para que as contas de aplicativo possam executar apenas funções predefinidas (ou seja, não é possível excluir todas as linhas de uma tabela). Uma camada de aplicação de banco de dados é uma ótima defesa contra injeção de SQL, porque o usuário conectado simplesmente não tem permissões de seleção nas tabelas.
3. Armazene valores criptografados em preferência a valores de texto não criptografado e valores de hash em vez de valores criptografados e não armazene nada que não seja necessário. Você realmente precisa dos nomes das pessoas, endereços, números de telefone, cartões de crédito, SSNs, senhas?
4. Dependendo da sua arquitetura, você pode se beneficiar de senhas que expiram regularmente ou de autenticar outro mecanismo.

Não esqueça do DR. Enquanto eu estava brincando sobre a limpeza dos discos, se a sua avaliação de risco é que alguém faria muito bem em deixar você fora do negócio por alguns dias (ou permanentemente), queimar seu data center é uma questão de segurança.

    

Answer 2

Aqui está uma lista de verificação para a segurança do SQL Server que parece focada na configuração do próprio servidor SQL: link

Além disso (se você não puder confiar apenas no modelo de segurança do Windows), você também desejará passar pelo exercício necessário para criptografar as seqüências de conexão.

    

Answer 3

Uma pergunta bastante aberta.

Um bom começo é ler algumas das noções básicas, Wikipedia tem um bom artigo sobre ele. Então você tem que olhar para os detalhes do seu sistema específico. Quase todos os mecanismos de banco de dados fornecem muitas informações sobre como proteger especificamente seus sistemas. E não se esqueça de olhar para o horizonte: não apenas o banco de dados está "protegido", mas também o sistema em que ele é executado.

SQL Injection é comum, mas uma das muitas preocupações de segurança a serem levadas em consideração.

    

Answer 4

No Oracle, uma escolha de design frequente que vejo sendo feita é que o aplicativo sempre efetua login como um usuário / esquema de banco de dados único - o proprietário de todos os objetos para esse aplicativo.

Um design melhor é ter um usuário / esquema que possua os objetos para o aplicativo e, em seguida, REVOKE CREATE SESSION desse usuário. Em seguida, crie outro usuário / esquema que não possua objetos (exceto, talvez, para sinônimos) que serão usados pelo aplicativo para efetuar login no banco de dados. Em seguida, emita as concessões mínimas necessárias (SELECT, INSERT, UPDATE, DELETE, EXECUTE, etc) para o usuário do aplicativo.

Dessa forma, você sabe que, mesmo que um bug no aplicativo permita que um usuário faça algo que não deveria (por exemplo, excluir registros de uma tabela), os privilégios do banco de dados garantirão que isso não acontecerá.

Caso contrário, se o aplicativo efetuar login como proprietário, não será possível%% dos privilégios em qualquer um dos objetos.