BLOG

Améliorer la sécurité opérationnelle dans le cloud

Miniature de Lori MacVittie
Lori MacVittie
Publié le 03 juin 2019

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 de l’infrastructure des services d’application vous offre un réel pouvoir, notamment la capacité de modifier des politiques qui pourraient autrement compliquer l’accès aux applications web. Pour Kubernetes, souvent visé parce qu’il ne requiert pas toujours d’identifiants, l’accès permet d’utiliser des ressources aux frais d’autrui.

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.

Chaque fois que vous bloquez une tentative échouée, vous utilisez des ressources. La bande passante. L’espace de stockage. La puissance de calcul.  

Utilisez les services cloud natifs pour améliorer les pratiques de sécurité

Tous les principaux fournisseurs de cloud (et sans doute les secondaires aussi) proposent des contrôles de sécurité réseau basiques pour restreindre l’accès de gestion à l’infrastructure des services applicatifs. Les groupes de sécurité AWS (SG) et les groupes de sécurité réseau Azure (NSG) fonctionnent comme un pare-feu : ils filtrent le trafic entrant et sortant d’une instance. Pour l’accès de gestion, ces outils représentent un atout majeur dans votre arsenal de sécurité. En limitant l’accès à des adresses IP connues ou à des plages spécifiques, vous réduisez considérablement le volume d’attaques ciblant votre infrastructure. Vous limitez ainsi vos coûts en évitant une surconsommation des ressources de calcul, de bande passante et de stockage.

Nous appliquons le même principe en utilisant des pare-feux applicatifs web dans le cloud, à la fois pour protéger vos applications et pour suivre les meilleures pratiques opérationnelles. Nous visons à interrompre l’attaque avant qu’elle n’épuise excessivement vos ressources.  Même si l’attaque échoue, ces tentatives risquent de déclencher des événements d’auto-échelle qui génèrent des coûts ou perturbent la disponibilité pour les utilisateurs légitimes. Aucun de ces scénarios ne vous avantage.

En règle générale, plus vous bloquez l’attaque près de sa source, plus vous sécurisez votre organisation et plus vous réduisez les coûts pour 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.