Oracle Cloud Infrastructure-Dokumentation

Einige allgemeine Features

Im Hinblick auf die Anpassung von Oracle Cloud Guard gibt es einige Features, die in mehreren Bereichen vorkommen.

Sie können eine Vorschau dieser Features in den folgenden Abschnitten anzeigen, bevor Sie mit der Anpassung von Cloud Guard beginnen. Sie können auch Links aus bestimmten Aufgaben folgen, in denen die Informationen hilfreich sind.

Überblick über Rezepte

Machen Sie sich mit den Unterschieden zwischen den von Oracle und den vom Benutzer verwalteten Rezepten und mit der Funktionsweise von vom Benutzer verwalteten Rezepten vertraut. Erfahren Sie außerdem, welche Einstellungen auf Rezept- und Zielebene geändert werden können.

Die drei folgenden Abschnitte werden auch unter OCI-Responder-Rezepte und OCI-Detektorrezepte angezeigt.

Von Oracle verwaltete und vom Benutzer verwaltete Rezepte

Machen Sie sich mit den Unterschieden zwischen diesen beiden Rezeptkategorien vertraut.

Cloud Guard bietet sowohl für Detektoren als auch Responder ein umfangreiches Set aus von Oracle verwalteten Rezepten für:

  • OCI-Aktivitätsdetektoren
  • OCI-Konfigurationsdetektoren
  • Detektoren für OCI Container Security Config
  • OCI-Instanzsicherheitsdetektoren
  • OCI-Bedrohungsdetektoren
  • Responder

Obwohl Sie die von Oracle verwalteten Rezepte unverändert verwenden können, müssen Sie in manchen Fällen Änderungen vornehmen, um sie an die spezifischen Anforderungen Ihrer Umgebung anzupassen. Insbesondere möchten Sie möglicherweise die Risikostufe für einige Regeln ändern und andere Regeln komplett deaktivieren. Um diese Arten von Änderungen vorzunehmen, klonen Sie zunächst das Rezept, um eine vom Benutzer verwaltete Kopie zu erstellen. Dann können Sie Änderungen an der Kopie vornehmen.

Wenn neue Detektorregeln zu einem von Oracle verwalteten Rezept hinzugefügt werden, werden die Regeln automatisch zu allen vom Benutzer verwalteten (geklonten) Kopien dieses Rezepts mit den Standardwerten aus der von Oracle verwalteten Quelle hinzugefügt. Anschließend können Sie die Konfiguration der neuen Regel in den vom Benutzer verwalteten Kopien des Rezepts ändern.

Die folgende Tabelle enthält ein Beispiel für drei Detektorregeln aus dem von Oracle verwalteten Rezept und zeigt, wie eine vom Benutzer verwaltete Kopie geändert werden kann. Änderungen für die vom Benutzer verwalteten Regeln werden fettgedruckt dargestellt:

von Oracle verwaltetes Rezept Vom Benutzer verwaltetes Rezept
Regel Status Risikostufe Status Risikostufe
Bucket ist öffentlich Aktiviert Hoch DEAKTIVIERT Hoch
KMS-Schlüssel nicht rotiert Aktiviert Mittel Aktiviert HOCH
Instanz hat öffentliche IP-Adresse Aktiviert Kritisch Aktiviert Kritisch

Sie können dasselbe von Oracle verwaltete Rezept beliebig oft klonen, um vom Benutzer verwaltete Kopien zu erstellen, die für besondere Zwecke fein abgestimmt werden. Gründe für unterschiedliche Rezepte:

  • Unterschiedliche Behandlung von Nicht-Produktions- und Produktions-Workloads
  • Separate Vorgänge oder Benachrichtigungsprozesse für Ressourcen in verschiedenen Compartments
  • Regionale Anforderungen an Ressourcen in einigen Compartments
  • Verschiedene Ressourcentypen, die unterschiedliche Regeln für Konfiguration oder Aktivität erfordern
So funktionieren vom Benutzer verwaltete (geklonte) Detektoren und Responder

