Confidentialite¶

Le service documentaire de l'organisation heberge des contenus de sensibilite variable : procedures publiques, guides internes, spécifications confidentielles, informations restreintes. Ce chapitre applique le modèle de classification a la documentation en s'appuyant sur le mécanisme d'isolation par build — chaque niveau de confiance produit un site statique autonome ne contenant physiquement que les pages autorisees.

Rappel du modèle de classification¶

Le modèle distingue quatre niveaux de classification, chacun associe a des exigences spécifiques d'accès et de protection.

Pour le detail complet du modèle et des zones de confiance associees, voir :

• Classification et zones de confiance
• Modèle de classification

Principe d'isolation par build¶

Un build par niveau¶

Chaque build est un site statique complet et autonome. Il ne contient que les pages correspondant a son niveau de classification et aux niveaux inférieurs. Il n'existe aucun mécanisme de masquage CSS, de contenu cache ou de filtrage a la volee : si une page n'est pas dans le build, son fichier HTML n'existe tout simplement pas sur disque.

Conséquence de sécurité¶

Cette architecture garantit que même en cas de compromission du serveur, seul le contenu du niveau de build correspondant est expose. Un attaquant qui obtiendrait un accès shell a la machine hebergeant le build interne n'y trouverait aucun fichier issu des pages confidentiel ou restreint.

La separation physique des builds s'applique aussi bien aux fichiers HTML qu'aux assets derives (images, fichiers PDF exportes, fragments de contenu). Le processus de build filtre l'ensemble des ressources selon la valeur du champ classification du front matter de chaque page.

Configuration du filtre de build¶

Dans mkdocs.yml, le plugin de classification lit le front matter de chaque fichier source et exclut les pages dont le niveau depasse celui du build cible :

# mkdocs.yml — exemple pour le build "interne"
plugins:
  - classification-filter:
      build_level: interne
      allowed_levels:
        - public
        - interne
      fail_on_unknown: true   # rejet strict des valeurs inconnues

Le parametre fail_on_unknown: true garantit un comportement fail-fast : toute valeur de classification non reconnue provoque l'echec du build avant la génération des fichiers de sortie.

Protection contre les erreurs de marquage¶

Validation stricte des valeurs¶

Le plugin de classification rejette toute valeur classification inconnue au moment du build. Cela empeche des erreurs typographiques silencieuses (par exemple confidentel au lieu de confidentiel) de provoquer une inclusion ou une exclusion non souhaitee d'une page.

Si une page comporte un front matter invalide, le build échoue avec un message explicite :

ERROR - Page 'docs/secrets/plan-strategique.md': unknown classification value 'confidentel'.
Allowed values: public, interne, confidentiel, restreint.
Build aborted.

Valeur par defaut et alerte CI¶

Pour détecter les pages non marquées, un script de validation peut etre integre a la pipeline CI en complement du build :

#!/bin/bash
# scripts/check-classification.sh
# Liste toutes les pages sans champ 'classification' dans le front matter.
set -euo pipefail

DOCS_DIR="${1:-docs}"
MISSING=0

while IFS= read -r -d '' file; do
  if ! grep -q '^classification:' "${file}"; then
    echo "WARN: pas de classification dans ${file}"
    MISSING=$((MISSING + 1))
  fi
done < <(find "${DOCS_DIR}" -name '*.md' -print0)

if [ "${MISSING}" -gt 0 ]; then
  echo ""
  echo "${MISSING} page(s) sans classification explicite (traitees comme 'public')."
  exit 1
fi

echo "Toutes les pages ont une classification explicite."

Ce script peut etre execute en mode informatif (sortie non bloquante) ou en mode strict (exit 1) selon la politique de l'organisation.

Protection du routage¶

Responsabilité du reverse proxy¶

