Entwerfen Sie eine Identity Governance-Lösung, die Identitätseinblicke nutzt

Identity Access Management (IAM) ist nicht nur ein Hype, sondern auch ein neues Phänomen. Access Control-Anwendungen werden seit mehreren Jahrzehnten verwendet und sind in die Infrastruktur vieler Unternehmen eingebettet, werden jedoch immer schwieriger zu verwalten.

Kunden verwalten manchmal Hunderttausende von Benutzern, die möglicherweise Zugriff auf mehrere Anwendungen haben, was bedeutet, dass es möglicherweise Hunderttausende von möglichen Autorisierungen gibt. Autorisierungen wie Zugriffsrechte und Berechtigungen in einer Anwendung, die alle gewartet werden müssen. Dies führt zu der Frage, wer Zugang zu welchen Informationen hat, unter welchen Kontexten/Bedingungen und wie.

Architektur

Diese Referenzarchitektur nutzt die folgenden Services.

• Oracle Identity Governance (OIG)
• Oracle Identity Role Intelligence (OIRI)
• Oracle Access Governance (AG)
• Oracle Access Management (OAM)
• Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)

Diese Architektur kann in Oracle Cloud Infrastructure (OCI), Kunden-Data Centern oder Clouds von Drittanbietern implementiert werden. Zu den Vorteilen dieser Architektur zählen:

• Reduziert die Betriebskosten für die Bereitstellung des Benutzerzugriffs, indem redundante und zeitaufwendige manuelle Prozesse eliminiert werden.
• Erzielt einen angemessenen ROI durch Investitionen in neue Technologien wie Container und Microservices
• Minimiert Sicherheitsrisiken durch effektive Kontrollen und Eliminierung menschlicher Fehler
• Konsolidiert Zugriffsdaten in einer Ansicht, um einen Einblick zu erhalten, wer Zugriff auf welche Bereiche hat und wie riskant dieser Zugriff für das Unternehmen ist. Diese Ansicht bietet Sicherheitsverantwortlichen und Managern vollständige Transparenz der Benutzerzugriffsmuster.
• Steigert die Produktivität und die Zufriedenheit der Endbenutzer durch die Nutzung eines sofort einsatzbereiten intuitiven Dashboards.
• Automatisiert regulierte Complianceberichte.

Logische Architektur

Das folgende Diagramm veranschaulicht die IAM-Zielreferenzarchitektur.

Beschreibung der Abbildung Identity-Governance-logical-architecture.png

Identitätsverwaltung-logisch-architecture.zip

Die Funktionen jeder von der Oracle-Plattform implementierten Komponente folgen.

Oracle Identity Governance (OIG), Oracle Identity Role Intelligence (OIRI) und OIG-Connectors stellen Folgendes bereit.

• Administration

  Selfservicefeatures und Delegieren von administrativen Funktionen für die Verwaltung der Benutzeridentität, einschließlich Benutzer- und privilegierter Accounts.

• Provisioning

  Der ausgehende Fluss von Benutzerinformationen von einem zentralen Administrationspunkt zu einem Zielsystem. Verfolgen Sie alle Aktionen (wie Erstellen, Aktualisieren und Löschen) von Accounts, Rollen und Berechtigungen über alle verwalteten Ressourcen hinweg.

• Abgleich

  Der eingehende Fluss von Benutzerinformationen aus einem vertrauenswürdigen System oder Zielsystem. Benutzerinformationen umfassen in der Regel alle Aktionen (wie Erstellen, Aktualisieren und Löschen) von Konten, Rollen und Berechtigungen für die zentrale Administrationsplattform.

• Workflow Management

  Die Möglichkeit, Geschäfts- und IT-Prozesse zu automatisieren, um richtlinienbasierte automatisierte Provisioning- und Modellierungsprozesse für die Verwaltung von Ressourcenzugriffsanforderungen zu ermöglichen.

• Kennwortverwaltung

  Kennwort-Policy-Unterstützung und Selfservice-Administration für Kennwortzurücksetzungen und Kennwortänderungen.

• Notifications

  Weiterleitung von Informationen zu allen Arten von Ereignissen, die von der Plattform verarbeitet werden, an den Endbenutzer und an die Verwaltung relevanter Einheiten sowie an System-, Sicherheits- und delegierte Administratoren.

• Connectors

  Drei-Ebenen-Integrationsfunktion für verschiedene heterogene identitätsbezogene IT-Systeme. Diese dreistufige Funktion spiegelt das Ziel wider, die benutzerdefinierte Entwicklung zu minimieren, die Wiederverwendung von Code zu maximieren und die Bereitstellungszeit zu verkürzen.

• Regel-Engine

  Definiert Bewertungskriterien für die Ausführung von Prozessen im Zusammenhang mit Benutzern, Rollen, Berechtigungen, Accounts und Organisationsmanagement.

