Qu'est-ce que la sécurité sans serveur ?

Qu'est-ce que l'informatique sans serveur ?

L'informatique sans serveur fait référence à un modèle informatique clouddans lequel le fournisseur cloud fait fonctionner le serveur et gère dynamiquement l'allocation des ressources de la machine. AWS Lambda Functions, Google cloud Functions et Azure Functions sont des frameworks populaires sans serveur qui construisent des applications.

Une architecture sans serveur offre l'avantage d'une mise à l'échelle automatisée et quasi infinie. Il y a très peu de distance entre les développeurs et le code déployé, ce qui accélère la mise sur le marché et facilite la maintenance et le test des fonctions individuelles. Enfin, la quantité réelle de ressources d'application consommées a un impact sur la tarification, ce qui signifie que vous ne payez que pour ce que vous utilisez, d'où une réduction des coûts.

La technologie sans serveur représente un nouveau transfert de responsabilités du client vers le fournisseur cloud. Aucune infrastructure n'étant impliquée, les frais généraux d'exploitation diminuent considérablement.

En confiant la gestion de l'infrastructure à votre fournisseur cloud, vous pouvez vous concentrer sur le développement de solutions au service de votre organisation et de vos clients. Elle vous aide à vous concentrer sur vos avantages concurrentiels uniques et vous permet souvent de réaliser des économies, non seulement sur le plan informatique, mais aussi en déplaçant des personnes vers le développement.

Comment la sécurité peut-elle être améliorée grâce à la technologie Serverless ?

Voici quelques points clés :

1. cloud Les fournisseurs s'occupent du système d'exploitation, de la sécurité d'exécution et des correctifs. En déployant une application sans serveur, vous cédez le contrôle de la majeure partie de la pile à votre fournisseur de cloud, et il fournit des services tels que la gestion des clés. Vous ne possédez plus le durcissement du système d'exploitation, les droits d'administration, le SSH et la segmentation. AWS, Microsoft et Google sont fiables en ce qui concerne le maintien des correctifs et de la sécurité de leurs parties de la pile, et le fait de leur donner une plus grande part de la pile améliore certainement les choses à cet égard.
2. Apatrides/éphémères. En outre, la nature éphémère et sans état de l'informatique sans serveur complique la vie des attaquants. Les fonctions sans serveur comme AWS Lambda s'exécutent pendant quelques secondes, puis meurent. Les conteneurs sont recyclés. Le fait que les fonctions sans serveur aillent et viennent, n'ayant pas de mémoire, réduit le risque d'attaques à long terme.
3. Visibilité sur les applications sans serveur - L'avantage. Le fait que les applications sans serveur soient structurées comme un grand nombre de petites fonctions dans le cloud offre une fantastique opportunité en matière de sécurité. Les outils de sécurité applicative se donnent souvent beaucoup de mal pour analyser et instrumenter votre application packagée dans le seul but de pouvoir observer ou filtrer le flux interne de votre application.
4. Des microservices plus petits = la possibilité de construire des rôles adéquats et minimaux pour chaque fonction. Le passage à des microservices plus petits vous permet d'avoir une gestion plus fine de l'IAM. Vous avez la possibilité d'appliquer des politiques de sécurité à chacune de ces petites choses, ce qui peut réduire considérablement votre surface d'attaque.

Tant qu'une fonction au sein d'un conteneur a besoin d'accéder à la lecture de S3, toutes les fonctions de ce conteneur disposent également de ce privilège. Avec AWS Lambda, vous avez la possibilité d'appliquer des privilèges à des fonctions individuelles, et de vous assurer que ces privilèges sont limités à la plus petite portée nécessaire. En cas de vulnérabilité dans l'une de vos fonctions, un attaquant n'aura accès qu'aux capacités limitées de cette fonction, et non à l'ensemble des autorisations à accorder à un conteneur.

Quels sont les défis de Sécurité sans serveur ?

Avec l'évolution de la structure des applications sans serveur, de nouveaux défis se présentent.

