Cybersécurité

Zero trust : nouvelle approche de la sécurité réseau

12 min de lecture

Ce que vous saurez faire

  1. Principes Zero Trust
  2. mTLS entre services
  3. OIDC + MFA obligatoire
  4. Policy as Code avec OPA

Étape 1 — Principes

Classique: firewall périmétrique (confiance interne)
Zero Trust: AUCUN réseau n'est digne de confiance
Chaque requête: authentifiée, autorisée, chiffrée

ZTNA: Zero Trust Network Access
MFA: Multi-Factor Authentication
mTLS: mutual TLS (certs client + serveur)
PDP/PEP: Policy Decision/Enforcement Point

Étape 2 — Identité forte OIDC + MFA

# Keycloak
realm: itskillscenter
clientPolicies:
  - name: ensure-mfa
    condition: { authenticationFlowBinding: browser }
    executor: { type: force-second-factor, config: { minimum-level: 2 } }
passwordPolicy: "length(12) and upperCase(1) and digits(2)"
sessionIdleTimeout: PT15M
offlineSessionIdleTimeout: PT24H

Étape 3 — mTLS service-to-service

openssl genrsa -out ca.key 4096
openssl req -new -x509 -key ca.key -out ca.crt -days 365 \
  -subj "/CN=ItsSkillsCenter Internal CA"

openssl genrsa -out api.key 4096
openssl req -new -key api.key -out api.csr -subj "/CN=api.internal"
openssl x509 -req -in api.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out api.crt
ssl_client_certificate /etc/nginx/certs/ca.crt;
ssl_verify_client on;

Étape 4 — Service Mesh Istio

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: itsc-prod
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: api-allowed-callers
spec:
  selector: { matchLabels: { app: api } }
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/itsc-prod/sa/frontend"]
      to:
        - operation: { methods: ["GET","POST"], paths: ["/v1/*"] }

Étape 5 — Policy as Code avec OPA

package http.authz

default allow := false

allow {
  input.method == "GET"
  input.path == ["v1", "clients", _]
  input.user.role == "admin"
}

allow {
  input.method == "POST"
  input.path == ["v1", "factures"]
  input.user.role == "commercial"
  input.user.region == input.body.region
}

Étape 6 — ZTNA avec Tailscale/Cloudflare

{
  "acls": [
    { "action":"accept", "src":["group:devs"], "dst":["tag:prod-db:5432"] },
    { "action":"accept", "src":["group:sre"], "dst":["*:*"] }
  ],
  "groups": {
    "group:devs": ["aminata@sn","ousmane@sn"]
  },
  "tagOwners": {
    "tag:prod-db": ["group:sre"]
  }
}

Étape 7 — Workload Identity K8s

spec:
  serviceAccountName: api
  containers:
    - name: api
      volumeMounts:
        - name: oidc-token
          mountPath: /var/run/secrets/tokens
  volumes:
    - name: oidc-token
      projected:
        sources:
          - serviceAccountToken:
              path: aws-token
              expirationSeconds: 3600
              audience: sts.amazonaws.com

Étape 8 — Chiffrement au repos

CREATE EXTENSION IF NOT EXISTS pgcrypto;

INSERT INTO clients(nom, email_chiffre) VALUES
  ('SARL', pgp_sym_encrypt('contact@sarl.sn', current_setting('app.key')));

SELECT nom, pgp_sym_decrypt(email_chiffre, current_setting('app.key'))
FROM clients WHERE id = 42;

Étape 9 — Journalisation chaque requête

{
  "ts": "2026-04-22T10:15:03Z",
  "user": "aminata@itsc.sn",
  "service": "api",
  "method": "PATCH",
  "path": "/v1/factures/42",
  "ip": "10.0.3.14",
  "device_id": "mac-amina-01",
  "auth": { "mfa": true, "mfa_age_s": 320, "token_type": "oidc" },
  "decision": "allow",
  "policy": "billing.editor",
  "latency_ms": 118,
  "status": 200
}

Étape 10 — Migration 6 étapes

  1. Inventaire : services, flux, identités (machines + humains)
  2. MFA obligatoire sur toutes identités humaines
  3. Remplacer VPN par ZTNA (Tailscale, Cloudflare, Teleport)
  4. mTLS sur services internes critiques
  5. Policies par rôle et ressource (OPA, Kyverno)
  6. Journalisation centralisée + détection anomalies

