Les principes d’une architecture d’applications sécurisée pour améliorer la résilience du cloud

L’ARCHITECTURE CLOUD SÉCURISÉE : LA BASE DES APPLICATIONS RÉSILIENTES

Les raisons pour une entreprise de transférer ses applications vers le cloud sont nombreuses : des économies de coûts, des déploiements plus rapides, une meilleure résilience et une plus grande élasticité. Sachant cela, les entreprises du monde entier adoptent les déploiements multicloud comme la meilleure solution pour gérer leurs très nombreuses applications, dont toute la gamme des applications classiques (MS Exchange, SAP, etc.) et des applications internes personnalisées.

Il faut prendre en compte plusieurs considérations importantes lors du déploiement des applications dans le cloud, en particulier la sécurité et la flexibilité. Ces considérations sont toutes étroitement liées. La sécurisation des applications web, surtout si elles sont distribuées sur plusieurs sites dans le cloud, peut et doit être intégré à votre architecture, dès le départ. Ceci permet de maintenir une politique de sécurité cohérente pour toutes vos applications et d’aider vos utilisateurs (employés, partenaires, clients) à vivre une expérience sans frictions. Cette cohérence crée aussi un degré de flexibilité et de résilience opérationnelles qui permet de réagir rapidement à des défis inattendus ou de s’adapter pour tirer parti de nouvelles opportunités.

Principes de l’architecture dans le cloud

Comme le souligne John Wagnon dans une récente Leçon Lightboard, les utilisateurs du cloud ont besoin de savoir quelles sont réellement leurs responsabilités. « En général, le fournisseur de cloud est chargé de la sécurité du cloud, et l’utilisateur est responsable de la sécurité dans le cloud ». Malheureusement, cette conceptualisation laisse de nombreuses questions de sécurité sans réponse. Pour assurer la sécurité de vos applications, vous devez combler ces lacunes.

Lorsque vous élaborez un programme pour la sécurité et la résilience des applications dans votre entreprise, trois capacités doivent être prioritaires : la cohérence, le contrôle et l’agilité. La méthode que nous recommandons ressemble à celle de la sécurité des aéroports. Au lieu d’exiger que chaque compagnie aérienne effectue ses propres contrôles de sécurité, les voyageurs sont contrôlés à un point de contrôle unifié, puis ils sont autorisés à se rendre à leur porte. De même, une architecture cloud sécurisée peut faire passer tout le trafic par un cloud privé virtuel (CPV) uniforme avant d’autoriser l’accès à une application particulière. Et tout comme l’agent d’entrée peut réattribuer des sièges et vérifier les billets des voyageurs avant l’embarquement, chaque application peut être dotée de fonctions et de capacités de sécurité supplémentaires.

Dans un tel scénario, le CPV de Sécurité peut être responsable de nombreuses capacités critiques (et souvent gourmandes en ressources), notamment l’équilibrage de charge, le WAF (et autres pare-feux), la gestion des accès, le chiffrement des identifiants, l’inspection SSL, la protection contre les DDoS et les robots, la gestion des API, la gestion des performances, entre autres.

Les services du CPV de Sécurité peuvent facilement communiquer entre eux, ce qui offre d’autres avantages. Par exemple, lorsque votre WAF intercepte une attaque, il peut notifier vos services de contrôle d’accès pour qu’ils bloquent aussi l’attaquant.

La possibilité de communiquer entre tous les éléments du CPV de sécurité permet d’inspecter plusieurs fournisseurs efficacement, ce qui élimine les points de friction et de redondance entre les organisations qui déploient des outils d’inspection comme McAfee, FireEye, Palo Alto Networks, etc. Le trafic non chiffré pour l’inspection SSL peut être transmis aux outils d’inspection pour passer un examen plus approfondi. C’est plus efficace que d’exiger de chaque outil qu’il décrypte, inspecte et de recrypte le même trafic.

Cette méthode de création d’une architecture de cloud sécurisée permet aux développeurs d’applications d’atteindre un niveau élevé d’agilité et d’évolutivité pour réduire les points de friction et améliorer la collaboration entre les équipes. Les normes de base sont déployées dans le CPV de sécurité et nécessitent peu de mises à jour. Les développeurs peuvent ajouter plus de sécurité au niveau de l’application selon les besoins, en prenant le CPV de sécurité comme base. De même, l’administrateur réseau peut définir des services de sécurité pour chaque environnement (développement, test, production). Si un développeur lance une application sans capacités de sécurité prédéfinies, il bénéficie de la couverture de base définie au niveau du CPV.

Rassemblez les tous

Faire passer les applications du code au client est devenu plus complexe que jamais. Certaines mesures peuvent simplifier le processus en garantissant la sécurité dans tous les environnements et dans les architectures multicloud. Commencez par établir un bon point d’entrée pour tout le trafic des applications et fournissez des niveaux de base de sécurité et de gestion du trafic par ce point. Vous pouvez ensuite définir des services de sécurité supplémentaires au niveau des applications. Cette méthode en deux étapes assure une sécurité fiable et garantit la cohérence, le contrôle et l’agilité de l’architecture.