Alliance-Boreale/alliance-boreale
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
alliance-boreale/docs/constitution/05_Architecture_Reference_Standards_Techniques.md
Dan Allaire 0437625565
Some checks are pending
CI / yaml-lint (push) Waiting to run
Details
CI / ssot-export (push) Waiting to run
Details
CI / tests (push) Waiting to run
Details
CI / docs (push) Waiting to run
Details
Documents opérationels de L'Alliance Boréale
2025-10-23 17:05:54 -04:00

50 KiB
Raw Blame History

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 :

# 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 :

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 :

[Interface]
PrivateKey = <clé_privée_m001>
Address = 10.100.1.1/32
ListenPort = 51820

[Peer]
# m002
PublicKey = <clé_publique_m002>
AllowedIPs = 10.100.2.1/32, 10.2.0.0/16
Endpoint = m002.example.com:51820
PersistentKeepalive = 25

Sur m002 :

[Interface]
PrivateKey = <clé_privée_m002>
Address = 10.100.2.1/32
ListenPort = 51820

[Peer]
# m001
PublicKey = <clé_publique_m001>
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  <IP_publique_m001>
ns2.boreal.ca.  A  <IP_publique_m002>
ns3.boreal.ca.  A  <IP_publique_m003>

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  <IP_m001>
ns2  A  <IP_m002>
ns3  A  <IP_m003>

; Outils communs L'Alliance
registraire  A  <IP_tool_server>
forge        A  <IP_tool_server>
wiki         A  <IP_tool_server>
matrix       A  <IP_tool_server>

; 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)

    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

    dnssec-signzone -o chezlepro.boreal.ca chezlepro.boreal.ca.zone

  3. Publication DS record chez parent (boreal.ca)

    chezlepro  DS  12345 8 2 <hash>

  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

    dig @8.8.8.8 mail.chezlepro.boreal.ca
dig @1.1.1.1 chezlepro.boreal.ca NS

  2. Réplication AXFR

    dig @ns2.chezlepro.boreal.ca chezlepro.boreal.ca AXFR

  3. DNSSEC (si activé)

    dig +dnssec chezlepro.boreal.ca

  4. Santé des NS

    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 :

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 :

# 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

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

# 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é)

# Variables sensibles (Ansible Vault)

vault_alliance_dns_tsig_key: "base64SecretKey=="
vault_alliance_backup_gpg_passphrase: "SuperSecretPassphrase123"
vault_prometheus_admin_password: "AnotherSecretPass456"

Chiffrement :

ansible-vault encrypt group_vars/all/vault.yml

Playbook (Exemple)

Fichier : playbooks/dns-setup.yml

---
- 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) :

# 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 :

- 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) :

# .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

# 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 :

# 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 :

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

/usr/lib/nagios/plugins/check_http -H mail.chezlepro.boreal.ca -S -C 30
# Alerte si expiration < 30 jours

3. Prometheus + Blackbox Exporter

- 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 :

- 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) :

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)

[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)

---
- 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

#!/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

#!/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 <domain>"
    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.