Vvanakor
Retour aux écrits
Data Security2 min de lecture

Le zero trust échoue sur la friction, pas sur l'architecture

Zero TrustData SecurityArchitectureEncryption

Le schéma n'est pas la difficulté

Tout le monde sait le dessiner. L'identité au centre, aucune confiance implicite liée à la position réseau, vérification à chaque requête, politique appliquée au plus près de la ressource.

Je n'ai jamais vu un programme zero trust échouer parce que l'architecture était fausse. J'en ai vu plusieurs échouer parce que la vérification est devenue assez coûteuse pour qu'on la contourne.

La friction est le vrai modèle de menace

Rendez l'autorisation lente et les équipes mettront les identifiants en cache. Rendez-la bureaucratique et elles demanderont des permissions bien plus larges que nécessaire, parce que demander deux fois coûte plus cher que demander trop d'un coup. Rendez-la peu fiable et quelqu'un ajoutera un contournement d'urgence qui deviendra discrètement le chemin normal.

Vous avez alors un schéma zero trust et un réseau fantôme. Le schéma reste exact. Il ne décrit simplement plus la façon dont le travail se fait.

La métrique qui compte n'est donc pas la couverture. C'est le temps qu'une requête légitime met à être autorisée, mesuré au P95, et la question de savoir si ce chiffre baisse.

Au niveau des données

La pensée périmétrique meurt lentement, et elle meurt en dernier autour des données. Le réflexe reste de protéger le magasin plutôt que l'enregistrement.

Classifiez d'abord, car on n'écrit pas de politique sur des données que l'on n'a pas décrites. Puis poussez l'application vers le plan de données — le chemin de requête, pas le réseau devant. Une base accessible depuis un seul sous-réseau de confiance reste une base qui rend tout à qui l'atteint.

Le chiffrement en transit et au repos est un minimum et ne prouve presque rien sur l'autorisation. Il protège contre une autre menace que celle dont il est question ici.

Les identités non humaines

L'essentiel des accès à vos données n'est pas humain. Comptes de service, identités de charge de travail, runners de pipeline, principals d'API. Ils sont généralement plus nombreux que les humains, ils ont rarement un propriétaire, et leurs identifiants tournent selon un calendrier qui se compte en années.

Si votre programme zero trust ne couvre que les personnes, il couvre la minorité de vos accès.

L'ordre que je suivrais

Inventaire des identités, y compris non humaines. Classification des données. Politique au plan de données. Puis mesurer le coût de conformité d'une requête légitime, et le faire baisser sans relâche.

La dernière étape est celle qu'on supprime, et c'est celle qui détermine si les autres survivent.

Retour aux écrits