Erfahren Sie, wie ein vom Benutzer verwaltetes Rezept weiterhin mit dem von Oracle verwalteten Rezept, aus dem es geklont wurde, verknüpft bleibt.

  • Beim Klonen eines von Oracle verwalteten Rezepts wird eine benutzerdefinierte Kopie erstellt. Die vom Benutzer verwaltete Kopie entspricht genau dem von Oracle verwalteten Original. Sie können sie jedoch anpassen.

    Änderungen, die Sie in der geklonten Kopie vornehmen, einschließlich Änderungen an Regeleinstellungen, wirken sich nicht auf das ursprüngliche Detektor- oder Responder-Rezept aus.

  • Sie können nicht alles in den vom Benutzer verwalteten Rezepten ändern. Für einzelne Regeln können Sie die Risikostufe ändern. Außerdem können Sie die Regel aktivieren und deaktivieren und ihre Risikostufe ändern. Sie können keine Regeln löschen oder neue Regeln hinzufügen.
  • Um ein vom Benutzer verwaltetes Rezept zu verwenden, müssen Sie es einem Ziel hinzufügen. Jedem Ziel kann nur ein Rezept für jeden Typ hinzugefügt werden: Konfigurationsdetektoren, Aktivitätsdetektoren und Responder. Wenn ein Ziel bereits ein Rezept des hinzuzufügenden Typs enthält, müssen Sie dieses Rezept entfernen, bevor Sie ein anderes Rezept desselben Typs hinzufügen können. Siehe OCI-Ziel und seine angehängten Rezepte bearbeiten.
  • Cloud Guard synchronisiert Ihre benutzerdefinierten Rezepte mit den Originalrezepten, die von Oracle verwaltet werden. Alle neuen Regeln, die dem ursprünglichen von Oracle verwalteten Rezept hinzugefügt wurden, werden automatisch zu den geklonten Kopien hinzugefügt. Außerdem werden alle Verbesserungen an Regeln im ursprünglichen von Oracle verwalteten Rezept automatisch an dieselben Regeln in den geklonten Kopien übertragen.
  • Suchen Sie nach neuen Regeln, die den benutzerdefinierten Rezepten hinzugefügt werden. Alle neu hinzugefügten Regeln werden standardmäßig deaktiviert. Prüfen Sie neue Regeln genau, um zu ermitteln, ob Sie sie aktivieren möchten. Informationen zu diesen Updates finden Sie in den Cloud Guard-Releasehinweisen.
  • Überwachen Sie die Liste der Regeln, die Sie in einem benutzerdefinierten Rezept deaktivieren, um festzustellen, ob einige von ihnen aktiviert werden müssen. Nach einiger Zeit möchten Sie möglicherweise einige der Rezepte verwenden, die Sie zuvor deaktiviert haben. Informationen zu diesen Updates finden Sie in den Cloud Guard-Releasehinweisen.
Rezepte auf Rezept- und Zielebene ändern

Hier erfahren Sie, wie Oracle Cloud Guard Rezepteinstellungen in zwei Ebenen unterteilt und wie Sie verschiedene Einstellungen für von Oracle verwaltete oder benutzerverwaltete (geklonte) Detektor- und Responder-Rezepte auf diesen beiden Ebenen aktualisieren.

Cloud Guard teilt die Einstellungen, die Sie für Detektor- und Responder-Regeln konfigurieren können, in zwei Gruppen auf Rezept- und Zielebene auf. Sie können von verschiedenen Seiten auf diese Ebenen zugreifen:

Wenn Sie die Details nicht verstehen, kann die Verwaltung von Detektor- und Responder-Rezepten in Oracle Cloud Guard verwirrend werden. Im Abschnitt Detektorrezeptreferenz am Ende dieses Abschnitts werden die Informationen für alle Rezepttypen zusammengefasst, wenn Sie von der Seite Ziele oder den entsprechenden Rezeptseiten darauf zugreifen.

Hinweis

