Le périmètre ne suffit plus à protéger l’accès
Le rapport Cloud Threat Horizons H1 2026 de Google Cloud décrit les menaces observées au second semestre 2025. Son enseignement le plus utile pour une petite entreprise est simple : l’accès ne passe plus seulement par un serveur ou un réseau à défendre. Il passe par une identité légitime, humaine ou non humaine, déjà autorisée à faire quelque chose.
Dans les engagements Mandiant analysés par Google, les problèmes d’identité ont servi de point d’accès initial dans 83 % des intrusions visant des environnements cloud et SaaS. Les données ont été ciblées dans 73 % des incidents liés au cloud. Ces chiffres ne décrivent pas toutes les entreprises, mais ils donnent une direction claire : connaître les identités qui peuvent lire, modifier ou exporter les données devient une priorité opérationnelle.
Une identité n’est pas forcément une personne
Une identité humaine est un compte de collaborateur, d’administrateur ou de prestataire. Une identité non humaine peut être un compte technique, une clé API, un token OAuth, une clé SSH ou une configuration utilisée par un script.
Pour l’attaquant, la différence importe moins que les permissions obtenues. Un token SaaS volé peut ouvrir une intégration sans déclencher le même signal qu’une connexion inhabituelle. Une clé API oubliée dans un fichier peut permettre une action automatisée. Un compte technique trop puissant peut transformer une petite fuite en accès durable à la production.
Le rapport relève aussi que les identités ont été ciblées par vishing, vol de tokens et abus de relations de confiance entre applications. Une authentification réussie ne prouve donc pas, à elle seule, que l’usage qui suit est légitime.
Les logiciels et les identifiants se renforcent mutuellement
Le rapport observe un déplacement des vecteurs d’accès : l’exploitation de logiciels tiers représentait 44,5 % des accès initiaux étudiés au second semestre 2025, contre 27,2 % pour les identifiants faibles ou absents. Le délai entre la divulgation d’une vulnérabilité et son exploitation massive s’est parfois réduit de plusieurs semaines à quelques jours.
Cela ne rend pas les identifiants secondaires. Un logiciel compromis devient dangereux précisément parce qu’il s’exécute dans un environnement où des secrets sont disponibles. Il peut lire une variable de pipeline, un fichier de configuration local, un token conservé par un outil ou une session déjà ouverte.
La sécurité des dépendances et la gestion des secrets doivent donc être pensées ensemble : moins une machine ou un pipeline contient de secrets permanents, moins une compromission logicielle peut s’étendre.
Ce que peut faire une TPE-PME cette semaine
Il n’est pas nécessaire de déployer une plateforme complexe pour commencer. Une première revue utile consiste à :
- Lister les accès. Notez les comptes humains, comptes techniques, clés API, tokens SaaS et secrets de configuration qui touchent les données ou la production.
- Réduire les privilèges. Retirez les droits devenus inutiles et séparez les comptes d’administration des comptes quotidiens.
- Faire expirer les accès. Préférez des tokens courts et ciblés ; révoquez ceux dont le propriétaire, la portée ou la date d’expiration sont inconnus.
- Surveiller les usages. Cherchez les exports inhabituels, les appels API en volume et les nouvelles autorisations OAuth.
- Vérifier les demandes sensibles. Un changement de MFA, une réinitialisation ou une nouvelle intégration doit être confirmé par un second canal.
L’objectif est de pouvoir répondre à trois questions sans fouiller dans des dizaines de messages : qui peut accéder à quoi, avec quel secret, et comment sait-on que cet accès est encore nécessaire ?
Quel outil pour quel secret ?
Un coffre local-first comme Soclyde répond d’abord aux secrets humains : mots de passe SaaS, accès partagés, codes de récupération et informations d’administration. Il limite les copies dans les tickets, tableurs et conversations, tout en gardant les données du coffre sous le contrôle de l’équipe.
Les secrets machine demandent d’autres garanties : portée réduite, expiration, rotation et journalisation. Les secrets utilisés par une application ou un pipeline doivent être injectés par le secret manager et les mécanismes d’identité de la plateforme cloud. Soclyde ne remplace pas ces contrôles ; il évite que les secrets humains et les secrets machine finissent mélangés au même endroit.
Le bon modèle n’est donc pas « tout local » ou « tout cloud ». C’est une séparation explicite des usages, avec le moins de privilèges et de copies possible pour chaque catégorie.
Pour approfondir cette séparation, consultez le guide Soclyde sur les gestionnaires de mots de passe local-first.
