↓ Aller au contenu
Antoine L.
  1. Visions/

Sécurité de l'information : périmètre et accès

·15 mins·
Articles Architecture
Sommaire

Introduction
#

La gestion de l’information est l’un des piliers d’une organisation : si certaines informations sont révélées, le coeur de métier peut s’effondrer, les concurrents peuvent s’en emparer, et les coûts voire la survie de l’organisation peuvent en être gravement impactés. Mais sans pour autant rester sur un ton alarmiste, une bonne gestion de l’information permet à chaque partie de l’organisation d’assurer une confidentialité nécessaire et de travailler efficacement. Parmi les étapes du cycle de vie des données comprenant leur classification, leur gouvernance, leur suivi, intéressons-nous à leur sécurité et leur accès.

→ Voyons pourquoi la sécurité de l’information est importante, interrogeons-nous sur le périmètre de contrôle, et comment pallier cette perte de contrôle une fois l’information partagée.

Pourquoi la sécurité
#

Pourquoi parler de sécurité de l’information ? Parce que certaines informations doivent être strictement gardées selon leur contenu : données personnelles, contrats importants,… Cette sécurité peut être divisée en plusieurs couches qui la garantissent, que sont :

  • la classification de l’information,
  • la gestion des accès à l’information,
  • le stockage de l’information,
  • le transit de l’information,
  • le périmètre de contrôle de l’information.
