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 des menaces actuelles est le credential stuffing. Si on le présente souvent comme un risque pour les ressources d’entreprise, toute plateforme accessible sur Internet avec identification est vulnérable à la compromission. Les développeurs ne sont ni plus ni moins enclins que les autres professionnels IT à adopter de bonnes pratiques de gestion des mots de passe. La réutilisation des mots de passe est courante, et l’exposition de milliards d’identifiants permet aux attaquants d’exploiter un large éventail de ressources pour tenter de s’introduire dans divers systèmes. Prenez cet article qui illustre parfaitement le constat : « Une enquête menée auprès de 306 professionnels de la sécurité de l’information à la conférence Infosecurity 2018 de Londres par Lastline montre que 45 % d’entre eux commettent l’un des pires péchés en sécurité : la réutilisation des mots de passe entre plusieurs comptes. » Si près de la moitié des professionnels de la sécurité pratiquent la réutilisation, imaginez ce que cela donne pour le reste de la communauté IT, 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.
Lorsque vous avez accès aux systèmes et services qui composent le SDLC, vous pouvez compromettre l’ensemble. Injecter un comportement malveillant ou voler des idées devient simple dès lors que vous pouvez accéder 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 .