Alliance-Boreale/alliance-boreale
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
alliance-boreale/docs/politiques/POL-OPS-STACK-001 — Conformité pile opérateur (C1–C5).md
Dan Allaire ef98fd8a3f Refonte
2026-03-09 18:23:06 -04:00

6.7 KiB
Raw Blame History

POL-OPS-STACK-001 — Conformité pile opérateur (C1–C5) — Exigences & preuves attendues

Version : 1.1
Date : 26 janvier 2026
Statut : Obligatoire (référence vivante)
Portée : Opérateurs (C1–C5), Gouvernance, Audit

1. Objet

Définir les exigences minimales et les preuves attendues pour qu’un membre “Opérateur” soit considéré conforme à la Pile opérateur de référence (ADR-OPS-STACK-001).

Cette politique est conçue pour produire une conformité mécanique :

  • des preuves standardisées,
  • indexées,
  • et vérifiables.

2. Exigences transversales (obligatoires)

2.1 Traçabilité (PR + ΔLog)

  • Toute modification doit être :
    • versionnée (Forgejo),
    • validée (PR),
    • expliquée (ΔLog),
    • reliée à une exécution (CI, OpenTofu, Ansible) si applicable.

Preuves :

  • Liens PR + ΔLog
  • Logs d’exécution (CI / runner C5)
  • Tag/release si changement livré

2.2 Membrane & non-bypass

  • C5 (NGINX+ModSecurity) est le point d’entrée unique.
  • Aucun accès tenant direct vers C2/C3/C4.

Preuves :

  • Export OPNsense + matrice de flux autorisés
  • Tests “saut de couche” (résultats + horodatage)
  • Logs NGINX/OPNsense démontrant la médiation

2.3 SSO & RBAC

  • Les portails exposés (Grafana, Icinga Web) sont accessibles via C5 et protégés par SSO (Keycloak).
  • Rôles séparés (ops, audit) documentés.

Preuves :

  • Export Keycloak (realm/clients/roles)
  • Matrice rôles → permissions
  • Logs d’authentification (exemples)

2.4 Indexation des preuves

  • Les preuves doivent être déposées et indexées dans le dépôt operator-stack/ selon un format stable.

Preuves :

  • evidence/00_Evidence_Index.md à jour
  • Convention de nommage appliquée
  • Preuves datées par période (trimestre ou mois)

3. Exigences et preuves par couche

3.1 C1 — Proxmox VE / Ceph / TrueNAS

Exigences

  • Proxmox VE : cluster opéré, accès admin restreint, inventaire maintenu.
  • Ceph : santé OK, réplication définie, capacité suivie.
  • TrueNAS : datasets/ACL + snapshots/rétention si utilisé pour landing zone / exports / backup.

Preuves minimales

  • C1-E1 : inventaire Proxmox (nœuds, versions, ressources)
  • C1-E2 : état de santé Ceph + capacité
  • C1-E3 : test de restauration documenté pour un workload critique
  • C1-E4 : configuration TrueNAS pertinente (datasets/snapshots) si activée

3.2 C2 — OPNsense / PowerDNS Authoritative / WireGuard

Exigences

  • OPNsense : segmentation par couche, “default deny”, logs activés.
  • PowerDNS : zones + délégations, ACL, traçabilité des changements.
  • WireGuard : accès ops/admin sécurisé, onboarding/offboarding maîtrisé.

Preuves minimales

  • C2-E1 : export configuration OPNsense (versionné) + matrice de flux
  • C2-E2 : test “non-bypass / adjacent-only” (résultats + logs)
  • C2-E3 : inventaire DNS (zones/délégations) + ΔLog des changements
  • C2-E4 : preuves WireGuard (pairs autorisés + journal connexions + runbook)

3.3 C3 — Keycloak / OpenLDAP / Icinga / Prometheus / Grafana / Loki

