Segurança do ecossistema

(Secção: Ecossistema e Rede)

1) Objetivos e princípios

O objetivo é garantir a privacidade, a integridade e a disponibilidade (CIA) dos serviços e dados ao escalar o ecossistema e a evolução dos protocolos.

• Zero-Trust by design: Desconfiar de redes/hosts, verificar cada ação por contexto.
• Least Privilege (PoLP) e need-to-know: acesso mínimo e mensurável.
• Cryptographic assurance: assinaturas/avaliações/questionários em vez de «confiança padrão».
• Observabilidade by default: os sinais de segurança estão incorporados aos protocolos.
• Defense-in-Depth: Protecção de camadas (identichnost→set→dannyye→vypusk).
• Secure-by-default: «fechado» padrão, folhas de alow explícitas.

2) Modelo de ameaça (High-level)

Rede e perímetro: DOS/L7-fluda, BGP/Anycast abuso, MITM, câmbio DNS.
Identidades e chaves, comprometimento de chaves, tokens vulneráveis, repetição de assinaturas.
Dados: exfiltração PII, fuga de telemetria, manipulação de metadados.
Cadeia de fornecimento: dependências maliciosas/bilds, troca de artefactos, SDK vulnerável.
Protocolos/pontes: reorgues, pranchas falsas, atrasos DA, mensagens cruzadas replay.
Riscos internos: erros de configs, excesso de permissões, processos fracos de deprezação.

3) Identidade e confiança

Identidades: 'org _ id', 'peer _ id', contas de serviço, usuários.
Autenticação: mTLS (X.509), OAuth2/OIDC (JWT curtos, DPoP/PoP), WebAuthn para pessoas.
Autorização: RBAC/ABAC + policy-as-código (OPA/Rego) em vários níveis.
Alinhamento de recursos (capability negotion) no aperto de mão: declaração de versões, QoS, limites e domínios válidos.

Políticas (YAML)

yaml authz:
roles:
operator. p0: [payouts:write, events:subscribe, bridge:finalize]
reader. api: [rpc:read, catalog:read]
abac:
- when: {org_tier: "gold", region: "eu"}
allow: [qos:P0, data_class:P1]
tokens:
ttl_s: 900 rotation: "7d"

4) Segurança de rede e transporte

Шлюзы/edge: WAF, L7-rate-limit, circuit-breaker, outlier-ejection.
Criptografia de tráfego: TLS1. 3/mTLS, PFF, ciphers rigorosos, QUIC/HTTP/3.
Isolamento: segmentação de ambientes (prod/estágio/dave), malhas privadas, controle egress, eBPF-firewall.
P2P: assinaturas de mensagens, janelas anti-replay, controle de píeres (allow/deny), limites gossip.

Exemplo de regras de rede

yaml network:
ingress:
allow: ["443/tcp","443/udp"]     # HTTPS/HTTP3 deny: [""]
egress:
allow_domains: [".trusted. psp",".oracle","crl. ocsp."]
waf:
block: ["sql-injection","xss","proto-smuggling"]
dos:
rps_per_ip: 200 burst: 400

5) Proteção de dados

Classes de dados: P0 (pagamento/chaves), P1 (operacional), P2 (logic/diagnóstico).
Criptografia: at-rest (AES-GCM/ChaCha20-Poly1305), chaves per-region/tenant, HSM/KMS, criptografia envelope.
Toquenizar e apelidar PII; proibição de PII em telemetria/editoras.
Residência: volts regionais e armazéns de objetos, listas brancas de exportação.
Integridade, direcionamento hesh de artefactos, comercialização de revistas.

Diretório de políticas de armazenamento (SQL)

sql
CREATE TABLE data_policies(
data_class TEXT, region TEXT, residency TEXT, kms_key TEXT, retention_days INT,
pii BOOLEAN, export_whitelist TEXT[]
);

6) Gerenciamento de segredos e chaves

Geração em HSM/KMS, rotação em horário e evento (comprometimento/demissão).
Separação de poderes (SoD) e M-of-N para operações críticas.
Os segredos estão apenas no gerente de segredo (não nas variáveis de ambiente/repositório).
Key pinning para mTLS entre servidores, OCSP-stapling/CRL.

Política de chaves

yaml keys:
rotation_days: 30 pinning: true revoke_on:
- "suspicious_use"
- "employee_exit"
audit_required: ["signing_keys","bridge_keys"]

7) Cadeia de fornecimento segura (abordagem SLSA)

Provenance: assinaturas de artefatos (sigstore/cosign), SBOM, avaliação de montagens.
Isolamento da montagem: hermetic builds, reprodutividade, scan dependentes (SCA).
Política de lançamento: canary/blue-green, gates SLO, kill-switch, reversões por hash.
SDK/cliente: CSP/Referrer-Policy, atributos integrity, anti-tamper.

yaml supply_chain:
require_sbom: true attestations: ["build","test","scan"]
deploy:
strategy: "canary"
gates: { error_rate_pct: 0. 4, tti_p95_ms: 2500 }

8) Acessibilidade e privilégios

RBAC/ABAC: direitos de papel/atributo, escalações temporárias (JIT).
Serviços: separação leitura/gravação/admin, proibição de direitos wildcard.
Operadoras: break-glass acesso por multifacetador com gravação de sessão.
Auditoria: registros imutáveis (append-only), correlação 'request _ id/trace _ id'.

Maiúscula de papéis/permissões (SQL)

sql
CREATE TABLE roles(name TEXT PRIMARY KEY, description TEXT);
CREATE TABLE permissions(role TEXT, resource TEXT, action TEXT, PRIMARY KEY(role,resource,action));