• Aufgabentrennung

  Verwendung von Identity Audit (davon IDA), um Verletzungen zu definieren und zu erkennen. Das Erkennungsverfahren von IDA überwacht den tatsächlichen Zugriff der Benutzer auf Ressourcen und erfasst kontinuierlich alle Verletzungen. IDA hat zwei Modi: Detektiv und Präventiv.

• Delegierte Rollen- und Zugriffsverwaltung

  Logische Gruppierung von Benutzern, denen Sie Zugriffsrechte zuweisen, Ressourcen automatisch bereitstellen oder in gemeinsamen Aufgaben wie Genehmigung und Zugriffszertifizierung verwenden können.

• Risikoanalysen

  Umfassende Risikomanagementfunktion für alle kritischen Funktionen, die Rollen, Konten und Berechtigungen direkt ein hohes, mittleres und geringes Risiko zuweisen können.

• Role Intelligence und Mining (OIRI)

  Ermittlung von Berechtigungsmustern über Peer-Gruppen hinweg mit Unterstützung eines Top-Down-Ansatzes für Role Mining basierend auf Benutzerattributen. Ein Bottom-up-Ansatz, der Daten basierend auf Anwendungen und Berechtigungen filtert, oder ein hybrider Top-down-Bottom-up-Ansatz.

  Vergleich von Kandidatenrollen mit einer vorhandenen Rolle, um eine Rollenexplosion zu vermeiden. Fähigkeit, Kandidatenrollen basierend auf Benutzeraffinität und Rollenaffinität zu optimieren. Automatisierte Veröffentlichung von Rollen in OIG, um einen Workflow zur Rollenakzeptanz auszulösen. Möglichkeit, Daten aus verschiedenen Quellen, wie OIG-Datenbank und Flat Files, zusammenzuführen und Was-wäre-wenn-Analysen bereitzustellen, bevor Kandidatenrollen in die Produktion verschoben werden.

Access Governance (AG) und AG-Agent stellen Folgendes bereit.

• Durchführung von Zertifizierungskampagnen mit einer intuitiven Benutzererfahrung, um angemessene und zeitnahe Zugriffsprüfungen sicherzustellen. Der intelligente Workflow leitet Benutzer und macht einfache Vorschläge, um Compliance- und regulatorische Ziele schneller zu erreichen.
• Risikoscoring und erweiterte Analysen basierend auf maschinellem Lernen mit präskriptiven Empfehlungen zur Verbesserung des Risikobewusstseins, zur Reduzierung manueller Zertifizierungsbemühungen und zur Automatisierung der Zugriffskontrolle/-bereitstellung.
• Konsolidierung von Gruppenzugriffsdaten in einer Ansicht, in der detailliert beschrieben wird, wer Zugriff auf was hat und wie riskant dieser Zugriff für das Unternehmen ist.
• Identitätsdatenorchestrierung zum Abrufen von Berechtigungsdaten direkt aus Oracle Identity Governance und Auslösen der Korrektur.

Oracle Access Manager (davon OAM) und OAM WebGate stellen Folgendes bereit.

• Autorisierung mit Entscheidungen und Durchsetzung von Zugriffs-Policys in Echtzeit (basierend auf Identitäten, Attributen, Rollen, Regeln und Berechtigungen für die Lösungsschnittstellen).
• Authentifizierung mit Echtzeitverifizierung anhand von Active Directory/Azure Active Directory-Benutzer-Repositorys der beanspruchten Identitäten für die Lösungsschnittstellen.
• Föderiertes Single Sign-On in der Rolle des Identitätsproviders bei OCI IAM in der Rolle des Serviceproviders für die Lösungsschnittstellen.

OCI IAM stellt Folgendes bereit.

• Föderiertes SSO mit OAM, als Serviceprovider mit OAM als Identitätsprovider.

Zielanwendungen

Zu implementierende Integrationszielanwendungen umfassen einige der folgenden Elemente.

• Identitätsabstimmung: Peoplesoft, SAP HRMS, Oracle e-Business Suite HRMS
• Provisioning und Zielabstimmung: SAP, Siebel, Salesforce, ServiceNow, Oracle e-Business Suite, Microsoft Office 365, Azure Active Directory, Amazon Web Services.

Physische Topologie

Das folgende Diagramm veranschaulicht die Referenzarchitektur eines Kubernetes-Clusters in einer Oracle Cloud Infrastructure-Region, die mehrere Availability-Domains enthält. Es wird eine Disaster-Recovery-Strategie innerhalb derselben Region empfohlen, um mehrere Availability-Domains (Data Center) zu nutzen und gleichzeitig Latenz und Performancebeeinträchtigung zu minimieren. Die vorgeschlagene Topologie verwendet zwei der drei Availability-Domains, da empfohlen wird, dass alle Pods auf Worker-Knoten in derselben Availability-Domain ausgeführt werden. Weitere Details zur Disaster-Recovery-Strategie finden Sie unten.

