Volle Zugangskontrolle – Teil 2

Teil 2: OAuth-Bereiche wirken wie Magie

Im ersten Teil habe ich die Ambition für ein unternehmensweites Zugangskontrollsystem beschrieben. In vielen Fällen nutzen Verbindungen zu digitalen Ressourcen etwas, das als Application Programming Interface (API) bekannt ist. In diesem letzten Teil enthülle ich, wie man ein solches Zugangskontrollsystem abbilden und aufbauen kann. Es erfordert eine enge Zusammenarbeit zwischen Ihrem Identitätsanbieter und Ihrem API-Gateway. Es erfordert auch eine API-First-Mentalität. Beide sind heutzutage ziemlich straightforward und auch sehr mächtig. Und das Beste daran ist, dass sie leicht skalierbar sind – sogar über hybride Clouds und eine Vielzahl unterschiedlicher Technologien hinweg. Schließlich nehme ich Sie mit auf eine Traummission. Viel Spaß beim Lesen!

Es umsetzen

Um die vollständige Kontrolle über den Zugang zu Ihren digitalen Assets auf jeder Skala zu behalten, ohne das Budget zu sprengen und ohne Ihre Agilität zu verlieren, ist eine klare Trennung der Verantwortlichkeiten Ihr bester Ansatz. Konzeptuell gibt es nur wenige Arten von Komponenten, die verwaltet werden müssen – Identitätsanbieter und API-Gateways. Es gibt auch einige Arten von Stakeholdern – Informationsmanager, Personalmanager, Linienmanager und Prüfer. Wenn Sie diese durch Ihre Informationslandschaft hinweg ausrichten, sind Sie auf dem besten Weg zu Ihrer vollständigen Zugangskontroll-Zukunft.

Ich möchte dort beginnen, wo Ihre digitalen Assets verwaltet werden. Lassen Sie uns zunächst einig sein, dass alle Ihre Daten irgendwie durch Software verarbeitet werden, sei es ein Textverarbeitungsprogramm, eine Website, ein Workflow-Management-System oder ein ERP-System. Wenn Sie also den Zugang zu diesen Assets verwalten möchten, müssen Sie sicherstellen, dass der Zugang nur über die Software möglich ist, die Sie kontrollieren. Dies kann bereits eine Reihe von Maßnahmen erfordern. Auf Netzwerkebene (denken Sie an Solarwinds?), auf Datenbankebene (vergessen Sie nicht, Ihre Backups zu verschlüsseln), und auf physischer Ebene (bewahren Sie diese Bänder hinter sicher verschlossenen Türen auf). Was nützt es schließlich, in die Sicherung des Zugangs zu Daten in der Datenbank zu investieren, wenn die Backups frei zugänglich sind? Alles ziemlich standardmäßige Cybersicherheitsmaßnahmen. Besonders beim Cloud Computing werden Sie durch die bekannten cloud-nativen Prinzipien dazu angeleitet, Ihre digitalen Assets innerhalb Ihrer Dienste zu kapseln.

Als Nächstes möchten Sie sicherstellen, dass der Zugang zu diesen Diensten nur über klar definierte Schnittstellen unter Verwendung von Industriestandardprotokollen möglich ist. Ja, ich spreche hier von APIs. Es ist egal, welchen Stil Sie umsetzen, REST, AsyncAPI, GraphQL oder eine andere Variante; wichtig ist, dass Sie den Zugang zu Ihren digitalen Ressourcen außerhalb des Dienstes, der ihn implementiert, verwalten können. Das ist offensichtlich wichtig, weil es die beste Möglichkeit ist,

• ein konsistentes Verhalten zu schaffen,
• den Überblick zu behalten und
• die Verbreitung von Management- und Governance-Aufwänden zu vermeiden.

