Les codeurs conquièrent l'infrastructure de sécurité en tant que série de codes : mauvaise configuration de la sécurité - autorisations inappropriées

De nos jours, les menaces à la cybersécurité sont omniprésentes et incessantes. La situation s'est tellement aggravée qu'il est devenu presque impossible d'essayer de les suivre après le déploiement des programmes. Au lieu de cela, les organisations avisées adoptent le concept d'infrastructure en tant que code, selon lequel les développeurs contribuent à la création d'applications sécurisées pendant leur création. Cette série vise à vous préparer à la sécurité, afin que vous puissiez comprendre les étapes que vous pouvez suivre en tant que développeur pour commencer à déployer une infrastructure sécurisée sous forme de code dans votre propre organisation.

Les erreurs de configuration de sécurité, en particulier celles liées à des autorisations inappropriées, se produisent le plus souvent chaque fois qu'un développeur crée un nouvel utilisateur ou autorise une application en tant qu'outil afin d'accomplir une tâche. Par exemple, cela pourrait être fait pour collecter des informations à partir d'une base de données. Mais si les autorisations du nouvel utilisateur sont trop élevées, ou si elles ne sont pas configurées par défaut pour la tâche en cours, cela peut introduire une grave vulnérabilité 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 aux autorisations inappropriées :

Comment t'es-tu débrouillé ? Allons un peu plus loin :

Accorder à un utilisateur ou à une application des autorisations complètes, ou simplement ne jamais se donner la peine de définir ce que le nouvel utilisateur doit être capable d'accomplir et quels comportements sont restreints, est certainement le moyen le plus rapide de mettre en place un nouveau code. Et si tout se passe parfaitement bien, l'application utilisera ces autorisations pour accomplir la tâche qui lui est assignée. Le danger est qu'un pirate informatique découvre ce processus et compromette ensuite cet utilisateur. Même si l'utilisateur a été créé pour exécuter une fonction spécifique pour une application particulière, s'il est compromis, il peut permettre à un attaquant de mettre en danger 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, voyons 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 d'y parvenir est d'autoriser l'exportateur à accéder à la base de données. Le code pourrait donc être quelque chose comme :

DEPUIS mysql:latest
COPIE. /scripts/create_users.sh /docker-entrypoint-initdb.d/
UTILISATEUR 999
CRÉER UN UTILISATEUR exportateur@% IDENTIFIÉ PAR $EXPORTER_PASSWORD ;
ACCORDEZ TOUT SUR *.* À exportateur@% ;
ACCORDEZ SELECT ON performance_schema.* À exporter@% ;

Cela permettrait certainement à l'exportateur d'accomplir sa tâche. Cependant, comme les autorisations ne sont pas définies, l'exportateur est en fait capable de faire presque tout. De toute évidence, 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 à l'exportateur ? Dans ce cas, étant donné qu'il disposait de toutes les autorisations, l'attaquant pouvait effectuer toutes sortes de tâches non autorisées avec le service SQL.

Sécurisation et élimination des autorisations inappropriées

Ici encore, nous abordons le concept d'infrastructure en tant que code. Si vous codez la sécurité de vos applications au fur et à mesure de leur création, le réseau sera toujours sur une bien meilleure base globale 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 de manière plus sûre en définissant ce qu'il doit être autorisé à accomplir. Voici un bon exemple de cela :

DEPUIS mysql:latest
COPIE. /scripts/create_users.sh /docker-entrypoint-initdb.d/
UTILISATEUR 999
CRÉER UN UTILISATEUR exportateur@% IDENTIFIÉ PAR $EXPORTER_PASSWORD ;
PROCESSUS D'OCTROI, CLIENT DE RÉPLICATION SUR *.* VERS exportateur@% ;
ACCORDEZ SELECT ON performance_schema.* À 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 d'exportation Prometheus MySQL compromis.

La restriction des autorisations au niveau du code peut garantir que les utilisateurs et les applications ne disposent que de suffisamment d'autorisations pour la tâche en cours. Et cela peut grandement contribuer à sécuriser vos réseaux et à adopter le concept d'infrastructure en tant que code.

Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez notre vitrine de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.