Améliorer la sécurité opérationnelle dans le cloud
Si vous souhaitez réduire les coûts d’exploitation dans le cloud, examinez vos pratiques de sécurité du côté de la gestion des opérations.
De nos jours, la majeure partie de l’attention portée à la sécurité se porte sur les protocoles application et les vulnérabilités de la pile application elle-même. Cela n’est pas surprenant étant donné que la majorité des violations se produisent parce que les vulnérabilités des plateformes et des cadres courants offrent un riche ensemble de cibles faciles.
Mais n’ignorons pas le côté de plus en plus accessible de la gestion de l’entreprise. À mesure que nous avons déplacé des applications vers le cloud public, nous avons souvent perdu de vue l’importance d’isoler le trafic de gestion d’un accès facile. Sur place, c'était facile. Le réseau de gestion était inaccessible au public. Nous les avons gardés enfermés sur un réseau non routable qui n'était accessible qu'à l'intérieur. Comme nous avons migré les applications et leur infrastructure de services application vers le cloud, nous avons besoin d'une gestion accessible au public, car les opérateurs sont désormais distants.
Bien que nous ayons effectué la transition de Telnet (à l'exception de tous les appareils IoT qui doivent rattraper leur retard) vers SSH et que nous pratiquions même de bons comportements de génération de mots de passe, nous n'avons pas nécessairement examiné comment mieux exploiter la sécurité native du cloud avec nos propres pratiques.
C'est l'utilisation des services de sécurité des fournisseurs de cloud qui peut avoir un impact considérable sur les coûts opérationnels des activités dans le cloud, en particulier lorsqu'il s'agit de gérer l'infrastructure des services application .
La menace est réelle
Si vous n'avez pas eu l'occasion de lire l'article de F5 Labs sur les noms d'utilisateur et mots de passe les plus attaqués, vous devriez le faire. Vous y apprendrez que SSH est un service très ciblé. Plus que tout autre, il s'avère.
Extrait de l'article :
En termes de volume d'attaque, les attaquants consacrent plus de temps et d'efforts à attaquer SSH qu'à tout autre service en ligne. L'accès par force brute aux connexions administratives des applications de production via SSH se produit 2,7 fois plus que les attaques contre l' application elle-même via HTTP (les attaquants essayant d'exploiter les vulnérabilités applicatives Web).
Et pourquoi pas ? Le contrôle administratif sur l'infrastructure des services application vous donne beaucoup de pouvoir, y compris la possibilité de modifier les politiques qui pourraient autrement empêcher un accès facile aux applications Web. Dans le cas de Kubernetes, souvent ciblé en raison de l'absence d'informations d'identification requises, l'accès est souhaité afin d'exploiter des ressources aux frais de quelqu'un d'autre.
Mais vous êtes un expert en sécurité et vous avez besoin de mots de passe forts pour tous les accès à l'infrastructure. Votre mot de passe SSH est si fort que vous devez vous arrêter et réfléchir à ce qu'il signifie pour le saisir. À chaque fois.
Passons maintenant à la déclaration évidente du siècle : les mots de passe forts n’empêchent pas les attaques. Ils ne font qu’atténuer les attaques réussies. Vous ne pouvez pas empêcher quelqu’un de lancer une attaque. Tu ne peux vraiment pas. Vous ne pouvez que le détecter et l’empêcher de réussir.
Mais en attendant, cette attaque a des coûts opérationnels réels qui lui sont associés. Parce que vous pratiquez une sécurité intelligente et que toutes ces tentatives infructueuses sont enregistrées. Chaque. Célibataire. Un.
Et pour chaque tentative échouée que vous bloquez, vous consommez des ressources. Bande passante. Stockage. Calculer.
Utilisez les services cloud natifs pour améliorer les pratiques de sécurité
Tous les principaux fournisseurs de cloud (et probablement aussi les plus mineurs) fournissent des contrôles de sécurité réseau de base qui peuvent être utilisés pour verrouiller l’accès de gestion à l’infrastructure des services application . Les groupes de sécurité AWS (SG) et les groupes de sécurité réseau Azure (NSG) fonctionnent de la même manière qu'un pare-feu : ils filtrent le trafic entrant (et sortant) d'une instance. Dans le cas d'un accès de gestion, cela peut constituer un outil important dans votre boîte à outils de sécurité. En verrouillant l'accès aux seules adresses IP connues (ou plages spécifiées), vous pouvez réduire considérablement le volume d'attaques qui atteint votre infrastructure. Cela peut permettre de réduire les coûts en évitant une consommation excessive de ressources de calcul, de bande passante et de stockage.
C’est le même principe qui encourage l’utilisation de pare-feu application Web dans le cloud, à la fois comme protection des applications et comme meilleures pratiques opérationnelles. L’objectif est d’arrêter l’attaque avant qu’elle ne puisse consommer des quantités excessives de ressources. Même si cette attaque avait échoué, le fait est que les tentatives sont susceptibles de provoquer des événements de mise à l’échelle automatique qui coûtent de l’argent à l’entreprise ou perturbent la disponibilité pour les utilisateurs légitimes. Aucune de ces deux issues n’est souhaitable.
En règle générale, plus vous êtes proche de la source de l'attaque, plus vous serez en sécurité et moins cela coûtera cher à l'entreprise.
Augmenter. Ne remplacez pas.
La clé de l’utilisation de services cloud natifs dans votre pratique de sécurité est « l’augmentation ». L'utilisation de mots de passe SSH forts est une bonne chose. Il est préférable de le combiner avec un contrôle d’accès renforcé. Mais n’abandonnez jamais, jamais, les pratiques de mots de passe forts au profit des seuls groupes de sécurité. Utilisez les deux ensemble pour garantir la sécurité et limiter le coût des activités dans le cloud.