🛡️ Plano de Remediação - RedeDor Security Incident Response

Versão: 1.0 Data: 2026-02-26 Status: EM EXECUÇÃO Severidade: 🔴 CRÍTICA

---

Fase 1: LOCKDOWN IMEDIATO (Horas 0-2)

Ação 1.1 - Revoke MSAL Dev ClientSecret

# QUEM: Azure AD Admin
# QUANDO: IMEDIATAMENTE
# PRIORIDADE: 🔴 CRÍTICA

App ID: cc06aa03 (Portal-Dev)
Secret: Qjc8Q~qh5ILbrPG71r35Y2U9M53nNMFZSyGi.aOb

PASSOS:
1. Azure Portal → App Registrations → Portal-Dev (cc06aa03)
2. Certificates & secrets → Client secrets
3. DELETE secret imediatamente
4. Gerar novo secret (use apenas em staging até testar)
5. Audit: Verificar quem criou este secret originalmente
6. Option: Disable app completamente se não for crítica em prod

IMPACTO:
- Portal-Dev para de funcionar
- Nenhuma app pode mais usar Graph API com este secret
- Impede ataque de enumerar 344 apps

Ação 1.2 - Revoke Oracle APEX Secret

# QUEM: APEX Administrator
# QUANDO: HOJE (expira em horas!)
# PRIORIDADE: 🔴 CRÍTICA

Secret: iC_
App ID: 4459f6a9 (APEX - AUTHENTICATION)
Status: EXPIRES TODAY

PASSOS:
1. APEX console → Application security
2. Revoke current secret imediatamente
3. Generate NEW secret
4. Update ALL applications using this secret
5. Verify APEX services operational

IMPACTO:
- Loss of APEX access if not rotated
- Business critical workflows affected
- Need coordinated deployment

Ação 1.3 - Revoke PAT Token Azure DevOps

# QUEM: Azure DevOps Admin
# QUANDO: HOJE
# PRIORIDADE: 🔴 CRÍTICA

Token: EbBQwWRTn29c...AZDO2por
Scope: Code + Packaging Read
Organization: rededorlabs

PASSOS:
1. dev.azure.com → User settings → Personal access tokens
2. Revoke token imediatamente
3. Audit: Check recent usages (IP, repos cloned, etc)
4. Issue NEW token com escopo MÍNIMO:
   - Se para CI/CD: apenas "Code (read)" em 1 repo
   - Se para usuarios: use OAuth em vez de PAT
5. Distribute new token securely (Azure Keyvault)

IMPACTO:
- CI/CD pode quebrar temporariamente
- Precisa novo token em pipelines
- Previne clone futuro de repos

Ação 1.4 - Audit MSAL Prod New Secret

# QUEM: Azure AD Admin + Security Team
# QUANDO: HOJE
# PRIORIDADE: 🔴 CRÍTICA

App ID: 4e5a672f (Portal-Prd)
Novo Secret: IA_8Q~
Status: ADICIONADO DURANTE AUDIT

INVESTIGAÇÃO:
1. Azure AD Audit Logs → Filter: 4e5a672f
2. Find: "Add client secret" event
3. Extract: WHO added it, WHEN, FROM_IP
4. Determine: Legitimate response to incident OR new attack?
5. If attacker added: REVOKE immediately
6. If legitimate: Document as part of incident response

AÇÃO:
- [ ] Review all app secret history
- [ ] Check access logs for abnormal usage
- [ ] Force password change for admins with app access

Ação 1.5 - Enable Enhanced Monitoring

# QUEM: Security + Operations teams
# QUANDO: IMEDIATAMENTE
# PRIORIDADE: 🟠 ALTA

AZURE AD:
- Enable Azure AD Sign-in logs (export to Sentinel)
- Create alerts for:
  * Admin role assignments
  * Service principal secret additions
  * Directory modifications
  * Graph API calls to app management

AZURE DEVOPS:
- Enable audit logs (export to SIEM)
- Create alerts for:
  * Repository clones
  * Code pushes
  * Access to secrets
  * PAT creation/usage

