De nos jours, les applications Cloud natives (NCA) représentent une formidable arme stratégique pour les entreprises. Si l’ingénierie logicielle classique est toujours d’actualité, de plus en plus d’entreprises songent à une migration vers le Cloud afin de profiter des avantages offerts par les NCA et rester compétitives.

Nous allons justement voir quels sont les avantages offerts par les applications Cloud natives et voir en détail leurs composants qui, par leur nature, sont à l’origine même de ces avantages. Pour finir, nous allons aborder les nouveaux défis de sécurité soulevés par ces applications.

Quels sont les avantages d’une application Cloud native ?

Applications plus fiables

Traditionnellement hébergées par les servers internes ou des datacenters privés, les applications, une fois portées sur le cloud, peuvent bénéficier d’une haute disponibilité grâce à la redondance (notamment géographique).

Coûts réduits

Alors qu’une application on-premise génère un coût même s’il n’y a pas d’utilisation, son équivalent cloud peut être mis en service seulement à la demande. De fait, les modules d’une NCA peuvent être créés, redimensionnés et détruits en fonction des besoins de l’entreprise.

Système plus facile à gérer

Comme nous allons le voir un peu plus loin, le déploiement et la gestion d’une infrastructure cloud peuvent, et devraient, être entièrement automatisables. De fait, une équipe réduite peut gérer efficacement une infrastructure complexe.

Time-to-Market

Si les 3 points précédents sont importants, pour certaines entreprises, ils ne suffiront peut-être pas à les inciter à sauter le pas. En fait, le vrai facteur concurrentiel est ce quatrième avantage : la possibilité de délivrer une nouvelle fonctionnalité aux clients en un temps réduit. Comme nous allons le voir ensemble, ce dernier point peut être vecteur de bonnes pratiques mais également source de nouvelles failles de sécurité.

Les piliers d’une application Cloud native

Les ressources cloud

Aussi évident que cela puisse être, une application Cloud native utilise des ressources Cloud. Par leur nature, ces ressources peuvent être créées et détruites à la demande, et certaines mises à l’échelle automatiquement. Par exemple, lors d’une période d’intense utilisation, de nouvelles ressources peuvent être ajoutées pour mieux supporter la charge (scale-out) et détruites lorsque la sollicitation redescend (scale-in). D’autres types de ressources cloud peuvent être à capacité variable et monter (scale-up) ou descendre (scale-down) en gamme en fonction de ces mêmes besoins. Évidemment, pour que la mise à l’échelle puisse se faire de façon efficace, il faut que l’application soit correctement conçue.

Les microservices

Concernant la conception, une des architectures les plus adaptées à une infrastructure cloud est l’architecture des microservices. Cette architecture promeut en effet le découpage d’une application monolithique en plusieurs petits modules autonomes communiquant entre eux. Ces modules doivent avoir une gestion indépendante les unes des autres ainsi qu’un cycle de vie qui leur est propre. Prenons l’exemple d’une application e-commerce monolithique découpée en un ensemble de services. Si certains services peuvent utiliser des bases de données relationnelles classiques, d’autres peuvent, comme le service Panier, s’appuyer sur des caches Redis par exemple. Ces services peuvent ainsi, contrairement à une application monolithique, être mis à jour séparément et les ressources utilisées par chacune d’elles, redimensionnées de manière indépendante.

L’architecture microservices n’est pas une obligation pour une migration vers le cloud, mais sa nature en fait une des plus adaptées pour tirer parti du maximum des possibilités offertes par le cloud.

Containers

Les containers permettent d’encapsuler un service et toutes ses dépendances en un seul package. Cela garantit une portabilité et une cohérence du service en question en l’isolant de l’infrastructure sous-jacente. Concrètement, il suffit que la machine hôte cible héberge le runtime permettant d’exécuter ces containers (par exemple Docker Engine). La technologie des containers est tout indiquée pour les microservices parce qu’elle permet une meilleure isolation de ces services tout en ayant une consommation réduite des ressources sur la machine hôte (contrairement aux machines virtuelles par exemple). Un service cloud d’orchestration permet alors de gérer l’ajout ou la suppression de ressources (instances de container, mémoire..) en fonction des besoins d’un service donné.

FaaS

Function-as-a-Service est un service permettant aux développeurs de développer, déployer et exécuter du code sans avoir à se soucier de l’infrastructure qui le supporte. C’est un service propre au cloud très pratique d’un point de vue Architecture car il exonère l’entreprise de se poser la question de l’infrastructure sous-jacente pour se concentrer sur les besoins de montée en charge et de réactivité. Cela amène cependant d’autres défis notamment en termes de sécurité de manière indirecte (voir plus loin).

Automation

Il y a principalement deux types d’automation concernant les NCAs. Le premier est l’automation de la gestion de l’infrastructure, ou Infra-as-Code (IaC) et le deuxième est l’intégration et le déploiement continu.

Comme le précise Maud Chiva Rampazzo, Directrice Technique

Les déploiements Cloud étant récents et l’architecture Cloud Native mettant en œuvre plus de services granulaires, cela nécessite une mise en œuvre plus avancée des approches CI/CD et IaaC que pour des déploiements OnPremise

