Identitäts- und Zugriffsverwaltung – Häufig gestellte Fragen

Häufig gestellte Fragen – Themen

Allgemeines

Was versteht man unter Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)?

OCI IAM ist ein nativer Service von OCI, der Identitäts- und Zugriffsverwaltungsfunktionen der Enterprise-Klasse wie starke, adaptive Authentifizierung, User Lifecycle Management (LCM) und Single Sign-On (SSO) für Unternehmensanwendungen bereitstellt. OCI IAM wird als Identitätsdomain(s) in OCI bereitgestellt. Mit enthaltenen Domains können Organisationen den Zugriff auf ihre Oracle Cloud-Services (Networking, Compute, Storage usw.) und Oracle SaaS-Anwendungen verwalten. Kunden können wählen, ob sie ein Upgrade durchführen oder zusätzliche Identitätsdomains erstellen möchten, um andere Anwendungsfälle zu berücksichtigen, z. B. die Verwaltung des Zugriffs von Mitarbeitern auf Nicht-Oracle Anwendungen, die Ermöglichung des Verbraucherzugriffs auf kundenorientierte Anwendungen oder die Einbettung von IAM in kundenspezifisch entwickelte Anwendungen.

Was sind Identitätsdomains?

Jede OCI IAM-Identitätsdomain ist eine eigenständige Identitäts- und Zugriffsverwaltungslösung, die für eine Vielzahl von IAM-Anwendungsfälle verwendet werden kann. Beispielsweise können Sie eine OCI IAM-Identitätsdomain verwenden, um den Zugriff für Mitarbeiter über zahlreiche Cloud- und On-Premises-Anwendungen hinweg zu verwalten und eine sichere Authentifizierung, eine einfache Verwaltung von Berechtigungen und nahtlosen Single Sign-On für Endbenutzer zu ermöglichen. Möglicherweise möchten Sie auch eine Identitätsdomain einrichten, sodass Geschäftspartner Zugriff auf Lieferketten- oder Bestellsysteme haben. Außerdem können Sie Identitätsdomains verwenden, um IAM für verbraucherorientierte Anwendungen zu aktivieren und Verbraucherbenutzern die Möglichkeit zu geben, sich selbst zu registrieren, sich bei sozialen Netzwerken anzumelden und/oder den Nutzungsbedingungen zuzustimmen. Identitätsdomains stellen eine umfassende Identity-as-a-Service-(IDaaS-)Lösung dar, die zahlreiche IAM-Anwendungsfälle und -Szenarien abdeckt.

Welche Art von Identitätsdomain sollte ich wählen?

  • Kostenlose Identitätsdomains: Jeder OCI-Mandant umfasst eine standardmäßige OCI-IAM-Identitätsdomain im kostenlosen Kontingent zum Verwalten des Zugriffs auf OCI-Ressourcen (Networking, Compute, Storage usw.). Wenn Sie nur den Zugriff auf OCI-Ressourcen verwalten möchten, können Sie die enthaltene Standarddomain verwenden. Sie bietet einen robusten Satz von IAM-Funktionen für die Verwaltung des Zugriffs auf Oracle Cloud-Ressourcen. Je nach Sicherheitsmodell und Team können Kunden diese Domain für OCI-Administratoren reservieren.
  • Oracle Apps-Identitätsdomains: Zahlreiche Oracle Cloud Applications (HCM, CRM, ERP, Branchen-Apps usw.) können die Verwendung von OCI IAM über eine Oracle Apps-Domain umfassen. Diese Domains sind für die Verwendung mit abonnierten Oracle Applications enthalten und bieten eine robuste IAM-Funktionalität für die Verwaltung des Zugriffs auf Oracle Cloud- und SaaS-Services. Kunden können alle Mitarbeiter zu dieser Domain hinzufügen, um SSO für einen Oracle Cloud Application-Service zu aktivieren, und können diese Domain verwenden, um den Zugriff auf einige oder alle ihrer OCI-Ressourcen zu verwalten.
  • Oracle Apps Premium-Identitätsdomänen: Wenn Sie eine Oracle Apps-Domain mit vollständigen Unternehmensfunktionen erweitern möchten, um den Zugriff für Oracle Applications zu verwalten, die möglicherweise nicht über SaaS bereitgestellt werden (z. B. Oracle E-Business Suite oder Oracle Databases, ob On-Premises oder in OCI gehostet), bieten Oracle Apps Premium-Domains alle OCI IAM-Features und -Funktionen zur Verwendung mit Oracle Zielen, die in Hybrid-Cloud-Umgebungen bereitgestellt werden können. Dies ist ein kostengünstiger Service mit vollem Funktionsumfang, der jedoch auf die Verwendung mit Oracle Zielen beschränkt ist.
  • Externe Identitätsdomains: Externe Identitätsdomains bieten eine vollständige Reihe von OCI IAM-Features und -Funktionen für Nicht-Mitarbeiter, wie z. B. Verbraucher, die auf eine Einzelhandelssite zugreifen, Regierungen, die Bürgern den Zugriff ermöglichen, oder Unternehmen, die Geschäftspartnern Zugriff gewähren. Es gibt keine Einschränkungen hinsichtlich der Anwendungen, auf die ausgerichtet werden kann. Bestimmte Unternehmensfunktionen, die in Szenarien ohne Mitarbeiter im Allgemeinen nicht nützlich sind, wie App Gateway und Provisioning Bridge, sind jedoch nicht enthalten. Externe Domains umfassen die Unterstützung für Social Logon, Selbstregistrierung, Zustimmung zu den Nutzungsbedingungen und Profil-/Kennwortverwaltung.
  • Premium-Identitätsdomains: Premium-Identitätsdomains bieten eine vollständige Reihe von OCI IAM-Features und -Funktionen ohne Einschränkungen hinsichtlich der Anwendungen, auf die ausgerichtet werden kann. Premium-Domains können als IAM-Service für Unternehmen verwendet werden, der den Zugriff von Mitarbeitern oder der Belegschaft über Cloud- und On-Premises-Anwendungen hinweg verwaltet und eine sichere Authentifizierung, einfache Verwaltung von Berechtigungen und den nahtlosen Single Sign-On für Endbenutzer ermöglicht.

Kann ich Mitarbeiter und Nicht-Mitarbeiter in einer einzigen Identitätsdomain mischen?

Nein. OCI IAM betrachtet diese für Lizenzierungszwecke als separate Benutzerpopulationen. Sie können jedoch denselben OCI IAM-Service verwenden, um zwei oder mehr Domains zu verwalten, die Mitarbeiter und Nicht-Mitarbeiter (Partner, verbundene Unternehmen, Verbraucher usw.) aufnehmen können. Mehrere Domains können für den Zugriff auf dieselben Anwendungen verwendet werden, aber die Regeln und Sicherheits-Policys für Nicht-Mitarbeiter unterscheiden sich normalerweise von denen, die für Mitarbeiter gelten. Jede Domain hat ihre eigenen Einstellungen, Konfigurationen und Sicherheits-Policys, die für diese Benutzerpopulation einzigartig sind. Dies ist beabsichtigt, um den stark variierenden Anforderungen gerecht zu werden, die für verschiedene Benutzerpopulationen typisch sind.

Wer hat Zugriff auf eine Identitätsdomain?

Jeder OCI-Mandant umfasst eine Administratorengruppe, die vollen Zugriff auf alle OCI-Ressourcen bietet. Es ist wichtig zu verstehen, dass alle Mitglieder der Gruppe „OCI-Administratoren“ vollen Zugriff haben, um OCI IAM-Identitätsdomains zu verwalten. Oracle empfiehlt eine sorgfältige Verwendung dieser Gruppe. Administratorrechte können innerhalb jeder Domain über Administratorrollen erteilt werden, die eine Aufgabentrennung zwischen Personengruppen ermöglichen. Weitere Einzelheiten finden Sie im Abschnitt Grundlegendes zu Administratorrollen.

Bietet OCI IAM High Availability und/oder Disaster Recovery?

Innerhalb jeder OCI-Region gibt es entweder mehrere Availability Domains (AD) oder Fault Domains (FD) (in Regionen mit einer AD). ADs und FDs dienen ähnlichen Funktionen, jedoch sind FDs physisch näher beieinander als ADs. Identitätsdomains werden mit redundanten Installationen in jeder Region (zwei über die ADs/FDs) bereitgestellt, die High Availability bieten. OCI IAM-Identitätsdomains bieten über einen Aktiv-Passiv-Ansatz, der eine leistungsstarke Datenreplikation nutzt, auch eine regionsübergreifende Disaster Recovery (DR). Dies sorgt für eine zuverlässige Datenwiederherstellung für Identitätsdomains für den unwahrscheinlichen Fall, dass eine gesamte OCI-Region nicht verfügbar ist. Diese DR wird über eine einzelne URL bereitgestellt und ist für Anwendungen transparent.