AWS:
- Enable CloudTrail detailed monitoring
- Create alerts for:
  * RDS access
  * Lambda invocations
  * ECR pulls
  * IAM changes
  * STS calls

SPLUNK/SENTINEL:
- Real-time dashboards for anomalies
- BASELINE current activity first!

---

Fase 2: SECRET ROTATION (Horas 2-24)

Ação 2.1 - TOKEN_SECRET Rotation (Complex!)

# QUEM: Backend Engineering + Ops
# QUANDO: Within 24 hours
# PRIORIDADE: 🔴 CRÍTICA
# COMPLEXITY: 🟠 HIGH (requires coordinated deployment)

Current Secret:
569825f342fae7cae51f7c55fcc805c6cec4e2cb7b1535e5344266d332911977

IMPACTO:
- Está em 2 repos (hardcoded!)
- Usado para JWT validation/signing
- Todas as JWTs assinadas com ela ficam inválidas após rotação
- Requer rebuild + deploy sincronizado

PLANO DE ROTAÇÃO:

OPÇÃO A: Dual-Secret Strategy (0-downtime)
1. Generate NEW secret
2. Deploy code que aceita AMBOS os secrets (old + new)
3. Esperar 24h para JWTs antigos expirem
4. Deploy código que aceita apenas NEW secret
5. Delete OLD secret

OPÇÃO B: Maintenance Window (com downtime)
1. Schedule maintenance window (ex: 2-4am)
2. Generate NEW secret
3. Update código em AMBOS os repos:
   - portal-de-relacionamento-backend
   - gestao-de-identidade-serverless
4. Build + test
5. Deploy sincronizado em:
   - AWS Account 282525845483 (gestao-identidade)
   - AWS Account 485245438221 (portal-backend)
6. Verify services operational
7. Delete OLD secret
8. Announce maintenance completion

PASSOS DETALHADOS (Opção A - Recomendada):

Dia 1 (T+0):
- [ ] Create NEW secret (256-bit random)
- [ ] Store in Azure Keyvault temporarily
- [ ] Merge PR to accept BOTH secrets:
  * portal-de-relacionamento-backend/src/config
  * gestao-de-identidade-serverless/src/config
- [ ] Build + Test both apps
- [ ] Deploy to DEV environment
- [ ] Verify JWT validation works with both

Dia 2 (T+24):
- [ ] Deploy to STAGING environment
- [ ] Run smoke tests
- [ ] Monitor for JWT errors

Dia 3 (T+48):
- [ ] Deploy to PROD
- [ ] Monitor: Look for JWT validation failures
- [ ] Keep OLD secret active during window

Dia 4-5 (T+72-120):
- [ ] Verify no more JWTs with OLD signature
- [ ] Deploy code that accepts ONLY NEW secret
- [ ] Test again

Dia 6 (T+144):
- [ ] Deactivate/Delete OLD secret from both locations
- [ ] Delete from Keyvault
- [ ] Update secret management documentation

TESTING:
- [ ] Unit tests: JWT signature verification
- [ ] Integration: End-to-end auth flow
- [ ] Load test: No performance impact
- [ ] Rollback plan: Keep OLD secret in backup

COMMUNICATION:
- [ ] Notify DevOps about maintenance window
- [ ] Notify Support about potential JWT auth issues
- [ ] Prepare rollback documentation

Ação 2.2 - MSAL Prod Secret Rotation

# QUEM: Azure AD Admin + Backend team
# QUANDO: Within 24 hours
# PRIORIDADE: 🔴 CRÍTICA

App: 4e5a672f (Portal-Prd)
Current Secret: IA_8Q~ (new, possibly compromised)
Original Secret: hint `ew5` (exp 2026-05-09)

PLANO:

IMEDIATO:
1. Azure AD → App registrations → Portal-Prd
2. Generate BRAND NEW secret
3. Add to Azure Keyvault with name: "msal-prod-secret-2026-02-26"
4. Set rotation reminder for 90 days

UPDATE APPLICATIONS:
1. Backend application (portal-de-relacionamento-backend)
   - src/config/auth.config.ts (or similar)
   - Update MSAL_CLIENT_SECRET = new secret