Exigences

  • Keycloak : SSO fonctionnel, RBAC, séparation ops/audit.
  • OpenLDAP : seulement si requis ; sauvegarde et contrôle d’accès.
  • Icinga2 + Web 2 + BPM : SLA/états auditables (vues auditeurs).
  • Prometheus + Alertmanager : collecte métriques et alerting.
  • Grafana : console unifiée (Prometheus + Loki).
  • Loki : logs centralisés, conventions de labels, rétention appliquée, séparation prouvable.

Preuves minimales

  • C3-E1 : export Keycloak + matrice rôles→droits
  • C3-E2 : exports BPM (tableaux “auditeur” couvrant C1–C5)
  • C3-E3 : couverture checks Icinga + historique alertes/incidents
  • C3-E4 : targets Prometheus + règles Alertmanager + exemple d’alerte
  • C3-E5 : exports dashboards Grafana + sources de données
  • C3-E6 : conformité Loki (labels/rétention + requêtes d’exemple reproductibles)

3.4 C4 — Forgejo / Forgejo Actions (CI) / Harbor / Vault / Référentiels IaC

Exigences

  • Forgejo : PR obligatoires, branches protégées, ADR/POL versionnés, ΔLog actif.
  • Forgejo Actions : CI de validation (build/test/scan/validation IaC), logs conservés.
  • Harbor : registry OCI avec RBAC, rétention, provenance (liens CI).
  • Vault : secrets centralisés, policies, audit log, rotation minimale.
  • Référentiels IaC : modules OpenTofu + playbooks/inventaires Ansible versionnés et revus.

Preuves minimales

  • C4-E1 : règles repos (branch protection, PR rules) + exemples PR + ΔLog
  • C4-E2 : logs Forgejo Actions (CI) + politique pass/fail
  • C4-E3 : configuration Harbor (RBAC/rétention) + preuve d’artefacts publiés
  • C4-E4 : policies Vault + audit log + preuve “no secrets in repos”
  • C4-E5 : preuves IaC côté C4 :
    • format/lint (OpenTofu/Ansible),
    • tofu plan (ou équivalent) attaché aux PR,
    • artefacts de validation si utilisés

3.5 C5 — NGINX+ModSecurity / FastAPI / Unbound / Runner d’exécution IaC

Exigences

  • NGINX + ModSecurity : point d’entrée unique, TLS, protections WAF, logs d’accès.
  • FastAPI : admission/quotas/politiques (au minimum), journalisation.
  • Unbound : DNS récursif tenants, ACL, forwarding contrôlé.
  • Runner d’exécution IaC (C5) : exécute les actions à privilèges (OpenTofu apply, Ansible) avec :
    • secrets fournis via Vault,
    • accès réseau minimal nécessaire,
    • traçabilité PR → exécution,
    • contrôle d’accès strict.

Preuves minimales

  • C5-E1 : configurations versionnées NGINX + ModSecurity + preuve TLS (certs)
  • C5-E2 : logs NGINX démontrant la médiation (absence de bypass)
  • C5-E3 : FastAPI (OpenAPI, version, logs, contrôles admission/quotas)
  • C5-E4 : Unbound (ACL/forwarding) + logs + preuve “tenants ne parlent pas à C2”
  • C5-E5 : preuves exécution IaC côté C5 :
    • logs plan/apply OpenTofu,
    • logs Ansible,
    • identité d’exécution (qui/quoi/quand),
    • liens PR → job → exécution,
    • preuve de rollback/restore si applicable

4. Déclaration de non-conformité

Une non-conformité est déclarée si :

  • un composant de la pile est absent,
  • les preuves minimales manquent ou ne sont pas indexées,
  • un bypass du pivot est possible,
  • les portails ne sont pas protégés par SSO via C5,
  • la traçabilité (PR/ΔLog) est absente,
  • l’exécution IaC n’est pas contrôlée via C5.

Remédiation attendue :

  • incident/ticket (si votre ITSM existe),
  • ΔLog,
  • PR corrective,
  • preuves mises à jour et indexées.

5. ΔLog (à compléter au commit)

  • Politique : Conformité pile opérateur (C1–C5) + preuves attendues
  • Auteur(s) : __________________
  • Référence PR : __________________
  • Date d’entrée : __________________