Sécurisez votre architecture serverless avec un Cloud Penetration Testing infaillible

Vous avez probablement entendu le discours : "Le serverless, c'est l'avenir." Plus besoin de patcher les noyaux de systèmes d'exploitation, plus besoin de s'inquiéter de l'utilisation du CPU sur une VM spécifique, et plus besoin de payer pour des serveurs inactifs. Cela ressemble à un rêve. Vous n'avez qu'à télécharger votre code sur une AWS Lambda, une Google Cloud Function ou une Azure Function, et le fournisseur de cloud s'occupe du reste.

Mais voici ce qui est souvent passé sous silence dans les présentations marketing : "Serverless" ne signifie pas qu'il n'y a pas de serveurs. Cela signifie simplement que quelqu'un d'autre les gère. Bien qu'Amazon ou Microsoft s'occupent du matériel physique et des correctifs d'exécution, vous êtes toujours responsable du code que vous écrivez, des permissions que vous accordez et des données que vous traitez.

De nombreuses équipes commettent l'erreur de penser que le passage à une architecture serverless réduit automatiquement leur surface d'attaque. En réalité, cela ne fait souvent que changer sa forme. Vous avez échangé quelques grands serveurs monolithiques contre des centaines de petites fonctions éphémères. Chacune de ces fonctions est un point d'entrée potentiel. Si une fonction est mal configurée ou présente une vulnérabilité, un attaquant pourrait potentiellement pivoter à travers tout votre environnement cloud.

C'est là que le cloud Penetration Testing entre en jeu. Vous ne pouvez pas utiliser les scanners de réseau traditionnels sur une application serverless car il n'y a pas d'adresse IP persistante à scanner. Vous avez besoin d'une approche différente, une approche qui comprend la logique des architectures événementielles et les particularités des permissions cloud.

Pourquoi les architectures serverless nécessitent une approche de sécurité spécifique

Pendant des années, la sécurité consistait à construire un "fossé" autour du centre de données. Vous aviez un pare-feu, une DMZ et quelques passerelles fortement gardées. Si quelqu'un passait le pare-feu, il était dans le réseau, et vous le combattiez là.

Le serverless inverse ce modèle. Dans un environnement serverless, votre "périmètre" est désormais votre API gateway, vos événements déclencheurs et vos rôles IAM (Identity and Access Management). La surface d'attaque est fragmentée. Au lieu d'une grande porte, vous avez mille petites fenêtres.

Le mythe de la "sécurité héritée"

Une idée fausse courante est que le fournisseur de cloud gère toute la sécurité. C'est le "Shared Responsibility Model", et c'est là que la plupart des violations se produisent parce que les gens comprennent mal où s'arrête le travail du fournisseur et où commence le vôtre.

Le fournisseur sécurise le cloud lui-même : la couche de virtualisation, les disques physiques et le système d'exploitation sous-jacent. Vous sécurisez tout ce qui se trouve à l'intérieur du cloud. Cela comprend :

Le code : Si votre fonction Node.js présente une vulnérabilité dans une bibliothèque tierce, AWS ne va pas la corriger pour vous.
La configuration : Si vous définissez votre bucket S3 sur "public" par erreur, c'est de votre faute.
Les permissions : Si votre fonction Lambda a AdministratorAccess au lieu de simplement la permission d'écrire dans une table de base de données spécifique, vous avez créé un énorme trou de sécurité.

Le défi des actifs éphémères

Le Penetration Testing traditionnel implique souvent la "persistance" : un testeur obtient l'accès à un serveur et maintient cet accès pour voir ce qu'il peut trouver. En serverless, le "serveur" existe peut-être pendant 200 millisecondes, puis disparaît.

Cela ne le rend pas plus sûr ; cela rend simplement la surveillance plus difficile. Les attaquants ont appris à s'adapter. Ils n'essaient pas de "s'asseoir" sur un serveur ; ils se concentrent sur l'"event injection" et l'"permission escalation". Ils cherchent des moyens d'amener votre fonction à exécuter une commande ou à divulguer une clé secrète qui leur permet de se déplacer latéralement dans votre compte cloud.

Vulnérabilités courantes dans les applications serverless

Avant de pouvoir tester les failles, vous devez savoir où elles se trouvent habituellement. Les applications serverless ont des modes de défaillance uniques. Bien que vous ayez toujours affaire à l'OWASP Top 10 (comme SQL Injection), elles se manifestent différemment dans un monde natif du cloud.