2. CI/CD pipelines
   - Azure DevOps → Pipelines → Variables
   - Update MSAL_CLIENT_SECRET variable

3. All environments:
   - DEV: deploy new secret
   - STAGING: deploy new secret
   - PROD: deploy new secret

4. Verify in each environment:
   - Test login flow
   - Test Graph API calls
   - Check application insights for errors

CLEANUP:
- [ ] Delete the old secret (ew5)
- [ ] Delete the suspicious secret (IA_8Q~)
- [ ] Keep only 1 active secret in app
- [ ] Document secret rotation in runbook

TIMELINE:
- T+0: Create new secret + Keyvault entry
- T+2h: Deploy to DEV + test
- T+4h: Deploy to STAGING + full test
- T+6h: Deploy to PROD + monitor
- T+24h: Cleanup old secrets

Ação 2.3 - MySQL RDS Dev Credentials Rotation

# QUEM: DBA + Backend Ops
# QUANDO: Within 24-48 hours
# PRIORIDADE: 🔴 CRÍTICA
# COMPLEXITY: 🟠 HIGH (database is critical)

Current Credentials:
User: dev_admin
Password: sShk9PkdQ35BRilDH0ukREDEDOR
Host: gestao-identidade-dev.cf04evbxtqfl.sa-east-1.rds.amazonaws.com
Port: 3306
Account: 282525845483

IMPACT ANALYSIS:
- Applications accessing this database:
  * gestao-de-identidade-serverless (ECS)
  * portal-de-relacionamento-backend (ECS)
  * Possibly Lambda functions
- Cannot have downtime (medical workflows)
- Requires coordinated rotation

ROTATION PLAN (Dual-User Strategy - Zero Downtime):

Phase 1 - Create new user (T+0):
```bash
mysql -h gestao-identidade-dev.cf04evbxtqfl.sa-east-1.rds.amazonaws.com \
  -u admin \
  -p[master-password] \
  -e "CREATE USER 'dev_admin_new' IDENTIFIED BY '[NEW_RANDOM_PASSWORD_256char]';"

# Grant same permissions as old user
mysql -h gestao-identidade-dev.cf04evbxtqfl.sa-east-1.rds.amazonaws.com \
  -u admin \
  -p[master-password] \
  -e "GRANT ALL PRIVILEGES ON *.* TO 'dev_admin_new'@'%';"

Phase 2 - Update applications (T+2h):

# For each application using dev_admin:
# 1. Update connection string
# 2. Deploy
# 3. Verify connections working

Applications to update:
- gestao-de-identidade-serverless/.env
- portal-de-relacionamento-backend/.env
- AWS Secrets Manager (if used)
- Azure Keyvault (if used)

Phase 3 - Verify and cleanup (T+24h):

# Monitor old user connections
mysql -e "SHOW PROCESSLIST;" | grep dev_admin

# Once no active connections from old user:
# DELETE old user
mysql -u admin -p \
  -e "DROP USER 'dev_admin'@'%';"

DATABASE SECURITY IMPROVEMENTS: - [ ] Enable encryption at rest (RDS parameter group) - [ ] Enable encryption in transit (RDS SSL) - [ ] Restrict security group to only app IPs - [ ] Enable audit logging for DDL/DML - [ ] Rotate master admin password - [ ] Implement least privilege (don't grant ALL on *)

MONITORING: - [ ] CloudWatch: Monitor connection count - [ ] RDS Enhanced Monitoring: CPU, IOPS - [ ] Application logs: Watch for connection errors - [ ] Slow query logs: Look for anomalies

BACKUP: - [ ] Create manual snapshot before rotation - [ ] Keep snapshot for 30 days - [ ] Test restore procedure

### Ação 2.4 - Swagger BasicAuth Rotation

```bash
# QUEM: Backend team
# QUANDO: Within 24-48 hours
# PRIORIDADE: 🟠 ALTA

Current Credentials:
User: S7W1vzE4Xx5scLY1GsKf
Password: $t7N0<\33Ts8

