diff --git a/docs/architecture/nomenclature_v2(1).md b/docs/architecture/nomenclature_v2(1).md deleted file mode 100644 index 9218b43..0000000 --- a/docs/architecture/nomenclature_v2(1).md +++ /dev/null @@ -1,1033 +0,0 @@ -# Standard de Nomenclature v2.0 -## L'Alliance Boréale - -**Version :** 2.0 -**Date :** 21 octobre 2025 -**Statut :** DRAFT - Validation requise par Cercle Technique -**Remplace :** N/A (première version unifiée) -**Auteur :** Daniel Mathieu (Chezlepro) avec assistance Claude -**Licence :** CC-BY-SA 4.0 - ---- - -## Table des Matières - -1. [Introduction](#1-introduction) -2. [Principes Directeurs](#2-principes-directeurs) -3. [Architecture Réseau de Référence](#3-architecture-réseau-de-référence) -4. [Nomenclature VMID (Proxmox)](#4-nomenclature-vmid-proxmox) -5. [Plan d'Adressage IP](#5-plan-dadressage-ip) -6. [Nomenclature VMs (Noms)](#6-nomenclature-vms-noms) -7. [Nomenclature DNS](#7-nomenclature-dns) -8. [Tables de Correspondance](#8-tables-de-correspondance) -9. [Procédures Opérationnelles](#9-procédures-opérationnelles) -10. [Exemples Complets](#10-exemples-complets) -11. [Migration et Adoption](#11-migration-et-adoption) -12. [Annexes](#12-annexes) - ---- - -## 1. Introduction - -### 1.1 Objectif du Document - -Ce standard définit la **nomenclature unifiée** pour l'infrastructure de L'Alliance Boréale, couvrant : -- Identifiants de machines virtuelles (VMID) dans Proxmox -- Plan d'adressage IP interne (10.0.0.0/8) -- Noms de VMs lisibles et structurés -- Noms de domaine DNS internes et fédérés -- Correspondance entre tous ces éléments - -### 1.2 Portée - -Ce standard s'applique à **tous les membres** de L'Alliance Boréale. Chaque membre, opérant derrière son propre NAT/firewall, utilise ce standard dans son espace interne. - -### 1.3 Cohérence avec l'Architecture - -Ce document est **aligné sur** : -- **Plan d'Adressage IP v3** (03-standards-techniques.md) -- **Architecture à 8 Couches** (Charte Fondatrice) -- **Modèle de fédération décentralisée** (chaque membre autonome) - ---- - -## 2. Principes Directeurs - -### 2.1 Mnémotechnique - -Chaque identifiant doit être **immédiatement compréhensible** : -- Le VMID indique la couche et le type de service -- L'adresse IP reflète la fonction -- Le nom DNS est descriptif - -### 2.2 Cohérence Totale - -**Un seul système** lie : -``` -VMID ←→ IP ←→ Nom VM ←→ DNS -``` - -### 2.3 Scalabilité - -Le système supporte : -- Jusqu'à **999 tenants** par membre -- Jusqu'à **99 instances** par type de service -- Expansion future sans refonte - -### 2.4 Isolation et Autonomie - -- Chaque membre utilise **10.0.0.0/8** localement (derrière NAT) -- Pas de conflit entre membres (isolation par firewall) -- VMIDs peuvent être identiques entre membres (Proxmox séparés) - ---- - -## 3. Architecture Réseau de Référence - -### 3.1 Vue Globale - -``` -┌─────────────────────────────────────────────────────────────┐ -│ INTERNET PUBLIC │ -│ • Services exposés (web, email, DNS public) │ -└─────────────────────┬───────────────────────────────────────┘ - │ - ┌─────────────┼─────────────┐ - │ │ │ -┌───────▼──────┐ ┌────▼─────┐ ┌────▼─────┐ -│ Chezlepro │ │ Nuage │ │ Techno │ -│ FIREWALL/NAT │ │ Libre │ │ Libre │ -└───────┬──────┘ └────┬─────┘ └────┬─────┘ - │ │ │ - │ 10.0.0.0/8 │ 10.0.0.0/8 │ 10.0.0.0/8 - │ (local) │ (local) │ (local) - │ │ │ -┌───────▼─────────────┴─────────────▼──────────────────────┐ -│ ESPACE FÉDÉRATIF (172.16.0.0/12) │ -│ • Services accessibles entre membres via tunnels │ -│ • DNS secondaire, monitoring, backups │ -└───────────────────────────────────────────────────────────┘ -``` - -### 3.2 Plan d'Adressage par Membre - -Chaque membre utilise **10.0.0.0/8** selon cette structure : - -``` -┌─────────────────────────────────────────────────────────────┐ -│ 10.0.0.0/8 - ESPACE INTERNE (derrière NAT) │ -├─────────────────────────────────────────────────────────────┤ -│ │ -│ INFRASTRUCTURE DU FÉDÉRÉ (Couches 1-4) │ -│ │ -│ 10.0.0.0/24 → Management (254 hôtes) │ -│ 10.0.1.0/24 → Platform Services (254 hôtes) │ -│ 10.0.2.0/24 → Public DNS (254 hôtes) │ -│ 10.0.20.0/22 → Reserved Infrastructure (1 024 hôtes) │ -│ │ -├─────────────────────────────────────────────────────────────┤ -│ │ -│ TENANTS (Couches 5-8) │ -│ │ -│ 10.0.10.0/23 → Tenant Infrastructure (512 hôtes) │ -│ 10.0.128.0/17 → Expansion (32 766 hôtes, 50% du /8) │ -│ │ -└─────────────────────────────────────────────────────────────┘ -``` - ---- - -## 4. Nomenclature VMID (Proxmox) - -### 4.1 Principe Général - -Le VMID Proxmox est un **identifiant numérique mnémotechnique** qui encode : -- La zone (Infrastructure ou Tenant) -- La couche (1-4 pour infra, tenant ID pour tenants) -- Le type de service -- L'instance - -### 4.2 Infrastructure Fédéré (VMID 01000-04999) - -**Format : `0CTTII`** - -Où : -- `0` = Infrastructure fédéré (préfixe fixe) -- `C` = Couche (1, 2, 3, ou 4) -- `TT` = Type de service (00-99) -- `II` = Instance (01-99) - -**Plages par Couche :** -``` -01000-01999 → Couche 1 - Physique (monitoring matériel) -02000-02999 → Couche 2 - Réseau (DNS, VPN, routeurs) -03000-03999 → Couche 3 - Stockage (Ceph, NFS, backups) -04000-04999 → Couche 4 - Orchestration (Ansible, Git, CI/CD) -``` - -**Types de Services (TT) :** - -#### Couche 2 - Réseau (02000-02999) -``` -00-09 : DNS (PowerDNS) -10-19 : VPN/WireGuard -20-29 : Routeurs virtuels -30-39 : Proxy/HAProxy -40-49 : Load Balancers -``` - -#### Couche 3 - Stockage (03000-03999) -``` -00-09 : Ceph Monitors -10-19 : Ceph OSDs (si VMs) -20-29 : NFS Servers -30-39 : Backup Servers (PBS, Borg) -40-49 : Object Storage (MinIO) -``` - -#### Couche 4 - Orchestration (04000-04999) -``` -00-09 : Ansible Controllers -10-19 : CI/CD Runners -20-29 : Forgejo/GitLab -30-39 : PostgreSQL Platform -40-49 : FastAPI Platform Admin -50-59 : Artifact Repositories -``` - -**Exemples :** -``` -02001 = Couche 2, DNS (00), Instance 1 → PowerDNS Master -02002 = Couche 2, DNS (00), Instance 2 → PowerDNS Slave 1 -02101 = Couche 2, VPN (10), Instance 1 → WireGuard Gateway -04001 = Couche 4, Ansible (00), Instance 1 → Ansible Controller -04201 = Couche 4, Git (20), Instance 1 → Forgejo -``` - -### 4.3 Tenants (VMID 10000-99999) - -**Format : `TTTII`** - -Où : -- `TTT` = Tenant ID (001-999) -- `II` = Instance dans le tenant (01-99) - -**Plages par Tenant :** -``` -10001-10099 → Tenant 001 (99 VMs max) -20001-20099 → Tenant 002 (99 VMs max) -30001-30099 → Tenant 003 (99 VMs max) -... -99901-99999 → Tenant 999 (99 VMs max) -``` - -**Convention Instance (II) :** -``` -01-09 : Web/Frontend -10-19 : Backend/API -20-29 : Bases de données -30-39 : Cache/Queue -40-49 : Workers/Jobs -50-59 : Monitoring tenant -60-69 : Dev/Staging -70-99 : Usage libre -``` - -**Exemples :** -``` -10001 = Tenant 001, Instance 01 → Web Frontend -10002 = Tenant 001, Instance 02 → Web Frontend HA -10011 = Tenant 001, Instance 11 → Backend API -10021 = Tenant 001, Instance 21 → PostgreSQL - -20001 = Tenant 002, Instance 01 → Web Frontend -20011 = Tenant 002, Instance 11 → Backend -``` - -### 4.4 Plages Réservées - -``` -00000-00999 : Réservé Proxmox système -01000-04999 : Infrastructure Fédéré (Couches 1-4) -05000-09999 : Réservé extension infrastructure -10000-99999 : Tenants (001-999) -``` - ---- - -## 5. Plan d'Adressage IP - -### 5.1 Infrastructure (10.0.0.0 - 10.0.23.255) - -#### 10.0.0.0/24 - Management -``` -10.0.0.1 → Gateway/Firewall principal -10.0.0.10-.50 → Hyperviseurs Proxmox (nodes physiques) -10.0.0.100-.200 → Outils monitoring/admin (Icinga, Grafana) -10.0.0.250-.254 → Réservé administration -``` - -#### 10.0.1.0/24 - Platform Services -``` -10.0.1.10 → Ansible Controller (VMID 04001) -10.0.1.20 → Forgejo Git (VMID 04201) -10.0.1.30 → PostgreSQL Platform (VMID 04301) -10.0.1.40 → FastAPI Platform Admin (VMID 04401) -10.0.1.50 → Dashboard React Platform (VMID 04501) -10.0.1.100-.200 → Autres services plateforme -``` - -#### 10.0.2.0/24 - Public DNS -``` -10.0.2.10 → PowerDNS Master (VMID 02001) -10.0.2.11 → PowerDNS Slave 1 (VMID 02002) -10.0.2.12 → PowerDNS Slave 2 (VMID 02003) -10.0.2.20 → WireGuard Gateway (VMID 02101) -10.0.2.30 → HAProxy (VMID 02301) -10.0.2.100-.200 → Autres services réseau -``` - -#### 10.0.20.0/22 - Reserved Infrastructure -``` -1 024 adresses réservées pour expansion infrastructure future -``` - -### 5.2 Tenants (10.0.10.0 - 10.255.255.255) - -#### 10.0.10.0/23 - Tenant Infrastructure -``` -512 adresses pour VMs des tenants -Allocation dynamique via IPAM -Gestion par FastAPI Platform -``` - -**Stratégie d'Allocation Suggérée :** -``` -10.0.10.0-.99 → Tenant 001 -10.0.10.100-.199 → Tenant 002 -10.0.11.0-.99 → Tenant 003 -... -``` - -#### 10.0.128.0/17 - Expansion Massive -``` -32 766 adresses (50% du /8) -Réservé pour croissance future des tenants -``` - -### 5.3 Formule de Calcul IP (Infrastructure) - -Pour les services d'infrastructure avec VMID `0CTTII` : - -**Si C=2 (DNS/Réseau) :** -``` -IP = 10.0.2.(TT*10 + II) -``` - -**Exemples :** -``` -VMID 02001 → TT=00, II=01 → 10.0.2.(0*10+1) = 10.0.2.1 (mais on utilise .10) -VMID 02101 → TT=10, II=01 → 10.0.2.(10*10+1) = 10.0.2.101 (mais on utilise .20) -``` - -**Note :** La formule est indicative. En pratique, on utilise une allocation manuelle cohérente documentée ci-dessus. - ---- - -## 6. Nomenclature VMs (Noms) - -### 6.1 Infrastructure (Couches 1-4) - -**Format : `-infra---`** - -Où : -- `` = ID court du membre (czp, nul, tli, etc.) -- `infra` = Marqueur infrastructure (fixe) -- `` = Type de service (dns-master, ansible-ctrl, etc.) -- `` = Environnement (prod, stg, dev, test) -- `` = Numéro (01, 02, 03...) - -**Exemples :** -``` -czp-infra-dns-master-prod-01 -czp-infra-dns-slave1-prod-01 -czp-infra-vpn-gateway-prod-01 -czp-infra-ansible-ctrl-prod-01 -czp-infra-git-forgejo-prod-01 -czp-infra-pbs-backup-prod-01 -czp-infra-ceph-mon1-prod-01 -``` - -### 6.2 Tenants (Couches 5-8) - -**Format : `-t---`** - -Où : -- `` = ID court du membre -- `t` = Tenant (t001, t002, t003...) -- `` = Type de service (web, db, api, backend, cache, worker...) -- `` = Environnement (prod, stg, dev) -- `` = Numéro (01, 02...) - -**Exemples :** -``` -czp-t001-web-prod-01 -czp-t001-db-postgres-prod-01 -czp-t001-api-fastapi-prod-01 -czp-t001-backend-prod-01 -czp-t001-cache-redis-prod-01 - -czp-t002-web-prod-01 -czp-t002-app-backend-prod-01 -czp-t002-db-mysql-prod-01 -``` - -### 6.3 Conventions Types - -**Infrastructure :** -``` -dns-master, dns-slave1, dns-slave2 -vpn-gateway, vpn-peer -ansible-ctrl, ci-runner -git-forgejo, git-gitlab -db-platform, api-admin -pbs-backup, borg-backup -ceph-mon, ceph-osd, nfs-server -``` - -**Tenants :** -``` -web, web-nginx, web-apache -db-postgres, db-mysql, db-mariadb -api-fastapi, api-django, backend -cache-redis, cache-memcached -queue-rabbitmq, queue-redis -worker, job-processor -monitoring, logging -``` - ---- - -## 7. Nomenclature DNS - -### 7.1 Infrastructure (Services Fédérés) - -**Format : `.infra..alliance-boreale.ca`** - -Où : -- `` = Nom du service (dns-master, ansible, git...) -- `infra` = Marqueur infrastructure (fixe) -- `` = ID court (czp, nul, tli) -- `alliance-boreale.ca` = Domaine fédéré - -**Exemples :** -``` -dns-master.infra.czp.alliance-boreale.ca → 10.0.2.10 -dns-slave1.infra.czp.alliance-boreale.ca → 10.0.2.11 -vpn.infra.czp.alliance-boreale.ca → 10.0.2.20 -ansible.infra.czp.alliance-boreale.ca → 10.0.1.10 -git.infra.czp.alliance-boreale.ca → 10.0.1.20 -backup.infra.czp.alliance-boreale.ca → 10.0.1.30 -``` - -### 7.2 Tenants - -**Format : `.t..alliance-boreale.ca`** - -Où : -- `` = Nom du service (web, db, api...) -- `t` = Tenant (t001, t002...) -- `` = ID court -- `alliance-boreale.ca` = Domaine fédéré - -**Exemples :** -``` -web.t001.czp.alliance-boreale.ca → 10.0.10.1 -db.t001.czp.alliance-boreale.ca → 10.0.10.2 -api.t001.czp.alliance-boreale.ca → 10.0.10.3 - -web.t002.czp.alliance-boreale.ca → 10.0.10.10 -backend.t002.czp.alliance-boreale.ca → 10.0.10.11 -``` - -### 7.3 DNS Publics (Exposés) - -Pour les services exposés publiquement : -``` -www.tenant-example.com → IP publique (NAT vers 10.0.10.X) -mail.tenant-example.com → IP publique (NAT vers 10.0.10.Y) -``` - -Le DNS interne reste accessible via le domaine `.alliance-boreale.ca` pour la fédération. - ---- - -## 8. Tables de Correspondance - -### 8.1 Infrastructure Complète (Exemple Chezlepro) - -| VMID | Nom VM | IP Interne | DNS | Fonction | -|------|--------|------------|-----|----------| -| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | PowerDNS Maître | -| 02002 | czp-infra-dns-slave1-prod-01 | 10.0.2.11 | dns-slave1.infra.czp.ab.ca | PowerDNS Esclave 1 | -| 02003 | czp-infra-dns-slave2-prod-01 | 10.0.2.12 | dns-slave2.infra.czp.ab.ca | PowerDNS Esclave 2 | -| 02101 | czp-infra-vpn-gateway-prod-01 | 10.0.2.20 | vpn.infra.czp.ab.ca | WireGuard Gateway | -| 02301 | czp-infra-proxy-haproxy-prod-01 | 10.0.2.30 | proxy.infra.czp.ab.ca | HAProxy Frontend | -| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | Proxmox Backup Server | -| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | Ansible Controller | -| 04201 | czp-infra-git-forgejo-prod-01 | 10.0.1.20 | git.infra.czp.ab.ca | Forgejo Git | -| 04301 | czp-infra-db-platform-prod-01 | 10.0.1.30 | db.infra.czp.ab.ca | PostgreSQL Platform | -| 04401 | czp-infra-api-admin-prod-01 | 10.0.1.40 | api.infra.czp.ab.ca | FastAPI Admin | - -### 8.2 Tenants (Exemples) - -| VMID | Nom VM | IP Interne | DNS | Fonction | -|------|--------|------------|-----|----------| -| 10001 | czp-t001-web-prod-01 | 10.0.10.1 | web.t001.czp.ab.ca | Web Frontend T001 | -| 10002 | czp-t001-web-prod-02 | 10.0.10.2 | web.t001.czp.ab.ca | Web Frontend T001 HA | -| 10011 | czp-t001-api-prod-01 | 10.0.10.3 | api.t001.czp.ab.ca | API Backend T001 | -| 10021 | czp-t001-db-postgres-prod-01 | 10.0.10.4 | db.t001.czp.ab.ca | PostgreSQL T001 | -| 20001 | czp-t002-web-prod-01 | 10.0.10.10 | web.t002.czp.ab.ca | Web Frontend T002 | -| 20011 | czp-t002-backend-prod-01 | 10.0.10.11 | backend.t002.czp.ab.ca | Backend T002 | -| 20021 | czp-t002-db-mysql-prod-01 | 10.0.10.12 | db.t002.czp.ab.ca | MySQL T002 | - ---- - -## 9. Procédures Opérationnelles - -### 9.1 Création d'une Nouvelle VM Infrastructure - -**Étapes :** - -1. **Déterminer le VMID** - ``` - - Identifier la couche (2, 3, ou 4) - - Identifier le type de service - - Choisir l'instance disponible - Exemple: DNS Slave 3 → 02003 - ``` - -2. **Calculer l'IP** - ``` - - Consulter la table d'allocation (section 5) - - Exemple: 02003 → 10.0.2.12 - ``` - -3. **Construire le nom VM** - ``` - Format: -infra--- - Exemple: czp-infra-dns-slave3-prod-01 - ``` - -4. **Créer l'entrée DNS** - ``` - Format: .infra..alliance-boreale.ca - Exemple: dns-slave3.infra.czp.alliance-boreale.ca → 10.0.2.12 - ``` - -5. **Créer la VM dans Proxmox** - ```bash - qm create 02003 \ - --name czp-infra-dns-slave3-prod-01 \ - --net0 virtio,bridge=vmbr0,tag=2 \ - --ipconfig0 ip=10.0.2.12/24,gw=10.0.0.1 - ``` - -6. **Documenter** - - Ajouter dans le registre des VMs - - Mettre à jour l'inventaire Ansible - - Ajouter dans le monitoring - -### 9.2 Création d'une Nouvelle VM Tenant - -**Étapes :** - -1. **Allouer un Tenant ID** - ``` - - Consulter le registre des tenants - - Exemple: Prochain disponible = 003 → t003 - ``` - -2. **Déterminer le VMID** - ``` - Format: TTTII - Exemple: Tenant 003, Web → 30001 - ``` - -3. **Allouer une IP** - ``` - - Utiliser IPAM ou allocation manuelle dans 10.0.10.0/23 - - Exemple: 10.0.10.20 - ``` - -4. **Construire le nom VM** - ``` - Format: -t--- - Exemple: czp-t003-web-prod-01 - ``` - -5. **Créer l'entrée DNS** - ``` - Format: .t..alliance-boreale.ca - Exemple: web.t003.czp.alliance-boreale.ca → 10.0.10.20 - ``` - -6. **Créer la VM dans Proxmox** - ```bash - qm create 30001 \ - --name czp-t003-web-prod-01 \ - --net0 virtio,bridge=vmbr0,tag=10 \ - --ipconfig0 ip=10.0.10.20/23,gw=10.0.0.1 - ``` - -### 9.3 Migration d'une VM Existante - -**Pour renommer selon le nouveau standard :** - -1. **Identifier les attributs actuels** - ``` - VMID actuel: 104 - Nom actuel: vm-web-01 - IP actuelle: 10.50.100.5 - ``` - -2. **Déterminer les nouveaux attributs** - ``` - Catégorie: Tenant 001 - Type: Web - → VMID: 10001 - → IP: 10.0.10.1 - → Nom: czp-t001-web-prod-01 - → DNS: web.t001.czp.alliance-boreale.ca - ``` - -3. **Planifier la migration** - ``` - - Fenêtre de maintenance - - Backup complet - - Plan de rollback - ``` - -4. **Exécuter la migration** - ```bash - # Arrêter la VM - qm stop 104 - - # Renommer (si VMID change, recréer) - qm set 104 --name czp-t001-web-prod-01 - - # Changer l'IP (dans la VM) - # Mettre à jour DNS - # Redémarrer - qm start 104 - - # Valider - ``` - ---- - -## 10. Exemples Complets - -### 10.1 Infrastructure Minimale (Bronze) - -**Membre : Chezlepro (czp)** - -| VMID | Nom | IP | DNS | Description | -|------|-----|-----|-----|-------------| -| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | DNS Maître | -| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | Orchestration | -| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | Backups | - -### 10.2 Infrastructure Complète (Or) - -**Membre : Chezlepro (czp)** - -| VMID | Nom | IP | DNS | -|------|-----|-----|-----| -| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | -| 02002 | czp-infra-dns-slave1-prod-01 | 10.0.2.11 | dns-slave1.infra.czp.ab.ca | -| 02003 | czp-infra-dns-slave2-prod-01 | 10.0.2.12 | dns-slave2.infra.czp.ab.ca | -| 02101 | czp-infra-vpn-gw-nul-prod-01 | 10.0.2.20 | vpn-nul.infra.czp.ab.ca | -| 02102 | czp-infra-vpn-gw-tli-prod-01 | 10.0.2.21 | vpn-tli.infra.czp.ab.ca | -| 02301 | czp-infra-proxy-haproxy-prod-01 | 10.0.2.30 | proxy.infra.czp.ab.ca | -| 03001 | czp-infra-ceph-mon1-prod-01 | 10.0.1.50 | ceph-mon1.infra.czp.ab.ca | -| 03002 | czp-infra-ceph-mon2-prod-01 | 10.0.1.51 | ceph-mon2.infra.czp.ab.ca | -| 03003 | czp-infra-ceph-mon3-prod-01 | 10.0.1.52 | ceph-mon3.infra.czp.ab.ca | -| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | -| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | -| 04101 | czp-infra-ci-runner1-prod-01 | 10.0.1.60 | ci-runner1.infra.czp.ab.ca | -| 04102 | czp-infra-ci-runner2-prod-01 | 10.0.1.61 | ci-runner2.infra.czp.ab.ca | -| 04201 | czp-infra-git-forgejo-prod-01 | 10.0.1.20 | git.infra.czp.ab.ca | -| 04301 | czp-infra-db-platform-prod-01 | 10.0.1.31 | db.infra.czp.ab.ca | -| 04401 | czp-infra-api-admin-prod-01 | 10.0.1.40 | api.infra.czp.ab.ca | -| 04501 | czp-infra-dashboard-react-prod-01 | 10.0.1.41 | dashboard.infra.czp.ab.ca | - -### 10.3 Tenant Multi-Services - -**Tenant 001 - Client "Acme Corp"** - -| VMID | Nom | IP | DNS | Description | -|------|-----|-----|-----|-------------| -| 10001 | czp-t001-web-prod-01 | 10.0.10.1 | web.t001.czp.ab.ca | Frontend Nginx | -| 10002 | czp-t001-web-prod-02 | 10.0.10.2 | web.t001.czp.ab.ca | Frontend HA | -| 10011 | czp-t001-api-fastapi-prod-01 | 10.0.10.3 | api.t001.czp.ab.ca | Backend API | -| 10021 | czp-t001-db-postgres-prod-01 | 10.0.10.4 | db.t001.czp.ab.ca | PostgreSQL 15 | -| 10031 | czp-t001-cache-redis-prod-01 | 10.0.10.5 | cache.t001.czp.ab.ca | Redis Cache | -| 10041 | czp-t001-worker-celery-prod-01 | 10.0.10.6 | worker.t001.czp.ab.ca | Celery Worker | -| 10061 | czp-t001-web-staging-01 | 10.0.10.7 | web-stg.t001.czp.ab.ca | Staging Web | - -### 10.4 Architecture Fédérée (3 Membres) - -**Services DNS exposés entre membres :** - -| Membre | VMID | Nom | IP Interne | DNS Fédéré | IP Fédérée (172.16.x.x) | -|--------|------|-----|------------|------------|-------------------------| -| Chezlepro | 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | 172.16.1.10 | -| Nuage Libre | 02001 | nul-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.nul.ab.ca | 172.16.2.10 | -| TechnoLibre | 02001 | tli-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.tli.ab.ca | 172.16.3.10 | - -**Note :** Les VMIDs sont identiques (02001) car chaque membre a son propre Proxmox. Les IPs internes sont identiques (10.0.2.10) car isolées par NAT. Les IPs fédérées (172.16.x.x) sont uniques et routées via tunnels VPN. - ---- - -## 11. Migration et Adoption - -### 11.1 Stratégie de Migration - -**Phase 1 : Documentation (Semaine 1-2)** -- [ ] Valider ce standard avec le Cercle Technique -- [ ] Obtenir le consentement de tous les membres actuels -- [ ] Publier dans la documentation officielle -- [ ] Former les administrateurs de chaque membre - -**Phase 2 : Nouveaux Déploiements (Semaine 3+)** -- [ ] Toute nouvelle VM doit suivre ce standard -- [ ] Utiliser les templates Ansible/Terraform mis à jour -- [ ] Documenter dans le registre - -**Phase 3 : Migration Progressive (Mois 2-6)** -- [ ] Inventorier toutes les VMs existantes -- [ ] Prioriser par criticité (services critiques en dernier) -- [ ] Planifier fenêtres de maintenance -- [ ] Migrer par lots (5-10 VMs à la fois) -- [ ] Valider après chaque lot - -**Phase 4 : Consolidation (Mois 7-12)** -- [ ] Vérifier conformité à 100% -- [ ] Mettre à jour toute la documentation -- [ ] Former les nouveaux membres sur ce standard - -### 11.2 Outils de Migration - -**Script d'Audit :** -```bash -#!/bin/bash -# audit-nomenclature.sh -# Vérifie la conformité des VMs au standard v2.0 - -for vmid in $(qm list | awk '{print $1}' | grep -v VMID); do - name=$(qm config $vmid | grep "name:" | awk '{print $2}') - ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,]*\).*/\1/') - - echo "VMID: $vmid | Nom: $name | IP: $ip" - - # Vérifier conformité VMID - if [[ ! $vmid =~ ^(0[1-4][0-9]{3}|[1-9][0-9]{4})$ ]]; then - echo " ⚠️ VMID non conforme" - fi - - # Vérifier conformité nom - if [[ ! $name =~ ^[a-z]+-((infra)|(t[0-9]{3}))-[a-z0-9-]+-prod-[0-9]{2}$ ]]; then - echo " ⚠️ Nom non conforme" - fi - - echo "" -done -``` - -**Script de Génération DNS :** -```bash -#!/bin/bash -# generate-dns-records.sh -# Génère les enregistrements DNS à partir de l'inventaire Proxmox - -MEMBER="czp" -DOMAIN="alliance-boreale.ca" - -echo "; Infrastructure DNS Records" -for vmid in $(qm list | grep "infra" | awk '{print $1}'); do - name=$(qm config $vmid | grep "name:" | awk '{print $2}') - ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,\/]*\).*/\1/') - service=$(echo $name | cut -d'-' -f3-) - - echo "${service}.infra.${MEMBER}.${DOMAIN}. IN A ${ip}" -done - -echo "" -echo "; Tenant DNS Records" -for vmid in $(qm list | grep "\-t[0-9]" | awk '{print $1}'); do - name=$(qm config $vmid | grep "name:" | awk '{print $2}') - ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,\/]*\).*/\1/') - tenant=$(echo $name | grep -oP 't\d{3}') - service=$(echo $name | cut -d'-' -f3) - - echo "${service}.${tenant}.${MEMBER}.${DOMAIN}. IN A ${ip}" -done -``` - -### 11.3 Checklist de Conformité - -**Pour chaque VM :** -- [ ] VMID respecte le format (0CTTII ou TTTII) -- [ ] Nom VM respecte le format -- [ ] IP cohérente avec la fonction -- [ ] Enregistrement DNS créé et fonctionnel -- [ ] Documenté dans l'inventaire -- [ ] Tags Proxmox appropriés -- [ ] Monitoring configuré - ---- - -## 12. Annexes - -### 12.1 Glossaire - -| Terme | Définition | -|-------|------------| -| **VMID** | Identifiant numérique unique d'une VM dans Proxmox | -| **Fédéré** | Membre de L'Alliance Boréale | -| **Tenant** | Client/organisation hébergé par un membre | -| **Infrastructure Fédéré** | Services propres au membre (couches 1-4) | -| **NAT** | Network Address Translation - isole l'espace 10.0.0.0/8 | -| **Espace Fédératif** | Plage 172.16.0.0/12 routée entre membres via tunnels | - -### 12.2 Références - -- **Document 03** : Standards Techniques (Plan d'Adressage IP v3) -- **Document 01** : Charte Fondatrice (Architecture 8 Couches) -- **Document 07** : Guide d'Intégration Technique -- **Document 14** : Structure YAML du Registraire - -### 12.3 Table de Conversion VMID Legacy → v2.0 - -**Si vous avez des VMs avec anciens VMIDs :** - -| Fonction | VMID Legacy | VMID v2.0 | Justification | -|----------|-------------|-----------|---------------| -| DNS Master | 100 | 02001 | Couche 2, DNS (00), Instance 1 | -| DNS Slave | 101 | 02002 | Couche 2, DNS (00), Instance 2 | -| Ansible | 200 | 04001 | Couche 4, Ansible (00), Instance 1 | -| PostgreSQL | 150 | 04301 | Couche 4, DB Platform (30), Instance 1 | -| Web Tenant 1 | 1001 | 10001 | Tenant 001, Instance 01 | -| DB Tenant 1 | 1002 | 10021 | Tenant 001, Instance 21 (DB) | - -### 12.4 FAQ - -**Q : Que faire si j'ai plus de 99 VMs pour un tenant ?** -R : Augmenter le nombre de chiffres pour l'instance (TTTIII au lieu de TTTII), ou subdiviser en sous-tenants (t001a, t001b). - -**Q : Puis-je utiliser des VMIDs personnalisés ?** -R : Non pour les nouveaux déploiements. Le standard doit être respecté pour la cohérence fédérale. - -**Q : Les VMIDs entre membres peuvent-ils être identiques ?** -R : Oui ! Chaque membre a son propre Proxmox. czp-002 peut avoir VMID 02001, et nul-002 aussi. - -**Q : Comment gérer les environnements dev/staging ?** -R : Utiliser le champ `` dans le nom (prod, stg, dev). L'IP peut être dans un sous-réseau dédié (ex: 10.0.100.0/24 pour staging). - -**Q : Faut-il migrer toutes les VMs immédiatement ?** -R : Non. Migration progressive recommandée sur 6-12 mois. Nouveaux déploiements doivent être conformes immédiatement. - -**Q : Comment documenter les exceptions ?** -R : Dans le registre des VMs avec justification. Exceptions doivent être validées par le Cercle Technique. - -### 12.5 Templates de Documentation - -**Template Fiche VM (YAML) :** -```yaml -vm: - vmid: 02001 - name: czp-infra-dns-master-prod-01 - member: czp-001 - category: infrastructure - layer: 2 - service_type: dns - - network: - ip: 10.0.2.10 - subnet: /24 - gateway: 10.0.0.1 - vlan: 2 - - dns: - internal: dns-master.infra.czp.alliance-boreale.ca - federated: dns-master.infra.czp.alliance-boreale.ca - - resources: - cpu: 2 - ram: 4096 - disk: 100G - - backup: - enabled: true - schedule: daily - retention: 30d - - monitoring: - enabled: true - checks: - - dns_query - - process_powerdns - - disk_usage - - tags: - - infrastructure - - dns - - critical - - layer-2 -``` - -**Template Entrée Inventaire Ansible :** -```yaml -# inventory/hosts.yml -all: - children: - infrastructure: - children: - layer_2_network: - hosts: - dns-master.infra.czp.alliance-boreale.ca: - ansible_host: 10.0.2.10 - vmid: 02001 - layer: 2 - service: dns-master - - layer_4_orchestration: - hosts: - ansible.infra.czp.alliance-boreale.ca: - ansible_host: 10.0.1.10 - vmid: 04001 - layer: 4 - service: ansible-controller - - tenants: - children: - tenant_001: - hosts: - web.t001.czp.alliance-boreale.ca: - ansible_host: 10.0.10.1 - vmid: 10001 - tenant: 001 - service: web -``` - ---- - -## 13. Validation et Approbation - -### 13.1 Processus de Validation - -**Ce document doit être validé par :** -- [ ] **Cercle Technique** - Validation technique de la nomenclature -- [ ] **Expert DevOps/SRE** - Validation Proxmox et automatisation -- [ ] **Expert Réseau** - Validation plan IP et DNS -- [ ] **Tous les membres actuels** - Consentement pour adoption - -**Timeline :** -- Semaine 1-2 : Revue et commentaires -- Semaine 3 : Intégration des retours -- Semaine 4 : Vote de consentement -- Semaine 5+ : Publication et déploiement - -### 13.2 Critères d'Acceptation - -Pour que ce standard soit adopté : -- ✅ Aucun membre n'a d'objection majeure (principe de consentement) -- ✅ Compatibilité confirmée avec infrastructures existantes -- ✅ Outils de migration validés et testés -- ✅ Documentation complète et claire -- ✅ Formation prévue pour tous les administrateurs - -### 13.3 Versionnage - -**Version actuelle : 2.0 (DRAFT)** - -Historique des versions : -- v2.0 (2025-10-21) : Création initiale - Nomenclature unifiée complète -- v2.1 (future) : Ajustements après retours terrain - ---- - -## 14. Maintenance du Standard - -### 14.1 Révisions - -Ce document sera révisé : -- **Annuellement** (octobre de chaque année) -- **À la demande** si problème majeur détecté -- **Lors d'évolutions** de l'architecture (nouveau plan IP, etc.) - -### 14.2 Propositions de Modification - -Pour proposer une modification : -1. Ouvrir une issue dans le dépôt Git de gouvernance -2. Documenter le problème et la solution proposée -3. Discussion au Cercle Technique (1 réunion minimum) -4. Vote de consentement si impact majeur -5. Publication de la nouvelle version - -### 14.3 Responsable du Document - -**Responsable principal :** Cercle Technique -**Contact :** technique@alliance-boreale.ca -**Dépôt Git :** https://forge.alliance-boreale.ca/standards/nomenclature - ---- - -## 15. Conclusion - -### 15.1 Récapitulatif - -Ce Standard de Nomenclature v2.0 établit : -- ✅ Un système unifié VMID ↔ IP ↔ Nom ↔ DNS -- ✅ Une organisation claire Infrastructure vs Tenants -- ✅ Une scalabilité jusqu'à 999 tenants par membre -- ✅ Une cohérence avec le Plan d'Adressage IP v3 -- ✅ Des procédures opérationnelles claires -- ✅ Une stratégie de migration progressive - -### 15.2 Bénéfices Attendus - -**Pour les Membres :** -- Gestion simplifiée de l'infrastructure -- Onboarding rapide des nouveaux administrateurs -- Automatisation facilitée (Ansible, Terraform) -- Audit et conformité simplifiés - -**Pour L'Alliance :** -- Interopérabilité renforcée -- Documentation homogène -- Support technique facilité -- Crédibilité professionnelle - -### 15.3 Prochaines Étapes - -1. **Validation** : Soumettre au Cercle Technique (semaine du 28 octobre 2025) -2. **Révision** : Intégrer retours (semaine du 4 novembre 2025) -3. **Vote** : Consentement des membres (semaine du 11 novembre 2025) -4. **Publication** : Version finale (15 novembre 2025) -5. **Formation** : Sessions pour administrateurs (décembre 2025) -6. **Déploiement** : Nouveaux projets conformes (janvier 2026) -7. **Migration** : VMs existantes (jan-déc 2026) - ---- - -**« Une nomenclature claire est le fondement d'une infrastructure maîtrisée. »** - ---- - -**FIN DU DOCUMENT** - -**Standard de Nomenclature v2.0 - L'Alliance Boréale** -**© 2025 L'Alliance Boréale - CC-BY-SA 4.0** -**Document préparé avec l'assistance de Claude (Anthropic)** \ No newline at end of file diff --git a/docs/constitution/01-vision.md b/docs/constitution/01-vision.md deleted file mode 100644 index feab6af..0000000 --- a/docs/constitution/01-vision.md +++ /dev/null @@ -1,5 +0,0 @@ -# Vision -Bâtir une Fédération numérique **souveraine**, **interopérable** et **résiliente**. -- Souveraineté locale (chaque membre administre son 10/8) -- Interopérabilité fédérative (172.16/12 via politiques communes) -- Reproductibilité (SSOT → exports déterministes) diff --git a/docs/constitution/02-gouvernance.md b/docs/constitution/02-gouvernance.md deleted file mode 100644 index 09c4dc1..0000000 --- a/docs/constitution/02-gouvernance.md +++ /dev/null @@ -1,5 +0,0 @@ -# Gouvernance -- Référentiel: ce dépôt fait foi (PR/approbation) -- Identités/PKI: CA fédératives, rôles (machines, services, usagers) -- Décision: RFC > revue > ratification (tags de version) -- Sécurité: revocation/CRL, rotation, audits périodiques diff --git a/docs/constitution/03-standards-techniques.md b/docs/constitution/03-standards-techniques.md deleted file mode 100644 index ae9f404..0000000 --- a/docs/constitution/03-standards-techniques.md +++ /dev/null @@ -1,14 +0,0 @@ -# Standards techniques -## Nommage DNS/PKI -Format: `...` -Ex.: `cloud.app.clp.chezlepro.ca`, `dns.net.dc1.chezlepro.ca`. - -## Plan d’adressage IP v3 -- **10.0.0.0/8**: espace interne par fédéré (non routé entre membres) -- **172.16.0.0/12**: espace fédératif (routé selon politiques) -- **172.20.0.0/16**: tunnels P2P (/30) -- **VNI** = tenant_id × 10000 + VLAN -- **VPN réservé aux couches 1–4** ; couches 5–8: préférence **PKI/TLS** + DNS/anycast. - -## Couches (1–8) -1. infra, 2. réseau, 3. systèmes, 4. sécurité, 5. middleware, 6. applicatif, 7. gouvernance/doc, 8. interface. diff --git a/docs/constitution/04_cadre_conformite_label.md b/docs/constitution/04_cadre_conformite_label.md deleted file mode 100644 index 26ad46d..0000000 --- a/docs/constitution/04_cadre_conformite_label.md +++ /dev/null @@ -1,1010 +0,0 @@ -# Cadre de Conformité & Label de Prestige -## L'Alliance Boréale - -**Version :** 1.0 -**Date :** 12 octobre 2025 -**Révision prévue :** Octobre 2026 - ---- - -## PRÉAMBULE — Pourquoi un Label? - -Le label **Boréal** n'est pas un "certificat" à accrocher au mur. - -C'est une **preuve vivante** que vous incarnez les valeurs de L'Alliance : souveraineté, liberté, sobriété, solidarité, transparence. - -Dans un monde où le "greenwashing" et le "privacy-washing" sont monnaie courante, nous voulons un label qui : -- **Se mérite** (audits rigoureux par les pairs) -- **Se maintient** (recertification annuelle obligatoire) -- **Se vérifie** (preuves publiques, indicateurs transparents) -- **A du sens** (alignement réel avec les pratiques quotidiennes) - -Le label Boréal est notre réponse à la question : *"Comment savoir si une organisation est vraiment éthique, ou si elle fait juste du marketing?"* - ---- - -## PARTIE I — PRINCIPES DIRECTEURS - -### Article 1 — Philosophie du Label - -#### 1.1 Alignement de Valeurs - -**Le label mesure l'alignement avec nos 5 valeurs cardinales :** - -1. **Souveraineté** : Contrôle réel de l'infrastructure et des données -2. **Liberté** : Utilisation de logiciels libres et standards ouverts -3. **Sobriété** : Mesure et réduction de l'empreinte environnementale -4. **Solidarité** : Contribution à la résilience collective -5. **Transparence** : Publication des politiques et indicateurs - -**Ce n'est pas :** -- Un concours de popularité -- Une question de taille d'organisation -- Un passe-droit pour les "amis" -- Un label qu'on achète - -**C'est :** -- Une reconnaissance de l'effort continu -- Une boussole pour progresser -- Un gage de confiance pour les usagers -- Une fierté collective - -#### 1.2 Preuve par l'Évidence - -**"Trust, but verify."** (Faire confiance, mais vérifier) - -Chaque affirmation doit être **prouvable** : -- Vous dites utiliser des logiciels libres? → Montrez la liste -- Vous dites mesurer votre consommation? → Montrez les métriques -- Vous dites avoir des sauvegardes? → Montrez les tests de restauration - -**Types de preuves acceptables :** -- Documents (politiques, procédures) -- Captures d'écran (configurations, dashboards) -- Logs horodatés -- Résultats de tests -- Code source (playbooks, scripts) -- Attestations de tiers (pentests, audits externes) - -**Pas acceptables :** -- "Faites-moi confiance" -- "C'est dans ma tête" -- "Je vais le faire bientôt" - -#### 1.3 Proportionnalité - -**Les exigences doivent être adaptées à la taille et au risque.** - -Une micro-entreprise de 2 personnes ne peut pas avoir la même infrastructure qu'une organisation de 50 employés. - -**Principe :** -- **Minima absolus** : Obligatoires pour tous (ex: sauvegardes testées) -- **Recommandations graduées** : Selon la taille/complexité -- **Progression par paliers** : Bronze → Argent → Or → Platine - -**Exemples de proportionnalité :** -- Micro (<5 employés) : Politique sécurité de 2 pages suffit -- PME (5-20) : Politique de 5-10 pages attendue -- Grande (20+) : Politique complète avec procédures détaillées - -#### 1.4 Pairs Avant Tout - -**L'évaluation est faite PAR les pairs, POUR les pairs.** - -Pas de certificateur externe qui ne comprend rien à notre réalité. -Pas de consultant qui facture 10 000 $ l'audit. -**Des pairs qui se connaissent, se respectent, et se challengent mutuellement.** - -**Avantages :** -- Bienveillance naturelle (on veut tous progresser) -- Exigence réelle (on se connaît, pas de bullshit) -- Apprentissage mutuel (on partage les bonnes pratiques) -- Coût minimal (temps échangé via Banque de Temps) - -**Garde-fous :** -- Pas d'auto-audit -- Pas d'audit par compétiteur direct -- Rotation des auditeurs -- Arbitrage par Cercle Éthique & Conformité si litige - -#### 1.5 Transparence Utile - -**Principe : "Ce qui impacte les usagers est public. Le reste est prouvable sur demande."** - -**Public :** -- Niveau du label (Bronze, Argent, Or, Platine) -- Score global (/100) -- Date d'expiration -- Liens vers politiques publiques (sécurité, vie privée, sobriété) -- Disponibilité (uptime) - -**Privé (mais prouvable aux pairs) :** -- Détails techniques d'infrastructure -- Configurations sensibles -- Résultats complets d'audit (seule la synthèse est publique) -- Incidents mineurs non critiques - -**Justification :** -Trop de transparence = risque sécuritaire (divulgation de vulnérabilités). -Pas assez = perte de confiance. -→ Équilibre intelligent. - ---- - -## PARTIE II — PÉRIMÈTRE DE CONFORMITÉ - -### Article 2 — Six Domaines Évalués - -Le label évalue **6 domaines** interdépendants. Tous sont importants, certains sont pondérés plus fortement. - ---- - -### 2.1 DOMAINE 1 : Gouvernance & Éthique - -**Pourquoi c'est important :** -Sans gouvernance claire et éthique forte, tout le reste n'est que technique vide de sens. - -#### Critères Obligatoires (Bronze minimum) - -1. **Charte interne signée** - - Document définissant mission, valeurs, principes - - Signé par le CA ou équivalent - - Publié (au moins résumé) - - **Preuve :** Résolution CA + lien vers charte - -2. **Registre des responsabilités** - - Qui est responsable de quoi? - - Délégations claires (technique, légal, sécurité, privacy) - - Organigramme à jour - - **Preuve :** Document interne ou page "À propos" sur site web - -3. **Politique de conflits d'intérêts** - - Comment gérer les situations où intérêt personnel ≠ intérêt organisation - - Déclarations obligatoires - - **Preuve :** Section dans charte ou document séparé - -#### Critères Recommandés (Argent+) - -4. **Documentation des décisions importantes** - - Procès-verbaux de réunions stratégiques - - Décisions traçables (Git, wiki, etc.) - - **Preuve :** Accès au dépôt de décisions (peut être privé) - -5. **Code de conduite** - - Comportements attendus/inacceptables - - Processus de plainte - - **Preuve :** Publié sur site web - -6. **Plan stratégique** - - Vision 3-5 ans - - Objectifs mesurables - - Révision annuelle - - **Preuve :** Document partagé avec l'auditeur - -#### Grille de Notation (0-5 points) - -| Score | Description | -|-------|-------------| -| **0** | Aucune gouvernance formelle, chaos total | -| **1** | Informel, tout "dans la tête" du fondateur | -| **2** | Quelques documents de base, mais incomplets | -| **3** | ✅ **BRONZE** — Minima atteints (1+2+3) | -| **4** | ✅ **ARGENT** — Bronze + (4 ou 5) | -| **5** | ✅ **OR/PLATINE** — Tout complet + amélioration continue démontrée | - -**Pondération :** 15% du score total - ---- - -### 2.2 DOMAINE 2 : Sécurité de l'Information - -**Pourquoi c'est important :** -Sans sécurité, il n'y a pas de souveraineté. Une faille chez un membre met en péril toute l'Alliance. - -#### Critères Obligatoires (Bronze minimum) - -1. **Gestion des vulnérabilités** - - Processus de veille (CVE, alertes sécurité) - - SLA de correction : Critique <48h, Élevé <7j, Moyen <30j - - **Preuve :** Logs de mises à jour, politique écrite - -2. **MFA pour administrateurs** - - Authentification multi-facteurs obligatoire pour tous les accès admin - - TOTP minimum (Authy, Google Authenticator, etc.) - - **Preuve :** Capture d'écran config ou test en direct - -3. **Sauvegardes 3-2-1 testées** - - **3** copies (production + 2 backups) - - **2** supports différents (disque + cloud ou autre site) - - **1** copie hors site (géographiquement séparée) - - **Testées** : Restauration complète réussie dans les 90 derniers jours - - **Preuve :** Rapport de test de restauration avec date + screenshots - -#### Critères Recommandés (Argent+) - -4. **Réponse à incident documentée** - - Procédure écrite : qui fait quoi en cas d'incident - - Contacts d'urgence - - Post-mortem des incidents passés - - **Preuve :** Document de procédure + 1 exemple de post-mortem - -5. **Chiffrement des données sensibles** - - Données au repos : chiffrées (LUKS, dm-crypt) - - Données en transit : TLS 1.3 minimum - - **Preuve :** Configuration serveurs + test SSL Labs - -6. **Segmentation réseau** - - DMZ, réseaux isolés - - Firewall avec règles strictes - - **Preuve :** Diagramme réseau + règles firewall - -#### Critères Avancés (Or+) - -7. **Tests de pénétration annuels** - - Pentest externe par tiers ou membre pair - - Rapport partagé avec les pairs (confidentiel) - - Plan de correction - -8. **Surveillance proactive (SIEM/IDS)** - - Logs centralisés et analysés - - Alertes automatiques - - **Preuve :** Accès au dashboard SIEM - -#### Grille de Notation (0-5 points) - -| Score | Description | -|-------|-------------| -| **0** | Aucune sécurité (serveur root sans mdp...) | -| **1** | Sécurité "de base" mais lacunes graves | -| **2** | Quelques mesures, mais sauvegardes non testées ou MFA absent | -| **3** | ✅ **BRONZE** — (1+2+3) Minima atteints | -| **4** | ✅ **ARGENT** — Bronze + (4 ou 5) | -| **5** | ✅ **OR/PLATINE** — Tout complet + (7 ou 8) | - -**Pondération :** 25% du score total (le plus important !) - ---- - -### 2.3 DOMAINE 3 : Vie Privée & Loi 25 - -**Pourquoi c'est important :** -Respect de la vie privée = valeur cardinale. Conformité légale = survie de l'organisation. - -#### Critères Obligatoires (Bronze minimum) - -1. **Registre des traitements** - - Liste de tous les traitements de données personnelles - - Pour chaque traitement : finalité, base légale, durée conservation, destinataires - - **Preuve :** Fichier Excel/YAML ou outil RGPD + accès - -2. **Base légale claire** - - Consentement, contrat, intérêt légitime, obligation légale ? - - Documenté pour chaque traitement - - **Preuve :** Inclus dans registre des traitements - -3. **Politique de confidentialité publiée** - - Accessible publiquement (site web) - - Langage clair, pas juste du jargon juridique - - Mise à jour récente (<12 mois) - - **Preuve :** Lien vers la politique - -#### Critères Recommandés (Argent+) - -4. **DPIA (si nécessaire)** - - Analyse d'impact si traitement à risque élevé - - Documentée et revue - - **Preuve :** Document DPIA (peut être anonymisé) - -5. **Droits des personnes** - - Processus pour exercer droits (accès, rectification, suppression, portabilité) - - Formulaire ou email dédié - - Délai de réponse <30 jours - - **Preuve :** Page web ou procédure documentée - -6. **Minimisation des données** - - Ne collecter que le strict nécessaire - - Pas de "on sait jamais, ça peut servir" - - **Preuve :** Revue du registre + justification de chaque champ collecté - -#### Critères Avancés (Or+) - -7. **Chiffrement bout-à-bout** - - Pour communications sensibles (emails, fichiers) - - **Preuve :** Démo ou config - -8. **Responsable de la protection des données (RPD)** - - Personne désignée, formée - - Point de contact connu - - **Preuve :** Nom publié + contact - -#### Grille de Notation (0-5 points) - -| Score | Description | -|-------|-------------| -| **0** | Aucune politique vie privée, données collectées n'importe comment | -| **1** | Politique copier-coller générique, non appliquée | -| **2** | Politique présente mais registre incomplet | -| **3** | ✅ **BRONZE** — (1+2+3) Minima atteints | -| **4** | ✅ **ARGENT** — Bronze + (4+5) | -| **5** | ✅ **OR/PLATINE** — Tout complet + (7 ou 8) | - -**Pondération :** 20% du score total - ---- - -### 2.4 DOMAINE 4 : Interopérabilité & Fédération - -**Pourquoi c'est important :** -L'Alliance repose sur l'interopérabilité. Sans elle, on redevient des silos. - -#### Critères Obligatoires (Bronze minimum) - -1. **DNS fédéré opérationnel** - - Zones hébergées en secondaire chez ≥2 pairs - - AXFR/NOTIFY fonctionnels - - Latence <50ms - - **Preuve :** Tests dig + logs PowerDNS - -2. **Métadonnées de fédération publiées** - - Endpoints SSO (.well-known/openid-configuration ou équivalent) - - Endpoints DNS (ns1.membre.ca avec IP) - - Endpoints VPN (wireguard config ou équivalent) - - **Preuve :** URLs accessibles publiquement - -#### Critères Recommandés (Argent+) - -3. **Identités fédérées (SSO)** - - Keycloak, OpenID Connect, SAML - - Intégration avec autres membres de l'Alliance - - **Preuve :** Test de connexion SSO entre 2 membres - -4. **Standards ouverts pour email** - - SMTP, IMAP (pas d'API propriétaire) - - SPF, DKIM, DMARC configurés - - **Preuve :** Résultats mail-tester.com >8/10 - -5. **Partage de fichiers interopérable** - - WebDAV, CalDAV, CardDAV - - Nextcloud, ownCloud ou compatible - - **Preuve :** Test de connexion depuis client standard - -#### Critères Avancés (Or+) - -6. **API publiques documentées** - - OpenAPI/Swagger pour services exposés - - Documentation accessible - - **Preuve :** Lien vers docs API - -7. **Participation active à la fédération** - - Contribution aux outils communs (playbooks Ansible, scripts) - - Support technique aux pairs - - **Preuve :** Commits Git + témoignages - -#### Grille de Notation (0-5 points) - -| Score | Description | -|-------|-------------| -| **0** | Aucune interopérabilité, silo complet | -| **1** | Quelques standards ouverts mais pas fédéré | -| **2** | DNS configuré mais non fonctionnel ou métadonnées absentes | -| **3** | ✅ **BRONZE** — (1+2) DNS + métadonnées OK | -| **4** | ✅ **ARGENT** — Bronze + SSO ou email ou fichiers | -| **5** | ✅ **OR/PLATINE** — Tout complet + contribution active | - -**Pondération :** 15% du score total - ---- - -### 2.5 DOMAINE 5 : Opérations & Résilience - -**Pourquoi c'est important :** -La fiabilité est non négociable. Si ton service est down, les usagers souffrent et l'Alliance est fragilisée. - -#### Critères Obligatoires (Bronze minimum) - -1. **Monitoring actif** - - Icinga, Prometheus, Netdata ou équivalent - - Surveillance 24/7 (automatisée) - - Alertes configurées (email/SMS/Matrix) - - **Preuve :** Accès au dashboard + historique - -2. **Journaux (logs) conservés ≥90 jours** - - Logs systèmes, applicatifs, accès - - Centralisés si possible - - **Preuve :** Montrer les logs d'il y a 60-90 jours - -3. **Tests de restauration trimestriels** - - Sauvegardes testées tous les 3 mois minimum - - Documenté avec dates et résultats - - **Preuve :** Rapports des 2 derniers tests - -#### Critères Recommandés (Argent+) - -4. **Gestion de capacité** - - Surveillance des ressources (CPU, RAM, disque) - - Prévisions de croissance - - Alertes avant saturation - - **Preuve :** Dashboard Grafana + tendances - -5. **Runbooks et documentation** - - Procédures d'incident documentées - - "How-to" pour tâches courantes - - Wiki ou dépôt Git - - **Preuve :** Accès au wiki + liste des runbooks - -6. **SLA publiés** - - Engagement de disponibilité (ex: 99,5%) - - Objectif de temps de rétablissement (RTO) - - Publié sur page de statut - - **Preuve :** Lien vers SLA - -#### Critères Avancés (Or+) - -7. **Haute disponibilité (HA)** - - Services critiques redondants - - Failover automatique - - **Preuve :** Test de bascule réussi - -8. **Plan de continuité d'activité (PCA)** - - Document complet : quoi faire si datacenter détruit - - Testé annuellement - - **Preuve :** Document PCA + rapport de test - -#### Grille de Notation (0-5 points) - -| Score | Description | -|-------|-------------| -| **0** | Aucun monitoring, aucune sauvegarde testée | -| **1** | Monitoring basique mais sauvegardes non testées | -| **2** | Monitoring + sauvegardes mais logs <90j ou tests >3 mois | -| **3** | ✅ **BRONZE** — (1+2+3) Minima atteints | -| **4** | ✅ **ARGENT** — Bronze + (4+5) | -| **5** | ✅ **OR/PLATINE** — Tout complet + HA ou PCA | - -**Pondération :** 15% du score total - ---- - -### 2.6 DOMAINE 6 : Sobriété Numérique - -**Pourquoi c'est important :** -L'une de nos 5 valeurs cardinales. Si on ne mesure pas, on ne peut pas réduire. - -#### Critères Obligatoires (Bronze minimum) - -1. **Mesure de consommation énergétique** - - Serveurs : mesure via PDU intelligent, IPMI, ou factures électricité - - Estimation si mesure directe impossible (mais justifiée) - - **Preuve :** Tableau de conso (kWh/mois) sur 3 mois minimum - -2. **Indicateurs de sobriété publiés** - - PUE (Power Usage Effectiveness) ou équivalent - - CO2/utilisateur ou CO2/service - - Publié sur site web ou registraire - - **Preuve :** Lien vers les indicateurs - -#### Critères Recommandés (Argent+) - -3. **Optimisation démontrée** - - Actions concrètes pour réduire l'empreinte : - - Mise en veille/extinction de VMs inutilisées - - Consolidation de serveurs - - Migration vers matériel plus efficient - - **Preuve :** Comparaison avant/après (métriques) - -4. **Choix matériels/logiciels frugaux** - - Hardware reconditionné privilégié - - Logiciels légers (pas de bloatware) - - **Preuve :** Liste du matériel + âge + justifications - -5. **Compensation carbone (optionnelle mais valorisée)** - - Si émissions incompressibles, compensation via projets certifiés - - **Preuve :** Certificats ou reçus - -#### Critères Avancés (Or+) - -6. **Infrastructure 100% renouvelable** - - Électricité verte certifiée (Hydro-Québec = déjà ~99% hydro ✅) - - Datacenter alimenté par énergies renouvelables - - **Preuve :** Factures énergie verte ou certification datacenter - -7. **Analyse de cycle de vie (ACV)** - - Empreinte totale : fabrication + usage + fin de vie - - Documentée - - **Preuve :** Rapport ACV simplifié - -#### Grille de Notation (0-5 points) - -| Score | Description | -|-------|-------------| -| **0** | Aucune mesure, aucune conscience de l'impact | -| **1** | Conscience du problème mais pas de mesure | -| **2** | Mesure partielle, indicateurs incomplets | -| **3** | ✅ **BRONZE** — (1+2) Mesure + indicateurs publiés | -| **4** | ✅ **ARGENT** — Bronze + (3 ou 4) optimisation démontrée | -| **5** | ✅ **OR/PLATINE** — Tout complet + (6 ou 7) excellence | - -**Pondération :** 10% du score total - ---- - -## PARTIE III — NIVEAUX DE LABEL - -### Article 3 — Les Quatre Niveaux - -Le label Boréal existe en **4 niveaux progressifs** : - -``` -Bronze → Argent → Or → Platine - (Base) (Solide) (Référence) (Excellence) -``` - -Chaque niveau a des exigences claires et un badge visuel distinct. - ---- - -### 3.1 Boréal Bronze — Base Conforme - -**Public cible :** Nouveaux membres, organisations en début de parcours - -**Exigences :** -- ✅ **Minima atteints sur les 6 domaines** - - Gouvernance : Charte + Registre responsabilités + Conflits d'intérêts - - Sécurité : Vulnérabilités gérées + MFA admins + Sauvegardes 3-2-1 testées - - Vie privée : Registre traitements + Base légale + Politique publiée - - Interopérabilité : DNS fédéré + Métadonnées publiées - - Opérations : Monitoring + Logs 90j + Tests restauration trimestriels - - Sobriété : Mesure conso + Indicateurs publiés - -- ✅ **Score minimum : 60/100** - -- ✅ **Aucune non-conformité majeure ouverte** - - Pas de faille de sécurité critique non corrigée - - Pas de violation de la Loi 25 avérée - - Pas d'indisponibilité >24h sans raison valable - -**Validité :** 12 mois - -**Badge :** -- Couleur : Brun/Bronze -- Texte : "Boréal Bronze 2025" -- Usage autorisé sur site web, signatures email - -**Message :** *"Nous respectons les fondamentaux de l'Alliance Boréale."* - ---- - -### 3.2 Boréal Argent — Solidité Opérationnelle - -**Public cible :** Membres établis avec pratiques solides - -**Exigences :** -- ✅ Tout ce qui est dans Bronze -- ✅ **Score minimum : 70/100** -- ✅ **Audit pair semestriel sans réserve majeure** - - 2 audits/an au lieu d'1 - - Pas de "réserve majeure" (réserves mineures OK) -- ✅ **Transparence renforcée :** - - Page de statut publique (uptime, incidents) - - Runbooks publiés (au moins procédures de base) - - Indicateurs de sobriété détaillés - -**Validité :** 12 mois - -**Badge :** -- Couleur : Argenté -- Texte : "Boréal Argent 2025" - -**Message :** *"Nous sommes transparents, fiables, et améliorés continuellement."* - ---- - -### 3.3 Boréal Or — Référence d'Excellence - -**Public cible :** Leaders de l'Alliance, modèles pour les autres - -**Exigences :** -- ✅ Tout ce qui est dans Argent -- ✅ **Score minimum : 85/100** -- ✅ **Exercices de crise annuels** - - Simulation d'incident majeur (ex: perte datacenter) - - Documenté + rapport + améliorations apportées -- ✅ **Indicateurs de sobriété publiés et exemplaires** - - Réduction démontrée année après année - - Ou déjà très bas (≤50% de la moyenne du secteur) -- ✅ **Tests de restauration réussis sur 12 derniers mois** - - Preuves des 4 tests trimestriels - - 100% de succès - -**Validité :** 12 mois - -**Badge :** -- Couleur : Doré -- Texte : "Boréal Or 2025" - -**Message :** *"Nous sommes une référence technique et éthique."* - ---- - -### 3.4 Boréal Platine — Excellence Continue - -**Public cible :** Les meilleurs des meilleurs, rares - -**Exigences :** -- ✅ Tout ce qui est dans Or -- ✅ **Score minimum : 90/100** -- ✅ **Amélioration continue démontrée** - - Augmentation du score d'au moins 5 points sur 2 ans - - Ou maintien à 95+ pendant 2 ans -- ✅ **Plan de continuité d'activité (PCA) documenté ET testé** - - Test réussi dans les 12 derniers mois - - Rapport public (synthèse) -- ✅ **Chiffrement bout-à-bout quand pertinent** - - Emails sensibles, fichiers, communications -- ✅ **Preuves tierces** - - Pentest annuel partagé aux pairs (confidentiel) - - Ou certification externe reconnue (ISO 27001, SOC 2) - -**Validité :** 12 mois (comme les autres, pas d'exception) - -**Badge :** -- Couleur : Platine/Blanc brillant -- Texte : "Boréal Platine 2025" - -**Message :** *"Nous incarnons l'excellence absolue de l'Alliance Boréale."* - ---- - -## PARTIE IV — SYSTÈME DE POINTS - -### Article 4 — Calcul du Score Global - -Le score global est calculé sur **/100 points** en fonction des 6 domaines. - -#### 4.1 Notation par Domaine (0-5) - -Chaque domaine est noté de **0 à 5 points** selon la grille de chaque domaine (voir Partie II). - -#### 4.2 Pondération - -Les domaines ont des poids différents selon leur importance : - -| Domaine | Poids | Points Max | -|---------|-------|------------| -| 1. Gouvernance & Éthique | 15% | 15 pts | -| 2. Sécurité de l'Information | 25% | 25 pts | -| 3. Vie Privée & Loi 25 | 20% | 20 pts | -| 4. Interopérabilité & Fédération | 15% | 15 pts | -| 5. Opérations & Résilience | 15% | 15 pts | -| 6. Sobriété Numérique | 10% | 10 pts | -| **TOTAL** | **100%** | **100 pts** | - -#### 4.3 Formule de Calcul - -``` -Score_Total = Σ (Note_Domaine × Poids_Domaine) - -Avec : -- Note_Domaine : de 0 à 5 -- Poids_Domaine : % du domaine - -Exemple : -Domaine 1 (Gouvernance) : Note 4/5 × 15% = 12/15 pts -Domaine 2 (Sécurité) : Note 5/5 × 25% = 25/25 pts -Domaine 3 (Vie privée) : Note 3/5 × 20% = 12/20 pts -Domaine 4 (Interop) : Note 4/5 × 15% = 12/15 pts -Domaine 5 (Ops) : Note 4/5 × 15% = 12/15 pts -Domaine 6 (Sobriété) : Note 3/5 × 10% = 6/10 pts - -Score_Total = 12+25+12+12+12+6 = 79/100 -→ Label : Argent (70-84) -``` - -#### 4.4 Seuils par Niveau - -| Niveau | Score Min | Score Max | -|--------|-----------|-----------| -| Bronze | 60 | 69 | -| Argent | 70 | 84 | -| Or | 85 | 89 | -| Platine | 90 | 100 | - -**Note :** Un score élevé ne suffit PAS. Les exigences qualitatives de chaque niveau doivent aussi être remplies. - ---- - -## PARTIE V — PROCESSUS D'ÉVALUATION - -### Article 5 — Demande de Labellisation - -#### 5.1 Qui Peut Demander? - -- Tout membre actif de l'Alliance (pas les probatoires) -- Demande volontaire (pas obligatoire, mais fortement encouragée) -- Un membre peut demander n'importe quel niveau (pas forcément Bronze d'abord) - -#### 5.2 Procédure de Demande - -**Étape 1 : Auto-évaluation (par le membre)** - -Le membre remplit la **grille d'auto-évaluation** (voir Annexe A) : -- Note estimée pour chaque domaine -- Liste des preuves disponibles -- Identification des lacunes - -**Durée :** 2-4 heures - -**Étape 2 : Soumission** - -Le membre soumet sa demande au **Cercle Éthique & Conformité** : -- Formulaire de demande -- Auto-évaluation complétée -- Niveau visé (Bronze, Argent, Or, Platine) -- Liste des documents/preuves joints - -**Étape 3 : Revue préliminaire (Cercle Éthique, 7 jours)** - -Le Cercle vérifie : -- La complétude du dossier -- L'éligibilité (membre actif, pas de non-conformité majeure) -- Le niveau visé est-il réaliste? - -**Décision :** -- ✅ Acceptée → Passage à l'audit -- ⚠️ Ajournée → Compléments demandés -- ❌ Refusée → Raisons expliquées (très rare) - -**Étape 4 : Audit pair-à-pair (voir Document 5)** - -Un audit complet est mené selon le **Protocole d'Audit Pair-à-Pair**. - -**Durée :** 2-3 semaines - -**Étape 5 : Décision (Cercle Éthique, 7 jours après audit)** - -Le Cercle examine le rapport d'audit et décide : -- ✅ Label accordé au niveau demandé -- 🔽 Label accordé à un niveau inférieur (ex: demande Or → octroi Argent) -- ⚠️ Label sous réserve (plan d'action de 30-90j requis) -- ❌ Label refusé (lacunes trop importantes) - -**Étape 6 : Publication (J+1)** - -Si accordé : -- Badge remis au membre -- Fiche au Registraire mise à jour -- Annonce dans #annonces (Matrix) -- Certificat numérique signé (PGP) - ---- - -## PARTIE VI — SURVEILLANCE CONTINUE - -### Article 6 — Entre Deux Audits - -**Le label n'est pas un "acquis". Il doit être maintenu.** - -#### 6.1 Déclarations d'Incidents - -**Obligation :** Tout incident majeur doit être déclaré sous **24h** : -- Indisponibilité >1h -- Faille de sécurité exploitée -- Perte de données -- Violation de vie privée - -**Procédure :** -- Email à incidents@alliance-boreale.ca -- Ou issue sur la forge (privée) -- Description, impact, actions prises - -**Conséquence sur le label :** -- Déclaration faite = OK, pas de pénalité (on apprend de nos erreurs) -- Déclaration NON faite = Suspension possible du label - -#### 6.2 Revue Semestrielle Légère (Pour Argent+) - -Les membres Argent, Or et Platine ont une **revue légère tous les 6 mois** : -- Pas un audit complet (trop lourd) -- Vérification des indicateurs clés : - - Disponibilité (uptime) - - Tests de sauvegarde (dates) - - Indicateurs de sobriété (évolution) -- Durée : 1h de visio + revue docs (15 min) - -**Si problème détecté :** Plan d'action ou audit de suivi déclenché - -#### 6.3 Audits Surprises (Si Suspicion) - -**Déclencheur :** -- Signalement par un pair -- Incident grave non déclaré -- Plainte d'un usager -- Rumeur persistante - -**Processus :** -- Le Cercle Éthique décide (consentement) -- Audit surprise sous 7 jours -- Le membre doit coopérer (obligation) - -**Refus de coopérer = Suspension immédiate du label** - ---- - -## PARTIE VII — RECERTIFICATION ANNUELLE - -### Article 7 — Renouvellement du Label - -**Tous les labels expirent après 12 mois. Pas d'exception.** - -#### 7.1 Processus de Recertification - -**6 mois avant expiration :** -- Notification automatique au membre -- Rappel des exigences - -**3 mois avant expiration :** -- Planification de l'audit de recertification -- Désignation de l'auditeur - -**1 mois avant expiration :** -- Audit de recertification complet -- Même rigueur que l'audit initial - -**À expiration :** -- Si audit OK → Label renouvelé 12 mois -- Si audit NOK → Label expiré, passage en "Sans label" (mais membre actif) - -#### 7.2 Possibilité de Monter de Niveau - -La recertification est l'occasion de demander un niveau supérieur : -- Bronze → Argent -- Argent → Or -- Or → Platine - -Même processus, mais exigences du niveau supérieur évidemment. - ---- - -## PARTIE VIII — RÈGLES D'USAGE DU LABEL - -### Article 8 — Marque et Badge - -#### 8.1 Droit d'Usage - -**Le label "Boréal" est une marque collective de L'Alliance Boréale.** - -**Droit d'usage accordé pour :** -- La durée de validité du label -- Usage sur site web, signatures email, documents officiels -- Mention dans communications (ex: "Nous sommes Boréal Or 2025") - -**Obligation :** -- Toujours mentionner l'année et le niveau -- Lien vers la fiche Registraire (preuve vérifiable) - -#### 8.2 Prohibitions - -**Usage interdit :** -- Utiliser le badge si label expiré -- Prétendre à un niveau supérieur -- Modifier le logo (couleurs, proportions) -- Créer des variantes non autorisées -- Laisser entendre un endorsement de l'Alliance sans base factuelle - -**Sanction :** Suspension immédiate du label + possibilité de radiation - -#### 8.3 Visuels Officiels - -**Kit graphique fourni par l'Alliance :** -- Logos SVG (Bronze, Argent, Or, Platine) -- Badges PNG (haute résolution) -- Guide d'utilisation (tailles, espaces, couleurs) - -**Disponible sur :** git.alliance-boreale.ca/alliance-boreale/brand/ - ---- - -## ANNEXE A — Grille d'Auto-Évaluation - -**À remplir par le membre demandeur** - -### Domaine 1 : Gouvernance & Éthique - -| Critère | Oui/Non | Preuve Disponible | Notes | -|---------|---------|-------------------|-------| -| Charte interne signée | ☐ | ☐ | | -| Registre des responsabilités | ☐ | ☐ | | -| Politique conflits d'intérêts | ☐ | ☐ | | -| Documentation des décisions | ☐ | ☐ | | -| Code de conduite | ☐ | ☐ | | -| Plan stratégique | ☐ | ☐ | | - -**Note estimée (0-5) :** _____ / 5 - -### Domaine 2 : Sécurité de l'Information - -[Même structure pour les 6 domaines...] - -### Score Total Estimé - -| Domaine | Note /5 | Poids | Points | -|---------|---------|-------|--------| -| 1. Gouvernance | ____ | 15% | ____ | -| 2. Sécurité | ____ | 25% | ____ | -| 3. Vie privée | ____ | 20% | ____ | -| 4. Interop | ____ | 15% | ____ | -| 5. Ops | ____ | 15% | ____ | -| 6. Sobriété | ____ | 10% | ____ | -| **TOTAL** | | **100%** | **____/100** | - -**Niveau visé :** ☐ Bronze ☐ Argent ☐ Or ☐ Platine - ---- - -## ANNEXE B — Exemples de Preuves Acceptables - -### Pour chaque critère, voici des exemples de preuves : - -**Charte interne signée :** -- PDF de la charte avec signatures -- Résolution CA d'adoption -- Lien vers page web publique - -**MFA pour admins :** -- Capture d'écran de la config (SSH, panel admin) -- Test en direct devant l'auditeur - -**Sauvegardes 3-2-1 testées :** -- Rapport de test de restauration avec date -- Screenshots du processus -- Logs de backup (anonymisés OK) - -**Registre des traitements (RGPD) :** -- Fichier Excel/YAML -- Ou outil RGPD (capture d'écran) - -**Indicateurs de sobriété :** -- Page web publique avec graphiques -- Ou document partagé avec auditeur - ---- - -## ANNEXE C — Modèle de Résolution Interne - -``` -RÉSOLUTION DU CONSEIL D'ADMINISTRATION -[Nom de l'organisation] - -Objet : Demande de Label Boréal - -IL EST RÉSOLU : - -1. De demander l'attribution du label "Boréal [Niveau]" - auprès de L'Alliance Boréale ; - -2. D'accepter le processus d'audit pair-à-pair selon - le Cadre de Conformité & Label de Prestige v1.0 ; - -3. D'autoriser la publication de notre fiche au Registraire - avec indication du label obtenu ; - -4. De s'engager à maintenir les exigences du label pendant - toute sa durée de validité ; - -5. D'autoriser l'usage du badge "Boréal [Niveau]" sur notre - site web et communications selon les règles d'usage. - -Adopté à [Ville], le [Date]. - -Signatures : -[Président] : _________________ -[Secrétaire] : _________________ -``` - ---- - -**FIN DU CADRE DE CONFORMITÉ & LABEL DE PRESTIGE** - -*"Le label n'est pas une fin. C'est un voyage."* - -🌲 **L'Alliance Boréale** diff --git a/docs/constitution/05_Architecture_Reference_Standards_Techniques.md b/docs/constitution/05_Architecture_Reference_Standards_Techniques.md deleted file mode 100644 index e5bc6dd..0000000 --- a/docs/constitution/05_Architecture_Reference_Standards_Techniques.md +++ /dev/null @@ -1,1871 +0,0 @@ -# Document 5 : Architecture de Référence & Standards Techniques -## L'Alliance Boréale — Couches 1 à 4 - -**Version:** 1.0 -**Date:** 23 octobre 2025 -**Statut:** Document opérationnel -**Adopté par :** Cercle Opérationnel -**Licence:** CC BY-SA 4.0 - ---- - -## PRÉAMBULE - -L'interopérabilité ne se décrète pas. Elle se construit sur des **standards partagés** et des **conventions claires**. - -**Ce document établit les règles techniques pour les couches 1 à 4** de l'architecture boréale : -- Couche 1 : Physique (serveurs, réseau) -- Couche 2 : Réseau (DNS, connectivité) -- Couche 3 : Stockage (volumes, backups) -- Couche 4 : Orchestration (IaC, automatisation) - -**Principe fondamental : Nomenclature mnémotechnique** - -> *"Un nom doit se comprendre sans documentation. Si tu dois chercher dans un wiki pour savoir ce que signifie `srv-xz42-prod`, le nom est mauvais."* - -**Nos conventions suivent trois règles d'or :** - -1. **Clarté > Concision** - Préférer `mail-prod-01` à `mp1` (3 caractères économisés ne valent pas la confusion). - -2. **Patterns répétés** - Si un pattern fonctionne pour le membre A, il doit fonctionner pour le membre B (prédictibilité). - -3. **Lecture par humains ET machines** - Les noms doivent être parsables automatiquement SANS sacrifier la lisibilité humaine. - -**Ce document est vivant.** Il évoluera avec nos apprentissages. Toute proposition d'amélioration est bienvenue (pull request sur Registraire). - ---- - -## SECTION 1 : CONVENTIONS DE NOMENCLATURE - -### 1.1 Membres — Identifiants et Slugs - -Chaque membre possède **deux identifiants** : - -#### ID Numérique (Machine-Readable) - -**Format :** `mXXX` où XXX est un entier séquentiel sur 3 chiffres. - -**Exemples :** -- `m001` : Premier membre (fondateur) -- `m002` : Deuxième membre -- `m042` : Quarante-deuxième membre - -**Usage :** -- Clé primaire dans Registraire YAML -- Références internes (décisions, audits) -- URLs de vérification (`registraire.alliance-boreale.ca/membres/m001`) - -**Avantages :** -- Unique -- Court -- Facile à parser -- Ordre d'arrivée visible - -**Inconvénients :** -- Pas mnémotechnique (on ne sait pas qui est m042 sans chercher) - ---- - -#### Slug Textuel (Human-Readable) - -**Format :** `[a-z0-9-]{3,20}` (minuscules, chiffres, tirets, 3-20 caractères) - -**Exemples :** -- `chezlepro` (Chez le Pro) -- `technolibre` (TechnoLibre) -- `coop-nordique` (Coopérative Nordique) -- `hebergement-ethique` (Hébergement Éthique Inc.) - -**Règles :** -- Pas d'accents (compatibilité DNS/URLs) -- Pas d'espaces (remplacés par tirets) -- Pas de caractères spéciaux (@, %, &, etc.) -- Unique dans L'Alliance (vérification lors de l'admission) - -**Usage :** -- Sous-domaines DNS (`chezlepro.boreal.ca`) -- Communication informelle (Matrix, email) -- URLs publiques (`chezlepro.ca`) - -**Avantages :** -- Mnémotechnique (on sait immédiatement de qui on parle) -- Identité de marque préservée -- SEO-friendly - ---- - -#### Mapping ID ↔ Slug - -**Fichier de référence :** `registraire/membres/[ID]-[slug].yml` - -**Exemple :** -```yaml -# Fichier : registraire/membres/m001-chezlepro.yml -member_id: m001 -slug: chezlepro -legal_name: "Chez le Pro Technologies Inc." -... -``` - -**Convention de nommage du fichier :** -Toujours `[ID]-[slug].yml` pour lier visuellement les deux identifiants. - ---- - -### 1.2 Domaines — Architecture DNS Fédérée - -#### Domaine Racine de la Fédération - -**Décision stratégique requise (à valider par Cercle Stratégique) :** - -**Option A : `boreal.ca`** -- Court, mémorable -- Identité forte (référence directe au nom de l'Alliance) -- Disponibilité à vérifier - -**Option B : `alliance-boreale.ca`** -- Explicite (aucune ambiguïté) -- Plus long (impact sur sous-domaines) -- Probablement disponible - -**Option C : `.coop` ou autre TLD** -- Signal identitaire (mouvement coopératif) -- TLD `.coop` = réservé aux coopératives (pas applicable aux OBNL) - -**Recommandation temporaire (ce document) :** -Utiliser `boreal.ca` dans les exemples, mais décision finale à valider avant déploiement. - ---- - -#### Structure des Sous-domaines - -**Hiérarchie standard :** - -``` -boreal.ca (racine fédérée) -│ -├── membre.[slug].boreal.ca → Zone déléguée au membre -│ ├── mail.[slug].boreal.ca → Service email -│ ├── cloud.[slug].boreal.ca → Nextcloud/stockage -│ ├── matrix.[slug].boreal.ca → Serveur Matrix -│ ├── status.[slug].boreal.ca → Page de statut -│ └── www.[slug].boreal.ca → Site web (optionnel) -│ -├── outils.boreal.ca → Outils communs L'Alliance -│ ├── registraire.boreal.ca → Registraire public -│ ├── forge.boreal.ca → Forge logicielle -│ ├── wiki.boreal.ca → Documentation -│ └── matrix.boreal.ca → Matrix fédéral -│ -└── ns[1-3].boreal.ca → Serveurs DNS autoritaires - ├── ns1.boreal.ca → Serveur primaire (membre fondateur) - ├── ns2.boreal.ca → Serveur secondaire (autre membre) - └── ns3.boreal.ca → Serveur tertiaire (optionnel) -``` - ---- - -#### Exemple Concret : Membre "Chez le Pro" (m001 / chezlepro) - -**Domaine délégué :** `chezlepro.boreal.ca` - -**Services standards :** -``` -mail.chezlepro.boreal.ca → Postfix/Dovecot -cloud.chezlepro.boreal.ca → Nextcloud -matrix.chezlepro.boreal.ca → Synapse -status.chezlepro.boreal.ca → Upptime/Cachet -www.chezlepro.boreal.ca → Site vitrine -``` - -**Serveurs DNS (internes) :** -``` -ns1.chezlepro.boreal.ca → Serveur DNS primaire du membre -ns2.chezlepro.boreal.ca → Serveur DNS secondaire (si redondance) -``` - -**Zone DNS déléguée (fichier) :** -`registraire/dns/zones/chezlepro.boreal.ca.zone` - ---- - -#### Services Réservés (Tous les Membres) - -**Ces sous-domaines DOIVENT suivre la convention :** - -| Service | Sous-domaine | Protocole | Port | Obligatoire ? | -|---------|--------------|-----------|------|---------------| -| Email (SMTP) | `mail.[slug].boreal.ca` | SMTP/S | 25, 587 | ✅ Oui | -| Email (IMAP) | `mail.[slug].boreal.ca` | IMAP/S | 143, 993 | ✅ Oui | -| Webmail | `webmail.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé | -| Stockage cloud | `cloud.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé | -| Calendrier/Contacts | `dav.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé | -| Messagerie Matrix | `matrix.[slug].boreal.ca` | HTTPS | 8448 | ⚠️ Recommandé | -| Status page | `status.[slug].boreal.ca` | HTTPS | 443 | ✅ Oui | -| Monitoring (Prometheus) | `prometheus.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé | -| Monitoring (Grafana) | `grafana.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé | - -**Flexibilité autorisée :** -Si un membre utilise un service équivalent sous un autre nom (ex: `files` au lieu de `cloud`), c'est acceptable, mais la convention doit être documentée dans la fiche membre. - ---- - -#### Anti-Patterns (À Éviter) - -❌ **Sous-domaines opaques :** -- `srv1.boreal.ca` (quel service ?) -- `app.boreal.ca` (quelle application ?) -- `prod.boreal.ca` (trop vague) - -❌ **Hiérarchie trop profonde :** -- `mail.services.production.chezlepro.boreal.ca` (6 niveaux = trop) - -❌ **Mélange ID et slug :** -- `mail.m001.boreal.ca` (incohérent, choisir ID OU slug) - ---- - -### 1.3 Infrastructure — Serveurs, VMs, Conteneurs - -#### Serveurs Physiques - -**Format :** `srv-[rôle]-[numero].[slug].internal` - -**Exemples :** -``` -srv-compute-01.chezlepro.internal → Serveur de calcul (hyperviseur) -srv-compute-02.chezlepro.internal → Deuxième serveur de calcul -srv-storage-01.chezlepro.internal → Serveur de stockage (NAS/SAN) -srv-network-01.chezlepro.internal → Routeur/firewall -``` - -**Rôles standards :** -- `compute` : Hyperviseur (Proxmox, OpenStack, ESXi) -- `storage` : Stockage (NAS, SAN, Ceph) -- `network` : Infrastructure réseau (routeur, firewall, load balancer) -- `backup` : Serveur de backups dédié -- `monitoring` : Serveur monitoring/logging dédié - -**Numérotation :** -Séquentielle par rôle (compute-01, compute-02, etc.) - -**Domaine `.internal` :** -Réservé à l'infrastructure interne (non exposée publiquement). - ---- - -#### Machines Virtuelles (VMs) - -**Format :** `vm-[service]-[techno]-[numero].[slug].internal` - -**Exemples :** -``` -vm-web-nginx-01.chezlepro.internal → VM web avec Nginx -vm-web-nginx-02.chezlepro.internal → Deuxième VM web (load balancing) -vm-db-postgres-01.chezlepro.internal → Base de données PostgreSQL -vm-db-postgres-02.chezlepro.internal → Réplica PostgreSQL -vm-mail-postfix-01.chezlepro.internal → Serveur mail Postfix/Dovecot -vm-cloud-nextcloud-01.chezlepro.internal → Nextcloud -``` - -**Pattern :** -- `vm-` : Préfixe (identifie type ressource) -- `[service]` : web, db, mail, cloud, matrix, backup, monitoring -- `[techno]` : nginx, apache, postgres, mysql, postfix, nextcloud, etc. -- `[numero]` : Séquentiel (01, 02, 03...) - -**Avantages :** -- On sait immédiatement ce que fait la VM -- On sait quelle techno est utilisée (utile pour troubleshooting) -- On sait s'il y a redondance (02, 03...) - ---- - -#### Conteneurs (Docker, LXC, Kubernetes) - -**Format :** `ct-[service]-[techno]-[numero].[slug].internal` - -**Exemples :** -``` -ct-web-nginx-01.chezlepro.internal → Conteneur web Nginx -ct-api-nodejs-01.chezlepro.internal → API Node.js -ct-cache-redis-01.chezlepro.internal → Cache Redis -ct-queue-rabbitmq-01.chezlepro.internal → File d'attente RabbitMQ -``` - -**Distinction VM vs Conteneur :** -- `vm-` : Machine virtuelle complète (kernel propre) -- `ct-` : Conteneur (partage kernel avec l'hôte) - -**Kubernetes :** -Si utilisation de Kubernetes, convention adaptée : -``` -k8s-[namespace]-[pod]-[replica].[slug].internal -k8s-prod-web-nginx-01.chezlepro.internal -k8s-prod-api-nodejs-01.chezlepro.internal -``` - ---- - -#### DNS Interne (Zone `.internal`) - -**Serveur DNS interne :** -Chaque membre DEVRAIT opérer un DNS interne pour résolution locale (dnsmasq, Bind9, Unbound). - -**Zone recommandée :** `[slug].internal` - -**Exemple de zone pour Chez le Pro :** -``` -chezlepro.internal. SOA ns1.chezlepro.internal. admin.chezlepro.ca. (...) - -; Serveurs physiques -srv-compute-01.chezlepro.internal. A 10.0.1.10 -srv-storage-01.chezlepro.internal. A 10.0.1.20 - -; Machines virtuelles -vm-web-nginx-01.chezlepro.internal. A 10.0.2.10 -vm-db-postgres-01.chezlepro.internal. A 10.0.2.20 - -; Conteneurs -ct-cache-redis-01.chezlepro.internal. A 10.0.3.10 -``` - -**Isolation :** -La zone `.internal` n'est PAS déléguée à la fédération. Elle reste privée au membre. - ---- - -### 1.4 Stockage — Volumes, Backups, Archives - -#### Volumes de Stockage - -**Format LVM :** `vg-[rôle]/lv-[service]-[numero]` - -**Exemples :** -``` -vg-data/lv-postgres-01 → Volume logique pour PostgreSQL -vg-data/lv-nextcloud-01 → Volume logique pour Nextcloud -vg-backup/lv-daily-01 → Volume logique pour backups quotidiens -``` - -**Format ZFS :** `pool-[rôle]/dataset-[service]` - -**Exemples :** -``` -pool-data/vm-web-nginx-01 → Dataset ZFS pour VM web -pool-data/vm-db-postgres-01 → Dataset ZFS pour VM base de données -pool-backup/snapshots → Dataset pour snapshots ZFS -``` - ---- - -#### Backups — Fichiers d'Archive - -**Format :** `backup-[frequence]-[slug]-[service]-[YYYYMMDD]-[HHMMSS].tar.gz.gpg` - -**Exemples :** -``` -backup-daily-chezlepro-postgres-20251023-020000.tar.gz.gpg -backup-weekly-chezlepro-nextcloud-20251020-030000.tar.gz.gpg -backup-monthly-chezlepro-full-20251001-040000.tar.gz.gpg -``` - -**Éléments :** -- `frequence` : daily, weekly, monthly -- `slug` : Identifiant du membre -- `service` : Service sauvegardé (postgres, nextcloud, mail, full) -- `YYYYMMDD` : Date (format ISO 8601, triable) -- `HHMMSS` : Heure (optionnel mais recommandé pour multiples backups/jour) -- `.tar.gz.gpg` : Compression + chiffrement (GPG) - -**Avantages :** -- Tri alphabétique = tri chronologique -- On sait immédiatement : quoi, quand, par qui -- Parsing facile pour scripts de rétention - ---- - -#### Rétention et Rotation - -**Politique recommandée (modèle 3-2-1) :** - -| Fréquence | Rétention | Copies | Localisation | -|-----------|-----------|--------|--------------| -| Quotidien | 7 jours | 2 | Local + Pair | -| Hebdomadaire | 4 semaines | 2 | Local + Pair | -| Mensuel | 12 mois | 3 | Local + Pair + Cloud | - -**Rotation automatisée :** -Script ou outil (restic, borg, rsnapshot) selon préférence du membre. - -**Nommage des destinations :** -``` -/backup/local/daily/ -/backup/local/weekly/ -/backup/local/monthly/ -/backup/remote/pair-m002/ → Backup chez un pair (membre m002) -/backup/remote/offsite/ → Backup hors-site (cloud éthique) -``` - ---- - -### 1.5 Secrets & Credentials - -#### Ansible Vault — Variables Chiffrées - -**Format :** `vault_[slug]_[service]_[credential_type]` - -**Exemples :** -```yaml -vault_chezlepro_db_postgres_password: "!vault |..." -vault_chezlepro_api_matrix_token: "!vault |..." -vault_chezlepro_backup_gpg_passphrase: "!vault |..." -vault_chezlepro_ssl_privkey_password: "!vault |..." -``` - -**Pattern :** -- Préfixe `vault_` (obligatoire, Ansible) -- `[slug]` : Identifiant membre -- `[service]` : Service concerné (db, api, backup, ssl) -- `[credential_type]` : password, token, passphrase, key, secret - -**Fichier de stockage :** -`ansible/inventories/[slug]/group_vars/all/vault.yml` - -**Chiffrement :** -`ansible-vault encrypt vault.yml` - ---- - -#### Secrets Kubernetes (si applicable) - -**Format :** `secret-[namespace]-[service]-[type]` - -**Exemples :** -``` -secret-prod-postgres-credentials -secret-prod-matrix-api-token -secret-staging-nextcloud-admin-password -``` - -**Gestion :** -Sealed Secrets, External Secrets Operator, ou Vault (HashiCorp). - ---- - -#### Certificats SSL/TLS - -**Format :** `cert-[slug]-[type]-[YYYYMMDD].[extension]` - -**Exemples :** -``` -cert-chezlepro-wildcard-20251023.pem → Certificat wildcard -cert-chezlepro-wildcard-20251023.key → Clé privée -cert-chezlepro-mail-20251023.pem → Certificat service mail -cert-chezlepro-matrix-20251023.pem → Certificat service Matrix -``` - -**Types :** -- `wildcard` : Certificat wildcard (`*.chezlepro.boreal.ca`) -- `[service]` : Certificat spécifique à un service (mail, matrix, cloud) - -**Renouvellement :** -Let's Encrypt renouvelle tous les 90 jours. Le timestamp dans le nom aide à tracer les versions. - -**Stockage :** -``` -/etc/ssl/certs/alliance/cert-chezlepro-wildcard-20251023.pem -/etc/ssl/private/alliance/cert-chezlepro-wildcard-20251023.key (chmod 600) -``` - ---- - -### 1.6 Récapitulatif des Conventions - -| Objet | Format | Exemple | -|-------|--------|---------| -| **Membre ID** | `mXXX` | `m001` | -| **Membre Slug** | `[a-z0-9-]{3,20}` | `chezlepro` | -| **Domaine public** | `[service].[slug].boreal.ca` | `mail.chezlepro.boreal.ca` | -| **Domaine interne** | `[type]-[service]-[num].[slug].internal` | `vm-web-nginx-01.chezlepro.internal` | -| **Serveur physique** | `srv-[role]-[num].[slug].internal` | `srv-compute-01.chezlepro.internal` | -| **VM** | `vm-[service]-[tech]-[num].[slug].internal` | `vm-db-postgres-01.chezlepro.internal` | -| **Conteneur** | `ct-[service]-[tech]-[num].[slug].internal` | `ct-cache-redis-01.chezlepro.internal` | -| **Volume LVM** | `vg-[role]/lv-[service]-[num]` | `vg-data/lv-postgres-01` | -| **Backup** | `backup-[freq]-[slug]-[service]-[YYYYMMDD].tar.gz.gpg` | `backup-daily-chezlepro-postgres-20251023.tar.gz.gpg` | -| **Secret Ansible** | `vault_[slug]_[service]_[type]` | `vault_chezlepro_db_password` | -| **Certificat SSL** | `cert-[slug]-[type]-[YYYYMMDD].pem` | `cert-chezlepro-wildcard-20251023.pem` | - ---- - -## SECTION 2 : ARCHITECTURE RÉSEAU FÉDÉRÉE - -### 2.1 Topologie de Référence - -#### Vue d'Ensemble - -``` - ┌─────────────────────────────────────┐ - │ Internet Public │ - └──────────┬──────────────────────────┘ - │ - ┌────────────────────┼────────────────────┐ - │ │ │ - ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐ - │ Membre A │ │ Membre B │ │ Membre C │ - │ (m001) │ │ (m002) │ │ (m003) │ - └─────────────┘ └─────────────┘ └─────────────┘ - │ │ │ - │ VPN maillé (optionnel, si besoin) │ - └────────────────────┼────────────────────┘ - │ - ┌──────────▼─────────────┐ - │ DNS Fédéré (AXFR) │ - │ ns1, ns2, ns3 │ - └────────────────────────┘ -``` - -**Principes :** -1. **Autonomie locale** : Chaque membre opère son infrastructure indépendamment -2. **Interconnexion par standards ouverts** : DNS (AXFR), SMTP, Matrix, etc. -3. **VPN optionnel** : Uniquement si besoin (administration mutuelle, backups croisés) -4. **Pas de point central** : Pas de serveur "maître" contrôlant tout - ---- - -### 2.2 Plages IP et Adressage - -#### IP Publiques - -**Recommandation :** Chaque membre conserve ses propres IP publiques (hébergeur, ISP). - -**Pas d'allocation centrale.** L'Alliance ne fournit pas d'IPs publiques. - -**BGP Peering (Optionnel, Avancé) :** -Si plusieurs membres ont des AS (Autonomous Systems), peering BGP possible pour optimiser routes. Non requis pour phase pilote. - ---- - -#### IP Privées (RFC 1918) - -**Recommandation par membre :** - -**Plage recommandée :** `10.[ID].[0-255].[0-255]/16` - -**Exemples :** -- Membre m001 : `10.1.0.0/16` -- Membre m002 : `10.2.0.0/16` -- Membre m003 : `10.3.0.0/16` - -**Découpage suggéré :** -``` -10.1.0.0/24 → Gestion (switches, IPMI, ILO) -10.1.1.0/24 → Serveurs physiques -10.1.2.0/24 → VMs production -10.1.3.0/24 → VMs staging -10.1.4.0/24 → Conteneurs -10.1.10.0/24 → VPN (interconnexion) -10.1.100.0/24 → Réseau invités (si applicable) -``` - -**Avantages :** -- Pas de collision entre membres (ID unique) -- Lisibilité (10.1.x.x = m001, 10.2.x.x = m002) -- Scalabilité (65k IPs par membre) - ---- - -### 2.3 Pare-feu — Ports Standards Ouverts - -#### Ports Obligatoires (Services Publics) - -| Service | Port(s) | Protocole | Commentaire | -|---------|---------|-----------|-------------| -| **HTTP** | 80 | TCP | Redirection vers HTTPS | -| **HTTPS** | 443 | TCP | Tous les services web | -| **SMTP** | 25 | TCP | Réception email (MX) | -| **Submission** | 587 | TCP | Envoi email (STARTTLS) | -| **IMAPS** | 993 | TCP | Lecture email (SSL/TLS) | -| **DNS** | 53 | TCP/UDP | DNS autoritaire public | -| **Matrix Federation** | 8448 | TCP | Fédération Matrix (si applicable) | - -#### Ports Recommandés (Services Optionnels) - -| Service | Port(s) | Protocole | Commentaire | -|---------|---------|-----------|-------------| -| **SSH** | 22 ou custom | TCP | Admin (filtré par IP si possible) | -| **SMTP/S** | 465 | TCP | Envoi email SSL/TLS legacy | -| **POP3S** | 995 | TCP | Si POP3 supporté | -| **CalDAV/WebDAV** | 443 | TCP | Via HTTPS (port standard) | -| **XMPP** | 5222, 5269 | TCP | Si XMPP utilisé | - -#### Ports VPN (Si Interconnexion) - -| VPN | Port(s) | Protocole | Commentaire | -|-----|---------|-----------|-------------| -| **WireGuard** | 51820 (défaut) | UDP | Recommandé (moderne, performant) | -| **OpenVPN** | 1194 (défaut) | UDP/TCP | Alternative | -| **IPsec** | 500, 4500 | UDP | Si besoin (complexe) | - ---- - -### 2.4 VPN Site-à-Site (Optionnel) - -**Cas d'usage :** -- Backups croisés entre membres -- Monitoring mutuel (accès Prometheus/Grafana) -- Administration mutualisée (support technique) - -**Technologie recommandée : WireGuard** - -**Avantages :** -- Simple à configurer -- Performant (kernel-space) -- Sécurisé (cryptographie moderne) -- Multi-plateformes - -**Topologie recommandée : Maillée (Full-Mesh)** - -**Exemple 3 membres :** -``` -m001 ↔ m002 -m001 ↔ m003 -m002 ↔ m003 -``` - -**Configuration WireGuard (Exemple m001 → m002) :** - -**Sur m001 :** -```ini -[Interface] -PrivateKey = -Address = 10.100.1.1/32 -ListenPort = 51820 - -[Peer] -# m002 -PublicKey = -AllowedIPs = 10.100.2.1/32, 10.2.0.0/16 -Endpoint = m002.example.com:51820 -PersistentKeepalive = 25 -``` - -**Sur m002 :** -```ini -[Interface] -PrivateKey = -Address = 10.100.2.1/32 -ListenPort = 51820 - -[Peer] -# m001 -PublicKey = -AllowedIPs = 10.100.1.1/32, 10.1.0.0/16 -Endpoint = m001.example.com:51820 -PersistentKeepalive = 25 -``` - -**Plage VPN : `10.100.0.0/16`** -- m001 : `10.100.1.1/32` -- m002 : `10.100.2.1/32` -- m003 : `10.100.3.1/32` - -**Routes autorisées :** -Chaque membre expose son réseau interne (`10.[ID].0.0/16`) via le VPN. - ---- - -## SECTION 3 : DNS FÉDÉRÉ - -### 3.1 Architecture DNS - -#### Serveurs DNS Autoritaires - -**Minimum requis : 2 serveurs DNS** -Un serveur primaire + un ou plusieurs secondaires (redondance). - -**Recommandation : 3 serveurs répartis chez différents membres** - -**Exemple :** -``` -ns1.boreal.ca → Hébergé chez m001 (Chez le Pro) -ns2.boreal.ca → Hébergé chez m002 (TechnoLibre) -ns3.boreal.ca → Hébergé chez m003 (Coop Nordique) -``` - -**Enregistrements NS (au registrar) :** -``` -boreal.ca. NS ns1.boreal.ca. -boreal.ca. NS ns2.boreal.ca. -boreal.ca. NS ns3.boreal.ca. - -ns1.boreal.ca. A -ns2.boreal.ca. A -ns3.boreal.ca. A -``` - ---- - -#### Zone Parente (boreal.ca) - -**Gestion :** Cercle Opérationnel (rotation des responsabilités). - -**Contenu minimal :** -``` -$ORIGIN boreal.ca. -$TTL 3600 - -@ SOA ns1.boreal.ca. admin.alliance-boreale.ca. ( - 2025102301 ; Serial (YYYYMMDDNN) - 3600 ; Refresh - 1800 ; Retry - 1209600 ; Expire (2 semaines) - 3600 ; Minimum TTL -) - -; Serveurs DNS autoritaires -@ NS ns1.boreal.ca. -@ NS ns2.boreal.ca. -@ NS ns3.boreal.ca. - -ns1 A -ns2 A -ns3 A - -; Outils communs L'Alliance -registraire A -forge A -wiki A -matrix A - -; Délégation zones membres -; (voir Section 3.2) -``` - ---- - -### 3.2 Délégation de Zones aux Membres - -**Principe :** -Chaque membre reçoit une zone DNS déléguée (`[slug].boreal.ca`) qu'il gère de manière autonome. - -**Processus de délégation :** - -1. **Membre configure ses serveurs DNS** - - Serveurs autoritaires pour sa zone (ns1/ns2.[slug].boreal.ca) - - Zone `[slug].boreal.ca` avec enregistrements de services - -2. **Membre communique IPs de ses NS au Cercle Opérationnel** - - ns1.chezlepro.boreal.ca → 203.0.113.10 - - ns2.chezlepro.boreal.ca → 203.0.113.11 - -3. **Cercle Opérationnel ajoute délégation dans zone parente** - -**Exemple de délégation (dans zone boreal.ca) :** -``` -; Membre m001 (Chez le Pro) -chezlepro NS ns1.chezlepro.boreal.ca. -chezlepro NS ns2.chezlepro.boreal.ca. -ns1.chezlepro A 203.0.113.10 -ns2.chezlepro A 203.0.113.11 - -; Membre m002 (TechnoLibre) -technolibre NS ns1.technolibre.boreal.ca. -technolibre NS ns2.technolibre.boreal.ca. -ns1.technolibre A 198.51.100.20 -ns2.technolibre A 198.51.100.21 -``` - -**Résultat :** -Le membre contrôle totalement sa zone. Il peut ajouter/modifier/supprimer enregistrements sans intervention de L'Alliance. - ---- - -### 3.3 Réplication AXFR entre Pairs - -**AXFR = Zone Transfer (RFC 5936)** - -**Objectif :** Permettre la réplication complète d'une zone DNS entre serveurs primaire et secondaires. - -**Configuration (Bind9 exemple) :** - -**Serveur primaire (m001 - ns1.chezlepro.boreal.ca) :** -``` -zone "chezlepro.boreal.ca" { - type master; - file "/etc/bind/zones/chezlepro.boreal.ca.zone"; - allow-transfer { 203.0.113.11; }; // ns2.chezlepro - notify yes; -}; -``` - -**Serveur secondaire (ns2.chezlepro.boreal.ca) :** -``` -zone "chezlepro.boreal.ca" { - type slave; - file "/var/cache/bind/chezlepro.boreal.ca.zone"; - masters { 203.0.113.10; }; // ns1.chezlepro -}; -``` - -**Sécurisation :** -- Restreindre `allow-transfer` aux IPs des secondaires -- Utiliser TSIG (Transaction Signature) pour authentification - -**TSIG (Exemple) :** -``` -key "chezlepro-axfr-key" { - algorithm hmac-sha256; - secret "base64EncodedSecretKey=="; -}; - -zone "chezlepro.boreal.ca" { - type master; - file "/etc/bind/zones/chezlepro.boreal.ca.zone"; - allow-transfer { key chezlepro-axfr-key; }; -}; -``` - ---- - -### 3.4 DNSSEC (Recommandé) - -**DNSSEC = DNS Security Extensions** - -**Objectif :** Authentifier les réponses DNS (prévenir spoofing, cache poisoning). - -**Processus :** - -1. **Génération de clés (ZSK + KSK)** - ```bash - dnssec-keygen -a RSASHA256 -b 2048 -n ZONE chezlepro.boreal.ca # ZSK - dnssec-keygen -a RSASHA256 -b 4096 -n ZONE -f KSK chezlepro.boreal.ca # KSK - ``` - -2. **Signature de la zone** - ```bash - dnssec-signzone -o chezlepro.boreal.ca chezlepro.boreal.ca.zone - ``` - -3. **Publication DS record chez parent (boreal.ca)** - ``` - chezlepro DS 12345 8 2 - ``` - -4. **Automatisation du renouvellement** - - Les clés DNSSEC expirent (30-90 jours typiquement) - - Script cron pour re-signer automatiquement - -**Complexité :** -DNSSEC ajoute de la complexité opérationnelle. Recommandé pour niveau label Or/Platine, optionnel pour Bronze/Argent. - ---- - -### 3.5 Monitoring DNS - -**Vérifications essentielles :** - -1. **Résolution publique** - ```bash - dig @8.8.8.8 mail.chezlepro.boreal.ca - dig @1.1.1.1 chezlepro.boreal.ca NS - ``` - -2. **Réplication AXFR** - ```bash - dig @ns2.chezlepro.boreal.ca chezlepro.boreal.ca AXFR - ``` - -3. **DNSSEC (si activé)** - ```bash - dig +dnssec chezlepro.boreal.ca - ``` - -4. **Santé des NS** - ```bash - dig +trace chezlepro.boreal.ca - ``` - -**Outils recommandés :** -- DNSViz (visualisation DNSSEC) -- Zonemaster (analyse qualité DNS) -- Nagios/Icinga checks DNS - ---- - -## SECTION 4 : STANDARDS DE STOCKAGE - -### 4.1 Systèmes de Fichiers Recommandés - -**Pour VMs et conteneurs :** - -| Use Case | Recommandation | Rationale | -|----------|----------------|-----------| -| **VM disks** | LVM + ext4 | Simplicité, maturité | -| **VM disks (avancé)** | ZFS | Snapshots, compression, checksums | -| **Conteneurs** | Overlay2 (Docker) | Standard Docker | -| **NAS/SAN** | ZFS ou Ceph | Résilience, scalabilité | -| **Backups** | Ext4 ou XFS | Performance séquentielle | - -**ZFS avantages :** -- Snapshots instantanés -- Compression (LZ4, ZSTD) -- Checksums (détection corruption) -- Réplication (zfs send/recv) - -**ZFS inconvénients :** -- Consommation RAM (1 GB RAM / 1 TB stockage recommandé) -- Complexité configuration - -**LVM avantages :** -- Simple -- Flexible (resize volumes) -- Standard Linux - ---- - -### 4.2 Chiffrement au Repos - -**Obligatoire pour :** -- Backups (GPG, borg, restic) -- Bases de données contenant données personnelles -- Volumes contenant secrets (clés, tokens) - -**Technologies recommandées :** - -| Couche | Technologie | Usage | -|--------|-------------|-------| -| **Disque complet** | LUKS (dm-crypt) | Chiffrement bloc entier | -| **Système de fichiers** | eCryptfs, ZFS native encryption | Chiffrement par fichier/dataset | -| **Application** | GPG, age, borg, restic | Chiffrement archives | - -**Exemple LUKS :** -```bash -cryptsetup luksFormat /dev/sdb1 -cryptsetup open /dev/sdb1 cryptvol -mkfs.ext4 /dev/mapper/cryptvol -``` - -**Gestion des clés :** -- Clés stockées dans Ansible Vault (chiffrées) -- Ou TPM 2.0 (Trusted Platform Module) si disponible -- Ou HSM (Hardware Security Module) pour haute sécurité - ---- - -### 4.3 Backups — Stratégie 3-2-1 - -**Règle 3-2-1 :** -- **3** copies des données (originale + 2 backups) -- **2** supports différents (ex: disque local + NAS distant) -- **1** copie hors-site (géographiquement séparée) - -**Application dans L'Alliance :** - -| Copie | Localisation | Technologie | Fréquence | -|-------|--------------|-------------|-----------| -| **1. Production** | Serveur local | VM/conteneur | Temps réel | -| **2. Backup local** | NAS local ou autre serveur | rsync, borg, restic | Quotidien | -| **3. Backup pair** | Chez un autre membre (VPN) | rsync, borg + chiffrement | Quotidien | -| **4. Backup offsite** | Cloud éthique (ex: Wasabi, Backblaze B2) | rclone, restic | Hebdomadaire | - -**Outils recommandés :** - -**Borg Backup :** -- Déduplication (économie espace) -- Compression (LZ4, ZSTD) -- Chiffrement (AES-256) -- Snapshots incrémentaux - -**Restic :** -- Similaire à Borg -- Multi-backend (local, SFTP, S3, B2, etc.) -- Vérification d'intégrité intégrée - -**Exemple Borg :** -```bash -# Initialisation repo -borg init --encryption=repokey /backup/local/borg - -# Backup quotidien -borg create /backup/local/borg::daily-{now} /data \ - --compression lz4 \ - --exclude /data/cache - -# Pruning (rétention) -borg prune /backup/local/borg \ - --keep-daily=7 \ - --keep-weekly=4 \ - --keep-monthly=12 -``` - ---- - -### 4.4 Tests de Restauration (Obligatoire) - -**Règle d'or :** Un backup non testé est un backup inexistant. - -**Fréquence minimale :** Trimestrielle (tous les 3 mois). - -**Procédure :** -1. Sélectionner un backup aléatoire (ex: backup mensuel du mois dernier) -2. Restaurer dans environnement isolé (VM de test) -3. Vérifier intégrité (checksums, démarrage services) -4. Documenter résultat (runbook ou wiki) - -**Critères de succès :** -- Restauration complète en < [RTO] (ex: 4h) -- Données intègres (aucune corruption) -- Services redémarrables - -**Documentation obligatoire :** -`wiki/runbooks/test-restauration-YYYY-MM-DD.md` - ---- - -## SECTION 5 : ORCHESTRATION (IaC) - -### 5.1 Ansible — Structure Recommandée - -**Ansible = Infrastructure as Code pour L'Alliance** - -**Philosophie :** -- Déclaratif (décrire l'état désiré, pas les étapes) -- Idempotent (exécuter N fois = même résultat) -- Agentless (SSH uniquement, pas d'agent installé) - ---- - -#### Structure de Répertoire Standard - -``` -ansible/ -├── inventories/ -│ ├── production/ -│ │ ├── hosts.yml # Inventaire membres prod -│ │ └── group_vars/ -│ │ ├── all/ -│ │ │ ├── vars.yml # Variables publiques -│ │ │ └── vault.yml # Variables chiffrées (Vault) -│ │ └── membres/ -│ │ ├── m001.yml # Variables spécifiques m001 -│ │ └── m002.yml -│ └── staging/ -│ └── hosts.yml # Inventaire staging (si applicable) -│ -├── playbooks/ -│ ├── site.yml # Playbook principal -│ ├── dns-setup.yml # Setup DNS -│ ├── monitoring-setup.yml # Setup monitoring -│ └── backup-setup.yml # Setup backups -│ -├── roles/ -│ ├── common/ # Rôle commun (tous serveurs) -│ │ ├── tasks/ -│ │ ├── handlers/ -│ │ ├── templates/ -│ │ └── vars/ -│ ├── dns-server/ # Rôle serveur DNS -│ ├── mail-server/ # Rôle serveur mail -│ └── web-server/ # Rôle serveur web -│ -├── group_vars/ # Variables par groupe -│ └── all.yml # Variables globales -│ -├── host_vars/ # Variables par hôte -│ └── ns1.chezlepro.boreal.ca.yml -│ -└── ansible.cfg # Configuration Ansible -``` - ---- - -#### Inventaire (Exemple) - -**Fichier : `inventories/production/hosts.yml`** - -```yaml -all: - children: - alliance_members: - children: - membre_m001: - hosts: - srv-compute-01.chezlepro.internal: - ansible_host: 203.0.113.10 - vm-web-nginx-01.chezlepro.internal: - ansible_host: 10.1.2.10 - - membre_m002: - hosts: - srv-compute-01.technolibre.internal: - ansible_host: 198.51.100.20 - - dns_servers: - hosts: - ns1.boreal.ca: - ansible_host: 203.0.113.10 - member_id: m001 - ns2.boreal.ca: - ansible_host: 198.51.100.20 - member_id: m002 - - mail_servers: - hosts: - mail.chezlepro.boreal.ca: - ansible_host: 10.1.2.20 - mail.technolibre.boreal.ca: - ansible_host: 10.2.2.20 -``` - ---- - -#### Variables (Exemple) - -**Fichier : `group_vars/all/vars.yml`** - -```yaml -# Variables publiques (non sensibles) - -alliance_domain: "boreal.ca" -alliance_ns_servers: - - ns1.boreal.ca - - ns2.boreal.ca - - ns3.boreal.ca - -# Paramètres DNS -dns_ttl_default: 3600 -dns_refresh: 3600 -dns_retry: 1800 -dns_expire: 1209600 - -# Paramètres backup -backup_retention_daily: 7 -backup_retention_weekly: 4 -backup_retention_monthly: 12 - -# Paramètres monitoring -prometheus_scrape_interval: 30s -prometheus_retention: 30d -``` - -**Fichier : `group_vars/all/vault.yml` (chiffré)** - -```yaml -# Variables sensibles (Ansible Vault) - -vault_alliance_dns_tsig_key: "base64SecretKey==" -vault_alliance_backup_gpg_passphrase: "SuperSecretPassphrase123" -vault_prometheus_admin_password: "AnotherSecretPass456" -``` - -**Chiffrement :** -```bash -ansible-vault encrypt group_vars/all/vault.yml -``` - ---- - -#### Playbook (Exemple) - -**Fichier : `playbooks/dns-setup.yml`** - -```yaml ---- -- name: Setup DNS Servers - hosts: dns_servers - become: yes - - roles: - - common - - dns-server - - tasks: - - name: Configure Bind9 zones - template: - src: "templates/bind/{{ item }}.zone.j2" - dest: "/etc/bind/zones/{{ item }}.zone" - owner: bind - group: bind - mode: '0644' - loop: - - boreal.ca - - "{{ member_slug }}.boreal.ca" - notify: reload bind9 - - - name: Enable DNSSEC - command: dnssec-signzone -o {{ item }} /etc/bind/zones/{{ item }}.zone - loop: - - boreal.ca - - "{{ member_slug }}.boreal.ca" - when: dnssec_enabled | default(false) - - handlers: - - name: reload bind9 - service: - name: bind9 - state: reloaded -``` - ---- - -### 5.2 Secrets Management - -**Options recommandées :** - -1. **Ansible Vault** (simple, intégré) -2. **HashiCorp Vault** (avancé, dynamique) -3. **SOPS (Mozilla)** (Git-friendly) - -**Ansible Vault (recommandé pour débuter) :** - -```bash -# Créer fichier chiffré -ansible-vault create secrets.yml - -# Éditer fichier chiffré -ansible-vault edit secrets.yml - -# Utiliser dans playbook -ansible-playbook site.yml --ask-vault-pass -# ou avec fichier de mot de passe -ansible-playbook site.yml --vault-password-file ~/.vault_pass -``` - -**HashiCorp Vault (pour production avancée) :** - -**Avantages :** -- Secrets dynamiques (génération à la demande) -- Rotation automatique -- Audit trail complet -- APIs RESTful - -**Intégration Ansible :** -```yaml -- name: Read database password from Vault - set_fact: - db_password: "{{ lookup('hashi_vault', 'secret=secret/data/postgres:password') }}" -``` - ---- - -### 5.3 CI/CD pour Infrastructure - -**GitOps pour IaC :** -Tout changement d'infrastructure passe par Git → Review → Déploiement automatisé. - -**Workflow recommandé (GitLab CI ou GitHub Actions) :** - -```yaml -# .gitlab-ci.yml (exemple) - -stages: - - validate - - test - - deploy - -ansible-lint: - stage: validate - script: - - ansible-lint playbooks/*.yml - -ansible-syntax: - stage: validate - script: - - ansible-playbook playbooks/site.yml --syntax-check - -ansible-test-staging: - stage: test - script: - - ansible-playbook -i inventories/staging playbooks/site.yml --check - only: - - merge_requests - -ansible-deploy-production: - stage: deploy - script: - - ansible-playbook -i inventories/production playbooks/site.yml - only: - - main - when: manual -``` - -**Protection :** -- Déploiement production = manuel (éviter accidents) -- Review obligatoire (2 pairs minimum) -- Tests automatisés (lint, syntax, dry-run) - ---- - -## SECTION 6 : CERTIFICATS SSL/TLS - -### 6.1 Let's Encrypt (Recommandé) - -**Let's Encrypt = CA gratuite, automatisée, ouverte** - -**Avantages :** -- Gratuit -- Automatisé (renouvellement tous les 90 jours) -- Reconnu universellement (trust stores) -- Support wildcards - -**Client recommandé : Certbot** - -```bash -# Installation (Debian/Ubuntu) -apt install certbot python3-certbot-nginx - -# Obtenir certificat (HTTP-01 challenge) -certbot --nginx -d mail.chezlepro.boreal.ca - -# Obtenir wildcard (DNS-01 challenge) -certbot certonly --dns-cloudflare \ - --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \ - -d '*.chezlepro.boreal.ca' -``` - -**Renouvellement automatique :** -```bash -# Cron (vérifie quotidiennement, renouvelle si < 30 jours) -0 3 * * * certbot renew --quiet -``` - ---- - -### 6.2 Certificat Wildcard vs Spécifique - -**Wildcard (`*.chezlepro.boreal.ca`) :** - -**Avantages :** -- Un seul certificat pour tous les sous-domaines -- Simplifie gestion - -**Inconvénients :** -- Nécessite DNS-01 challenge (accès API DNS) -- Si compromis, tous les sous-domaines affectés - -**Certificats spécifiques (`mail.chezlepro.boreal.ca`) :** - -**Avantages :** -- HTTP-01 challenge (plus simple) -- Isolation (compromission limitée) - -**Inconvénients :** -- Plusieurs certificats à gérer - -**Recommandation :** -Wildcard pour simplifier, SAUF si services très sensibles (séparer). - ---- - -### 6.3 Chaîne de Confiance et Formats - -**Formats de certificats :** - -| Format | Extension | Usage | -|--------|-----------|-------| -| **PEM** | .pem, .crt, .cer | Standard (texte base64) | -| **DER** | .der | Binaire (rare) | -| **PKCS#12** | .p12, .pfx | Bundle (cert + clé, Windows) | - -**Fichiers Let's Encrypt (après certbot) :** -``` -/etc/letsencrypt/live/mail.chezlepro.boreal.ca/ -├── fullchain.pem → Certificat + chaîne complète (à utiliser) -├── cert.pem → Certificat seul -├── chain.pem → Chaîne intermédiaire -└── privkey.pem → Clé privée (chmod 600 !) -``` - -**Configuration Nginx :** -```nginx -server { - listen 443 ssl http2; - server_name mail.chezlepro.boreal.ca; - - ssl_certificate /etc/letsencrypt/live/mail.chezlepro.boreal.ca/fullchain.pem; - ssl_certificate_key /etc/letsencrypt/live/mail.chezlepro.boreal.ca/privkey.pem; - - # Protocoles et ciphers sécurisés - ssl_protocols TLSv1.3 TLSv1.2; - ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256...'; - ssl_prefer_server_ciphers off; - - # HSTS - add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; -} -``` - ---- - -### 6.4 Monitoring Expiration - -**Outils recommandés :** - -**1. SSL Labs (manuel)** -``` -https://www.ssllabs.com/ssltest/analyze.html?d=mail.chezlepro.boreal.ca -``` - -**2. Nagios/Icinga check** -```bash -/usr/lib/nagios/plugins/check_http -H mail.chezlepro.boreal.ca -S -C 30 -# Alerte si expiration < 30 jours -``` - -**3. Prometheus + Blackbox Exporter** -```yaml -- job_name: 'ssl-expiry' - metrics_path: /probe - params: - module: [http_2xx] - static_configs: - - targets: - - https://mail.chezlepro.boreal.ca - relabel_configs: - - source_labels: [__address__] - target_label: __param_target - - target_label: instance - replacement: blackbox-exporter:9115 -``` - -**Alerte Prometheus :** -```yaml -- alert: SSLCertExpiringSoon - expr: probe_ssl_earliest_cert_expiry - time() < 30 * 24 * 3600 - annotations: - summary: "SSL certificate expiring soon for {{ $labels.instance }}" -``` - ---- - -## SECTION 7 : MONITORING ET OBSERVABILITÉ - -### 7.1 Stack Recommandée - -**Prometheus + Grafana + Loki + Alertmanager** - -| Composant | Rôle | Port | Stockage | -|-----------|------|------|----------| -| **Prometheus** | Métriques (time-series) | 9090 | Local ou remote (Thanos) | -| **Grafana** | Visualisation | 3000 | PostgreSQL ou SQLite | -| **Loki** | Logs (agrégation) | 3100 | S3 ou local | -| **Alertmanager** | Alertes (routing) | 9093 | Volatile (config) | -| **Node Exporter** | Métriques serveur | 9100 | N/A (agent) | -| **Blackbox Exporter** | Probes externes | 9115 | N/A (agent) | - ---- - -### 7.2 Métriques à Exporter (Obligatoire Label) - -**Pour conformité Label (Domaine 1 + 5) :** - -**1. Disponibilité des services** -``` -up{job="web-server", instance="vm-web-nginx-01"} -``` - -**2. Latence HTTP** -``` -http_request_duration_seconds{handler="/", method="GET"} -``` - -**3. Utilisation ressources** -``` -node_cpu_seconds_total -node_memory_MemAvailable_bytes -node_disk_io_time_seconds_total -``` - -**4. État backups** -``` -backup_last_success_timestamp_seconds -backup_size_bytes -``` - -**5. Certificats SSL** -``` -probe_ssl_earliest_cert_expiry -``` - -**Configuration Prometheus (scrape) :** -```yaml -scrape_configs: - - job_name: 'node-exporter' - static_configs: - - targets: - - srv-compute-01.chezlepro.internal:9100 - - vm-web-nginx-01.chezlepro.internal:9100 - relabel_configs: - - source_labels: [__address__] - target_label: member - replacement: chezlepro -``` - ---- - -### 7.3 Dashboard Partagé (Optionnel) - -**Concept :** -Dashboard Grafana centralisé montrant métriques agrégées de tous les membres (avec consentement). - -**Métriques partagées (anonymisées si sensible) :** -- Disponibilité globale (%) -- Incidents P0/P1 (nombre, durée) -- Consommation énergétique agrégée (kWh) - -**Accès :** -- Membres actifs : lecture complète -- Public : tableau de bord synthétique (stats globales) - -**URL :** `grafana.boreal.ca/d/alliance-overview` - -**Implémentation :** -Prometheus Federation ou Thanos (query multi-tenancy). - ---- - -## SECTION 8 : CONFORMITÉ ET AUDITS - -### 8.1 Checklist Infrastructure (Label Domaine 1) - -**Avant demande de labellisation, vérifier :** - -- [ ] DNS configuré (ns1, ns2 minimum) -- [ ] AXFR fonctionnel entre ns1 et ns2 -- [ ] DNSSEC activé (recommandé pour Or/Platine) -- [ ] Certificats SSL/TLS valides (grade A SSL Labs) -- [ ] Backups automatisés quotidiens -- [ ] Test de restauration réalisé (< 6 mois) -- [ ] Monitoring actif (Prometheus + Node Exporter) -- [ ] Alerting configuré (Alertmanager ou équivalent) -- [ ] Status page publique (Upptime, Cachet, ou custom) -- [ ] Documentation architecture à jour (wiki) -- [ ] Runbooks pour procédures critiques (≥ 3) - ---- - -### 8.2 Preuves Techniques à Fournir - -**Lors de l'audit (voir Document 3) :** - -**DNS :** -- Capture `dig` résolution publique -- Capture `dig AXFR` réplication -- DNSViz report (si DNSSEC) - -**SSL/TLS :** -- Scan SSL Labs (grade A- minimum) -- Liste certificats avec dates expiration - -**Backups :** -- Logs de backups (derniers 30 jours) -- Rapport test restauration (avec capture écran) - -**Monitoring :** -- Capture Grafana dashboard disponibilité -- Métriques Prometheus (query échantillon) -- Logs Alertmanager (alertes déclenchées) - -**Infrastructure :** -- Inventaire serveurs/VMs/conteneurs (CSV ou YAML) -- Diagramme architecture (Diagrams.net, Draw.io) -- Configuration IaC (playbooks Ansible, extraits) - ---- - -## CONCLUSION - -**Ce document pose les fondations techniques de la fédération.** - -**Sans conventions partagées, pas d'interopérabilité.** -**Sans standards, pas de résilience.** -**Sans nomenclature mnémotechnique, pas de transmissibilité.** - -**Ces règles ne sont pas des carcans.** Elles sont des chemins tracés dans la forêt pour faciliter la coopération. Chaque membre reste souverain sur son infrastructure, mais nous parlons le même langage. - -**Les conventions évoluent.** Si une règle pose problème, proposez un amendement (pull request sur Registraire). Si un pattern fonctionne mieux, partagez-le (wiki). - -**L'objectif n'est pas la perfection immédiate, c'est la cohérence progressive.** - -**Bienvenue dans l'architecture boréale.** 🌲 - ---- - -## ANNEXES - -### Annexe A : Templates de Fichiers - -#### A.1 Zone DNS (Bind9) - -**Fichier : `/etc/bind/zones/chezlepro.boreal.ca.zone`** - -``` -$ORIGIN chezlepro.boreal.ca. -$TTL 3600 - -@ SOA ns1.chezlepro.boreal.ca. admin.chezlepro.ca. ( - 2025102301 ; Serial - 3600 ; Refresh - 1800 ; Retry - 1209600 ; Expire - 3600 ; Minimum TTL -) - -; Serveurs DNS -@ NS ns1.chezlepro.boreal.ca. -@ NS ns2.chezlepro.boreal.ca. - -ns1 A 203.0.113.10 -ns2 A 203.0.113.11 - -; Services publics -mail A 203.0.113.20 -webmail A 203.0.113.20 -cloud A 203.0.113.30 -matrix A 203.0.113.40 -status A 203.0.113.50 -www A 203.0.113.60 - -; MX records -@ MX 10 mail.chezlepro.boreal.ca. - -; SPF, DKIM, DMARC -@ TXT "v=spf1 mx -all" -_dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@chezlepro.ca" -default._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..." -``` - ---- - -#### A.2 Configuration Ansible (ansible.cfg) - -```ini -[defaults] -inventory = inventories/production/hosts.yml -roles_path = roles -host_key_checking = False -retry_files_enabled = False -gathering = smart -fact_caching = jsonfile -fact_caching_connection = /tmp/ansible_facts -fact_caching_timeout = 86400 - -[privilege_escalation] -become = True -become_method = sudo -become_user = root -become_ask_pass = False - -[ssh_connection] -pipelining = True -control_path = /tmp/ansible-ssh-%%h-%%p-%%r -``` - ---- - -#### A.3 Playbook Backup (backup-daily.yml) - -```yaml ---- -- name: Daily Backup - hosts: all - become: yes - - vars: - backup_date: "{{ ansible_date_time.iso8601_basic_short }}" - backup_base: "/backup/local/daily" - backup_gpg_key: "{{ vault_backup_gpg_key }}" - - tasks: - - name: Create backup directory - file: - path: "{{ backup_base }}" - state: directory - mode: '0700' - - - name: Backup PostgreSQL databases - shell: | - pg_dumpall | gzip | gpg --encrypt --recipient {{ backup_gpg_key }} \ - > {{ backup_base }}/backup-daily-{{ inventory_hostname_short }}-postgres-{{ backup_date }}.sql.gz.gpg - when: "'db_servers' in group_names" - - - name: Backup /etc configuration - archive: - path: /etc - dest: "{{ backup_base }}/backup-daily-{{ inventory_hostname_short }}-etc-{{ backup_date }}.tar.gz" - format: gz - - - name: Encrypt /etc backup - shell: | - gpg --encrypt --recipient {{ backup_gpg_key }} \ - {{ backup_base }}/backup-daily-{{ inventory_hostname_short }}-etc-{{ backup_date }}.tar.gz - rm {{ backup_base }}/backup-daily-{{ inventory_hostname_short }}-etc-{{ backup_date }}.tar.gz - - - name: Prune old backups (keep 7 days) - shell: | - find {{ backup_base }} -type f -mtime +7 -delete -``` - ---- - -### Annexe B : Scripts Utilitaires - -#### B.1 Vérification DNS Fédéré - -**Fichier : `scripts/check-dns-federation.sh`** - -```bash -#!/bin/bash -# Vérification santé DNS fédéré - -DOMAIN="boreal.ca" -MEMBERS=("chezlepro" "technolibre" "coop-nordique") - -echo "=== Vérification DNS Fédération Alliance Boréale ===" -echo "" - -# Test résolution NS racine -echo "1. Serveurs NS racine ${DOMAIN}:" -dig +short ${DOMAIN} NS -echo "" - -# Test délégation membres -for member in "${MEMBERS[@]}"; do - echo "2. Délégation ${member}.${DOMAIN}:" - dig +short ${member}.${DOMAIN} NS - echo "" - - echo "3. Services ${member}.${DOMAIN}:" - dig +short mail.${member}.${DOMAIN} A - dig +short cloud.${member}.${DOMAIN} A - echo "" -done - -# Test AXFR (si autorisé) -echo "4. Test AXFR (depuis ns1):" -dig @ns1.${DOMAIN} ${DOMAIN} AXFR +short | head -10 -echo "" - -echo "=== Fin vérification ===" -``` - ---- - -#### B.2 Génération Certificat Let's Encrypt - -**Fichier : `scripts/certbot-wildcard.sh`** - -```bash -#!/bin/bash -# Obtenir certificat wildcard Let's Encrypt avec Cloudflare DNS - -DOMAIN="$1" -EMAIL="admin@${DOMAIN}" -CLOUDFLARE_CREDS="/root/.secrets/cloudflare.ini" - -if [ -z "$DOMAIN" ]; then - echo "Usage: $0 " - echo "Exemple: $0 chezlepro.boreal.ca" - exit 1 -fi - -certbot certonly \ - --dns-cloudflare \ - --dns-cloudflare-credentials ${CLOUDFLARE_CREDS} \ - --email ${EMAIL} \ - --agree-tos \ - --non-interactive \ - -d "*.${DOMAIN}" \ - -d "${DOMAIN}" - -echo "Certificat généré dans /etc/letsencrypt/live/${DOMAIN}/" -``` - ---- - -### Annexe C : Checklist Démarrage Membre - -**Pour nouveau membre rejoignant la fédération :** - -#### Phase 1 : Préparation (Semaines 1-2) - -- [ ] Choisir slug (unique, vérifier disponibilité) -- [ ] Obtenir domaine public propre (optionnel mais recommandé) -- [ ] Configurer infrastructure de base (1+ serveur) -- [ ] Installer OS (Debian/Ubuntu/autre Linux) -- [ ] Configurer réseau interne (10.[ID].0.0/16) - -#### Phase 2 : DNS et Connectivité (Semaine 3) - -- [ ] Installer serveur DNS (Bind9, PowerDNS) -- [ ] Configurer zone `[slug].boreal.ca` -- [ ] Demander délégation au Cercle Opérationnel -- [ ] Tester résolution publique -- [ ] Configurer AXFR avec 1+ pair -- [ ] Configurer firewall (ports standards ouverts) - -#### Phase 3 : Services de Base (Semaines 4-6) - -- [ ] Déployer serveur email (Postfix, Dovecot) -- [ ] Configurer DKIM, SPF, DMARC -- [ ] Obtenir certificats SSL/TLS (Let's Encrypt) -- [ ] Déployer services optionnels (Nextcloud, Matrix) -- [ ] Configurer backups quotidiens -- [ ] Tester restauration - -#### Phase 4 : Monitoring et Documentation (Semaines 7-8) - -- [ ] Installer Prometheus + Node Exporter -- [ ] Configurer Grafana -- [ ] Créer status page publique -- [ ] Documenter architecture (wiki) -- [ ] Rédiger runbooks (≥ 3 procédures) - -#### Phase 5 : Intégration (Semaines 9-12) - -- [ ] Participer à audits pair-à-pair -- [ ] Contribuer à documentation commune -- [ ] Établir VPN avec 1+ pair (si besoin backups croisés) -- [ ] Demander labellisation (Bronze minimum) - -**Durée totale estimée : 3 mois (phase probatoire)** - ---- - -## MÉTADONNÉES - -**Document :** 05_Architecture_Reference_Standards_Techniques.md -**Version :** 1.0 -**Date de création :** 23 octobre 2025 -**Auteur :** Claude (profils #3 Infrastructure, #4 Réseau, #5 IaC, #12 Documentaliste) -**Révision par :** Cercle Opérationnel -**Statut :** À adopter par Cercle Stratégique -**Longueur :** ~15 000 mots (30 pages équivalent) -**Licence :** CC BY-SA 4.0 - -**Sources utilisées :** -- `00_Glossaire_et_Definitions.md` -- `01_Charte_Fondatrice_v2_1.md` -- `02_Reglement_de_Regie_Interne.md` -- `03_Cadre_Conformite_Label_Prestige.md` -- `devis_alliance_boreale_v2.md` - -**Prochaine révision prévue :** Octobre 2026 (après 1 an d'usage terrain) - ---- - -**Changelog :** -- 2025-10-23 v1.0 : Création initiale Architecture & Standards Techniques - ---- - -**FIN DE L'ARCHITECTURE DE RÉFÉRENCE** - -*"Un nom bien choisi vaut mieux qu'une longue documentation."* - -🌲 **L'Alliance Boréale** -*Standards mnémotechniques pour une fédération durable.* diff --git a/docs/constitution/05_Operation_DNS_Federee.md b/docs/constitution/05_Operation_DNS_Federee.md new file mode 100644 index 0000000..733f0ee --- /dev/null +++ b/docs/constitution/05_Operation_DNS_Federee.md @@ -0,0 +1,1289 @@ +# Document 5 : Opération DNS Fédérée +## L'Alliance Boréale + +**Version :** 1.0 +**Date :** 23 octobre 2025 +**Statut :** DRAFT - Validation requise par Cercle Technique +**Prérequis :** `nomenclature_v2.md` (nommage et adressage) +**Auteur :** Claude (profils #4 Architecte Réseau, #10 Auditeur Sécurité) +**Licence :** CC-BY-SA 4.0 + +--- + +## Table des Matières + +1. [Introduction](#1-introduction) +2. [Principes de la Fédération DNS](#2-principes-de-la-fédération-dns) +3. [Architecture DNS Distribuée](#3-architecture-dns-distribuée) +4. [Standards Techniques Obligatoires](#4-standards-techniques-obligatoires) +5. [Processus de Délégation de Zones](#5-processus-de-délégation-de-zones) +6. [Niveaux de Service DNS](#6-niveaux-de-service-dns) +7. [Sécurité et Gestion des Incidents](#7-sécurité-et-gestion-des-incidents) +8. [Monitoring et Outils Mutualisés](#8-monitoring-et-outils-mutualisés) +9. [Retrait et Transition](#9-retrait-et-transition) +10. [Annexes](#10-annexes) + +--- + +## 1. Introduction + +### 1.1 Objectif de ce Document + +Ce document définit **comment les membres de L'Alliance Boréale opèrent et fédèrent leur infrastructure DNS**. Il couvre : +- Les relations primaire/secondaire entre membres +- Les standards techniques (AXFR, DNSSEC, TSIG) +- Les processus de délégation de zones +- La gestion collective des incidents DNS + +### 1.2 Prérequis + +**Ce document s'appuie sur `nomenclature_v2.md`** pour : +- Nommage des serveurs DNS (`dns-master.infra..alliance-boreale.ca`) +- Plan d'adressage IP (10.0.2.0/24 pour DNS) +- Structure des zones DNS fédérées + +**Lecture obligatoire** : `nomenclature_v2.md` avant de procéder. + +### 1.3 Portée + +Ce document s'applique à **tous les membres actifs** de L'Alliance Boréale. Les membres en probation peuvent l'appliquer partiellement (DNSSEC optionnel). + +### 1.4 Alignement avec les Valeurs + +**Autonomie :** Chaque membre gère ses zones de manière souveraine. +**Résilience :** DNS secondaires mutuels entre pairs. +**Standards ouverts :** RFCs DNS, DNSSEC, protocoles documentés. +**Subsidiarité :** L'Alliance n'intervient que pour coordination minimale. + +--- + +## 2. Principes de la Fédération DNS + +### 2.1 Autonomie Locale + +**Chaque membre est autoritaire pour ses propres zones.** + +``` +czp.alliance-boreale.ca → Géré par Chezlepro +nul.alliance-boreale.ca → Géré par Nuage Libre +tli.alliance-boreale.ca → Géré par TechnoLibre +``` + +L'Alliance ne contrôle **aucun contenu** des zones membres. Elle coordonne uniquement : +- Délégation depuis la zone parent (`alliance-boreale.ca`) +- Standards techniques minimums (DNSSEC, AXFR) + +### 2.2 Résilience par la Redondance + +**Minimum 2 serveurs DNS par membre.** + +Configuration type : +``` +ns1.czp.alliance-boreale.ca → DNS Primaire (VMID 02001) +ns2.czp.alliance-boreale.ca → DNS Secondaire (VMID 02002) +``` + +**Optionnel mais recommandé :** DNS secondaire croisé avec un autre membre. + +Exemple : +``` +czp.alliance-boreale.ca: + - ns1.czp.alliance-boreale.ca (primaire) + - ns2.czp.alliance-boreale.ca (secondaire local) + - ns1.nul.alliance-boreale.ca (secondaire croisé) +``` + +**Avantages :** +- Résilience accrue (3 sites distincts) +- Solidarité technique entre membres +- Détection rapide de pannes (monitoring mutuel) + +### 2.3 Standards Ouverts + +**L'Alliance privilégie exclusivement les standards RFC.** + +- RFC 1034/1035 : DNS de base +- RFC 2136 : DNS UPDATE (optionnel) +- RFC 4033-4035 : DNSSEC +- RFC 5936 : AXFR +- RFC 8945 : TSIG (authentification) + +**Aucune extension propriétaire** ne doit être requise pour interopérer. + +### 2.4 Confiance Vérifiable + +**DNSSEC est obligatoire pour les zones critiques.** + +**Zones critiques :** +- Zone racine membre (`czp.alliance-boreale.ca`) +- Services d'infrastructure (`*.infra.czp.alliance-boreale.ca`) +- Email (domaines avec enregistrements MX) + +**Zones optionnelles :** +- Zones tenants (décision du membre) +- Environnements dev/staging + +**Vérification :** DNSViz.net doit afficher une chaîne DNSSEC valide. + +--- + +## 3. Architecture DNS Distribuée + +### 3.1 Vue d'Ensemble + +``` +┌─────────────────────────────────────────────────────────────┐ +│ alliance-boreale.ca (Zone Parent) │ +│ Géré par: Cercle Opérationnel │ +│ Serveurs: ns1/ns2/ns3.alliance-boreale.ca │ +└────────────┬────────────────────────────────────────────────┘ + │ + │ Délégations NS + │ + ┌───────┴────────┬─────────────┬──────────────┐ + │ │ │ │ +┌────▼─────┐ ┌────▼─────┐ ┌───▼──────┐ ┌───▼──────┐ +│ czp │ │ nul │ │ tli │ │ autres │ +│ Zone │ │ Zone │ │ Zone │ │ membres │ +└──────────┘ └──────────┘ └──────────┘ └──────────┘ +``` + +### 3.2 Serveurs DNS Autoritaires + +**Minimum requis : 2 serveurs** + +**Configuration type (membre Chezlepro) :** + +| Serveur | VMID | IP Interne | IP Publique | Rôle | +|---------|------|------------|-------------|------| +| ns1.czp.alliance-boreale.ca | 02001 | 10.0.2.10 | 198.51.100.10 | Primaire (MASTER) | +| ns2.czp.alliance-boreale.ca | 02002 | 10.0.2.11 | 198.51.100.11 | Secondaire (SLAVE) | + +**Recommandé : 3 serveurs (avec secondaire croisé)** + +| Serveur | Localisation | Rôle | +|---------|--------------|------| +| ns1.czp.alliance-boreale.ca | Datacenter Chezlepro | MASTER | +| ns2.czp.alliance-boreale.ca | Datacenter Chezlepro | SLAVE | +| ns1.nul.alliance-boreale.ca | Datacenter Nuage Libre | SLAVE (croisé) | + +### 3.3 Relations Primaire/Secondaire + +**Architecture recommandée : Hub & Spoke modifié** + +``` +Membre A (czp) + ├─ ns1.czp (MASTER) + ├─ ns2.czp (SLAVE local) + └─ ns1.nul (SLAVE croisé) ← AXFR depuis ns1.czp + +Membre B (nul) + ├─ ns1.nul (MASTER) + ├─ ns2.nul (SLAVE local) + └─ ns1.tli (SLAVE croisé) ← AXFR depuis ns1.nul + +Membre C (tli) + ├─ ns1.tli (MASTER) + ├─ ns2.tli (SLAVE local) + └─ ns1.czp (SLAVE croisé) ← AXFR depuis ns1.tli +``` + +**Avantages :** +- Topologie en triangle (pas de point unique de défaillance) +- Charge répartie (pas de "hub" central) +- Latence réduite (géographiquement distribué) + +### 3.4 Stratégies de Délégation de Zones + +**Principe : Délégation minimale nécessaire** + +**Zone parent (`alliance-boreale.ca`) :** +``` +; Délégation zone membre Chezlepro +czp NS ns1.czp.alliance-boreale.ca. +czp NS ns2.czp.alliance-boreale.ca. +czp NS ns1.nul.alliance-boreale.ca. ; Secondaire croisé + +ns1.czp A 198.51.100.10 +ns2.czp A 198.51.100.11 +ns1.nul A 198.51.100.20 ; IP publique Nuage Libre +``` + +**Zone membre (`czp.alliance-boreale.ca`) :** +``` +$ORIGIN czp.alliance-boreale.ca. + +; SOA et NS +@ SOA ns1.czp.alliance-boreale.ca. admin.czp.alliance-boreale.ca. ( + 2025102301 ; Serial + 3600 ; Refresh + 1800 ; Retry + 1209600 ; Expire + 3600 ; Minimum TTL +) + +@ NS ns1.czp.alliance-boreale.ca. +@ NS ns2.czp.alliance-boreale.ca. +@ NS ns1.nul.alliance-boreale.ca. + +; Sous-délégation infrastructure +infra NS ns1.czp.alliance-boreale.ca. +infra NS ns2.czp.alliance-boreale.ca. +``` + +**Pas de délégation récursive excessive.** Si un membre a besoin de sous-zones complexes, il les gère en interne (pas de nouvelle délégation depuis la zone parent). + +--- + +## 4. Standards Techniques Obligatoires + +### 4.1 Logiciel DNS Recommandé + +**Primaire : PowerDNS Authoritative Server** + +**Pourquoi PowerDNS ?** +- Open source (GPLv2) +- Backend SQL (PostgreSQL/MySQL) → auditable +- DNSSEC natif +- API REST (automatisation) +- Support AXFR/NOTIFY robuste + +**Alternatives acceptées :** +- BIND9 (si configuration validée par pair) +- NSD (si DNSSEC géré manuellement) +- Knot DNS + +**Inacceptable :** +- DNS Windows Server (non open source) +- Solutions cloud propriétaires sans AXFR (Route53, Cloudflare seul) + +### 4.2 DNSSEC Obligatoire + +**Pour qui ?** +- Membres actifs : **Obligatoire** pour zones critiques +- Membres en probation : **Recommandé** (optionnel pendant probation) + +**Configuration minimale :** + +```bash +# Générer clés DNSSEC (PowerDNS) +pdnsutil secure-zone czp.alliance-boreale.ca +pdnsutil rectify-zone czp.alliance-boreale.ca + +# Vérifier +pdnsutil check-zone czp.alliance-boreale.ca +``` + +**DS Records :** +Le membre doit fournir ses DS records au Cercle Opérationnel pour insertion dans la zone parent. + +**Commande d'export :** +```bash +pdnsutil show-zone czp.alliance-boreale.ca | grep DS +``` + +**Validation publique :** +```bash +dig +dnssec czp.alliance-boreale.ca @8.8.8.8 +# Doit afficher: flags: ad (Authenticated Data) +``` + +**Outil de validation :** DNSViz.net + +### 4.3 AXFR Sécurisé + +**AXFR = Transfert de zone complet depuis primaire vers secondaires.** + +**Sécurité obligatoire :** +1. **ACL strictes** : Liste blanche des IPs autorisées +2. **TSIG** : Authentification cryptographique (recommandé) + +#### Configuration AXFR avec ACL (PowerDNS) + +**Sur le MASTER (ns1.czp) :** + +```sql +-- Table domainmetadata +INSERT INTO domainmetadata (domain_id, kind, content) +VALUES ( + (SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'), + 'ALLOW-AXFR-FROM', + '10.0.2.11' -- ns2.czp (secondaire local) +); + +INSERT INTO domainmetadata (domain_id, kind, content) +VALUES ( + (SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'), + 'ALLOW-AXFR-FROM', + '198.51.100.20' -- ns1.nul (secondaire croisé) +); +``` + +**Sur le SLAVE (ns2.czp ou ns1.nul) :** + +```conf +# /etc/powerdns/pdns.conf +slave=yes +superslave=no +``` + +**Test AXFR :** +```bash +dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca AXFR +# Doit retourner toute la zone +``` + +#### Configuration AXFR avec TSIG (recommandé) + +**Générer clé TSIG :** +```bash +tsig-keygen czp-nul-xfer > /etc/powerdns/tsig.key +``` + +**Contenu du fichier :** +``` +key "czp-nul-xfer" { + algorithm hmac-sha256; + secret "Base64EncodedSecretHere=="; +}; +``` + +**Configuration MASTER (ns1.czp) :** +```sql +-- Ajouter TSIG key +INSERT INTO tsigkeys (name, algorithm, secret) +VALUES ('czp-nul-xfer', 'hmac-sha256', 'Base64EncodedSecretHere=='); + +-- Associer à la zone +INSERT INTO domainmetadata (domain_id, kind, content) +VALUES ( + (SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'), + 'TSIG-ALLOW-AXFR', + 'czp-nul-xfer' +); +``` + +**Configuration SLAVE (ns1.nul) :** +```conf +# /etc/powerdns/pdns.conf (ajouter) +include-dir=/etc/powerdns/tsig.d + +# /etc/powerdns/tsig.d/czp.conf +zone "czp.alliance-boreale.ca" { + type slave; + masters { 198.51.100.10 key czp-nul-xfer; }; +}; +``` + +**Test AXFR avec TSIG :** +```bash +dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca AXFR -y hmac-sha256:czp-nul-xfer:Base64EncodedSecretHere== +``` + +### 4.4 Notifications (NOTIFY) + +**RFC 1996 : DNS NOTIFY** + +Quand la zone primaire change, elle envoie un NOTIFY aux secondaires pour déclencher AXFR immédiat. + +**Configuration (PowerDNS) :** +```sql +-- Activer NOTIFY vers secondaires +INSERT INTO domainmetadata (domain_id, kind, content) +VALUES ( + (SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'), + 'ALSO-NOTIFY', + '10.0.2.11' -- ns2.czp +); + +INSERT INTO domainmetadata (domain_id, kind, content) +VALUES ( + (SELECT id FROM domains WHERE name='czp.alliance-boreale.ca'), + 'ALSO-NOTIFY', + '198.51.100.20' -- ns1.nul (secondaire croisé) +); +``` + +**Vérification :** +```bash +# Modifier un enregistrement sur MASTER +# Vérifier logs SLAVE pour "NOTIFY received" +tail -f /var/log/pdns.log | grep NOTIFY +``` + +### 4.5 TTL Raisonnables + +**Équilibre cache / réactivité** + +**Recommandations :** + +| Type d'enregistrement | TTL Recommandé | Rationale | +|----------------------|----------------|-----------| +| SOA (minimum) | 3600s (1h) | Cache raisonnable | +| NS | 86400s (24h) | Changent rarement | +| A/AAAA (services) | 3600s (1h) | Migration possible | +| A/AAAA (infra critique) | 1800s (30min) | Réactivité incidents | +| MX | 3600s (1h) | Standard email | +| TXT (SPF, DKIM) | 3600s (1h) | Changent occasionnellement | +| CNAME | 3600s (1h) | Flexibilité | + +**À éviter :** +- TTL < 300s (5min) : Charge excessive sur DNS +- TTL > 86400s (24h) pour services : Lenteur migration/incident + +**Exception :** Pendant migration planifiée, réduire temporairement TTL à 300s, puis revenir à 3600s après. + +--- + +## 5. Processus de Délégation de Zones + +### 5.1 Demande de Délégation + +**Qui ?** Nouveau membre en onboarding (semaines 3-4) + +**Prérequis :** +1. ✅ Serveurs DNS configurés (ns1, ns2) +2. ✅ Zone membre créée localement +3. ✅ AXFR fonctionnel entre ns1 et ns2 +4. ✅ IPs publiques stables et documentées +5. ✅ (Optionnel) DNSSEC activé et DS records disponibles + +**Procédure :** + +1. **Soumettre demande via Matrix (#technique)** + +Template : +``` +Demande de délégation DNS +=========================== +Membre : Chezlepro (czp) +Zone demandée : czp.alliance-boreale.ca +Parrain : Nuage Libre (nul) + +Serveurs NS : +- ns1.czp.alliance-boreale.ca (198.51.100.10) +- ns2.czp.alliance-boreale.ca (198.51.100.11) +- ns1.nul.alliance-boreale.ca (198.51.100.20) [secondaire croisé] + +DNSSEC : Oui +DS Records : (joint en annexe) + +Tests effectués : +✅ dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca SOA +✅ dig @ns2.czp.alliance-boreale.ca czp.alliance-boreale.ca SOA +✅ AXFR ns1 → ns2 fonctionnel +✅ DNSViz.net validé (si DNSSEC) + +Délai souhaité : 2025-10-28 +``` + +2. **Validation technique par un pair** + +Un membre actif (idéalement le parrain) vérifie : +- [ ] Résolution SOA sur ns1 et ns2 +- [ ] AXFR fonctionne +- [ ] DNSSEC valide (si activé) +- [ ] Pas de conflit de nommage + +**Commandes de validation :** +```bash +# Test SOA +dig @198.51.100.10 czp.alliance-boreale.ca SOA +short + +# Test AXFR +dig @198.51.100.10 czp.alliance-boreale.ca AXFR +short | wc -l + +# Test DNSSEC +dig @198.51.100.10 czp.alliance-boreale.ca DNSKEY +dnssec + +# Validation DNSViz (manuel) +# https://dnsviz.net/d/czp.alliance-boreale.ca/dnssec/ +``` + +3. **Approbation Cercle Opérationnel** + +Vote de consentement (asynchrone, Matrix ou réunion). + +Critères : +- Validation technique OK +- Membre en règle (probation active) +- Pas d'objection motivée + +**Délai** : 48-72h maximum + +4. **Insertion dans zone parent** + +Membre du Cercle Opérationnel (rotation) effectue : + +```bash +# Éditer zone alliance-boreale.ca +pdnsutil edit-zone alliance-boreale.ca + +# Ajouter délégation +czp NS ns1.czp.alliance-boreale.ca. +czp NS ns2.czp.alliance-boreale.ca. +czp NS ns1.nul.alliance-boreale.ca. + +ns1.czp A 198.51.100.10 +ns2.czp A 198.51.100.11 + +# Si DNSSEC activé, ajouter DS records +czp DS 12345 13 2 (hash SHA256) + +# Incrémenter serial SOA +pdnsutil increase-serial alliance-boreale.ca + +# Vérifier +pdnsutil check-zone alliance-boreale.ca +``` + +5. **Notification et tests publics** + +Post Matrix (#annonces) : +``` +🎉 Nouvelle délégation DNS : czp.alliance-boreale.ca +Serveurs : ns1/ns2.czp.alliance-boreale.ca + ns1.nul (croisé) +DNSSEC : Activé ✅ +Tests publics bienvenus ! +``` + +**Tests publics (par tous) :** +```bash +# Depuis n'importe où sur Internet +dig czp.alliance-boreale.ca NS @8.8.8.8 +dig mail.czp.alliance-boreale.ca A @8.8.8.8 +dig +dnssec czp.alliance-boreale.ca @1.1.1.1 +``` + +### 5.2 Enregistrement au Registraire + +Une fois la délégation active, mettre à jour le fichier YAML du membre. + +**Fichier : `registraire/membres/m001-chezlepro.yml`** + +```yaml +dns: + primary: + - name: ns1.czp.alliance-boreale.ca + ip: 198.51.100.10 + vmid: 02001 + - name: ns2.czp.alliance-boreale.ca + ip: 198.51.100.11 + vmid: 02002 + secondary_cross: + - name: ns1.nul.alliance-boreale.ca + ip: 198.51.100.20 + member: nul + zones_delegated: + - czp.alliance-boreale.ca + dnssec: true + dnssec_ds_records: + - "12345 13 2 ABC123..." + last_delegation_date: "2025-10-28" + validated_by: m002 # Parrain ou pair +``` + +### 5.3 Propagation et Tests + +**Délai de propagation :** 24-48h (selon TTL des NS records parent) + +**Tests progressifs :** + +| Temps | Test | Commande | +|-------|------|----------| +| T+0 | Résolution depuis DNS autoritaires Alliance | `dig @ns1.alliance-boreale.ca czp.alliance-boreale.ca NS` | +| T+1h | Résolution depuis Google DNS | `dig @8.8.8.8 czp.alliance-boreale.ca NS` | +| T+24h | Résolution depuis Cloudflare | `dig @1.1.1.1 czp.alliance-boreale.ca NS` | +| T+48h | Validation DNSSEC globale | DNSViz.net | + +--- + +## 6. Niveaux de Service DNS + +### 6.1 Disponibilité Cible + +**Membres actifs : ≥ 99.5% (uptime annuel)** + +Calcul : +``` +99.5% = 43.8 heures de downtime/an maximum + = 3.65 heures/mois + = ~50 minutes/semaine +``` + +**Mesure :** Monitoring Prometheus avec probe externe (Blackbox Exporter) + +**Exclusions (downtime justifié) :** +- Maintenance planifiée (notifiée 48h à l'avance) +- Incident majeur hors contrôle (DDoS massif, panne datacenter) + +### 6.2 Temps de Réponse Acceptable + +**Requêtes DNS simples (A, AAAA, NS) :** +- Médiane : < 50ms +- P95 : < 100ms +- P99 : < 200ms + +**Requêtes DNSSEC (avec validation) :** +- Médiane : < 100ms +- P95 : < 200ms +- P99 : < 500ms + +**Mesure :** Prometheus `probe_duration_seconds` histogram + +### 6.3 Maintenance Planifiée + +**Notification requise : 48h minimum** + +**Canaux de notification :** +1. Matrix #annonces +2. Status page (status.czp.alliance-boreale.ca) +3. Email liste membres (si critique) + +**Template notification :** +``` +🔧 Maintenance DNS planifiée + +Membre : Chezlepro (czp) +Date : 2025-10-30 03:00-05:00 UTC +Durée estimée : 2 heures +Impact : Résolution DNS czp.alliance-boreale.ca + (secondaires actifs : ns2.czp + ns1.nul) + +Services affectés : ns1.czp.alliance-boreale.ca (MASTER) +Services maintenus : ns2.czp.alliance-boreale.ca (SLAVE) + +Raison : Migration serveur physique +Contact : admin@chezlepro.tech +``` + +**Bonne pratique :** +- Planifier entre 2h-6h du matin (heure locale) +- Vérifier que secondaires sont opérationnels avant +- Monitoring actif pendant maintenance + +### 6.4 Gestion des Incidents DNS + +**Classification :** + +| Priorité | Définition | SLA Réponse | SLA Résolution | +|----------|------------|-------------|----------------| +| P0 | Tous DNS down (zone inaccessible) | 15 min | 2 heures | +| P1 | DNS primaire down (secondaires OK) | 30 min | 4 heures | +| P2 | Lenteur résolution (>500ms) | 1 heure | 8 heures | +| P3 | Anomalie non critique | 4 heures | 24 heures | + +**Procédure incident :** + +1. **Détection** + - Monitoring Prometheus (AlertManager) + - Rapport Matrix (#incidents) + - Signalement utilisateur + +2. **Notification** + - Post Matrix #incidents immédiat + - Mention @dns-oncall si configuré + - Update status page + +3. **Investigation** + - Logs DNS serveur : `tail -f /var/log/pdns.log` + - Métriques Grafana + - Tests externes : `dig`, `nslookup` + +4. **Résolution** + - Corriger ou basculer sur secondaire + - Valider résolution publique + - Post Matrix résolution + +5. **Post-Mortem (si P0/P1, >1h downtime)** + - Documenter cause racine + - Corrective actions + - Publier sur wiki (transparence) + +**Template Post-Mortem :** +```markdown +# Post-Mortem : Panne DNS czp.alliance-boreale.ca + +**Date :** 2025-10-25 +**Durée :** 1h30 +**Impact :** Résolution DNS czp.alliance-boreale.ca indisponible +**Priorité :** P0 + +## Chronologie +- 14:23 UTC : Alerte Prometheus "DNS ns1.czp down" +- 14:25 UTC : Confirmation manuelle (dig timeout) +- 14:30 UTC : Basculement manuel vers ns2.czp +- 14:45 UTC : Identification cause (OOM serveur ns1) +- 15:20 UTC : Redémarrage ns1, AXFR sync OK +- 15:53 UTC : Retour normal, monitoring OK + +## Cause Racine +Out-of-Memory sur ns1.czp (processus PowerDNS tué par OOM killer). +Cause : Fuite mémoire dans module expérimental (dnsdist). + +## Impact +- Zone czp.alliance-boreale.ca inaccessible : 1h30 +- Secondaire ns2.czp actif, mais non prioritaire dans délégation +- ~50% requêtes timeouts (clients avec cache OK) + +## Actions Correctives +✅ Désactivation dnsdist (immédiat) +✅ Augmentation RAM VM ns1 : 2GB → 4GB +🔄 Configuration monitoring OOM (en cours) +🔄 Rééquilibrage priorité NS (ns2 en premier) + +## Leçons Apprises +- Secondaires fonctionnent, mais délégation ordre NS critique +- Besoin alerte proactive RAM/CPU (pas juste down/up) + +**Auteur :** admin@chezlepro.tech +**Publié :** wiki.alliance-boreale.ca/postmortems/2025-10-25-dns-czp +``` + +--- + +## 7. Sécurité et Gestion des Incidents + +### 7.1 Protection contre DDoS + +**Couches de protection :** + +1. **Firewall (iptables/nftables)** + +```bash +# Limiter requêtes DNS/sec par IP source +iptables -A INPUT -p udp --dport 53 -m state --state NEW \ + -m recent --set --name dns_limit + +iptables -A INPUT -p udp --dport 53 -m state --state NEW \ + -m recent --update --seconds 1 --hitcount 20 --name dns_limit \ + -j DROP +``` + +2. **Rate Limiting PowerDNS** + +```ini +# /etc/powerdns/pdns.conf +max-queue-length=5000 +max-tcp-clients=128 +max-tcp-per-client=5 + +# Limiter réponses NXDOMAIN (cache poisoning) +max-cache-entries=1000000 +negquery-cache-ttl=60 +``` + +3. **Anycast (avancé, optionnel)** + +Si plusieurs membres dans régions distinctes, anycast BGP pour distribuer charge. + +**Note :** Complexe, recommandé seulement si >10 membres actifs. + +### 7.2 Détection d'Anomalies + +**Monitoring Prometheus : Métriques clés** + +```yaml +# prometheus.yml (extrait) +- job_name: 'dns-czp' + static_configs: + - targets: ['198.51.100.10:9153'] # PowerDNS Exporter + metric_relabel_configs: + - source_labels: [__name__] + regex: 'pdns_(up|queries_total|latency_seconds.*)' + action: keep +``` + +**Alertes AlertManager :** + +```yaml +groups: +- name: dns + rules: + - alert: DNSDown + expr: probe_success{job="dns"} == 0 + for: 5m + labels: + severity: critical + annotations: + summary: "DNS {{ $labels.instance }} down" + + - alert: DNSSlowQueries + expr: histogram_quantile(0.95, rate(pdns_latency_seconds_bucket[5m])) > 0.5 + for: 10m + labels: + severity: warning + annotations: + summary: "DNS {{ $labels.instance }} slow (P95 > 500ms)" + + - alert: DNSHighQueryRate + expr: rate(pdns_queries_total[5m]) > 1000 + for: 5m + labels: + severity: warning + annotations: + summary: "DNS {{ $labels.instance }} high query rate (potential DDoS)" +``` + +### 7.3 Réponse à Incident + +**Escalade :** + +1. **Auto-détection (Prometheus) :** Post Matrix #incidents automatique +2. **Membre concerné** : Investigate (15-30 min) +3. **Si bloqué** : Demande support Matrix #support +4. **Si P0 non résolu <1h** : Escalade Cercle Opérationnel +5. **Si attaque coordonnée** : Communication collective (tous membres alertés) + +**Communication pendant incident :** + +✅ **Faire :** +- Updates régulières (toutes les 30 min si P0) +- Être transparent sur cause (même si embarrassant) +- Documenter actions prises + +❌ **Éviter :** +- Silence prolongé (anxiété collective) +- Minimiser impact (crédibilité) +- Blâmer outils/tiers sans preuve + +### 7.4 Post-Mortem Obligatoire + +**Quand ?** +- Tout incident P0 (zone complètement down) +- Incident P1 > 1h (primaire down, même si secondaires OK) +- Incident sécurité (compromission, DDoS majeur) + +**Délai :** 7 jours après résolution + +**Publication :** Wiki public (transparence) + +**Template :** Voir Section 6.4 + +--- + +## 8. Monitoring et Outils Mutualisés + +### 8.1 Tableau de Bord Partagé + +**Objectif :** Visibilité collective sur santé DNS de la fédération + +**Outil recommandé :** Grafana mutualisé (hébergé par un membre volontaire) + +**URL exemple :** `https://monitoring.alliance-boreale.ca/d/dns-federation` + +**Panels :** + +1. **Statut Membres (heatmap)** + - Vert : DNS UP (100%) + - Jaune : Dégradé (secondaires OK, primaire down) + - Rouge : DOWN complet + +2. **Latence Résolution (par membre)** + - Graphe timeseries P50/P95/P99 + - Alerte visuelle si >200ms + +3. **Volume Requêtes (stacked area)** + - Requêtes/sec par membre + - Détection pics anormaux + +4. **DNSSEC Status** + - Validation chain OK/KO + - Expiration clés KSK/ZSK + +**Source données :** Prometheus federation + +### 8.2 Alerting Inter-Pairs + +**Principe :** Un membre peut monitorer le DNS d'un autre (avec consentement) + +**Configuration Prometheus (membre A monitore membre B) :** + +```yaml +# prometheus.yml (membre A) +scrape_configs: + - job_name: 'dns-czp-external' + metrics_path: '/probe' + params: + module: [dns_soa] + target: ['czp.alliance-boreale.ca'] + static_configs: + - targets: + - ns1.czp.alliance-boreale.ca + - ns2.czp.alliance-boreale.ca + relabel_configs: + - source_labels: [__address__] + target_label: __param_target + - source_labels: [__param_target] + target_label: instance + - target_label: __address__ + replacement: 127.0.0.1:9115 # Blackbox Exporter local +``` + +**Alertes envoyées à membre concerné :** + +```yaml +# alertmanager.yml +route: + receiver: 'matrix' + routes: + - match: + job: 'dns-czp-external' + receiver: 'matrix-czp' + continue: true + +receivers: + - name: 'matrix-czp' + webhook_configs: + - url: 'https://matrix.alliance-boreale.ca/webhook/czp-alerts' +``` + +### 8.3 Tests Automatisés (DNS Probes) + +**Smokeping pour latence historique** + +```bash +# Installation +apt install smokeping + +# Configuration +++ DNS-czp +menu = DNS Chezlepro +title = Latence DNS czp.alliance-boreale.ca +probe = DNS +host = ns1.czp.alliance-boreale.ca + +++ DNS-nul +menu = DNS Nuage Libre +title = Latence DNS nul.alliance-boreale.ca +probe = DNS +host = ns1.nul.alliance-boreale.ca +``` + +**Healthchecks.io (optionnel)** + +Pour monitoring externe (hors infrastructure Alliance) : + +```bash +# Cron job teste DNS toutes les 5 min +*/5 * * * * dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca SOA +short > /dev/null && curl -fsS -m 10 --retry 5 https://hc-ping.com/UUID-czp-dns +``` + +**DNSViz automatisé** + +```bash +# Script hebdomadaire vérifie DNSSEC +#!/bin/bash +# /etc/cron.weekly/dnsviz-check + +ZONE="czp.alliance-boreale.ca" +REPORT_URL="https://dnsviz.net/d/${ZONE}/dnssec/" + +curl -s "$REPORT_URL" | grep -q "No errors" + +if [ $? -eq 0 ]; then + echo "✅ DNSSEC OK pour ${ZONE}" +else + echo "❌ DNSSEC ERREUR pour ${ZONE}" + # Notification Matrix + curl -X POST https://matrix.alliance-boreale.ca/webhook/dns-alerts \ + -d "{\"zone\": \"${ZONE}\", \"status\": \"dnssec_error\", \"url\": \"${REPORT_URL}\"}" +fi +``` + +--- + +## 9. Retrait et Transition + +### 9.1 Procédure de Retrait Propre + +**Cas 1 : Retrait volontaire d'un membre** + +**Étapes :** + +1. **Notification préalable : 14 jours minimum** + + Post Matrix #annonces : + ``` + 📢 Notification de retrait + + Membre : Chezlepro (czp) + Date effective : 2025-11-15 + Zone concernée : czp.alliance-boreale.ca + + Transition planifiée : + - Délégation DNS maintenue jusqu'au 2025-11-15 23:59 UTC + - Après cette date, zone supprimée de alliance-boreale.ca + - Secondaires croisés désactivés + + Contact pour questions : admin@chezlepro.tech + ``` + +2. **Migration des zones déléguées (si applicable)** + + Si d'autres membres utilisaient `*.czp.alliance-boreale.ca` : + - Coordonner migration vers nouveau domaine + - Délai suffisant (14 jours minimum) + +3. **Désactivation progressive** + + | Jour | Action | + |------|--------| + | J-14 | Notification publique | + | J-7 | Désactivation AXFR croisé vers autres membres | + | J-3 | TTL réduits à 300s (préparation suppression) | + | J-0 | Suppression enregistrements NS dans zone parent | + | J+1 | Désactivation serveurs DNS membre | + +4. **Nettoyage Registraire** + + ```yaml + # registraire/membres/m001-chezlepro.yml + status: withdrawn + withdrawn_date: "2025-11-15" + dns: + status: deactivated + last_active: "2025-11-15" + ``` + +**Cas 2 : Retrait forcé (non-conformité grave)** + +**Cas exceptionnels :** +- Compromission sécurité non résolue (>30 jours) +- Violation répétée standards techniques +- Indisponibilité prolongée (>99% downtime sur 3 mois) + +**Procédure :** +1. Décision Cercle Éthique & Conformité (vote consentement) +2. Notification membre concerné (7 jours pour remédiation) +3. Si non-remédiation : Retrait forcé (délégation supprimée sous 48h) +4. Communication publique (transparence, mais sans humiliation) + +### 9.2 Délais de Préavis + +| Type de retrait | Préavis | Rationale | +|----------------|---------|-----------| +| Volontaire (membre actif) | 14 jours | Temps migration utilisateurs | +| Volontaire (membre probation) | 7 jours | Moins d'impact | +| Forcé (sécurité) | 48h | Urgence | +| Forcé (non-conformité) | 7 jours | Chance remédiation | + +### 9.3 Archivage des Configurations + +**Responsabilité : Membre sortant** + +**À conserver (membre) :** +- Export complet zone DNS (AXFR dump) +- Configuration serveurs (PowerDNS, BIND) +- Clés DNSSEC (backup sécurisé) +- Logs incidents (6 derniers mois minimum) + +**À fournir (Alliance) :** +- Post-mortem si applicable +- Documentation leçons apprises +- Playbooks Ansible (si contribués) + +**Responsabilité : Alliance** + +**À archiver (Registraire) :** +- Fiche membre (status: withdrawn) +- Historique labels +- Contributions (timebank, audits) +- Décisions liées au membre + +**Rétention :** 5 ans (conformité juridique OBNL) + +--- + +## 10. Annexes + +### Annexe A : Checklist Onboarding DNS + +**Pour nouveau membre :** + +- [ ] Serveurs DNS installés (ns1, ns2 minimum) +- [ ] Zone créée localement (`[slug].alliance-boreale.ca`) +- [ ] SOA configuré (serial, refresh, retry, expire, minimum) +- [ ] NS records configurés +- [ ] AXFR fonctionnel ns1 → ns2 +- [ ] IPs publiques stables et documentées +- [ ] Firewall configuré (port 53 UDP/TCP ouvert) +- [ ] (Optionnel) DNSSEC activé + DS records générés +- [ ] (Optionnel) TSIG configuré pour AXFR +- [ ] Tests résolution locale réussis +- [ ] Demande délégation soumise Matrix +- [ ] Validation technique par pair +- [ ] Délégation active dans zone parent +- [ ] Tests résolution publique réussis +- [ ] Enregistrement Registraire mis à jour + +### Annexe B : Commandes de Diagnostic + +**Test résolution depuis Internet :** +```bash +dig @8.8.8.8 czp.alliance-boreale.ca NS +dig @1.1.1.1 mail.czp.alliance-boreale.ca A +``` + +**Test AXFR (depuis serveur autorisé) :** +```bash +dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca AXFR +``` + +**Test DNSSEC :** +```bash +dig +dnssec @8.8.8.8 czp.alliance-boreale.ca SOA +delv @8.8.8.8 czp.alliance-boreale.ca SOA +``` + +**Vérification chaîne DNSSEC :** +```bash +drill -TD czp.alliance-boreale.ca @8.8.8.8 +``` + +**Test latence :** +```bash +time dig @ns1.czp.alliance-boreale.ca czp.alliance-boreale.ca SOA +short +``` + +**Vérification propagation globale :** +```bash +# Tool: whatsmydns.net +# https://www.whatsmydns.net/#A/mail.czp.alliance-boreale.ca +``` + +### Annexe C : Configuration PowerDNS Référence + +**Installation (Debian/Ubuntu) :** +```bash +apt update +apt install pdns-server pdns-backend-pgsql postgresql +``` + +**Configuration minimale (`/etc/powerdns/pdns.conf`) :** +```ini +launch=gpgsql +gpgsql-host=/var/run/postgresql +gpgsql-dbname=powerdns +gpgsql-user=pdns +gpgsql-password=SecurePasswordHere + +local-address=0.0.0.0 +local-port=53 + +master=yes +slave=yes + +api=yes +api-key=SecureAPIKeyHere +webserver=yes +webserver-address=0.0.0.0 +webserver-port=8081 +webserver-allow-from=10.0.0.0/8 + +dnssec=yes +default-soa-content=ns1.@ admin.@ 0 3600 1800 1209600 3600 + +log-dns-queries=no +log-dns-details=yes +loglevel=4 +``` + +**Création base de données :** +```bash +sudo -u postgres createdb powerdns +sudo -u postgres createuser pdns +sudo -u postgres psql powerdns < /usr/share/doc/pdns-backend-pgsql/schema.pgsql.sql +``` + +**Création zone :** +```bash +pdnsutil create-zone czp.alliance-boreale.ca +pdnsutil add-record czp.alliance-boreale.ca @ NS ns1.czp.alliance-boreale.ca +pdnsutil add-record czp.alliance-boreale.ca @ NS ns2.czp.alliance-boreale.ca +pdnsutil add-record czp.alliance-boreale.ca ns1 A 198.51.100.10 +pdnsutil add-record czp.alliance-boreale.ca ns2 A 198.51.100.11 +``` + +**Activation DNSSEC :** +```bash +pdnsutil secure-zone czp.alliance-boreale.ca +pdnsutil set-nsec3 czp.alliance-boreale.ca '1 0 10 ab' narrow +pdnsutil rectify-zone czp.alliance-boreale.ca +``` + +**Export DS records :** +```bash +pdnsutil show-zone czp.alliance-boreale.ca | grep DS +``` + +### Annexe D : Glossaire + +| Terme | Définition | +|-------|------------| +| **AXFR** | Transfert complet de zone DNS depuis primaire vers secondaires | +| **DS Record** | Delegation Signer - Lie zone enfant DNSSEC à zone parent | +| **KSK** | Key Signing Key - Clé maître DNSSEC (signe ZSK) | +| **NOTIFY** | Notification envoyée par primaire aux secondaires lors de changement | +| **SOA** | Start of Authority - Enregistrement définissant zone autoritaire | +| **TSIG** | Transaction Signature - Authentification cryptographique AXFR | +| **ZSK** | Zone Signing Key - Clé DNSSEC qui signe les enregistrements | + +### Annexe E : Références + +**RFCs :** +- RFC 1034, 1035 : DNS (Domain Name System) +- RFC 1996 : DNS NOTIFY +- RFC 2136 : DNS UPDATE +- RFC 4033-4035 : DNSSEC +- RFC 5936 : AXFR +- RFC 8945 : TSIG + +**Documentation PowerDNS :** +- https://doc.powerdns.com/authoritative/ +- https://doc.powerdns.com/authoritative/dnssec/ + +**Outils de validation :** +- DNSViz : https://dnsviz.net +- Zonemaster : https://zonemaster.net +- IntoDNS : https://intodns.com + +**Monitoring :** +- PowerDNS Exporter : https://github.com/janeczku/powerdns_exporter +- Blackbox Exporter : https://github.com/prometheus/blackbox_exporter + +--- + +## MÉTADONNÉES + +**Document :** 05_Operation_DNS_Federee.md +**Version :** 1.0 +**Date de création :** 23 octobre 2025 +**Auteur :** Claude (profils #4 Architecte Réseau, #10 Auditeur Sécurité) +**Révision par :** Cercle Technique +**Statut :** DRAFT - À valider +**Longueur :** ~10 000 mots (20 pages) +**Licence :** CC BY-SA 4.0 + +**Sources utilisées :** +- `00_Glossaire_et_Definitions.md` (AXFR, DNSSEC, DNS autoritaire) +- `nomenclature_v2.md` (nommage serveurs DNS, adressage IP) +- `devis_alliance_boreale_v2.md` (structure Document 5) +- `08_Processus_Onboarding_Membres.md` (critères DNS onboarding) +- `01_Charte_Fondatrice_v2_1.md` (Couche 2, valeurs) + +**Prochaine révision prévue :** Avril 2026 (après 6 mois d'opération) + +--- + +**Changelog :** +- 2025-10-23 v1.0 : Création initiale Document 5 (Option B) + +--- + +**FIN DE L'OPÉRATION DNS FÉDÉRÉE** + +*"Chaque membre gère ses propres zones. Ensemble, nous assurons leur résilience."* + +🌲 **L'Alliance Boréale** +*DNS fédéré, autonomie locale, résilience collective.* diff --git a/docs/constitution/2025-10-12 - Cadre_de_conformite_label_de_prestige_lalliance_boreale.md b/docs/constitution/2025-10-12 - Cadre_de_conformite_label_de_prestige_lalliance_boreale.md deleted file mode 100644 index 895c42e..0000000 --- a/docs/constitution/2025-10-12 - Cadre_de_conformite_label_de_prestige_lalliance_boreale.md +++ /dev/null @@ -1,146 +0,0 @@ -# Cadre de conformité & label de prestige — L’Alliance Boréale - -> **But** : garantir que les partenaires membres incarnent les valeurs de l’Alliance (logiciels libres, souveraineté, sobriété, transparence, sécurité, respect de la vie privée) et offrir un **label de prestige** reconnu. - ---- - -## 1) Principes directeurs -- **Alignement de valeurs** : souveraineté numérique, logiciels libres, données localisées, éthique. -- **Preuve par l’évidence** : indicateurs vérifiables, journaux publics, tests réguliers. -- **Proportionnalité** : exigences adaptées à la taille/risque; progression possible par paliers. -- **Pairs avant tout** : évaluation par les pairs avec arbitrage léger et traçabilité. -- **Transparence utile** : ce qui impacte les usagers est public, le reste est prouvable sur demande. - ---- - -## 2) Périmètre de conformité (domaines évalués) -1. **Gouvernance & éthique** - – Charte interne signée, registre des responsabilités, politique de conflits d’intérêts. -2. **Sécurité de l’information** - – Gestion des vulnérabilités (SLA correctifs), MFA admins, sauvegardes 3‑2‑1 testées, réponse à incident. -3. **Vie privée & Loi 25** - – Registre des traitements, base légale, DPIA si nécessaire, politiques de rétention et droits des personnes. -4. **Interopérabilité & fédération** - – Identités (Keycloak/OpenID/SAML), courriel, fichiers/visio; métadonnées de fédération publiées. -5. **Opérations & résilience** - – Monitoring, journaux ≥ 90 j, capacité/disponibilité, runbooks/documentation, test de restauration trimestriel. -6. **Sobriété numérique** - – Mesure de consommation, optimisation (sleep/offload), choix matériels/logiciels frugaux, indicateurs par service. - ---- - -## 3) Niveaux de label (prestige) -- **Boréal Bronze** (Base conforme) - Minima atteints sur 6 domaines, preuves fournies, 0 non‑conformité majeure ouverte. -- **Boréal Argent** (Solide) - Bronze + score global ≥ 70/100, audit pair semestriel sans réserve majeure, transparence renforcée (status public, runbook). -- **Boréal Or** (Référence) - Argent + score ≥ 85/100, exercices de crise annuels, indicateurs de sobriété publiés, tests de restauration réussis sur 12 derniers mois. -- **Boréal Platine** (Excellence) - Or + amélioration continue démontrée, plan de continuité documenté et testé, chiffrement bout‑à‑bout quand pertinent, preuves tierces (ex.: pentest annuel partagé aux pairs). - -> **Validité** : 12 mois. Recertification annuelle; surveillance continue (voir §6). - ---- - -## 4) Système de points (100 pts) -Chaque domaine est noté **0 à 5** puis **pondéré**. Score final = somme pondérée, normalisée /100. - -| Domaine | Pondération | Exemples de critères (0→5) | -|---|---:|---| -| Gouvernance & éthique | 15% | 0: aucun doc; 3: charte signée+registre R&R; 5: revue annuelle + COI géré | -| Sécurité de l’info | 25% | 0: pas de MFA/backups; 3: MFA admins+3‑2‑1+patch<30j; 5: pentest annuel+EDR+SLA<7j critique | -| Vie privée & Loi 25 | 20% | 0: pas de registre; 3: registre+politique droits; 5: DPIA outillé + logs d’accès | -| Interop & fédération | 15% | 0: silo; 3: OIDC/SAML actifs; 5: métadonnées publiées+tests inter‑nœuds | -| Opérations & résilience | 15% | 0: pas de monitoring; 3: monitoring+runbooks; 5: tests DR réussis trimestriels | -| Sobriété numérique | 10% | 0: non mesuré; 3: mesure+objectifs; 5: indicateurs publics+gains démontrés | - -**Seuils** : Bronze ≥ 55, Argent ≥ 70, Or ≥ 85, Platine ≥ 92 **et** aucun « blocant ». - -> **Blocants** (kill‑switch) : pas de sauvegardes effectives, pas de MFA admins, incident grave non notifié, manquement majeur Loi 25 non corrigé. - ---- - -## 5) Processus de labellisation -1. **Auto‑évaluation** (questionnaire + pièces) - – Fichier YAML/JSON structuré + liens de preuves; attestation signée. -2. **Revue par les pairs** (≤ 7 jours) - – 2 examinateurs de nœuds distincts; questions/réserves tracées. -3. **Décision** - – Consentement par défaut; en cas d’objection → arbitrage (3 référents élus). -4. **Publication** - – Entrée dans le **Registraire des partenaires** avec **niveau** et **score**; rapport public « light ». -5. **Validité & suivi** - – 12 mois; recert annuelle; surveillance continue (status/alertes RSS). - ---- - -## 6) Surveillance continue & incidents -- **Flux status** public (SLA, disruptions) + **webhooks** d’alerte. -- **Notification inter‑nœuds** < 24 h si risque fédératif (IOC, périmètre, mesures). -- **Post‑mortem light** ≤ 10 j pour incidents impactant des pairs/usagers. - ---- - -## 7) Sanctions & remédiation -- **Plan de correction** sous 30 j pour non‑conformités majeures. -- **Ajustement temporaire du label** (ex.: Or → Argent) en cas de réserve. -- **Suspension** (interop réduite) si blocant persistant. -- **Radiation** en dernier recours (décision arbitrage). - ---- - -## 8) Règles d’usage du label (marque de prestige) -- **Droit d’usage** : accordé pour la durée de validité; doit mentionner **année et niveau** (ex.: *Boréal Or 2026*). -- **Prohibitions** : pas d’usage trompeur ou hors périmètre; retrait immédiat si suspension/radiation. -- **Visuels** : kit officiel (logos, badges SVG), couleurs et marges; interdiction de modification non approuvée. -- **Référencement** : chaque badge public doit **lienner** vers la fiche **Registraire** correspondante. - ---- - -## 9) Transparence (ce qui est public) -- Identité du nœud et contacts génériques (legal/security/noc/privacy). -- Niveau du label, score global et date d’expiration. -- Liens : status, politiques publiques, métadonnées de fédération, runbook public. - ---- - -## 10) Annexes pratiques -### 10.1 Modèle de **fiche Registraire** (extraits publics) -```yaml -id: tik-007 -legal_name: "TechnoLibre coop." -status: active -label: - level: "Boréal Or" - score: 88 - valid_until: "2026-10-31" -public_urls: - status: "https://status.technolibre.org" - policies: "https://technolibre.org/policies" - federation: "https://id.technolibre.org/realms/boreal/.well-known/openid-configuration" -``` - -### 10.2 Grille d’auto‑évaluation (résumé) -- MFA admins : Oui/Non -- Sauvegardes 3‑2‑1 test trimestriel : Oui/Non (preuve) -- Registre traitements & politique droits : Oui/Non (lien) -- Métadonnées fédération publiées : Oui/Non (URL) -- Monitoring public ou partage pair : Oui/Non -- Indicateurs sobriété publiés : Oui/Non (ou plan) - -### 10.3 Modèle de **résolution interne** — Usage du label -``` -Chezlepro inc. — Résolutions du CA -Objet : Adhésion & label « L’Alliance Boréale » - -IL EST RÉSOLU : -• D’adhérer au cadre de conformité de L’Alliance Boréale; -• D’autoriser la publication de la fiche Registraire et l’usage du badge de niveau obtenu; -• De maintenir les minima et de se soumettre aux audits pairs et recertifications annuelles. -``` - ---- - -**Version** : v1.0 (proposée) — prête à itérer avec tes partenaires. - diff --git a/docs/constitution/cadre_de_conformite_label_de_prestige_lalliance_boreale.md b/docs/constitution/cadre_de_conformite_label_de_prestige_lalliance_boreale.md deleted file mode 100644 index 895c42e..0000000 --- a/docs/constitution/cadre_de_conformite_label_de_prestige_lalliance_boreale.md +++ /dev/null @@ -1,146 +0,0 @@ -# Cadre de conformité & label de prestige — L’Alliance Boréale - -> **But** : garantir que les partenaires membres incarnent les valeurs de l’Alliance (logiciels libres, souveraineté, sobriété, transparence, sécurité, respect de la vie privée) et offrir un **label de prestige** reconnu. - ---- - -## 1) Principes directeurs -- **Alignement de valeurs** : souveraineté numérique, logiciels libres, données localisées, éthique. -- **Preuve par l’évidence** : indicateurs vérifiables, journaux publics, tests réguliers. -- **Proportionnalité** : exigences adaptées à la taille/risque; progression possible par paliers. -- **Pairs avant tout** : évaluation par les pairs avec arbitrage léger et traçabilité. -- **Transparence utile** : ce qui impacte les usagers est public, le reste est prouvable sur demande. - ---- - -## 2) Périmètre de conformité (domaines évalués) -1. **Gouvernance & éthique** - – Charte interne signée, registre des responsabilités, politique de conflits d’intérêts. -2. **Sécurité de l’information** - – Gestion des vulnérabilités (SLA correctifs), MFA admins, sauvegardes 3‑2‑1 testées, réponse à incident. -3. **Vie privée & Loi 25** - – Registre des traitements, base légale, DPIA si nécessaire, politiques de rétention et droits des personnes. -4. **Interopérabilité & fédération** - – Identités (Keycloak/OpenID/SAML), courriel, fichiers/visio; métadonnées de fédération publiées. -5. **Opérations & résilience** - – Monitoring, journaux ≥ 90 j, capacité/disponibilité, runbooks/documentation, test de restauration trimestriel. -6. **Sobriété numérique** - – Mesure de consommation, optimisation (sleep/offload), choix matériels/logiciels frugaux, indicateurs par service. - ---- - -## 3) Niveaux de label (prestige) -- **Boréal Bronze** (Base conforme) - Minima atteints sur 6 domaines, preuves fournies, 0 non‑conformité majeure ouverte. -- **Boréal Argent** (Solide) - Bronze + score global ≥ 70/100, audit pair semestriel sans réserve majeure, transparence renforcée (status public, runbook). -- **Boréal Or** (Référence) - Argent + score ≥ 85/100, exercices de crise annuels, indicateurs de sobriété publiés, tests de restauration réussis sur 12 derniers mois. -- **Boréal Platine** (Excellence) - Or + amélioration continue démontrée, plan de continuité documenté et testé, chiffrement bout‑à‑bout quand pertinent, preuves tierces (ex.: pentest annuel partagé aux pairs). - -> **Validité** : 12 mois. Recertification annuelle; surveillance continue (voir §6). - ---- - -## 4) Système de points (100 pts) -Chaque domaine est noté **0 à 5** puis **pondéré**. Score final = somme pondérée, normalisée /100. - -| Domaine | Pondération | Exemples de critères (0→5) | -|---|---:|---| -| Gouvernance & éthique | 15% | 0: aucun doc; 3: charte signée+registre R&R; 5: revue annuelle + COI géré | -| Sécurité de l’info | 25% | 0: pas de MFA/backups; 3: MFA admins+3‑2‑1+patch<30j; 5: pentest annuel+EDR+SLA<7j critique | -| Vie privée & Loi 25 | 20% | 0: pas de registre; 3: registre+politique droits; 5: DPIA outillé + logs d’accès | -| Interop & fédération | 15% | 0: silo; 3: OIDC/SAML actifs; 5: métadonnées publiées+tests inter‑nœuds | -| Opérations & résilience | 15% | 0: pas de monitoring; 3: monitoring+runbooks; 5: tests DR réussis trimestriels | -| Sobriété numérique | 10% | 0: non mesuré; 3: mesure+objectifs; 5: indicateurs publics+gains démontrés | - -**Seuils** : Bronze ≥ 55, Argent ≥ 70, Or ≥ 85, Platine ≥ 92 **et** aucun « blocant ». - -> **Blocants** (kill‑switch) : pas de sauvegardes effectives, pas de MFA admins, incident grave non notifié, manquement majeur Loi 25 non corrigé. - ---- - -## 5) Processus de labellisation -1. **Auto‑évaluation** (questionnaire + pièces) - – Fichier YAML/JSON structuré + liens de preuves; attestation signée. -2. **Revue par les pairs** (≤ 7 jours) - – 2 examinateurs de nœuds distincts; questions/réserves tracées. -3. **Décision** - – Consentement par défaut; en cas d’objection → arbitrage (3 référents élus). -4. **Publication** - – Entrée dans le **Registraire des partenaires** avec **niveau** et **score**; rapport public « light ». -5. **Validité & suivi** - – 12 mois; recert annuelle; surveillance continue (status/alertes RSS). - ---- - -## 6) Surveillance continue & incidents -- **Flux status** public (SLA, disruptions) + **webhooks** d’alerte. -- **Notification inter‑nœuds** < 24 h si risque fédératif (IOC, périmètre, mesures). -- **Post‑mortem light** ≤ 10 j pour incidents impactant des pairs/usagers. - ---- - -## 7) Sanctions & remédiation -- **Plan de correction** sous 30 j pour non‑conformités majeures. -- **Ajustement temporaire du label** (ex.: Or → Argent) en cas de réserve. -- **Suspension** (interop réduite) si blocant persistant. -- **Radiation** en dernier recours (décision arbitrage). - ---- - -## 8) Règles d’usage du label (marque de prestige) -- **Droit d’usage** : accordé pour la durée de validité; doit mentionner **année et niveau** (ex.: *Boréal Or 2026*). -- **Prohibitions** : pas d’usage trompeur ou hors périmètre; retrait immédiat si suspension/radiation. -- **Visuels** : kit officiel (logos, badges SVG), couleurs et marges; interdiction de modification non approuvée. -- **Référencement** : chaque badge public doit **lienner** vers la fiche **Registraire** correspondante. - ---- - -## 9) Transparence (ce qui est public) -- Identité du nœud et contacts génériques (legal/security/noc/privacy). -- Niveau du label, score global et date d’expiration. -- Liens : status, politiques publiques, métadonnées de fédération, runbook public. - ---- - -## 10) Annexes pratiques -### 10.1 Modèle de **fiche Registraire** (extraits publics) -```yaml -id: tik-007 -legal_name: "TechnoLibre coop." -status: active -label: - level: "Boréal Or" - score: 88 - valid_until: "2026-10-31" -public_urls: - status: "https://status.technolibre.org" - policies: "https://technolibre.org/policies" - federation: "https://id.technolibre.org/realms/boreal/.well-known/openid-configuration" -``` - -### 10.2 Grille d’auto‑évaluation (résumé) -- MFA admins : Oui/Non -- Sauvegardes 3‑2‑1 test trimestriel : Oui/Non (preuve) -- Registre traitements & politique droits : Oui/Non (lien) -- Métadonnées fédération publiées : Oui/Non (URL) -- Monitoring public ou partage pair : Oui/Non -- Indicateurs sobriété publiés : Oui/Non (ou plan) - -### 10.3 Modèle de **résolution interne** — Usage du label -``` -Chezlepro inc. — Résolutions du CA -Objet : Adhésion & label « L’Alliance Boréale » - -IL EST RÉSOLU : -• D’adhérer au cadre de conformité de L’Alliance Boréale; -• D’autoriser la publication de la fiche Registraire et l’usage du badge de niveau obtenu; -• De maintenir les minima et de se soumettre aux audits pairs et recertifications annuelles. -``` - ---- - -**Version** : v1.0 (proposée) — prête à itérer avec tes partenaires. -