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

212 lines
No EOL
6.7 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# POL-OPS-STACK-001 — Conformité pile opérateur (C1C5) — Exigences & preuves attendues
**Version :** 1.1
**Date :** 26 janvier 2026
**Statut :** Obligatoire (référence vivante)
**Portée :** Opérateurs (C1C5), Gouvernance, Audit
---
## 1. Objet
Définir les exigences minimales et les **preuves attendues** pour quun 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 dexécution (CI / runner C5)
- Tag/release si changement livré
---
### 2.2 Membrane & non-bypass
- C5 (NGINX+ModSecurity) est **le** point dentré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 dauthentification (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 daccè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 C1C5)
- C3-E3 : couverture checks Icinga + historique alertes/incidents
- C3-E4 : targets Prometheus + règles Alertmanager + exemple dalerte
- C3-E5 : exports dashboards Grafana + sources de données
- C3-E6 : conformité Loki (labels/rétention + requêtes dexemple 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 dartefacts 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 dexécution IaC
**Exigences**
- NGINX + ModSecurity : point dentrée unique, TLS, protections WAF, logs daccès.
- FastAPI : admission/quotas/politiques (au minimum), journalisation.
- Unbound : DNS récursif tenants, ACL, forwarding contrôlé.
- Runner dexé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 daccè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é dexé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,
- lexécution IaC nest 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 (C1C5) + preuves attendues
- Auteur(s) : \_________________\_
- Référence PR : \_________________\_
- Date dentrée : \_________________\_