Suas credenciais foram roubadas (e você nem sabe)

Suas credenciais foram roubadas (e você nem sabe).

Você é founder de SaaS.

Ontem, relatório anual Verizon (Data Breach Investigations Report) foi lançado.

Relatório analisa: 5.000+ breaches reais (2025-2026).

Pergunta: "Qual é o #1 vetor de ataque inicial?"

Resposta: Credenciais roubadas (ou exploradas).

Número: ~60% de todos os breaches começam com credential theft.

O quê significa?

6 em cada 10 empresas hackeadas começou porque alguém conseguiu senha/token.

Não foi zero-day (vulnerabilidade desconhecida).

Não foi engenharia social sofisticada.

Foi: "Achei senha no GitHub, entrei no seu servidor."

Você:

• Tem agente de IA (rodando em servidor)
• Agente acessa: Banco de dados, API externa, email
• Agente usa: Credenciais (API keys, database passwords, tokens)
• Credenciais são: Hardcoded? No .env? No GitHub (oops)?

Pergunta: Alguém já roubou suas credenciais?

Probabilidade: Sim (se você não tá monitorando).

Sinais: Nenhum (até aparecer breach no news).

Vamos entender: O quê é "identity visibility" e por que importa.

---

O que é identity visibility (e por que você tá fazendo errado)

Entenda: Seu agente tem 10 "identidades"

=== IDENTITY: O QUÊ É? ===

Identity = qualquer coisa que pode acessar seus systems.

Exemplos: ├─ Human: Você (founder), seu time ├─ AI Agent: Seu agente de suporte/vendas ├─ Service: Seu banco de dados, API, webhook ├─ External: Stripe, OpenAI, AWS, ferramentas terceiras ├─ Machine: Servidor, container, serverless function └─ Bot: GitHub Actions, CI/CD pipeline, cron job

Cada identity tem: ├─ Credencial: Password, API key, token, SSH key, certificate ├─ Permissões: O que pode fazer (read, write, delete) ├─ Access log: Histórico de o quê acessou └─ Status: Ativo? Expirado? Comprometido?

=== IDENTITY VISIBILITY: O QUÊ É? ===

Visibility = você sabe TODAS as identidades + credenciais?

Exemplo (seu SaaS):

Identities que você SABE que tem: ├─ Banco de dados (password conhecida) ├─ API Stripe (key em .env) ├─ Seu GitHub repo (token PAT) └─ Email da empresa (password em KeePass)

Identities que você NÃO sabe que tem: ├─ Dev antigo que deixou API key no código ├─ Jenkins job com credencial hardcoded (não atualizado há 2 anos) ├─ Webhook antigo (Stripe, GitHub) usando token expirado (mas still works) ├─ AWS access key criada em 2022 (nunca rotacionada) ├─ Database backup (restaurado em staging, credenciais iguais à produção) ├─ Antiga conta ex-employee (disabled, mas access token still valid) └─ Contractor (precisa acesso ao GitHub, nunca foi removido)

ISSO é lack of identity visibility.

You don't know all credentials. You can't track who accessed what. You can't detect compromise.

=== WHY IT MATTERS ===

Hacker encontra 1 credential: ├─ Old GitHub token (in code history) ├─ Or: Database password in code comment ├─ Or: API key in old Docker image ├─ Or: SSH key in ~/.ssh (unsecured) └─ Result: Hacker tem acesso