Folglich sind Benutzerkonten, Anwendungen und Berechtigungen alles digitale Assets, die Sie auf Unternehmensebene verwalten sollten. Erlauben Sie Ihren Leuten den Luxus, eine Identität mit einem Satz von Anmeldeinformationen zu haben, die all ihren digitalen Bedürfnissen dient. Ich weiß, vielleicht besser als die meisten Menschen, dass dies leichter gesagt als getan ist. Gleichzeitig weiß ich, dass die Authentifizierungs- und Autorisierungsstandards sich stark weiterentwickelt haben, und ein clever genutzter Identitätsintegrationshub ist ein leistungsfähiges Werkzeug, um all Ihre Identitäts- und Zugriffsmanagement-Teile zusammenzuführen.

Effektiv mit dem Managementaufwand umgehen

Sobald Sie auf Ihre digitalen Assets über APIs zugreifen, haben Sie die Möglichkeit, ein API-Gateway zur Kontrolle des Zugangs zu Ihren APIs und damit zu Ihren digitalen Assets zu verwenden. Das ist richtig, ein API-Gateway ist ein wertvolles Werkzeug zur Zugangskontrolle. Wie? Nun, Zugangskontrolle basiert auf Autorisierung, Autorisierung basiert auf Authentifizierung, und Authentifizierung basiert auf Identifikation. Eine API-Spezifikation kann verwendet werden, um den erforderlichen Authentifizierungsmechanismus zu definieren. Schauen Sie sich dieses Beispiel an:

securitySchemes:
    JWT:
      description: OAuth2 JWT bearer token assertion
      type: OAuth2
      scheme: bearer
      bearerFormat: JWT

Dieses Beispiel definiert effektiv, dass Sie die API nur mit einem ID-Token [iii] als Authentifizierung aufrufen können. Das ist großartig, weil Sie die Signatur des JWT validieren können (um festzustellen, dass es sich um ein Originaltoken handelt) und somit dem Inhalt des JWT vertrauen können. Darüber hinaus können Sie den Inhalt leicht für Autorisierungszwecke nutzen. Das ist der Punkt, an dem die OAuth-Bereiche ins Spiel kommen. Auch wenn dies noch nicht weit verbreitet ist, können OAuth-Bereiche wirklich Magie bei der Zugangskontrolle zu Ihren digitalen Assets wirken.

security:

  - ApiKeyAuth: ["account.read", "finance.supervise"]

Diese formale Definition besagt, dass nur Benutzer, die mindestens einen der Bereiche „account.read“ oder „finance.supervise“ im Abschnitt „scopes“ ihres JWT haben, Zugriff auf die API-Ressource erhalten. Es ist auch eine einfache Aussage für das API-Gateway zur Durchsetzung. Und es funktioniert tatsächlich auch aus einer Management-Perspektive hervorragend.

Sie können ein Software-Token mit der Plastikkarte vergleichen, die Sie erhalten, um Ihr Hotelzimmer zu betreten. Beide gewähren Zugang zu einer Ressource, beide können ungültig gemacht werden, und beide sind Beispiele für Autorisierung – das Besitzen des Tokens oder der Karte gewährt Ihnen Zugang zur Ressource, solange Ihr Token oder Ihre Karte noch gültig ist. Eine Schlüsselkarte kann Zugang zu mehreren Zimmern gewähren. Ebenso kann ein Software-Token eine beliebige Anzahl von Bereichen umfassen. Sie können weitere Eigenschaften hinzufügen, um die Sicherheit zu verbessern. Zum Beispiel können Sie ein Foto auf eine Schlüsselkarte drucken, Sie können ein Hotel in separate Zonen unterteilen. Auch bei einem JWT können Sie bequem Informationen hinzufügen. Zum Beispiel gibt der Authentication Context Class Reference die Zuverlässigkeit der Authentifizierung an. Dies können Sie nutzen, um sicherzustellen, dass die Basisauthentifizierung nur Zugang zu grundlegenden Informationen gewährt.

