Sécurité de l'écosystème

(Section : Écosystème et réseau)

1) Objectifs et principes

L'objectif est de garantir la confidentialité, l'intégrité et la disponibilité (CIA) des services et des données lors de la mise à l'échelle de l'écosystème et de l'évolution des protocoles.

• Zero-Trust by design : méfiez-vous des réseaux/hôtes, vérifiez chaque action par contexte.
• Least Privilège (PoLP) et need-to-know : l'accès est minimal et mesurable.
• Cryptographic assurance : signatures/attestations/ancres au lieu de « approbation par défaut ».
• Observability by default : les signaux de sécurité sont intégrés dans les protocoles.
• Défense-in-Depth : protection en couches (identichnost→set→dannyye→vypusk).
• Secure-by-default : « fermé » par défaut, feuilles d'allow explicites.

2) Modèle de menace (haut niveau)

Réseau et périmètre : DoS/L7-fluds, BGP/Anycast abus, MITM, remplacement DNS.
Identités et clés : compromission des clés, tokens vulnérables, répétition des signatures.
Données : exfiltration PII, fuite de télémétrie, manipulation de métadonnées.
Chaîne d'approvisionnement : dépendances malveillantes/billets, échange d'artefacts, SDK vulnérable.
Protocoles/ponts : réorgues, faux proufs, retards DA, replay de messages croisés.
Risques internes : erreurs de configus, droits excédentaires, processus de déprécation faibles.

3) Identité et confiance

Identités : 'org _ id', 'peer _ id', comptes de service, utilisateurs.
Authentification : mTLS (X.509), OAuth2/OIDC (JWT à courte durée de vie, DPoP/PoP), WebAuthn pour les personnes.
Autorisation : RBAC/ABAC + policy-as-code (OPA/Rego).
Négociation des capacités (capability negotiation) lors de la poignée de main : déclaration des versions, QoS, limites et domaines valides.

Politique (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) Sécurité du réseau et transport

Шлюзы/edge: WAF, L7-rate-limit, circuit-breaker, outlier-ejection.
Cryptage du trafic : TLS1. 3/mTLS, PFS, rigoureux ciphers, QUIC/HTTP/3.
Isolation : segmentation des environnements (prod/stage/dev), grilles privées, contrôle egress, firewall eBPF.
P2P : signatures de message, fenêtre anti-replay, contrôle des pyres (allow/deny), limites gossip.

Exemple de règles réseau

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) Protection des données

Classes de données : P0 (paiement/clés), P1 (opération), P2 (journal/diagnostic).
Cryptage : at-rest (AES-GCM/ChaCha20-Poly1305), clés per-region/tenant, HSM/KMS, encryptage envelope.
Tokénisation et pseudonyme du PII ; interdiction des PII en télémétrie/labels.
Résidence : volts régionaux et entrepôts d'objets, listes blanches d'exportations.
Intégrité : adressage hash des artefacts, merclisation des journaux.

Répertoire des stratégies de stockage (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) Gestion des secrets et des clés

Génération en HSM/KMS, rotation selon l'horaire et l'événement (compromission/licenciement).
Séparation des pouvoirs (SoD) et M-of-N pour les opérations critiques.
Secrets uniquement dans le gestionnaire secret (pas dans les variables d'environnement/référentiels).
Key pinning pour les mTLS interservices, OCSP-stapling/CRL.

Stratégie de clé

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

7) Chaîne d'approvisionnement sécurisée (approche SLSA)

Provenance : signatures d'artefacts (sigstore/cosign), SBOM, attestations d'assemblages.
Isolation de l'assemblage : constructions hermétiques, reproductibilité, scan de dépendances (SCA).
Politique de release : canary/blue-green, SLO-gates, kill-switch, retouches de hachage.
SDK/client : CSP/Referrer-Policy, attributs 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) Accès et privilèges

RBAC/ABAC : droits par rôle/attributs, escalade temporelle (JIT).
Services : délimitation lecture/écriture/admin, interdiction des droits wildcard.
Opérateurs : accès break-glass par multifacteur, avec enregistrement de session.
Audit : journaux immuables (append-only), corrélation "request _ id/trace _ id'.

Registre des rôles/droits (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) Observabilité, SLI/SLO et signaux de sécurité

• AuthN/AuthZ Success%, Anomalous Deny%;
• Key/Cert Drift (à l'expiration/incohérence) ;
• Integrity Violations (signatures, CSP) ;
• Abuse Signals: rate-limit hits, DoS/scan events;
• Data Residency Violations;
• Error Budget Burn по P0.

• Auth p95 ≤ 200 мс, Success ≥ 99. 95%;
• Événements signés ≥ 99. 9%;
• CSP des infractions ≤ 0. 05 % des succès ;
• Irrégularités de résidence = 0.

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

10) Intervention en cas d'incident (IR) et SOAR