Checklist

✓ SSO + MFA forcé partout
✓ mTLS entre services backend
✓ Policies OPA en CI
✓ ZTNA remplace VPN
✓ Short-lived tokens (OIDC)
✓ Chiffrement au repos (colonnes PII)
✓ Journalisation immuable
✓ Tests d'intrusion annuels

Un hébergeur abordable pour vos projets

Hostinger combine prix raisonnable et stabilité. Lien partenaire — pas de surcoût pour vous.

Choisir une offre →

Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.

Étape 1 — Comprendre le principe « never trust, always verify »

Le modèle Zero Trust, formalisé par John Kindervag chez Forrester en 2010 puis codifié par le NIST dans la publication SP 800-207 en 2020, renverse la logique périmétrique : aucun appareil, aucun utilisateur, aucune application n’est de confiance par défaut, même à l’intérieur du réseau. Chaque accès est authentifié, autorisé et chiffré, à chaque requête. Pour une PME ouest-africaine à Dakar ou Cotonou avec 30 collaborateurs et un mix télétravail/bureau, ce modèle est plus pertinent qu’un VPN classique.

Avant de déployer un outil, posez cinq questions sur papier : qui se connecte, depuis quel appareil, vers quelle ressource, à quel moment, depuis quelle géographie ? Les réponses dessinent votre future politique d’accès.

Étape 2 — Inventorier les ressources à protéger

Listez sur une feuille tous les actifs accessibles à distance : serveur de fichiers, ERP, CRM, panel d’administration WordPress, base de données, dépôt Git interne, panel Coolify, wiki BookStack, etc. Pour chacun, notez la criticité (haute, moyenne, basse) et le périmètre d’utilisateurs autorisés. C’est la matrice qui guidera toutes les décisions techniques.

Ressource              | Criticité | Utilisateurs autorisés
ERP Odoo               | Haute     | Compta + Direction
Wiki BookStack         | Moyenne   | Tous les salariés
Panel Coolify          | Haute     | DSI uniquement
Dépôt Gitea            | Moyenne   | Équipe Tech
Base de données prod   | Haute     | Lead dev + DSI

Sans cette matrice, toute politique Zero Trust devient du bricolage qui s’effondre au premier audit. Imprimez-la, faites-la valider par la direction, archivez-la dans BookStack avec un cycle de revue tous les 6 mois.

Étape 3 — Authentification multi-facteur partout

L’identité est le nouveau périmètre. MFA obligatoire pour tous les comptes ayant accès à une ressource de criticité moyenne ou haute. Privilégiez TOTP (Aegis, FreeOTP) plutôt que SMS, vulnérable au SIM swap répandu en Afrique de l’Ouest. Pour les comptes administrateurs, ajoutez une clé matérielle YubiKey ou Solokey (~22 000 FCFA pièce, achat unique).

Mettez en place un IdP central : Authentik ou Keycloak self-hostés font le travail pour 0 FCFA en plus du VPS. Tous les services internes s’authentifient via OIDC contre cet IdP. Quand un collaborateur quitte la PME, vous désactivez son compte une seule fois et il perd l’accès à toutes les ressources.

Étape 4 — Évaluer la posture des appareils

Zero Trust exige de vérifier l’état de l’appareil avant d’autoriser l’accès. Au minimum : OS à jour, disque chiffré (BitLocker, FileVault, LUKS), antivirus actif. Outils gratuits côté client : OSQuery pour collecter l’état, Fleet pour centraliser. Sur 30 postes, l’installation prend 1 jour homme.

Définissez 3 niveaux de posture : conforme (tout vert), tolérée (1 alerte mineure), non conforme (chiffrement absent ou OS périmé). Seuls les postes conformes accèdent aux ressources critiques. Les postes tolérés accèdent au wiki et au mail. Les postes non conformes sont coupés.

Étape 5 — Choisir un proxy d’accès Zero Trust

