Wie einst Mark Twain als Reaktion auf das Lesen seines eigenen Nachrufs im Mai 1897 schrieb: „Die Berichte über meinen Tod sind stark übertrieben.“ Fast hundert Jahre später, im Jahr 1995, schuf ein finnischer Informatiker namens Tatu Ylönen ein sicheres Transportprotokoll, das einfach als Secure Shell (SSH) bekannt ist. Was haben diese Dinge miteinander zu tun? Nichts, abgesehen von der Wahrnehmung.
In der Praxis ermöglicht SSH Benutzern, eine sichere Remote-Verbindung mit einer Linux-basierten Maschine über eine Befehlszeilenschnittstelle (CLI) herzustellen. SSH ist der De-facto-Standard für sicheren Serverzugriff und hat sich trotz einer deutlichen Verschiebung in der Art und Weise, wie Infrastruktur in der Cloud betrieben wird, bewährt.
Bei Okta begrüßen wir die Verlagerung hin zum Cloud-Betriebsmodell, bei dem Ressourcen dynamisch und kurzlebig sind, indem wir die zugrunde liegenden Sicherheitseigenschaften von SSH anpassen. Unsere Kunden nutzen Okta Advanced Server Access (Okta ASA), um Identitäts- und Zugriffskontrollen für ihre Teams sicher zu automatisieren, damit sie SSH sicher nutzen können. Und wir haben gerade einen wichtigen Meilenstein bei der Akzeptanz erreicht, indem wir über 1 Million SSH-Logins pro Monat registriert haben... Tendenz steigend!
In diesem Beitrag möchte ich einige der Trends rund um das Cloud-Betriebsmodell, die anhaltende Rolle von SSH bei der Sicherung des Fernzugriffs und die Art und Weise, wie Okta unseren Kunden geholfen hat, einen hartnäckigen Schmerzpunkt elegant zu lösen, erläutern.
Mit großer Macht kommt große Verantwortung
Als De-facto-Standard für den Fernzugriff auf Linux-Server ist SSH natürlich ein häufiges Ziel für Angreifer, die versuchen, in das Netzwerk eines Unternehmens einzudringen. Das Transportprotokoll ist von Natur aus sicher; der zugrunde liegende Anmeldeinformationsmechanismus ist jedoch anfällig für menschliche Fehler – mit potenziell katastrophalen Folgen. SSH-Schlüssel, die als kryptografische Schlüsselpaare zur Vertrauensbestätigung dienen, müssen mit grosser Sorgfalt behandelt werden, damit sie nicht in die falschen Hände geraten. Es gibt keine Möglichkeit, eine Verbindung zwischen einem SSH-Schlüssel und einer Identität zu garantieren, daher ist in vielerlei Hinsicht der Besitz das A und O.
Daher waren Unternehmen traditionell gezwungen, eines der folgenden Dinge zu tun:
- Implementieren Sie eine Sicherheitsrichtlinie, damit Benutzer ihre persönlichen SSH-Schlüssel regelmäßig verwalten und rotieren können (am einfachsten, am wenigsten sicher).
- Betreiben Sie einen sicheren Vault-Service, der SSH-Schlüssel speichern kann, die bei Bedarf ausgecheckt werden (schwieriger, sicherer).
- Kaufen und implementieren Sie ein Privileged Access Management-Produkt, das als Gateway für den Remote-Zugriff dient (am schwierigsten, am sichersten).
Ich kann mir vorstellen, dass Sie das Muster hier erkennen\[U+2014]wie bei so vielen Dingen bekommen Sie das heraus, was Sie hineinstecken. Aber sehen Sie, die Sicherheit ver\[U+00E4]ndert sich, und zwar schnell. Erstens ist die schwierigste L\[U+00F6]sung nicht immer die sicherste, aber was noch wichtiger ist: Wer hat schon Zeit f\[U+00FC]r all die zus\[U+00E4]tzliche harte Arbeit??!! Wir sind alle gezwungen, mit weniger mehr zu erreichen, aber Sicherheitsteams stehen auch vor der zus\[U+00E4]tzlichen Herausforderung, das Unternehmen zu sch\[U+00FC]tzen, ohne das Gesch\[U+00E4]ft zu behindern. Keine leichte Aufgabe, f\[U+00FC]r die man zur Rechenschaft gezogen wird.
Wir verstehen diesen ständigen Balanceakt und entwickeln unsere Produkte so, dass sie die sicherste und benutzerfreundlichste L ösung auf dem Markt sind. Bevor wir auf die Details eingehen, wie wir unsere Kunden in die Lage versetzen, mit Okta ASA ein besseres Ergebnis zu erzielen, m chte ich auf die Wahrnehmung eingehen, dass SSH in der modernen Cloud-Ära tot ist.
Die Kubernetes-Herausforderung
Mit der Verlagerung hin zum Cloud-Betriebsmodell hat sich Kubernetes zum beliebtesten Configuration-Management-Plane/Orchestration-Layer/CLI/Runtime/Service-Mesh/Dev-Environment der Welt entwickelt. Hier ist ein Satz, den ich manchmal höre: „Wir setzen voll auf Kubernetes, wir brauchen keinen SSH-Zugriff mehr.“
Das klingt ja wie ein Traum: eine einheitliche Abstraktionsschicht, die jegliche menschliche Interaktion bei der Verwaltung elastischer Multi-Cloud-Infrastrukturen \[U+00FC]berfl\[U+00FC]ssig macht. Kubernetes ist sicherlich auf dem besten Weg, das sprichw\[U+00F6]rtliche Betriebssystem der Cloud zu werden, f\[U+00FC]hrt aber auch eine ganze Reihe neuer Komplexit\[U+00E4]ten und \[U+00DC]berlegungen ein. Hier ist eine kleine Auswahl von Szenarien, in denen menschliche Interaktion weiterhin erforderlich ist:
- Anmeldung bei zugrunde liegenden Hosts, um Diagnose-Skripte auszuführen, Protokolle zu prüfen, Netzwerkprobleme zu beheben usw.
- Schreiben und Debuggen von YAML-Code zur Beschreibung und Konfiguration von Zielumgebungen, Diensten, Laufzeiten usw.
- Überwachung der Leistung von Netzwerken, Infrastruktur, Diensten usw.
Inmitten all dieser Innovationen und Veränderungen steht SSH stark und unerschütterlich da, denn man kann diese robuste, direkte Verbindung zwischen einem Benutzer und einem Host-Betriebssystem einfach nicht ersetzen. Selbst die am stärksten automatisierten Umgebungen benötigen im Notfall einen menschlichen Zugriff, aber es steckt mehr dahinter – auch die Automatisierung braucht Sicherheitskontrollen. SSH ist nach wie vor für den Zugriff durch Menschen und auf Serviceebene geeignet.
Das Bild, das wir wahrscheinlich alle im Kopf haben, ist ein Systemadministrator, der an seinem Schreibtisch sitzt und sich von seinem Terminal aus mit einem einzelnen Linux-Server verbindet, indem er „ssh <hostname>“ eintippt. Während die direkte Benutzer-zu-Server-Anmeldung ein häufiger Anwendungsfall ist, ist die Verwendung von SSH auch verbreitet in:
- Entwickler, die Skripte schreiben und ausführen, die sich mit vielen Servern gleichzeitig verbinden, um eine Reihe von Diagnosetests durchzuführen
- Konfigurationsmanagement-Software (Terraform, Chef, Puppet, Ansible usw.), die sich mit Zielhosts verbindet, um lokale Änderungen vorzunehmen
- CI/CD-Automatisierungstools, die sich mit Produktionsservern verbinden, um Runtimes zu konfigurieren und Software-Builds zu pushen
Wer hat die Schlüssel?
Betrachten wir noch einmal das Problem mit SSH-Schlüsseln. Die traditionelle PKI (Public Key Infrastructure), die SSH unterstützt, wurde für eine andere Zeit entwickelt, in der ein Schlüsselaustausch ausreichte, um Vertrauen zu gewähren. Das Kernproblem liegt in der falschen Annahme, dass der Besitz eines privaten Schlüssels einem Identitätsprofil gleichkommt. Auch wenn wir sagen „Alices privater Schlüssel“, gibt es keinen zugehörigen Authentifizierungsprozess, der überprüfen könnte, ob Alice es war, die das Schlüsselpaar überhaupt generiert hat, oder dass Alice die einzige Person ist, die derzeit den privaten Schlüssel besitzt.
Da diese Schlüssel ausgegeben und über dynamische Infrastruktur- und Cloud-Service-Flotten verteilt werden, verstärkt sich die Herausforderung nur noch. Jeder öffentliche Schlüssel erhält im Laufe der Zeit mehr Berechtigungen; je länger er aktiv ist, desto wahrscheinlicher ist es, dass er für eine Ressource freigegeben wurde, was es extrem schwierig macht, ihn zu verfolgen und anschließend zu widerrufen. Bei diesem Modell ist die Zeit ein Fehler, der nicht behoben werden kann.
In einer Zero Trust-Weltist eine sinnvolle Vertrauensbestätigung die korrekte Einhaltung einer Richtlinie, die besagt, dass eine Person (oder ein Dienst) von einem bekannten Gerät zu einem bestimmten Zeitpunkt auf eine bestimmte Ressource zugreifen kann. Es geht nicht unbedingt um die Anmeldeinformationen selbst, sondern um den Kontext der Anfrage. Trotzdem benötigen wir immer noch eine Möglichkeit, die Identität und die Berechtigungen darzustellen, die mit der abgegebenen Bestätigung verbunden sind.
SSH-Client-Zertifikate eingeben
Glücklicherweise haben sich die OpenSSH-Kerntechnologien im Laufe der Zeit weiterentwickelt und 2011 die Möglichkeit eingeführt, sich mit einem Client-Zertifikat anstelle eines SSH-Schlüssels zu authentifizieren. Im Gegensatz zu Standard-SSH-Schlüsseln, die keine Metadaten enthalten, sind Client-Zertifikate kryptografisch verifizierbare Metadatenobjekte, die Dinge wie Benutzernamen, Rollen und mehr einfügen können. Aber wohl am wichtigsten ist, dass sie ein Ablaufdatum haben.
Mit Client Certificates kann der SSH-Zugriff einem Identity-zentrierten Authentifizierungs- und Autorisierungs-Workflow folgen, bei dem eine Berechtigung, die eng auf eine kontextbezogene Zugriffsentscheidung abgestimmt ist, On-Demand gemintet wird. Eine einzelne Anfrage, eine einzelne Berechtigung—schön und sauber. Mit einer kurzen Ablaufzeit ist keine Bereinigung erforderlich, wodurch die Last entfällt, die mit der Verfolgung, Verwaltung und Rotation von Anmeldeinformationen verbunden ist, wie zuvor erläutert. Die Zeit wird nun zu einem Feature.
Nun, es gibt immer noch keinen kostenlosen Mittagstisch; es erfordert eine Menge Arbeit und kontinuierliche betriebliche Verantwortung, um ein Public Key Infrastructure (PKI)-System aufzubauen und zu unterhalten, das diese Client-Zertifikate auf jede gültige Anfrage hin generieren kann. Hier kommt Okta ins Spiel—genau wie wir wissen, dass Sie Ihre eigene Authentifizierung nicht selbst entwickeln sollten, sollten Sie auch Ihre eigene PKI nicht selbst entwickeln.
Wie wir den SSH-Zugriff mit Okta ASA verwalten
Seit der Einführung von Okta ASA haben immer mehr unserer Kunden erkannt, dass der Serverzugriff in erster Linie ein Identitätsproblem ist. Unterschiedliche Zugriffsverwaltungssysteme mit unterschiedlichen Kontrollen führen zu unerwünschter Komplexität und einer unüberschaubaren Angriffsfläche. Je mehr Sie den Zugriff mit der Identität vereinheitlichen können, desto besser, und wenn Sie von Anfang an die marktführende Plattform haben, wird es natürlich, den Zugriff auf weitere identitätszentrierte Ressourcen wie Linux-Server zu erweitern.
Mit Okta ASA folgen SSH-Logins nun einer vertrauten Single Sign-On -Erfahrung, und authentifizierte und autorisierte Anfragen werden hinter den Kulissen mit sogenannten „ephemeren Anmeldeinformationen“ versehen. Für den Benutzer ist es einfach nur SSH. Für das Sicherheitsteam ist es eine ganze Welt voller Schmerz, die beseitigt wird.
Okta Advanced Server Access Endbenutzererfahrung
Benutzer installieren eine schlanke Client-Anwendung auf ihren Workstations, die mit ihren lokalen SSH-Tools interagiert. Für die Ausführung benötigt die Client-Anwendung Administratorrechte auf dem Rechner. Server, die bei Okta registriert sind, führen einen schlanken Agenten aus, der die lokale Konto- und Richtlinienverwaltung durchführt und Anmeldeereignisse erfasst. Um die Client-Zertifikatsauthentifizierung zu aktivieren, ist OpenSSH lokal so konfiguriert, dass es von Okta signierten Zertifikaten als gültigen Authentifizierungsmechanismus vertraut – dies ist ein wichtiges Detail, das wir bei der Erörterung des zugrunde liegenden PKI-Systems behandeln werden.
Wenn ein Benutzer versucht, sich an einem Server anzumelden, wird er über Okta authentifiziert und unterliegt den konfigurierten Anmelderichtlinien des Kunden. Dies kann Multifaktor-Authentifizierung (MFA) und/oder Device Trust umfassen. Nach der Authentifizierung werden sie basierend auf den rollenbasierten Zugriffskontrollen (RBAC) des Zielservers autorisiert. Wenn alle Prüfungen erfolgreich sind, erstellt Okta ASA ein kurzlebiges Client-Zertifikat, das auf die Anfrage zugeschnitten ist. Dieses Client-Zertifikat wird an die Client-Anwendung geliefert, die es im Speicher verwendet, um eine direkte, sichere Verbindung mit dem Zielserver herzustellen.
Was dies so revolutionär macht, ist, dass wir so viel PKI-Komplexität hinter der Eleganz unseres SaaS abstrahieren und ein vertrautes und nahtloses Single Sign-On-Erlebnis bieten können. Was geht also hinter den Kulissen vor, das so komplex ist?
Dynamische Client-Zertifikat-Architektur
Es erfordert viel Aufwand, eine hochverfügbare, ausfallsichere und sichere SaaS-Plattform zu betreiben. Wenn Sie PKI hinzufügen, haben Sie ein ziemliches Ungetüm in Ihren Händen, weshalb wir niemals empfehlen würden, ein gleichwertiges System selbst zu entwickeln. Die zugrunde liegende Client-Zertifikatsarchitektur von Okta ASA stammt von ScaleFT, das im Juli 2018 von Okta übernommen wurde.
Das Besondere an unserem Design ist, dass wir keine Zertifizierungsstelle (Certificate Authority, CA) im traditionellen Sinne betreiben (man denke an Web-PKI, wo die Vertrauenskette von entscheidender Bedeutung ist, da die Zertifikate eine lange Lebensdauer haben). Wir behandeln unsere CA-Architektur so dynamisch wie die Cloud-Infrastrukturumgebungen unserer Kunden und starten Dienste, die in der Lage sind, auf Anfrage ephemere Client-Zertifikate für bestimmte Servergruppen bei jeder unabhängigen SSH-Anmeldung zu erstellen.
Okta ASA CA-Architektur
Das Hauptziel dieser CA-Architektur ist es, den Umfang jedes Client-Zertifikats so weit wie technisch möglich zu minimieren. Als signierte Anmeldeinformationen sind die kryptografischen Eigenschaften jedes einzelnen natürlich immer noch wichtig. Wir nutzen AWS KMS als Root-Signierservice und profitieren von ihren zugrunde liegenden Sicherheitseigenschaften und dem hochverfügbaren Design. Innerhalb von Okta ASA betreiben wir Verschlüsselungsdienste, die eine Reihe von Aufgaben basierend auf verschiedenen API-Ereignissen ausführen.
Die hier relevantesten Ereignisse sind Projekterstellung und SSH-Verbindung:
- Wenn ein neues Okta ASA-Projekt erstellt wird, erstellen wir einen SHA-256-verschlüsselten Signierschlüssel. Wenn Server mit dem jeweiligen ASA-Projekt registriert werden, wird das lokale OpenSSH so konfiguriert, dass es Client-Zertifikaten vertraut, die mit diesem Schlüssel signiert sind. Da Projekte den Autorisierungsbereich des rollenbasierten Zugriffs (RBAC) auf Server darstellen, schränkt ein dedizierter Signierschlüssel auch die Anmeldeinformationen ein.
- Wenn eine SSH-Anmeldung authentifiziert und für einen Benutzer auf einem Gerät zu einem bestimmten Zeitpunkt autorisiert wird, erstellen wir ein neues Client-Zertifikat mit eingefügten Benutzer- und Geräte-Metadaten und einer kurzen Gültigkeitsdauer, um seine Gültigkeit zu begrenzen. Dieses Client-Zertifikat verwendet die Client-Anwendung des Benutzers, um eine sichere SSH-Verbindung mit dem Zielserver gemäß dem Workflow der Endbenutzererfahrung herzustellen. Aufgrund der kurzen Gültigkeitsdauer muss das Client-Zertifikat nach seiner Verwendung nicht bereinigt werden.
So viel Zeit und Geld wurde von Unternehmen und Anbietern aufgewendet, um das Risiko der Ausweitung von Anmeldeinformationen zu mindern. Wir gehen dieses Problem an der Wurzel an. Der beste Weg, das Risiko von Anmeldeinformationen zu mindern, besteht darin, sie unbrauchbar zu machen!
Eine Million SSH-Logins. Null SSH-Schlüssel.
Nun zurück zu diesem großen Meilenstein. Der Server-Agent, der auf jedem Zielserver installiert ist, erfasst jedes Anmeldeereignis, das einem Benutzer und einem Gerät zugeordnet werden kann, was ein viel stärkeres Audit-Ereignis darstellt als das, was Sie möglicherweise durch die Verwendung gemeinsam genutzter Konten oder gemeinsam genutzter Anmeldeinformationen erhalten würden.
Da immer mehr Okta-Kunden Advanced Server Access übernommen haben, um ihre Serverflotten in AWS, GCP, Azure oder On-Premises zu sichern, haben wir einen kontinuierlichen Anstieg der Serverregistrierungen und SSH-Login-Ereignisse festgestellt. Und wir haben den Meilenstein von 1 Million SSH-Logins in einem Monat erreicht, ohne die Verwendung von SSH-Schlüsseln, wodurch das Risiko der Ausbreitung von Anmeldeinformationen erheblich reduziert wird.
Gesamtzahl der erfolgreichen SSH-Logins pro Monat über Okta ASA
SSH bleibt bestehen
Obwohl sein Nachruf bereits 1897 veröffentlicht wurde, starb Mark Twain tatsächlich erst im April 1910, nachdem er zwei weitere Romane und mehrere Kurzgeschichten fertiggestellt hatte. In ähnlicher Weise können wir davon ausgehen, dass SSH weiterhin stark sein und sich an veränderte Anwendungsfälle anpassen wird. Genau wie in der Literatur gilt auch für die Sicherheit: Bewährtes ist einfach unschlagbar.
Um mehr darüber zu erfahren, wie Okta SSH richtig macht (und SSH wieder Spaß macht), besuchen Sie die Okta Advanced Server Access Übersicht, oder fordern Sie eine Demo an.
