L’identité est le nouveau périmètre

La leçon précédente a tracé une ligne entre ce qu’un fournisseur cloud sécurise et ce que le client doit sécuriser. Du côté du client, un élément fait plus de travail que tout autre : l’identité — qui est autorisé à se connecter, et ce qu’il peut ensuite faire. Un réseau de bureau traditionnel avait un mur et une porte verrouillée ; un compte cloud a un formulaire de connexion, accessible depuis n’importe où sur Terre, à toute heure. Sécuriser cette connexion, c’est l’essentiel de ce que signifie en pratique la « sécurité dans le cloud ».

Comment les comptes sont réellement pris

La prise de contrôle d’un compte implique rarement qu’un attaquant viole les systèmes d’un fournisseur cloud. Elle suit généralement le schéma de vol d’identifiants du cours sur la modélisation des menaces de cette université : un mot de passe réutilisé provenant d’un service sans rapport ayant subi une fuite, ou une page d’hameçonnage convaincante qui demande simplement les identifiants directement. Une fois qu’un attaquant possède des identifiants valides, la plupart des services cloud n’ont aucun moyen de les distinguer du véritable propriétaire du compte — c’est exactement pourquoi le contrôle unique que la CISA met en avant par-dessus tous les autres est l’authentification multifacteur (MFA).

La MFA, et pourquoi toutes les formes ne se valent pas

La CISA indique clairement que « les utilisateurs qui activent la MFA ont beaucoup moins de risques d’être piratés », parce qu’un mot de passe volé seul cesse d’être suffisant. Mais la CISA classe aussi les formes de MFA disponibles selon leur résistance à l’hameçonnage, et ce classement compte : « la seule authentification largement disponible et résistante à l’hameçonnage est l’authentification FIDO/WebAuthn » — la norme derrière les clés d’accès (passkeys) et les clés de sécurité matérielles, traitée dans le cours de cryptographie. Un code par SMS reste, selon les mots de la CISA, bien meilleur qu’aucun second facteur, mais il peut être intercepté ou relayé par un attaquant suffisamment motivé ; les notifications push basées sur une appli avec correspondance de numéros se situent entre les deux. Pour un compte cloud contenant quoi que ce soit de sensible, activer l’option de MFA la plus forte que ce compte propose est l’action ayant le plus de valeur dans cette leçon.

OAuth : les permissions que vous accordez à d’autres applis

Chaque fois que vous cliquez sur « continuer avec Google » ou que vous connectez un outil de planification à votre agenda, vous utilisez OAuth, décrit par la documentation propre de la norme comme « le protocole standard de l’industrie pour l’autorisation ». Sa propriété utile est que l’appli tierce ne voit jamais votre mot de passe — vous vous connectez directement auprès de votre fournisseur, puis approuvez un ensemble précis et limité de permissions, appelées scopes, pour cette appli. Son risque est exactement cette autorisation : une appli de planification qui n’a besoin que de lire les créneaux libres/occupés de votre agenda peut demander, et se voir couramment accorder, la permission de lire et d’envoyer des e-mails en votre nom. Chaque appli connectée est un accès permanent qui persiste jusqu’à ce que quelqu’un le révoque, c’est pourquoi la dernière leçon de ce cours traite de la révision de cette liste, pas seulement de sa configuration correcte une seule fois.

Les clés qui fuitent : la cousine moins visible d’OAuth

Les outils automatisés et les intégrations s’authentifient souvent avec une clé d’API plutôt qu’avec une connexion humaine — une longue chaîne qui fonctionne comme un mot de passe mais n’est pas tapée par une personne et n’est souvent protégée par aucune MFA. Ces clés finissent par être exposées plus souvent qu’on ne le pense : collées dans un ticket de support, accidentellement intégrées dans un dépôt de code, laissées dans un fichier de configuration partagé plus largement que prévu. Traiter une clé d’API avec la même prudence qu’un mot de passe — ne jamais la partager en clair, la faire tourner si elle a pu être exposée, et limiter ce qu’elle est autorisée à faire — ferme une faille que la MFA, conçue pour les connexions humaines, ne couvre pas.