Fundamentos de segurança da informação para desenvolvedores

A maior parte da segurança de software é bom senso aplicado, mas a área tem um vocabulário preciso, e usá-lo de forma frouxa leva a controles que erram o alvo. "Torne isso seguro" não é um requisito; "a trilha de auditoria deve tornar qualquer adulteração detectável e ser mantida por sete anos" é. Este guia cobre os conceitos que um desenvolvedor encontra em requisitos de segurança, registros de riscos, relatórios de testes de invasão e revisões de incidentes — o suficiente para ler esses documentos com precisão e defender o controle certo.

Ele é propositalmente introdutório. Quando um assunto tem guia próprio, este apresenta a visão geral e aponta o caminho: as fraquezas específicas da web estão no OWASP Top 10, a prática de design em arquitetura de segurança de aplicações, e tudo sobre contas e permissões em gestão de identidades e acessos.

As propriedades que vale a pena nomear

A tríade CIA (confidencialidade, integridade e disponibilidade, na sigla em inglês) nomeia as três propriedades clássicas de segurança.

Confidencialidade — a informação só está disponível para quem tem autorização para vê-la. É quebrada por um bucket de armazenamento exposto, um log com números de cartão, uma API que devolve o registro de outro cliente.

Integridade — informações e sistemas não podem ser alterados sem que isso seja detectado. É quebrada por um mecanismo de atualização sem assinatura, um valor total que o cliente consegue recalcular, um log de auditoria que um administrador pode editar.

Disponibilidade — o serviço pode ser usado quando necessário. É quebrada por um ataque de esgotamento de recursos, mas com muito mais frequência por um certificado expirado ou um deploy que falhou, e é por isso que disponibilidade é tanto uma propriedade de engenharia quanto de segurança.

Outras duas propriedades importam o bastante para ganhar nome próprio. Autenticidade é saber que uma mensagem ou um ator é de fato quem diz ser — a propriedade que a autenticação e as assinaturas digitais oferecem. Não repúdio é poder demonstrar depois que uma parte específica realizou uma ação, de modo que ela não possa negá-la de forma crível; exige ao mesmo tempo autenticação forte e um registro imutável, e é por isso que sistemas financeiros e jurídicos se preocupam em assinar, e não apenas em autorizar.

Escreva os requisitos nesses termos. "Os registros de aprovação devem tornar qualquer adulteração detectável" é um requisito de integridade testável; "o sistema deve ser seguro" não é.

Risco em termos de segurança

A gestão de riscos usa cinco palavras de forma consistente, e misturá-las produz registros inúteis.

• Um ativo é algo de valor: um conjunto de dados, um serviço, uma reputação, uma chave.
• Uma ameaça é uma causa potencial de dano — um agente com uma motivação ou um evento como uma enchente.
• Uma vulnerabilidade é uma fraqueza que uma ameaça pode explorar: uma biblioteca sem patch, uma verificação ausente, um usuário sem treinamento.
• A probabilidade é o quanto essa combinação é provável, levando em conta a exposição e a capacidade do atacante.
• O impacto é quanto custa se acontecer — em termos financeiros, regulatórios, operacionais ou de reputação.

Risco é a combinação de probabilidade e impacto de uma ameaça específica explorando uma vulnerabilidade específica contra um ativo específico. Uma vulnerabilidade sem nenhuma ameaça plausível é um risco baixo; uma vulnerabilidade modesta em um sistema exposto à internet que guarda dados regulados, não.

Existem quatro respostas, e o objetivo do exercício é escolher de forma consciente: mitigar adicionando um controle, transferir por meio de seguro ou contrato, evitar deixando de fazer a coisa arriscada, ou aceitar com um responsável nomeado e uma data de revisão. Aceitar um risco deliberadamente é legítimo; descobrir, em uma revisão pós-incidente, um risco aceito que ninguém lembra de ter aceitado, não.

A criptografia de que um desenvolvedor realmente precisa

No código de aplicação, a criptografia dá errado principalmente por erros de categoria — usar uma primitiva que não oferece a propriedade exigida. Quatro categorias, quatro garantias.

A codificação converte dados entre representações. Base64, URL encoding e hexadecimal não têm chave nem sigilo; existem para que dados binários sobrevivam a um canal de texto. Um codificador e decodificador base64 reverte qualquer um deles na hora, e é exatamente essa a ideia.

O hashing mapeia uma entrada para um resumo de tamanho fixo, de forma determinística e irreversível. Ele garante integridade e identidade do conteúdo, não confidencialidade. Use SHA-256 ou SHA-3 para checksums e fingerprints; MD5 e SHA-1 estão quebrados para qualquer uso relevante em segurança, porque é possível construir colisões. Verificar um artefato baixado contra um resumo publicado é um uso legítimo de um gerador de hash; armazenar senhas não é — isso exige uma função lenta e que consuma muita memória.

