CompTIA SY0-701: Segurança de Dados, Privacidade e Criptografia — Guia de estudos

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Faz parte do CompTIA Security+ SY0-701 — Guia de estudos. Pratique com respostas verificadas no centro de exames da CompTIA, ou faça testes cronometrados no ExamRoll.io.

Os dados são o alvo final da maioria dos ataques, e a criptografia é o principal mecanismo técnico para protegê-los em trânsito, em repouso e em uso. Compreender as propriedades, limitações e a aplicação correta das primitivas criptográficas é fundamental — não apenas para o exame, mas para projetar sistemas que permaneçam seguros quando os controles individuais falham.

Classificação e Manuseio de Dados

A classificação de dados atribui rótulos de sensibilidade que orientam os requisitos de manuseio. Estruturas governamentais usam Não Classificado, Confidencial, Secreto e Ultrassecreto. Estruturas comerciais normalmente usam Público, Interno, Confidencial e Restrito (ou equivalentes). A classificação deve ser orientada pela sensibilidade dos dados e pelas obrigações regulatórias, não por conveniência.

Sistemas de Prevenção contra Perda de Dados (DLP) impõem políticas de manuseio inspecionando o conteúdo em endpoints, pontos de saída da rede e armazenamento em nuvem. Uma regra de DLP pode bloquear anexos de e-mail que contenham sequências de 16 dígitos correspondentes a padrões de cartão de crédito, ou alertar quando um usuário faz upload de um arquivo contendo a frase “alvo de aquisição” para um serviço de armazenamento em nuvem pessoal. A eficácia do DLP depende da classificação precisa — se os dados sensíveis não forem rotulados, o DLP não poderá protegê-los.

A soberania de dados diz respeito a onde os dados residem fisicamente e às leis de qual jurisdição se aplicam. O GDPR exige que os dados pessoais da UE transferidos para fora da UE sejam protegidos por decisões de adequação, Cláusulas Contratuais Padrão ou Regras Corporativas Vinculantes. Organizações que operam globalmente devem mapear os fluxos de dados e garantir que os locais de armazenamento e processamento estejam em conformidade com as regulamentações aplicáveis.

Criptografia em Trânsito e em Repouso

O TLS 1.3 é o padrão atual para criptografar dados em trânsito. Ele elimina conjuntos de cifras (cipher suites) fracos, exige forward secrecy (troca de chaves efêmera Diffie-Hellman) e reduz o handshake para um único round trip. O TLS 1.0 e 1.1 estão obsoletos; o TLS 1.2 continua aceitável, mas deve ser configurado com conjuntos de cifras fortes. Uma configuração do Nginx que impõe os padrões atuais:

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

A criptografia em repouso protege os dados em mídias de armazenamento. A criptografia de disco completo (BitLocker, FileVault, LUKS) criptografa todo o volume; a criptografia em nível de arquivo (EFS, contêineres VeraCrypt) criptografa arquivos individuais. A criptografia em nível de banco de dados (Transparent Data Encryption no SQL Server e Oracle) criptografa arquivos de dados e backups. A nuance crítica: a criptografia em repouso protege contra o roubo da mídia física, mas não protege contra uma aplicação comprometida que já descriptografou os dados para processá-los.

Primitivas Criptográficas

Algoritmos simétricos (AES-128, AES-256, ChaCha20) usam uma única chave compartilhada e são rápidos, adequados para grandes volumes de dados. Algoritmos assimétricos (RSA, ECDSA, Ed25519, ECDH) usam pares de chaves e permitem a troca de chaves, assinaturas digitais e vinculação de identidade, mas são computacionalmente caros. Sistemas híbridos — como o TLS — usam criptografia assimétrica para negociar uma chave de sessão simétrica e, em seguida, criptografam o tráfego em massa de forma simétrica.

O Hashing (SHA-256, SHA-3) é uma função de mão única que produz um resumo (digest) de tamanho fixo. Hashes não são criptografia: eles não podem ser revertidos com uma chave porque não há chave. Hashes de senha com sal (salted) (usando bcrypt, scrypt, Argon2 ou PBKDF2) adicionam um valor aleatório por usuário para derrotar as rainbow tables. Hashes fornecem verificação de integridade; o HMAC combina um hash com uma chave secreta para fornecer tanto integridade quanto autenticidade.

Os modos de cifra importam tanto quanto o algoritmo. O AES no modo ECB criptografa cada bloco independentemente, produzindo texto cifrado idêntico para blocos de texto plano idênticos — uma propriedade catastrófica que vaza padrões de dados. O AES-GCM (Galois/Counter Mode) fornece confidencialidade e integridade em uma única passagem e é o padrão para protocolos modernos. O modo CBC com padding adequado e um HMAC é aceitável, mas mais complexo de implementar corretamente.

Gerenciamento e Armazenamento de Chaves

