Pular para o conteúdo principal

Questão de Banco de Dados — Segurança em Banco de Dados — INSTITUTO AOCP 2024

Banco de DadosSegurança em Banco de Dados
Código
qa630614
Banca
INSTITUTO AOCP
Órgão
DPE MS
Ano
2024
Cargo
Ana Def ( )
Qual é a melhor maneira de proteger um sistema de gerenciamento de banco de dados PostgreSQL contra ataques de SQL Injection?
  1. AUsar uma senha forte e única para o usuário administrativo.
  2. BHabilitar a autenticação por dois fatores (2FA) para todos os usuários.
  3. CAtualizar o PostgreSQL para a versão mais recente.
  4. DCriptografar os dados em repouso.
  5. EValidar todos os dados inseridos no banco de dados.
Revelar gabarito e comentário

GabaritoE — Validar todos os dados inseridos no banco de dados.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Segurança em PostgreSQL: proteção contra SQL Injection

Gabarito: letra E. A melhor maneira de proteger um SGBD PostgreSQL contra ataques de SQL Injection é validar todos os dados inseridos no banco de dados, pois essa técnica impede que entradas maliciosas sejam interpretadas como parte de comandos SQL. As demais alternativas, embora importantes para a segurança geral, não atacam diretamente a vulnerabilidade de injeção de SQL.

SQL Injection é uma das ameaças mais comuns e perigosas a sistemas de banco de dados. Ela ocorre quando um atacante insere código SQL malicioso em campos de entrada de uma aplicação, que é então executado pelo banco de dados. O objetivo é manipular consultas para obter acesso não autorizado, roubar dados, modificar ou excluir informações, ou até mesmo executar comandos arbitrários no servidor. A vulnerabilidade surge quando a aplicação constrói consultas SQL concatenando strings diretamente com a entrada do usuário, sem qualquer tratamento ou validação.

A proteção contra SQL Injection não é uma única medida, mas um conjunto de boas práticas de programação e configuração. A técnica mais eficaz é o uso de comandos parametrizados (também conhecidos como prepared statements ou variáveis de ligação), onde a entrada do usuário é passada como parâmetro e nunca como parte da instrução SQL. Isso garante que o banco de dados trate a entrada como dado, e não como código executável. A validação de entrada (ou filtragem) é outra camada de defesa, que consiste em verificar e sanitizar os dados fornecidos pelo usuário, removendo ou escapando caracteres perigosos, como aspas simples. Embora a validação seja útil, ela não é infalível, pois pode haver muitos caracteres de escape a considerar. Por isso, a combinação de comandos parametrizados com validação de entrada é a abordagem mais robusta.

É importante entender que a segurança de um banco de dados é multifacetada. Medidas como senhas fortes, autenticação em dois fatores, atualizações do sistema e criptografia de dados são fundamentais para proteger o banco contra outros tipos de ataques, como acesso não autorizado, roubo de credenciais ou violação de dados em repouso. No entanto, nenhuma delas aborda diretamente a vulnerabilidade de injeção de SQL, que é uma falha na camada de aplicação. A questão pede especificamente a melhor maneira de proteger contra SQL Injection, e a resposta correta é a que trata da validação dos dados de entrada, que é uma das principais técnicas de proteção contra esse tipo de ataque.

A banca explora a confusão entre medidas de segurança gerais e a proteção específica contra SQL Injection. O candidato pode ser tentado a escolher uma alternativa que pareça mais "forte" ou "abrangente", como criptografia ou autenticação, mas a chave é identificar qual delas ataca diretamente o mecanismo da injeção de SQL. A validação de entrada é a única que impede que o código malicioso seja processado pelo banco de dados, tornando-a a resposta mais adequada.

Proteção contra SQL Injection
  • 1Camada de aplicação (ataca a vulnerabilidade)
    • Validação de entrada (filtragem)
    • Comandos parametrizados (prepared statements)
  • 2Camada do banco (segurança geral, não previne injeção)
    • Senha forte
    • Autenticação 2FA
    • Atualização do SGBD
    • Criptografia em repouso
LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

Usar uma senha forte e única para o usuário administrativo é uma prática de segurança importante para proteger o acesso ao banco de dados, mas não impede ataques de SQL Injection. A injeção de SQL explora vulnerabilidades na aplicação que interage com o banco, não na autenticação do usuário. Uma senha forte protege contra acesso não autorizado, mas não contra a manipulação de consultas SQL por meio de entradas maliciosas.

Alternativa B — ❌ Incorreta

Habilitar a autenticação por dois fatores (2FA) para todos os usuários é uma medida de segurança adicional que dificulta o acesso não autorizado, mas não tem relação direta com a prevenção de SQL Injection. O 2FA protege contra roubo de credenciais, mas não impede que um atacante explore uma vulnerabilidade de injeção de SQL na aplicação, que pode ser feita mesmo por um usuário autenticado.

Alternativa C — ❌ Incorreta

Atualizar o PostgreSQL para a versão mais recente é importante para corrigir vulnerabilidades conhecidas do próprio SGBD, mas a SQL Injection é uma vulnerabilidade da aplicação que usa o banco, não do banco em si. Atualizações do PostgreSQL podem corrigir falhas de segurança internas, mas não protegem contra uma aplicação que constrói consultas SQL de forma insegura.

Alternativa D — ❌ Incorreta

Criptografar os dados em repouso protege os dados armazenados no disco contra acesso não autorizado, mas não impede ataques de SQL Injection. A criptografia protege a confidencialidade dos dados, mas não interfere na execução de comandos SQL maliciosos, que ocorre na camada de aplicação antes de os dados serem armazenados ou recuperados.

Alternativa E — ✅ Correta ⟵ GABARITO

Validar todos os dados inseridos no banco de dados é a técnica mais eficaz para prevenir SQL Injection. A validação de entrada (ou filtragem) consiste em verificar e sanitizar os dados fornecidos pelo usuário, removendo ou escapando caracteres perigosos, como aspas simples, que poderiam ser usados para manipular a consulta SQL. Além disso, a validação pode ser combinada com o uso de comandos parametrizados, que tratam a entrada como dado e não como código, eliminando a possibilidade de injeção. Essa é a abordagem recomendada por especialistas em segurança de banco de dados.

PEGA ESSA DICA!

Para questões sobre SQL Injection, lembre-se de que a proteção está na camada de aplicação, não no banco de dados. As medidas de segurança do banco (senha, 2FA, criptografia, atualização) protegem contra outros tipos de ataque, mas a validação de entrada e o uso de comandos parametrizados são as defesas específicas contra injeção de SQL.

Gabarito: letra E

Link permanente: /questoes/qa630614