Aula 5

Controle de usuários no desenvolvimento colaborativo

Professor: Ricardo Pires
3º Técnico DS - Desenvolvimento de Sistemas II

---

🚀 Roteiro (105 min)

• Ritmo: Conceito → Código → Resolução de Problema.
• Foco: acesso, rastreabilidade e segurança no ciclo de desenvolvimento.
• Meta: colaboração com governança técnica.

---

🧠 Conceito: identidade e responsabilidade

• Cada integrante usa conta individual.
• Permissão por papel (RBAC).
• Nada de usuário compartilhado.

dev -> Pull Request -> reviewer -> maintainer -> main

---

🔐 Regras mínimas de segurança

• MFA obrigatório.

• Branch protection em main.

• CI bloqueando merge com teste falho.

• Secrets fora do código (vault/env).

• Resultado: trilha de auditoria confiável.

---

💻 Exemplo prático (política de PR)

Regras de merge:
[ ] 1 aprovação obrigatória
[ ] Build e testes verdes
[ ] Sem push direto na main
[ ] Histórico de revisão preservado

• Evita “subiu e quebrou” em produção.

---

🗣️ Desafio do Código - O Bug de Produção

Token de acesso de ex-colaborador permanece ativo e dispara alteração indevida em configuração.

Impacto:
- Risco de segurança
- Indisponibilidade parcial
- Necessidade de rollback urgente

• Causa: processo fraco de revogação de acesso.

---

✅ Desafio do Código - A Solução do Sênior

• Revogar acessos no desligamento imediatamente.
• Automatizar checklist de offboarding.
• Auditar permissões periodicamente.

Governança contínua -> menos incidente -> time mais confiável

---

🎯 Checklist final da Aula 5

1. Há separação clara de papéis no repositório?
2. O merge depende de review e CI?
3. Existe trilha de auditoria por autor?
4. O processo de revogação de acesso está formalizado?

📝 Atividades práticas em sala (30 min)

Exercício 1: Configuração de repositório

Analisar este cenário de repositório e identificar problemas:

Repositório "sistema-vendas":
- Branch main: sem proteção
- Todos os devs: admin rights
- CI: opcional
- Secrets: no código fonte (hardcoded)
- MFA: não obrigatório

Tarefas:

1. Listar todos os riscos identificados
2. Priorizar por criticidade (alta/média/baixa)
3. Propor solução para os 3 principais

Exercício 2: Política de commit

Escrever policy de commit para o time considerando:

• Formato de mensagem
• Quando fazer commit
• Como fazer merge
• Quem pode aprovar PR

---

✅ Gabarito das atividades

Gabarito 1 - Riscos identificados:

Alta criticidade:

1. Secrets hardcoded (vazamento de credenciais)
2. Sem branch protection (push direto na main)
3. Admin rights para todos (acesso excessivo)

Média criticidade: 4. CI opcional (deploy com erro) 5. Sem MFA (conta comprometida)

Soluções propostas:

• Mover secrets para vault/environment variables
• Ativar branch protection na main
• Implementar RBAC (dev/reviewer/maintainer)

Gabarito 2 - Política de commit:

Formato: tipo(escopo): descrição
Exemplo: feat(auth): adicionar validação de JWT
 
Regras:
- Commit pequeno e atômico
- PR obrigatório para main
- 1 aprovação mínima
- CI verde obrigatório
- Revisor não pode ser o autor

Atividade rápida

• Documentar política de acesso do projeto atual.
• Alinhar papéis e responsabilidades na equipe.