Comment intégrer la sécurité en tant que fonctionnalité SaaS : un guide

Dans cet article, je vais vous montrer comment fournir une connectivité plus granulaire et plus sécurisée vers et depuis une plateforme SaaS. Le résultat final est une solution holistique qui ressemble à une extension naturelle de la plate-forme SaaS et est proposée soit comme fonctionnalité pour les plans axés sur l'entreprise, soit comme différenciateur concurrentiel pour tous vos clients. Le temps total requis pour exécuter la démo n’est que de quelques minutes. Je vais également approfondir ce qui se passe dans les coulisses pour expliquer comment la magie opère.

Tout d’abord, permettez-moi d’expliquer pourquoi ce besoin spécifique se pose et de souligner les lacunes des mises en œuvre traditionnelles. Parce que ces anciennes approches ne fonctionnent plus.

Vous devez commencer à considérer la sécurité comme une fonctionnalité. Si vous êtes vice-président de l'ingénierie, si vous êtes chef de produit, propriétaire de produit, consacrez du temps à la sécurité, laissez vos développeurs créer une infrastructure meilleure et plus sécurisée.

— Joel Spolsky , fondateur de Stack Overflow

Les produits qui connaîtront le plus de succès au cours de la décennie à venir seront ceux qui prendront conscience que les approches du statu quo ne suffisent plus. Vous n’avez pas non plus besoin de croire Joel sur parole ; lisez les détails du Private Cloud Compute récemment annoncé par Apple. L’une des entreprises les plus performantes des deux dernières décennies affirme clairement que la sécurité, la confidentialité et la confiance seront des facteurs de différenciation essentiels.

Ils discutent même du fait que l'utilisation actuelle de protocoles tels que TLS ne peut pas fournir les garanties de sécurité et de confidentialité de bout en bout que les clients devraient attendre.

J'ai travaillé sur la connexion de systèmes entre eux il y a de nombreuses années, une tâche à forte intensité de main-d'œuvre au début de ma carrière. Notre entreprise était en pleine croissance et nous patcherions la salle des serveurs du bâtiment actuel avec le système que nous venions d'installer dans le nouveau bâtiment. Le nouveau bureau se trouvait à quelques pâtés de maisons de la rue et nous travaillions avec l'opérateur téléphonique local pour installer une ligne dédiée.

À l’époque, connecter deux réseaux distincts avait une réalité évidente et physiquement tangible.

Nous avons tous quitté cette époque. Aujourd’hui, les piles technologiques modernes sont plus compliquées ; une série d'applications interconnectées réparties à travers le monde, gérées dans le cloud par les meilleures sociétés de produits. Au fil des décennies, nous avons évolué. Aujourd'hui, il est rare que deux entreprises distinctes souhaitent réellement connecter l'ensemble de leurs réseaux : ce sont des applications et des charges de travail spécifiques au sein de chaque réseau qui doivent communiquer.

Pourtant, nous avons continué à utiliser d’anciennes approches pour connecter nos systèmes de manière « sécurisée ».

Le cheminement réel des câbles a été supprimé, mais nous faisons pratiquement la même chose. Ces anciennes approches vous exposent de manière transitive à un nombre incalculable de réseaux, ce qui constitue une énorme surface d’attaque prête à être exploitée.

La nécessité de se connecter à un système privé

Ce que les gens entendent par « cloud » ou « sur site » est devenu flou au cours des décennies précédentes. Pour éviter toute confusion, je vais créer pour nous un scénario hypothétique :

• Plateforme Initech : Il s'agit d'une plateforme SaaS que vous exploitez. Il est élastique et évolutif et hébergé chez l'un des principaux fournisseurs de cloud. Les clients achètent la plateforme pour améliorer leurs processus DevOps, car elle offre une visibilité sur un ensemble de mesures utiles et fournit des commentaires utiles directement dans leurs flux de travail de développement.

• ACME Corp : Il s'agit d'un gros client d'Initech que vous souhaitez accompagner. Ils gèrent de nombreuses infrastructures à divers endroits. Est-ce « sur site » au sens classique du terme, c'est-à-dire dans leur propre centre de données ? Est-ce dans leur propre VPC sur l'un des principaux fournisseurs de cloud ? Cela n'a pas d'importance! Les systèmes clients fonctionnent sur un ou plusieurs réseaux qu'Initech ne contrôle pas, auxquels nous n'avons pas accès et qui ne sont pas directement accessibles depuis l'Internet public.