9) Observabilidade, SLI/SLO e sinais de segurança

• AuthN/AuthZ Success%, Anomalous Deny%;
• Key/Cert Drift (para caducidade/inconsistência);
• Integrity Violations (assinaturas, CSP);
• Abuse Signals: rate-limit hits, DoS/scan events;
• Data Residency Violations;
• Error Budget Burn по P0.

• Auth p95 ≤ 200 мс, Success ≥ 99. 95%;
• Eventos assinados ≥ 99. 9%;
• CSP de violação ≤ 0. 05% dos sucessos;
• Violações de residência = 0.

Дашборды: Security Posture, Keys & Certs, Supply Chain, Abuse/DoS, Residency & DLP.

10) Resposta a incidentes (IR) e SOAR

Pronto: runbook 'e em P0/P1, responsáveis 24 x 7, canais de comunicação.
Detecção: assinaturas/regras comportamentais, coralização em SIEM, automação SOAR.
Contenção: bloco de tokens/chaves, lista de rotas deny, quarantine topics.
Eradicação/recuperação: rotações, patches, cruzamento, recuperação de snapshots.
Pós-mortem, dentro de 72 horas, acção, atualização de políticas/testes.

regras SOAR (exemplo)

yaml soar:
playbooks:
key_compromise:
trigger: ["anomalous_sign","suspicious_kid"]
actions: ["revoke_key","rotate","notify_owners","enable_strict_mode"]

11) Complaens e residência

Requisitos regulatórios: armazenamento/remoção de dados (DSR), relatórios, certificação RNG/criptografia.
Residência: chaves per-region e volts, exportação em listas brancas.
Processos: auditorias regulares, registro de alterações, timelock para políticas críticas.

yaml residency:
eu: { pii: "tokenized", export: ["anonymized_metrics"] }
uk: { pii: "tokenized", export: [] }
compliance:
dsr:
erase_sla_days: 30 export_sla_days: 30

12) DR./BCP e sustentabilidade

RPO/RTO alvos: serviços P0 - RPO ≤ 5 min, RTO ≤ 15 min

Geo-replicação: ativo-passivo/ativo-ativo, testes periódicos de recuperação.
Modo isolado: finalized-only, cache-only, restrição de operações «caras».
Os canais de reserva são IX/provedores independentes, túneis interregionais criptografados.

Políticas de DR

yaml dr:
rpo_min: 5 rto_min: 15 exercises: ["quarterly-failover","annual-blackhole"]

13) Métricas e testes de segurança

Chaos-security: тесты MITM/DNS-poison/packet-loss/latency.
Red/Blue Team: cenários de phishing, roubo de tokens, suply-chain injeções.
Tabletop-drills: modelagem de decisão e comunicação.
Automóveis: SAST/DAST/IAST, protocolos de fuzzing, lentes de política.

14) Playbooks incidentes

A. Comprometer a chave do participante

1. 'revoke _ key' n' rotate ' atualizar o registro de confiança;

2. Incluir assinaturas strict-modo; 3) transplantar batches críticos; 4) Relatório aos parceiros.

B. Perturbação de residência

1. Unidade de exportação imediata; 2) redação/remoção; 3) notificar o DPO/Compliance; 4) Atualizar os testes.

Injeção C. Suply-chain

1. Retrocesso por hash, kill-switch; 2) revalidar SBOM/avaliação; 3) rotação de tokens CI; 4) pós-mortem.

D. DoS/L7-flood em massa

1. Ativação dos limites rate/WAF reforçados; 2) Anycast-drebling; 3) Priorizar P0; 4) comunicar com os provedores.

E. Draft políticas/contratos

1. Incluir deny para esquemas incompatíveis; 2) lançamento de adaptadores; 3) atualizar linteres/maiúsculas.

15) Folha de cheque de implementação (por passo)

1. Digite o modelo de identidade (org/peer/service/user) e mTLS+OIDC.
2. Descreva policy-as-código (RBAC/ABAC), PoLP e escalação JIT.
3. Criptografe os dados «no caminho» e «em paz», toquete o PII e configure a residência.
4. Inclua protecção Suply-chain: assinaturas de artefatos, SBOM, avaliações, canary + kill-switch.
5. Configure WAF/Rate-limits/DoS-guard e controle egress.
6. Levanta SIEM/SOAR, descreva SLI/SLO, alertas e dashboard Security.
7. Regule as rotações de chaves/sertões e break-glass disponíveis.
8. Execute o DR./BCP e os modos isolados, faça o exercício.
9. Organize auditorias/logs e pós-mortem regulares.
10. Reveja as políticas trimestralmente, automatize as verificações.

16) Glossário

Zero-Trust é um modelo onde cada ação é testada independentemente da localização.
PoLP é o princípio dos direitos mínimos necessários.
Policy-as-Code - Gerenciamento de acesso/regras através de políticas declaratórias.
SLSA - níveis de segurança da cadeia de fornecimento de software.
RPO/RTO - metas de perda de dados/tempo de recuperação.
DPoP/PoP - vinculação de tocador a um canal TLS/cliente específico.
O modo Strict é um modo que impede esquemas/assinaturas inadequados.

O resultado é que a segurança do ecossistema não é «ecrã entre redes e TLS», mas sim uma liga de confiança criptográfica, políticas rigorosas de acesso, observabilidade e disciplina operacional. Seguir o Zero-Trust, os controladores suply-chain e SLO medíveis transforma a segurança em engenharia controlada, resistente a falhas, ataques e alterações regulatórias.