1. La visibilité de la sécurité devient plus difficile. La quantité totale d'informations et le nombre de ressources augmentent avec le serverless. Cela vous empêche de donner un sens à toutes les données. Avec un milliard d'événements dans votre journal chaque jour, il est difficile d'obtenir de l'intelligence à partir des montagnes de données pour une véritable observabilité.
2. Les protocoles, les vecteurs et les points d'attaque se sont multipliés dans chaque fonction, et protocole = un point d'attaque potentiel. Cela nécessite des approches uniques pour la sécurité de Google Functions, Azure Functions et AWS Lambda.
3. Plus de ressources = plus d'autorisations à gérer. Plus de ressources équivaut à plus de permissions à gérer, ce qui crée des difficultés pour déterminer les permissions pour toutes ces interactions. Une technologie automatisée permet de détecter les risques liés à la configuration et de générer automatiquement des autorisations pour les fonctions de moindre privilège.
4. L'observabilité dans les applications sans serveur - Le défi. Les apps sans serveur utilisent différents services de divers fournisseurs de cloud, à travers plusieurs versions et régions. Pour comprendre votre surface d'attaque et les risques potentiels, vous avez besoin d'une vue d'ensemble de tout votre écosystème sans serveur. Au fur et à mesure que votre application se propage, cette vision axée sur la sécurité peut s'avérer de plus en plus difficile à construire et à maintenir.

Où déployer Sécurité sans serveur ?

Avec une application sans serveur, il n'y a nulle part où placer une sécurité classique telle que WAF, firewall et IDS. Il n'est pas simple d'ériger des murs entre les attaquants et les ressources, et ce pour plusieurs raisons.

1. Si un déploiement plus rapide et plus fréquent peut être très positif, la vélocité du serverless peut soulever de nouveaux défis en matière de configuration de la sécurité.
2. Les outils de sécurité peuvent allonger le temps de traitement, que vous devez multiplier par toutes les demandes. Heureusement, la plupart des bonnes pratiques de Sécurité sans serveur ne nécessitent pas de temps de traitement supplémentaire.
3. Érosion du périmètre. L'application traditionnelle avait une limite claire. L'extérieur et l'intérieur étaient distincts et nous pouvions assurer la sécurité du périmètre. Bien qu'il ne soit pas idéal de maintenir la sécurité exclusivement dans le périmètre, il a été possible de construire un mur.

Les applications sans serveur sont plus poreuses et plus fines. Composées de dizaines ou de centaines de fonctions, les applications sans serveur sont de minuscules microservices avec leurs propres politiques, rôles, API, piste d'audit, etc. Cela modifie la surface d'attaque : au lieu d'un petit nombre de points d'entrée avec de nombreuses fonctionnalités cachées derrière chacun d'entre eux, il y a maintenant plus de points d'entrée, chacun avec une petite partie de l'application derrière lui. Pour défendre votre site application, vous devez désormais réfléchir à chaque point d'entrée.

Divers événements peuvent déclencher des fonctions, telles que

• cloud les événements de stockage (par exemple AWS S3, Azure Blob storage, Google cloud Storage)
• Traitement des données de flux (par exemple AWS Kinesis)
• Changements dans les bases de données (par exemple AWS DynamoDB, Azure CosmosDB)
• Modifications du code (par exemple AWS CodeCommit)
• Notifications (par exemple, SMS, courriels, IoT)

Quelles sont les menaces de Sécurité sans serveur ?

Si les motivations des attaquants restent les mêmes, les tactiques qu'ils utiliseront avec les applications sans serveur doivent changer. Voici quelques-unes des menaces de Sécurité sans serveur propres à cette nouvelle architecture d'application.

1. La menace des fonctions sur-privilégiées

Avec l'application sans serveur, vous avez la possibilité d'appliquer des privilèges à des fonctions individuelles, et de vous assurer que ces privilèges sont limités au plus petit périmètre nécessaire. Cela peut vous permettre de réduire considérablement votre surface d'attaque et d'atténuer l'impact d'une attaque.

Malheureusement, une étude récente de Check Point a révélé que la grande majorité des développeurs ne profitent pas de cette opportunité. Notre recherche a découvert que 98 % des fonctions dans les applications sans serveur sont à risque, dont 16 % sont considérées comme "sérieuses". En outre, la plupart de ces fonctions sont dotées de plus d'autorisations qu'elles n'en ont besoin, qui pourraient être supprimées pour améliorer la sécurité de la fonction et de l'application.