Durch die Definition dieser Bereiche (Sie sind frei, Ihre eigenen Bereiche nach Bedarf zu definieren) definiert der Besitzer der API ausdrücklich das Berechtigungsniveau, das für den Zugriff auf die Ressource erforderlich ist. Anschließend können Sie den Bereich an eine oder mehrere Benutzergruppen oder Benutzerrollen binden. Dies ist die Aufgabe eines Zugriffsmanagers. Jemand, der den Überblick hat, um niedrigstufige Berechtigungen in höherstufige Ansprüche zu gruppieren, die in einer Organisation sinnvoll sind. Schließlich muss ein Linienmanager die Rolle einer Person in seiner Linie zuweisen, die die eigentliche Arbeit erledigt. Dies bringt eine Trennung der Aufgaben auf der angemessenen Ebene mit sich. Gleichzeitig ist es sehr skalierbar und leicht zu organisieren. Es passt gut in Microservice-Architekturen und eine agile Arbeitsweise. Es ist einfach zu prüfen. Was gibt es daran nicht zu mögen?

Whitepaper Die Identity Und Access Management Auswahlhilfe

Möchten Sie Ihr Identitäts- Und Zugangsmanagement Gleich Von Anfang An Richtig Regeln?

Jetzt herunterladen

Vor kurzem habe ich ein recht komplexes System entworfen, das Informationen zwischen Regierungsbehörden und Bürgern austauscht. Verständlicherweise war Sicherheit ein wichtiger Antrieb für das Design. Bürger können nur auf die Informationen zugreifen, die ihnen gesendet wurden, und die Regierungsbehörden können nur Informationen an Bürger senden, die zuvor ihre Zustimmung gegeben haben. Darüber hinaus können Bürger anderen Bürgern delegierten Zugriff auf bestimmte Teile ihrer Informationen gewähren. Ebenso können Regierungsbehörden Organisationen ernennen, um sie zu vertreten.

Ich habe das gesamte System „API-First“ entworfen, was die Möglichkeit eröffnet, jede „Ressource“ durch ein API-Gateway vorzuschalten. Dies ist unser Hauptzugangskontrollpunkt geworden. Außerdem haben wir ein Verwaltungsportal erstellt, in dem Regierungsbehörden ihre eigenen Benutzer sowie ihre Vertretungen verwalten und autorisieren können. In einem anderen Portal verwalten die Bürger ihre Delegationen. Alternativ können sie sich für eine mobile App entscheiden.

Unser Identitätsanbieter erzeugt ein OpenID Connect-Token, das alle Informationen enthält, die das API-Gateway zur Kontrolle des Zugangs zu allen Ressourcen verwendet, einschließlich der APIs zur Verwaltung von Benutzern und deren Autorisierungen (OpenID Connect-Bereiche). Jetzt, da das System in Betrieb ist, scheint die Sicherheit fast einfach. Die Verwaltungslast ist gering, die Leistung ist hoch, während die Durchsetzung rockfest und vollständig transparent ist. Es basiert auch auf Industriestandards, was unter anderem die zukünftige Wartbarkeit gewährleistet.

Büroanwendungen

Vielleicht fragen Sie sich jetzt, wie Sie Ihre Büroanwendungen und ähnliches schützen können? Schließlich verwenden sie keine API, die Sie zur Verwaltung des Zugriffs auf Ihre Dateien im Netzwerk nutzen können. Sie sind eine integrierte Benutzeroberfläche und Backend-Anwendung. Ein reiner Monolith. Und Benutzer können auf diese Dateien zugreifen, indem sie Software verwenden, die Sie nicht kontrollieren können.

Auch wenn ich nicht denke, dass diese älteren Architekturen so schnell verschwinden werden, sehe ich doch einige hoffnungsvolle Anzeichen. Besonders in Cloud-nativen Anwendungen gibt es eine elegante Lösung für dieses Problem. Eine einfache Speicherlösung, die als netzwerkbasierte API konzipiert ist. Es gibt so viel, was an dem AWS S3-Dienst zu schätzen ist, dass alternative Implementierungen wie Minio und S3Proxy im gesamten Cyberspace verwendet werden. S3 ist nicht genau ein Dateidienst, sondern ein verteilter Objektspeicher. Es ist robust, widerstandsfähig, hyper-skalierbar und vor allem, es ist eine API. Konzeptuell ist es ein kleiner Schritt für Bürotools, die Objektablage als Funktion hinzuzufügen. Selbst die Sharepoint-API könnte eine solche Aufgabe übernehmen. Sobald wir dort sind, werden Sie die vollständige Kontrolle haben.