Wenn Sie ein von Oracle verwaltetes Rezept aktualisieren, werden die Aktualisierungen automatisch auf alle vom Benutzer verwalteten Rezepte angewendet, die daraus geklont wurden. Unabhängig davon, von welcher Seite Sie mit der Änderung eines Rezepts beginnen, bleiben die Änderungen bestehen, wenn Sie von der anderen Seite auf das Rezept zugreifen.
  • Einstellungen auf Rezeptebene sind "strategisch". Das heißt, sie haben die umfassendsten Auswirkungen und wirken sich auf alle Ziele aus, an die das Rezept angehängt wurde. Diese Einstellungen sollten die höchste Berechtigungsebene erfordern, um Änderungen vorzunehmen.
    • Sicherheitsprinzip: Rezepteinstellungen haben umfassende Auswirkungen in Cloud Guard. Daher sollte es nur wenigen Benutzern erlaubt sein, die Einstellungen auf dieser Ebene zu ändern.
    • Einstellungen, die Sie auf Rezeptebene ändern können:
      • Detektoren:
        • Status (Regel aktivieren oder deaktivieren, nur vom Benutzer verwaltet).
        • Risk Level (nur vom Benutzer verwaltet).
        • Labels (nur vom Benutzer verwaltet).
        • Eingabeeinstellung (sofern für die Regel zutreffend).
        • Einstellungen für Bedingungsgruppe.
      • Bearbeiter:
        • Status (Regel aktivieren oder deaktivieren, nur vom Benutzer verwaltet).
    • Umfang: Änderungen für Detektor- und Responder-Regeln auf Rezeptebene:
      • Statusänderungen (Regeln aktivieren oder deaktivieren):
        • Können nur für benutzerverwaltete (geklonte) Rezepte vorgenommen werden.
        • Gelten global für alle Ziele, bei denen der Detektor oder Responder bereits angehängt wurde oder später angehängt wird.
      • Einstellungen für Bedingungsgruppe:
        • Geben Sie die Standardwerte für alle Ziele an, in denen das Detektor- oder Responder-Rezept später hinzugefügt wird.
        • Nachdem ein Rezept einem Ziel hinzugefügt wurde, können Änderungen in den Bedingungsgruppeneinstellungen nur aus diesem Ziel vorgenommen werden.
      • Policy-Anweisungen (nur für Responder-Regeln auf Zielebene):
        • Die Aktivierung einer Policy-Anweisung ist global und gilt für alle Responder-Regeln, die eine Policy erfordern, sowohl auf Rezept- als auch auf Zielebene.
        • Sie müssen eine Policy nur einmal in einem Mandanten aktivieren.
    • Zugriff: Greifen Sie von den Rezeptseiten Detektorrezepte oder Responder-Rezepte auf die Detektor- und Responder-Regeln zu, um diese Einstellungen zu ändern, wie oben beschrieben.
  • Einstellungen auf Zielebene sind "taktisch". Das heißt, sie wirken sich nur auf ein einziges Ziel aus und können daher eine niedrigere Berechtigung erfordern, um Änderungen vorzunehmen.
    • Sicherheitsprinzip: Ziele haben in der Regel geringfügigere Auswirkungen, die sich nur auf eine Teilmenge Ihrer Compartments auswirken. Daher können mehr Benutzer die Berechtigung erhalten, Einstellungen auf dieser Ebene zu ändern.
    • Einstellungen, die Sie auf Zielebene ändern können:
      • Detektoren:
        • Bedingungsgruppen (nur vom Benutzer verwaltet).
      • Bearbeiter:
        • Status (Regel aktivieren oder deaktivieren, nur vom Benutzer verwaltet).
        • Eingabeeinstellungen zum Aktivieren oder Deaktivieren der Benachrichtigung nach der Korrektur (sofern für die Regel anwendbar).
        • Ändern Sie den Regeltrigger zwischen Automatisch ausführen und Vor Ausführen der Regel fragen....
        • Andere Einstellungen ändern (z.B. Erforderliche Policy-Anweisungen und Korrekturbenachrichtigung aktivieren oder deaktivieren).
    • Umfang: Änderungen an Detektor- und Responder-Regeln auf Zielebene gelten für Folgendes:
      • Im Allgemeinen gelten Änderungen für das aktuelle Ziel. Änderungen wirken sich nicht auf Einstellungen in Zielen aus, in denen das Detektor- oder Responder-Rezept bereits angehängt wurde. Nachdem Rezepte an ein Ziel angehängt wurden, müssen weitere Änderungen in den Einstellungen für dieses Ziel aus demselben Ziel vorgenommen werden. Änderungen, die später auf Rezeptebene vorgenommen wurden, aktualisieren automatisch das an das Ziel angehängte Rezept.
      • Um erforderliche Policys zu aktivieren und Korrekturbenachrichtigungen zu aktivieren und zu deaktivieren (nur für Responder-Rezepte), geben Änderungen die Standardwerte für alle Ziele an, denen das benutzerdefinierte (geklonte) Detektor- oder Responder-Rezept später hinzugefügt wird.
    • Zugriff: Greifen Sie von der Seite Ziele auf die Detektor- und Responder-Regeln zu, um diese Einstellungen wie oben beschrieben zu ändern.
  • Übersicht über wichtige Einschränkungen: Einige Einstellungen können nur auf Rezept- oder Zielebene oder nur in von Oracle oder von einem Benutzer verwaltetem Rezept geändert werden:
    • Detektoren:
      • Status (Regel aktivieren oder deaktivieren): Nur in benutzerdefinierten Rezepten, auf Rezeptebene.
      • Risikoebene: Nur in benutzerdefinierten Rezepten, auf Rezeptebene.
      • Labels: Nur im benutzerdefinierten Rezept, auf Rezeptebene.
    • Responder:
      • Status (Regeln aktivieren oder deaktivieren): Nur im vom Benutzer verwalteten Rezept, nur auf Rezeptebene.
      • Eingabeeinstellungen zum Aktivieren oder Deaktivieren der Benachrichtigung nach der Korrektur (sofern für die Regel anwendbar): Nur auf Zielebene (sowohl für von Oracle als auch vom Benutzer verwaltete Rezepte).
      • Regel-Trigger (zwischen Automatisch ausführen und Vor Abfragen...): Nur auf Zielebene (für von Oracle und vom Benutzer verwaltete Responder-Rezepte).