Was sind die wichtigsten Begriffe und Konzepte von Oracle Identity and Access Management?

Die wichtigsten Konzepte von IAM sind die folgenden:

  • Account oder Mandant – Wenn Sie sich für OCI anmelden, erstellt Oracle einen Mandanten für Ihr Unternehmen, bei dem es sich um eine isolierte Partition innerhalb von OCI handelt, in der Sie Ihre Cloud-Ressourcen erstellen, organisieren und verwalten können. Dies wird manchmal auch als OCI-Account bezeichnet.
  • Compartment – Ein logischer Container innerhalb eines OCI-Accounts für Oracle Cloud-Ressourcen. Administratoren können zur Organisation und Verwaltung von Ressourcen innerhalb eines OCI-Accounts ein oder mehrere Compartments erstellen. Beispielsweise können Compartments verwendet werden, um die Aufgabentrennung zwischen verschiedenen Arten von Administratoren (Networking, Compute, Storage usw.)
  • Root Compartment – Das oberste Compartment innerhalb eines OCI-Accounts. Das Root Compartment wird automatisch für Sie erstellt, wenn Ihr Account bereitgestellt wird.
  • Identitätsdomains – Eine Identitätsdomain repräsentiert eine Benutzerpopulation in OCI sowie zugehörige Konfigurationen und Sicherheitseinstellungen. Jeder Account enthält eine standardmäßige Identitätsdomain, mit der Kunden den Zugriff auf OCI-Ressourcen verwalten können. Außerdem können Kunden basierend auf ihren spezifischen Anforderungen zusätzliche Identitätsdomains erstellen. Identitätsdomains werden innerhalb eines Compartments erstellt, und der Zugriff zum Verwalten von Domains ist an Compartment-Berechtigungen gebunden. Darüber hinaus können OCI-Zugriffs-Policys geschrieben werden, um Benutzern in bestimmten Compartments/Domains den Zugriff auf Ressourcen in anderen Compartments zu ermöglichen.
  • Benutzer – Eine Entität, die authentifiziert werden kann. Ein Benutzer kann entweder ein Personen- oder ein Computerkonto sein. Jeder Benutzer hat einen eindeutigen Namen in Ihrem Account und eine global eindeutige Kennung. Benutzer können Kennwörter für den Zugriff auf die Webkonsole und Schlüssel für den Zugriff auf die Services über die APIs zugewiesen werden.
  • Gruppe – Eine Gruppe von Benutzern. Gruppen werden verwendet, um die Zugriffsverwaltung zu vereinfachen. Zum Beispiel können Softwareentwickler als Mitglieder einer „Entwickler“-Gruppe gruppiert werden, was ihnen ermöglicht, Code zu lesen und/oder zu modifizieren. Ein einzelner Benutzer kann Mitglied mehrerer Gruppen sein.
  • Policy – Ein Dokument, das festlegt, wer auf welche OCI-Ressourcen zugreifen kann und welche Berechtigungen er hat. Eine Policy besteht aus Policy-Anweisungen, die die natürliche Sprachsyntax nutzen.

Was ist das Besondere an dem Ansatz zur Identitäts- und Zugriffsverwaltung von Oracle Cloud Infrastructure?

Mit OCI IAM können Sie ein einziges Modell für die Authentifizierung und Autorisierung in allen Oracle Cloud- und Cloud Application-Services nutzen. OCI IAM erleichtert die Zugriffsverwaltung für Organisationen jeder Größe, von einer Person, die an einem einzelnen Projekt arbeitet, bis hin zu großen Unternehmen mit vielen Gruppen, die gleichzeitig an vielen Projekten arbeiten – und das alles innerhalb eines einzigen Accounts. Die Ressourcenverwaltung und -autorisierung kann auf Account- oder Compartment-Ebene erfolgen, wobei eine zentrale Prüfung und Abrechnung weiterhin möglich ist. OCI IAM ist von Grund auf so aufgebaut, dass Sie das Sicherheitsprinzip der niedrigsten Berechtigung erzwingen können – standardmäßig dürfen neue Benutzer keine Aktionen für Ressourcen ausführen. Administratoren können dann jedem Benutzer nur den Zugriff gewähren, der für den jeweiligen Benutzer geeignet ist.

Und zusätzlich zur Verwaltung von OCI-Ressourcen stellt Ihnen OCI IAM eine IDaaS-Lösung der Unternehmensklasse zur Verfügung. Mit einem Klick auf eine Schaltfläche können Sie eine robuste IAM-Lösung bereitstellen, die verwendet werden kann, um viele IAM-Anforderungen in Anwendungsfällen von Mitarbeitern/der Belegschaft, Partnern oder Verbrauchern zu erfüllen.

Wie unterstützt Oracle Cloud Infrastructure Multi-Faktor-Authentifizierung?

OCI IAM bietet umfassende Unterstützung für die Multifaktor-Authentifizierung (MFA), die eine mobile MFA-Anwendung umfasst, welche Optionen für Push oder One-Time-Passcode, Unterstützung für FIDO2-Authentifikatoren und Unterstützung für SMS, E-Mail, Telefonanrufe und mehr bietet. Darüber hinaus umfasst OCI IAM eine kontextbewusste adaptive Sicherheit, die das Risiko reduziert und für eine reibungslose Endbenutzererfahrung sorgt. Adaptive Security wertet das Gerät, das Netzwerk, den Standort und das frühere Verhalten des Benutzers aus, um eine Risikobewertung für die Sitzung des Benutzers zu erstellen. Administratoren können MFA-Policys konfigurieren, die für bestimmte Anwendungen oder für bestimmte Benutzergruppen unterschiedlich sein können.

Werden Änderungen an Benutzern, Gruppen, Compartments und Policys zu Debug- und Überwachungszwecken aufgezeichnet?

Ja. Zur Unterstützung der Unternehmensanforderungen für Auditing und Compliance werden alle Änderungen aufgezeichnet und diese Aufzeichnungen können Ihnen ohne zusätzliche Kosten zur Verfügung gestellt werden.

Wie sehen die ersten Schritte mit OCI IAM aus ?

OCI IAM wird standardmäßig ohne zusätzliche Kosten aktiviert. Der allererste Benutzer in Ihrem Account ist der Standardadministrator. Alle nachfolgenden Benutzer werden über den IAM-Dienst erstellt, wobei Sie ihnen explizit Berechtigungen für die Interaktion mit bestimmten Cloud-Ressourcen erteilen.

Sie können auf Oracle IAM über die Konsole, Rest API oder SDKs zugreifen.

Wie setze ich mein Kennwort als Oracle Cloud Infrastructure-Benutzer zurück?

Um Ihr Passwort für Oracle Cloud Infrastructure zurückzusetzen, müssen Sie zunächst sicherstellen, dass Sie Ihrem Account eine E-Mail-Adresse zugeordnet haben. Besuchen Sie die Benutzerprofilseite für Ihr Oracle Cloud Infrastructure-Account, und fügen Sie eine E-Mail-Adresse hinzu, auf die nur Sie Zugriff haben. Sie erhalten eine E-Mail, um zu bestätigen, dass Sie diese Adresse in Ihrem Account registrieren möchten. Anschließend können Sie Ihr Passwort mit Ihrem E-Mail-Account zurücksetzen, sofern es nicht von Ihrem Tenancy-Administrator deaktiviert wurde.

Compartments

Welche Probleme sollen Compartments lösen?

Ein Compartment ist ein sicherer logischer Container in Ihrem Account, der zum Hosten Ihrer Infrastrukturressourcen (z. B. Computing, Storage und Networking) zusammen mit einer Reihe von Zugriffsverwaltungs-Policys für diese Ressourcen verwendet wird. Mithilfe von Compartments können Sie Ihre Cloud-Ressourcen logisch organisieren, um eine Vielzahl von Anwendungsfällen zu unterstützen.