LOCATIONS:
- Swagger/OpenAPI configuration (multiple files?)
- API gateway configuration
- Documentation

ROTATION:

1. Generate NEW credentials:
   User: [random 20 chars]
   Password: [random 32 chars, special chars safe for URLs]

2. Update Swagger configuration:
   - Find all swagger.json, swagger.yaml files
   - Update BasicAuth credentials
   - Commit with new secret in secure storage

3. Update API gateway (if applicable):
   - Kong, AWS API Gateway, etc.
   - Update BasicAuth configuration

4. Update documentation:
   - Internal runbooks
   - API client code (libraries)

5. Notify API consumers:
   - Send email with new credentials
   - Provide secure delivery mechanism (Keyvault URL, encrypted email)

6. Cleanup:
   - Delete old credentials from all locations
   - Verify no old credentials in code

TESTING:
- [ ] Test Swagger endpoint with new credentials
- [ ] Test with old credentials (should fail)
- [ ] Test API calls through Swagger UI

Ação 2.5 - Remaining Secrets Rotation

Secret	Current Value	Rotate By	Responsible
ServiceNow Creds (2x)	y}57}QL)T, 0TykR59NL]!X84T<	T+48h	ServiceNow Admin
CRM Password	503743dE2c124255A395Db53b8757793	T+72h	CRM Admin
Cognito Secret	59r3tknurueajmegi8dme43c9ef9hirfvjg6cdtpb12r7uj4dav	T+72h	AWS Admin
APEX DEV/PRD (2x)	DDc, YP8	T+7d	APEX Admin

---

Fase 3: GIT HISTORY REMEDIATION (Horas 24-72)

Ação 3.1 - Scan Completo com TruffleHog

# QUEM: Security team + Git admin
# QUANDO: T+24h
# PRIORIDADE: 🔴 CRÍTICA

SETUP:
pip install truffleHog3
# ou
git clone https://github.com/trufflesecurity/trufflehog.git
cd trufflehog
go install -v

SCAN CADA REPO:
```bash
# 1. portal-de-relacionamento-backend (3377 commits)
trufflehog git https://dev.azure.com/rededorlabs/portal-de-relacionamento/_git/portal-de-relacionamiento-backend \
  --json > backend-secrets.json \
  --fail --max-depth 1000000

# 2. gestao-de-identidade-serverless (280 commits)
trufflehog git https://dev.azure.com/rededorlabs/gestao-de-identidade/_git/gestao-de-identidade-serverless \
  --json > identidade-secrets.json

# 3. portal-de-relacionamento-frontend (2373 commits)
trufflehog git https://dev.azure.com/rededorlabs/portal-de-relacionamento/_git/portal-de-relacionamento-frontend \
  --json > frontend-secrets.json

# 4-6. Outros repos similarly

ANALISA RESULTADOS:

# Summary
jq '.[] | {repo, secret_type}' backend-secrets.json | sort | uniq -c

# Find commits with secrets
jq '.[] | {commit, secret_match: .matched_string}' backend-secrets.json

EXPECTED FINDINGS: - TOKEN_SECRET (já conhecemos) - MSAL secrets (já conhecemos) - RDS credentials (já conhecemos) - Swagger auth (já conhecemos) - POSSIVELMENTE mais que não foram achadas na scan inicial

ACTION PER SECRET FOUND: 1. Identify commit hash 2. Determine scope: Who has access? 3. Rotate the secret immediately 4. Document in incident report

### Ação 3.2 - Git History Rewrite (Force-Push)

```bash
# QUEM: Git Administrator + Engineering Lead
# QUANDO: T+72h (após todas as credenciais rotacionadas!)
# PRIORIDADE: 🔴 CRÍTICA
# WARNING: Force-push reescreve história público!

PREREQUISITE:
- [ ] Todas as credenciais expostas foram rotacionadas
- [ ] Backup de todos os repos
- [ ] Notificação a ALL developers
- [ ] Coordenado com CI/CD team

PROCEDURE (BFG Repo-Cleaner recommended):