In der folgenden Tabelle werden die Detektor- und Responder-Regeleinstellungen zusammengefasst, die Sie auf Rezept- und Zielebene für sowohl von Oracle als auch vom Benutzer verwaltete Rezepte ändern können.

Arten von Änderungen (unten)

 Änderungen des Detektorrezepts auf... Änderungen des Responder-Rezepts auf...
Von Oracle verwaltet Von Benutzer verwaltet (geklont) Von Oracle verwaltet Von Benutzer verwaltet (geklont)
Seite "Rezepte" Seite "Ziele" Seite "Rezepte" Seite "Ziele" Seite "Rezepte" Seite "Ziele" Seite "Rezepte" Seite "Ziele"
Status (Regeln aktivieren und deaktivieren) Nein Nein Ja Nein Nein Nein Ja Nein
Risikostufe Nein Nein Ja Nein N/V N/V N/V N/V
Beschriftungen Nein Nein Ja Nein N/V N/V N/V N/V
Eingabeeinstellungen Ja Nein Ja Nein Nein Ja Nein Ja
Bedingungsgruppen Ja Ja Ja Ja Nein Ja Nein Ja
Aktivieren Sie Policy-Anweisungen N/V N/V N/V N/V Nein Ja Nein Ja
Regeltrigger (manuelle oder automatische Ausführung) N/V N/V N/V N/V Nein Ja Nein Ja
Benachrichtigung nach Korrektur (Einstellung) N/V N/V N/V N/V Nein Ja Nein Ja
Anweisungen finden Sie unter: Thema Thema Thema Thema Thema Thema Thema Thema
Compartment-Vererbung

Sie ordnen eine Compartment-Hierarchie einem Ziel zu. Die Detektorrezepte, die Sie an das Ziel anhängen, überwachen die Ressourcen in der Compartment-Hierarchie.

Wenn ein Compartment andere untergeordnete Compartments aufweist, gelten die Regeln des Detektorrezepts automatisch für alle untergeordneten Compartments in der Hierarchie.

Wenn in einer Compartment-Hierarchie Detektorrezepte auf Compartments auf verschiedenen Ebenen angewendet werden und ein Regelkonflikt auftritt, setzen die Regeln aus dem Detektorrezept, das auf einer niedrigeren Ebene angewendet wird, die Regeln aus jedem Detektorrezept auf höherer Ebene außer Kraft. Das gilt für das Compartment, auf das ein Detektorrezept angewendet wird, sowie für alle untergeordneten Compartments.

Vererbungsdetails für Detektorregelfelder

Es gibt vier Ebenen, auf denen die Felder in einem Detektorrezept und dessen Detektorregeln geändert werden können. Jede hat ihre eigenen Einschränkungen.

Hinweis

Die Priorität für Detektorrezeptregeln, die auf diesen verschiedenen Ebenen angewendet werden, ähnelt der Priorität für eine Compartment-Hierarchie: Bei einem Regelkonflikt setzen die Regeln auf einer spezifischeren Ebene (höhere Zahl in Liste unten) die Regeln auf einer umfassenderen Ebene (niedrigere Zahl in Liste unten) außer Kraft.
  1. Oracle: Wenn Cloud Guard von Oracle verwaltete Rezepte aktualisieren oder erstellen muss, stehen diese allen Mandanten zur Verfügung.
  2. Tenant: Diese Änderungen gelten nur für einen bestimmten Mandanten.
    • Diese Felder können auf Mandantenebene für ein von Oracle verwaltetes Rezept geändert werden:
      • Labels ( können nur hinzugefügt werden)
      • Konfiguration (auch als Einstellungen bezeichnet)
      • Bedingungen
    • Diese Felder können nicht auf Mandantenebene für ein von Oracle verwaltetes Rezept geändert werden:
      • Status (Aktiviert/Deaktiviert)
      • Risikostufe
    • Diese Felder können auf Mandantenebene für ein nicht von Oracle verwaltetes Rezept geändert werden:
      • Status (Aktiviert/Deaktiviert)
      • Risikostufe
      • Beschriftungen
      • Konfiguration (auch als Einstellungen bezeichnet)
      • Bedingungen
  3. Ziel: Diese Änderungen gelten nur für ein bestimmtes Ziel.
    • Diese Felder können auf Zielebene für von Oracle verwaltete und nicht von Oracle verwaltete Rezepte geändert werden:
      • Bedingungen
    • Diese Felder können auf Zielebene für ein nicht von Oracle verwaltetes Rezept geändert werden:
      • Status (Aktiviert/Deaktiviert)
      • Risikostufe
      • Beschriftungen
      • Konfiguration (auch als Einstellungen bezeichnet)
  4. Sub-Compartments eines Ziels: Diese Änderungen gelten nur für ein Compartment, das im Nachkommenbaum eines Ziels ausgewählt wurde.
    • Diese Felder können auf Zielebene für von Oracle verwaltete und nicht von Oracle verwaltete Rezepte geändert werden:
      • Bedingungen
    • Diese Felder können auf Zielebene für ein nicht von Oracle verwaltetes Rezept geändert werden:
      • Status (Aktiviert/Deaktiviert)
      • Risikostufe
      • Beschriftungen
      • Konfiguration (auch als Einstellungen bezeichnet)

Bedingungsgruppen mit Rezeptregeln verwenden

Mit Bedingungsgruppen können Sie schnell den Geltungsbereich festlegen, für den eine Detektor- oder Responder-Regel aktiviert werden soll.

Bedingungsgruppen für Detektoren

Eine Bedingungsgruppe legt Parameter fest, die Sie angeben, um den Geltungsbereich von Situationen zu begrenzen, in denen die Verletzung einer Detektorregel tatsächlich ein Problem auslöst:

  • Bei Konfigurationsdetektoren ermöglichen Bedingungsgruppen die Aufnahme oder den Ausschluss bestimmter Ressourcen für die Überwachung.
  • Aktivitätsdetektoren können Sie mit Bedingungsgruppen auf bestimmte IP-Bereiche, Regionen, Benutzer, Gruppen oder Ressourcen beschränken.
  • So implementieren Sie Bedingungsgruppen, wenn Sie eine Detektorrezeptregel ändern:
    1. Wählen Sie Parameter, Operator und Benutzerdefinierte Liste oder Verwaltete Liste aus.
    2. Geben Sie mindestens einen Eintrag für den abzugleichenden Wert ein.
    • Gehen Sie wie folgt vor, um eine Bedingung für einen anderen Parameter als "Tags" festzulegen:
      1. Wählen Sie in der Liste Parameter einen anderen Parameter als Tags aus.
      2. Wählen Sie einen Operator, eine Liste und einen Wert aus.
      3. Um eine weitere Bedingung hinzuzufügen, wählen Sie Weitere Bedingung aus.
        Hinweis

        Die Angabe mehrerer Bedingungen fungiert als UND-Operator. Die Regel wird nur durchgesetzt, wenn alle Bedingungen erfüllt sind.
    • Gehen Sie folgendermaßen vor, um eine Bedingung für Tags festzulegen:
      1. Wählen Sie in der Liste Parameter die Option Tags aus.
      2. Wählen Sie einen Operator aus (In oder Nicht in).

        Wenn Sie In auswählen, wirkt sich die Regel nur auf Elemente aus, die mit einem der Tags getaggt sind, die sich in der von Ihnen angegebenen Liste befinden.

        Wenn Sie Nicht in auswählen, wirkt sich die Regel nur auf Elemente aus, die nicht mit einem der Tags gekennzeichnet sind, die in der von Ihnen angegebenen Liste enthalten sind.

      3. Wählen Sie Tags auswählen aus.
      4. Legen Sie im Dialogfeld Tags auswählen eine Bedingung für definierte oder Freiformtags fest:

        Um eine Bedingung für definierte Tags festzulegen, wählen Sie einen anderen Tag-Namespace als Kein Wert aus, wählen Sie einen Tagschlüssel aus, und wählen Sie dann den Tagwert aus, oder geben Sie ihn ein:

        Um eine Bedingung für Freiformtags festzulegen, wählen Sie unter Tag-Namespace die Option Kein Wert für Tag-Namespace aus, geben Sie einen Tagschlüssel ein, und geben Sie dann optional den Tagwert ein.

        Fügen Sie bei Bedarf weitere Tags hinzu.
        Hinweis

        Wenn Sie mehrere Tags angeben, wird die Regel nur durchgesetzt, wenn alle Bedingungen erfüllt sind.
  • Sie können eine Bedingung für eine einzelne Ressource und Eingabe mit einer benutzerdefinierten Liste oder mehrere Ressourcen und Eingaben gleichzeitig mit verwalteten Listen hinzufügen.

