Chaque semaine, les équipes de sécurité du monde entier découvrent des environnements en nuage dont l'accès est mal configuré, un problème connu sous le nom de mauvaise configuration du nuage ou de Shadow IT. Il ne s'agit généralement pas de l'œuvre de pirates chevronnés, mais de simples erreurs aux conséquences considérables.
Un exemple récent qui a fait la une des journaux est celui d'une grande entreprise de services financiers, Ernst & Young (EY). Une simple erreur de configuration du stockage dans le nuage a laissé un fichier de sauvegarde du serveur SQL de 4 téraoctets exposé à l'internet public. Cet événement prouve que même les organisations disposant de budgets de sécurité de plusieurs millions de dollars sont vulnérables lorsque l'erreur humaine entre en jeu. Il s'agit d'un mal de tête qui touche l'ensemble du secteur et qui nous montre que les erreurs les plus faciles à commettre sont souvent celles qui causent le plus de dégâts.
Le problème se résume à ceci : la complexité interne et l'informatique fantôme peuvent être tout aussi dangereuses qu'un adversaire extérieur. Dans ce blog, nous examinerons comment une erreur "en un clic" se produit et comment mettre en œuvre une gestion continue de la posture de sécurité pour l'éviter.
La vulnérabilité dans l'affaire récente qui a fait grand bruit était une liste de contrôle d'accès (ACL) mal configurée sur un conteneur de stockage en nuage, qui a rendu public un fichier sensible. Cette erreur élémentaire nous montre clairement les problèmes fondamentaux qui se cachent derrière presque toutes les mauvaises configurations de l'informatique en nuage : le déficit de complexité et le déficit de visibilité.
Le "fossé de la complexité" explique comment l'erreur "en un clic" s'est produite. Il s'agit d'une défaillance classique du modèle de responsabilité partagée de l'informatique dématérialisée.
Alors que le fournisseur d'informatique en nuage sécurise l'infrastructure physique, le client conserve l'entière responsabilité, non négociable, de la sécurisation de ses propres données, configurations et gestion des accès au sein de l'informatique en nuage.
Dans la course à l'agilité, le choix rapide d'un ingénieur de rendre un fichier public, même temporairement, peut instantanément contourner tous les contrôles de sécurité stratégiques de l'entreprise. Le rythme incessant du développement et le nombre considérable de paramètres évolueront toujours trop vite pour que l'on puisse tout vérifier manuellement à temps. C'est pourquoi s'appuyer sur le seul contrôle humain pour la sécurité du cloud est un échec.
Une erreur technique est dangereuse, mais elle devient une crise lorsqu'elle se produit dans un angle mort. C'est là que le "déficit de visibilité" devient le principal accélérateur.
L'actif mal configuré s'est avéré "non connecté" aux systèmes de sécurité globaux de l'organisation, ce qui constitue la définition classique de l'infrastructure fantôme. Qu'il s'agisse d'un bien hérité d'une fusion-acquisition, d'un environnement de test oublié ou d'un compte cloud non autorisé, l'invisibilité ne fait qu'aggraver l'erreur. Si un bien n'est pas signalé au centre des opérations de sécurité (SOC) ou ne figure pas dans l'inventaire central, l'erreur humaine peut rester là pour toujours. Cela prouve une règle fondamentale de la sécurité des infrastructures : si vous ne pouvez pas le voir, vous ne pouvez pas le protéger.
Les RSSI doivent prendre des mesures dès aujourd'hui pour éviter qu'une telle situation ne se reproduise. La solution ne consiste pas simplement à rédiger davantage de règles ; il s'agit de mettre en place une application automatisée dans vos opérations et de la soutenir avec des experts en sécurité.
Le passage à la sécurité nécessite une gestion automatisée de la sécurité dans le nuage, unepratique souvent désignée comme l'adoption des principes de protection des applications natives dans le nuage (Cloud-Native Application Protection, CNAP). Cette approche moderne s'appuie sur des capacités clés pour empêcher l'erreur humaine de s'aggraver :
Même lorsque les organisations possèdent la technologie de sécurité nécessaire (comme les suites Microsoft E5), le défi des ressources humaines demeure. Parce qu'un simple oubli dans la configuration de la politique peut toujours conduire à une exposition, une gestion experte et un personnel dédié sont cruciaux.
SecureOps Managed Detection and Response (MDR), détenu en copropriété, apporte une valeur ajoutée considérable dans ce domaine. Un partenaire MDR fournit le personnel et l'expertise nécessaires pour exécuter et ajuster en permanence vos outils de sécurité, ce qui garantit queles erreurs " en un clic " sont détectées et corrigées rapidement, et non pas plusieurs jours plus tard. Nous éliminons la dépendance à l'égard de la surveillance manuelle qui crée le fossé de la complexité.
Si vous êtes à la recherche de fournisseurs de services de MDR, apprenez à sélectionner le bon fournisseur pour répondre à vos besoins grâce à notre Guide de l'acheteur pour les services de MDR cogérés.
La seule véritable défense contre l'erreur humaine est l'automatisation soutenue par une gestion experte.
Pour les organisations disposant d'une licence Microsoft E5, vous possédez déjà les composants de base pour l'automatisation de la sécurité au sein de Microsoft Defender XDR (y compris XDR, VM et les capacités de gestion de la posture). SecureOps se spécialise dans l'exploitation de votre investissement existant, en ajustant et en gérant votre pile E5 afin de fournir une protection immédiate et robuste.
Si votre organisation est un environnement dédié à Microsoft, il existe un argument commercial substantiel pour consolider votre pile de technologies de sécurité sur la suite de solutions E5. Découvrez comment cette consolidation peut réduire la prolifération des fournisseurs et maximiser votre investissement en licences dans notre article de blog dédié.