paint-brush
So integrieren Sie Sicherheit als SaaS-Funktion: Eine Anleitungvon@ockam
3,860 Lesungen
3,860 Lesungen

So integrieren Sie Sicherheit als SaaS-Funktion: Eine Anleitung

von Ockam10m2024/08/07
Read on Terminal Reader

Zu lang; Lesen

In diesem Beitrag zeige ich Ihnen, wie Sie eine detailliertere und sicherere Verbindung zu und von einer SaaS-Plattform bereitstellen. Ich werde auch tief in die Vorgänge hinter den Kulissen eintauchen, um zu erklären, wie die Magie funktioniert. Das Endergebnis ist eine ganzheitliche Lösung, die wie eine natürliche Erweiterung der SaaS-Plattform aussieht und sich auch so anfühlt.
featured image - So integrieren Sie Sicherheit als SaaS-Funktion: Eine Anleitung
Ockam HackerNoon profile picture
0-item
1-item
2-item

In diesem Beitrag zeige ich Ihnen, wie Sie eine detailliertere und sicherere Verbindung zu und von einer SaaS-Plattform bereitstellen. Das Endergebnis ist eine ganzheitliche Lösung, die wie eine natürliche Erweiterung der SaaS-Plattform aussieht und sich auch so anfühlt und entweder als Funktion für unternehmensorientierte Pläne oder als Wettbewerbsvorteil für alle Ihre Kunden angeboten wird. Die gesamte zum Ausführen der Demo erforderliche Zeit beträgt nur wenige Minuten. Ich werde auch tief in das eintauchen, was hinter den Kulissen passiert, um zu erklären, wie die Magie funktioniert.


Lassen Sie mich zunächst einige Hintergrundinformationen dazu geben, warum dieser spezielle Bedarf besteht, und die Mängel herkömmlicher Implementierungen hervorheben. Denn diese alten Ansätze funktionieren nicht mehr.


Sie müssen anfangen, Sicherheit als Funktion zu betrachten. Wenn Sie Vizepräsident für Technik, Produktmanager oder Produktbesitzer sind, widmen Sie der Sicherheit Zeit und lassen Sie Ihre Entwickler eine bessere und sicherere Infrastruktur erstellen.

Joel Spolsky , Gründer von Stack Overflow


Die erfolgreichsten Produkte des kommenden Jahrzehnts werden diejenigen sein, die erkennen, dass die Status-Quo-Ansätze nicht mehr ausreichen. Sie müssen sich auch nicht auf Joels Wort verlassen; lesen Sie die Details des kürzlich angekündigten Private Cloud Compute von Apple. Eines der erfolgreichsten Unternehmen der letzten zwei Jahrzehnte macht klar, dass Sicherheit, Datenschutz und Vertrauen ein zentrales Differenzierungsmerkmal sein werden.


Sie diskutieren sogar, dass die aktuelle Verwendung von Protokollen wie TLS nicht die durchgängige Sicherheit und Datenschutzgarantien bieten kann, die Kunden erwarten sollten.


Ich habe vor vielen Jahren daran gearbeitet, Systeme miteinander zu verbinden, eine arbeitsintensive Aufgabe in den Anfangsphasen meiner Karriere. Unser Unternehmen wuchs und wir verbanden den Serverraum im bestehenden Gebäude mit dem System, das wir gerade im neuen Gebäude installiert hatten. Das neue Büro war ein paar Blocks die Straße hinunter und wir arbeiteten mit dem örtlichen Telekommunikationsunternehmen zusammen, um eine Standleitung zu installieren.


Damals war die Verbindung zweier getrennter Netzwerke eine offensichtliche und physisch greifbare Realität.


Diese Zeiten haben sich geändert. Heute sind moderne Tech-Stacks komplexer: eine Reihe miteinander verbundener Apps, die über den ganzen Globus verteilt sind und von den besten Produktunternehmen in der Cloud betrieben werden. Wir haben uns über Jahrzehnte weiterentwickelt. Heute ist es selten, dass zwei verschiedene Unternehmen ihre gesamten Netzwerke miteinander verbinden wollen – es sind die spezifischen Apps und Workloads innerhalb jedes Netzwerks, die miteinander kommunizieren müssen.


