La sécurisation des applications commence par la sécurisation du pipeline SDLC
Les pratiques de développement modernes automatisent de plus en plus le cycle de vie du développement. De l'IDE aux référentiels de code, de la création et de l'analyse automatisées à la mise en production, les outils sont reliés entre eux pour former un pipeline de livraison continue.
Les référentiels servent à la fois de lieux de stockage de code et de lieu de lancement des événements qui composent le processus de livraison. Lorsque le code est validé, il peut exécuter une analyse de sécurité. Lorsqu'une configuration est modifiée, elle peut être automatiquement transférée vers l'infrastructure appropriée pour un déploiement immédiat.
Ces outils accélèrent le processus de développement, de livraison et de déploiement, et ils sont de plus en plus « dans le cloud ». Ceux qui résident sur site sont souvent accessibles via Internet pour prendre en charge une communauté croissante de développeurs distants. Même si la plupart des organisations sont suffisamment averties en matière de sécurité pour exiger un accès certifié aux référentiels, elles ne sécurisent pas nécessairement cet accès contre les menaces modernes.
L’une de ces menaces modernes est le « credential stuffing » . Généralement présenté comme un risque pour les ressources de l’entreprise, la réalité est que tout système d’identification accessible via Internet risque d’être compromis. Les développeurs ne sont ni plus ni moins susceptibles que tout autre professionnel de l’informatique d’appliquer des pratiques de mots de passe sécurisées. La réutilisation des mots de passe sur Internet est courante et l’exposition de milliards d’identifiants permet aux attaquants d’exploiter un riche ensemble de ressources dans leurs efforts pour accéder à une variété de systèmes. Considérez cet article exposant cet aphorisme : « Une enquête menée par Lastline auprès de 306 professionnels de la sécurité informatique lors de la conférence Infosecurity 2018 de Londres a montré que 45 % d'entre eux commettent l'un des plus grands péchés capitaux en matière de sécurité : la réutilisation des mots de passe sur plusieurs comptes. » Si près de la moitié des professionnels de la sécurité réutilisent des mots de passe, imaginez à quoi ressemble le profil du reste de la communauté informatique, y compris les développeurs.
D'un point de vue existentiel, la tristement célèbre violation de données aux États-Unis... L'Office of Personnel Management (OPM), qui a débuté en 2014, a été perpétrée par des attaquants qui ont réussi à compromettre les informations d'identification d'un utilisateur privilégié. Une fois que les attaquants ont réussi à voler ces informations d'identification, ils ont pu accéder non seulement aux informations sensibles contenues dans les serveurs de l'OPM, mais ils ont également pu se déplacer latéralement dans les serveurs et l'infrastructure des États-Unis. Département de l'Intérieur où ils ont également causé des ravages.
L’accès aux systèmes et aux services qui composent le SDLC permet aux attaquants d’empoisonner le puits, en quelque sorte. L'injection de comportements malveillants ou le vol d'idées est facilement accompli si l'on a accès au code source.
Pour lutter contre cette menace, les organisations devraient envisager d’étendre la notion d’architecture zero-trust aux outils de leur pipeline de développement logiciel. De l'IDE aux consoles de gestion cloud en passant par les référentiels de code, l'utilisation de l'accès utilisateur privilégié peut renforcer les pratiques de sécurité basées sur MFA/CAC.
Accès utilisateur privilégié et pipeline SDLC
L'accès utilisateur privilégié (PUA) est fondamentalement une fédération sans SAML ni l'obligation pour les applications de prendre en charge une sorte de méthode d'authentification exotique. Il est capable d'étendre les principes de confiance zéro aux applications héritées et de prendre en charge les applications Web modernes.
Cette solution est basée sur la capacité de F5 Access Policy Manager (APM) à agir comme un proxy d'informations d'identification ainsi que sur sa capacité à généraliser automatiquement les informations d'identification éphémères. En un mot, les utilisateurs sont authentifiés par rapport à un magasin d’informations d’identification d’entreprise (contrôleur de domaine, LDAP), puis APM génère des informations d’identification éphémères qui peuvent être utilisées pour se connecter au système protégé. Dans le cas du pipeline de développement, cela peut être le référentiel de code tel que Bitbucket , GitHub ou GitLab . Cette approche permet de contrôler plus étroitement l'accès au référentiel sans introduire une tonne de frais généraux de processus pour le développeur.
- L'utilisateur fournit des informations d'identification à BIG-IP
- BIG-IP valide les informations d'identification des utilisateurs par rapport à un service d'annuaire IaaS ou sur site
- BIG-IP fournit des informations d'identification éphémères à l'utilisateur authentifié
- Informations d'identification éphémères de l'utilisateur via IDE ou navigateur vers le référentiel
- Le référentiel transmet le nom d'utilisateur et les informations d'identification éphémères à BIG-IP pour validation
- BIG-IP renvoie la validation
- L'utilisateur est connecté avec succès au référentiel
Les données sensibles doivent inclure du code. Cela signifie que, comme pour les données, l'accès au code doit être protégé. Le code est le cœur d’une entreprise numérique et le pipeline de livraison est de plus en plus considéré comme un vecteur d’attaque. En mettant en place un modèle d'accès utilisateur privilégié, vous pouvez être plus sûr que les informations d'identification (et l'utilisateur qui les sous-tend) sont légitimes.
Vous pouvez en apprendre plus sur F5 APM ici .