Oracle Cloud Infrastructure - Dokumentation

Zugriff auf Oracle-Services: Servicegateway

In diesem Thema wird beschrieben, wie Sie ein Servicegateway einrichten und verwalten. Ein Servicegateway ermöglicht Cloud-Ressourcen ohne öffentliche IP-Adressen den privaten Zugriff auf Oracle-Services.

Zugriff auf Oracle-Services

Das Oracle Services Network ist ein konzeptionelles Netzwerk in Oracle Cloud Infrastructure, das für Oracle-Services reserviert ist. Diese Services verfügen über öffentliche IP-Adressen, die Sie normalerweise über das Internet erreichen. Sie können jedoch auf das Oracle Services Network zugreifen, ohne dass der Traffic über das Internet geleitet wird. Je nachdem, welche der Hosts Zugriff benötigen, gibt es unterschiedliche Möglichkeiten:

Highlights

  • Mit einem Servicegateway erhält Ihr virtuelles Cloud-Netzwerk (VCN) privaten Zugriff auf bestimmte Oracle-Services, ohne die Daten für das öffentliche Internet sichtbar zu machen. Für den Zugriff auf diese spezifischen Services ist kein Internetgateway oder NAT-Gateway erforderlich. Die Ressourcen im VCN können sich in einem privaten Subnetz befinden und nur private IP-Adressen verwenden. Der Traffic vom VCN zu dem Oracle-Service durchläuft das Oracle-Fabric, ohne jemals über das Internet geleitet zu werden.
  • Das Servicegateway ist regional und ermöglicht nur den Zugriff auf unterstützte Oracle-Services in derselben Region wie das VCN.
  • Für jedes VCN ist nur ein Servicegateway erforderlich. Alle Subnetze in einem VCN haben Zugriff auf das Servicegateway, wenn die Sicherheitsregeln und Routentabellenregeln diesen Zugriff zulassen.

  • Das Servicegateway ermöglicht den Zugriff auf unterstützte Oracle-Services innerhalb der Region, um Ihre Daten vor dem Internet zu schützen. Ihre Workloads benötigen möglicherweise Zugriff auf öffentliche Endpunkte oder Services, die vom Servicegateway nicht unterstützt werden (z.B. zum Herunterladen von Updates oder Patches). Stellen Sie sicher, dass Sie gegebenenfalls ein NAT-Gateway oder anderen Zugriff auf das Internet haben.

  • Die unterstützten Oracle-Services umfassen Oracle Cloud Infrastructure Object Storage und andere im Oracle Services Network. Eine Liste finden Sie unter Servicegateway: Unterstützte Cloud-Services im Oracle Services Network.
  • Das Servicegateway verwendet das Konzept eines Service-CIDR-Labels. Diese Zeichenfolge repräsentiert alle regionalen öffentlichen IP-Adressbereiche für den gewünschten Service oder eine Gruppe von Services (Beispiel: OCI PHX Object Storage ist die Zeichenfolge für Object Storage in US West (Phoenix)). Sie verwenden dieses Service-CIDR-Label beim Konfigurieren des Servicegateways und der zugehörigen Routingregeln, um den Traffic zum Service zu steuern. Sie können es optional beim Konfigurieren von Sicherheitsregeln verwenden. Wenn sich die öffentlichen IP-Adressen des Service in Zukunft ändern, müssen Sie diese Regeln nicht mehr anpassen.
  • Sie können ein VCN so einrichten, dass Ihr On-Premise-Netzwerk über das VCN und dessen Servicegateway privaten Zugriff auf Oracle-Services erhält. Die Hosts in Ihrem On-Premise-Netzwerk kommunizieren mit ihren privaten IP-Adressen, und der Traffic wird nicht über das Internet geleitet. Weitere Informationen finden Sie unter Privater Zugriff auf Oracle-Services.

Servicegateways - Überblick

Mit einem Servicegateway erhalten Ressourcen in Ihrem VCN privaten Zugriff auf bestimmte Oracle-Services, ohne die Daten für ein Internetgateway oder für NAT sichtbar zu machen. Die Ressourcen im VCN können sich in einem privaten Subnetz befinden und nur private IP-Adressen verwenden. Der Traffic vom VCN zu dem betreffenden Service durchläuft das Oracle-Fabric, ohne jemals über das Internet geleitet zu werden.

