ZTNA — Zero Trust Network Access

Le modele Zero Trust

Probleme du VPN traditionnel

Un VPN classique fonctionne comme un pont-levis : une fois l'utilisateur authentifie, il a acces a tout le reseau interne. C'est le modele "chateau fort" — dur a l'exterieur, mou a l'interieur.

Aspect VPN traditionnel ZTNA
Principe "Fait confiance apres authentification" "Ne jamais faire confiance, toujours verifier"
Perimetre Acces au reseau entier Acces application par application
Authentification Une seule fois a la connexion Continue (chaque requete)
Posture endpoint Non verifiee Verifiee en continu (AV, OS, cert)
Surface d'attaque Reseau entier expose Seules les apps autorisees sont visibles
Mouvement lateral Possible Impossible (pas d'acces reseau) 
graph LR
    subgraph ANCIEN["VPN Traditionnel"]
        VPN_USER["Utilisateur"] -->|"Tunnel VPN"| VPN_NET["Reseau entier expose"]
        VPN_NET --> APP1["App 1"]
        VPN_NET --> APP2["App 2"]
        VPN_NET --> APP3["App 3"]
        VPN_NET --> SERVERS["Serveurs internes"]
    end
graph LR
    subgraph ZTNA_NEW["ZTNA FortiGate"]
        ZTNA_USER["Utilisateur"] -->|"Tunnel app 1"| ZTNA_APP1["App 1 autorisee"]
        ZTNA_USER -.->|"Bloque"| ZTNA_APP2["App 2"]
        ZTNA_USER -.->|"Bloque"| ZTNA_APP3["App 3"]
        ZTNA_USER -.->|"Invisible"| ZTNA_SRV["Serveurs"]
    end

Les 5 piliers du Zero Trust

  1. Verifier explicitement — toujours authentifier et autoriser en fonction de tous les points de donnees disponibles (identite, localisation, appareil, service, classification des donnees)
  2. Moindre privilege — limiter l'acces avec des politiques adaptatives basees sur le risque et la protection des donnees
  3. Presumer la compromission — minimiser le rayon d'explosion, segmenter l'acces, verifier le chiffrement de bout en bout
  4. Micro-segmentation — isoler les ressources pour que la compromission d'un segment ne donne pas acces aux autres
  5. Verification continue — ne pas se fier a une authentification ponctuelle, reverifier en permanence

Architecture FortiGate ZTNA

L'architecture repose sur trois composants :

graph TB
    subgraph CLIENT["Poste utilisateur"]
        FC["FortiClient<br/>Agent ZTNA"]
    end

    subgraph FGT["FortiGate"]
        PROXY["Access Proxy<br/>HTTPS reverse proxy"]
        POLICY["ZTNA Policy<br/>Regles d'acces"]
        TAGS["ZTNA Tags<br/>Classification posture"]
    end

    subgraph IDP["Fournisseur d'identite"]
        ENTRA["Microsoft Entra ID<br/>SAML/OIDC + MFA"]
    end

    subgraph APPS["Applications internes"]
        APP1["ERP SAP"]
        APP2["GitLab"]
        APP3["Kibana SOC"]
    end

    FC -->|"HTTPS"| PROXY
    PROXY --> POLICY
    POLICY -->|"Verifie identite"| ENTRA
    POLICY -->|"Verifie posture"| TAGS
    POLICY -->|"Autorise"| APPS
Composant Role
FortiClient Agent sur le poste — etablit le tunnel HTTPS, remonte la posture (AV, OS, cert, chiffrement disque)
FortiGate Access Proxy Reverse proxy HTTPS — termine les tunnels, applique les politiques d'acces
Microsoft Entra ID Fournisseur d'identite — SSO via SAML/OIDC, MFA obligatoire
ZTNA Tags Labels dynamiques attribues aux endpoints selon leur posture (ex: compliant, managed, risky)

Mecanismes de securite

1. Verification d'identite

L'authentification forte repose sur SAML 2.0 ou OpenID Connect avec Entra ID :

  • SSO (Single Sign-On) — l'utilisateur ne s'authentifie qu'une fois pour acceder a toutes ses applications
  • MFA obligatoire — second facteur requis pour chaque session :
    • TOTP (application Microsoft Authenticator)
    • Push notification
    • Cle physique FIDO2 (YubiKey)
  • Conditional Access — politiques adaptatives (geolocalisation, heure, niveau de risque du compte)

2. Controle de posture endpoint

Avant d'autoriser l'acces, FortiGate verifie l'etat de l'endpoint via FortiClient :

Verification Critere Consequence si KO
Antivirus A jour, actif Acces refuse ou limite
Systeme d'exploitation Patche, version supportee Acces refuse
Chiffrement disque BitLocker/FileVault actif Acces refuse aux donnees sensibles
Certificat machine Delivre par la PKI interne Acces refuse (appareil non gere)
FortiClient version Version minimale requise Mise a jour forcee

3. Acces applicatif granulaire

Chaque application interne est publiee individuellement. L'utilisateur ne voit que les applications auxquelles il a droit. Les autres sont invisibles (pas juste bloquees).

4. Tunnel chiffre applicatif

Le tunnel est un HTTPS standard (port 443) entre FortiClient et FortiGate :

  • Pas de protocole proprietaire → traverse tous les firewalls et proxies
  • Chiffrement TLS 1.3
  • Inspection possible par le FortiGate (contrairement a un VPN IPsec classique)

5. Politiques dynamiques

Les droits d'acces s'adaptent au contexte en temps reel :

Contexte Politique appliquee
Depuis le bureau, appareil gere Acces complet aux applications
Depuis la maison, appareil gere Acces aux applications non sensibles
Depuis un pays a risque MFA renforce + acces limite
Appareil non conforme Acces refuse, notification a l'admin
Hors heures ouvrables Acces restreint aux services critiques

Flux d'authentification complet

sequenceDiagram
    participant User as Utilisateur + FortiClient
    participant FGT as FortiGate Access Proxy
    participant Entra as Entra ID (IdP)
    participant App as Application interne

    User->>FGT: 1. Demande d'acces a l'application (HTTPS 443)
    FGT->>FGT: 2. Verifie si une session ZTNA active existe
    FGT->>Entra: 3. Redirection SAML (si pas de session)
    Entra->>User: 4. Page de login + challenge MFA
    User->>Entra: 5. Credentials + validation MFA (TOTP/push/FIDO2)
    Entra->>FGT: 6. Assertion SAML (identite validee + groupes)
    FGT->>User: 7. Verification posture FortiClient
    Note over FGT: AV a jour ? OS patche ?<br/>Chiffrement disque ? Certificat valide ?
    FGT->>FGT: 8. Evaluation ZTNA policy (identite + posture + contexte)
    FGT->>App: 9. Reverse proxy vers l'application
    App->>User: 10. Reponse applicative (tunnel HTTPS)
    Note over User,App: Session active — posture reverifiee periodiquement

Avantages pour INDIO Group

Benefice Detail
Reduction surface d'attaque -80% — seules les apps autorisees sont accessibles
Fin du VPN Plus de tunnel reseau ouvert, moins de risque de mouvement lateral
Experience utilisateur SSO transparent, pas de client VPN lourd a configurer
Visibilite Chaque acces est logue avec l'identite, l'application et la posture
Conformite MFA + chiffrement + posture = conformite ANSSI, ISO 27001, RGPD