Engagement proactif dans les flux de travail des développeurs

Lors de la création de la première version de la plate-forme Initech, il y a de nombreux clients potentiels avec lesquels travailler pour prouver l'adéquation du produit au marché. Il s'intégrera aux API publiques des principaux fournisseurs de systèmes de contrôle de version (par exemple, GitHub, GitLab, Bitbucket, etc.), utilisera les commit/webhooks pour réagir aux événements, poussera les résultats dans le flux de travail et tout fonctionnera comme prévu.

C'est formidable alors que le produit est passif et réagit simplement aux événements initiés par quelqu'un chez ACME Corp. De nombreux services souhaitent apporter de la valeur en évaluant les changements externes dans le monde et en étant proactifs dans la conduite d'améliorations pour leurs clients.

Pensez aux nombreux services d'analyse de dépendances ou de sécurité : en cas de nouvelle divulgation de vulnérabilité, ils souhaitent créer une demande d'extraction/fusion sur tous les référentiels concernés le plus rapidement possible. Les services VCS entièrement gérés avec des API publiques fournissent des moyens d'activer cela. Cependant, les versions auto-hébergées de ces produits ne disposent pas d'API accessible au public.

Les clients qui choisissent d'auto-héberger ces systèmes se tournent généralement vers les grandes entreprises. Nous sommes donc désormais confrontés à des décisions difficiles : Initech est-il incapable de vendre son produit à ces clients de grande valeur ? Les clients doivent-ils acheter une version réduite du produit à laquelle manque l’une des fonctionnalités les plus précieuses ? Ou leur demandons-nous de réévaluer certains aspects de leur posture de sécurité et de réseau pour accorder l'accès à Initech ?

Accès aux données privées

Initech doit interroger une base de données pour afficher sa solution de reporting personnalisée. Ce n'est pas un problème propre à Initech, car presque toutes les plateformes de données client (CDP) ou outils de visualisation ont le même problème : les clients ne veulent pas rendre leurs données privées accessibles depuis l'Internet public, elles le seront donc généralement dans un base de données dans un sous-réseau privé.

Les problèmes de nos approches actuelles

Comme je l’ai dit plus tôt, les piles technologiques modernes ont évolué vers une série d’applications interconnectées. Cependant, la façon dont nous connectons ces applications n’a que peu changé par rapport à la façon dont nous connections les réseaux il y a plusieurs décennies. Bien que ces approches soient pratiques et familières, elles n’ont jamais été conçues pour les cas d’utilisation actuels.

Ils tentent plutôt d’apporter les plus petites modifications possibles à la façon dont les choses fonctionnaient auparavant pour essayer de se rapprocher de la façon dont nous avons besoin que les choses fonctionnent aujourd’hui.

Mettre les systèmes sur l'Internet public

L'option de déploiement par défaut pour la plupart des systèmes privés consiste à les localiser dans un réseau privé, avec un sous-réseau privé, sans adresses IP publiques. Il y a de très bonnes raisons à cela ! L'option la plus simple pour qu'Initech se connecte à ce système privé serait de demander à ACME Corp de fournir une adresse IP publique ou un nom d'hôte accessible depuis Internet.

C'est mauvais.

Toutes les bonnes raisons de placer initialement un système dans un réseau privé déconnecté du monde disparaissent immédiatement. Ce système est désormais accessible sur l’ensemble de l’Internet public, permettant à des milliers de pirates informatiques potentiels d’essayer constamment de se frayer un chemin par force brute dans le système ou simplement de le faire un DoS. Il vous suffit d'une fuite d'informations d'identification, de CVE ou d'un autre problème pour en devenir propriétaire.

Proxy inversés

Une autre approche consiste à placer un proxy inverse devant le système. Je ne parle pas seulement de quelque chose comme nginx et HA Proxy ; il existe toute une catégorie de services hébergés ou gérés qui correspondent également à cette description.

Cela présente l'avantage qu'ACME Corp ne met plus de système privé directement sur l'Internet public. Le proxy inverse ajoute également la possibilité de limiter le débit ou d'affiner les restrictions d'accès pour atténuer les attaques DoS potentielles. Il s’agit d’une amélioration de la défense en profondeur, mais ACME Corp permet toujours à l’ensemble de l’Internet public d’atteindre et de tenter d’attaquer le proxy.