Lors de l'analyse des fonctions, Check Point attribue un score de risque à chaque fonction. Elle est basée sur les faiblesses de posture découvertes et tient compte non seulement de la nature de la faiblesse, mais aussi du contexte dans lequel elle se produit. Après avoir analysé des dizaines de milliers de fonctions dans des applications réelles, nous avons constaté que la plupart des applications sans serveur ne sont tout simplement pas déployées de manière aussi sécurisée qu'elles devraient l'être pour minimiser les risques. Les principaux problèmes de sécurité découverts par Check Point sont des autorisations inutiles, tandis que les autres concernent des codes et des configurations vulnérables.

2. L'attaque de la marmotte

Le fait que les fonctions sans serveur soient éphémères et de courte durée rend plus difficile pour les attaquants de persister dans votre application à long terme. C'est d'ailleurs l'un des nombreux avantages du serverless en matière de sécurité. Toutefois, ce n'est pas parce que cela rend la vie plus difficile aux attaquants qu'ils cesseront leurs attaques ; ils changeront simplement de stratégie.

La courte durée des fonctions sans serveur signifie que les menaces de Sécurité sans serveur peuvent changer de forme. Les attaquants peuvent élaborer une attaque beaucoup plus courte qui se contente de voler, par exemple, quelques numéros de carte de crédit. Ce tour unique de l'attaque se répète continuellement dans ce que nous appelons l'attaque du "jour de la marmotte".

3. L'empoisonnement du puits

Malgré la courte durée de vie des ressources natives de cloud, les attaquants peuvent toujours trouver des moyens d'obtenir une persistance à long terme dans votre application. Une façon pour les attaquants de contourner la nature éphémère de l'application sans serveur est de mener une attaque en amont, ou "Poisoning the Well".

Les applications "cloud-native" ont tendance à comprendre de nombreux modules et bibliothèques avec du code provenant de diverses sources tierces. Les attaquants s'efforcent d'inclure des codes malveillants dans les projets courants. Ensuite, après avoir empoisonné le puits, le code malveillant contenu dans vos applications cloud peut appeler chez lui, obtenir des instructions et faire des ravages.

4. Augmentation du temps nécessaire à la configuration de la sécurité sans serveur

Bien qu'il ne s'agisse pas précisément d'une "menace" pour la sécurité, il s'agit plutôt d'un défi et d'une entrave possible à vos efforts pour sécuriser votre architecture sans serveur.

Serverless offre l'avantage d'augmenter la vitesse de développement de application. Malheureusement, l'approche traditionnelle de la sécurité, selon laquelle les développeurs écrivent du code et des charges de travail, et les opérations de sécurité mettent ensuite en place des contrôles de sécurité autour de ces charges de travail, ne fonctionnera tout simplement pas pour le serverless.

Si les développeurs doivent attendre que la sécurité ouvre des ports, des rôles IAM ou des groupes de sécurité pour eux, l'avantage d'une plus grande rapidité s'érode rapidement. Trop souvent, la solution consiste à supprimer le SecOps de l'équation, ce qui peut effectivement constituer un risque.

D'autre part, la configuration des autorisations pour la myriade de ressources sans serveur et les interactions entre elles est une tâche qui prend du temps. En outre, le fait de "consacrer" le temps des développeurs à cette configuration de sécurité peut rapidement s'avérer coûteux et ne constitue pas une utilisation idéale de leur temps. L'automatisation, telle que la plateforme CloudGuard, permet d'améliorer la sécurité sans serveur sans consacrer trop de temps aux développeurs.

5. Augmentation du temps de traitement des dossiers de sécurité

Un autre avantage du serverless est que vous ne payez que pour ce que vous consommez réellement, ce qui peut se traduire par une réduction des coûts. Néanmoins, le fait de payer exactement ce que vous utilisez signifie que toute augmentation du temps de traitement entraînera une augmentation des coûts.

Le fait de placer un excès de configuration de sécurité dans votre application peut potentiellement ajouter du travail supplémentaire à vos fonctions, ce qui peut augmenter les coûts. Si l'augmentation du temps de traitement au nom de la sécurité est un investissement judicieux, elle nécessite une mise en œuvre adéquate afin d'éviter des augmentations de coûts excessives et inutiles.

À l'instar de l'augmentation du temps pour Sécurité sans serveur Configuration ci-dessus, il ne s'agit pas exactement d'une menace, mais plutôt d'un défi que vous devrez relever tout en sécurisant votre architecture sans serveur.