Fundamentos de Segurança Cibernética: risco e proteção de aplicações

Introdução

Segurança Cibernética começa pela compreensão do que precisa ser protegido e das consequências de uma falha. Uma aplicação não é segura apenas porque autentica usuários, utiliza um framework conhecido ou passou por uma ferramenta automatizada.

O trabalho envolve decisões contínuas de prevenção, detecção, resposta e recuperação. Essas decisões atravessam arquitetura, desenvolvimento, infraestrutura, produto, privacidade e operação.

O vocabulário do risco

Um ativo é algo que possui valor para a organização ou para as pessoas: dados, credenciais, código, disponibilidade de um serviço, reputação ou receita.

Uma ameaça é uma circunstância ou ação capaz de causar dano. Ela pode envolver um agente malicioso, erro humano, falha técnica ou evento ambiental.

Uma vulnerabilidade é uma fraqueza que pode ser explorada ou acionada. Código sem autorização, configuração permissiva e algoritmo criptográfico inadequado são exemplos.

Um incidente ocorre quando um evento compromete, ou ameaça comprometer, a operação ou a segurança. O impacto descreve a consequência para dados, pessoas, serviço e negócio.

A probabilidade expressa quão plausível é o cenário no contexto analisado. O risco combina essa plausibilidade com as consequências esperadas, sem depender de uma fórmula universal.

Critérios para avaliar risco

A classificação precisa considerar contexto e evidências. Entre os critérios úteis estão exposição do fluxo, facilidade de abuso, privilégios necessários, alcance sobre dados, criticidade operacional, capacidade de detecção e dificuldade de recuperação.

Rótulos como baixo, médio e alto só são comparáveis quando a organização documenta o significado de cada nível. Um risco alto para um portal interno pode ter natureza diferente de um risco alto para uma plataforma de pagamentos.

Confidencialidade, integridade e disponibilidade

A tríade CID organiza três objetivos fundamentais:

• Confidencialidade: somente identidades autorizadas acessam a informação.
• Integridade: dados e comportamentos não são alterados de forma indevida.
• Disponibilidade: sistemas e informações permanecem acessíveis quando necessários.

Os objetivos criam trade-offs. Criptografia e verificações adicionais podem aumentar latência; redundância eleva custo; controles de acesso excessivamente rígidos podem prejudicar uma operação legítima. A decisão madura explicita o que está sendo protegido e qual custo foi aceito.

Princípios que reduzem o raio de impacto

O menor privilégio concede somente as permissões necessárias, pelo tempo e no escopo necessários. Uma conta de aplicação que apenas consulta pedidos não deveria poder alterar usuários administrativos.

A defesa em profundidade combina camadas independentes. Validação de entrada, autorização no servidor, segmentação, criptografia, logs e alertas tratam falhas diferentes. Se uma camada cair, as demais ainda limitam o impacto.

Zero Trust elimina confiança implícita baseada apenas na origem da rede. Usuários, dispositivos e serviços precisam ser verificados explicitamente; cada acesso deve ser autorizado, limitado e observado.

Codificação, criptografia e transporte seguro

Codificação transforma a representação de dados para compatibilidade ou transporte. Base64 é reversível sem segredo; portanto, não oferece confidencialidade.

Criptografia utiliza algoritmos e chaves para proteger propriedades como confidencialidade ou autenticidade. Sua segurança depende do algoritmo, do modo, do tamanho de chave, do gerenciamento de chaves e da implementação.

O esquema HTTP Basic Authentication envia o par usuário e senha codificado em Base64. Isso não é criptografia. Sem Hypertext Transfer Protocol Secure (HTTPS), credenciais e conteúdo podem ficar expostos no transporte.

HTTPS aplica Transport Layer Security (TLS) ao tráfego HTTP. HTTP Strict Transport Security (HSTS) instrui navegadores compatíveis a usar HTTPS nas visitas seguintes, reduzindo oportunidades de downgrade após uma primeira conexão segura.

Algoritmos também envelhecem

O uso de Data Encryption Standard (DES) é inadequado para nova proteção de dados. O algoritmo legado não oferece a força esperada para sistemas atuais.

O rótulo RSA-256 é ambíguo. Se significar uma chave RSA de 256 bits, o tamanho é inadequado; recomendações atuais exigem parâmetros muito maiores. Se a intenção for RSA com SHA-256, ainda é necessário declarar esquema de assinatura ou padding, finalidade, tamanho de chave e biblioteca. Nomes imprecisos escondem decisões críticas.

Migração criptográfica exige inventário, compatibilidade, rotação de chaves, recriptografia quando aplicável e plano de reversão. Trocar o nome do algoritmo em uma configuração não completa o trabalho.

Autenticação, autorização, 401 e 403

Autenticação comprova ou estabelece a identidade apresentada. Autorização decide se essa identidade pode executar uma ação sobre um recurso específico.

Em termos práticos, uma sessão válida responde “quem está chamando?”. A política de acesso responde “essa identidade pode alterar este recurso agora?”.