Trois options crédibles pour une PME ouest-africaine. Cloudflare Access : 0 USD jusqu’à 50 utilisateurs, intégration en 1 heure, IdP au choix, dépend de la disponibilité Internet vers Cloudflare. Pomerium : self-hosté, gratuit, déployable sur le même VPS Hetzner que vos applications (~2 960 FCFA/mois), demande 1 jour de configuration. Teleport : self-hosté, version Community gratuite, idéal si vous donnez aussi accès SSH et Kubernetes.

Pour démarrer sans coût et sans dépendance externe, choisissez Pomerium. Pour démarrer sans serveur à gérer, choisissez Cloudflare Access. Pour une équipe DevOps avec besoins SSH/K8s, choisissez Teleport.

Étape 6 — Déployer Pomerium devant les applications internes

Sur votre VPS Hetzner, installez Pomerium en mode tout-en-un. La configuration tient en 30 lignes YAML.

routes:
  - from: https://erp.exemple.sn
    to: http://localhost:8069
    policy:
      - allow:
          and:
            - email:
                is: '@exemple.sn'
            - groups:
                has: 'compta'
  - from: https://wiki.exemple.sn
    to: http://localhost:6875
    policy:
      - allow:
          or:
            - email:
                is: '@exemple.sn'
authenticate_service_url: https://auth.exemple.sn
idp_provider: oidc
idp_client_id: ...
idp_client_secret: ...
idp_provider_url: https://authentik.exemple.sn/application/o/pomerium/

Démarrez avec docker compose up -d. Tapez https://erp.exemple.sn dans un navigateur : Pomerium redirige vers l’IdP, vous authentifie, vérifie que vous êtes dans le groupe compta, puis ouvre l’accès. Toute requête sans cookie valide est rejetée avec 401.

Étape 7 — Micro-segmentation au niveau réseau

Côté infrastructure, isolez les services dans des réseaux Docker séparés. La base de données ne doit accepter de connexion que depuis l’application, pas depuis le serveur de monitoring ni depuis le poste du développeur. Sur Coolify ou docker-compose, déclarez explicitement les réseaux :

networks:
  app-net:
    internal: false
  db-net:
    internal: true

services:
  api:
    networks: [app-net, db-net]
  postgres:
    networks: [db-net]
  caddy:
    networks: [app-net]

Le réseau db-net avec internal: true n’a pas d’accès Internet sortant. Si quelqu’un compromet PostgreSQL, il ne peut ni télécharger un payload ni exfiltrer vers l’extérieur sans rebondir d’abord par l’API. Cette défense en profondeur ralentit considérablement un attaquant.

Étape 8 — Journaliser et alerter sur les accès anormaux

Pomerium et Cloudflare Access exposent des logs structurés JSON. Centralisez-les dans Loki + Grafana (gratuit, 30 minutes d’installation) et créez 3 alertes : 1) plus de 5 échecs d’authentification en 5 minutes pour le même utilisateur, 2) connexion depuis un pays non habituel (par exemple en dehors de la zone UEMOA), 3) connexion à 03:00 du matin un dimanche pour un compte non astreint.

Routez ces alertes vers un canal Discord ou Slack dédié à la sécurité. Trois alertes pertinentes valent mieux que 50 alertes que personne ne lit. Calibrez sur 2 semaines puis verrouillez les seuils.

Pour étoffer le tableau, voyez aussi notre tutoriel sur les headers de sécurité Caddy qui complète Pomerium côté navigateur, et notre guide sur Cloudflare gratuit pour PME africaines.

Étape 9 — Politique BYOD encadrée

À Dakar, Abidjan ou Bamako, beaucoup de collaborateurs utilisent leur ordinateur personnel. Plutôt que d’interdire (irréaliste), encadrez : exigez le chiffrement de disque, un mot de passe d’au moins 12 caractères, l’inscription dans Fleet, l’installation de l’agent Pomerium ou Cloudflare WARP. Documentez ces obligations dans une charte signée par chaque collaborateur, annexée au contrat de travail.

Pour les appareils mobiles, imposez l’authentification biométrique et l’effacement à distance via le compte Google ou Apple personnel du collaborateur. Vous n’avez pas besoin d’un MDM enterprise hors de prix pour atteindre 80 % du résultat.

Étape 10 — Plan de migration progressive sur 90 jours