A criptografia simétrica usa uma única chave compartilhada para cifrar e decifrar. AES em um modo autenticado como o GCM é a escolha padrão; é rápido, serve para grandes volumes de dados, e todo o problema passa a ser como os dois lados obtiveram a chave. Nunca reutilize um nonce com a mesma chave, e nunca use o modo ECB puro, que vaza a estrutura dos dados.

A criptografia assimétrica usa um par de chaves: a chave pública cifra e só a chave privada decifra. RSA e os algoritmos de curva elíptica são lentos em comparação com as cifras simétricas, então os sistemas reais os usam para estabelecer ou encapsular uma chave simétrica e depois passam a usá-la — o arranjo híbrido que o TLS adota.

As assinaturas digitais invertem o par assimétrico: a chave privada assina um hash, e qualquer pessoa com a chave pública verifica. Isso fornece integridade, autenticidade e não repúdio de uma só vez, e é o mecanismo por trás de certificados, tokens assinados e artefatos de release assinados. Um código de autenticação de mensagem como o HMAC também fornece integridade e autenticidade, mas com um segredo compartilhado, então não consegue provar qual das partes o gerou.

Uma regra sustenta tudo isso: use uma biblioteca consagrada e uma construção padrão. Protocolos feitos em casa e o "a gente faz um XOR com um segredo" falham de maneiras óbvias para especialistas e invisíveis para quem os escreveu.

TLS e a cadeia de certificados

O TLS dá a uma conexão confidencialidade, integridade e autenticidade do servidor, e é o controle que o resto da stack pressupõe silenciosamente. O TLS 1.3 (RFC 8446) simplificou o handshake para uma única ida e volta e removeu as cifras e opções antigas que causaram a maioria das falhas históricas.

Client                                          Server
  |-- ClientHello -------------------------------->|   supported groups, key share, cipher suites
  |<------------------------------- ServerHello ---|   chosen suite, key share
  |<------------- {EncryptedExtensions, Certificate,|
  |                CertificateVerify, Finished} ----|   everything after ServerHello is encrypted
  |-- {Finished} --------------------------------->|
  |<========== application data (AEAD) ===========>|

Cada lado contribui com uma parte de chave Diffie-Hellman efêmera, e os dois derivam o mesmo segredo de sessão sem que ele jamais trafegue pela rede. Como a chave é efêmera, gravar o tráfego hoje e roubar a chave privada do servidor amanhã não permite decifrá-lo — é a propriedade chamada forward secrecy, agora obrigatória. O servidor prova que detém a chave privada do seu certificado assinando a transcrição do handshake em CertificateVerify, o que impede um atacante de reaproveitar um certificado que apenas copiou.

A confiança vem da infraestrutura de chaves públicas (PKI). Uma autoridade certificadora verifica o controle de um domínio e emite um certificado que vincula esse nome a uma chave pública, assinado por uma autoridade intermediária cujo próprio certificado é assinado por uma raiz em que seu sistema operacional ou navegador já confia. A validação percorre essa cadeia, verifica a assinatura em cada etapa, confere as datas de validade, se o nome corresponde e a revogação. O que ela prova é restrito e merece ser dito com todas as letras: você está falando com quem detém a chave privada desse nome, e ninguém no meio consegue ler nem modificar o tráfego. Ela não atesta nada sobre o operador.

Consequências práticas para um desenvolvedor: sirva TLS 1.3 ou 1.2 com suítes modernas e nada mais antigo; habilite o HSTS para que os navegadores se recusem a fazer downgrade; automatize a renovação, porque a expiração é a principal causa de incidentes de TLS; use TLS também dentro da rede, já que a posição na rede não é uma fronteira de confiança; e nunca desabilite a validação de certificados para fazer um teste passar — esse hábito invariavelmente escapa para produção. Quando as duas partes precisam se autenticar, o TLS mútuo faz o cliente apresentar um certificado também, e é a escolha habitual para chamadas entre serviços.

Governança, normas e políticas

As organizações gerenciam a segurança por meio de frameworks, e os requisitos que chegam a um time de desenvolvimento quase sempre nascem de um deles.

A ISO/IEC 27001 especifica um sistema de gestão da segurança da informação: definir o escopo, avaliar os riscos, selecionar controles, documentá-los, medir e melhorar, e passar por auditoria com base nisso. A certificação é um ativo de negócio porque os clientes a pedem, e seus controles viram as expectativas no nível do time — gestão de mudanças, revisão de acessos, logging, avaliação de fornecedores, desenvolvimento seguro.