Pour pouvoir gérer efficacement une infrastructure cloud, il faut pouvoir « coder » les environnements. Concrètement, il faut écrire des scripts idempotents permettant de générer tout un environnement (avec ses composants infrastructure). Plus une infrastructure est complexe, plus grande est la probabilité d’erreurs si une personne devait tout créer « à la main », d’où l’intérêt du script idempotent.

Les applications, elles aussi, nécessitent d’être déployées de manière automatique et scriptées pour éviter au maximum l’intervention humaine. C’est le principe de l’intégration continue et du déploiement continu. Il s’agit d’un ensemble d’outils et de techniques permettant de garantir la bonne mise en service d’une application lorsque le développeur a fini son travail.

Les nouveaux défis de sécurité des applications Cloud natives

Comme nous venons de voir ensemble, les applications Cloud natives sont une source d’innovation et peuvent représenter un vrai avantage concurrentiel. Cependant, leurs caractéristiques, celles-là même qui représentent leurs forces, peuvent aussi représenter de potentielles failles de sécurité dans le système.

Infrastructure

L’infrastructure cloud, dans toute sa richesse et complexité, peut laisser beaucoup de « portes ouvertes ». Il faut appliquer le principe du moindre privilège, et n’accorder aux utilisateurs que les droits dont il a besoin et pour lesquels l’accès lui est légitime. Chaque fournisseur cloud possède ses propres mécanismes pour limiter les droits permettant de définir les rôles, les identités managées, les périmètres, etc. Il convient d’utiliser ces mécanismes systématiquement pour limiter au strict nécessaire les droits d’un utilisateur ou d’un service.

Le code

Dans le cloud, tout peut être du code, et donc il est normal de consacrer autant d’efforts que nécessaire quand il s’agit de sécurité.

Traditionnellement, les développeurs implémentent des fonctionnalités avec du code et ne s’occupent que très rarement de la question de la sécurité. C’est seulement une fois que le développement est terminé que l’équipe d’exploitation prend le relais et se pose des questions sur la sécurisation de l’infrastructure. Avec les applications natives cloud, il faut impliquer les développeurs sur la sécurité dès la phase de conception. Supposons qu’une clé d’accès commune aux différents groupes de ressources cloud soit poussée par erreur par un développeur dans le contrôle de source, cela représenterait une sérieuse faille.

De même, les FaaS, peuvent aussi provoquer indirectement des trous de sécurité car elles permettent d’exécuter du code « rapidement » quitte à négliger parfois les bonnes pratiques. Comme le précise Maud Chiva Rampazzo, Directrice Technique

Avec des instances Azure Function ou AppService par exemple, on peut verrouiller très fortement les accès grâce à des niveaux granulaires de sécurisation réseau et de gestion des permissions rarement mis en œuvre en OnPremise. De même, les capacités d’audit notamment de sécurité que l’on obtient de base avec ces services Cloud, sont plus difficiles à avoir en OnPremise … C’est parce que c’est facile à déployer depuis les environnements de développement (déploiement AppService, déploiement Azure Function depuis Visual Studio) vers les environnements de tests, qu’on oublie complètement ces configurations de sécurisation nécessaires en production mais non accessibles depuis les outils de publication de développement, et que les équipes d’exploitation ont encore tendance à laisser passer qu’il y a alors un risque de sécurité moindre…

Dans le développement il est fortement déconseillé de « réinventer la roue ». C’est pourquoi, il n’est pas inhabituel que des composants open-source se retrouvent dans des applications critiques (ce n’est pas spécifique aux applications Cloud native mais ça illustre bien le risque de sécurité démultiplié par des déploiements plus rapides). Cependant cela doit être maîtrisé en terme de bon choix, de gestion des versions, ce qui est rarement le cas. Une célèbre faille récente n’est autre que celle concernant Log4j. Il est donc impératif d’incorporer des outils d’analyse dédiés dans les pipelines.

Et enfin et pas le moindre, l’Infra-as-Code, permettant de générer toute l’infrastructure à partir du code, nécessite une attention toute particulière car si une faille y est présente dès le départ, alors toute l’infrastructure est corrompue.

L’intégration continue et le déploiement continu

Ces 2 fonctionnalités sont à la base du Time-to-Market, arme stratégique s’il en est pour les entreprises. Mais qui dit intégration/déploiement fréquent, dit aussi de nouvelles failles potentielles fréquentes. Il est donc indispensable de sensibiliser et de former les développeurs au Security by design car ils forment la première ligne de défense du système.

Conclusion :

Les applications Cloud natives représentent un formidable vecteur d’innovation et de création de valeur. Mais comme toute nouvelle opportunité, elles viennent avec leur lot de nouveaux défis à relever. Ne les considérons pas comme une menace, mais plutôt comme une occasion de faire évoluer nos connaissances, nos outils et notre façon de travailler pour construire un système de plus en plus sécure et fiable. Les services Cloud native offrent des solutions de sécurité très avancées bien plus que les architectures OnPrem mais, comme le précise Maud Chiva Rampazzo

le risque sécurité lié aux applications Cloud Native tient donc plus du fait que leurs capacités avancées de sécurisation ne sont pas suffisamment connues et donc utilisées (configurations additionnelles) par les développeurs d’une part, et que la délégation de ces responsabilités aux développeurs se fait sans contrôle suffisant par des exploitants parfois eux même novices en cloud d’autre part : « Shift Left mal abouti ».