Ne basculez pas tout d’un coup. Plan type sur 3 mois pour une PME de 30 personnes : mois 1 = mise en place IdP + MFA + inventaire des ressources ; mois 2 = déploiement Pomerium devant 2 applications pilotes (wiki, ERP) ; mois 3 = extension à toutes les applications, micro-segmentation réseau, alertes en production. Coût total typique : 1 VPS Hetzner ~2 960 FCFA/mois + 5 YubiKeys ~110 000 FCFA + 10 jours hommes répartis sur le trimestre.

À la fin du trimestre, supprimez le VPN historique. Vos collaborateurs travaillent depuis n’importe où, l’accès est plus rapide qu’avec le VPN, et vous dormez tranquille.

Étape 11 — Cas particulier des prestataires externes

Les développeurs freelance, comptables externes et auditeurs ont souvent besoin d’un accès temporaire. Plutôt que de créer un compte permanent dans votre IdP, utilisez les fonctions guest access ou tunnel partagé temporaire avec une expiration automatique au bout de 7 ou 30 jours. Pomerium et Cloudflare Access supportent les deux.

Documentez chaque accès accordé dans un registre simple : qui, quoi, jusqu’à quand. Un cron mensuel qui liste les comptes externes encore actifs vous évite l’oubli classique du prestataire payé six mois plus tôt qui garde un accès complet à vos serveurs.

Étape 12 — Indicateurs à suivre tous les mois

Pour piloter durablement, suivez 5 indicateurs simples présentés à la direction chaque mois : pourcentage d’utilisateurs avec MFA actif (cible 100 %), nombre d’appareils non conformes (cible 0), nombre d’alertes de sécurité ouvertes plus de 7 jours (cible 0), nombre d’accès temporaires expirés non révoqués (cible 0), temps moyen entre la détection d’une anomalie et l’investigation (cible < 4 heures).

Présentez ces 5 chiffres sur une slide unique. Si l’un dérape, vous savez exactement où agir. La sécurité devient mesurable et reproductible, pas un sujet vague qui revient seulement après un incident.

Étape 13 — Ressources officielles à consulter

Trois lectures indispensables, gratuites en ligne. NIST SP 800-207 « Zero Trust Architecture » publié en août 2020, document de référence mondial. ANSSI guide « Recommandations de sécurité relatives aux architectures Zero Trust » publié en 2024 pour le contexte francophone. CISA « Zero Trust Maturity Model » version 2.0 publiée en 2023, qui propose une grille d’auto-évaluation par paliers. Avec ces trois documents et la méthode décrite ci-dessus, vous avez 95 % du contenu nécessaire pour piloter votre projet Zero Trust à Dakar, Abidjan, Bamako ou Cotonou.

Étape 14 — Erreurs courantes à éviter

Première erreur : empiler Zero Trust par-dessus un VPN existant et ne jamais retirer le VPN. Vous doublez la complexité sans gain de sécurité. Deuxième erreur : exempter la direction du MFA pour leur « confort ». La direction est précisément la cible numéro 1 du phishing ciblé. Troisième erreur : oublier les services machine-to-machine (cron, scripts batch, intégrations API). Eux aussi doivent passer par l’IdP avec des comptes de service à durée de vie courte. Une PME ouest-africaine bien outillée peut atteindre un niveau Zero Trust mature en 6 mois pour moins de 200 000 FCFA d’investissement initial, hors temps interne.

Étape 15 — Premier exercice de table à organiser

Un mois après la mise en production, organisez un exercice de table de 90 minutes avec 4 ou 5 personnes. Scénario type : un collaborateur signale qu’il a cliqué sur un lien suspect dans un mail. Comment réagit l’équipe ? Qui désactive le compte dans l’IdP ? Qui consulte les logs Pomerium ? Qui décide d’isoler ou non le poste ? Qui informe la direction ? Qui rédige le post-mortem ?

L’exercice révèle systématiquement 3 ou 4 trous dans la procédure que vous corrigez à chaud. Documentez le scénario et la réponse dans BookStack, planifiez un nouvel exercice tous les semestres avec un scénario différent. La maturité Zero Trust se construit dans la répétition, pas dans la configuration initiale.

Partager
#sécurité

Articles Similaires