O NIST Cybersecurity Framework 2.0 organiza as atividades em seis funções: Govern, Identify, Protect, Detect, Respond e Recover. É mais um vocabulário para estruturar do que uma certificação, e é especialmente útil para identificar desequilíbrios — muitos times investem pesado em Protect e quase nada em Detect e Recover.

Outros aparecem em contextos específicos: PCI DSS para dados de cartão, SOC 2 para organizações prestadoras de serviços e a regulação setorial em finanças e saúde.

Uma política de segurança é a declaração escrita do que a organização exige, com padrões e procedimentos abaixo dela que trazem os detalhes. Políticas que os desenvolvedores conseguem seguir são curtas, específicas e verificáveis; políticas escritas para agradar um auditor tendem a não ser lidas nem seguidas, o que é pior do que não ter nenhuma, porque cria uma não conformidade documentada.

Resposta a incidentes

Incidentes acontecem com organizações competentes. A diferença entre uma semana ruim e uma catástrofe é a preparação, e vale a pena conhecer as fases do NIST SP 800-61 antes de precisar delas.

Preparação. Contatos, papéis, um caminho de escalonamento, acesso aos logs, backups testados e um plano ensaiado. Tudo o que é caro de organizar sob pressão é organizado agora.

Detecção e análise. Reconhecer que algo está acontecendo, a partir de um alerta, do relato de um cliente ou de uma notificação de terceiros, e estabelecer o escopo: o que foi atingido, quando começou, se ainda está em andamento. Isso depende inteiramente do logging e do monitoramento implantados antes.

Contenção, erradicação e recuperação. Conter a propagação — isolar um host, revogar credenciais, desativar um endpoint — preservando as evidências, porque uma máquina apagada não pode ser analisada. Depois, remover a causa, restaurar a partir de um estado sabidamente íntegro e monitorar de perto qualquer recorrência.

Atividades pós-incidente. Uma revisão sem busca de culpados sobre o que aconteceu, qual foi a linha do tempo, o que funcionou e quais mudanças evitam uma repetição, com responsáveis e prazos. Um incidente que não gera nenhuma mudança duradoura foi desperdiçado.

Duas coisas que os desenvolvedores precisam saber de antemão: para quem ligar às três da manhã, e que rotacionar credenciais, revogar tokens e forçar nova autenticação precisam ser operações que você consiga executar rapidamente. Pratique; um runbook que ninguém executou é uma hipótese.

Proteção de dados pessoais

Regulamentações de proteção de dados como o GDPR impõem princípios que se traduzem diretamente em decisões de design, qualquer que seja a sua jurisdição.

• Base legal e limitação de finalidade — coletar para uma finalidade declarada e não reaproveitar os dados discretamente para outra.
• Minimização de dados — coletar apenas o que a finalidade exige. A forma mais barata de proteger um campo é não armazená-lo.
• Limitação do armazenamento — definir a retenção por categoria de dados e excluir dentro do prazo, o que significa que a exclusão precisa estar implementada, não ser uma aspiração.
• Integridade e confidencialidade — medidas técnicas adequadas: criptografia, controle de acesso, logging.
• Responsabilização — ser capaz de demonstrar a conformidade, por meio de registros das operações de tratamento e das decisões de design.

Duas técnicas são citadas com frequência e confundidas com frequência. A pseudonimização substitui identificadores por tokens mantendo um mapeamento separado, então os dados continuam sendo pessoais e continuam regulados, embora mais seguros em caso de vazamento. A anonimização elimina de vez a possibilidade de reidentificação, o que coloca os dados fora da regulamentação — e é genuinamente difícil, já que combinações de atributos comuns costumam ser únicas. Incorpore desde o início os direitos que a regulamentação garante — acesso, correção, eliminação, portabilidade —, porque adaptar depois uma exclusão que alcance cada réplica, backup, cache e exportação analítica é uma das tarefas de engenharia mais difíceis em um sistema maduro.

Principais conclusões

• Confidencialidade, integridade e disponibilidade, somadas a autenticidade e não repúdio, dão a você as palavras para escrever um requisito testável.
• Risco é ativo, ameaça, vulnerabilidade, probabilidade e impacto; todo risco termina em uma decisão consciente de mitigar, transferir, evitar ou aceitar.
• Codificação não é criptografia, hash não é reversível, a simétrica é rápida e a assimétrica resolve a distribuição de chaves, e assinaturas provam a origem.
• O TLS 1.3 oferece forward secrecy em uma única ida e volta; certificados provam o controle de um nome e nada sobre o operador, então automatize a renovação e nunca desabilite a validação.
• A ISO 27001 e o framework do NIST são a origem dos requisitos no nível do time; políticas só funcionam se forem curtas, específicas e seguidas.
• Prepare-se para incidentes antes que aconteçam e faça a revisão gerar mudanças; para dados pessoais, minimize, defina a retenção e projete a exclusão desde o início.