With access: ├─ Hacker lists: All files, databases, secrets ├─ Hacker finds: More credentials (cascade) ├─ Hacker exfiltrates: Customer data ├─ Hacker deletes logs: To cover tracks └─ Result: Breach (you don't notice until too late)

=== THE GAP ===

What you think: ├─ "We use strong passwords" ├─ "We have MFA" ├─ "We rotate credentials every 90 days" └─ "We're secure"

What's actually happening: ├─ 47 credentials in production (you know of 5) ├─ 12 are outdated (should be revoked) ├─ 3 are hardcoded in code (accidentally committed) ├─ 8 belong to people who don't work there anymore ├─ 19 have never been rotated (since creation) ├─ Access logs: Not monitored (you don't know who used what) └─ Result: Blind to compromise

---

Por que credenciais roubadas são #1 vetor de ataque

A realidade: Breaches começam simples

=== VERIZON REPORT: TOP INITIAL ACCESS VECTORS ===

1. Stolen/Weak Credentials: 60% ├─ Reason: Easy. Credentials everywhere. ├─ Example: "Found API key in GitHub history" ├─ Time to exploit: 5 minutes └─ Detection: None (if not monitoring)

2. Phishing: 25% ├─ Reason: Social engineering works ├─ Example: Email that looks legit, "click here" ├─ Time to exploit: Depends on victim └─ Detection: Email filter (maybe)

3. Exploitable vulnerability: 10% ├─ Reason: Takes time to find/exploit ├─ Example: Zero-day in your software ├─ Time to exploit: Days/weeks └─ Detection: Anomaly detection (if deployed)

4. Other (supply chain, insider, etc): 5% └─ Complex, rare

=== WHY STOLEN CREDENTIALS IS #1? ===

Easiest path of least resistance: ├─ Hacker: Scans GitHub for "password =", "API_KEY =" ├─ Result: Finds 1000s of credentials (public repos) ├─ Hacker: Tries credentials against your servers ├─ Success rate: ~5-10% (many companies reuse passwords) ├─ Time investment: Low (automated) ├─ Cost: $0 (freely available tools) ├─ Detection risk: Minimal (you're not monitoring) └─ Payoff: Access to production

Compare to zero-day: ├─ Hacker: Spends months finding vulnerability ├─ Time investment: High ├─ Cost: High (specialized knowledge) ├─ Detection risk: High (security researchers also looking) ├─ Payoff: Same (access to production) └─ Rational choice: Stolen credentials (easier)

=== YOUR COMPANY: CREDENTIAL AUDIT ===

How many credentials do you have RIGHT NOW?

Guess: ├─ Database passwords: ? ├─ API keys (external): ? ├─ Internal service tokens: ? ├─ SSH keys: ? ├─ Certificates: ? ├─ OAuth tokens: ? ├─ Employee passwords: ? ├─ Old/legacy credentials (never rotated): ? └─ Total: Probably more than you think

Proof: ├─ Run: git log --all --source -S 'password' -- '*.py' '*.js' '*.env' ├─ Or: grep -r 'API_KEY\|SECRET\|PASSWORD' . ├─ Or: Check AWS IAM (list all access keys) └─ Result: Shockingly many credentials

Example (real SaaS company):

git grep "password" | wc -l

47 matches found 12 in production code 8 in comments 27 in old commits (deleted, but in history)

=== IF HACKER GETS 1 CREDENTIAL ===

Scenario: Hacker finds old GitHub token in code history

1. Access (minutes 0-5) ├─ Token: Still valid (you didn't rotate) ├─ Hacker: Pulls your code repo ├─ Hacker: Finds more credentials in code ├─ Hacker: Gets database password └─ Result: 2 credentials now

2. Lateral movement (minutes 5-30) ├─ Database password: Works (credentials sync'd across env) ├─ Hacker: Connects to database ├─ Hacker: Exports customer data (emails, credit cards) ├─ Hacker: Finds AWS keys in database backups └─ Result: 5 credentials + customer data

3. Persistence (minutes 30-60) ├─ AWS keys: Still valid ├─ Hacker: Creates new IAM user (backdoor) ├─ Hacker: Creates S3 bucket (stores data) ├─ Hacker: Disables logging (to cover tracks) └─ Result: Permanent access

4. Exfiltration (hours 1-24) ├─ Hacker: Downloads all customer data ├─ Hacker: Downloads source code (your IP) ├─ Hacker: Deletes CloudTrail logs (AWS activity) └─ Result: Data breach (you don't notice)

5. Discovery (days/weeks) ├─ You notice: Customer complaints ("My data was sold") ├─ You notice: News article ("YourCompany data breach") ├─ You notice: GDPR/LGPD notice (regulators) ├─ Too late: Damage done └─ Cost: R$50M+ fine + lawsuits

=== THE COMMON EXCUSE ===

You think: "We have MFA, we're safe"

Reality: MFA protects human accounts, not machine-to-machine.

Example: ├─ Database password: No MFA (it's a database) ├─ API key: No MFA (it's an API key) ├─ Token: No MFA (it's a token) └─ Result: Stealing credentials = immediate access

MFA helps: Only when human enters password interactively. MFA doesn't help: Automated systems using credentials.

---

Identity Visibility Framework (como implementar)

5 passos pra ter controle das suas credenciais

=== STEP 1: INVENTORY (discover all identities) ===

Ação 1.1: Code scan bash

Find credentials in code

git log --all --source -S 'password|api_key|secret|token' -- '.py' '.js' '*.env'

Find in current code

grep -r 'password|API_KEY|SECRET|token' . --include=".py" --include=".js"

Check .git history

git log --all --oneline | wc -l

Ação 1.2: Infrastructure audit bash

AWS: List all access keys

aws iam list-access-keys aws iam list-user-access-keys --user-name

GitHub: List all tokens

gh auth token # Current

Manual: Check GitHub Settings > Developer settings > Personal access tokens

Database: List all users

MYSQL: SELECT user FROM mysql.user; POSTGRES: SELECT usename FROM pg_user;

Ação 1.3: Create inventory

Spreadsheet: ├─ Credential type: Database password, API key, SSH key, etc ├─ Owner: Who created it ├─ Purpose: What it's used for ├─ Created: When ├─ Last rotated: When ├─ Expires: When (if ever) ├─ Stored where: Code, .env, Vault, AWS Secrets Manager ├─ Risk level: Low/Medium/High └─ Action: Rotate? Delete? Secure?

Expected result: ├─ You now know: All credentials (approximately) ├─ Shocked: "We have 87 credentials?" ├─ Horror: "12 are 3+ years old" └─ Action: Let's fix this

=== STEP 2: CLASSIFICATION (categorize by risk) ===

High risk (fix immediately): ├─ Credentials in code (GitHub, commits) ├─ Credentials in .env files (version controlled) ├─ Credentials in logs (accidentally printed) ├─ Never rotated (>1 year old) ├─ Belongs to ex-employee ├─ Hardcoded (not in secrets manager) └─ Action: Revoke immediately, create new ones

Medium risk (fix in 30 days): ├─ Credentials not rotated (6+ months) ├─ Belongs to contractor (should be revoked) ├─ Not in secrets manager (but .env only) ├─ Used by multiple people (should be individual) └─ Action: Rotate, move to secrets manager, restrict access

Low risk (monitor): ├─ Recently rotated (<30 days) ├─ In secrets manager ├─ Individual ownership ├─ Proper permissions (least privilege) ├─ Monitored (access logs) └─ Action: Continue monitoring

=== STEP 3: REMEDIATION (fix the high-risk ones) ===

Ação 3.1: Revoke compromised credentials bash

GitHub: Revoke old tokens

gh auth logout

AWS: Delete old keys

aws iam delete-access-key --access-key-id AKIA...

Database: Drop old users

DROP USER 'olduser'@'localhost';

Ação 3.2: Create new credentials (secure) bash

Use secrets manager (not code)

AWS Secrets Manager, HashiCorp Vault, 1Password, etc

Example: Store in AWS Secrets Manager

aws secretsmanager create-secret --name prod/db-password --secret-string ""

Application retrieves at runtime

import boto3 secrets_client = boto3.client('secretsmanager') secret = secrets_client.get_secret_value(SecretId='prod/db-password') db_password = secret['SecretString']

Ação 3.3: Remove from code/logs bash

GitHub: Purge secrets from history

git filter-branch --tree-filter 'rm -f .env' HEAD git push --force-with-lease

Or: Use git-secrets

git secrets --install git secrets --register-aws

=== STEP 4: MONITORING (detect misuse) ===

Quest 4.1: Access logging

Enable logging for all identity access: ├─ Database: Query logs (who accessed what) ├─ API: Request logs (who called API) ├─ AWS: CloudTrail (all API calls logged) ├─ GitHub: Audit logs (who accessed repos) └─ SSH: Syslog (who logged in)

Quest 4.2: Anomaly detection

Set up alerts for: ├─ Credential used from unusual IP ├─ Credential used at unusual time ├─ Credential used for unusual query (e.g., SELECT * FROM customers) ├─ Multiple failed login attempts ├─ Credential access after hours └─ New credential created (should be approved)

Quest 4.3: Tools

Options: ├─ AWS: CloudTrail + EventBridge + SNS (free tier covered) ├─ DataDog: Monitor all access (cost: ~$200/month) ├─ Sumo Logic: Similar to DataDog ├─ Splunk: Enterprise logging (expensive) ├─ DIY: Parse logs, write alerts in Python

=== STEP 5: ROTATION (scheduled refresh) ===

Schedule: ├─ Database passwords: Every 90 days ├─ API keys: Every 180 days ├─ SSH keys: Every 6 months ├─ Certificates: Before expiry (90 days notice) ├─ Employee passwords: Every 90 days (MFA encouraged) └─ Contractor credentials: Upon offboarding (immediate)

Automation: python import schedule import time from aws_secrets import rotate_secret

def rotate_db_password(): rotate_secret(secret_id='prod/db-password') print("Database password rotated")

def rotate_api_keys(): rotate_secret(secret_id='prod/stripe-api-key') rotate_secret(secret_id='prod/openai-api-key') print("API keys rotated")

Schedule

schedule.every(90).days.do(rotate_db_password) schedule.every(180).days.do(rotate_api_keys)

while True: schedule.run_pending() time.sleep(60)

=== BONUS: ZERO-TRUST ARCHITECTURE ===

Princípio: Never trust, always verify.

Applying to credentials: ├─ Don't trust: Credentials in code ├─ Don't trust: Single password ├─ Don't trust: Credentials without MFA ├─ Don't trust: Old/stale credentials ├─ Don't trust: Credentials without encryption

Instead: ├─ Require: Secrets manager (encrypted) ├─ Require: Automatic rotation ├─ Require: Individual credentials (not shared) ├─ Require: Monitoring (all access logged) ├─ Require: Minimal permissions (least privilege) ├─ Require: MFA (when human-facing)

---

Caso real: Como você foi hackeado (e não percebeu)

Timeline típica de breach credential-based

=== YOUR COMPANY: BREACH TIMELINE ===

Month 1: Vulnerability introduced ├─ Dev commits: API key to GitHub (by accident) ├─ PR review: Missed (no code scanning tool) ├─ Merge: Key is now in production repo ├─ You notice: Nothing └─ Hacker notices: Yes (GitHub scrapers scan public repos)

Month 2: Hacker accesses ├─ Hacker: Uses API key to access your system ├─ Hacker: Downloads source code ├─ Hacker: Finds database password in code ├─ Hacker: Accesses production database ├─ You notice: Nothing (no monitoring) └─ Hacker: Exfiltrates customer data (10GB)

Month 3: Hacker covers tracks ├─ Hacker: Deletes logs (CloudTrail, database logs) ├─ Hacker: Disables CloudWatch alarms (to avoid alerts) ├─ Hacker: Exits ├─ You notice: Nothing └─ Database size: Inexplicably decreased (logs deleted)

Month 4: You get hacked (but don't know yet) ├─ You: Continue business normally ├─ Customers: Data being sold on dark web ├─ You notice: Nothing └─ Damage: R$100M+ (if big customer list)

Month 5: Discovery ├─ News article: "Customer data from [YourCompany] found for sale" ├─ You: "Wait, that's our data?" ├─ Regulators: GDPR/LGPD notice (breach investigation) ├─ Customers: Lawsuits (unauthorized data disclosure) ├─ You notice: Now it's too late └─ Damage: R$50M fine + lawsuits + reputation

=== HOW MUCH DID IT COST TO PREVENT? ===

Preventive measures: ├─ Code scanning tool (GitGuardian, TruffleHog): R$50/month ├─ Secrets manager (AWS Secrets Manager): Free tier included ├─ Monitoring (CloudTrail): Free tier included ├─ Team training: R$5k (one-time) ├─ Process (credential rotation automation): R$10k (dev time) └─ Total: ~R$20k (one-time) + R$600/year

Cost of breach: ├─ GDPR/LGPD fines: R$50M+ (yes, really) ├─ Lawsuit settlements: R$5-20M ├─ Reputation damage: Lost customers, 30-50% revenue drop ├─ Incident response (lawyers, forensics): R$500k-2M └─ Total: R$60M+

ROI: Invest R$20k to prevent R$60M loss = 3000x return.

---

Ações imediatas

Do hoje pra semana que vem

☐ Day 1: Run credential audit (grep, git log, AWS IAM list) ☐ Day 1: Create inventory (spreadsheet of all credentials) ☐ Day 2: Classify by risk (which ones are urgent?) ☐ Day 3: Revoke high-risk credentials (GitHub tokens, old keys) ☐ Day 4: Set up secrets manager (AWS Secrets Manager, Vault, 1Password) ☐ Day 5: Move credentials to secrets manager (not code) ☐ Day 5: Enable logging (CloudTrail, database audit logs) ☐ Day 5: Set up monitoring (alerts for unusual access) ☐ Week 2: Automation (credential rotation script) ☐ Week 2: Team training (how to handle credentials safely)

---

Conclusão

Verizon: Credenciais roubadas = 60% de todos os breaches.

Realidade: Você tem credenciais em código, sem rotação, sem monitoramento.

Pergunta: Quando será hackeado?

Resposta: Provavelmente já foi (você só não sabe).

Identity Visibility = Controle total das suas credenciais:

1. Inventory: Descubra todas as credenciais (hoje)
2. Classification: Priorize as mais perigosas
3. Remediation: Revogue/rotacione as altas-risco
4. Monitoring: Detecte uso anômalo em tempo real
5. Rotation: Atualize automaticamente (90 dias)

Investimento: R$20k-50k (setup) + R$1k/mês (operação)

Benefício: Prevenir breach = R$50M+ loss avoided

ROI: 2500x+

Na OpenClaw, ajudamos SaaS builders implementar identity visibility:

• Credential Audit: Você tem quantas credenciais? Quais estão expostas?
• Inventory Management: Organize + classify todas as identidades
• Secrets Manager Setup: AWS Secrets Manager, Vault, 1Password
• Monitoring & Alerting: Detecte compromisso em tempo real
• Rotation Automation: Script para rotacionar automaticamente
• Zero-Trust Architecture: Framework completo pra identity security
• Compliance Roadmap: GDPR/LGPD/SOC 2 compliance pra credentials

Implemente identity visibility | Credential Security + Monitoring →