```bash
# 1. Install BFG
brew install bfg  # macOS
# or download from https://rtyley.github.io/bfg-repo-cleaner/

# 2. Clone mirror of each repo
git clone --mirror https://dev.azure.com/rededorlabs/.../_git/portal-de-relacionamiento-backend.git
cd portal-de-relacionamiento-backend.git

# 3. Create secrets.txt com padrões para remover
cat > secrets.txt << 'EOF'
569825f342fae7cae51f7c55fcc805c6
Qjc8Q~qh5ILbrPG71r35Y2U9M53nNMFZSyGi.aOb
sShk9PkdQ35BRilDH0ukREDEDOR
S7W1vzE4Xx5scLY1GsKf
503743dE2c124255A395Db53b8757793
# ... etc
EOF

# 4. Clean repo history
bfg --replace-text secrets.txt portal-de-relacionamiento-backend.git

# 5. Prune reflog
cd portal-de-relacionamiento-backend.git
git reflog expire --expire=now --all
git gc --prune=now --aggressive

# 6. Force-push new history
git push --mirror --force

# 7. Notify developers to re-clone

DEVELOPER NOTIFICATION:

IMPORTANT: Repository history rewritten for security reasons

You MUST re-clone your working repositories:

git clone https://dev.azure.com/rededorlabs/.../_git/portal-de-relacionamiento-backend.git

If you have local commits not yet pushed:
git log origin/main..main  # Shows unpushed commits
# Backup these commits before re-cloning
# Then cherry-pick them to new clone

Do NOT attempt to merge old history back!

VERIFICATION:

# Verify secrets no longer in history
git log --all -S "569825f342fae7cae51f7c55fcc805c6" --oneline
# Should return: fatal: no match

# Verify commits still intact
git log --oneline | wc -l
# Should be ~3377 for backend (minor loss if large files removed)

ROLLBACK PLAN: - [ ] Keep backup of old repos for 30 days - [ ] If force-push causes issues, restore from backup - [ ] Document in runbook

---

## Fase 4: INFRASTRUCTURE HARDENING (Dias 3-30)

### Ação 4.1 - Azure AD Security Policies

```bash
# QUEM: Azure AD Admin
# QUANDO: T+3-7 days
# PRIORIDADE: 🟠 ALTA

IMPLEMENT:

1. Service Principal Password Rotation Policy
   - Azure DevOps → Pipelines → Library → Secure files
   - Set 90-day rotation policy for ALL app secrets
   - Automate rotation using Azure Automation

2. Disable legacy apps
   - Remove apps not used in 30 days
   - Consolidate duplicate apps
   - Require approval for new apps

3. Implement MFA for privileged operations
   - Require MFA to add service principal secrets
   - Require MFA for Directory Write operations
   - Require MFA for Key Vault access

4. Enable Conditional Access
   - Block legacy authentication
   - Require trusted devices for app management
   - Restrict to corporate network IPs

5. Audit and Review
   - Generate report of all 344 apps
   - Identify unused apps for removal
   - Document legitimate secret usage
   - Create exception list for required secrets

CONFIGURATION:
- Azure Portal → Azure AD → Security → Conditional Access
- Create policies:
  * "Require MFA for app secret operations"
  * "Block legacy auth for service principals"
  * "Restrict app registration to whitelisted users"

Ação 4.2 - AWS Account Hardening

# QUEM: AWS Admin
# QUANDO: T+3-7 days
# PRIORIDADE: 🟠 ALTA

IMPLEMENT:

1. RDS Security Groups
   - Restrict access to only app security groups
   - Remove 0.0.0.0/0 access (if currently enabled)
   - Enable encryption at rest + in transit

2. Parameter Store / Secrets Manager
   - Migrate ALL hardcoded secrets to AWS Secrets Manager
   - Enable automatic rotation (90 days)
   - Enable CloudTrail logging for secret access
   - Restrict IAM permissions (least privilege)

3. CloudTrail
   - Enable in all regions
   - Send logs to S3 + CloudWatch
   - Enable log validation
   - Set up alerts for suspicious activities

4. Access Management
   - Review IAM roles for each service
   - Remove unused IAM credentials
   - Implement MFA for admin accounts
   - Enable STS CloudTrail logging