Im Folgenden finden Sie einige gebräuchliche Methoden zur Verwendung von Compartments:

  • Trennen Sie Ihre Softwareentwicklungsumgebungen für eine einfache Administration. Beispielsweise könnten Sie separate Compartments für Entwicklung, Test und Produktion nutzen, oder Sie verwenden separate Compartments, um Blue-Green-Bereitstellung zu unterstützen.
  • Vereinfachen Sie die Berechtigungsverwaltung. Sie können beispielsweise ein separates Compartment für Ihre Netzwerkressourcen (VCNs, Subnetze, Internetgateways usw.) erstellen und dann nur Netzwerkadministratoren den Zugriff auf dieses Fach gestatten.
  • Messen Sie die Nutzung separat für unterschiedliche Geschäftsbereiche, um diese Geschäftsbereiche ordnungsgemäß anhand des Cloud-Ressourcenverbrauchs abzurechnen.
  • Minimieren Sie die Ressourcen, die für bestimmte Benutzergruppen sichtbar sind. Beispielsweise könnten Sie ein separates Compartment für Ihr Finanzteam haben, die nur für bestimmte Mitarbeiter sichtbar ist.

Können Compartments Ressourcen in mehreren Availability-Domains enthalten?

Ja. Compartments sind logische Gruppierungen von Ressourcen, die sich von den physischen Konstrukten von Availability-Domain unterscheiden. Ein einzelnes Compartment kann Ressourcen in verschiedenen Availability-Domains enthalten.

Wie werden Compartments für die Zugriffssteuerung verwendet?

Alle Policys sind entweder dem Root Compartment oder einem Child-Compartment zugeordnet. Jede Policy besteht aus einer oder mehreren Policy-Anweisungen, die dieser grundlegenden Syntax folgen:

Allow group ... to ... in compartment ...

Mit Policy-Anweisungen können Sie Compartments verwenden, um die Berechtigungsverwaltung zu vereinfachen. Sie können beispielsweise eine Policy schreiben, mit der die Gruppe HRAdministratoren alle Ressourcen im Compartment HRCompartment verwalten kann.

Kann ich Compartments löschen?

Ja, Sie können Compartments löschen.

Kann ich ganze Compartment-Strukturen und die darin enthaltenen Ressourcen verschieben?

Ja, Sie können ganze Compartment-Strukturen und die darin enthaltenen Ressourcen in andere übergeordnete Compartments verschieben.

Kann ich Ressourcen wie eine Compute-Instanz oder ein Blockvolume von einem Compartment in ein anderes verschieben?

Ja, Sie können Ressourcen von einem Compartment in ein anderes verschieben.

Kann ich eine Compartment-Hierarchie erstellen?

Ja, Sie können eine Hierarchie von Compartments erstellen, indem Sie diese verschachteln. Mit hierarchischen oder verschachtelten Compartments kann der Systemadministrator Ressourcen organisieren und dies auch für Administratoren auf niedrigerer Ebene ermöglichen, wobei die vollständige Visibilität und die Kontrolle über die Policy erhalten bleiben.

Wie viele Ebenen tief können Sie Compartments verschachteln?

Die maximale Tiefe eines verschachtelten Compartments beträgt sechs Ebenen.

Gelten Policys für ein übergeordnetes Compartment auch für ein untergeordnetes Compartment?

Ja, Policys für übergeordnete Compartments werden von untergeordneten Compartments übernommen.

Kann ich die Kosten und die Nutzung nach Compartments verfolgen?

Ja, Sie können Kosten und Nutzung nach Compartments unter „Meine Services“ verfolgen.

Was versteht man unter einem Root Compartment?

Oracle Cloud Infrastructure erstellt für jeden Account automatisch ein übergeordnetes Compartment, das als Root Compartment bezeichnet wird. Ähnlich wie der Stamm-Ordner in einem Dateisystem verhält sich das Root Compartment bis auf einige Besonderheiten genau wie das untergeordnete Compartment:

  • Da die Berechtigungen hierarchisch sind, gelten die Gruppenberechtigungen im Root Compartment für alle untergeordneten Compartments. Wenn beispielsweise der Gruppe „NetworkAdmins“ die Berechtigung zum Verwalten von Virtual Cloud Networks (VCN) im Root Compartment erteilt wird, kann diese Gruppe VCNs in allen Compartments verwalten.
  • Derzeit werden alle Benutzer und Gruppen im Root Compartment erstellt. Policys können verwendet werden, um ihnen nur Zugriff auf bestimmte untergeordnete Compartments zu gewähren.

Hinweis: Derzeit können Sie zusätzliche Compartments nur im Root Compartment und nicht in anderen Compartments erstellen.

Wann sollte ich Ressourcen im Root Compartment erstellen und wann sollte ich sie in einem untergeordneten Compartment erstellen?

Im Allgemeinen sollten Ressourcen in einen anderen Compartment als das Root Compartment erstellt werden. Am besten entwerfen Sie Ihre Compartment-Hierarchie, bevor Sie mit der Erstellung von Compartments und Ressourcen beginnen.

Benutzer

Was kann ein Oracle Cloud Infrastructure Console-Benutzer tun?

Ein Benutzer ist jemand, der sich erfolgreich bei OCI IAM authentifizieren kann und über ausreichende Berechtigungen verfügt, um Cloud-Ressourcen in Ihrem Account zu nutzen oder zu verwalten. Administratoren können einen oder mehrere Benutzer in ihrem Account erstellen und sie Gruppen zuweisen, um ihnen Berechtigungen für Ressourcen in bestimmten Compartments zu erteilen.

Wer kann Benutzer anlegen und verwalten?

Ihr Account wird mit einem einzelnen Benutzer bereitgestellt: dem Standardadministrator, und einer einzelnen Gruppe: Administratoren, deren Mitglied der standardmäßige Administratorbenutzer ist. Diese Gruppe (Administratoren) hat vollen Zugriff auf Ihren Account. Dieser spezielle Benutzer (Standardadministrator) muss zusätzliche Benutzer erstellen oder anderen Benutzern die Berechtigung erteilen, neue Benutzer zu erstellen.

Welche Zugriffsrechte hat ein neuer Benutzer beim Erstellen?

Standardmäßig verfügt ein neuer Benutzer nicht über die Berechtigung, eine Ressource oder einen Service in Ihrem Account zu verwenden. Alle Berechtigungen müssen explizit erteilt werden. Mit diesem Ansatz können Sie das Sicherheitsprinzip der geringsten Berechtigungen einhalten, bei dem Sie jedem Benutzer nur den für diesen bestimmten Benutzer erforderlichen Zugriff gewähren. Sie müssen den Benutzer entweder explizit einer vorhandenen Gruppe hinzufügen oder eine neue Gruppe für diesen erstellen und dieser Gruppe dann über eine Policy die entsprechenden Berechtigungen zuweisen.

Kann ich den Zugriff für Benutzer aktivieren und deaktivieren?

Administratoren können einen Benutzer deaktivieren oder sperren, um seinen Zugriff vorübergehend zu deaktivieren. Darüber hinaus können Sie Benutzerkennwörter zurücksetzen oder Schlüssel entfernen.

Können wir die Ablaufzeit für Kennwörter festlegen? Wie kann ich die Anmeldeinformationen wechseln?

Ja, mit Kennwort-Policys können Sie eine Ablaufzeit für Kennwörter festlegen. Sie können auch das Zurücksetzen von Kennwörtern, Schlüsseländerungen oder Änderungen an Benutzer- und Gruppenmitgliedschaften über die REST-API und SDKs automatisieren.

Policys

Was ist eine Policy?

Eine Policy ist ein Dokument, das aus beschreibenden Policy-Anweisungen besteht, die bestimmten Benutzergruppen bestimmte Berechtigungen erteilen. Sie sind in einer leicht verständlichen SQL-ähnlichen Syntax geschrieben. Beispiel-Policys können Folgendes erzwingen:

  • Systemadministratoren können Ihre Bare Metal-Compute-Instanzen „beenden“ oder „neu starten“.
  • Netzwerkadministratoren können alle netzwerkbezogenen Infrastrukturressourcen vollständig verwalten.
  • IT-Administratoren können Benutzer erstellen und Gruppenmitgliedschaften bearbeiten.

Eine Policy ermöglicht es einer Gruppe, auf bestimmte Weise mit bestimmten Arten von Ressourcen in einem bestimmten Compartment zu arbeiten. Optional können Policys eine Bedingungsklausel („wobei ... gilt“) enthalten, die die Policy-Anweisung weiter einschränkt. Policys folgen der folgenden Syntax:

