Serverless et sécurité, ce qu’il faut comprendre
Sujets : Serverless, sécurité, OWASP
19/06/2019 - 19h30 - 20h30
Par Steve Houël (Ippon). Merci !
Steve a créé daSWAG, un générateur d’application web serverless.
La sécurité et nous ?
La sécurité c’est pour les autres. Je n’ai pas le budget…
Pourtant les statistiques parlent : le plus gros coût d’une attaque c’est la productivité.
La sécurité et le cloud public, un mariage parfait !
On parle de modèles de partage de sécurité. AWS garantit le niveau le plus haut possible. Plus solide que du “on premise”.
Qu’est-ce que le serverless ?
Même si le terme porte à confusion il y a bien des serveurs physiques derrière mais pas besoin de les gérer, ni même d’y penser ou encore de provisionner en infrastructure. L’idée est de ne payer que ce que l’on utilise. Pour simplifier le serverless c’est du BaaS (backend as a service) et du FaaS (function as a service) = on déploie des fonctions et non des applications. Et enfin le serverless est basé sur les évènements.
Les bénéfices ?
- Coût opérationnel réduit
- BaaS coût réduit de développement
- FaaS coût scaling
- Optimisation du code primordiale pour éviter les dépenses inutiles d’argent
- Plus écologique en termes de consommation de ressources
Les inconvénients ?
- “Vendor lock in”
- Problèmes de sécurité : comment gérer la gouvernance ?
- Implémentation : durée d’exécution, temps de démarrage, tests, packaging, versioning
- Difficulté pour tester, même si des frameworks comme LocalStack permettent d’émuler des appels nombreux. Notion de alias shifting proche du canary release pour choisir d’utiliser de tel ou tel environnement.
Certains langages ne sont pas adaptés au serverless (Java ou .NET C# par exemple). Il est préférable d’utiliser Node, Go ou Python sur du serverless. Il y a peu de développeurs compétents dans ces domaines.
Et la sécurité dans tout ça ?
Les responsabilités ne sont pas les mêmes que sur d’autres architectures. Pas besoin de gérer la sécurité au niveau OS car pas d’accès depuis les fonctions. Le FaaS s’occupe de la partie OS, des VMs, des containers, des BDDs…
Dangers :
- Surface d’attaque agrandie
- Complexité de cette surface d’attaque
- Complexité du système dans son ensemble (AWS Lambda, Amazon DynamoDB, Amazon API Gateway, Amazon Kinesis…)
Les risques principaux sont connus et sont recensés notamment par le Top 10 OWASP (le dernier disponible en ligne semble dater de 2017).
Il existe également un top 12 des risques critiques pour le serverless édité par Puresec.
Top 10 serverless :
- Injection de données dans les fonctions
- Authentification cassée : il faut des rôles privilégiés pour chaque fonction même si elles sont nombreuses et éviter l’authentification faible
- Configuration de déploiement non sécurisée : par exemple avec un flag qui rend public un bucket S3 (qui sont très crawlés par des personnes mal intentionnées)
- Rôles et permissions IAM : ne donner que les rôles minimaux aux fonctions
- Monitoring et logs inadéquats : manque de réponses aux incidents en temps réel
- Dépendances tierces non sécurisées : penser aux méthodes comme le OWASP dependency check dans maven, npm audit…
- Stockage des informations sensibles : attention aux variables d’environnement (possibilité de chiffrer l’information)
- DDoS : limite d’exécutions concurrentes, serverless apporte de la haute disponibilité et scalabilité, régler les timeouts bas
- Manipulation du flow d’exécution
- Mauvaise gestion des erreurs et exceptions : les options de debug pas à pas pour serverless sont limitées et plus complexes
En conclusion, il vaut mieux prévenir que guérir :
- Choisir le privilège moindre (plugin serverless-puresec-cli : scanne les fonctions et détecte les bonnes policies à mettre en place) : AWS IAM
- Logs et piste d’audit : AWS Cloudtrail et AWS Cloudwatch
- Outils d’observabilité comme Datadog notamment pour analyser les logs AWS Cloudtrail
- Éviter les DDoS : bien gérer les timeouts (pas 15 minutes par exemple si on sait que notre fonction s’exécute en moyenne en 30 ms => plutôt 50 ms), côté API Gateway pour gérer les quotas, penser au monitoring
- Utiliser AWS Config for Compliance pour détecter les problèmes avant qu’ils ne surviennent avec notamment des règles sur les rôles