Event Injection : le nouveau SQLi

Dans une application traditionnelle, l'entrée utilisateur provient généralement d'une requête HTTP. En serverless, l'entrée peut provenir de n'importe où : un téléchargement de bucket S3, un flux DynamoDB, un message Pub/Sub ou un e-mail via SES.

Si votre fonction fait confiance aux données provenant d'un déclencheur d'événement sans les assainir, vous avez un problème d'injection. Par exemple, si une fonction est déclenchée par un téléchargement de fichier et utilise ensuite le nom de fichier dans une commande système pour traiter l'image, un attaquant pourrait télécharger un fichier nommé ; rm -rf /; .jpg. Si le code n'est pas prudent, il pourrait exécuter cette commande.

Rôles IAM sur-privilégiés

C'est peut-être le risque le plus important dans les environnements cloud. Parce qu'il est "plus facile" de simplement donner à une fonction FullAccess à un service que de passer une heure à déterminer les 12 permissions exactes dont elle a besoin, de nombreux développeurs prennent le chemin de la moindre résistance.

Imaginez une fonction qui n'a besoin que de lire un fichier spécifique à partir d'un bucket S3. Si on lui donne les permissions s3:*, un attaquant qui trouve une vulnérabilité d'exécution de code dans cette fonction peut maintenant lister tous les buckets de votre compte, télécharger les données de vos clients ou même supprimer vos sauvegardes. Le cloud Penetration Testing se concentre fortement sur les audits de "moindre privilège" pour trouver ces lacunes.

Authentification et autorisation brisées

Étant donné que les fonctions serverless sont souvent découplées, les développeurs supposent parfois que si une requête a atteint la fonction, elle a déjà été authentifiée par l'API Gateway.

Mais que se passe-t-il s'il existe un moyen de déclencher la fonction directement, en contournant la passerelle ? Ou que se passe-t-il si la fonction ne vérifie pas que l'utilisateur a la permission d'accéder à l'ID de ressource spécifique qu'il demande ? Cela conduit à des Insecure Direct Object References (IDOR), où un utilisateur peut changer un userId dans une requête et voir les données de quelqu'un d'autre.

L'enfer des dépendances dans le cloud

Le serverless encourage l'utilisation de nombreuses petites bibliothèques pour maintenir un package de déploiement léger. Cependant, chaque package npm ou pip que vous incluez est une porte dérobée potentielle. Étant donné que ces fonctions sont déployées fréquemment et automatiquement, une dépendance compromise peut être poussée en production à travers un millier de fonctions en quelques secondes.

Les Composants Principaux du Cloud Penetration Testing

Si vous voulez correctement « blindé » votre configuration, vous ne pouvez pas simplement exécuter un script et considérer que c'est terminé. Vous avez besoin d'une approche multicouche qui imite la façon dont un véritable attaquant pense.

1. Revue d'Architecture et Modélisation des Menaces

Vous commencez par cartographier le flux. D'où viennent les données ? Quelles fonctions communiquent avec quelles bases de données ? Où sont les limites de confiance ?

Un bon modèle de menace pose la question suivante : « Si cette fonction Lambda spécifique est compromise, quelle est la pire chose qui puisse arriver ? » Si la réponse est « Ils obtiennent les clés de tout le royaume », vous savez exactement où vos tests doivent se concentrer.

2. Audit de Configuration

C'est le « fruit à portée de main ». Une grande partie du cloud Penetration Testing consiste à rechercher les erreurs de configuration. Nous recherchons :

Des buckets S3 ouverts ou des snapshots EBS publics.
Des clés d'API codées en dur dans les variables d'environnement.
Un manque de chiffrement des données au repos ou en transit.
Des informations d'identification par défaut sur les instances de base de données.

3. Analyse Dynamique (DAST) pour Serverless

C'est la partie active du test. Le but est d'envoyer des événements « malveillants » à vos fonctions et de voir comment elles réagissent.

Fuzzing API Gateways : Envoyer des caractères inattendus ou des charges utiles surdimensionnées pour voir si la fonction plante ou divulgue une trace de pile.
Manipulation d'Événements : Créer de faux événements S3 ou des messages SNS pour voir si la fonction les traite sans validation appropriée.
Attaques de Timing : Mesurer le temps qu'une fonction met à répondre pour déterminer si une donnée spécifique existe (par exemple, deviner des noms d'utilisateur).