S'il est compromis, il fera ce que fait un proxy : laisser passer le trafic vers la destination prévue.

Listes IP autorisées

Une amélioration progressive consiste pour Initech à fournir une liste d'adresses IP à partir desquelles ils enverront des demandes et à laisser ACME Corp gérer son pare-feu et ses règles de routage pour autoriser uniquement les demandes provenant de ces adresses IP. Ce n’est cependant pas une grande amélioration.

Chez Initech, vous ne voudrez pas avoir un lien étroit entre vos instances d'application actuelles et les adresses IP ; vous aurez besoin de la flexibilité nécessaire pour pouvoir faire évoluer l'infrastructure selon vos besoins sans avoir à informer constamment les clients des nouvelles adresses IP.

Ainsi, les adresses IP appartiendront très probablement à une passerelle NAT ou à un serveur proxy. ACME Corp pourrait supposer que le verrouillage de l'accès à seulement une ou deux adresses IP sources signifie que seules une ou deux machines distantes ont accès à leur réseau.

La réalité est que tout ce qui sur le réseau distant peut envoyer une requête via la passerelle NAT ou le proxy aura désormais également accès au réseau ACME Corp. Cela n'autorise pas l'accès d'une seule application ou d'une seule machine ; vous avez autorisé un réseau distant entier.

Ce qui est encore plus préoccupant, c'est que les adresses IP sources sont trivialement usurpées . Un attaquant potentiel serait capable de créer une requête bien formée, d'usurper l'adresse source et d'envoyer des données ou des instructions dans le réseau ACME Corp. Les fournisseurs SaaS, y compris Initech, doivent également inévitablement documenter la liste des adresses IP actuelles afin qu'il existe une liste prête à l'emploi d'adresses IP à essayer d'usurper l'identité.

Plus votre approche du filtrage IP est sophistiquée, plus un attaquant doit être sophistiqué pour la compromettre, mais aucune d'entre elles n'est parfaite. J'ai entendu des gens affirmer dans le passé que l'usurpation d'adresse IP ne concernait en réalité que les attaques DDoS, car dans la plupart des cas, l'attaquant ne peut pas recevoir de réponse et ne peut donc rien faire d'utile.

Pensez aux systèmes que nous connectons : dans quelle mesure êtes-vous sûr qu'il n'existe aucun appel d'API de type "déclencher et oublier" qui ne créera pas, ne mettra pas à jour ou ne détruira pas consciencieusement des données précieuses ? Une bonne sécurité ne consiste pas seulement à empêcher l’exposition des données, il s’agit également de les protéger et de garantir leur intégrité.

Si vous êtes une cible précieuse, telle qu'une grande institution financière, les attaquants sont motivés pour utiliser des approches comme celle-ci pour lancer des attaques MitM et intercepter les flux de communication . Si vos clients et prospects sont des cibles précieuses, cela fait de vous également une cible précieuse.

Réseaux privés virtuels (VPN)

Les VPN sont une solution courante dans de nombreuses entreprises pour permettre aux employés de se connecter au « réseau d'entreprise » lorsqu'ils sont en dehors du bureau. Ils sont également utilisés pour permettre à d’autres systèmes de se connecter à un réseau existant.

Le cas d'utilisation dont nous parlons ici est différent. Il s'agit de permettre à deux entreprises distinctes, un produit SaaS et leur(s) client(s), de pouvoir communiquer entre elles.

Dans la plupart de ces cas, il n'y a qu'un seul système à chaque extrémité de la connexion qui devrait pouvoir communiquer entre eux. Au lieu de cela, nous recherchons un outil conçu pour connecter des réseaux entiers. C'est comme exécuter un patch virtuel depuis le routeur d'une entreprise vers le routeur d'une autre.

Si je vous demandais d'en faire la version physique, de brancher un câble de votre environnement de production directement à l'environnement de production d'une autre entreprise, vous y accorderiez probablement une pause. Beaucoup de pauses. Et pour une bonne raison. Mais les VPN sont « virtuels » et « privés » et si simples (par rapport à l’utilisation d’un câble) et si omniprésents que nous n’y prêtons pas autant d’attention.