Beispiel: Sie nutzen 10 Compute-Instanzen. Zwei Instanzen (Instance1 und Instance2) sollen öffentlich sein. Daher soll die Regel "Instanz ist öffentlich zugänglich" keine Probleme bei diesen Instanzen auslösen. Mit Bedingungsgruppen können Sie diese beiden Instanzen mit benutzerdefinierten Listen oder verwalteten Listen ausschließen.

Gültige Werte für Bedingungsgruppenparameter

Sowohl in Detektor- als auch in Responder-Rezepten verfügen einige Regeln über Parameteroptionen, bei denen Sie mindestens einen gültigen Werteintrag eingeben müssen. Die folgende Liste enthält Links zu Quellen, die die gültigen Werte für jeden Parametertyp angeben. Wenn keine Links verfügbar sind, wird kurz erläutert, wie Sie gültige Werte finden.

Ausschluss von Ressourcen mit benutzerdefinierten Listen

Verwenden Sie benutzerdefinierte Listen, wenn Sie nur wenige Elemente abgleichen und nicht erwarten, dass dieselbe Liste mehrmals wiederverwendet werden muss.

  1. Öffnen Sie die Detailseite für das Detektorrezept, auf der die Regel "Instanz ist öffentlich zugänglich" aktiviert ist.

    Siehe Benutzerdefiniertes OCI-Detektorrezept bearbeiten.

  2. Suchen Sie auf der Detailseite des Detektors unter Detektorregeln die Zeile für die Regel "Instanz ist öffentlich zugänglich".
  3. Öffnen Sie am rechten Ende dieser Zeile das Menü "Aktionen" Abbildung des Aktionsmenüs, und wählen Sie Bearbeiten aus.
  4. Führen Sie im Dialogfeld Detektorregel bearbeiten im Abschnitt Bedingungsgruppe folgende Schritte aus:
    1. Setzen Sie Parameter auf Instanz-OCID.
    2. Setzen Sie Operator auf Nicht in.
    3. Setzen Sie Liste auf Benutzerdefinierte Liste.
    4. Geben Sie unter Wert die OCID für Instance1 ein.
  5. Wählen Sie Bedingung hinzufügen aus.
  6. Führen Sie in der Zeile der neuen Bedingung folgende Schritte aus:
    1. Setzen Sie Parameter auf Instanz-OCID.
    2. Setzen Sie Operator auf Nicht in.
    3. Setzen Sie Liste auf Benutzerdefinierte Liste.
    4. Geben Sie unter Wert die OCID für Instance2 ein.
  7. Klicken Sie auf Speichern.

    Die Regel "Instanz ist öffentlich zugänglich" überwacht jetzt alle Instanzen auf eine öffentliche Konfiguration, mit Ausnahme von Instance1 und Instance2.

Ausschluss von Ressourcen mit verwalteten Listen