Dennoch verwenden wir weiterhin alte Ansätze, um unsere Systeme „sicher“ zu verbinden.


Das eigentliche Verlegen von Kabeln wurde abstrahiert, aber wir tun praktisch dasselbe. Diese alten Ansätze setzen Sie vorübergehend einer unzähligen Anzahl von Netzwerken aus, was eine enorme Angriffsfläche darstellt, die nur darauf wartet, ausgenutzt zu werden.

Die Notwendigkeit der Verbindung mit einem privaten System

Was die Leute meinen, wenn sie „Cloud“ oder „On-Prem“ sagen, ist in den letzten Jahrzehnten immer unklarer geworden. Um Verwirrung zu vermeiden, werde ich ein hypothetisches Szenario für uns entwerfen:


  • Initech-Plattform: Dies ist eine SaaS-Plattform, die Sie betreiben. Sie ist flexibel und skalierbar und wird von einem der großen Cloud-Anbieter gehostet. Kunden kaufen die Plattform, um ihre DevOps-Prozesse zu verbessern, da sie Einblick in eine Reihe nützlicher Metriken bietet und nützliches Feedback direkt in ihre Entwicklungs-Workflows einspeist.


  • ACME Corp: Dies ist ein großer Kunde von Initech, den Sie unterstützen möchten. Sie betreiben eine große Infrastruktur an verschiedenen Standorten. Ist sie „vor Ort“ im klassischen Sinne, also in ihrem eigenen Rechenzentrum? Befindet sie sich in ihrem eigenen VPC bei einem der großen Cloud-Anbieter? Das spielt keine Rolle! Kundensysteme laufen in einem oder mehreren Netzwerken, die Initech nicht kontrolliert, auf die wir keinen Zugriff haben und die nicht direkt über das öffentliche Internet zugänglich sind.

Proaktive Einbindung in Entwickler-Workflows

Beim Erstellen der ersten Version der Initech-Plattform gibt es viele potenzielle Kunden, mit denen wir zusammenarbeiten können, um die Markttauglichkeit des Produkts zu beweisen. Es wird in die öffentlichen APIs der wichtigsten Anbieter von Versionskontrollsystemen (z. B. GitHub, GitLab, Bitbucket usw.) integriert, verwendet Commit/Webhooks, um auf Ereignisse zu reagieren, Ergebnisse in den Workflow zu übertragen und alles funktioniert wie erwartet.


Das ist großartig, solange das Produkt passiv ist und lediglich auf Ereignisse reagiert, die von jemandem bei ACME Corp. initiiert werden. Viele Dienste möchten einen Mehrwert bieten, indem sie externe Änderungen in der Welt bewerten und proaktiv Verbesserungen für ihre Kunden vorantreiben.


Denken Sie an die vielen Abhängigkeits- oder Sicherheitsscan-Dienste – wenn eine neue Sicherheitslücke bekannt wird, möchten sie so schnell wie möglich eine Pull-/Merge-Anfrage für alle betroffenen Repositories erstellen. Die vollständig verwalteten VCS-Dienste mit öffentlichen APIs bieten Möglichkeiten, dies zu ermöglichen. Die selbst gehosteten Versionen dieser Produkte verfügen jedoch nicht über eine öffentlich zugängliche API.


Die Kunden, die sich für das Self-Hosting dieser Systeme entscheiden, sind in der Regel große Unternehmen. Daher stehen wir nun vor einigen schwierigen Entscheidungen: Kann Initech sein Produkt nicht an diese anspruchsvollen Kunden verkaufen? Müssen die Kunden eine abgespeckte Version des Produkts kaufen, bei der eine der wertvollsten Funktionen fehlt? Oder müssen wir sie bitten, einige Aspekte ihrer Sicherheits- und Netzwerksituation zu überdenken, um Initech Zugriff zu gewähren?

Zugriff auf private Daten

Initech muss eine Datenbank abfragen, um seine benutzerdefinierte Berichtslösung anzuzeigen. Dies ist kein Problem, das nur Initech betrifft, da fast jede Customer Data Platform (CDP) oder jedes Visualisierungstool das gleiche Problem hat: Kunden möchten ihre privaten Daten nicht über das öffentliche Internet zugänglich machen, daher befinden sie sich normalerweise in einer Datenbank in einem privaten Subnetz.