In dem folgenden einfachen Diagramm wird ein VCN dargestellt, das sowohl ein öffentliches Subnetz  als auch ein privates Subnetz  besitzt. Ressourcen im privaten Subnetz besitzen nur private IP-Adressen.

Das angezeigte VCN verfügt über drei Gateways:

  • Internetgateway: Dient dazu, dem öffentlichen Subnetz direkten Zugriff auf öffentliche Endpunkte im Internet zu ermöglichen. Verbindungen können aus dem Subnetz oder aus dem Internet initiiert werden. Die Ressourcen im öffentlichen Subnetz müssen öffentliche IP-Adressen haben. Weitere Informationen finden Sie unter Internetgateway.
  • Servicegateway: Dient dazu, dem privaten Subnetz privaten Zugriff auf unterstützte Oracle-Services innerhalb der Region zu ermöglichen. Verbindungen können nur aus dem Subnetz heraus initiiert werden.
  • NAT-Gateway: Dient dazu, dem privaten Subnetz privaten Zugriff auf öffentliche Endpunkte im Internet zu ermöglichen. Verbindungen können nur aus dem Subnetz heraus initiiert werden. Weitere Informationen finden Sie unter NAT-Gateway.

Sie steuern das Routing in Ihrem VCN auf der Subnetzebene. So können Sie angeben, von welchen Subnetzen im VCN jedes Gateway verwendet wird. Im Diagramm sendet die Routentabelle für das öffentliche Subnetz (Callout 1) nicht lokalen Traffic über das Internetgateway. Die Routentabelle für das private Subnetz (Callout 2) sendet Traffic, der für die Oracle-Services bestimmt ist, über das Servicegateway. Der gesamte verbleibende Traffic wird an das NAT-Gateway gesendet.

Diese Abbildung zeigt das grundlegende Layout eines VCN mit einem Servicegateway
Callout 1: Routentabelle für öffentliches Subnetz
Ziel-CIDR Routenziel
0.0.0.0/0 Internetgateway
Callout 2: Routentabelle für privates Subnetz
Ziel-CIDR Routenziel
OSN-Services in Region Servicegateway
0.0.0.0/0 NAT-Gateway
Wichtig

Informationen zur Konfiguration von Routingregeln mit einem Servicegateway als Ziel in Routentabellen, die mit öffentlichen Subnetzen verknüpft sind, finden Sie in diesem bekannten Problem.

Ein Servicegateway kann von Ressourcen im eigenen VCN des Gateways verwendet werden. Wenn das VCN jedoch per Peering mit einem anderen Netzwerk verknüpft ist, können Ressourcen in dem anderen VCN nur auf das Servicegateway zugreifen, wenn ein Servicegateway in beiden VCNs konfiguriert ist. Sie können Traffic, der für Oracle Services Network bestimmt ist und von einem Spoke stammt, so konfigurieren, dass er über eine virtuelle Netzwerk-Appliance (NVA) im Hub und dann über das Servicegateway des Hubs geleitet wird. Weitere Informationen finden Sie unter Private IP als Routenziel verwenden und Privater Zugriff auf Oracle-Services.

Ressourcen in Ihrem On-Premise-Netzwerk, das über FastConnect oder Site-to-Site-VPN mit dem VCN des Servicegateways verbunden ist, können das Servicegateway ebenfalls verwenden. Weitere Informationen finden Sie unter Privater Zugriff auf Oracle-Services.

Beachten Sie, dass Ihr On-Premise-Netzwerk ebenfalls das FastConnect-Public Peering für privaten Zugriff auf öffentliche Oracle-Services verwenden kann. Das bedeutet, dass Ihr On-Premise-Netzwerk durchaus mehrere Pfade haben kann, um auf öffentliche IP-Adressbereiche von Oracle-Services zuzugreifen. Ist dies der Fall, empfängt das Edge-Gerät Routen-Advertisements zu den öffentlichen IP-Adressbereichen der Oracle-Services über mehrere Pfade. Wichtige Informationen zur korrekten Konfiguration des Edge-Geräts finden Sie unter Routingdetails für Verbindungen zu Ihrem On-Premise-Netzwerk.

Für jedes VCN ist nur ein Servicegateway erforderlich. Alle Subnetze in einem VCN haben Zugriff auf das Servicegateway, wenn die Sicherheitsregeln und Routentabellenregeln diesen Zugriff zulassen.

Anweisungen zum Einrichten eines Servicegateways finden Sie unter Servicegateway in der Konsole einrichten.

Informationen zu Service-CIDR-Labels

