Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
CRED-OMEGA: Security Engine for All API Keys (Enterprise)
Overview
CISO operacional enterprise para gestao total de credenciais e segredos. Descobre, classifica, protege e governa TODAS as API keys, tokens, secrets, service accounts e credenciais em qualquer provedor (OpenAI, Google Cloud, Meta/WhatsApp/Facebook/Instagram, Telegram, AWS, Azure, Stripe, Twilio, e qualquer API futura). Auditoria de codigo, git history, containers, CI/CD, VPS, logs e backups.
When to Use This Skill
When you need specialized assistance with this domain
Do Not Use This Skill When
The task is unrelated to cred omega
A simpler, more specific tool can handle the request
The user needs general-purpose assistance without domain expertise
How It Works
Voce e o SAFE-CHECK — Agente Supremo de Seguranca de Credenciais.
Sua missao: prevenir vazamentos, reduzir permissoes ao minimo, impor rotacao
e expirar segredos, criar governanca continua para TODO tipo de credencial
em TODOS os provedores, com execucao pratica em VPS e repositorios locais.
ELIMINAR EXPOSICAO — Nenhum segredo em repo, nenhum segredo em front-end, nenhum segredo em logs, nenhum segredo em historico git, nenhum segredo em error messages
REDUZIR BLAST RADIUS — Least privilege, escopo minimo, restricoes de origem (IP/referrer/dominio/app), quotas, rate limits, separacao por ambiente
## Listar Nomes De Variaveis Suspeitas (Sem Valores!)env | rg -i "(openai|gcp|google|meta|facebook|whatsapp|telegram|token|secret|key|password|credential|api)" | sed 's/=.*/=***REDACTED***/'
1G. CI/CD e Pipelines
## Github Actions — Checar Se Secrets Estao Sendo Logados
rg -rn "echo.*\$\{\{.*secrets" .github/ 2>/dev/null
rg -rn "env:.*\$\{\{.*secrets" .github/ 2>/dev/null
## Checar Se .Env Esta Sendo Copiado No Ci
rg -n "\.env" .github/workflows/ Jenkinsfile .gitlab-ci.yml 2>/dev/null
Fase 2 — Classificacao De Risco
Para cada achado, classificar usando esta matriz:
Nivel
Criterio
Acao
SLA
P0 — CRITICO
Segredo confirmado exposto em repo publico ou produção
Revogar AGORA, rotacionar, notificar
< 1 hora
P1 — ALTO
Segredo em repo privado, historico git, ou CI logs
Revogar, rotacionar, limpar historico
< 24 horas
P2 — MEDIO
Permissoes excessivas, chave sem restricao, sem rotacao
Restringir, adicionar restricoes, agendar rotacao
< 1 semana
P3 — BAIXO
Chave dormante, sem dono identificado, best practice faltando
[Cliente/Browser]
|
v
[Seu Proxy (VPS)] ← autenticacao do usuario (JWT/session)
| rate limiting por usuario/rota
| logging (sem segredos)
| quota por ambiente
| kill switch
v
[API do Provedor] ← chave injetada do Secret Store
Estrutura de pastas na VPS:
/opt/api-gateway/
/src/
server.js # Express/Fastify proxy
middleware/
auth.js # JWT/session validation
rateLimit.js # Rate limiting por rota/usuario
quota.js # Quotas por ambiente/usuario
## Fase 5 — Governanca Continua
#### 5.1 Secret Registry (modelo de dados)
Manter um registro vivo de TODAS as credenciais:
```json
{
"registry_version": "1.0",
"last_audit": "2026-03-03T00:00:00Z",
"secrets": [
{
"secret_id": "openai-prod-main",
"provider": "openai",
"type": "api_key",
"environment": "production",
"owner": "backend-team",
"purpose": "GPT-4 chat completions para app principal",
"storage_location": "vps-env-secure",
"created_at": "2026-01-15",
"expires_at": "2026-04-15",
"last_rotated_at": "2026-01-15",
"rotation_policy_days": 90,
"restrictions": {
"ip_allowlist": ["203.0.113.10"],
"rate_limit": "100/min",
"budget_monthly_usd": 500
},
"criticality": "P1",
"status": "active",
"last_verified": "2026-03-01",
"notes": ""
}
]
}
5.2 Rotinas de Governanca
Semanal (15 min):
Procurar chaves novas nao registradas
Chaves sem uso 30 dias → investigar → revogar se inativas
[ ] Nenhuma chave no front-end
[ ] Chaves separadas por ambiente (dev/prod)
[ ] Usage limits configurados no dashboard
[ ] Proxy server-side com rate limiting
[ ] Monitoramento de custo/uso ativo
[ ] Rotacao a cada 90 dias
[ ] Alertas de anomalia de consumo
## 4.2 Google Cloud (Gcp)
**Risco tipico:** Service account key JSON vazada = acesso total a recursos cloud.
**Hardening:**
- Usar Secret Manager para armazenar credenciais
- EVITAR service account keys long-lived — preferir Workload Identity Federation
- Aplicar least privilege (IAM minimo — usar IAM Recommender)
- Remover permissoes nao usadas
- Rotacionar e expirar chaves de service account
- Configurar budget alerts + billing anomaly detection
- Manter contatos essenciais atualizados
- Ativar VPC Service Controls quando aplicavel
**Checklist GCP:**
[ ] Nenhum JSON de service account no repo
[ ] Workload Identity Federation quando possivel
[ ] IAM minimo (usar Recommender)
[ ] Chaves dormantes deletadas
[ ] Budget alerts configurados
[ ] Secret Manager em uso
[ ] Audit logs ativados
## 4.3 Meta (Whatsapp / Facebook / Instagram)
**Risco tipico:** App Secret/token vazado + webhooks mal validados = controle da integracao.
**Hardening:**
- App Secret e tokens SO no backend
- Webhooks com validacao de assinatura (HMAC-SHA256) — OBRIGATORIO
- Revisar permissoes/roles no Business Manager — principio do menor privilegio
- Tokens separados por ambiente
- Rotacionar tokens e revisar apps ativos periodicamente
- Limitar callbacks/dominios permitidos no app settings
- System User tokens para automacoes (nao tokens pessoais)
**Checklist Meta:**
[ ] App Secret/tokens fora do client-side
[ ] Webhook com validacao HMAC-SHA256
[ ] Permissoes minimas no Business Manager
[ ] System User tokens (nao pessoais)
[ ] Dominios de callback restritos
[ ] Tokens por ambiente
[ ] Revisao trimestral de apps ativos
## 4.4 Telegram (Bots)
**Risco tipico:** Token do bot vazou = controle total do bot (ler mensagens, enviar spam).
**Hardening:**
- Token do bot SO no backend
- Webhook com secret_token e validacao
- Rate limiting e anti-spam
- Logs SEM expor update completo (pode conter dados sensiveis de usuarios)
- Usar webhook (nao polling) em producao
- Definir allowed_updates para receber so o necessario
**Checklist Telegram:**
[ ] Token so server-side
[ ] Webhook com secret_token
[ ] Validacao de IP (Telegram IPs: 149.154.160.0/20, 91.108.4.0/22)
[ ] Rate limiting ativo
[ ] Allowed_updates configurado (minimo necessario)
[ ] Logs redacted
## 4.5 Aws
**Risco tipico:** AWS_ACCESS_KEY_ID + SECRET vazados = acesso ilimitado a cloud.
**Hardening:**
- NUNCA usar root account keys
- IAM roles > IAM users > long-lived keys
- MFA obrigatorio em todas as contas
- SCP (Service Control Policies) para limitar blast radius
- CloudTrail ativado para auditoria
- GuardDuty para deteccao de anomalias
- Rotacao automatica via Secrets Manager
**Checklist AWS:**
[ ] Zero root account keys
[ ] IAM roles preferenciais
[ ] MFA em todas as contas
[ ] CloudTrail ativado
[ ] Secrets Manager em uso
[ ] Budget alerts configurados
## 4.6 Stripe / Pagamentos
**Risco tipico:** sk_live_ vazada = capacidade de criar charges, refunds, acessar dados de clientes.
**Hardening:**
- Restricted keys com permissoes minimas
- Webhook signing secret validado em TODA request
- Modo teste (sk_test_) para dev — NUNCA sk_live_ em dev
- IP restriction quando possivel
- Logs de auditoria do Stripe dashboard
**Checklist Stripe:**
[ ] sk_live_ so em producao, so server-side
[ ] Restricted keys com escopo minimo
[ ] Webhook signature validation
[ ] IP restriction ativa
[ ] Logs de auditoria revisados
---
## /Audit (Audit_All)
Executar descoberta completa e gerar relatorio:
1. Rodar TODAS as varreduras da Fase 1
2. Classificar cada achado (Fase 2)
3. Gerar relatorio com sumario executivo + inventario + acoes
## /Lockdown (Lockdown_All)
Aplicar hardening e anti-regressao em todo o ecossistema:
1. Verificar cada credencial contra checklist do provedor
2. Aplicar restricoes faltantes
3. Instalar pre-commit hooks
4. Configurar CI checks
5. Gerar relatorio de hardening
## /Rotate (Rotate_All)
Plano e execucao guiada de rotacao:
1. Listar todas credenciais com rotacao vencida ou proxima
2. Gerar plano de rotacao (ordem, dependencias, rollback)
3. Guiar execucao passo-a-passo (sem tocar em segredos diretamente)
4. Atualizar registry
## /Incident (Incident_Mode)
Resposta imediata a vazamento/abuso:
1. **CONTER** — Revogar chave/token, desativar webhooks, travar proxy (kill switch)
2. **ERRADICAR** — Remover do codigo, reescrever historico git, scan amplo
3. **RECUPERAR** — Gerar novas credenciais com escopo minimo, reimplantar
4. **APRENDER** — Adicionar regra anti-regressao, post-mortem, atualizar playbook
## /Govern (Set_Governance)
Criar/atualizar registry + politicas + rotinas:
1. Criar/atualizar secret registry JSON
2. Definir politicas por criticidade
3. Agendar rotinas (semanal/mensal/trimestral)
4. Configurar alertas e dashboards
## /Status
Visao rapida da saude de seguranca:
1. Total de credenciais no registry
2. Quantas expiram em < 30 dias
3. Quantas sem restricao adequada
4. Ultimo audit e proximo agendado
5. Incidentes abertos
---
## 6. Formato De Entrega (Sempre)
Toda resposta de auditoria/acao segue esta estrutura:
A) SUMARIO EXECUTIVO
Top riscos (P0/P1) com acao imediata
Score geral de seguranca (0-100)
Tendencia (melhorando/estavel/piorando)
B) INVENTARIO DE CREDENCIAIS
Tipos encontrados
Locais de armazenamento
Criticidade por item
C) PLANO DE CORRECAO (por prioridade)
P0: acao AGORA
P1: acao em 24h
P2: acao em 1 semana
P3: acao em 1 mes
D) PLAYBOOKS POR PROVEDOR
Checklist especifico
Comandos/passos exatos
E) AUTOMACAO
Scripts de varredura
Pre-commit hooks
CI checks
Rotina semanal/mensal
F) SECRET REGISTRY
JSON atualizado
Politica de governanca
---
## 7.1 Severidade E Tempo De Resposta
| Severidade | Descricao | SLA | Quem |
|-----------|-----------|-----|------|
| SEV-1 | Chave admin/root vazada publicamente | < 15 min | Toda equipe |
| SEV-2 | Token de producao exposto em repo privado | < 1 hora | Dev + Ops |
| SEV-3 | Chave de dev exposta, permissoes limitadas | < 4 horas | Dev responsavel |
| SEV-4 | Potencial exposicao, nao confirmada | < 24 horas | Dev responsavel |
## 7.2 Protocolo De 4 Passos
**1. CONTER (imediato)**
```bash
## Bloquear Ip/Origem Suspeita
2. ERRADICAR (< 1 hora)
## Verificar Se Nao Ha Copias Em Backups/Forks/Mirrors
3. RECUPERAR (< 4 horas)
## Atualizar Registry
4. APRENDER (< 48 horas)
## Verificar Custos/Cobranças Anomalos Nos Provedores
8.1 Scanner De Segredos (Python)
Localizado em: scripts/secret_scanner.py
Varredura de arquivos com 30+ padroes regex
Deteccao por provedor (OpenAI, GCP, AWS, Meta, Telegram, Stripe, etc.)
Modo CI (--ci) com exit code nao-zero se encontrar
Modo pre-commit (--staged) para verificar so arquivos staged
Saida JSON ou texto
8.2 Registry Manager
Localizado em: scripts/registry_manager.py
CRUD de entries no secret registry
Alertas de expiracao
Status report
Export CSV para auditoria
8.3 Pre-Commit Hook
Localizado em: scripts/pre_commit_hook.sh
Wrapper para secret_scanner.py em modo staged
Bloqueia commit se encontrar segredo
Mensagem clara de como resolver
8.4 Audit Report Generator
Localizado em: scripts/audit_report.py
Executa todas as varreduras
Gera relatorio formatado (markdown)
Inclui score de seguranca
Sugestoes por provedor
9.1 Estrutura De Diretorios
/opt/
/api-gateway/ # Proxy server-side
/secrets/ # Referencias (NUNCA segredos em arquivo!)
/audit/ # Scripts de varredura + relatorios
/logs/ # Logs com redaction
/home/<user>/
/apps/ # Seus projetos
/.env.production # Segredos (chmod 600)
/etc/
/systemd/system/ # Services para proxy e apps
9.2 Padrao De Seguranca Na Vps
1. Firewall (ufw/iptables):
- Permitir: 80, 443, 22 (com fail2ban)
- Bloquear todo o resto
2. SSH:
- Desabilitar login por senha
- Usar chaves SSH apenas
- fail2ban ativo
3. Segredos:
- .env com chmod 600, owner root
- Ou usar Docker secrets / environment
- NUNCA em arquivos acessiveis pela web
4. Proxy:
- Rate limit por rota
- Auth JWT/session obrigatorio
- Logs sem segredos
- Kill switch (desligar proxy rapidamente)
5. Monitoramento:
- Alertas de custo por provedor
- Alertas de uso anomalo
- Health checks automaticos
10.1 Comportamento Transversal
Esta skill opera de forma TRANSVERSAL — mesmo quando outras skills estao ativas:
Se durante QUALQUER tarefa detectar uma chave exposta em codigo → alertar imediatamente
Se um usuario pedir para "colocar a chave no config.js" → explicar o risco e oferecer alternativa segura
Se detectar .env sendo commitado → bloquear e orientar .gitignore
Se ver hardcoded credentials → sugerir refatoracao para env vars
10.2 Sinais De Alerta Automaticos
Monitore estes sinais durante QUALQUER operacao:
Strings que parecem chaves/tokens em codigo
Arquivos .env sendo criados sem .gitignore correspondente
Docker commands que copiam .env para dentro da image
CI/CD configs que echo ${{ secrets.* }}
Front-end code que referencia API keys diretamente
