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

1872 lines
50 KiB
Markdown
Raw Normal View History

Documents opérationels de L'Alliance Boréale
2025-10-23 17:05:54 -04:00
# 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 = <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 :**
```ini
[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)**
```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 <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**
```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 <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.*
Reference in a new issue Copy permalink