Jeder Oracle-Service verfügt über einen regionalen öffentlichen Endpunkt, der öffentliche IP-Adressen für den Zugriff verwendet. Wenn Sie ein Servicegateway mit Zugriff auf einen Oracle-Service einrichten, richten Sie für den Networking-Service außerdem Routingregeln und optional Sicherheitsregeln ein, die den Traffic mit dem Service steuern. Das würde normalerweise bedeuten, dass Sie die öffentlichen IP-Adressen des Service wissen müssen, um diese Regeln einzurichten. Um dies zu vereinfachen, verwendet der Networking-Service Service-CIDR-Labels als Alias, der alle öffentlichen CIDRs für einen bestimmten Oracle-Service oder eine Gruppe von Oracle-Services darstellt. Wenn sich die CIDRs eines Service später ändern, müssen Sie die Routingregeln oder Sicherheitsregeln nicht anpassen.

Beispiele:

  • OCI PHX Object Storage ist ein Service-CIDR-Label, das alle Object Storage-CIDRs in der Region US West (Phoenix) darstellt.
  • All PHX Services in Oracle Services Network ist ein Service-CIDR-Label, das alle CIDRs für die unterstützten Services im Oracle Services Network in der Region US West (Phoenix) darstellt. Eine Liste der Services finden Sie unter Servicegateway: Unterstützte Cloud-Services im Oracle Services Network.

Wie Sie sehen, kann ein Service-CIDR-Label einem einzelnen Oracle-Service (Beispiel: Object Storage) oder mehreren Oracle-Services zugeordnet sein. Nachdem Sie einem Servicegateway ein Service-CIDR-Label zugewiesen haben, können Sie mit der Konsole zu dem anderen Label wechseln. Das Servicegateway muss jedoch immer ein Service-CIDR-Label aufweisen. Mit der API und der CLI können Sie das Service-CIDR-Label vollständig entfernen.

Der Begriff Service wird im Rahmen dieses Themas häufig anstelle des genaueren Begriffs Service-CIDR-Label verwendet. Hierbei ist zu beachten, dass Sie beim Einrichten eines Servicegateways (und zugehöriger Routingregeln) das gewünschte Service-CIDR-Label angeben müssen. In der Konsole werden die verfügbaren Service-CIDR-Labels angezeigt. Wenn Sie die REST-API verwenden, gibt der ListServices-Vorgang die verfügbaren Service-Objekte zurück. Das Attribut cidrBlock des Objekts Service enthält das Service-CIDR-Label (Beispiel: all-phx-services-in-oracle-services-network).

Verfügbare Service-CIDR-Labels

Nachfolgend finden Sie die verfügbaren Service-CIDR-Labels:

Wichtig

Informationen zum Zugriff auf Oracle YUM-Services über das Servicegateway finden Sie in diesem bekannten Problem.

Service-CIDR-Label für ein Servicegateway aktivieren

Um Ihrem VCN Zugriff auf ein bestimmtes Service-CIDR-Label zu erteilen, müssen Sie das Service-CIDR-Label für das Servicegateway des VCN aktivieren. Dies kann beim Erstellen des Servicegateways oder später erfolgen. Sie können ein Service-CIDR-Label für das Servicegateway auch jederzeit deaktivieren.

Wichtig

Da Object Storage sowohl von OCI <region> Object Storage als auch von All <region> Services in Oracle Services Network abgedeckt wird, kann ein Servicegateway nur eines dieser Service-CIDR-Labels verwenden. Ebenso kann eine Routentabelle eine einzelne Regel für eines der Service-CIDR-Labels aufweisen. Sie kann nicht zwei separate Regeln enthalten, eine für jedes Label.

Wenn für das Servicegateway die Verwendung von All <region> Services in Oracle Services Network konfiguriert ist, kann die Routingregel ein beliebiges der beiden CIDR-Labels verwenden. Wenn für das Servicegateway jedoch die Verwendung von OCI <region> Object Storage konfiguriert ist und die Routingregel All <region> Services in Oracle Services Network verwendet, wird der Traffic zu Services im Oracle Services Network (mit Ausnahme von Object Storage) verworfen. In der Konsole werden Sie daran gehindert, das Servicegateway und die entsprechende Routentabelle auf diese Weise zu konfigurieren.

Wenn Sie möchten, dass das Servicegateway ein anderes Service-CIDR-Label verwendet, lesen Sie Wenn Sie zu einem anderen Service-CIDR-Label wechseln.

Traffic über ein Servicegateway blockieren

Sie erstellen ein Servicegateway im Kontext eines bestimmten VCN. Anders ausgedrückt, das Servicegateway ist immer an dieses VCN angehängt. Sie können jedoch jederzeit Traffic über das Servicegateway blockieren oder zulassen. Standardmäßig lässt das Gateway den Trafficfluss beim Erstellen zu. Durch Blockieren des Servicegatewaytraffics wird der gesamte Traffic unterbunden, unabhängig davon, welche Service-CIDR-Labels aktiviert oder welche Routingregeln oder Sicherheitsregeln in Ihrem VCN vorhanden sind. Anweisungen zum Blockieren des Traffic finden Sie unter Traffic für ein Servicegateway steuern.

Routingregeln und Sicherheitsregeln für ein Servicegateway

Damit Traffic von einem Subnetz in Ihrem VCN an ein Servicegateway weitergeleitet werden kann, müssen Sie der Routentabelle des Subnetzes eine entsprechende Regel hinzufügen. Die Regel muss das Servicegateway als Ziel verwenden. Für das Ziel müssen Sie das Service-CIDR-Label verwenden, das für das Servicegateway aktiviert ist. Das bedeutet, dass Sie nicht die genauen öffentlichen CIDRs kennen müssen, die sich mit der Zeit ändern können.

Jeder Traffic, der das Subnetz verlässt und für die öffentlichen CIDRs des Service bestimmt ist, wird dann an das Servicegateway weitergeleitet. Wenn der Servicegatewaytraffic blockiert wird, fließt kein Traffic durch das Gateway, selbst wenn eine Routingregel für den entsprechenden Traffic vorhanden ist. Anweisungen zum Einrichten von Routingregeln für ein Servicegateway finden Sie unter Aufgabe 2: Routing für das Subnetz aktualisieren.

Die Sicherheitsregeln des VCN müssen ebenfalls den gewünschten Traffic zulassen. Bei Bedarf können Sie auch ein Service-CIDR-Label anstelle eines CIDR für die Quelle oder das Ziel des gewünschten Traffics verwenden. Wie bereits erwähnt, bedeutet dies, dass Sie nicht die genauen öffentlichen CIDRs für den Service kennen müssen. Der Einfachheit halber können Sie in Sicherheitsregeln auch dann ein Service-CIDR-Label verwenden, wenn Ihr VCN kein Servicegateway besitzt und der Traffic über ein Internetgateway zu den Services gelangt.

Sie können Sicherheitsregeln für zustandsbehafteten oder zustandslosen Traffic mit einem Service-CIDR-Label verwenden:

  • Bei Regeln für zustandsbehafteten Traffic: Erstellen Sie eine Egress-Regel, in der der Zielservice dem gewünschten Service-CIDR-Label entspricht. Wie bei jeder Sicherheitsregel können Sie andere Elemente angeben, wie z.B. das IP-Protokoll und die Quell- und Zielports.
  • Bei Regeln für zustandslosen Traffic: Sowohl Egress- als auch Ingress-Regeln sind erforderlich. Erstellen Sie eine Egress-Regel, in der der Zielservice dem gewünschten Service-CIDR-Label entspricht. Erstellen Sie außerdem eine Ingress-Regel, in der der Quellservice dem gewünschten Service-CIDR-Label entspricht. Wie bei jeder Sicherheitsregel können Sie andere Elemente angeben, wie z.B. das IP-Protokoll und die Quell- und Zielports.

Anweisungen zum Einrichten von Sicherheitsregeln, die ein Service-CIDR-Label verwenden, finden Sie unter Aufgabe 3 (optional): Sicherheitsregeln aktualisieren.

Object Storage: Bucket-Zugriff nur aus einem bestimmten VCN oder CIDR-Bereich zulassen

Wenn Sie mit einem Servicegateway auf Object Storage zugreifen, können Sie eine IAM-Policy schreiben, die den Zugriff auf einen bestimmten Object Storage-Bucket nur zulässt, wenn die folgenden Anforderungen erfüllt sind:

  • Die Anforderung durchläuft ein Servicegateway.
  • Die Anforderung stammt aus dem in der Policy angegebenen VCN.

Beispiele für diesen bestimmten IAM-Policy-Typ und wichtige Hinweise zu dessen Verwendung finden Sie unter Aufgabe 4 (optional): IAM-Policys aktualisieren, um den Zugriff auf Objektspeicher-Buckets einzuschränken.

Alternativ können Sie den Zugriff auf eine IP-Adresse oder Adressbereiche mit IP-basierter IAM-Filterung einschränken. Weitere Informationen finden Sie unter Netzwerkquellen verwalten.

Servicegateway löschen

Um ein Servicegateway zu löschen, muss sein Traffic nicht blockiert werden. Es darf jedoch keine Routentabelle vorhanden sein, in der es als Ziel aufgeführt wird. Siehe Servicegateway löschen.

Erforderliche IAM Policy

Um Oracle Cloud Infrastructure zu verwenden, muss Ihnen ein Administrator in einer Policy  Sicherheitszugriff erteilen. Dieser Zugriff ist erforderlich, unabhängig davon, ob Sie die Konsole oder die REST-API mit einem SDK, einer CLI oder einem anderen Tool verwenden. Wenn Sie eine Nachricht erhalten, dass Sie keine Berechtigung haben oder nicht autorisiert sind, fragen Sie den Administrator, welcher Zugriffstyp Ihnen erteilt wurde und in welchem Compartment  Sie arbeiten sollen.

Für Administratoren: Weitere Informationen finden Sie unter IAM-Policys für Networking.

Servicegateway in der Konsole einrichten

Weitere Informationen finden Sie unter Servicegateway erstellen.

Aufgabe 1: Servicegateway erstellen

Weitere Informationen finden Sie unter Servicegateway erstellen.

Aufgabe 2: Routing für das Subnetz aktualisieren

Wenn Sie ein Servicegateway für ein bestimmtes Service-CIDR-Label konfigurieren, müssen Sie auch eine Routingregel erstellen, die dieses Label als Destination und als Ziel das Servicegateway angibt. Führen Sie diesen Schritt für jedes Subnetz aus, das auf das Gateway zugreifen muss.

  1. Bestimmen Sie, welche Subnetze in Ihrem VCN Zugriff auf das Servicegateway benötigen.

  2. Für jedes dieser Subnetze aktualisieren Sie die Routentabelle des Subnetzes so, dass sie eine neue Regel mit den folgenden Werten enthält:

    • Zieltyp: Servicegateway.
    • Zielservice: Das Service-CIDR-Label, das für das Gateway aktiviert ist.
    • Compartment: Das Compartment, in dem das Servicegateway gespeichert ist.
    • Ziel: Das Servicegateway.
    • Beschreibung: Eine optionale Beschreibung der Regel.

Jeder Subnetztraffic mit einem Ziel, das der Regel entspricht, wird an das Servicegateway weitergeleitet. Weitere Informationen zum Einrichten von Routingregeln finden Sie unter VCN-Routentabellen.

Wenn Sie später das Servicegateway nicht mehr benötigen und es löschen möchten, müssen Sie zuerst alle Routingregeln in Ihrem VCN löschen, die das Servicegateway als Ziel angeben.

Tipp

Ohne das erforderliche Routing wird der Traffic nicht über das Servicegateway weitergeleitet. Wenn eine Situation auftritt, in der Sie den Traffic über das Gateway zu einem bestimmten Service vorübergehend stoppen möchten, können Sie einfach die Routingregel, die den Traffic zulässt, entfernen. Sie können dieses spezielle Service-CIDR-Label auch für das Gateway deaktivieren. Sie können den Traffic über das Servicegateway auch komplett blockieren. Sie müssen das Gateway nicht löschen.

Aufgabe 3 (optional): Sicherheitsregeln aktualisieren

Wenn Sie für ein Servicegateway den Zugriff auf ein Service-CIDR-Label konfigurieren, müssen Sie außerdem sicherstellen, dass die Sicherheitsregeln so konfiguriert sind, dass der gewünschte Traffic zulässig ist. Ihre Sicherheitsregeln lassen diesen Traffic möglicherweise bereits zu. Daher ist diese Aufgabe optional. Bei dem folgenden Verfahren wird davon ausgegangen, dass Sie Sicherheitslisten zur Implementierung Ihrer Sicherheitsregeln verwenden. In dem Verfahren wird beschrieben, wie Sie eine Regel einrichten, die das Service-CIDR-Label verwendet. Führen Sie diesen Schritt für jedes Subnetz aus, das auf das Gateway zugreifen muss.

Tipp