4. Tests d'Escalade IAM

Une fois qu'un testeur trouve un moyen d'exécuter du code dans une fonction, il ne s'arrête pas là. Il essaie de « sortir » du périmètre limité de la fonction. Il vérifiera le rôle IAM actuel et essaiera d'utiliser l'interface de ligne de commande du fournisseur de cloud pour voir ce qu'il peut faire d'autre. Peut-il créer un nouvel utilisateur administrateur ? Peut-il lire des secrets depuis le Secret Manager ? C'est là que réside le véritable danger.

Étape par Étape : Comment Mener un Audit de Sécurité Serverless

Si vous êtes chargé de sécuriser une application serverless, ne vous contentez pas d'improviser. Suivez un processus structuré. Voici une présentation pratique du déroulement habituel d'une évaluation professionnelle.

Phase 1 : Reconnaissance

Dans le cloud, la reconnaissance consiste souvent à trouver les points d'entrée.

Identifier les Endpoints : Trouvez toutes les URL d'API Gateway, les endpoints de Webhook et les buckets accessibles au public.
Analyser les Données Publiques : Recherchez les clés divulguées sur GitHub ou les fichiers JS publics qui révèlent la structure interne de l'API.
Cartographier les Déclencheurs : Comprenez quels événements déclenchent quelles fonctions. Un téléchargement vers bucket-a déclenche-t-il function-b ?

Phase 2 : Découverte des Vulnérabilités

Maintenant, vous commencez à tester le système.

Tests d'Entrée : Essayez les injections classiques (SQL, NoSQL, OS Command) sur chaque champ de saisie.
Tests de Logique : Essayez de contourner le flux attendu. Si un processus est censé être Step A -> Step B -> Step C, pouvez-vous déclencher Step C directement ?
Analyse des Dépendances : Utilisez des outils pour vérifier les vulnérabilités connues (CVEs) dans les bibliothèques utilisées par les fonctions.