Beschreibung der Abbildung Identity-Governance-topology.png

Identitätsverwaltung-topology.zip

Die Architektur umfasst die folgenden Komponenten:

• Virtuelles Cloud-Netzwerk (VCN) und Subnetze

  Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

• Region

  Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domain bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).

• Internetgateway

  Das Internetgateway ermöglicht Traffic zwischen den öffentlichen Subnetzen in einem VCN und dem öffentlichen Internet.

• Web Application Firewall (WAF)

  Oracle Cloud Infrastructure Web Application Firewall (WAF) ist ein mit der Zahlungskartenindustrie (PCI) konformer, regionaler Edge-Enforcement-Service, der an einen Enforcement Point angehängt ist, wie einen Load Balancer oder einen Domainnamen einer Webanwendung. WAF schützt Anwendungen vor schädlichem und unerwünschtem Internettraffic. WAF kann alle internetseitigen Endpunkt schützen und bietet eine konsistente Regeldurchsetzung über alle Anwendungen eines Kunden hinweg.

• Dynamisches Routinggateway (DRG)

  Das DRG ist ein virtueller Router, der einen Pfad für privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, z.B. ein VCN in einer anderen Oracle Cloud Infrastructure-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

• Servicegateway

  Das Servicegateway bietet Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service wird über die Oracle-Netzwerkstruktur geleitet und durchläuft nicht das Internet.

• Network Address Translation-(NAT-)Gateway

  Ein NAT-Gateway ermöglicht privaten Ressourcen in einem VCN den Zugriff auf Hosts im Internet, ohne dass diese Ressourcen für eingehende Internetverbindungen freigegeben werden.

• Subnetze
  Das VCN in dieser Architektur besteht aus 10 Subnetzen, die Produktions- und Disaster-Recovery-Umgebungen koppeln. Alle Subnetze sind Availability-Domain-spezifisch, d.h. sie sind innerhalb eines Data Centers begrenzt, um Latenz und Performancebeeinträchtigung zu minimieren. Disaster Recovery, das in demselben VCN und derselben Region bereitgestellt wird, schützt auch vor einem Ausfall der Availability-Domain.

  • Zwei öffentliche Subnetze gelten für die Web-Tier.
  • Zwei private Subnetze für den privaten Load Balancer.
  • Zwei private Subnetze sind für Admin-Hosts bestimmt, die das Tooling enthalten, das zur Verwaltung des Kubernetes-Clusters und der Knoten des Kubernetes-Clusters erforderlich ist.
  • Zwei private Subnetze sind für die Kubernetes-Cluster-API-Endpunkte vorgesehen.
  • Zwei private Subnetze dienen dem Zugriff auf den privaten Autonomous Database-Endpunkt, um nur Verbindungen vom angegebenen privaten Netzwerk (VCN) zuzulassen.
• Load-Balancer-Knoten
  • Ein regionaler öffentlicher Load Balancer-Knoten fängt Traffic ab und verteilt ihn auf die Compute-Instanzen, auf denen die Webschicht der Lösung ausgeführt wird, über Produktions- und Disaster Recovery-Umgebungen hinweg.
  • Ein Availability-Domain-spezifischer privater Load Balancer-Knoten pro Umgebung fängt Traffic ab und verteilt ihn auf die Kubernetes-Knoten, auf denen die Middle Tier der containerisierten Anwendungen ausgeführt wird.
• Kubernetes-Worker-Knoten

  Die Kubernetes-Worker-Knoten sind die Compute-Instanzen, auf denen containerisierte Anwendungen bereitgestellt werden. Alle Worker-Knoten in dieser Referenzarchitektur befinden sich in einem einzelnen Knotenpool und sind an ein privates Subnetz angehängt. Bei Bedarf können mehrere Knotenpools erstellt werden.

  Auf die Worker-Knoten in dieser Referenzarchitektur kann nicht direkt über das öffentliche Internet zugegriffen werden. Benutzer der containerisierten Anwendungen können über den Load Balancer auf sie zugreifen. Administratoren können über den Bastion-Service auf die Worker-Knoten zugreifen. Die Kubernetes-Masterknoten werden im Mandanten von Oracle ausgeführt und nicht angezeigt.

• Kubernetes-API-Endpunkt

  Der Kubernetes-API-Endpunkt im Cluster-Control Panel, das in einem dedizierten Subnetz gehostet wird, ermöglicht es Endbenutzern, Kubernetes-Ressourcen abzufragen und zu ändern (wie Pods, Namespaces, Konfigurationszuordnungen und Ereignisse).

