6.3 KiB
6.3 KiB
POL-OBS-LOG-001 — Contrat de journalisation (Logs) — Référence Loki
Version : 1.0
Date : 25 janvier 2026
Cycle de Réalignement Boréal : CRB-3
Statut : Obligatoire (référence vivante)
Portée : C3 (Observabilité fédérée), C5 (Pivot), C6–C8 (Tenants), Membres affiliés
1. Objet
Définir le contrat minimal de collecte, transport, étiquetage, rétention, accès et preuves pour les logs, avec Loki comme backend de référence.
Cette politique vise explicitement la simplicité d’adoption par les petits membres :
- un endpoint standard,
- une configuration “copier-coller” (agent),
- un jeu de labels minimal,
- un modèle d’accès via SSO.
2. Principes invariants
2.1 Adjacent-only (obligatoire)
- Les logs ne contournent jamais le pivot.
- Chemin normatif : C6 → C5 → C3 (tenant vers pivot vers fédération).
2.2 Séparation Fédération / Tenants
- Les tenants sont isolés en lecture/écriture.
- La Fédération peut opérer et auditer sans exposer les couches internes.
2.3 Simplicité opératoire
- Un petit membre n’a pas à comprendre le multi-tenant.
- L’isolation est assurée par le Pivot (C5).
3. Référence technique
3.1 Backend
- Loki = backend de logs de référence.
3.2 Visualisation / requêtes
- Grafana = interface de consultation de référence.
3.3 Agent de collecte
- Grafana Alloy = agent recommandé par défaut.
- Autres agents acceptés si :
- ils supportent l’ingestion Loki via HTTP(S),
- ils respectent les labels et les contraintes de cette politique,
- ils n’introduisent pas de labels à haute cardinalité.
4. Points d’entrée (endpoints) — standardisation
4.1 Ingestion (écriture)
- Endpoint unique via le Pivot (C5) :
https://logs.pivot.<membre>.alliance-boreale.ca/... - Interdiction : accès direct tenant → Loki (C3).
4.2 Consultation (lecture)
- Accès Grafana via Pivot (C5) (reverse-proxy) + SSO (Keycloak).
Note : Le chemin exact (
/loki/api/v1/push, etc.) est défini par l’implémentation du Gateway, mais l’invariant est : une URL unique, TLS obligatoire, auth obligatoire.
5. Authentification & autorisation
5.1 Lecture (Grafana)
- SSO via Keycloak (OIDC/SAML).
- RBAC : permissions par organisation/tenant et par rôle (admin, ops, lecteur).
5.2 Écriture (agents)
Mode recommandé (simple) :
- Token d’ingestion (Bearer) par organisation/tenant, délivré/provisionné via le Pivot.
- Le secret est stocké comme secret (Vault ou mécanisme équivalent), jamais en clair dans un repo.
Mode alternatif (si requis) :
- mTLS avec certificats gérés par la Fédération.
6. Isolation (multi-tenant) — masquée pour les petits
6.1 Principe
- Le Pivot (C5) est responsable d’assigner l’isolement tenant (ex. injection d’un identifiant d’organisation).
- Les petits membres/tenants ne manipulent pas l’identifiant d’isolation.
6.2 Interdictions
- Un agent ne doit pas pouvoir écrire dans un autre tenant.
- Toute tentative d’accès hors périmètre est loggée et alertée.
7. Labels (schéma Boréal) — minimal et stable
7.1 Labels obligatoires (MVP)
Chaque stream de logs DOIT inclure au minimum :
org: organisation ou tenant (valeur stable)env:prod | preprod | devservice: nom stable du service (ex.pivot-api,forgejo,nextcloud,tenant-app)member: code membre (ex.czp,mtl,qc2)
7.2 Labels optionnels (avec prudence)
host: nom machine/VM (stable)layer: couche (c3,c5,c6, etc.) si utile
7.3 Interdictions (cardinalité)
Il est strictement interdit de promouvoir en labels des valeurs à haute cardinalité, incluant (non exhaustif) :
trace_id,span_id,request_id,session_iduser_id,email, identifiants personnels- timestamps, UUIDs, numéros de commande, adresses IP client
Ces valeurs doivent rester dans le contenu du log (requêtables), pas dans les labels.
8. Qualité des logs (hygiène minimale)
8.1 Format recommandé
- JSON structuré si possible (clé/valeur), sinon logfmt.
- Les champs sensibles doivent être masqués (redaction) avant expédition.
8.2 Données sensibles
- Ne pas expédier de secrets (tokens, clés, mots de passe).
- Ne pas expédier de données personnelles non nécessaires.
- Si un tenant a des contraintes particulières, il doit fournir une règle de redaction.
9. Rétention & classes de service
9.1 Rétention par défaut (standard)
- 14 jours (sauf exception documentée).
9.2 Exceptions
- Toute rétention supérieure (ex. “régulé”) doit être :
- justifiée,
- validée par gouvernance (C3),
- accompagnée de preuves (stockage, coûts, risques, contrôles).
10. Quotas & protection
Le Pivot (C5) doit appliquer :
- quotas d’ingestion (taux, volume/jour),
- limites de taille par entrée,
- protections anti-boucle / anti-tempête (burst control),
- blocage ou mise en quarantaine en cas de non-conformité (labels interdits, volumes anormaux).
11. Preuves minimales (audit)
Pour être “conforme POL-OBS-LOG-001”, les preuves suivantes doivent être disponibles :
- Configuration du Gateway (C5) : TLS, auth, routage, quotas.
- Configuration Loki (C3) : rétention, stockage, limites, accès.
- Exemple de configuration agent (Alloy) “copier-coller” (template).
- Démonstration : une requête Grafana/Loki qui retourne des logs d’un service donné.
- Journal des incidents de non-conformité (tentatives cross-tenant, labels interdits).
12. Non-conformité & remédiation
12.1 Détection
- Toute violation (labels interdits, volumétrie anormale, tentative cross-tenant) déclenche :
- un événement de sécurité/opérations,
- une entrée de traçabilité (ΔLog / incident).
12.2 Réponse
- Quarantaine du flux (au pivot) si nécessaire.
- Correction du template agent.
- Ajustement des politiques si apprentissage systémique requis.
13. Annexes
A) Requête Loki (exemple conceptuel)
{org="t001", env="prod", service="pivot-api", member="czp"}
B) Convention de nommage (rappel)
- Conformité à la Nomenclature v3 pour VMID, DNS, et segmentation par couche.