Allow group ... to ... in compartment ...

Im Folgenden finden Sie beispielsweise eine Policy-Anweisung, mit der Berechtigungen zur Verwendung von Compute-Instanzen erteilt werden:

Gruppe „Entwickler“ für „Instanzverwendung“ in Compartment „ProjectA“ zulassen

  • „group_name“ ist der Name der Gruppe, der Berechtigungen erteilt wurden.
  • „verbs“ sind Aktionen, die Sie für Ressourcen ausführen können, zum Beispiel: Inspizieren, Lesen, Verwenden oder Verwalten (inspect, read, use oder manage).
  • „resource-type“ ist die Cloud-Ressource, für die Berechtigungen erteilt werden. Beispiele für „resource-types“ sind: Instanzen, Volumes und Routingtabellen.
  • „compartment_name“ ist der Name des Compartments, in dem die Ressourcen organisiert sind.
  • „conditions“ sind weitere Spezifikationen, die den Umfang der Policy-Anweisung einschränken. Beispiele: „where request.user.id=target.user.id“ oder „where target.group_name != Administrators“.

Weitere Einzelheiten finden Sie im Abschnitt zu OCI IAM in der Oracle Cloud Infrastructure-Dokumentation.

Werden Policys für das Root Compartment von untergeordneten Compartments übernommen?

Ja. Eine Policy, die Berechtigungen im Root Compartment gewährt, gewährt automatisch die gleichen Berechtigungen für alle untergeordneten Compartments. Die folgende Policy erteilt beispielsweise allen Benutzern in der Gruppe „InstanceAdmins“ die Berechtigung, Instanzen im Root Compartment sowie in allen untergeordneten Compartments zu verwalten:

Gruppe „InstanceAdmins“ für „Instanzenverwaltung“ in der Tenancy zulassen

Können Policys auf bestimmte Compartments beschränkt werden?

Ja. Jede Policy ist an ein Compartment „angehängt“. Die Position des Anhangs legt dann fest, wer sie ändern oder löschen kann. Wenn Sie eine Policy an das Root Compartment anhängen, kann sie jeder ändern oder löschen, der Zugriff auf die Verwaltung von Policys im Root Compartment hat. Wenn Sie die Policy stattdessen an das Compartment anhängen, kann sie jeder ändern oder löschen, der Zugriff auf die Verwaltung von Policys im Compartment hat. In der Praxis bedeutet dies, dass es problemlos möglich ist, Compartment-Administratoren (d. h. einer Gruppe mit Zugriff auf die Verwaltung aller Ressourcen im Compartment) Zugriff auf die Verwaltung der Policys ihres eigenen Compartments zu gewähren, ohne ihnen einen breiteren Zugriff auf die Verwaltung der Policys zu gewähren, die sich im Account befinden.

Wo kann ich mehr über das Schreiben von Policy-Anweisungen erfahren?

Weitere Informationen zu Policys und Policy-Anweisungen finden Sie unter „Erste Schritte mit Policys“ und „Gemeinsame Policys“ in der Oracle Cloud Infrastructure-Dokumentation.

IAM-Deny-Policy

Häufig gestellte Fragen zu OCI Identity and Access Management

Diese häufig gestellte Fragen führen Nutzer durch die Deny-Policys von Oracle Cloud Infrastructure (OCI) Identity and Access Management, mit denen berechtigte Personen gezielt Aktionen sperren können, um die Sicherheit zu erhöhen und die Zugriffskontrolle in OCI-Mandanten zu vereinfachen. Weitere Informationen finden Sie in der Dokumentation zu OCI Identity and Access Management.

Erste Schritte mit IAM Deny

Wie aktiviere ich die IAM Deny-Funktion in OCI?

IAM Deny ist eine optionale Funktion, die explizit von einem Mandantenadministrator aktiviert werden muss: Öffnen Sie dazu in der OCI-Konsole Policys, dann Aktionen und Policy-Einstellungen. Sie kann nicht von regulären Nutzern oder Policy-Autoren aktiviert werden. Nach der Aktivierung ist die Funktion dauerhaft Teil des IAM-Frameworks des Mandanten und kann über die Benutzeroberfläche nicht mehr deaktiviert werden. Ein Mandantenadministrator mit Schreibrechten für Deny-Policys kann die Nutzung präzise steuern, indem er eine übergeordnete Deny-Policy erstellt, die alle Nutzer außer der Standard-Administratorgruppe daran hindert, Deny-Policys zu erstellen bzw. zu bearbeiten. Ein Beispiel: Deny any-user to manage policies in tenancy where target.policy.type='DENY'

Bei Aktivierung von IAM Deny

  • OCI hinterlegt automatisch eine Standard-Deny-Policy im Root Compartment, um eine sichere Nutzung zu gewährleisten.
  • Nur die Standard-Administratorgruppe und der Mandantenadministrator, der IAM Deny aktiviert hat, behalten die Berechtigung, Deny-Policys zu konfigurieren und zu verwalten.
  • Der Mandantenadministrator kann die Standard-Deny-Policy danach anpassen, sodass autorisierte Nutzergruppen – zum Beispiel Administratoren in den Bereichen Banking, Investments und Compliance – in der OCI-Konsole Deny-Policys verfassen dürfen.

Was sind Deny-Anweisungen in Oracle Identity and Access Management?

Mit Deny-Anweisungen in OCI Identity and Access Management können Sie explizite Policys erstellen, die gezielt Aktionen in einem OCI-Mandanten blockieren und damit Allow-Policys für eine präzise Zugriffskontrolle ergänzen. Sie können beispielsweise Deny any-user to inspect all-resources in tenancy where request.service='streaming' nutzen, um sämtlichen Zugriff auf den OCI Streaming Service im Mandanten zu verhindern, während andere Berechtigungen weiterhin durch Allow-Policys gewährt werden.

Welche Begrenzungen gelten für IAM-Deny-Policys?

Deny-Policys unterliegen denselben Begrenzungen wie Allow-Policys. Ein Mandant kann bis zu 100 IAM-Policy-Objekte enthalten, jedes mit maximal 50 Policy-Anweisungen (Deny oder Allow); insgesamt sind über alle Objekte höchstens 100 Policy-Anweisungen zulässig.

Welche Meta-Verben werden von IAM-Deny-Policys unterstützt, und handelt es sich dabei um neue oder bestehende?

IAM-Deny-Policys verwenden die bestehenden Meta-Verben: manage, use, read und inspect. Es werden keine neuen Meta-Verben eingeführt. Im Gegensatz zu Allow-Anweisungen, die Berechtigungen kumulativ gewähren (z. B. umfasst „manage“ alle niedrigeren Rechte), sind Deny-Anweisungen subtraktiv und sperren nur die angegebene Berechtigung sowie alle übergeordneten Ebenen.

So sperrt beispielsweise Deny group DevOps to manage instance in compartment Prod nur die Berechtigung „manage“, während „use“, „read“ und „inspect“ weiterhin ausgeführt werden können. Das Verweigern von „inspect“ blockiert jedoch alle Berechtigungen, da es sich um die grundlegende Basisebene handelt.

Erstellung und Verwaltung von Policys

Wo kann ich Deny-Policys in der OCI-Konsole anlegen?

Deny-Policys werden in derselben OCI-Konsole erstellt wie Allow-Policys. Navigieren Sie zu Identität & Sicherheit, dann zu Policys, wählen Sie ein Compartment und fügen Sie im Policy-Editor das Schlüsselwort „deny“ zusätzlich zu „allow“ hinzu. Für den Prozess ist keine separate Schnittstelle erforderlich.

Gibt es ein separates Policy-Objekt zum Ablehnen von Policys?

Nein, Deny-Policys verwenden dasselbe Policy-Objekt wie Allow-Policys. Beide werden innerhalb desselben Policy-Objekts verwaltet, wodurch die Administration vereinfacht wird.

Kann ich Deny- und Allow-Anweisungen in ein einzelnes IAM-Policy-Objekt aufnehmen?

Ja, Sie können Deny-Anweisungen in einem Policy-Objekt kombinieren und zulassen, um eine flexible Zugriffskontrolle zu ermöglichen.

Ein Policy-Objekt kann z. B. folgende Anweisungen enthalten:

Deny group Interns to use instance in compartment Finance
Allow group Admins to manage all-resources in compartment Finance