5. Rotate Root Credentials
   - AWS Account 282525845483 (gestao-de-identidade)
   - AWS Account 485245438221 (portal-backend)
   - AWS Account 527905719568 (cinemed-prd)

MONITORING:
- GuardDuty: Enable threat detection
- Config: Compliance monitoring
- Security Hub: Centralized finding management

Ação 4.3 - CI/CD Pipeline Security

# QUEM: DevOps team
# QUANDO: T+7-14 days
# PRIORIDADE: 🟠 ALTA

IMPLEMENT:

1. Secret Detection in Pipelines
   - Add TruffleHog to pre-commit hooks
   - Add GitLeaks to CI/CD pipeline
   - Block commits with detected secrets
   - Setup alerts on detection

2. Secrets Management
   - Remove ALL hardcoded secrets from code
   - Use Azure Keyvault for app secrets
   - Use AWS Secrets Manager for AWS credentials
   - Use Managed Identities where possible

3. Artifact Signing
   - Sign container images in ECR
   - Sign deployment artifacts
   - Verify signatures in pipelines

4. Access Control
   - Require code review for secret changes
   - Limit who can deploy to production
   - Require approval for infrastructure changes
   - Enforce branch protection rules

AZURE DEVOPS CONFIG:
```yaml
# azure-pipelines.yml
trigger:
  - develop
  - main

pr:
  - develop
  - main

jobs:
  - job: SecurityScan
    displayName: 'Secret Detection'
    steps:
      - script: |
          python -m pip install truffleHog3
          trufflehog filesystem . --json > truffle-results.json
          # Fail if high-confidence secrets found
          cat truffle-results.json | jq -e '.[] | select(.verified==true)' && exit 1 || exit 0
        displayName: 'TruffleHog Scan'

GITHUB CONFIG (if using):

# .github/workflows/security.yml
name: Security Scan

on: [push, pull_request]

jobs:
  detect-secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: gitleaks/gitleaks-action@v2
      - name: Prevent Merge on Secret Detection
        if: failure()
        run: exit 1

---

## Fase 5: DETECTION & RESPONSE (Ongoing)

### Ação 5.1 - Monitoring Rules

```bash
# Create alerts in Azure Sentinel / Splunk / CloudWatch

ALERT RULES:

1. "Azure AD App Secret Creation"
   - ANY new app secret created
   - Alert immediately to security team
   - Require approval workflow

2. "Service Principal Graph API Usage"
   - Track all Graph API calls from service principals
   - Alert if calling sensitive APIs (app registration, users, roles)
   - Baseline current legitimate usage first

3. "RDS Unauthorized Access Attempts"
   - Failed login attempts on RDS
   - Access from unknown IPs
   - Queries on sensitive tables (users, passwords)

4. "DevOps Repository Clones"
   - Alert on ALL clone operations
   - Track which repos, which users, which IPs
   - Baseline current legitimate usage

5. "AWS Credential Abuse"
   - CloudTrail alerts for STS assume role calls
   - S3 bucket access patterns
   - EC2/Lambda invocations outside normal hours
   - Spike in API calls

IMPLEMENTATION:
- Azure Sentinel: Use KQL for custom detections
- Splunk: Use SPL for custom searches
- CloudWatch: Use metric alarms + SNS notifications

Ação 5.2 - Incident Response Playbook

# Incident Response Playbook: Secret Exposure

## Detection
- Monitoring rule triggered: [Alert Name]
- Manual report from employee
- Third-party notification (e.g., GitHub, AWS)

## Immediate Actions (0-1 hour)
1. [ ] Confirm secret exposure (verify in codebase/history)
2. [ ] Identify scope: What systems does it access?
3. [ ] Check usage: Is it actively being abused?
4. [ ] Page on-call security engineer
5. [ ] Create incident ticket (PagerDuty/Jira)

## Containment (1-4 hours)
1. [ ] Revoke the secret immediately
2. [ ] Generate new secret
3. [ ] Enable enhanced monitoring for the system
4. [ ] Review access logs for suspicious activity
5. [ ] Determine if other secrets are also exposed