Die Probleme unserer aktuellen Ansätze

Wie ich bereits sagte, haben sich moderne Tech-Stacks zu einer Reihe miteinander verbundener Apps entwickelt. Die Art und Weise, wie wir diese Apps verbinden, hat sich jedoch kaum verändert im Vergleich zu der Art und Weise, wie wir vor Jahrzehnten Netzwerke miteinander verbunden haben. Diese Ansätze sind zwar bequem und vertraut, wurden jedoch nie für die Anwendungsfälle entwickelt, die wir heute haben.


Sie versuchen vielmehr, die bisherige Funktionsweise so wenig wie möglich zu verändern, um sie der Funktionsweise anzunähern, die wir heute benötigen.

Systeme ins öffentliche Internet stellen

Die Standardbereitstellungsoption für die meisten privaten Systeme besteht darin, sie in einem privaten Netzwerk mit einem privaten Subnetz ohne öffentliche IP-Adressen zu platzieren. Dafür gibt es sehr gute Gründe! Die einfachste Möglichkeit für Initech, eine Verbindung zu diesem privaten System herzustellen, besteht darin, ACME Corp zu bitten, eine öffentliche IP-Adresse oder einen Hostnamen bereitzustellen, auf den über das Internet zugegriffen werden kann.


Das ist schlecht.


Alle guten Gründe, ein System zunächst in einem privaten, von der Außenwelt abgekoppelten Netzwerk zu platzieren, sind damit hinfällig. Dieses System ist nun über das gesamte öffentliche Internet erreichbar, sodass Tausende von Möchtegern-Hackern ständig versuchen können, sich mit Brute-Force-Angriffen Zugang zum System zu verschaffen oder es einfach mit einem DoS-Angriff anzugreifen. Sie sind nur ein einziges durchgesickertes Anmeldeinformations-, CVE- oder anderes Problem davon entfernt, erwischt zu werden.


Reverse-Proxys

Ein anderer Ansatz besteht darin, einen Reverse-Proxy vor das System zu setzen. Ich spreche hier nicht nur von etwas wie nginx und HA Proxy; es gibt eine ganze Kategorie gehosteter oder verwalteter Dienste, auf die diese Beschreibung ebenfalls zutrifft.


Dies hat den Vorteil, dass ACME Corp kein privates System mehr direkt ins öffentliche Internet stellt. Der Reverse-Proxy bietet außerdem die Möglichkeit, die Zugriffsrate zu begrenzen oder zu optimieren, um potenzielle DoS-Angriffe abzuschwächen. Dies ist eine umfassende Verbesserung der Verteidigung, aber ACME Corp lässt immer noch zu, dass das gesamte öffentliche Internet den Proxy erreicht und versucht, ihn anzugreifen.


Wenn es kompromittiert wird, verhält es sich wie ein Proxy: Es lässt den Datenverkehr bis zum beabsichtigten Ziel durch.


IP-Zulassungslisten

Eine schrittweise Verbesserung besteht darin, dass Initech eine Liste der IP-Adressen bereitstellt, von denen aus Anfragen gesendet werden, und dass ACME Corp seine Firewall- und Routing-Regeln so verwaltet, dass nur Anfragen von diesen IP-Adressen zugelassen werden. Dies ist jedoch keine große Verbesserung.



Bei Initech möchten Sie keine enge Kopplung an Ihre aktuellen App-Instanzen und die IP-Adressen haben. Sie möchten die Flexibilität, die Infrastruktur nach Bedarf skalieren zu können, ohne die Kunden ständig über neue IP-Adressen informieren zu müssen.


Die IP-Adressen gehören also höchstwahrscheinlich zu einem NAT-Gateway oder Proxy-Server. ACME Corp könnte davon ausgehen, dass die Beschränkung des Zugriffs auf nur eine oder zwei Quell-IP-Adressen bedeutet, dass nur ein oder zwei Remote-Computer Zugriff auf ihr Netzwerk haben.


Tatsächlich wird jedem im Remote-Netzwerk, der eine Anfrage über das NAT-Gateway oder den Proxy senden kann, nun auch Zugriff auf das ACME Corp-Netzwerk gewährt. Damit wird nicht einer einzelnen App oder Maschine der Zugang gewährt, sondern einem ganzen Remote-Netzwerk.