Diese Policys erlauben Admins die vollständige Verwaltung von Ressourcen im Bereich Finance, während Interns keine Schreibaktionen an Instanzen durchführen dürfen – so gestalten Sie den Zugriff optimal und übersichtlich.

Wie kann ich verhindern, dass Nutzern mit Policy-Verwaltungsrechten auch Deny-Policys definieren dürfen?

Um dies zu verhindern, legen Sie auf Root-Ebene eine Deny-Policy an, die das Erstellen von Deny-Policys blockiert.

Zum Beispiel: Deny group PolicyAdmins to manage policies in tenancy where target.policy.type='DENY'

Dadurch können PolicyAdmins keine Deny-Policys erstellen oder ändern, behalten aber das Recht, Allow-Policys zu verwalten. Die Standard-Administratorgruppen sind davon ausgenommen und können weiterhin Deny-Policys anlegen, falls erforderlich.

Wie kann ich mit einer IAM Deny-Policy einen kompletten OCI-Service sperren?

Um einen kompletten Service zu blockieren, erstellen Sie eine Deny-Policy auf der Root-Ebene, die beispielsweise anhand von request.service.name auf die gewünschten Ressourcen oder Aktionen zielt.

Zum Beispiel, um den OCI Streaming Service mandantenweit zu sperren

Deny any-user to inspect all-resources in tenancy where request.service.name='streaming'

Diese Policy verhindert jeglichen Zugriff auf den OCI Streaming-Service. Dies ist besonders für die Einhaltung von Vorschriften in Branchen wie dem Gesundheitswesen nützlich. Platzieren Sie die Policy im Root Compartment, um eine unternehmensweite Anwendung zu gewährleisten und „Policy-Wildwuchs“ zu reduzieren.

Wie verhindere ich, dass eine Gruppe Ressourcen in einer bestimmten Region verwaltet?

Um zu verhindern, dass eine Gruppe Ressourcen in einer bestimmten Region verwaltet, nutzen Sie eine Deny-Policy mit der Bedingung request.region.

Um beispielsweise zu verhindern, dass eine Gruppe in einer bestimmten Region andere Aktionen als Lesezugriff durchführt, können Sie folgende Deny-Policy schreiben:

Deny group RegionalAdmins to use all-resources in tenancy where request.region='sa-saopaulo-1'

Diese Policy nimmt der Gruppe RegionalAdmins alle Nutzungsrechte in der Region São Paulo, erlaubt aber weiterhin die Rechte use, read und inspect. Dies ist ideal für Finanzinstitute, die regionale Datenschutzgesetze einhalten müssen.

Wie kann ich einer Gruppe den Zugriff auf Compute-Instanzen in einem bestimmten Compartment verweigern?

Um einer Gruppe den Zugriff auf Compute-Instanzen in einem spezifischen Compartment zu verweigern, verwenden Sie

Deny group DevTeam to inspect instance in compartment ProjectX

Diese Policy verweigert sämtliche Berechtigungen (inspect, read, use, manage) auf Compute-Instanzen im Compartment ProjectX. Ein Technologieunternehmen kann dies nutzen, um dem DevTeam den Zugriff auf Produktionsinstanzen zu verwehren und Entwicklungs- und Produktionsumgebungen zum Schutz zu trennen.

Wie kann ich verhindern, dass eine Gruppe den Objektspeicher in einem bestimmten Compartment verwaltet?

Um einer Gruppe das Verwalten von Objektspeicher-Ressourcen zu untersagen, nutzen Sie

Deny group StorageUsers to inspect object-family in compartment DataLake

Diese Policy verweigert sämtliche Berechtigungen (inspect, read, use, manage) für Objektspeicher-Ressourcen im Compartment DataLake. Zum Beispiel kann eine Gesundheitseinrichtung dies einsetzen, um StorageUsers vom Zugriff auf sensible Patientendaten auszuschließen und Datenschutzvorschriften einzuhalten.

Wie delegiere ich Aufgaben an Nutzer, die Policys in einem untergeordneten Compartment verwalten können, ohne ihnen Änderungen an bestimmten Ressourcen oder das Schreiben von Deny-Policys zu erlauben?

Um Aufgaben sicher an Benutzer zu delegieren, die Policys in einem untergeordneten Compartment verwalten können, können Sie

  • Über Allow-Policys gezielt Berechtigungen für bestimmte Compartments oder Ressourcen vergeben.
  • Schränken Sie die Rechte zum Erstellen von Deny-Policys ein, damit keine unerwünschten Policys erstellt werden können.
  • Verwenden Sie Deny-Policys, um den Zugriff auf besonders sensible Ressourcen zu blockieren.

Beispiel: Soll Nutzern die Verwaltung von Compute-Ressourcen in einem Compartment erlaubt werden, aber Änderungen an Netzwerken und das Schreiben von Deny-Policys verhindert werden, können Sie die folgenden Policys verwenden:

Deny group ProjectAdmins to manage network-family in compartment ProjectX Deny group ProjectAdmins to manage policies in compartment ProjectXwhere target.policy.type='DENY'

Allow group ProjectAdmins to manage instance-family in compartment ProjectX

Mit diesen Policys können ProjectAdmins Instanzen in ProjectX verwalten, aber keine Netzwerke ändern und keine Deny-Policys erstellen, wodurch eine sichere Delegation unterstützt wird. Ein Finanzunternehmen kann damit Sub-Admins Berechtigungen zur Verwaltung von Compute-Ressourcen einräumen und dennoch die Kontrolle über Netzwerksettings sowie Policys behalten.

Mechanismen für Sicherheit und Wiederherstellung

Werden Deny-Policys vor Allow-Policys geprüft?

Ja, OCI Identity and Access Management nutzt ein Deny-First-Prinzip: Es werden zuerst Deny-, danach Allow-Policys innerhalb der Compartment-Hierarchie ausgewertet. Entspricht eine Anfrage einer Deny-Policy, wird der Zugriff unabhängig von Allow-Policys verweigert. Die Standard-Administrationsgruppen sind von Deny-Policys ausgenommen, um einen vollständigen Ausschluss zu verhindern.

Beispielsweise können die folgenden Policys im Produktions-Compartment vorhanden sein:

Deny group Devs to manage instance-family in compartment Prod
Allow group Devs to manage all-resources in compartment Prod

Die Deny-Policy verhindert, dass Entwickler Instanzen verwalten, während Standardadministratoren dies weiterhin tun können.

Was passiert, wenn ein Nutzer eine Deny-Policy erstellt, die alle Benutzer in der Umgebung ausschließt?

Die Standardadministratorgruppe ist von Deny-Policys ausgenommen, sodass ihre Mitglieder sich anmelden, Policys ansehen und bearbeiten können, um Sperrungen aufzulösen. Diese Schutzmaßnahme verhindert Ausfälle auf Mandantenebene.

Beispiel: Wird „Deny any-user to inspect all-resources in tenancy“ verwendet, können Mitglieder der Standard-Administratorgruppe sich weiterhin anmelden und die Policy bearbeiten oder entfernen.

Wie kann ich eine mandantenweite Deny-Policy wiederherstellen, die alle Benutzer sperrt?

Eine mandantenweite Deny-Policy, wie z. B. „Benutzer verweigern“, um alle Ressourcen im Mandanten zu prüfen, kann den gesamten Benutzerzugriff blockieren, was zu einem Ausfall führt. Zum Wiederherstellen:

1. Melden Sie sich als Mitglied der Standard-Administratorgruppe an (ausgenommen von Deny-Policys).
2. Gehen Sie in der OCI-Konsole auf Identität & Sicherheit und dann zu Policys.
3. Suchen Sie die fehlerhafte Policy im Root Compartment.
4. Bearbeiten oder löschen Sie die Policy (z. B. ändern Sie „Deny any-user“ in „Deny group Interns“, um nur die gewünschte Gruppe einzuschränken).
5. Alternativ können Sie die folgende OCI-Befehlszeile nutzen: oci iam policy update --policy-id --statements '["Deny group Interns to inspect all-resources in tenancy"]

Wenn ein Benutzer mit Berechtigungen zur Policy-Verwaltung in einem untergeordneten Compartment versehentlich „Deny any-user to inspect all-resources in tenancy“ anwendet, kann ein Benutzer der Standard-Administratorgruppe sich anmelden und die Policy so anpassen, dass sie nur auf die Gruppe Guests abzielt. Dadurch werden zukünftige Sperren verhindert. Um solche Probleme zu vermeiden, testen Sie Policys gründlich und beschränken Sie die Erstellung von Deny-Policys auf ausgewählte Personen.