Os códigos não substituem a política. A autorização deve ocorrer no servidor, em todas as operações sensíveis, considerando função, propriedade do recurso, estado do negócio e contexto.

Caso: endpoint administrativo

Considere POST /admin/users/42/suspend. O middleware confirma um token válido, mas o handler não verifica permissão administrativa. A aplicação autenticou a identidade e falhou ao autorizar a função.

Prepared statements poderiam proteger uma consulta SQL usada pelo handler, mas não corrigiriam a ausência de autorização. Parametrização e controle de acesso tratam riscos distintos.

A01 e A02 no OWASP Top 10:2021

O OWASP Top 10:2021 é um documento de conscientização sobre riscos de aplicações web. Nesta aula, duas categorias sustentam os fundamentos:

• A01 — Broken Access Control: identidades conseguem agir fora dos limites previstos.
• A02 — Cryptographic Failures: dados ou funções dependem de proteção criptográfica ausente, fraca ou mal aplicada.

Mass assignment é um exemplo concreto de controle de acesso quebrado. Ao desserializar todo o corpo recebido diretamente em uma entidade, a API pode permitir a modificação de propriedades internas.

type UpdateProfileInput = {
  displayName: string;
};
 
const input: UpdateProfileInput = {
  displayName: request.body.displayName,
};
 
await profiles.update(request.user.id, input);

O contrato público aceita apenas displayName. O campo role não é copiado do cliente, e mudanças de privilégio seguem um fluxo administrativo separado, autorizado e auditado.

Threat modeling e attack trees

Threat modeling, ou modelagem de ameaças, antecipa perguntas de segurança durante o desenho. O time identifica ativos, fluxos de dados, fronteiras de confiança, ameaças, cenários de abuso, controles e risco residual.

Uma attack tree, ou árvore de ataque, decompõe um objetivo adversário em caminhos possíveis. Ela não prevê tudo; ajuda o time a tornar hipóteses discutíveis e testáveis.

Objetivo: obter privilégio administrativo
├── Alterar role por mass assignment
├── Chamar endpoint sem autorização
└── Obter credencial de administrador
    ├── Interceptar tráfego sem HTTPS
    └── Explorar gestão inadequada de segredo

O time pode então relacionar cada ramo a prevenção, sinais de detecção, resposta e recuperação. O aprofundamento de threat modeling está em Security by Design, Privacy by Design e frameworks.

DevSecOps e capacidade de detecção

DevSecOps integra segurança ao planejamento, desenvolvimento, entrega e operação. Isso inclui critérios de aceite, revisão de arquitetura, testes automatizados, gestão de dependências, proteção de artefatos e observabilidade.

Logs úteis registram identidade, ação, recurso, resultado, contexto de correlação e horário, sem expor segredos ou dados pessoais desnecessários. Monitoramento transforma esses eventos em indicadores, alertas e investigação.

Um Security Information and Event Management (SIEM) centraliza e correlaciona eventos de segurança. Um Security Orchestration, Automation and Response (SOAR) ajuda a coordenar playbooks e automatizar partes de uma resposta.

Automação precisa de limites. Bloquear toda identidade após um único sinal fraco pode ampliar indisponibilidade. Ações irreversíveis ou de grande alcance exigem confiança suficiente, supervisão e trilha de auditoria.

Privacidade e proteção de dados

Segurança protege sistemas, dados e ativos contra ações indevidas. Privacidade orienta a coleta e o tratamento de dados pessoais de acordo com finalidade, necessidade, transparência e direitos das pessoas.

Criptografar tudo o que foi coletado não corrige coleta excessiva. Da mesma forma, minimizar dados não substitui controle de acesso, monitoramento ou resposta a incidentes. Security by Design introduz decisões de proteção desde o desenho; Privacy by Design trata riscos às pessoas desde o início. A distinção é aprofundada na Live 02 desta trilha.

Referências

• OWASP Top 10:2021 — categorias A01 a A10 para aplicações web.
• OWASP A01:2021 — Broken Access Control — controle de acesso no servidor e menor privilégio.
• RFC 7617 — The Basic HTTP Authentication Scheme — definição do esquema Basic e uso de Base64.
• RFC 9110 — HTTP Semantics — semântica dos códigos 401, 403 e 404.
• NIST SP 800-131A Rev. 2 — transição de algoritmos e tamanhos de chave criptográficos.
• NIST Cybersecurity Framework 2.0 — resultados de governança, identificação, proteção, detecção, resposta e recuperação.
• OWASP Threat Modeling Project — práticas e recursos de modelagem de ameaças.

Conclusão

Segurança de aplicações depende de linguagem precisa e controles proporcionais ao risco. Ativos, ameaças, vulnerabilidades, incidentes e impactos descrevem partes diferentes do cenário; confidencialidade, integridade e disponibilidade mostram o que pode ser comprometido.

Autenticação não substitui autorização. Base64 não é criptografia. Prepared statements reduzem SQL Injection clássica, mas não corrigem controle de acesso. HTTPS, HSTS, algoritmos adequados e gestão de chaves protegem o transporte e os dados, sem eliminar falhas de lógica.