Noch besorgniserregender ist jedoch, dass IP-Quelladressen einfach gefälscht werden. Ein potenzieller Angreifer könnte eine wohlgeformte Anfrage erstellen, die Quelladresse fälschen und Daten oder Anweisungen an das Netzwerk von ACME Corp senden. SaaS-Anbieter, darunter auch Initech, müssen außerdem zwangsläufig die Liste der aktuellen IP-Adressen dokumentieren, sodass eine fertige Liste von IPs vorhanden ist, die man zu imitieren versuchen kann.


Je ausgefeilter Ihr IP-Filteransatz ist, desto ausgefeilter muss ein Angreifer vorgehen, um ihn zu kompromittieren. Aber keiner dieser Ansätze ist perfekt. Ich habe in der Vergangenheit Leute behaupten hören, dass IP-Spoofing eigentlich nur für DDoS-Angriffe geeignet ist, weil der Angreifer in den meisten Fällen die Antwort nicht empfangen und daher nichts Sinnvolles tun kann.


Denken Sie an die Systeme, die wir verbinden – wie sicher sind Sie, dass es keine Fire-and-Forget-API-Aufrufe gibt, die nicht automatisch wertvolle Daten erstellen/aktualisieren/zerstören? Gute Sicherheit bedeutet mehr als nur die Offenlegung von Daten zu verhindern. Es geht auch darum, sie zu schützen und ihre Integrität zu gewährleisten.


Wenn Sie ein wertvolles Ziel sind, wie z. B. ein großes Finanzinstitut, sind Angreifer motiviert, solche Ansätze zu verwenden, um MitM-Angriffe zu starten und Kommunikationsflüsse abzufangen . Wenn Ihre Kunden und Interessenten wertvolle Ziele sind, sind Sie auch ein wertvolles Ziel.

Virtuelle private Netzwerke (VPNs)

VPNs sind in vielen Unternehmen eine gängige Lösung, um Mitarbeitern auch außerhalb des Büros den Zugriff auf das „Unternehmensnetzwerk“ zu ermöglichen. Sie werden auch verwendet, um anderen Systemen den Zugriff auf ein bestehendes Netzwerk zu ermöglichen.


Der Anwendungsfall, über den wir hier sprechen, ist anders. Es geht darum, zwei verschiedenen Unternehmen, einem SaaS-Produkt und ihren Kunden, die Möglichkeit zu geben, miteinander zu kommunizieren.


In vielen dieser Fälle gibt es an jedem Ende der Verbindung nur ein System, das miteinander kommunizieren kann. Stattdessen greifen wir zu einem Tool, das ganze Netzwerke miteinander verbindet. Das ist, als würde man ein virtuelles Patchkabel vom Router eines Unternehmens zum Router eines anderen Unternehmens verlegen.


Wenn ich Sie bitten würde, die physische Version davon durchzuführen, also ein Kabel von Ihrer Produktionsumgebung direkt in die Produktionsumgebung eines anderen Unternehmens zu stecken, würden Sie wahrscheinlich zögern. Sehr zögern. Und das aus gutem Grund. Aber VPNs sind „virtuell“ und „privat“ und so einfach (im Vergleich zum Verlegen eines Kabels) und so allgegenwärtig, dass wir nicht so viel darüber nachdenken.


Wenn Sie lediglich eine Sache in jedem Netzwerk verbinden müssten, hätten Sie für eine Aufgabe, die eigentlich sehr präzise sein sollte, ein sehr stumpfes Instrument verwendet.


Sie können diese Aufgabe auch mit einem VPN erledigen, aber es gibt mehrere Ebenen von Netzwerkkontrollen und Routingregeln, die Sie sicherstellen müssen, damit alle Türen geschlossen werden und nur die geöffnet bleiben, die Sie in jedem Netzwerk öffnen möchten. Dies ist ein weiteres Beispiel dafür, dass wir über Tools und Ansätze verfügen, die für ihren Zweck hervorragend geeignet sind, aber wir machen schrittweise Fortschritte bei ihrer Nutzung, um sie an unsere weiterentwickelten Anforderungen anzupassen.