Le routage vers le bon build est une decision serveur, jamais une decision client. Le reverse proxy (Caddy, dans l'architecture décrite en installation) inspecte le token JWT de l'utilisateur, extrait le claim de clearance et achemine la requête vers le répertoire de build correspondant.

Aucune logique de filtrage ne s'effectue côté navigateur. Le client reçoit uniquement les pages du build auquel il est autorise a accéder.

Absence de listing de répertoires¶

Les répertoires de builds sont configures sans listing. Un utilisateur qui tenterait d'accéder à la racine d'un build pour en énumérer les fichiers obtiendra une réponse 403 ou une page d'erreur personnalisee, jamais un index de fichiers.

# Caddyfile — desactiver le listing (valeur par defaut dans Caddy)
file_server {
    browse  # NE PAS inclure cette directive
}

Protection contre le path traversal¶

Les builds sont heberges dans des répertoires séparés et isoles. Aucun lien symbolique ni chemin relatif ne permet à un utilisateur du build interne d'accéder au contenu de ../confidentiel/ ou ../restreint/. Le reverse proxy normalise les chemins et bloque toute tentative de remontee d'arborescence avant de transmettre la requête au serveur de fichiers.

En-têtes de sécurité¶

Les en-têtes de sécurité HTTP sont appliques a l'ensemble des réponses, quel que soit le build servi. Leur configuration est centralisee dans le Caddyfile décrit en installation :

• Content-Security-Policy : limitation des sources de scripts et de styles
• X-Frame-Options: DENY : prevention du clickjacking
• Strict-Transport-Security : imposition du HTTPS
• X-Content-Type-Options: nosniff : prevention du MIME sniffing
• Referrer-Policy: no-referrer : protection des informations de navigation

Journalisation des accès¶

Structure d'un événement de log¶

Chaque accès au service documentaire est enregistre avec les informations suivantes :

Format JSON pour integration SIEM¶

Les logs sont emis en JSON structurée pour faciliter l'ingestion dans un SIEM (ELK, Loki, Splunk, Wazuh) :

{
  "timestamp": "2026-04-17T09:14:32.847Z",
  "request_id": "a3f2c1d8-7e56-4b90-a123-e4f5d6c7b8a9",
  "user_id": "u-8f3a2c1d",
  "clearance": "confidentiel",
  "method": "GET",
  "path": "/architecture/decisions/adr-0042.html",
  "status": 200,
  "source_ip": "10.10.5.22",
  "user_agent": "Mozilla/5.0 (X11; Linux x86_64)",
  "response_time_ms": 18
}

Les accès refuses (403) et les tentatives d'accès a des ressources inexistantes (404) sont traces avec le même format, en ajoutant un champ deny_reason lorsque la decision de refus est explicite.

Pour la politique de retention et les procedures d'audit, voir Audit et traçabilité.

Revocation d'accès¶

Procedure de revocation¶

La revocation d'un accès s'effectue dans Keycloak en retirant l'utilisateur du groupe ou en supprimant le claim de clearance correspondant :

1. Ouvrir la console d'administration Keycloak
2. Naviguer vers Users > selectionner l'utilisateur cible
3. Onglet Groups : retirer le groupe correspondant au niveau a revoquer
4. Onglet Attributes : supprimer ou modifier le claim doc_clearance si applicable
5. Optionnel : forcer la deconnexion de toutes les sessions actives via Sessions > Logout all sessions

La modification prend effet sur le prochain renouvellement de token JWT. Avec une duree de session courte (voir ci-dessous), l'impact d'un accès residuel est borne dans le temps.

Duree de session recommandee¶

Ces valeurs sont configurees dans Keycloak au niveau du realm (parametre SSO Session Max) et peuvent etre affinees par client OIDC.

Validation systematique des tokens¶

Le reverse proxy ne met pas les tokens JWT en cache. Chaque requête fait l'objet d'une validation du token aupres du endpoint d'introspection Keycloak (ou par vérification locale de la signature et des claims si le proxy supporte les JWKS). Cela garantit que la revocation est prise en compte au prochain accès apres expiration du token courant, sans delai supplémentaire lie a un cache proxy.

Modèle de menaces¶

Le tableau suivant recense les menaces principales et les mitigations correspondantes dans l'architecture documentaire.