Série Coders Conquer Security Infrastructure as Code : Erreur de configuration de sécurité - Autorisations inappropriées

Les menaces de cybersécurité sont aujourd'hui omniprésentes et incessantes. La situation est telle qu'il est devenu presque impossible de les contrer une fois les programmes déployés. Les organisations avisées adoptent donc le concept d'infrastructure as code, permettant aux développeurs de contribuer à la création d'applications sécurisées dès leur conception. Cette série a pour but de vous préparer à la sécurité, afin que vous puissiez comprendre les mesures à prendre en tant que développeur pour déployer une infrastructure sécurisée en tant que code au sein de votre propre organisation.

Les erreurs de configuration de sécurité, en particulier celles liées à des autorisations inappropriées, surviennent le plus souvent lorsqu'un développeur crée un nouvel utilisateur ou accorde des droits à une application pour accomplir une tâche. Par exemple, cela peut être fait pour collecter des informations à partir d'une base de données. Mais si les autorisations du nouvel utilisateur sont trop étendues, ou ne sont pas configurées par défaut pour la tâche à accomplir, cela peut introduire une vulnérabilité grave dans le code.

Avant d'entrer dans le vif du sujet, pourquoi ne pas tester vos compétences dès maintenant ? Essayez de trouver et de corriger certaines vulnérabilités liées à des autorisations inappropriées :

Comment vous en êtes-vous sorti ? Approfondissons un peu :

Accorder à un utilisateur ou à une application des autorisations complètes, ou ne jamais prendre la peine de définir ce que le nouvel utilisateur doit pouvoir accomplir et quels comportements sont restreints, est certainement le moyen le plus rapide de mettre en place du nouveau code. Si tout se passe parfaitement, l'application utilisera ces autorisations pour accomplir sa tâche. Le danger est qu'un pirate informatique découvre ce processus et compromette cet utilisateur. Bien que l'utilisateur ait été créé pour une fonction spécifique, s'il est compromis, il peut permettre à un attaquant de mettre en péril d'autres applications, des données ou même le réseau.

Comment les erreurs de configuration de sécurité sont-elles exploitées ?

Pour visualiser le danger, examinons comment une tâche courante est parfois codée dans l'environnement cloud Docker. Supposons qu'un développeur utilise le service Prometheus MySQL Exporter pour collecter des informations à partir d'une base de données. Le moyen le plus simple est d'accorder à l'exportateur l'autorisation d'accéder à la base de données. Le code pourrait donc ressembler à ceci :

FROM mysql:latest
   COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
   USER 999
     CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
       GRANT ALL ON *.* TO exporter@%;
       GRANT SELECT ON performance_schema.* TO exporter@%;

Cela permettrait certainement à l'exportateur d'accomplir sa tâche. Cependant, comme les autorisations ne sont pas définies, l'exportateur a en réalité la capacité de presque tout faire. Évidemment, l'exportateur lui-même n'agirait jamais en dehors de ses comportements programmés. Mais que se passerait-il si un attaquant parvenait à compromettre le service d'exportation ? Dans ce cas, puisqu'il a reçu des autorisations complètes, l'attaquant pourrait effectuer toutes sortes de tâches non autorisées avec le service SQL.

Sécuriser et éliminer les autorisations inappropriées

Ici encore, nous revenons au concept d'infrastructure as code. Si vous intégrez la sécurité dans vos applications dès leur création, le réseau sera toujours dans une bien meilleure position en matière de cybersécurité.

Dans l'exemple Docker ci-dessus, si un développeur souhaite que Prometheus MySQL Exporter puisse interroger une base de données, il peut le faire plus sûrement en définissant ce qu'il est autorisé à accomplir. Un bon exemple serait :

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
   CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
   GRANT PROCESS, REPLICATION CLIENT ON *.* TO exporter@%;
   GRANT SELECT ON performance_schema.* TO exporter@%;

Dans ce cas, l'utilisateur MySQL configuré pour le service Prometheus MySQL Exporter ne dispose que d'autorisations restreintes sur le service MySQL. Plus précisément, seuls les privilèges PROCESS et REPLICATION CLIENT sont autorisés. Cela empêcherait un utilisateur malveillant de tirer parti d'un service Prometheus MySQL Exporter compromis.

Restreindre les autorisations au niveau du code garantit que les utilisateurs et les applications ne disposent que des droits nécessaires à leur tâche. Cela contribue grandement à sécuriser vos réseaux et à adopter l'infrastructure as code.

Consultez les pages du blog Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation. Vous pouvez également essayer notre démonstration de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.