Um dies auf sichere Weise zu tun, müssen wir die Komplexität erhöhen und hoffen, dass wir alle Details in allen diesen Schichten immer richtig darstellen. Wenn wir es falsch machen, besteht das Risiko eines transitiven Zugriffs, der über die ursprünglichen Absichten hinausgeht.


Sie können dem Netzwerk nicht vertrauen

Was wäre, wenn ich Ihnen sagen würde, dass Ihr Netzwerk mit ziemlicher Sicherheit einer leicht auszunutzenden Sicherheitslücke ausgesetzt ist, unabhängig davon, wie viel Zeit, Personal und Geld Sie in Ihr Sicherheitsprogramm investieren? …


Branchendaten zeigen, dass weniger als 1 % der weltweit größten Unternehmen bisher keine Schritte unternommen haben, um ihr Netzwerk vor dieser neuen und aufkommenden Bedrohung zu schützen …


Die Geschichte hat uns gelehrt, dass das Richtige das Einfachste sein muss. Dies ist besonders wichtig bei Softwareentwicklern und beim Schutz vor absichtlich bösartigen Komponenten. Diese langsame Akzeptanzkurve für Sicherheitstechnologie … ermöglichte es böswilligen Akteuren, das Potenzial zu erkennen, Innovationen zu entwickeln und das spektakuläre Wachstum der Cyberkriminalität voranzutreiben.


Mitchell Johnson , Sonatype


Das Problem bei jedem dieser Ansätze besteht darin, dass für die Annahme seiner Sicherheit viele zusätzliche Annahmen erforderlich sind: dass niemand im Internet versuchen wird, Sie zu kompromittieren, dass Sie der Quell-IP der Anfragen vertrauen können, dass das Remote-Netzwerk ausschließlich aus guten Akteuren besteht, dass diese Annahmen sowohl jetzt als auch auf unbestimmte Zeit in der Zukunft gelten werden … und dass alle diese Annahmen auch für jedes Netzwerk gelten, mit dem Sie verbunden sind, und für jedes Netzwerk, mit dem sie verbunden sind, und für jedes Netzwerk …


Sehen Sie sich an, wie dies aus der Sicht von ACME Corp aussehen könnte:



Es sind nicht nur zwei Netzwerke und zwei Unternehmen, die jetzt miteinander verbunden sind; es sind viele Netzwerke. Jeder SaaS-Anbieter hat seine eigenen Dienste, die er verwendet, was dies noch vervielfacht. Sie können nicht nur dem Netzwerk nicht vertrauen, Sie können auch keinem anderen Netzwerk vertrauen. Jeder Teilnehmer in diesem Bild ist nur eine Netzwerkfehlkonfiguration oder eine beeinträchtigte Abhängigkeit davon entfernt, dieses Risiko über das/die Netzwerk(e) zu übertragen.


Und dieses Bild ist das am stärksten herangezoomte fraktale Beispiel dieses Problems! Zoomen Sie heraus, und jeder Anbieter ist mit seinem eigenen Kundenstamm, seinen eigenen Anbietern und seinen eigenen Kunden verbunden ... die Risikofläche wächst exponentiell.

Also, lasst es uns lösen!


Wir können Sicherheit innerhalb von Minuten als Funktion in unser Produkt integrieren! Wir werden die Sicherheitslatte höher legen, indem wir eine gezieltere und detailliertere Lösung anbieten. Wir werden auch aufhören, die Probleme auf Kunden wie ACME Corp abzuwälzen, indem wir sie bitten, Änderungen auf Netzwerkebene vorzunehmen.


Stattdessen verlagern wir die sichere Konnektivität auf die Anwendungsebene und sorgen für ein ganzheitliches Produkterlebnis, indem wir die Initech-Plattform an den erforderlichen Stellen erweitern.


Das Beispiel hier zeigt, wie die Initech-Plattform eine Verbindung zu einem selbstgehosteten GitHub Enterprise-Server herstellen kann, der von ACME Corp. verwaltet wird. Das Endergebnis sieht folgendermaßen aus:


Das Hochfahren aller erforderlichen Teile dauert nur wenige Minuten! Um zu erfahren, wie das geht, sehen Sie sich unsere Code-Tour zum Erstellen der Grundlage eines selbstgehosteten Agenten an.