À propos du moindre privilège, du JIT et de l'autorisation forte

Je travaille comme professionnel de la sécurité depuis plus de 20 ans. Il m'est impossible de compter le nombre de fois où j'ai prononcé les mots « moindre privilège ». C'est une sorte de mantra, assis sur le même banc que « défense en profondeur » et « menace interne ».

Mais dire à quelqu'un d'appliquer le moindre privilège puis quitter la pièce revient à ce qu'un médecin vous dise de « manger plus sainement » tout en vous recalant à votre visite médicale d'assurance et en quittant la pièce avant de vous surfacturer.

Le moindre privilège est une réalité. Il compte. Contrairement au changement de mot de passe tous les 90 jours, il peut avoir un effet matériel sur l'amélioration de votre sécurité.

Le moindre privilège est aussi vraiment difficile. Surtout à grande échelle. Et il ne fonctionne pas pour vos utilisateurs les plus importants.

Pourquoi ? Parce que le moindre privilège ne correspond pas aux privilèges minimaux dont vous avez besoin à cet instant, mais aux privilèges minimaux dont vous pourriez avoir besoin pour faire votre travail… un jour. Et lorsque quelqu'un doit faire quelque chose qui sort du périmètre défini au moment où ces privilèges ont été cartographiés, cela déclenche un lent processus de changement qui doit traverser différentes équipes et différents responsables.

Ou parfois, il vous faut simplement convaincre Bob de vous donner l'accès. Et Bob est du genre ronchon et sur la défensive, car il ne fait confiance à personne et ne veut pas être blâmé quand vous ferez une erreur.

Même avec le moindre privilège, si un attaquant obtient ces identifiants (la principale source de violations cloud natives), il pourra probablement quand même faire des dégâts. Car si le moindre privilège n'est pas toujours trop pénible à mettre en œuvre pour l'utilisateur ou l'employé moyen, il est vraiment difficile à imposer aux développeurs et aux administrateurs qui, par nature, ont besoin de davantage de privilèges.

Tout comme nous disposons du MFA pour l'authentification forte, il nous faut quelque chose pour l'autorisation forte.

C'est là qu'intervient le Just in Time (JIT). Plutôt que d'essayer de déterminer à l'avance tous les privilèges dont une personne a besoin, celle-ci peut demander à tout moment des permissions limitées dans le temps. Je considère désormais que le JIT devrait être la norme pour les accès administratifs et sensibles.

Je recommande de voir le moindre privilège comme un excellent concept pour l'accès des utilisateurs généraux, mais le JIT est préférable pour tout niveau d'accès admin/dev/sensible dans le cloud.

Just in Time

Le JIT est une déclinaison du PIM/PAM. Le Privileged Access Management et le Privileged Identity Management sont des systèmes conçus pour élever les privilèges d'un utilisateur. Celui-ci opère à un niveau inférieur jusqu'à ce qu'une élévation soit nécessaire, et ces systèmes recourent à plusieurs techniques pour fournir un accès étendu, généralement pour une session limitée dans le temps. Ce n'est pas aujourd'hui que nous entrerons dans les nuances, mais l'avantage est qu'ils permettent de la souplesse tout en maintenant la sécurité. Une personne doit demander des privilèges supplémentaires lorsqu'elle en a besoin ; ainsi, même si ses identifiants sont compromis, l'attaquant reste limité.