## Investigation (4-24 hours)
1. [ ] Analyze access logs before revocation
   - Who accessed? When? From where?
   - What data was accessed?
2. [ ] Check downstream systems
   - Were credentials used to access other systems?
   - Any lateral movement?
3. [ ] Determine root cause
   - How was it exposed? (git history, logs, configuration)
   - Why wasn't it caught earlier? (code review gap?)
4. [ ] Estimate blast radius
   - How many users/customers affected?
   - What data was exposed?

## Recovery (24-72 hours)
1. [ ] Deploy new credentials
2. [ ] Update all applications using the secret
3. [ ] Test end-to-end workflows
4. [ ] Revert/rollback if needed
5. [ ] Monitor for any issues

## Notification (Timeline)
1. [ ] T+0: Notify security team
2. [ ] T+2h: Notify affected team leads
3. [ ] T+4h: Notify C-level + legal (if data exposure)
4. [ ] T+24h: Notify affected customers (if required by regulation)
5. [ ] T+30d: Post-mortem + lessons learned

## Post-Incident
1. [ ] Root cause analysis
2. [ ] Implement preventive controls
3. [ ] Update runbooks
4. [ ] Schedule training for team
5. [ ] Update threat model

---

Verificação Final (Post-Remediation)

# CHECKLIST:

SECRETS ROTATION:
- [ ] TOKEN_SECRET rotacionado em ambos os repos
- [ ] MSAL Dev revogado
- [ ] MSAL Prod novo secret deployado
- [ ] RDS Dev password alterada (force reconnect)
- [ ] Swagger BasicAuth rotacionada
- [ ] ServiceNow secrets rotacionados
- [ ] CRM password alterada
- [ ] Cognito secret rotacionado
- [ ] APEX secrets rotacionados

GIT CLEANUP:
- [ ] TruffleHog scan completado
- [ ] Todos os secrets identificados
- [ ] Git history rewritten (force-push)
- [ ] Nenhum secret em histórico (reconfirm)
- [ ] Developers re-clonaram repos

AZURE AD:
- [ ] 344 apps auditados
- [ ] Unused apps deletados
- [ ] Secrets rotation policy implementada
- [ ] MFA required for sensitive ops
- [ ] Conditional Access policies enabled

AWS:
- [ ] RDS security groups restringidos
- [ ] All secrets em AWS Secrets Manager
- [ ] CloudTrail enabled em todas contas
- [ ] Root credentials rotacionados
- [ ] GuardDuty + Config enabled

CI/CD:
- [ ] Secret detection em pipelines
- [ ] No hardcoded secrets remaining
- [ ] Code review checklist incluindo secrets
- [ ] Pre-commit hooks enabled

MONITORING:
- [ ] Sentinel alerts configured
- [ ] CloudWatch alarms created
- [ ] Splunk dashboards built
- [ ] On-call rotation updated
- [ ] Incident playbook updated

DOCUMENTATION:
- [ ] Secret rotation runbook updated
- [ ] Architecture diagrams updated
- [ ] Access control matrix updated
- [ ] Incident report completed
- [ ] Post-mortem scheduled

---

Timeline Resumido

Data	Ação	Status
2026-02-26	Revoke MSAL Dev, APEX, PAT	🔴 CRÍTICA
2026-02-26	Enable monitoring	🟠 ALTA
2026-02-27	Rotate TOKEN_SECRET, MSAL Prod, RDS	🔴 CRÍTICA
2026-02-28	TruffleHog scan + git cleanup planning	🟠 ALTA
2026-03-02	Execute git history rewrite	🔴 CRÍTICA
2026-03-05	Rotate remaining secrets	🟠 ALTA
2026-03-12	Azure AD hardening	🟠 ALTA
2026-03-19	AWS hardening	🟠 ALTA
2026-03-26	CI/CD pipeline security	🟠 ALTA
2026-03-31	Post-mortem + lessons learned	🟡 MÉDIA

---

Document Owner: Security Team Last Updated: 2026-02-26 Review Date: Every week during remediation Approval: CISO + CTO + Compliance Officer