Auswirkungen von Berechtigungen

Was passiert, wenn ich die Berechtigung „manage“ verweigere?

Das Verweigern von „manage“ blockiert nur diese Berechtigung. „use“, „read“ und „inspect“ sind weiterhin erlaubt.

Beispiel: „Deny group DevOps to manage instance in compartment Production“ verhindert die Verwaltung von Instanzen durch DevOps, erlaubt aber deren Nutzung, Lesen und Inspektion.

Was passiert, wenn ich die Berechtigung „use“ verweigere?

Das Verweigern von „use“ blockiert sowohl „use“ als auch „manage“. „read“ und „inspect“ sind weiterhin erlaubt.

Beispiel: „Deny group Testers to use bucket in compartment QA“ verhindert für die Testers-Gruppe das Verwenden und Verwalten von Buckets, erlaubt jedoch das Lesen und Inspizieren.

Was passiert, wenn ich die Berechtigung „read“ verweigere?

Das Verweigern von „read“ blockiert „read“, „use“ und „manage“. „inspect“ ist weiterhin erlaubt.

Beispiel: „Deny group Auditors to read logs in compartment Logging“ verhindert, dass die Gruppe die Logs lesen, verwenden oder verwalten kann. Das Inspizieren ist weiterhin erlaubt.

Was passiert, wenn ich die Berechtigung „inspect“ verweigere?

Das Verweigern von „inspect“ blockiert alle Berechtigungen. Dazu gehören „inspect“, „read“, „use“ und „manage“. „inspect“ ist die grundlegende Basisberechtigung.

Beispiel: „Deny group Viewers to inspect instance in compartment Public“ verhindert für Viewers jeglichen Instanzzugriff.

Erweiterte Anwendungsfälle und Fehlerbehebung

Wie überwache ich Deny-Policys, um sicherzustellen, dass sie wie vorgesehen wirken?

Überprüfen Sie die OCI-Audit-Logs, um Aktionen nachzuverfolgen, die durch Deny-Policys blockiert wurden. Sollte zum Beispiel „Deny any-user to inspect cloud-shell in tenancy“ Probleme verursachen, schränken Sie sie präziser ein, z. B. durch „Deny group Interns to inspect cloud-shell in tenancy“. Richten Sie Benachrichtigungen für Policy-Änderungen ein, um proaktiv reagieren zu können.

Beispiel: Überwachen Sie Protokolle, um bei Bedarf „Deny group Drivers to manage instance-family in compartment Fleet“ anzupassen, falls legitime Aufgaben blockiert werden.

Welche typischen Fehler sollten bei Deny-Policys vermieden werden?

Das Deny-first-Modell von OCI priorisiert Deny-Policys gegenüber Allow-Policys. Sind Deny-Policys zu breit gefasst, kann dies zu Störungen im Betrieb führen. Häufige Fehler sind mandantenweite oder compartmentweite Sperren sowie zu breit gefasste, tagbasierte Bedingungen.

Eine Policy wie „Deny any-user to inspect all-resources in tenancy“ kann beispielsweise den gesamten Zugriff blockieren und zu einer mandantenweiten Sperre führen. Verwenden Sie stattdessen gezielte Policys, wie z. B.:

Deny group Interns to inspect all-resources in compartment Public

So wird der Zugriff nur für die Gruppe Interns eingeschränkt, und unbeabsichtigte Störungen werden vermieden. Ein Technologieunternehmen kann damit den Zugriff von Gästen einschränken und dennoch die Funktionen für andere Gruppen erhalten. Testen Sie Policys vorab in einer Sandbox, halten Sie sie möglichst einfach und beschränken Sie die Autorisierung zur Erstellung von Deny-Policys.

Werden Deny-Anweisungen für mandantenübergreifende Anwendungsfälle unterstützt?

Ja, Deny-Anweisungen unterstützen mandantenübergreifende Szenarios. Eine einzelne Deny-Endorse- oder Deny-Admit-Anweisung kann mandantenübergreifende Anfragen blockieren. Im Gegensatz dazu müssen bei Endorse/Admit-Paaren beide Bedingungen erfüllt sein.

Das folgende Beispiel zeigt einen Quellmandanten:

Endorse group Devs to use object-family in tenancy PartnerTenancy Deny endorse group Devs to manage object-family in tenancy PartnerTenancy

Dadurch können Entwickler den Objektspeicher im Partner-Mandanten verwenden, aber Verwaltungsaktionen blockieren. Ein Partnerunternehmen kann so Datenaustausch ermöglichen und gleichzeitig die Kontrolle über Ressourcen behalten.

Wie interagieren Deny-Policys mit OCI Zero Trust Packet Routing?

OCI Zero Trust Packet Routing arbeitet auf Layer 4 (Netzwerkebene) des Open Systems Interconnection-Modells. IAM Deny Policys setzen Zugriffsregeln auf Layer 7 (Applikationsebene) durch. Auch wenn OCI Zero Trust Packet Routing die Kommunikation erlaubt, können IAM Deny Policys Aktionen weiterhin blockieren.

Beispiel:

  • OCI Zero Trust Packet Routing-Policy: Lässt zu, dass dynamic-group FrontEnd im VCN web:vcn eine Verbindung zu backend:server-instance im VCN vcn:server herstellt, sodass Netzwerktraffic zulässig ist.
  • IAM-Policy: Deny dynamic-group FrontEnd to manage instance-family in compartment ProjectA blockiert die Verwaltung von Instanzen. Dies gilt auch dann, wenn OCI Zero Trust Packet Routing den Netzwerkverkehr erlaubt.

OCI Zero Trust Packet Routing und IAM-Policys werden nacheinander geprüft, wobei IAM letztlich den endgültigen Zugriff regelt.

Wie interagieren systemdefinierte Policys mit Deny-Policys?

Standardmäßige System-Policys haben stets Vorrang vor benutzerdefinierten Deny-Policys, um den Betrieb wesentlicher Services sicherzustellen (z. B. Allow any-user to read domains in tenancy where target.domain.id='request.domain.id').

Beispiel: „Deny group Users to read domains in tenancy“ blockiert keinen Zugriff, wenn eine Standard-System-Policy Domain-Zugriff erlaubt.

Werden Deny- und Allow-Policys unterschiedlich ausgewertet?

OCI Identity and Access Management verwendet ein Deny-First-Modell. Dabei werden Deny-Policys vor Allow-Policys in der Compartment-Hierarchie geprüft. Entspricht eine Anfrage einer Deny-Policy, wird der Zugriff unabhängig von Allow-Policys verweigert. Systemdefinierte Policys können benutzerdefinierte Deny-Policys übersteuern (siehe Frage 27). Standardmäßige Administratorgruppen sind von Deny-Policys ausgenommen. So bleibt die Verwaltung von Policys auch bei Sperren möglich.

Beispiel: Wenn „Deny group Users to manage instance-family in compartment Prod“ und „Allow group Users to manage all-resources in compartment Prod“ existieren, blockiert die Deny-Policy die Verwaltung von Instanzen.

Überschreibt IAM Deny die Oracle Administrationsrollen für Identitätsdomänen (z. B. Identity Domain Administrator, Security Administrator und User Manager)?

In der aktuellen Version überschreiben IAM Deny-Policys die Administrationsrollen von Oracle Identity Cloud Service nicht (z. B. Identity Domain Administrator, Security Administrator, User Manager). Dies ist eine Einschränkung. In der nächsten Version werden IAM Deny-Policys Vorrang vor den Oracle Identity Cloud Service-Administrationsrollen haben, um für konsistente Zugriffskontrolle zu sorgen.

Wie setze ich IAM Deny so ein, dass der Zugriff auf einen Service ausschließlich über das neue OCI Private Service Access erfolgt?

OCI Private Service Access ermöglicht den Zugang zu Oracle Services über einen privaten Netzwerkpfad anstelle des öffentlichen Internets. OCI Private Service Access wurde für Kunden entwickelt, die eine private Anbindung zwischen ihren Workloads und Oracle Services benötigen – wie z. B. aus Gründen der Compliance, Performance oder Sicherheit.

Wenn Sie OCI Private Service Access für sicheren Zugriff auf einen Service (z. B. OCI Object Storage oder OCI Streaming) einsetzen, können Sie durchsetzen, dass sämtlicher Zugriff nur über OCI Private Service Access erfolgt. Mit IAM Deny können Sie sämtlichen Datenverkehr zu einem Service blockieren, der nicht über OCI Private Service Access erfolgt – selbst wenn entsprechende Allow-Policys existieren.

