Si vous souhaitez réduire les coûts liés à l’exploitation dans le cloud, examinez vos pratiques de sécurité en matière de gestion des opérations.
Aujourd’hui, en matière de sécurité, l’attention se porte principalement sur les protocoles applicatifs et les vulnérabilités de la pile applicative elle-même. Cela n’a rien d’étonnant, puisque la majorité des failles de sécurité sont dues aux vulnérabilités des plateformes et frameworks courants, qui constituent autant de cibles faciles.
Mais ne négligeons pas l’administration des systèmes, qui devient de plus en plus accessible. En déplaçant les applications vers le cloud public, nous avons souvent perdu de vue l’importance d’isoler le trafic d’administration afin d’en restreindre l’accès. Sur site, c’était simple : le réseau d’administration était inaccessible au public. Nous le maintenions confiné à un réseau non routable, accessible uniquement en interne. Maintenant que nous avons migré vers le cloud aussi bien les applications que l’infrastructure de leurs services applicatifs, l’administration doit être accessible publiquement, car les opérateurs travaillent désormais à distance.
Bien que nous ayons abandonné Telnet (à l’exception de tous ces appareils IoT qui doivent encore se mettre à niveau) au profit de SSH et que nous adoptions même de bonnes pratiques de génération de mots de passe, nous n’avons pas nécessairement cherché à mieux tirer parti de la sécurité native du cloud en complément de nos propres pratiques.
C’est l’utilisation des services de sécurité des fournisseurs de cloud qui peut avoir une incidence considérable sur les coûts opérationnels liés aux activités dans le cloud, notamment lorsqu’il s’agit de gérer l’infrastructure des services applicatifs.
La menace est bien réelle
Si vous n’avez pas encore eu l’occasion de lire l’article de F5 Labs sur les noms d’utilisateur et mots de passe les plus ciblés par les attaques nous vous le recommandons. Vous y apprendrez que SSH est un service particulièrement ciblé, plus que tout autre, en réalité.
Extrait de l’article :
En termes de volume d’attaques, les attaquants consacrent davantage de temps et d’efforts à attaquer SSH qu’à tout autre service en ligne. Les tentatives d’accès par force brute aux comptes administrateur des applications en production via SSH sont 2,7 fois plus fréquentes que les attaques visant l’application elle-même via HTTP (les attaquants cherchant à exploiter les vulnérabilités des applications web).
Et pourquoi pas ? Le contrôle administratif de l’infrastructure des services applicatifs confère un pouvoir considérable, notamment la possibilité de modifier des politiques qui, autrement, pourraient empêcher d’accéder facilement aux applications web. Dans le cas de Kubernetes, souvent pris pour cible parce qu’il n’exige aucun identifiant, l’objectif est d’exploiter des ressources aux frais de quelqu’un d’autre.
Mais vous vous y connaissez en sécurité et vous exigez des mots de passe robustes pour tout accès à l’infrastructure. Votre mot de passe SSH est si complexe que vous devez vous arrêter un instant pour vous en souvenir avant de le saisir. À chaque fois.
Passons maintenant à l’évidence du siècle : les mots de passe robustes n’empêchent pas les attaques. Ils ne font que limiter les chances qu’elles aboutissent. Vous ne pouvez pas empêcher quelqu’un de lancer une attaque. C’est réellement impossible. Vous pouvez seulement la détecter et l’empêcher de réussir.
Mais entre-temps, cette attaque entraîne de réels coûts opérationnels. Car vous appliquez de bonnes pratiques de sécurité et toutes ces tentatives infructueuses sont consignées. Absolument. Toutes. Sans exception.
Et pour chaque tentative infructueuse que vous bloquez, vous consommez des ressources. Bande passante. Stockage. Puissance de calcul.
Utilisez des services cloud natifs pour renforcer les pratiques de sécurité
Tous les principaux fournisseurs de services cloud (et probablement les plus modestes aussi) proposent des contrôles de sécurité réseau de base permettant de verrouiller l’accès d’administration à l’infrastructure des services applicatifs. Les groupes de sécurité AWS (SG) et les groupes de sécurité réseau Azure (NSG) fonctionnent à peu près comme un pare-feu : ils filtrent le trafic entrant dans une instance (et sortant de celle-ci). Pour l’accès d’administration, ils peuvent constituer un outil important dans votre arsenal de sécurité. En limitant l’accès aux seules adresses IP connues (ou aux plages spécifiées), vous pouvez réduire considérablement le volume d’attaques atteignant votre infrastructure. Cela permet de maîtriser les coûts en évitant une consommation excessive de ressources de calcul, de bande passante et de stockage.
C’est ce même principe qui incite à utiliser des pare-feu d’applications web dans le cloud, à la fois pour protéger les applications et pour respecter les bonnes pratiques opérationnelles. L’objectif est de bloquer l’attaque avant qu’elle ne puisse consommer des quantités excessives de ressources. Même si cette attaque était vouée à l’échec, les tentatives peuvent suffire à déclencher des opérations de mise à l’échelle automatique qui coûtent de l’argent à l’entreprise ou perturbent la disponibilité du service pour les utilisateurs légitimes. Aucun de ces résultats n’est souhaitable.
En règle générale, plus vous pouvez arrêter l’attaque près de sa source, plus vous serez en sécurité et moins les coûts pour l’entreprise seront élevés.
Renforcez. Ne remplacez pas.
Le maître-mot pour intégrer les services cloud natifs à vos pratiques de sécurité est « renforcer ». Utiliser des mots de passe SSH robustes est une bonne chose. Les associer à un contrôle d’accès rigoureux, c’est encore mieux. Mais n’abandonnez jamais, au grand jamais, les bonnes pratiques en matière de mots de passe au profit des seuls groupes de sécurité. Utilisez les deux conjointement pour garantir la sécurité et maîtriser les coûts liés à l’activité dans le cloud.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.