Phase 3 : Exploitation (L'« Effraction »)

Si vous trouvez une vulnérabilité, vous essayez de prouver son impact.

Preuve de Concept (PoC) : Pouvez-vous réellement lire un fichier que vous ne devriez pas ? Pouvez-vous modifier un enregistrement dans la base de données ?
Livraison de la Charge Utile : Utilisez une charge utile pour exfiltrer les informations d'identification de sécurité temporaires (les AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY) que le fournisseur de cloud injecte dans l'environnement de la fonction.

Phase 4 : Post-Exploitation et Mouvement Latéral

C'est la phase la plus critique pour comprendre le risque commercial.

Évaluation des Informations d'Identification : Utilisez les clés temporaires volées pour voir à quels autres services elles peuvent accéder.
Pivot : Voyez si vous pouvez utiliser la fonction compromise pour attaquer d'autres services internes qui ne sont pas exposés à Internet.
Exfiltration de Données : Tentez de déplacer un petit élément de données sensibles hors de l'environnement pour prouver qu'une violation pourrait se produire.

Comparaison entre le Pen Testing Traditionnel et le Pen Testing Natif du Cloud

Il est courant que les entreprises essaient d'utiliser leurs anciennes listes de contrôle de Penetration Testing pour leurs nouvelles applications cloud. Cela ne fonctionne presque jamais. Voici pourquoi ils sont fondamentalement différents.

Fonctionnalité	Penetration Testing Traditionnel	Cloud-Native/Serverless Pen Testing
Cible	Adresses IP, Serveurs, Ports	APIs, Déclencheurs d'événements, Rôles IAM
Objectif	Vulnérabilités du système d'exploitation, Failles du réseau	Erreurs de logique, Mauvaises configurations, Permissions
Persistance	Installation d'une porte dérobée/Rootkit	Vol de jetons temporaires, Prise de rôle
Outillage	Nmap, Metasploit, Nessus	Cloud Custodian, Burp Suite, Scripts d'événements personnalisés
Périmètre	Pare-feu et VPN	L'identité est le nouveau périmètre (IAM)
Vitesse	Plus lent, axé sur l'accès "profond"	Plus rapide, axé sur l'accès "large" à travers les services

Gérer le "Bruit" : Surveillance et journalisation en Serverless

L'un des plus gros casse-têtes de la sécurité serverless est que les journaux sont dispersés. Vous avez les journaux d'API Gateway, les journaux CloudWatch, les traces X-Ray et peut-être une journalisation tierce.

Si un attaquant frappe vos fonctions avec un millier de charges utiles différentes, comment savez-vous qu'il s'agit d'une attaque et pas simplement d'un frontend bogué ?

L'importance de la journalisation centralisée

Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir. Pour rendre votre application serverless véritablement à l'épreuve des balles, vous devez envoyer vos journaux à un système centralisé (comme un SIEM) où vous pouvez corréler les événements.

Par exemple, si vous voyez une rafale d'erreurs 403 Forbidden sur votre API Gateway, suivie d'un seul 200 OK sur un endpoint sensible, c'est un signe classique d'une attaque par force brute ou par injection réussie. Si ces journaux se trouvent à deux endroits différents, vous manquerez le schéma.

Implémentation de la "Security-as-Code"

Puisque le serverless est axé sur l'automatisation, votre sécurité devrait l'être aussi. Au lieu de faire un Penetration Test une fois par an, passez à une sécurité continue.

Analyse de l'Infrastructure as Code (IaC) : Utilisez des outils pour analyser vos modèles Terraform ou CloudFormation avant qu'ils ne soient déployés. Si un modèle définit un bucket S3 comme public, la build doit échouer automatiquement.
Garde-fous automatisés : Configurez des politiques qui empêchent certaines actions sur l'ensemble du compte (par exemple, "Personne n'est autorisé à créer un utilisateur IAM avec un accès Administrateur").

Comment Penetrify Simplifie le Cloud Penetration Testing

Faire tout cela manuellement est un cauchemar. Vous avez soit besoin d'une équipe massive de consultants en sécurité coûteux, soit d'un développeur qui passe la moitié de son temps à lire des blogs sur la sécurité au lieu d'écrire des fonctionnalités.

C'est là que Penetrify intervient. Au lieu d'essayer de construire votre propre laboratoire de sécurité ou de deviner où se trouvent les trous, Penetrify fournit une plateforme cloud-native pour identifier, évaluer et corriger ces vulnérabilités.

Fini les maux de tête liés à l'infrastructure

Les outils de test traditionnels vous obligent souvent à configurer des "agents d'analyse" ou du matériel spécialisé. Penetrify est basé sur le cloud. Vous n'avez pas besoin d'installer quoi que ce soit sur votre machine locale ou de lancer des VMs séparées juste pour tester votre environnement. Vous obtenez une vue complète de votre posture de sécurité sans les dépenses d'investissement en matériel spécialisé.

Mise à l'échelle de votre sécurité

Pour les entreprises de taille moyenne, l'embauche de cinq penetration testers à temps plein n'est pas toujours réalisable. Penetrify vous permet de mettre à l'échelle vos capacités de test. Que vous ayez dix fonctions ou dix mille, la plateforme peut vous aider à automatiser le processus d'analyse tout en fournissant la profondeur nécessaire à l'évaluation manuelle.

Combler le fossé entre la découverte et la correction

Le pire dans un Penetration Test est de recevoir un PDF de 100 pages de "vulnérabilités" que les développeurs ignorent ensuite parce qu'ils ne savent pas comment les corriger. Penetrify se concentre sur les conseils de correction. Il ne se contente pas de dire "Vous avez un rôle IAM surprivilégié" ; il vous aide à comprendre exactement comment resserrer ce rôle pour suivre le principe du moindre privilège.

Surveillance continue vs. Tests ponctuels

Un Penetration Test est un instantané. Dès que vous déployez une nouvelle version de votre code, cet instantané est obsolète. Penetrify aide les organisations à évoluer vers un modèle de surveillance continue. En s'intégrant à vos flux de travail existants, il garantit que les nouvelles vulnérabilités sont détectées dès leur introduction, plutôt que six mois plus tard lors d'un audit annuel.

Erreurs courantes lors de la sécurisation des applications Serverless

Même les développeurs chevronnés commettent ces erreurs. Si vous les voyez dans votre codebase, vous devriez prioriser un Penetration Test immédiatement.

1. Utilisation d'un seul rôle IAM pour toutes les fonctions

Si chaque fonction de votre application partage le même "AppRole", vous avez un rayon d'explosion massif. Si la fonction "Contactez-nous" est compromise, l'attaquant a maintenant les permissions de la fonction "Traiter les paiements". Chaque fonction doit avoir son propre rôle dédié.

2. Faire confiance au réseau "interne"

Certaines personnes pensent que parce qu'une fonction est déclenchée par une autre fonction interne, les données sont "sûres". C'est une erreur. Si un attaquant compromet la première fonction, il peut envoyer des charges utiles malveillantes à la seconde. Validez toujours les entrées, peu importe d'où elles viennent.

3. Coder en dur les secrets dans les variables d'environnement

Bien que les variables d'environnement soient meilleures que le codage en dur des clés dans le script, elles sont encore souvent visibles dans la console cloud ou divulguées dans les journaux. Utilisez un gestionnaire de secrets dédié (comme AWS Secrets Manager ou HashiCorp Vault) et extrayez les clés au moment de l'exécution.

4. Ignorer les paramètres "Timeout" et "Memory"

C'est un point subtil. Si vous définissez le délai d'expiration de votre fonction à 15 minutes et que vous lui donnez 10 Go de RAM, vous avez créé une cible de choix pour les attaques de type Denial of Wallet (DoW). Un attaquant peut envoyer des requêtes complexes qui forcent vos fonctions à s'exécuter pendant la durée maximale et à utiliser la mémoire maximale, ce qui peut faire grimper votre facture cloud à des milliers de dollars en quelques heures.

Une checklist pratique pour la sécurité Serverless

Si vous vous apprêtez à effectuer un examen de sécurité aujourd'hui, utilisez cette checklist pour vous assurer d'avoir couvert les bases.

Identity and Access Management (IAM)

Chaque fonction a-t-elle son propre rôle IAM unique ?
Existe-t-il des rôles avec des permissions * (caractère générique) ?
Utilisons-nous des informations d'identification temporaires au lieu de clés d'utilisateur IAM à long terme ?
L'authentification MFA est-elle activée pour tous les utilisateurs ayant accès à la console cloud ?

Gestion des entrées et des données

Toutes les entrées provenant de déclencheurs d'événements (S3, SNS, SQS) sont-elles nettoyées avant d'être utilisées ?
Utilisons-nous des requêtes paramétrées pour toutes les interactions avec la base de données ?
Les données sensibles sont-elles chiffrées au repos et en transit ?
Avons-nous désactivé les messages d'erreur détaillés (traces de pile) en production ?

Réseau et infrastructure

Les API Gateways sont-elles protégées par un Web Application Firewall (WAF) ?
Utilisons-nous un VPC pour les fonctions qui doivent accéder à des ressources internes ?
Tous les buckets S3 sont-ils configurés par défaut sur privé ?
Avons-nous mis en œuvre une limitation du débit pour empêcher les attaques DoS/DoW ?

Observabilité et gouvernance

Tous les journaux de fonctions sont-ils envoyés vers un emplacement central ?
Avons-nous des alertes pour les pics anormaux d'exécution ou d'erreurs de fonctions ?
Notre Infrastructure as Code (IaC) est-elle analysée pour détecter les erreurs de configuration ?
Avons-nous un processus documenté pour corriger les dépendances vulnérables ?

Mettre tout cela en œuvre : un scénario réel

Examinons un scénario hypothétique pour voir comment ces éléments s'articulent.

L'application : Un service de traitement d'images serverless. Les utilisateurs téléchargent une photo dans un bucket S3, ce qui déclenche une fonction Lambda pour redimensionner l'image et stocker un lien dans une table DynamoDB.

La vulnérabilité : Le développeur a utilisé une bibliothèque de traitement d'images courante qui présentait une vulnérabilité connue permettant l'exécution de code à distance (RCE) si un fichier .jpg spécialement conçu était téléchargé. Pour faciliter les choses, la fonction Lambda a reçu les permissions s3:* et dynamodb:*.

Le chemin d'attaque :

L'attaquant télécharge un fichier image malveillant.
La fonction Lambda se déclenche, la bibliothèque plante et l'attaquant obtient un shell à l'intérieur de l'environnement de la fonction.
L'attaquant exécute env et trouve les jetons de sécurité AWS temporaires.
Comme le rôle est sur-privilégié, l'attaquant utilise ces jetons pour lister tous les buckets S3 du compte.
Il trouve un bucket appelé customer-backups-2023 et télécharge l'intégralité du contenu.

La prévention (la méthode "à toute épreuve") :

Analyse des dépendances : Un outil comme Penetrify aurait signalé la bibliothèque d'images vulnérable pendant le processus de construction.
Moindre privilège : Si la fonction n'avait que s3:GetObject pour un bucket spécifique et dynamodb:PutItem pour une table, l'attaquant n'aurait pas pu lister les autres buckets.
WAF/Validation des entrées : Un WAF aurait pu bloquer le téléchargement de fichiers avec des en-têtes suspects.
Surveillance : Une alerte se serait déclenchée lorsque la fonction Lambda a soudainement commencé à effectuer des appels ListBuckets, une action qu'elle n'effectue jamais en fonctionnement normal.

FAQ : Questions fréquentes sur les Penetration Testing Serverless

Q : Ai-je vraiment besoin d'un Penetration Test si j'utilise un service géré comme AWS Lambda ? R : Oui. AWS gère le serveur, mais vous gérez la logique. La plupart des violations serverless se produisent en raison de bugs au niveau de l'application ou de mauvaises configurations IAM, et non parce que la plateforme Lambda sous-jacente a été piratée.

Q : Les Penetration Testing ne risquent-ils pas de faire planter mon environnement de production ? R : Cela peut arriver, si c'est mal fait. C'est pourquoi les tests professionnels sont généralement effectués dans un environnement de staging qui reflète la production. Cependant, les outils natifs du cloud sont conçus pour être moins intrusifs que les anciens scanners de type "hammer the server".

Q : À quelle fréquence dois-je effectuer des Penetration Testing cloud ? R : Au minimum, une fois par an ou après tout changement architectural majeur. Cependant, la référence est la "Sécurité Continue" - l'intégration de l'analyse automatisée dans votre pipeline CI/CD afin que chaque commit soit testé.

Q : Ne puis-je pas simplement utiliser un scanner de vulnérabilités automatisé ? R : Les scanners automatisés sont parfaits pour trouver les CVE connus ou les ports ouverts, mais ils sont nuls pour trouver les failles logiques. Ils ne vous diront pas que votre fonction "Admin" peut être déclenchée par un utilisateur "Guest". Vous avez besoin d'une combinaison d'analyse automatisée et d'expertise humaine manuelle.

Q : Le serverless est-il réellement plus sûr que l'hébergement VPS traditionnel ? R : À bien des égards, oui. Vous vous débarrassez de toute une classe de vulnérabilités (comme les mauvaises configurations SSH ou les exploits du noyau du système d'exploitation). Mais vous en introduisez de nouvelles. Ce n'est pas "plus" ou "moins" sûr ; c'est juste un ensemble de risques différents.