A criptografia é tão forte quanto seu gerenciamento de chaves. As chaves devem ser geradas com entropia forte, armazenadas separadamente dos dados que protegem, rotacionadas periodicamente e destruídas quando desativadas. Módulos de Segurança de Hardware (HSMs) fornecem armazenamento de chaves resistente a adulterações e aceleração criptográfica. Um Módulo de Plataforma Confiável (TPM) é um chip em endpoints que armazena chaves usadas pelo BitLocker e pela inicialização medida (measured boot). A custódia de chaves (key escrow) deposita uma cópia das chaves com um terceiro confiável para recuperação legal, enquanto os agentes de recuperação de chaves permitem que as empresas descriptografem os dados dos funcionários quando necessário. Serviços de KMS na nuvem (AWS KMS, Azure Key Vault, Google Cloud KMS) oferecem criptografia de envelope (envelope encryption), onde uma chave de criptografia de dados (DEK) protege os dados e é, por sua vez, criptografada por uma chave de criptografia de chaves (KEK) mantida no HSM.

Infraestrutura de Chave Pública (PKI)

A PKI vincula identidades a chaves públicas por meio de certificados emitidos por uma Autoridade Certificadora (CA). Uma CA subordinada se encadeia a uma CA raiz cujo certificado deve ser pré-confiado. O ciclo de vida do certificado começa com uma Solicitação de Assinatura de Certificado (CSR) gerada juntamente com uma chave privada:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

A CA valida o solicitante, assina o CSR e emite um certificado X.509. A revogação é publicada por meio de Listas de Certificados Revogados (CRLs) — listas de números de série revogados baixadas periodicamente — ou por respondedores do Protocolo de Status de Certificado Online (OCSP) que respondem a consultas por certificado em tempo real. O OCSP stapling permite que o servidor apresente um status recente e assinado durante o handshake TLS, evitando consultas do cliente à CA. Os certificados expiram e devem ser renovados; a automação via ACME (Let’s Encrypt, servidores ACME internos) evita interrupções por certificados expirados.

Assinatura de Código e Validação de Integridade

A assinatura de código (code signing) usa a chave privada de um desenvolvedor para assinar um artefato de software; os destinatários verificam a assinatura com o certificado do desenvolvedor, confirmando tanto a integridade quanto a origem. Isso protege contra adulteração na cadeia de suprimentos (supply-chain). Ferramentas de monitoramento de integridade de arquivos (Tripwire, AIDE) e a publicação de hashes (valores de sha256sum junto aos downloads) detectam de forma semelhante modificações não autorizadas, mas o hashing por si só prova apenas que o arquivo corresponde a um valor — ele não autentica quem produziu esse valor. Apenas uma assinatura digital, respaldada por uma PKI, fornece tanto integridade quanto não repúdio (non-repudiation).

Retenção, Sanitização e Descarte Seguro

Políticas de retenção definem por quanto tempo cada classe de dados deve ser mantida e quando deve ser excluída. Regulamentações frequentemente exigem tanto mínimos (registros financeiros por sete anos) quanto máximos (dados pessoais retidos por não mais tempo do que o necessário). Backups não são isentos: se um titular de dados exerce o direito de exclusão, a organização deve ter um processo defensável para remover esses dados dos backups ou documentar as restrições técnicas e os controles compensatórios. Retenções legais (legal holds) sobrepõem a retenção normal e congelam os dados durante um litígio.

Quando a mídia atinge o fim de sua vida útil, a sanitização deve corresponder à sensibilidade dos dados e ao destino da mídia. O NIST SP 800-88 define três níveis: Clear (sobrescrita lógica, suficiente para reutilização dentro da organização), Purge (apagamento criptográfico, apagamento de bloco ou desmagnetização, suficiente para reutilização externa) e Destroy (fragmentação, desintegração, incineração, pulverização). O apagamento criptográfico (cryptographic erasure) — destruir a chave de criptografia para que o texto cifrado se torne irrecuperável — é rápido e eficaz para unidades com autocriptografia (self-encrypting drives) que estão sendo reaproveitadas. A desmagnetização (degaussing) torna a mídia magnética inutilizável e não funciona em SSDs. A destruição física é o único método garantido para mídias danificadas ou para as classificações mais altas.

Cenário Prático: Falha no Gerenciamento de Chaves Levando a uma Violação

Uma empresa de SaaS criptografou seu banco de dados de clientes usando AES-256, mas armazenou a chave de criptografia em um arquivo de configuração de texto plano no mesmo repositório do código da aplicação. Quando um desenvolvedor acidentalmente enviou (push) o repositório para uma conta pública do GitHub, um bot automatizado de varredura de credenciais descobriu a chave em 11 minutos. O invasor usou a chave para descriptografar um backup do banco de dados que havia sido armazenado em um bucket S3 publicamente acessível (uma outra configuração incorreta). A criptografia estava tecnicamente correta — o AES-256 é inquebrável por força bruta — mas o gerenciamento de chaves era catastroficamente falho. Um gerenciamento de chaves adequado teria armazenado a chave em um gerenciador de segredos (AWS Secrets Manager, HashiCorp Vault) com acesso controlado por papéis do IAM (IAM roles), nunca no código-fonte ou em arquivos de configuração.

← Segurança de Cloud · Todos os domínios · Continuidade de Negócios e Recuperação de Desastres →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →