Oracle Cloud Infrastructure - Ressourcen und Services
Oracle Cloud Infrastructure (OCI) stellt verschiedene Ressourcen und Services bereit, mit denen Sie Ihre Ressourcen steuern können. Erfahren Sie mehr über OCI-Services und darüber, wie Ihr Unternehmen ein Governance-Modell implementieren kann.
Ressourcen
Mit Oracle Cloud Infrastructure (OCI) können Sie Ihre Ressourcen organisieren und Governance in Ihrer Organisation implementieren. Erfahren Sie mehr über die physische und logische Organisation von OCI-Ressourcen und -Services.
Region
OCI wird physisch in geografischen Regionen und Availability-Domains gehostet. Eine Region ist ein bestimmter geografischer Bereich. Eine Availability-Domain umfasst mindestens ein Data Center innerhalb einer Region.
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center, die sogenannten Availability-Domains, enthält. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (auf Ländern oder sogar Kontinenten).
Eine Region besteht aus einer oder mehreren Availability-Domains. OCI-Ressourcen sind spezifisch für eine Region, wie ein virtuelles Cloud-Netzwerk, oder spezifisch für eine Availability-Domain, wie eine Compute-Instanz.
Availability-Domain
Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was Fehlertoleranz bietet. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung, Kühlung oder das interne Availability-Domainnetzwerk. Daher ist es wahrscheinlich, dass sich ein Fehler in einer Availability-Domain auf die anderen Availability-Domains in der Region auswirkt.
Wenn Sie Cloud-Services konfigurieren, verwenden Sie mehrere Availability-Domains, um High Availability sicherzustellen und Schutz vor Ressourcenausfällen zu bieten. Beachten Sie, dass einige Ressourcen innerhalb derselben Availability-Domain erstellt werden müssen, z.B. eine Instanz und das zugeordnete Speicher-Volume.
Faultdomain
Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen damit den physischen Serverausfall, die Systemwartung und Stromausfälle innerhalb einer Faultdomain tolerieren.
Beispiel: Ein Hardwarefehler oder Wartungsereignis für Compute-Hardware, die sich auf eine Faultdomain auswirken, hat keine Auswirkungen auf Instanzen in anderen Fehlerdomains.
Ressourcen identifizieren
Ein grundlegendes Konzept zur Identifizierung von OCI-Ressourcen ist die OCID (Oracle Cloud-ID). Es ist eine eindeutige ID, die Ressourcen in einem Oracle Cloud Infrastructure-(OCI-)Service identifiziert, der Metadaten zu den Ressourcen enthält. Die Ressource kann ein Benutzer, eine Gruppe, eine Instanz oder ein Service sein. Die Ressource, die eine Instanz eines Service oder Principals ist, ist eine Komponente der vollständigen OCID einer bestimmten Ressource.
OCI verwendet die OCID, um Policys für Ressourcen zu identifizieren und durchzusetzen, wenn Sie Governance in Ihrer Organisation implementieren. Im Folgenden werden die OCID-Syntax und die zugehörigen Komponenten dargestellt:
Oracle Cloud Infrastructure stellt die folgenden Services bereit, mit denen Sie Ihre Cloud-Ressourcen erstellen, organisieren und verwalten können.
ocid1.<RESOURCE TYPE>.<REALM>.[REGION][.FUTURE USE].<UNIQUE
ID>
- OCID1: Die literale Zeichenfolge, welche die Version der OCID angibt.
- Ressourcentyp: Der Typ der Ressource, wie Instanz, VCN, Benutzer oder Gruppe.
- Realm: Eine Realm ist eine Gruppe von Regionen, die Entitys gemeinsam verwenden, wie oc1 für die kommerzielle Realm, oc2 für die Government Cloud, oc3 für die Bundesregierung.
- Region: Die geografische Wohnsitzregion der Ressource befindet sich in phx, iad.
- Future Use: Gibt an, ob die Ressourcen für die zukünftige Verwendung reserviert sind.
- Unique ID: Der eindeutige Teil der ID.
Mandant
Ein Mandant ist eine sichere und isolierte Partition, die Oracle in Oracle Cloud einrichtet, wenn Sie sich für Oracle Cloud Infrastructure registrieren. Sie können Ihre Ressourcen in Oracle Cloud innerhalb Ihres Mandanten erstellen, organisieren und verwalten. Ein Mandant ist ein Synonym für eine Firma oder Organisation. Normalerweise hat ein Unternehmen einen einzelnen Mandanten und spiegelt seine Organisationsstruktur in diesem Mandanten wider. Ein einzelner Mandant ist in der Regel mit einem einzelnen Abonnement verknüpft, und ein einzelnes Abonnement hat in der Regel nur einen Mandanten.
Jede Ressource innerhalb einer Mandantenstruktur im Mandanten gehört zu einem Compartment (mit wenigen Ausnahmen), mit dem die Ressourcen logisch gruppiert und verwaltet werden können, um sie dem definierten Governance-Modell zu entsprechen. Eine Ressource wird im Mandanten für IaaS-, PaaS- und Infrastrukturkomponenten bereitgestellt, ist aber nicht auf virtuelle Cloud-Netzwerke (VCNs), Subnetze, Sicherheit und Routingregeln beschränkt.
Die meisten Core-Ressourcen gehören zu einem Compartment im Mandanten. Es gibt jedoch Kernressourcen, die global sind und außerhalb von Compartments leben.
Compartments
Compartments sind regionsübergreifende logische Partitionen in einem Oracle Cloud Infrastructure-Mandanten. Mit Compartments können Sie Ihre Ressourcen in Oracle Cloud organisieren, den Zugriff auf die Ressourcen kontrollieren und Nutzungsquoten festlegen. Um den Zugriff auf die Ressourcen in einem bestimmten Compartment zu kontrollieren, definieren Sie Policys, mit denen angegeben wird, wer auf die Ressourcen zugreifen kann und welche Aktionen sie ausführen können.
Gut konzipierte Compartments ermöglichen Ihrem Unternehmen Folgendes:
- Kontrollieren Sie den Zugriff durch Compartments, um eine SoD durchzusetzen und den Zugriff basierend auf Funktionen, wie Netzwerkressourcen oder Datenbanken, zu kontrollieren
- Administrative Berechtigungen an Compartment-Administratoren delegieren, um die entsprechenden Ressourcen zu verwalten
- Chargen-Back-Modell nach Abteilungen basierend auf den jeweiligen Compartments entwickeln
- Quotas und Budges auf Basis von Compartments definieren
Servicelimits
Wenn Sie sich für OCI registrieren, wird eine Reihe von Servicelimits für Ihren Mandanten konfiguriert. Das Servicelimit ist die Quote oder die zugeteilte Menge für eine Ressource. Beispiel: Ihr Mandant hat möglicherweise eine maximale Anzahl von Data Science-Serviceinstanzen zugelassen. Jede Ressource verfügt über einen definierten Grenzwert und Geltungsbereich. Die ursprünglich im Mandanten festgelegten Limits basieren auf einer Kombination aus Ressourcen, die in der Stückliste erworben wurden, und Werten, die als Standardwerte festgelegt wurden. Der Geltungsbereich von Servicelimits ist entweder regional oder Availability-Domain-spezifisch und bietet zusätzliche Flexibilität. Diese Limits können für Sie automatisch entsprechend Ihrer OCI-Ressourcennutzung und Ihrem Account-Stand erhöht werden.
Budgets
Sie können ein Budget angeben, um flexible Limits für Ihre OCI-Ausgaben festzulegen. Sie können auch Alerts für Ihr Budget festlegen, um Sie zu benachrichtigen, wenn die Nutzung Ihr Budget überschreitet. Über die OCI-Konsole können Sie alle Budgets und Ausgaben an einer zentralen Stelle anzeigen.
Compartment Quotas
Mit Compartment Quotas können Mandanten- und Compartment-Administratoren besser steuern, wie Ressourcen in OCI verbraucht werden. Mit Quotas können Administratoren Compartments über die Konsole einfach zuweisen. Compartment-Quotas stellen einen leistungsstarken Mechanismus zur Verwaltung Ihrer Ausgaben in OCI-Mandanten bereit.
Logging
- Auditlogs: Logs, die sich auf Ereignisse beziehen, die vom Audit-Service ausgegeben werden.
- Servicelogs: Logs, die von einzelnen Services ausgegeben werden, wie API-Gateway, Ereignisse, Funktionen, Load Balancing, Object Storage und VCN-Flusslogs.
- Benutzerdefinierte Logs: Logs, die Diagnoseinformationen von benutzerdefinierten Anwendungen, anderen Cloud-Providern oder einer On-Premise-Umgebung enthalten.
Loggruppen
Logische Container zur Organisation von Logs, mit denen der Zugriff auf Logs für eine begrenzte Benutzergruppe definiert/beschränkt wird. Sie können separate Loggruppen basierend auf der Vertraulichkeit der Logdaten erstellen.
Beispiel: Erstellen Sie drei Loggruppen: Sicherheit, Netzwerk und Anwendung.
- Erstellen Sie dann für jede Loggruppe OCI-IAM-Policys, um Admin-Benutzern Zugriff auf Blogs aus Loggruppen zu erteilen.
- Zulassen, dass die Gruppe SecOps den Loginhalt im Compartment-Logging liest, wobei:
target.loggroup.id=’ocid1.loggroup.oc1.<OCIRegion>..<SecurityLogGroupUniqueID>
Logginganalysen
Eine Cloud-Lösung in OCI, mit der Sie alle Logdaten aus Ihren Anwendungen und der Systeminfrastruktur indexieren, erweitern, aggregieren, untersuchen, suchen, analysieren, korrelieren, visualisieren und überwachen können.
Logging Analytics bietet mehrere Möglichkeiten, betriebliche Einblicke aus Ihren Logs zu gewinnen.
- Log Explorer-UI verwenden
- Loginformationen in Dashboards aggregieren
- Daten mit den APIs aufnehmen und analysieren
- Integration mit anderen OCI-Services
Cloud Guard

Beschreibung der Abbildung cloud-guard-detector-recipe.png
Mit Oracle Cloud Guard können Sie die Sicherheit Ihrer Ressourcen in Oracle Cloud Infrastructure überwachen und verwalten. Cloud Guard verwendet Detektorrezepte, die Sie definieren können, um Ihre Ressourcen auf Sicherheitsschwächen zu untersuchen und Operatoren und Benutzer auf riskante Aktivitäten zu überwachen. Wenn fehlerhafte oder unsichere Aktivitäten ermittelt werden, empfiehlt Cloud Guard Korrekturmaßnahmen und unterstützt die Durchführung dieser Aktionen basierend auf Responder-Rezepten, die Sie definieren können.
Detektorrezept
Eine Gruppe von Regeln/Prüfungen zur Identifizierung potenzieller Sicherheitsprobleme. Oracle stellt einige Baseline-Detektorrezepte für Services bereit, wie Objektspeicher-Buckets, Compute-Instanzen, VCN-Instanzen, IAM-Benutzer und -Gruppen, Load Balancer, Sicherheitslisten und Netzwerksicherheitsgruppen. Sie können die Rezeptregel für von Oracle verwaltete Rezepte nicht aktualisieren. Sie können jedoch von Oracle verwaltete Rezepte klonen und neue Rezepte erstellen, die als benutzerverwaltete Detektorrezepte bezeichnet werden.
Rezepte für Regeln zur Erkennung von Problemen
- Von Oracle verwaltete Rezepte
- Vom Benutzer verwaltete Rezepte
- Konfigurationsdetektorrezepte
- Öffentlicher Bucket
- Instanz hat eine öffentliche IP-Adresse
- LB-SSL-Zertifikat läuft in Kürze ab
- Aktivitätsmelderrezepte
- Benutzer einer Gruppe hinzugefügt
- Compute-Instanz gelöscht
Konfigurationsdetektorrezepte prüfen Ressourcenkonfigurationen. Prüfen Sie beispielsweise, ob der Speicher-Bucket öffentlich ist oder ob ein NAT-Gateway oder Internetgateway in einem VCN erstellt wurde. Andere Detektorrezepte erkennen Aktivitäten wie das Erstellen einer dynamischen Gruppe oder das Hinzufügen einer VNIC zur VM.
Rezept des Antwortenden
Eine Gruppe von Regeln zur Behebung des erkannten Problems oder zum Senden einer Benachrichtigungsanforderung. Das Standard-Responder-Rezept bietet keine Option zur Behebung jedes Problems. Sie können dies jedoch beheben, indem Sie Funktionen aus Ereignissen aufrufen. Sie ergreifen Korrekturmaßnahmen oder beheben das Problem mit der OCI-Funktion.
Wie Detektorrezepte gibt es von Oracle verwaltete Responder-Rezepte und vom Kunden verwaltete Responder-Rezepte. Vom Kunden verwaltete Responder-Rezepte sind ein Klon von Oracle verwalteter Rezepte, in denen Sie einige der vordefinierten Responder-Regeln deaktivieren können.
Ziel
Ein Ziel definiert den Geltungsbereich der Prüfung durch Cloud Guard. Sie enthält eine Liste der Compartments. Wenn Sie ein Compartment als Ziel hinzufügen, prüft Cloud Guard auch alle Sub-Compartments. Ziele werden definiert, wo Compartments, Detektorrezepte und Responder-Rezepte miteinander verbunden sind.
Tagging
Tags enthalten Metadaten, Schlüssel/Wert-Paare, die an Ressourcen angehängt sind und deren Attribute wie Verwendung, Kosten oder Eigentümer definieren.
Taggrundlagen
Tag-Namespace (nur für definierte Tags anwendbar)
Tag-Namespace ist ein Container für Ihre Tags. Er besteht aus einem Namen sowie null oder mehr Tagschlüsseldefinitionen. Tag-Namespace ist mandantenübergreifend eindeutig.
Tagschlüssel
Der Name, mit dem Sie auf das Tag verweisen. Tagschlüssel sind im Namespace eindeutig.
Tagwerttyp
Gibt den für den Wert zulässigen Datentyp an. Es gibt zwei unterstützte Datentypen: Zeichenfolge und eine Liste von Zeichenfolgen.
Tagwert
Der Wert, den der Benutzer auf die Tags anwendet. Einige Tags haben vordefinierte Werte. Benutzer müssen einen Wert aus der Werteliste für andere Tags auswählen.
Eine Ressource, bei der es sich um eine Instanz eines Service in einem Compartment handelt, kann ein oder mehrere Tags haben. Tags, die einem Compartment zugewiesen sind, werden allen Ressourcen im Compartment zugewiesen.
Es gibt zwei Möglichkeiten, Ressourcen Tags zuzuweisen.
Definierte Tags
Vordefinierte Tags, bei denen Administratoren die Metadaten verwalten, werden häufiger verwendet. Beispiel: Um Ressourcenmetadaten zu erstellen, um Ressourcen zu verwalten oder Daten zu erfassen, können Sie definierte Tags verwenden. Es gibt drei Typen von definierten Tags basierend auf deren Verwendung und der Zuweisung von Werten.
-
Tags mit vordefinierten Werten
Sie können eine Werteliste erstellen und diese Liste mit einer Tagschlüsseldefinition verknüpfen. Wenn Benutzer das Tag auf eine Ressource anwenden, müssen sie einen Wert aus der Liste vordefinierter Werte auswählen. Verwenden Sie Listen mit vordefinierten Werten, um Limits für die Werte festzulegen, auf die Benutzer angewendet werden können.
-
Tags für Kostenverfolgung
Tags, die beim Festlegen von Budgets zur Verwaltung der Kosten der Ressourcennutzung verwendet werden.
-
Tagstandardwerte
Sie können Standardtags definieren, die auf alle Ressourcen angewendet werden, wenn sie in einem bestimmten Compartment erstellt werden. Durch das Einrichten von Tagstandardwerten wird sichergestellt, dass die entsprechenden Tags bei der Ressourcenerstellung angewendet werden, ohne dass der Benutzer, der die Ressource erstellt, Zugriff auf die Tag-Namespaces haben muss. Verwenden Sie Tagvariablen, um effizient Tagstandardwerte für Ressourcen zu erstellen, die in einem Compartment erstellt wurden. Beispiel:$(iam.principal.name}, $(iam.principal.type}, ${oci.datetime}
Beliebiges Format
Benutzerdefinierte nicht verwaltete Metadaten, die während des Lebenszyklus einer Ressource auf Ressourcen angewendet werden.