Dernières réflexions et prochaines étapes

Passer au serverless est une excellente initiative pour la vitesse et l'évolutivité, mais cela ne doit pas être un raccourci pour la sécurité. La "magie" du cloud - l'abstraction, l'automatisation, l'éphémère - est précisément ce qui rend sa sécurisation difficile.

Si vous vous êtes reposé sur la mentalité du « c'est géré par le fournisseur », il est temps de changer de cap. Commencez par auditer vos rôles IAM. Nettoyez ces permissions avec des caractères génériques. Examinez vos dépendances. Et surtout, arrêtez de considérer la sécurité comme une simple case à cocher à la fin d'un projet.

L'objectif n'est pas de construire un mur autour de votre application, car dans le cloud, il n'y a pas de murs. L'objectif est de construire un système résilient où chaque composant est renforcé, chaque permission est minimisée et chaque événement est validé.

Si vous vous sentez dépassé par la complexité de votre environnement cloud, vous n'êtes pas obligé de le faire seul. Des plateformes comme Penetrify sont conçues pour éliminer les approximations du processus. En combinant l'analyse automatisée avec une architecture native du cloud, elles vous aident à trouver les failles avant que les méchants ne le fassent.

Prêt à voir où sont vos angles morts ? N'attendez pas une violation de données pour découvrir que vos rôles IAM sont trop permissifs. Rendez-vous sur Penetrify et commencez à sécuriser votre infrastructure serverless dès aujourd'hui. Vos données, et votre sommeil, vous remercieront.

Retour au blog