graph TD
C{Sécurité}
C --> D[Classification]
C --> E[Gestion d'accès]
C --> F[Stockage]
C --> G[Transit]
C --> H[Périmètre]

Dont les objectifs sont d’assurer :

  • la confidentialité : seules les personnes concernées peuvent accéder au contenu,
  • l’intégrité : personne ne peut altérer le contenu,
  • la disponibilité : la libre consultation du contenu.

Le point de départ qui conditionne les autres est la classification de l’information. Sans pouvoir identifier quelles informations sont plus critiques que d’autres, on ne peut dissocier les moyens et les coûts à mettre en oeuvre.

Voici à titre d’exemple un modèle de classification, lié à des contrôles différents.

ClasseExempleContrôle
PublicMarketing, PublicitéIntégrité
InterneDocumentation interneIntégrité et accès limité
ConfidentielCode sourceIntégrité, accès limité et chiffrement
RestreintClés de chiffrementIntégrité, accès limité, chiffrement et audit

→ Selon la nature de l’information, son utilisation sera soumise à un traitement différent. Par exemple nous ne stockerons pas de la même manière les extraits d’identité des employés et les offres d’emplois. De plus l’axe financier peut aider cette classification : les données à fort impact financier se garderont plus strictement que des documents qui n’ont presque pas de répercussions sur le business.

Note

Rappel de la différence entre information et donnée. La donnée est la représentation conventionnelle d’une information en vue de son traitement informatique1. L’information est un élément de connaissance susceptible d’être représenté à l’aide de conventions pour être conservé, traité ou communiqué2.

Dans notre périmètre
#

L’environnement a une place importante dans le raisonnement : dans notre infrastructure, nous pouvons mettre en place des garde fous, des contrôles d’accès à nos données. Nous pouvons segmenter les appareils connectés sur le réseau, intégrer les employés à des groupes d’accès. Dans certains cas nous pouvons également avoir une approche dite Zero trust, où chaque équipement et personne doivent s’identifier avant d’accèder à quelconque ressource.

Dans notre périmètre, nous sommes maîtres.

Modèles d’accès
#

Notre périmètre, donc nos règles d’accès aux données. Les suites logicielles utilisées se conforment à certains types d’accès, tels que les accès basés principalement sur le rôle de la personne (RBAC) ou sur les attributs de la personne (ABAC). Ces modalités d’accès font partie de la gestion de l’identité de personnes au sein de l’organisation. Creusons le modèle d’accès RBAC.

RBAC
#

Ce modèle propose un accès aux ressources attribué selon le rôle, qui se réfère à un groupe de personne partageant les mêmes caractéristiques, telles que le département, la localisation, la séniorité, la nature du travail,… Par exemple une personne de département de finance n’a pas accès aux ressources de l’IT. Trois caractéristiques définissent ce modèle :

  1. Assignation du rôle : la personne peut exercer la permission seulement si un rôle lui a été assigné.
  2. Autorisation du rôle : l’assignation du rôle doit être autorisée.
  3. Autorisation de la permission : la personne peut exercer la permission que si le rôle le peut.

Certains niveaux conceptuels et d’implémentation sont à différencier au sein du modèle RBAC.

NiveauNomFonctionnalitéExemple
Niveau 1RBAC basiqueStructure basique: Utilisateur → Rôle → PermissionLa plupart des applications
Niveau 2RBAC hiérarchiqueHéritage des rôles. Rôles supérieurs incluent les inférieursLe manager possède les droits de son équipe
Niveau 3RBAC contraintsSéparation des fonctions. Rôles exclusifs“Réalisateur” et “validateur” ne peuvent pas être la même personne
Niveau 4RBAC symétriquesNiveau 2 + niveau 3Très spécifique pour définir

Outils
#

La gestion de ces rôles passe par des outils qui sont dédiés. Citons par exemple Keycloak3, Azure Entra ID 4.

→ Identifier le périmètre est essentiel, garant du contrôle de nos données. Mais à quel moment perd-on ce contrôle ?

Dans la nature
#

Dès que l’information même partielle quitte notre périmètre, le contrôle de confidentialité, d’intégrité et de disponibilité ne sont plus possibles.

flowchart TD
    A["Périmètre contrôlé\n\nModèle d'accès implémenté\n\nIAM/RBAC\nRestrictions réseau"] -->|"La donnée quitte\nle périmètre"| B["Environnement non contrôlé\n\nPas de modèle d'accès"]

Dès lors, on ne peut savoir ce qu’il va advenir de la donnée. Il existe des méthodes pour assurer l’intégrité, la confidentialité, la disponibilité.

À l’extérieur de notre périmètre, nous perdons tout pouvoir sur nos données.

→ Une principale réponse technique pour cela est le chiffrement : se protéger des regards malveillants pendant le transit, se protéger des accès tiers à nos données stockées hors périmètre,…

À l’extérieur de notre périmètre, le chiffrement nous permet alors d’appliquer des protections pour assurer la confidentialité, l’intégrité et la disponibilité de nos données.

Le transit
#

Pour un échange avec un service tiers, nous chiffrerons le transit des données avec le protocole TLS, dont la version recommandée sera la v1.35. Elle ne permet plus l’échange de cyphers de type RSA statiques qui n’assurent pas PFS ou Perfect forward secrecy : fonctionnalité qui protège contre un déchiffrement des données, et ce même en ayant la clé privée du serveur.

sequenceDiagram
    participant C as Client
    participant S as Serveur

    Note over C,S: Connexion TCP établie

    C->>+S: ClientHello (version TLS 1.3, cyphers, key_share ECDHE client + random)
    Note over S: Le serveur calcule le secret partagé (ECDHE)
    S-->>C: ServerHello (cypher choisi, key_share ECDHE serveur + random)
    Note over C,S: Dès ici, tout le reste est chiffré (clés de handshake dérivées du secret ECDHE)
    S-->>C: {Certificate} (certificat complet)
    S-->>C: {CertificateVerify} (signature du transcript avec la clé privée du certificat)
    S-->>C: {Finished} (HMAC du transcript avec la clé de handshake)

    Note over C: Le client vérifie le certificat, la CertificateVerify et le Finished

    C->>+S: {Finished} (HMAC du transcript avec la clé de handshake)
    Note over C,S: Clés d'application dérivées, dans les deux sens

    Note over C,S: Données applicatives chiffrées (dans les deux sens)

Avec le modèle serveur-client, après l’établissement de la connexion TCP s’ensuit une vérification de certificat (l’identité) et une génération de clés de chiffrement pour la communication.

  • L’établissement de la connexion sécurisée commence par le message ClientHello, qui contient la version TLS supportée, les algorithmes de chiffrement (cyphers) supportés, ainsi qu’une clé publique éphémère générée pour l’occasion (key_share).
  • Le serveur répond avec un ServerHello contenant le cypher choisi et sa propre clé publique éphémère : dès ce point, les deux parties disposent de tout le nécessaire pour calculer un secret partagé, sans attendre d’échange supplémentaire.
  • Grâce à ce secret partagé, tout ce que le serveur envoie ensuite — y compris son certificat — est déjà chiffré, contrairement aux versions antérieures où le certificat circulait en clair.
  • Le client vérifie alors l’authenticité du serveur à partir de ce certificat, ainsi qu’une preuve cryptographique que le serveur possède bien la clé privée correspondante.
  • Comme les deux clés publiques éphémères ne servent qu’à cette seule connexion et sont recalculées à chaque session, aucune clé statique et durable n’intervient dans le chiffrement des échanges : c’est ce qui garantit la confidentialité persistante (PFS), qu’un compromis futur du serveur ne pourra pas compromettre a posteriori.
  • Le calcul de la clé de session est bien réalisé localement de part et d’autre ; seuls le serveur et le client connaissent alors la clé de session et s’assurent un échange chiffré.

En plus, un certificat client pourra ajouter une vérification d’authenticité supplémentaire. Cette manière de faire est appelée mTLS6 pour Mutual TLS.

sequenceDiagram
    participant C as Client
    participant S as Serveur

    Note over C,S: Connexion TCP établie

    C->>+S: ClientHello (version TLS 1.3, cyphers, key_share ECDHE client + random)
    Note over S: Le serveur calcule le secret partagé (ECDHE)
    S-->>C: ServerHello (cypher choisi, key_share ECDHE serveur + random)
    Note over C,S: Dès ici, tout le reste est chiffré (clés de handshake dérivées du secret ECDHE)
    S-->>C: {CertificateRequest} (le serveur exige un certificat client)
    S-->>C: {Certificate} (certificat complet du serveur)
    S-->>C: {CertificateVerify} (signature du transcript avec la clé privée du serveur)
    S-->>C: {Finished} (HMAC du transcript avec la clé de handshake)

    Note over C: Le client vérifie le certificat serveur, la CertificateVerify et le Finished

    C->>+S: {Certificate} (certificat complet du client)
    C->>+S: {CertificateVerify} (signature du transcript avec la clé privée du client)
    Note over S: Le serveur vérifie le certificat client et la CertificateVerify

    C->>+S: {Finished} (HMAC du transcript avec la clé de handshake)
    Note over C,S: Clés d'application dérivées, dans les deux sens

    Note over C,S: Données applicatives chiffrées (dans les deux sens)

Cette manière de faire est identique à la première, en ajoutant en plus des échanges dédiées pour l’échange du certificat client.

→ Ici, on se protège de potentiels interceptions de l’information, et des déchiffrements présents et futurs.

Le stockage sur disque
#

Le disque en lui-même peut être chiffré par une clé. Cela signifie que lors de l’écriture sur le disque en question, les données physiques ne sont pas exploitables sans la clé de chiffrement. Selon le modèle, la gestion de cette clé apporte plus ou moins de contrôle et de sécurité.

Clé gérée par le service
#

Le fournisseur du service apporte la clé de chiffrement et la gère. Pas de contrôle de la nature de la clé.

flowchart TD
    subgraph PMK["Platform-Managed Keys"]
        direction LR
        subgraph PMKF["Périmètre Fournisseur — clé gérée ici"]
            pmk_k(["🔑 Clé gérée\npar fournisseur"]) --> pmk_kms[("KMS")] --> pmk_d[/"Données\nchiffrées"/]
        end
    end
    classDef key fill:#ffe0b2,stroke:#e65100,color:#000
    classDef data fill:#d4edda,stroke:#4cae4c,color:#000
    classDef kms fill:#fff3cd,stroke:#cc9900,color:#000
    classDef client fill:#b3d9ff,stroke:#3366cc,color:#000
    classDef provider fill:#ffb3b3,stroke:#cc4444,color:#000
    classDef gradient fill:#efefef,stroke:#aaa,color:#333

    class pmk_k,cmk_k,hyok_k key
    class pmk_d,cmk_d,byok_d,hyok_d data
    class pmk_kms,cmk_kms,byok_kms,hyok_hsm kms
    class pmk_c,cmk_c,byok_c client
    class hyok_svc provider
    class GRAD gradient

Clé du service gérée par le client (CMK)
#

Le fournisseur du service apporte la clé, dont la gestion est faite par le client. Le fournisseur peut toujours accéder à la clé et donc au contenu.

flowchart TD

subgraph CMK["Customer-Managed Keys (CMK)"]
    direction LR
    subgraph CMKF["Périmètre Fournisseur"]
        cmk_k(["🔑 Clé\ngérée par\nle fournisseur"]) --> cmk_kms[("KMS")]
        cmk_kms --> cmk_d[/"Données\nchiffrées"/]
    end
    cmk_c["Le client\n le gère cycle de vie"]
    cmk_c -->|"politiques"| cmk_kms
end
classDef key fill:#ffe0b2,stroke:#e65100,color:#000
classDef data fill:#d4edda,stroke:#4cae4c,color:#000
classDef kms fill:#fff3cd,stroke:#cc9900,color:#000
classDef client fill:#b3d9ff,stroke:#3366cc,color:#000
classDef provider fill:#ffb3b3,stroke:#cc4444,color:#000
classDef gradient fill:#efefef,stroke:#aaa,color:#333

class pmk_k,cmk_k,hyok_k key
class pmk_d,cmk_d,byok_d,hyok_d data
class pmk_kms,cmk_kms,byok_kms,hyok_hsm kms
class pmk_c,cmk_c,byok_c client
class hyok_svc provider
class GRAD gradient

Clé importée par le client (BYOK)
#

Le client apporte la clé dans l’écosystème du fournisseur du service. Gestion de la clé par le client, le fournisseur du service opère le stockage de la clé.

flowchart TD
    subgraph BYOK["Bring Your Own Key (BYOK)"]
        direction LR
        byok_c["Le client\n gère le cycle de vie\nde la clé 🔑"]
        subgraph BYOKF["Périmètre Fournisseur — clé importée ici"]
            byok_kms[("KMS")] --> byok_d[/"Données\nchiffrées"/]
        end
        byok_c -->|"importe"| byok_kms
    end
    classDef key fill:#ffe0b2,stroke:#e65100,color:#000
    classDef data fill:#d4edda,stroke:#4cae4c,color:#000
    classDef kms fill:#fff3cd,stroke:#cc9900,color:#000
    classDef client fill:#b3d9ff,stroke:#3366cc,color:#000
    classDef provider fill:#ffb3b3,stroke:#cc4444,color:#000
    classDef gradient fill:#efefef,stroke:#aaa,color:#333

    class pmk_k,cmk_k,hyok_k key
    class pmk_d,cmk_d,byok_d,hyok_d data
    class pmk_kms,cmk_kms,byok_kms,hyok_hsm kms
    class pmk_c,cmk_c,byok_c client
    class hyok_svc provider
    class GRAD gradient

Clé dédiée par client (HYOK)
#

Gestion totale de la clé par le client, nécessite une intégration pour l’utiliser dans le service. Contrôle maximal mais complexité opérationnelle.

flowchart TD
    subgraph HYOK["HYOK / Customer-Dedicated Keys"]
        direction LR
        subgraph HYOKC["Périmètre Client — la clé ne reste dans ce périmètre"]
            hyok_k(["🔑 Clé gérée\npar le client"]) --> hyok_hsm[("KMS\nclient")]
        end
        subgraph HYOKF["Périmètre Fournisseur"]
            hyok_svc["Service\nFournisseur"] -->|"③ Accès aux données chiffrées"| hyok_d[/"Données\nchiffrées"/]
        end
        hyok_svc -->|"① Demande de\ndéchiffrement"| hyok_hsm
        hyok_hsm -->|"② Réponse chiffrée\n(en mémoire uniquement)"| hyok_svc
    end
    classDef key fill:#ffe0b2,stroke:#e65100,color:#000
    classDef data fill:#d4edda,stroke:#4cae4c,color:#000
    classDef kms fill:#fff3cd,stroke:#cc9900,color:#000
    classDef client fill:#b3d9ff,stroke:#3366cc,color:#000
    classDef provider fill:#ffb3b3,stroke:#cc4444,color:#000
    classDef gradient fill:#efefef,stroke:#aaa,color:#333

    class pmk_k,cmk_k,hyok_k key
    class pmk_d,cmk_d,byok_d,hyok_d data
    class pmk_kms,cmk_kms,byok_kms,hyok_hsm kms
    class pmk_c,cmk_c,byok_c client
    class hyok_svc provider
    class GRAD gradient

→ Chiffrer le disque physique est une bonne pratique. Mais lorsque les données doivent être transférées vers un autre support, comment se prémunir d’une lecture en clair ?

Le stockage dans le conteneur
#

Prenons exemple ici un stockage en base de données. Le chiffrement à ce niveau permet une assurance du chiffrement de la donnée elle-même via son conteneur, et ce même si elle est transférée vers un autre support. Les politiques de sauvegarde et restauration de disques n’ont donc pas de responsabilité supplémentaire vis-à-vis de ce chiffrement. Chaque base de données peut avoir une clé dédiée : la fuite d’une clé n’affectera qu’un seul client.

flowchart TB

    subgraph KMS["KMS — Gestion des Clés"]
        direction LR
        kek["KEK\nClé Maître"]
        kek -->|"protège"| k1["🔑 Clé Tenant A\n`key-tenant-a`"]
        kek -->|"protège"| k2["🔑 Clé Tenant B\n`key-tenant-b`"]
    end

    subgraph DB["🗄️ Base de Données (moteur partagé)"]
        direction TB

        subgraph TA["Tenant A"]
            ta_data["📧 email → 🔒 `3f9a...`\n📋 contrat → 🔒 `a1b2...`"]
        end

        subgraph TB2["Tenant B"]
            tb_data["📧 email → 🔒 `9c3d...`\n📋 contrat → 🔒 `f4e5...`"]
        end
    end

    appA["🖥️ Application\nTenant A"] -->|"requête"| TA
    appB["🖥️ Application\nTenant B"] -->|"requête"| TB2

    k1 -->|"déchiffre\nuniquement"| TA
    k2 -->|"déchiffre\nuniquement"| TB2

    classDef key fill:#fff3cd,stroke:#cc9900,color:#000
    classDef app fill:#b3d9ff,stroke:#3366cc,color:#000
    classDef data fill:#ffb3b3,stroke:#cc4444,color:#000
    classDef kek fill:#d4edda,stroke:#4cae4c,color:#000

    class k1,k2 key
    class kek kek
    class appA,appB app
    class ta_data,tb_data data

→ Un modèle à chiffrement multiple (disque et conteneur) accentue les difficultés de déchiffrement et la protection. Généralement, ces manières de procéder sont disponibles dans les services cloud classiques.

Chiffrement dédié
#

En plus de chiffrer le contenu lors de son transit et pour son stockage, il arrive parfois de vouloir s’assurer que seul le destinataire puisse y accéder. Dans ce cas, il est possible de chiffrer le contenu de manière asymétrique, en nécessitant un partage de clé du destinataire. De ce fait, nous sommes en mesure d’attester que seul ce destinataire particulier, qui détient sa propre clé, peut déchiffrer le contenu.

sequenceDiagram
    participant A as Alice (Émetteur)
    participant B as Bob (Destinataire)

    Note over B: 🔑 Clé privée Bob (secrète, jamais partagée)
    Note over B: 🔓 Clé publique Bob (partageable)

    B-->>A: partage sa clé publique 🔓

    Note over A: 📄 Fichier en clair

    A->>A: chiffre le fichier
avec la clé publique de Bob 🔓
    Note over A: 📄 Fichier → 🔒 Fichier chiffré

    A->>A: signe le fichier chiffré
avec sa clé privée 🔑
    Note over A: 🔒 Fichier chiffré + ✍️ Signature Alice

    A->>B: envoie 🔒 Fichier chiffré + ✍️ Signature

    Note over B: reçoit 🔒 Fichier chiffré + ✍️ Signature

    B->>B: vérifie la signature
avec la clé publique d'Alice 🔓
    Note over B: ✅ Authenticité confirmée — c'est bien Alice

    B->>B: déchiffre avec
sa clé privée 🔑
    Note over B: 📄 Fichier en clair

    Note over A,B: ✅ Confidentialité (seul Bob peut déchiffrer)
✅ Authenticité (signature d'Alice vérifiée)

Ayant au préalable reçu la clé publique du destinataire, on peut chiffrer l’information qui va lui parvenir. De ce fait, on est sûrs que seul le titulaire de la clé privée correspondante pourra déchiffrer l’information.

→ C’est une technique communément utilisée pour l’échange par email.

La tenancy
#

Cette information d’architecture est cruciale pour comprendre comment sont stockées nos données dans l’exploitation d’un service. Une architecture dite Single tenant ne permettra pas le service à faire cohabiter les données de différents clients.

flowchart TD
    A[Client A] -->|Accède| B(Service web)
    C[Client B] -->|Accède| E(Service web)
    B --> D[Base de données]
    E --> G[Base de données]

Un déploiement des ressources est nécessaire pour chaque client, dont les données sont isolées par l’infrastructure elle-même.

A contrario de l’architecture Multi-tenant, où les ressources sont partagées : conteneur (base de données), disque,…

flowchart TD
    A[Client A] -->|Accède| B(Service web)
    C[Client B] -->|Accède| B
    B --> D[Base de données]

Dans ce cas, les éléments matériels sont partagés et il est important de comprendre quels moyens (notamment logiciels) sont mis en oeuvre pour éviter une exfiltration fortuite ou préméditée. Isolation au niveau du système d’exploitation (namespaces), au niveau conteneur (une clé de chiffrement par client), au niveau applicatif (identifiant par client) ?

→ N’apportant pas de moyen technique pour protéger nos données, le concept de tenancy reste quand même inévitable pour comprendre les risques d’accès non souhaités.

Conclusion
#

Maîtriser son capital d’information passe par étudier les outils numériques qui structurent son environnement, son cycle de vie, et ses modalités d’accès.

Dans notre environnement contrôlé, nous sommes garants des accès aux informations sensibles et avons le pouvoir de mettre en place des modalités d’accès qui correspondent à notre manière de fonctionner.

Cependant, une fois que l’information quitte son environnement initial, on se tourne vers la protection unitaire de chaque donnée via un chiffrement adapté en fonction du cas d’usage.

En résumé, le diagramme suivant montre un aperçu des points d’attention selon le cas.

flowchart TD
    B[Donnée dans le périmètre]
    C[Donnée à l'extérieur du périmètre]
    B --> D(Mettre en place le modèle d'accès\n\n RBAC\nSegmentation réseau)
    C --> |Pas de contrôle d'accès| E(S'assurer du stockage chiffré)
    B --> |Partage| F(Chiffrer le transit)
    F --> C
    E --> G[Modèle de tenancy]
    G --> |Multi-tenant|I(Évaluer les isolations entre tenants)

Glossaire
#

  • ACL : Access Control List — liste définissant les permissions d’accès à une ressource.
  • AES : Advanced Encryption Standard — algorithme de chiffrement symétrique standard (AES-128, AES-256).
  • BYOK : Bring Your Own Key — le client génère sa clé et l’importe dans le KMS du fournisseur.
  • CMK : Customer-Managed Key — clé générée par le fournisseur mais dont les politiques d’accès sont gérées par le client.
  • DEK : Data Encryption Key — clé utilisée pour chiffrer directement les données.
  • FDE : Full-Disk Encryption — chiffrement de l’intégralité d’un volume disque au niveau OS.
  • HMAC : Hash-based Message Authentication Code — empreinte cryptographique garantissant l’intégrité et l’authenticité.
  • HSM : Hardware Security Module — module matériel dédié au stockage et aux opérations cryptographiques.
  • HSTS : HTTP Strict Transport Security — directive forçant l’utilisation de HTTPS.
  • HYOK : Hold Your Own Key — le client génère, stocke et opère la clé dans son propre HSM.
  • IAM : Identity and Access Management — gestion des identités et des droits d’accès.
  • KEK : Key Encryption Key — clé maître utilisée pour chiffrer et protéger les DEK.
  • KMS : Key Management Service — service de gestion du cycle de vie des clés cryptographiques.
  • mTLS : Mutual TLS — TLS avec authentification mutuelle client et serveur par certificat.
  • PKI : Public Key Infrastructure — infrastructure de gestion des certificats et des autorités de certification.
  • RBAC : Role-Based Access Control — contrôle d’accès basé sur les rôles.
  • ABAC : Attribute-Based Access Control — contrôle d’accès basé sur les attributs (plus fin que RBAC).
  • TLS : Transport Layer Security — protocole de chiffrement des communications réseau.
  • Tenancy : La configuration d’une plateforme à héberger de manière séparée ou conjointe des données de multiples clients. On parle de single tenant lorsque qu’il ne peut y avoir de cohabitation, et de multi-tenant sinon.

  1. https://www.larousse.fr/dictionnaires/francais/donn%c3%a9e/26436 ↩︎

  2. https://www.larousse.fr/dictionnaires/francais/information/42993 ↩︎

  3. https://www.keycloak.org/ ↩︎

  4. https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id ↩︎

  5. https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-13.html#name-handshake-protocol ↩︎

  6. https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/ ↩︎