Si tout ce que vous aviez à faire était de connecter un élément dans chaque réseau, vous avez utilisé un instrument très brutal pour ce qui était censé être une tâche très précise.

Vous pouvez toujours effectuer la tâche précise en utilisant un VPN, mais il existe des couches de contrôles au niveau du réseau et des règles de routage dont vous devez vous assurer qu'elles sont en place pour fermer toutes les portes à celle que vous souhaitez ouvrir dans chaque réseau. C'est un autre exemple de la façon dont nous disposons d'outils et d'approches qui conviennent parfaitement à ce pour quoi ils ont été conçus, mais nous progressons progressivement dans la façon dont nous les utilisons pour les forcer à travailler avec nos besoins évolués.

Faire cela en toute sécurité signifie ajouter plus de complexité et espérer que nous obtenons tous les détails de toutes ces couches correctement, à tout moment. Se tromper comporte des risques d’accès transitif au-delà des intentions initiales.

Vous ne pouvez pas faire confiance au réseau

Et si je vous disais que, quels que soient le temps, les personnes et l'argent que vous investissez dans votre programme de sécurité, votre réseau est presque certainement exposé à une faille de sécurité facilement exploitable ? …

les données du secteur montrent que moins de 1 % des plus grandes entreprises mondiales n'ont encore pris aucune mesure pour protéger leur réseau contre cette menace nouvelle et émergente…

L’histoire nous a appris que la bonne chose à faire doit être la chose la plus facile à faire. Ceci est particulièrement critique pour les développeurs de logiciels et pour la protection contre les composants intentionnellement malveillants. Cette lente courbe d’adoption des technologies de sécurité… a effectivement permis aux mauvais acteurs de voir le potentiel, d’innover et de stimuler la croissance spectaculaire de la cybercriminalité.

— Mitchell Johnson , Sonatype

Le problème avec chacune de ces approches est que pour supposer qu'elles sont sécurisées, il faut de nombreuses hypothèses supplémentaires : que personne sur Internet ne tentera de vous compromettre, que vous pouvez faire confiance à l'adresse IP source des requêtes, que le réseau distant est uniquement composé de bons acteurs. , que ces hypothèses continueront d'être vraies maintenant et indéfiniment dans le futur… et que toutes ces hypothèses sont également vraies pour chaque réseau auquel vous vous êtes connecté, et pour tout réseau auquel vous vous êtes connecté, et pour tout réseau…

Jetez un œil à ce à quoi cela pourrait ressembler du point de vue d'ACME Corp :

Il ne s’agit pas seulement de deux réseaux et de deux entreprises désormais connectées entre elles ; ce sont de nombreux réseaux. Chaque fournisseur SaaS disposera de son propre ensemble de services, ce qui multiplie encore davantage ce chiffre. Non seulement vous ne pouvez pas faire confiance au réseau, mais vous ne pouvez pas non plus faire confiance à quelqu'un d'autre. Tout participant à cette image n’est qu’une mauvaise configuration du réseau ou une dépendance compromise qui l’empêche de transmettre ce risque à travers le(s) réseau(s).

Et cette image est l’exemple le plus agrandi d’une fractale de ce problème ! Effectuez un zoom arrière et chaque fournisseur est connecté à son propre ensemble de clients, à ses propres fournisseurs, à ses propres clients... la surface de risque augmente de façon exponentielle.

Alors, résolvons-le !

Nous pouvons intégrer la sécurité en tant que fonctionnalité dans notre produit en quelques minutes ! Nous élèverons la barre de sécurité en fournissant une solution plus ciblée et plus granulaire. Nous allons également cesser de rejeter les problèmes sur des clients comme ACME Corp en leur demandant d'apporter des modifications au niveau du réseau.

Au lieu de cela, nous allons faire passer la connectivité sécurisée au niveau de l'application et offrir une expérience produit holistique en étendant la plate-forme Initech aux endroits spécifiques où elle doit être.

L'exemple ici va expliquer comment Initech Platform peut établir une connexion à un serveur GitHub Enterprise auto-hébergé et géré par ACME Corp. Le résultat final ressemblera à :

Cela ne prend que quelques minutes pour faire tourner toutes les pièces requises ! Pour savoir comment procéder, jetez un œil à notre visite guidée du code pour construire les bases d'un agent auto-hébergé .