Verwenden Sie verwaltete Listen, wenn Sie viele Elemente abgleichen müssen oder erwarten, dass dieselbe Liste mehrmals wiederverwendet werden muss.

  1. Erstellen Sie zunächst eine verwaltete Liste mit Instanz-OCIDs, die die die OCIDs für Instance1 und Instance2 enthält.

    Siehe Verwaltete Liste erstellen.

    In diesem Beispiel geben Sie dieser Liste den Namen "Public Compute Instance OCIDs".

  2. Öffnen Sie die Detailseite für das Detektorrezept, auf der die Regel "Instanz ist öffentlich zugänglich" aktiviert ist.

    Siehe Benutzerdefiniertes OCI-Detektorrezept bearbeiten.

  3. Suchen Sie auf der Detailseite des Detektors unter Detektorregeln die Zeile für die Regel "Instanz ist öffentlich zugänglich".
  4. Öffnen Sie am rechten Ende dieser Zeile das Menü "Aktionen" Abbildung des Aktionsmenüs, und wählen Sie Bearbeiten aus.
  5. Führen Sie im Dialogfeld Detektorregel bearbeiten im Abschnitt Bedingungsgruppe folgende Schritte aus:
    1. Setzen Sie Parameter auf Instanz-OCID.
    2. Setzen Sie Operator auf Nicht in.
    3. Setzen Sie Liste auf Verwaltete Liste.
    4. Wählen Sie unter Wert den Namen der von Ihnen erstellten verwalteten Liste aus ("Public Compute Instance OCIDs" im Beispiel in Schritt 1).
  6. Klicken Sie auf Speichern.

    Die Regel "Instanz ist öffentlich zugänglich" überwacht jetzt alle Instanzen auf eine öffentliche Konfiguration, mit Ausnahme von Instance1 und Instance2.

    Hinweis

    Alle Compute-Instanz-OCIDs, die Sie der verwalteten Liste in Zukunft hinzufügen, werden ebenfalls von der Überwachung ausgeschlossen.

Verwaltete und benutzerdefinierte Listen mit Rezeptregeln verwenden

Mit verwalteten Listen können Sie schnell den Geltungsbereich festlegen, für den eine Rezeptregel angewendet werden soll, indem Sie eine vordefinierte Parameterliste ein- oder ausschließen. Mit benutzerdefinierten Listen können Sie eine kurze Liste von Parametern für denselben Zweck eingeben.

Verwaltete Liste auf Konfigurationsdetektor anwenden

Beispiel: Sie möchten ein Problem auslösen, wenn eine Compute-Instanz eine öffentliche IP-Adresse hat. Einige Instanzen sollen jedoch öffentliche IP-Adressen aufweisen, und Sie möchten nicht, dass diese Instanzen Probleme auslösen.

  1. Erstellen Sie eine verwaltete Liste mit allen Ressourcen-OCIDs der Compute-Instanzen, die öffentliche IP-Adressen aufweisen sollen.

    Siehe Verwaltete Liste erstellen.

  2. Weisen Sie diese verwaltete Liste als Bedingten Gruppeneintrag für die Konfigurationsmelderregel "Instanz hat eine öffentliche IP" zu.

    Siehe Benutzerdefiniertes OCI-Detektorrezept bearbeiten.

Verwaltete Liste auf Aktivitätsdetektor anwenden

Beispiel: Wenn eine Aktivität, die von bestimmten verdächtigen IP-Adressen initiiert wurde, einen Bucket oder eine Instanz erstellt, möchten Sie ein Problem auslösen.

  1. Erstellen Sie eine verwaltete Liste mit den bekannten verdächtigen IP-Adressen.

    Siehe Verwaltete Liste erstellen.

  2. Weisen Sie diese verwaltete Liste als Bedingungsgruppeneintrag für die Detektorregel "Verdächtige IP-Aktivität" zu.

    Siehe Benutzerdefiniertes OCI-Detektorrezept bearbeiten.

Alternativ dazu können Sie wie folgt vorgehen, wenn Sie wissen, dass Buckets oder Instanzen nur von bestimmten vertrauenswürdigen IP-Adressen erstellt werden sollen:

  • Erstellen Sie eine verwaltete Liste mit vertrauenswürdigen IP-Adressen.
  • Verwenden Sie dann den Operator "Nicht in" im Bedingungsgruppeneintrag für die Detektorregel "Verdächtige IP-Aktivität".