• Überlagerungsnetzwerk für Pods/Services

  Im Kubernetes-Networkingmodell wird davon ausgegangen, dass Pods eindeutige und weiterleitbare IP-Adressen innerhalb eines Clusters aufweisen. Im Kubernetes-Netzwerkmodell verwenden Pods diese IP-Adressen, um miteinander zu kommunizieren. Mit den Control-Plane-Knoten des Clusters mit Pods auf anderen Clustern, mit anderen Services (wie Speicherservices) und mit dem Internet.

• Autonome Datenbank mit privatem Endpunkt

  Bietet erweiterte Sicherheit, indem eine Datenbankeigenschaft festgelegt wird, die erzwingt, dass alle ausgehenden Verbindungen zu einem Zielhost den Egress-Regeln des privaten Endpunktes unterliegen und durch diese begrenzt werden. Egress-Regeln werden in der VCN-Sicherheitsliste oder in der Netzwerksicherheitsgruppe (NSG) definiert, die mit dem privaten Endpunkt der Autonomous Database-Instanz verknüpft ist.

• Bastionservice

  Oracle Cloud Infrastructure (OCI) Bastion bietet eingeschränkten und zeitlich begrenzten sicheren Zugriff auf Ressourcen, die keine öffentlichen Endpunkte haben und strenge Ressourcenzugriffskontrollen erfordern, wie Bare Metal und virtuelle Maschinen, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Cloud Infrastructure Kubernetes Engine (OKE) und alle anderen Ressourcen, die Secure Shell Protocol-(SSH-)Zugriff ermöglichen. Mit dem OCI Bastion-Service können Sie den Zugriff auf private Hosts aktivieren, ohne einen Jump-Host bereitzustellen und zu verwalten. Darüber hinaus erhalten Sie eine verbesserte Sicherheitslage mit identitätsbasierten Berechtigungen und einer zentralisierten, auditierten und zeitgebundenen SSH-Session. Mit OCI Bastion ist keine öffentliche IP für Bastionzugriff erforderlich. Dadurch entfällt der Aufwand und die potenzielle Angriffsfläche bei der Bereitstellung von Remotezugriff.

• Persistente Speicherreplikation

  Rsync auf NFS stellt eine Methode der persistenten Speicherreplikation bereit, mit der die Domainkonfiguration mit minimaler Wartung und Konfiguration repliziert wird.

• Autonomous Data Guard (Data Guard-Replikation)

  Wenn Sie Autonomous Data Guard mit einer Standbydatenbank in der aktuellen Region aktivieren, überwacht Autonomous Database die Primärdatenbank. Wenn die Primärdatenbank heruntergefahren wird oder ausfällt, übernimmt die Standbyinstanz die Rolle der Primärinstanz. Wenn Autonomous Data Guard mit einer lokalen Standbydatenbank aktiviert ist, stellt Autonomous Database eine identische Standbydatenbank bereit, die je nach Status der Primärdatenbank Folgendes zulässt.

  Wenn die Primärdatenbank heruntergefahren wird oder ausfällt, konvertiert Autonomous Data Guard die Standbydatenbank mit minimaler Unterbrechung in die Primärdatenbank. Nach Abschluss des Failovers erstellt Autonomous Data Guard eine neue Standbydatenbank für Sie.

  Sie können einen Switchover-Vorgang ausführen, bei dem die Primärdatenbank zur Standbydatenbank wird und die Standbydatenbank zur Primärdatenbank.

Hinweise

Beachten Sie beim Entwerfen Ihrer Identity Governance-Lösung Folgendes.

Disaster Recovery

Die Disaster Recovery-Lösung auf OCI ist ein aktiv-passives Modell.

Es gibt ein Primärsystem, das aus einer Oracle WebLogic-Domain (WLS), Oracle Identity and Access Management (OIG & OAM) auf der Oracle Cloud Infrastructure Kubernetes Engine, einem Load Balancer, einem Oracle Autonomous Transaction Processing (ATP) und zwei Oracle HTTP-Servern (OHS) in einer Availability-Domain (AD) besteht.

Das sekundäre System besteht aus denselben Architekturkomponenten, jedoch in einer anderen Availability-Domain. Die Availability-Domain, das Data Center und die Standorte befinden sich physisch weit genug von der primären Availability-Domain entfernt, um die Komponenten im Katastrophenfall zu schützen.

Mehr erfahren

Erfahren Sie mehr über das Entwerfen einer Identity Governance-Lösung.

Prüfen Sie diese zusätzlichen Ressourcen:

• Oracle Cloud Infrastructure-Dokumentation
• Oracle Cloud Kostenschätzer

Danksagungen

Autor: Katerina Kalimeri

Mitwirkende: Andreas Theodoridis, Ioannis Episkopakis, Kostantinos Pateras

Änderungslog

In diesem Log werden wichtige Änderungen aufgeführt:

30. September 2024

Inhalt in Überlegungen verbessert.