Aula 9 - Material Escrito

Objetivo da Aula

Entender segurança como atributo de qualidade do software e traduzir esse atributo em decisões concretas de autenticação, autorização, emissão de tokens, MFA e rastreabilidade para a API do projeto.

1. Storytelling: por que segurança entra no projeto agora

Imagine um dashboard gerencial com dados de RH e desempenho. O endpoint de exportação funciona, o relatório é bonito e o deploy está no ar. Um colaborador cai em phishing, entrega a senha e o atacante entra com credenciais legítimas. Não houve “exploit cinematográfico”; houve falha de desenho de segurança.

A partir desse ponto, o problema deixa de ser técnico apenas. A organização perde confidencialidade, confiança e capacidade de provar o que aconteceu. Por isso a pergunta correta não é “tem login?”, e sim “o que impede, detecta e rastreia abuso?”.

2. O que é SWEBOK e onde segurança se encaixa

SWEBOK significa Guide to the Software Engineering Body of Knowledge. Ele organiza o corpo de conhecimento essencial de engenharia de software. Em segurança, a leitura mais útil para esta disciplina é:

• Software Requirements: segurança aparece como requisito de qualidade e restrição do sistema.
• Software Design: arquitetura traduz risco em mecanismos de controle.
• Software Construction: implementação correta de autenticação, sessões, segredos e validações.
• Software Testing / Software Quality: verificação de comportamentos esperados e proteção contra abuso.

A mensagem principal é que segurança não mora em um único capítulo. Ela atravessa o ciclo inteiro.

3. Segurança como requisito não funcional

Requisitos funcionais descrevem serviços e comportamentos de negócio: cadastrar usuário, exportar relatório, filtrar dados. Requisitos não funcionais descrevem qualidades e restrições: desempenho, disponibilidade, confiabilidade e segurança.

• “Gerar relatório trimestral” é funcional.
• “Somente gestor autenticado com MFA pode exportar relatório sensível” é segurança como NFR.
• “Registrar toda exportação com usuário, horário e resultado” também é segurança como NFR.

Se não for mensurável, auditável ou testável, ainda está vago demais para ser requisito de segurança.

4. Autenticação x autorização

• Autenticação: prova identidade. Responde “quem é você?”.
• Autorização: prova permissão. Responde “o que você pode fazer?”.

Em APIs, é comum modelar essa diferença também nas respostas:

• 401: sem identidade válida, token inválido ou sessão ausente.
• 403: identidade válida, mas sem permissão para aquele recurso.

5. Os três estágios da segurança

• Conter: impedir acesso indevido com login forte, MFA, rate limit, política e segmentação.
• Observar comportamento: detectar padrões estranhos, tentativas excessivas, acessos incomuns e abuso.
• Rastrear: preservar logs e trilhas de auditoria para reconstruir incidentes e responsabilizar ações.

Segurança madura não é só barreira. É também visibilidade e explicabilidade.

6. Por que a senha está ficando obsoleta

A senha não está ficando irrelevante por fraqueza matemática, mas por vulnerabilidade operacional. O problema real é que:

• usuários reutilizam senha;
• phishing continua muito eficiente;
• vazamentos em terceiros expõem credenciais;
• engenharia social rouba segredo sem quebrar o sistema.

Por isso a indústria migra para MFA, passkeys, biometria e tokens de vida curta.

7. Técnicas de segurança discutidas na aula

• MFA com aplicativo autenticador.
• JWT para autenticação stateless em APIs.
• Autorização por roles, claims e policies.
• Logs de auditoria e rastreabilidade.
• Provedor de identidade externo, como Keycloak ou Auth0.

8. MFA com Google Authenticator no .NET

O padrão mais simples para o projeto é TOTP: o servidor gera um segredo, o usuário cadastra esse segredo no app Google Authenticator e, a cada login, informa um código temporário. O backend só emite a credencial final após validar esse segundo fator.

TOTP significa Time-based One-Time Password. É uma senha temporária que muda em intervalos curtos, geralmente 30 segundos. O aplicativo e o servidor conseguem gerar o mesmo código porque compartilham um segredo cadastrado durante o onboarding do usuário.

// Exemplo conceitual com Otp.NET
var secret = KeyGeneration.GenerateRandomKey(20);
var base32Secret = Base32Encoding.ToString(secret);

var otpUri =
  $"otpauth://totp/Projeto9:{email}?secret={base32Secret}&issuer=Projeto9";

var totp = new Totp(Base32Encoding.ToBytes(base32Secret));
var isValid = totp.VerifyTotp(
    codigoDigitado,
    out _,
    VerificationWindow.RfcSpecifiedNetworkDelay
);

if (!isValid)
{
    return Unauthorized("Codigo MFA invalido.");
}

Em produção, o segredo precisa ficar protegido, e o sistema deve oferecer códigos de recuperação, limite de tentativas e logs de ativação/falha.

9. Como funciona o JWT

JWT é um formato de token composto por header.payload.signature. Em geral, o provedor de identidade autentica o usuário e emite um token assinado. A API recebe esse token e valida:

• assinatura;
• emissor (iss);
• audiência (aud);
• expiração (exp);
• claims usadas para autorização.

{
  "sub": "user-123",
  "role": "manager",
  "department": "rh",
  "scope": "reports:read reports:export",
  "iss": "https://auth.projeto9.local",
  "aud": "projeto9-api",
  "exp": 1772804400
}

JWT não deve carregar segredo nem dado sensível desnecessário. Ele é útil porque transporta identidade e contexto, não porque substitui boas decisões de segurança.

10. Keycloak como técnica de segurança de token

Keycloak é uma solução open source de gerenciamento de identidade e acesso. Em vez de sua API implementar tudo manualmente, o sistema delega autenticação, emissão de token, gestão de usuários e integração com OAuth2/OIDC a um provedor especializado.

• O usuário autentica no provedor.
• O provedor emite o JWT.
• A API valida o token e aplica autorização localmente.
• O time ganha centralização de identidade e consistência de políticas.

Isso reduz a chance de o time reinventar uma camada crítica com falhas conceituais.

11. Auth0 para o projeto

Auth0 é uma plataforma gerenciada de identidade. Para fins práticos da disciplina, ele pode ser encarado como uma alternativa comercial para delegar autenticação, MFA e emissão de tokens sem operar um servidor de IAM por conta própria.

• Prós: rapidez, boa documentação, MFA pronto, menor esforço operacional.
• Contras: custo, dependência de fornecedor e limites do plano gratuito.

12. Atividade de pesquisa do grupo

Escolham uma abordagem para aplicar no projeto e entreguem:

• fluxo desenhado de login, MFA, emissão de token e autorização da API;
• justificativa técnica da escolha;
• endpoints que exigirão proteção diferenciada;
• lista mínima de logs e eventos auditáveis;
• critérios de aceitação para validar a segurança proposta.

As duas sugestões da aula são:

• Google Authenticator via Firebase: foco em rapidez de adoção e MFA gerenciado.
• Auth0: foco em arquitetura de identidade, tokens e autorização por claims.

Pergunta final para orientar o projeto

Se um atacante roubar apenas a senha de um usuário hoje, o que exatamente ainda impede esse atacante de acessar, exportar ou manipular os dados mais sensíveis da sua aplicação?