Proteja identidades e acessos
Separe a autenticação da autorização, limite o acesso e contenha um dispositivo comprometido.
- Diferenciar provar uma identidade de decidir o que ela pode fazer
- Aplicar o controle de acesso baseado em funções com negação por padrão
- Evitar referências diretas a objetos inseguras (IDOR)
- Explicar por que a localização na rede, sozinha, não dá confiança e como a segmentação limita o movimento
Duas perguntas protegem toda requisição:
- Autenticação (authn): quem é você? - provado com uma senha, uma passkey, um certificado ou um token.
- Autorização (authz): o que você pode fazer? - decidido por permissões, funções, propriedade e políticas.
Errar na autorização é tão comum que o Broken Access Control (controle de acesso quebrado) é o número um no OWASP Top 10:2025. Erros típicos: verificar as permissões só na interface do usuário, esquecer uma verificação num endpoint, ou confiar num ID na URL sem verificar quem é o dono daquele registro.
Experimente
Até 15 XPAutenticação ou autorização?
Classifique cada verificação ou falha.
“Verificar a assinatura de uma passkey no login”
“Só os gestores podem aprovar relatórios de despesas”
“Um usuário logado abre /invoices/1043, que pertence a outra pessoa”
“Verificar um código de uso único de um aplicativo autenticador”
“Um atendente de suporte pode ler os chamados, mas não apagá-los”
“Um serviço apresenta um certificado de cliente a outro serviço”
Menor privilégio e negação por padrão
O controle de acesso baseado em funções (RBAC) agrupa as permissões em funções (leitor, editor, administrador) e atribui funções aos usuários. Dois princípios o mantêm seguro:
- Negar por padrão - tudo o que não foi explicitamente permitido é recusado, inclusive funções e ações desconhecidas.
- Menor privilégio - dê só o acesso de que uma tarefa precisa, só pelo tempo necessário, e revise-o com regularidade.
Funções não bastam para dados pessoais: um usuário pode ver faturas, mas só as próprias. Quando uma URL tem um ID como /invoices/1043, o servidor precisa verificar a propriedade em toda requisição. Devolver 404 Not Found para registros que não são do usuário (em vez de 403) também evita confirmar que o registro existe.
Prática: negar por padrão
Experimente
Até 15 XPDê a cada função só o que ela precisa
Os leitores leem documentos, os editores leem e alteram, e mais ninguém entra. Ligue e desligue regras até todas as requisições receberem a resposta certa.
Rodada 1 de 1: Funções num aplicativo de documentos
O que nenhuma regra permite é negado por padrão.
Sua política
Solicitações
- Um leitor lê um documentoPermitida (deveria ser permitida)Decidida por: Todos podem fazer tudo
- Um leitor altera um documentoPermitida (deveria ser negada)Decidida por: Todos podem fazer tudo
- Um editor altera um documentoPermitida (deveria ser permitida)Decidida por: Todos podem fazer tudo
- Um editor lê um documentoPermitida (deveria ser permitida)Decidida por: Todos podem fazer tudo
- Uma função desconhecida lê um documentoPermitida (deveria ser negada)Decidida por: Todos podem fazer tudo
Prática: leia a fatura de outra pessoa
Experimente
Até 15 XPExplore uma verificação de acesso quebrada
Você está logada num site de cobrança simulado como ana, e esta é a sua própria fatura. Mude o número na URL para abrir a de outra pessoa. Depois ligue a correção e tente de novo. Nenhuma ferramenta de hacker é necessária: é por isso que esse bug é tão comum.
Uma simulação. Você está conectado como ana.
- Abrir uma fatura que não é sua
- Ativar a correção e ver a mesma solicitação ser recusada
Suponha que um dispositivo está comprometido
Um notebook roubado de um funcionário já está dentro da rede da empresa. Se toda máquina interna consegue alcançar todos os bancos de dados e backups, um único dispositivo comprometido pode virar um incidente muito maior. A segmentação de rede limita quais sistemas podem conversar entre si: um aplicativo web pode precisar de acesso ao banco de dados, mas um notebook de funcionário e a internet aberta, não.
O zero trust (confiança zero) acrescenta uma segunda ideia: estar no Wi-Fi do escritório, na VPN ou num dispositivo da empresa não torna uma requisição automaticamente confiável. Verifique a identidade, o dispositivo, o recurso solicitado e a política a cada decisão de acesso; conceda só o acesso necessário. A segmentação é útil, mas a localização na rede não substitui a autorização na aplicação. A NIST SP 800-207 explica o princípio, e as orientações da CISA sobre microssegmentação mostram como segmentos menores limitam o movimento lateral.
Experimente
Até 15 XPMantenha o banco de dados atrás do aplicativo
O banco de dados escuta na porta 5432. Os clientes ainda precisam de HTTPS na 443, e o servidor do aplicativo ainda precisa da conexão com o banco. Uma regra de permissão ampla hoje abre o banco de dados para todo mundo. Reordene as regras (vale a primeira que bate) até os quatro fluxos terem o veredito certo. Um notebook comprometido não pode chegar direto ao banco de dados.
Regras, verificadas de cima para baixo
- 1PermitirBanco de dados de qualquer lugar (amplo demais)
- 2NegarBloquear outros acessos ao banco de dados
- 3PermitirServidor do aplicativo para o banco de dados
- 4PermitirHTTPS para os clientes
- –Todo o resto: negado por padrão
Tráfego
- O servidor do aplicativo consulta o banco de dadosDeve passar. Correspondeu à regra 1: Permitir.
- Um notebook de funcionário comprometido sonda o banco de dadosDeve ser bloqueado. Correspondeu à regra 1: Permitir.
- Um host da internet sonda o banco de dadosDeve ser bloqueado. Correspondeu à regra 1: Permitir.
- Um cliente carrega o site HTTPSDeve passar. Correspondeu à regra 4: Permitir.
2 fluxos estão com o veredito errado.
Principais conclusões
A autenticação pergunta quem; a autorização pergunta o que essa pessoa pode fazer.
Negue por padrão e conceda o menor privilégio; revise os acessos com regularidade.
Verifique no servidor a propriedade de todo registro que uma requisição cita.
Segmente os sistemas para limitar o movimento lateral, e verifique o acesso mesmo dentro da rede.
Quiz da aula
7 perguntas · aprovação com 5 acertos · até 50 XP
Ao passar, você conclui a aula e mantém sua sequência. As perguntas erradas voltarão em sessões de revisão.
Pratique: escreva código em Python
Escreva código Python no editor e execute os testes com exemplos. O Python roda localmente no navegador usando WebAssembly.
Impeça referências diretas a objetos inseguras
A primeira linha é um JSON que mapeia IDs de faturas para os seus donos. Cada linha seguinte é user GET /invoices/ID. Imprima user /invoices/ID -> 200 só se a fatura existir e pertencer ao usuário; caso contrário, imprima -> 404 (não revele que a fatura de outra pessoa existe).
- Faturas próprias, de outros e inexistentes
O Python é executado em um ambiente isolado no navegador, com limite de 60 segundos. O runtime é carregado pelo CDN do Pyodide; seu código permanece neste navegador.
Dúvidas sobre esta lição
Travou em algum ponto? Pergunte. Descobriu algo? Compartilhe. Explicar também é uma ótima forma de aprender.
Carregando publicações…