Le « JIT » (Just in Time) est une technique de PAM/PIM (ou, en réalité, de n'importe quel accès). Un utilisateur dispose d'identifiants de base qui peuvent ne donner accès à rien du tout, puis ses privilèges sont élevés sur demande. Nous utilisons nous-mêmes le JIT (et il est disponible dans Cloud Defense), et Netflix a publié un outil open source appelé ConsoleMe basé sur son outil interne. Azure propose un service intégré (mais moyennant un coût supplémentaire) nommé Entra ID Privileged Identity Management. (Entra ID est ce que nous appelions auparavant Azure AD, avant que quelqu'un ne juge judicieux de semer la confusion chez des millions de clients à des fins de branding.) Il existe d'autres options, ce ne sont que des exemples.

Pour renforcer la sécurité, le JIT doit utiliser un flux d'approbation hors bande et fournir un accès limité dans le temps. Ce sont là les fondamentaux. La demande et l'approbation doivent emprunter un chemin différent de l'authentification normale, à la manière d'une forme de MFA. La différence est que le MFA est un facteur hors bande d'authentification (prouver que vous êtes bien qui vous prétendez être) tandis que le JIT est une forme d'autorisation (vous demandez et recevez la permission de faire quelque chose).

Gérer les frictions

Le moindre privilège comme le JIT introduisent des frictions. Il faut dire que tout ce que nous faisons en sécurité introduit une forme de friction, Bob en particulier. Avec le moindre privilège, la friction principale tient à la charge de définition et de déploiement des privilèges, et à ce qui casse lorsque quelqu'un ne dispose pas des privilèges dont il a besoin. Avec le JIT, la friction réside dans le processus de soumission et d'obtention d'une approbation.

Après avoir longtemps utilisé et étudié à la fois le moindre privilège et le JIT, j'ai appris des techniques pour réduire la friction. Dans certains cas, vous obtenez des processus plus rapides et meilleurs que ceux que nous avons historiquement mis en place

• Le flux de demande et d'approbation doit être en temps réel. Cela signifie des approbations via ChatOps, SMS, ou la puce 5G implantée avec votre vaccin COVID.
• Pour les accès à faibles privilèges, comme l'accès en lecture à certains journaux, vous pouvez et devez prendre en charge une auto-approbation. En quoi cela aide-t-il ? Parce que le processus hors bande est toujours utilisé, ce qui réduit la capacité d'un attaquant à exploiter des identifiants perdus, volés ou exposés.
• Vous pouvez également prendre en charge des approbations automatiques, où il n'est même pas nécessaire de cliquer pour s'auto-approuver. En quoi cela aide-t-il ? Vous pouvez approuver automatiquement tout en utilisant votre canal hors bande pour signaler que des privilèges ont été élevés. Vous avez probablement déjà vu cela en ajoutant un appareil Netflix ou Hulu à votre compte. La seule prise de conscience peut être incroyablement efficace.
• Si cela s'adresse aux développeurs, vous devez prendre en charge la ligne de commande et les autres outils qu'ils utilisent. Allez vers eux. Rendez l'usage extrêmement simple. Si vous les obligez à se connecter à un outil de sécurité, le projet échouera.
• Si les approbateurs ne sont pas réactifs, c'est-à-dire instantanés, vous échouerez. Ne faites pas de Bob le seul approbateur.

Apportez cette capacité à vos développeurs et administrateurs dans les outils qu'ils utilisent déjà. Rendez-la rapide et sans friction. Idéalement, faites en sorte qu'elle soit plus simple et plus rapide que d'ouvrir un gestionnaire de mots de passe ou de naviguer dans un portail SSO rempli de 374 comptes cloud parmi lesquels choisir. Offrez des cookies à Bob. Aux pépites de chocolat. (Ah, attendez, c'est moi.)

Vous pouvez aussi recourir à l'automatisation pour réduire la friction liée à l'accès au moindre privilège. Le Duckbill Group a mis en œuvre sa propre version du moindre privilège automatisé en utilisant d'autres technologies, avec l'aide de Chris Farris. Des outils comme AWS Access Advisor sont là pour vous aider à surveiller les permissions utilisées et à les restreindre. L'automatisation est là pour vous aider à mettre en œuvre le moindre privilège à grande échelle, et peut aussi venir compléter le JIT.

Quand utiliser l'un ou l'autre

Le moindre privilège n'est en aucun cas un concept mort. Il reste la référence absolue pour les utilisateurs et employés du quotidien qui ont besoin d'un niveau d'accès assez constant. Le JIT convient mieux aux accès à privilèges élevés, en particulier aux environnements de production, et surtout dans le cloud, où les expositions d'identifiants constituent LA première source de violations. Voici où nous l'utilisons nous-mêmes :

• Accès en lecture des développeurs à la production.
• Accès en modification des développeurs à la production (hors CI/CD). Bien plus restreint, avec davantage d'approbateurs requis.
• Accès administrateur aux comptes de production.
• Accès pour la réponse à incident.
• Certains accès à des comptes de développement, car cela peut être plus rapide que de revenir au portail SSO, en particulier lorsque l'on travaille en ligne de commande.

Je ne considère plus le moindre privilège seul comme un concept valable pour un niveau significatif d'accès à privilèges dans le cloud (IaaS/PaaS), même lorsque nous utilisons un MFA fort. Il est trop difficile de délimiter correctement les permissions à grande échelle, dans la durée. Le JIT est une bien meilleure option dans ces cas d'usage. Le moindre privilège reste tout à fait viable lorsque des permissions constantes dans le temps sont nécessaires, en particulier associées à une bonne journalisation des accès et au MFA. Le JIT est le compagnon du MFA. C'est l'autorisation forte à associer à votre authentification forte. À mesure que nous transférons des opérations toujours plus critiques vers des plans de gestion exposés à Internet, le JIT s'impose.