Was ist mit der digitalen Governance?

Es ist leicht vorherzusagen, dass die Governance zu einem großen Engpass wird, sobald Ihre gesamte Zugangskontrolle zentralisiert ist. Und ja, dies wird ein Umdenken erfordern. Glücklicherweise sind wir auf einem guten Weg zu einem verteilten Governance-Modell. Ein Modell, in dem Verantwortlichkeiten innerhalb geeigneter Rahmenbedingungen delegiert werden, sodass die Verantwortlichkeit weiterhin gewährleistet werden kann. Vielleicht besser als je zuvor.

Das Geheimnis der digitalen Governance heißt „Shift Left and Shield Right“. Das bedeutet, die Verantwortung radikal auf die niedrigstmögliche Ebene zu delegieren, auf der Verantwortung gespürt wird. Ermächtigen Sie diese Verantwortlichen mit Werkzeugen, die sie bei der Entscheidungsfindung und der Festlegung geeigneter Richtlinien unterstützen. Stellen Sie sicher, dass sie, wann immer sie außerhalb ihrer Rahmenbedingungen handeln, die Genehmigung einer „höheren“ Instanz benötigen. Stellen Sie auch sicher, dass diese Richtlinien vollständig durchgesetzt werden. Das ist der Teil, bei dem „Shield Right“ ins Spiel kommt. Wenn Sie Ihre Autorisierungsrichtlinien korrekt deklarieren, kann die digitale Infrastruktur sicherstellen, dass nur ordnungsgemäß autorisierte Akteure auf Ihre digitalen Assets zugreifen können. Keine Ausnahmen, keine Hintertüren. Garantiert.

Ich habe zuvor über API-Sicherheit, 42Crunch, und wie deren Toolset Ihre API-Sicherheit verbessert. Dies ist jetzt relevanter denn je.

Ist das wirklich eine Allheilmittel?

Nun, ehrlich gesagt nicht zu 100%. Es gibt eine Kategorie digitaler Assets, die wir bisher nicht besprochen haben. Und das sind die Systeme, bei denen der Ersteller eines digitalen Assets auch derjenige ist, der den Zugang zu seinem Asset verwaltet. Allerdings verwaltet er den Zugang außerhalb des Rahmens der Zugangskontrollsysteme. Das bricht die besprochene Trennung der Aufgaben. Es führt auch zu ernsthaften Problemen – es gibt keine Aufsicht über Berechtigungen, und Autorisierungen sind oft nicht gut verwaltet. Nicht gut.

Typischerweise passiert dies bei Systemen, in denen Dokumente, Projekte oder Fälle verwaltet werden. Ein einzelner Benutzer, wie vom Identitätsanbieter identifiziert, hat unterschiedliche Zugriffsebenen auf verschiedene Projekte, Fälle, Konten im System, basierend auf seiner Art der Beteiligung. Standardmäßig können Sie nichts zugreifen, es sei denn, der Besitzer eines Assets hat Ihnen eine „Beteiligungsrolle“ gewährt.

Fundamental ist das Problem, dass die Identifikatoren dieser Assettypen (Projekte, Fälle, Client-IDs, Ordner) nicht in Ihrem Identitätsanbieter verwaltet werden. Folglich lässt Sie Ihr Identitätsanbieter nicht den Zugang zu diesen nicht identifizierten digitalen Objekten verwalten. Das macht für mich Sinn. Erstens gibt es keine verfügbaren Standards zur Erstellung einer Schnittstelle für die Verwaltung dieser Identifikatoren. Zweitens können diese Assets sehr dynamisch sein. Denken Sie an ein IT-Service-Management-System, in dem täglich (viele) Hunderttausende von Fällen geschlossen werden, wobei das Zugriffslevel eines einzelnen Mitarbeiters auf jeden Fall stark variieren kann.