Beispielsweise können Sie den Zugriff auf OCI Object Storage ausschließlich über OCI Private Service Access erlauben, indem Sie folgende Policy verwenden:

Deny any-user to access object-family in tenancy where any {not request.gateway.id, request.gateway.type !='privateserviceaccess'}

Diese Policy verhindert den Zugriff auf OCI Object Storage, es sei denn, der Datenverkehr wird über einen OCI Private Service Access-Endpunkt geleitet. Besonders nützlich ist dies, wenn Sie OCI Private Service Access für sensible Daten eingerichtet haben und den Zugriff über ungeplante öffentliche Wege komplett ausschließen möchten.

Was ist der Unterschied zwischen OCI Identity and Access Management Deny-Policys und Oracle Security Zones, und wann sollte ich sie einsetzen?

OCI bietet sowohl IAM Deny-Policys als auch Oracle Security Zones, um Ihren Mandanten durch das Verhindern unsicherer Aktionen abzusichern. Während beide die Sicherheit erhöhen, unterscheiden sie sich aber im Funktionsumfang und ihrer Flexibilität.

  • Gemeinsamkeiten: Sowohl IAM Deny-Policys als auch Oracle Security Zones verhindern gezielt bestimmte Aktionen, schützen Ihre Ressourcen und sorgen für die Einhaltung von Best Practices in Ihrer OCI-Umgebung.
  • Wesentliche Unterschiede
    • IAM Deny-Policys: Sie erstellen individuelle Policys, um Aktionen anhand von Kriterien wie Benutzeridentität, Ressourcentyp, IP-Adresse oder Tags zu sperren. Diese Policys dienen als Leitplanken und werden ab der nächsten Version Vorrang vor sämtlichen IAM-Policys haben. Beispielsweise lässt sich das Löschen kritischer Ressourcen für eine bestimmte Benutzergruppe blockieren, wenn die Ressource mit einem bestimmten Tag wie environment:production versehen ist.
    • Oracle Security Zones: Hierbei werden vordefinierte Sicherheitsregeln auf Compartments oder den gesamten Mandanten angewendet. Nach Aktivierung setzen Oracle Security Zones automatisch Einschränkungen für verschiedene OCI-Services durch, z. B. wird die Erstellung öffentlicher Subnetze verhindert oder eine Verschlüsselung erzwungen. Sie müssen keine Policys schreiben. Die Regeln sind integriert und prüfen Ressourceneinstellungen automatisch.
  • Zeitpunkt der Verwendung
    • Verwenden Sie IAM Deny Policies für individuelle, gezielte Einschränkungen. Beispielsweise zum Blockieren bestimmter Benutzer oder Aktionen. Die Bedingungen definieren Sie selbst.
    • Nutzen Sie Oracle Security Zones für automatische, vordefinierte Sicherheitsregeln. So setzen Sie Best Practices mit minimalem Aufwand durch.
    • Kombinieren Sie beide Ansätze für einen stärkeren Schutz. Aktivieren Sie Oracle Security Zones als grundlegende Leitplanken, und ergänzen Sie diese mit IAM Deny Policies für präzise, maßgeschneiderte Kontrollen.

Unterstützung zu OCI Identity and Access Management Deny-Policys

Weitere Unterstützung finden Sie in der OCI Identity and Access Management-Dokumentation oder bei Ihrem OCI-Account-Team.

Gruppen

Was ist eine Gruppe?

Eine Gruppe ist eine Sammlung von Benutzern, die ähnliche Zugriffsrechte benötigen, um eine bestimmte Ressource in Ihrem Account zu verwenden oder zu verwalten. Benutzer können mehreren Gruppen angehören. Berechtigungen sind additiv. Wenn die Mitgliedschaft in einer Gruppe beispielsweise die Verwendung von Compute-Instanzen durch Benutzer und die Mitgliedschaft in einer zweiten Gruppe die Verwaltung von Blockvolumes durch Benutzer ermöglicht, können die Benutzer sowohl Instanzen als auch Blockvolumes verwalten.

Administratoren schreiben Policys, die Gruppen (nicht einzelne Benutzer) mit dem erforderlichen Zugriff festlegen, der für ein bestimmtes Compartment oder den Account erforderlich ist. Administratoren fügen dann Benutzer zu den entsprechenden Gruppen hinzu.

Kann ich mehrere Administratoren haben?

Ja. Ihr Account ist mit einem einzelnen Standardadministrator ausgestattet, der zu einer Administratorgruppe in Ihrem Root Compartment gehört. Diese Gruppe verfügt über die vollständigen Berechtigungen zum Erstellen und Verwalten aller Oracle Cloud Infrastructure-Ressourcen in Ihrem Account, einschließlich Benutzern, Gruppen, Policys und Compartments sowie aller anderen Cloud-Infrastrukturressourcen in Compartments. Sie können dieser Administratorengruppe weitere Benutzer hinzufügen.

Features

Wie geht OCI IAM mit den Anforderungen für den Kennwortablauf um?

Mit Kennwort-Policys können Sie eine Ablaufzeit für Kennwörter festlegen. Eine standardmäßige Kennwort-Policy legt fest, dass Kennwörter nach 120 Tagen ablaufen. Dies ist konfigurierbar und verschiedene Policys können auf Benutzer-Untergruppen angewendet werden.

Wie kann ich Aufgaben auf einer Compute-Instanz ausführen, ohne Benutzerzugangsdaten darin einzubetten?

Verwenden Sie dynamische Ressourcengruppen, um einer Gruppe einen Satz von Compute-Ressource zuzuweisen. Anschließend können Sie dieser Gruppe über eine Policy Berechtigungen zuweisen. Dadurch kann eine Compute-Instanz sicher auf andere OCI-Ressourcen zugreifen, ohne Zugangsdaten in Skripte einzubetten.

Verbund

Was ist ein Identitätsverbund in Oracle Cloud Infrastructure?

Ein Identitätsverbund ist ein Mechanismus zum Delegieren der Benutzerverwaltung für Ihre Oracle Cloud Infrastructure-Tenancy an eine andere Entität, die Identitätsanbieter oder IdP genannt wird. Dies ist hilfreich für Unternehmen, die über ein vorhandenes Identitätssystem verfügen, das sie verwenden möchten, anstatt eine neue Gruppe von Benutzern zu erstellen und zu verwalten. Für den Verbund ist eine einmalige Konfiguration zwischen Oracle Cloud Infrastructure und dem als Verbundvertrauensstellung bekannten IdP erforderlich.

Was sind Verbundnutzer?

Verbundnutzer (externe Identitäten) sind Benutzer, die Sie außerhalb von Oracle Cloud Infrastructure verwalten (z. B. in Ihrem Unternehmensverzeichnis), denen Sie jedoch Zugriff auf Ihr Oracle Cloud Infrastructure-Account gewähren. Sie unterscheiden sich von Oracle Cloud Infrastructure-Benutzern, die in Ihrem Oracle Cloud Infrastructure-Account erstellt und verwaltet werden.

Können Verbundnutzer auf die Oracle Cloud Infrastructure-Konsole zugreifen?

Ja. Verbundnutzer können auf die Oracle Cloud Infrastructure-Konsole zugreifen.

Können Verbundnutzer auf Oracle Cloud Infrastructure SDK und CLI zugreifen?

Ja. Verbundnutzer können auf die Oracle Cloud Infrastructure SDK und CLI zugreifen.

Welche Aktionen können Oracle Cloud Infrastructure-Benutzer in der Konsole ausführen, die Verbundnutzer nicht ausführen können?

Verbundnutzer können ihre Passwörter in der Oracle Cloud Infrastructure-Konsole weder ändern noch zurücksetzen.

Wie kann ich steuern, was ein Verbundnutzer tun darf, wenn er bei der Konsole angemeldet ist?

Sie verwenden dieselben Oracle Cloud Infrastructure-Policys zum Verwalten von Verbundnutzern wie für native Benutzer. Sie ordnen Rollen und Gruppen in Ihren Identitätsanbietergruppen in Oracle Cloud Infrastructure zu. Wenn sich ein Verbundnutzer anmeldet, wendet die Oracle Cloud Infrastructure-Konsole Policys an, die auf der Oracle Cloud Infrastructure-Gruppenmitgliedschaft basieren, genau wie bei nativen Benutzern. Beispiele finden Sie in der Dokumentation.