Prêt : runbook 'et sur les P0/P1 responsables 24 × 7, canaux de communication.
Détection : signatures/règles de comportement, corélation dans SIEM, automatisation SOAR.
Confinement : bloc de tokens/clés, feuille de déni des itinéraires, quarantine des tops.
Eradication/récupération : rotations, patchs, recadrage, récupération à partir de snapshots.
Post-mortem : dans les 72 h, action-aytem, mise à jour des politiques/tests.

Règles SOAR (exemple)

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

11) Conformité et résidence

Exigences réglementaires : stockage/suppression de données (DSR), rapports, certification RNG/cryptographie.
Résidence : clés par région et volts, exportation par listes blanches.
Processus : audits réguliers, journal des changements, timelock sur les politiques critiques.

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 et durabilité

Objectifs RPO/RTO : Services P0 - RPO ≤ 5 min, RTO ≤ 15 min.
Géo-réplication : Actif-passif/actif-actif, tests de récupération périodiques.
Mode isolé : finalized-only, cache-only, limitation des opérations « chères ».
Canaux de secours : IX/fournisseurs indépendants, tunnels interrégionaux cryptés.

Politique du DR

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

13) Mesures et essais de sécurité

Chaos-security: тесты MITM/DNS-poison/packet-loss/latency.
Red/Blue Team : scénarios de phishing, détournement de token, injections de supply-chain.
Tabletop-drills : modélisation de la prise de décision et des communications.
Autotests : SAST/DAST/IAST, protocole de fuzzing, linters de politique.

14) Pleybooks d'incidents

A. Compromission de la clé du participant

1. 'revoke _ key' → 'rotate' → mettre à jour le registre de confiance ;

2. inclure le mode strict des signatures ; 3) recouper les batchs critiques ; 4) rapport aux partenaires.

B. Violation de la résidence

1. Unité d'exportation immédiate ; 2) redaction/suppression ; 3) aviser le DPO/Conformité ; 4) mettre à jour les tests.

Injection de C. Supply-chain

1. Retour sur le hachage, kill-switch ; 2) revalider les SBOM/attestations ; 3) rotation des tokens CI ; 4) post-mortem.

D. DoS/L7-flood de masse

1. Activation des limites de taux/WAF renforcées ; 2) Anycast-drebling ; 3) hiérarchisation P0 ; 4) la communication avec les fournisseurs.

E. Drift politiques/contrats

1. Activer deny pour les schémas incompatibles ; 2) la sortie des adaptateurs ; 3) mettre à jour les linters/registres.

15) Chèque de mise en œuvre (par étapes)

1. Entrez le modèle d'identité (org/peer/service/user) et mTLS + OIDC.
2. Décrire la politique-as-code (RBAC/ABAC), le PoLP et l'escalade JIT.
3. Chiffrez les données « en transit » et « au repos », tokenizez le PII, ajustez la résidence.
4. Activez la protection de la chaîne d'approvisionnement : signatures d'artefacts, SBOM, attestations, canary + kill-switch.
5. Configurez WAF/Rate-limits/DoS-Guards et egress-control.
6. Soulevez le SIEM/SOAR, décrivez le SLI/SLO, les alertes et les dashboards Security.
7. Réglez les rotations de clés/serts et les accès break-glass.
8. Travaillez le DR/BCP et les modes isolés, effectuez des exercices.
9. Organiser un audit/loging et des post-mortems réguliers.
10. Révisez vos politiques tous les trimestres, automatisez vos vérifications.

16) Glossaire

Zero-Trust est un modèle où chaque action est validée indépendamment de l'emplacement.
PoLP est le principe des droits minimaux nécessaires.
Policy-as-Code - Contrôle des accès/règles par le biais de stratégies déclaratives.
SLSA - Niveaux de sécurité de la chaîne d'approvisionnement des logiciels.
RPO/RTO - valeurs cibles de perte de données/temps de récupération.
DPoP/PoP est la liaison d'un jeton à un canal/client TLS particulier.
Le mode strict est un mode qui interdit les schémas/signatures non conformes.

Résultat : la sécurité de l'écosystème n'est pas un « pare-feu et TLS », mais un alliage de confiance cryptographique, de politiques strictes d'accès, d'observation et de discipline opérationnelle. Suivre les contrôles Zero-Trust, PoLP, supply-chain et le SLO mesurable transforme la sécurité en une pratique d'ingénierie gérée résistante aux pannes, aux attaques et aux changements réglementaires.