Sie könnten OPA – den Open Policy Agent, der in cloud-nativen Umgebungen weit verbreitet ist, in Betracht ziehen. Er bietet eine moderne deklarative Sprache zur Definition von Zugangskontrollrichtlinien. Tatsächlich bieten WSO2 API Manager und WSO2 Identity Server beide eine OPA-Integration als Policy Decision Engine an. Aber es löst nicht das grundlegende Problem. Regeln bauen auf Fakten auf, und die Fakten werden außerhalb des Entscheidungssystems verwaltet. Darüber hinaus besitzt der Dienst, der geschützt werden muss, die Daten zum eigenen Schutz.

Groß träumen

Erlauben Sie mir, ein wenig über eine mögliche Lösung zu träumen. Identitätsanbieter beinhalten typischerweise eine Funktion zur Verwaltung von Benutzergruppen. Sie können oft Rollen einer Gruppe von Benutzern zuweisen, sodass jedes Mitglied der Gruppe automatisch die Berechtigungen dieser Rolle erbt. Was wäre, wenn wir es so betrachten könnten? Jedes Projekt hat eine Gruppe von Mitgliedern, eine Gruppe von Eigentümern und eine Gruppe von Scrum Mastern. Was wäre, wenn wir diese Gruppen auf die Beteiligungsrollen im Projektmanagementsystem abbilden könnten? Wir müssten nur die Gruppen als benutzerdefiniertes Anspruch in das Token aufnehmen. Darüber hinaus könnten wir einfach den SCIM2-Standard als Schnittstelle anwenden.

Denken Sie darüber nach. Es gibt viele potenzielle Vorteile. Aus einer Governance-Perspektive wäre es viel besser, einen einzigen Verwaltungspunkt für Berechtigungen zu haben. Nur wenn Sie einen vollständigen Überblick haben, können Sie unerwünschte Überschneidungen von Berechtigungen analysieren und angehen. Wenn jemand den Job wechselt, können Sie alle seine Berechtigungen widerrufen. Aber es gibt auch praktischere Vorteile. Wann immer das letzte Mitglied in einer aktiven „Eigentümer“-Gruppe entlassen wird, könnte automatisch eine Warnung generiert werden, um die Vakanz zu füllen. Wenn jemand in eine neue Position versetzt wird, können seine Mitgliedschaften automatisch zur Neuzuweisung eingeplant werden. Wenn jemand in den Urlaub geht, kann der Zugriff vorübergehend delegiert werden. Bei einer langfristigen Erkrankung können die Berechtigungen neu zugewiesen werden. Und das Beste daran ist, dass keine API jemals ohne Verantwortlichen bleibt.

Abschließender Gedanke

Ist vollständige Zugangskontrolle also möglich, ohne das Budget zu sprengen und ohne Agilität zu verlieren? Nun, ja, aber vielleicht noch nicht heute. Zumindest nicht in jeder Organisation zu 100 Prozent. Aber Sie können zweifellos weit kommen, und unter bestimmten Bedingungen und mit etwas Aufwand können Sie es morgen vollständig erreichen. Es könnte einige Beharrlichkeit und harte Arbeit erfordern, Sie müssen möglicherweise einige Abstriche machen oder einige Zwischenstufen nehmen. Aber am Ende wird es den Aufwand wert sein. Schließlich sollte jede digitale Organisation sich zu einer gut geölten Maschine entwickeln, in der Sicherheit selbstverständlich geworden ist.

Warum nicht heute anfangen?

Wenn Sie tiefer eintauchen möchten, zögern Sie nicht. Wir bei Yenlo sind hier, um Ihnen zu helfen. Kontaktieren Sie uns einfach.