Sicherheitslisten sind eine Möglichkeit, den Traffic in die und aus den Ressourcen des VCN zu steuern. Sie können auch Netzwerksicherheitsgruppen verwenden, mit denen Sie ein Set von Sicherheitsregeln auf ein Set von Ressourcen anwenden können, die alle denselben Sicherheitsstatus aufweisen.
  1. Bestimmen Sie, welche Subnetze in Ihrem VCN eine Verbindung zu den gewünschten Services herstellen müssen.

  2. Aktualisieren Sie die Sicherheitsliste für jedes dieser Subnetze mit Regeln, um den gewünschten Egress- oder Ingress-Traffic mit dem jeweiligen Service zu ermöglichen.

    Angenommen, Sie möchten eine Regel für zustandsbehafteten Traffic hinzufügen, mit der Egress-HTTPS-Traffic (TCP-Port 443) vom Subnetz zu Object Storage und zu Oracle YUM-Repositorys aktiviert wird. Beim Hinzufügen einer Regel stehen folgende grundlegende Optionen zur Auswahl:

    1. Klicken Sie im Abschnitt Regeln für Egress zulassen auf +Regel hinzufügen.
    2. Lassen Sie das Kontrollkästchen Zustandslos deaktiviert.
    3. Zieltyp: Service.
    4. Zielservice: Das gewünschte Service-CIDR-Label. Um sowohl auf Object Storage als auch auf Oracle YUM-Repositorys zuzugreifen, wählen Sie All <region> Services in Oracle Services Network.
    5. IP-Protokoll: Behalten Sie "TCP" bei.
    6. Quellportbereich: Behalten Sie Alle bei.
    7. Zielportbereich: Geben Sie "443" ein.
    8. Beschreibung: Eine optionale Beschreibung der Regel.

Weitere Informationen zum Einrichten von Sicherheitsregeln finden Sie unter Sicherheitsregeln.

Aufgabe 4 (optional): IAM-Policys aktualisieren, um den Zugriff auf Objektspeicher-Buckets einzuschränken

Diese Aufgabe ist nur anwendbar, wenn Sie über ein Servicegateway auf Object Storage zugreifen. Sie können optional eine Netzwerkquelle erstellen und eine IAM-Policy schreiben, damit nur die Ressourcen in einem bestimmten VCN Objekte in einen bestimmten Bucket schreiben können.

Wichtig

Wenn Sie mit einer der folgenden IAM-Policys den Zugriff auf einen Bucket einschränken, ist der Bucket nicht über die Konsole zugänglich. Der Zugriff ist nur über das spezifische VCN möglich.

Darüber hinaus lassen IAM-Policys nur dann Anforderungen an Object Storage zu, wenn sie vom angegebenen VCN über das Servicegateway geleitet werden. Wenn sie das Internetgateway durchlaufen, werden die Anforderungen abgelehnt.

  • Erstellen Sie eine Netzwerkquelle, um das zulässige VCN anzugeben. Weitere Informationen zum Erstellen von Netzwerkquellen finden Sie unter Netzwerkquellen verwalten.
  • Erstellen Sie die Policy. Im folgenden Beispiel können Ressourcen in der ObjectBackup-Beispielgruppe Objekte in einen vorhandenen Bucket mit dem Namen db-backup schreiben, der sich in einem Compartment mit dem Namen ABC befindet. 
    Allow group ObjectBackup to read buckets in compartment ABC

Allow group ObjectBackup to manage objects in compartment ABC where
   all {target.bucket.name='db-backup', 
        request.networkSource.name='<VCN_NETWORK_SOURCE',
        any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}}

Sie können mehrere VCNs angeben, indem Sie mehrere Netzwerkquellen in der Policy erstellen und angeben. Das nächste Beispiel enthält Netzwerkquellen für zwei VCNs. Dies kann geschehen, wenn Sie Ihr On-Premise-Netzwerk mit privatem Zugriff auf Oracle-Services über ein VCN und darüber hinaus ein oder mehrere andere VCNs mit ihren eigenen Servicegateways eingerichtet haben. Weitere Informationen finden Sie unter Privater Zugriff des On-Premise-Netzwerks auf Oracle Services - Überblick. 

Allow group ObjectBackup to read buckets in compartment ABC

Allow group ObjectBackup to manage objects in compartment ABC where
   all {target.bucket.name='db-backup', 
        any {request.networkSource.name='<NETWORK_SOURCE_FOR_VCN_1>', request.networkSource.name='<NETWORK_SOURCE_FOR_VCN_2'},
        any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}}