Eine einzelne Rolle oder Gruppe in Ihrem Identitätsanbieter kann mehreren Oracle Cloud Infrastructure-Gruppen zugeordnet werden. Gleichermaßen können mehrere Rollen oder Gruppen in Ihrem Identitätsanbieter einer einzelnen Oracle Cloud Infrastructure-Gruppe zugeordnet werden.

Wie vielen Verbundnutzern kann ich Zugriff auf die Oracle Cloud Infrastructure-Konsole gewähren?

Die Anzahl der Verbundnutzer, denen Zugriff auf die Konsole gewährt werden kann, ist unbegrenzt.

Welche Identitätsanbieter werden unterstützt?

OCI IAM unterstützt jeden SAML 2.0-, Open ID Connect- oder OAuth-konformen Identitätsprovider, einschließlich gängiger Lösungen wie Oracle Access Manager, Microsoft Active Directory Federation Services (AD FS) und Okta.

Multifaktor-Authentifizierung

Was versteht man unter Multifaktor-Authentifizierung (MFA), und warum ist sie wichtig?

In der Vergangenheit wurden Konten mit einem einfachen Benutzernamen und einem Passwort gesichert. Passwörter sind jedoch schwer zu merken und können mit gängigen Cyberangriffstechniken wie Netzwerk-Sniffing, Phishing und Brute-Force-Angriffen relativ leicht geknackt werden. Wenn jemand Ihre Anmeldedaten stiehlt, kann diese Person sich für Sie ausgeben und auf alle Ihre Konten und Ressourcen zugreifen.

Die Multifaktor-Authentifizierung (MFA) ist ein beliebtes Sicherheitsfeature, das dazu beiträgt, das Risiko einer Kontoübernahme zu verringern, indem es die Sicherheit erhöht, dass ein Anwendungsbenutzer derjenige ist, der er vorgibt zu sein. MFA verlangt von den Nutzern, dass sie mehr als nur einen Authentifizierungsfaktor angeben. Es gibt drei Kategorien von Authentifizierungsfaktoren: etwas, was Sie wissen (z. B. ein Passwort oder eine PIN), etwas, was Sie haben (z. B. ein Sicherheits-Token oder eine Telefonnummer) und etwas, was Sie sind (z. B. biometrische Daten wie ein Fingerabdruck oder ein Gesichtsscan). Wenn MFA aktiviert ist, kann sich ein Angreifer, selbst wenn es ihm gelingen sollte, Ihr Passwort zu erlangen, nicht als Sie authentifizieren, ohne die von der MFA geforderten zusätzlichen Nachweise zu erbringen. Das kann unbefugten Zugriff verhindern und vor der Preisgabe sensibler Informationen oder vor unangemessenen Handlungen schützen. Die Aktivierung von MFA hilft außerdem bei der Einhaltung gesetzlicher Vorschriften und Industriestandards, wie z. B. denen des National Institute of Standards and Technology (NIST).

Wer sollte MFA nutzen?

Oracle empfiehlt allen Nutzern die Aktivierung von MFA. Zumindest sollten Sie MFA für Benutzer mit administrativen Rechten aktivieren, wie z. B. die Fähigkeit zum Erstellen und Verwalten von OCI-Ressourcen. Außerdem sollten Sie MFA für den Zugriff auf alle Anwendungen verlangen, die sensible Daten enthalten oder risikoreiche Maßnahmen ermöglichen.

Wie sieht die Benutzererfahrung bei aktivierter MFA aus?

Wenn MFA zum ersten Mal von einem Administrator aktiviert wird, werden die Nutzer bei ihrer nächsten Anmeldung aufgefordert, ihre MFA zu registrieren. Nach der Erstanmeldung werden die Nutzer bei jedem weiteren Besuch während des Anmeldevorgangs zur MFA aufgefordert. Wenn der Administrator die Option „vertrauenswürdige Geräte“ aktiviert, können Benutzer „diesem Gerät vertrauen“ auswählen, wodurch die Anforderung für MFA entfällt, wenn der Benutzer mit demselben Gerät zurückkehrt.

Weitere Informationen finden Sie in der folgenden Anleitung:

Ist MFA unter allen Umständen obligatorisch?

Nein, MFA ist nicht unter allen Umständen obligatorisch. Für den Zugang zu einer öffentlichen Website ist z. B. normalerweise überhaupt keine Authentifizierung erforderlich. Wenn Sie möchten, dass sich die Nutzer beim Kauf anmelden, damit Sie wissen, welches Konto belastet werden muss und wohin die Produkte geliefert werden sollen, reichen eventuell ein Benutzername und ein Passwort aus. Wenn aber derselbe Benutzer die Zahlungsmethode oder die Lieferadresse ändern möchte oder wenn die Anwendung Maßnahmen zulässt, die sich auf Ihr Unternehmen auswirken könnten, dann ist MFA empfehlenswert.

Oracle empfiehlt dringend, MFA für alle Cloud- und Anwendungsadministratoren zu aktivieren. Letztendlich müssen Sie basierend auf den internen Sicherheitsrichtlinien und der Risikobewertung Ihres Unternehmens abwägen, ob MFA durchgesetzt werden soll. Es ist jedoch ein bewährtes Verfahren, mit einer Richtlinie zu beginnen, die besagt, dass MFA immer obligatorisch ist, und die Genehmigung der Geschäftsleitung für alle Anwendungen zu verlangen, für die Sie MFA optional machen wollen.

Welche MFA-Faktoren sind für mich verfügbar? Fallen Kosten dafür an?

Um die verfügbaren Faktoren und Kosten gänzlich zu verstehen, müssen Sie zunächst verstehen, welche Art von OCI-Tenancy Sie haben. In dieser Dokumentation erfahren Sie, ob Ihre Tenancy OCI Identity and Access Management (IAM) mit Identitätsdomains oder OCI IAM ohne Identitätsdomains umfasst.

  • Wenn Ihre Tenancy über OCI IAM mit Identitätsdomains verfügt, unterstützen alle Identitätsdomaintypen MFA ohne zusätzliche Kosten. Identitätsdomains vom Typ „Free“ können zwar keine SMS als Authentifizierungsfaktor verwenden, doch andere Faktoren sind verfügbar. Weitere Informationen dazu finden Sie in der MFA-Dokumentation OCI IAM mit Identitätsdomains.
  • Wenn Ihre Tenancy OCI IAM ohne Identitätsdomains umfasst, haben Sie zwei Optionen für die MFA:
    • Aktivieren Sie MFA für die direkte Benutzeranmeldung über den OCI IAM-Service. Diese Option bietet eine begrenzte Anzahl von Authentifizierungsfaktoren ohne zusätzliche Kosten. Weitere Informationen dazu finden Sie in der MFA-Dokumentation OCI IAM ohne Identitätsdomains.
    • Authentifizieren Sie Benutzer mit Oracle Identity Cloud Service (IDCS). Diese Option bietet weitere MFA-Funktionen und Authentifizierungsoptionen.
  • Für die Authentifizierung mit IDCS gibt es zwei Lizenztypen:
    • Die IDCS Foundation (Free-Tier) unterstützt MFA nur beim Zugriff auf die OCI-Konsole kostenlos. Sie umfasst lediglich eine begrenzte Anzahl von Authentifizierungsfaktoren, wie hier dokumentiert. Um andere Anwendungen zu schützen, müssen Sie ein Upgrade auf IDCS Standard durchführen.
    • IDCS Standard unterstützt eine breite Palette von MFA-Optionen für alle geschützten Dienste oder Anwendungen ohne zusätzliche Kosten. Umfassende Details dazu finden Sie in der MFA-Dokumentation Identity Cloud Service (IDCS).

Wo kann ich mehr über die Implementierung von MFA erfahren?

Die genauen Anweisungen zur Implementierung von MFA variieren je nach Typ der OCI-Tenancy, die Sie haben. In dieser Dokumentation wird beschrieben, ob Ihre Tenancy OCI IAM mit Identitätsdomains oder OCI IAM ohne Identitätsdomains umfasst.

Was passiert, wenn ich keine MFA einführe?

Wenn Sie keine MFA implementieren, besteht ein erhöhtes Risiko, dass ein gezielter Angriff zur Übernahme eines Kontos erfolgreich ist. Mit MFA funktionieren Ihre Tenancy und/oder andere Authentifizierungsverfahren weiterhin normal.