Logs und Loggruppen

Mit Oracle Cloud Infrastructure Logging können Sie Logs und Loggruppen verwalten.

Logs enthalten wichtige Diagnoseinformationen, die beschreiben, wie Ressourcen ausgeführt werden und wie auf sie zugegriffen wird. Sie können Logging für unterstützte Ressourcen aktivieren. Eine nach Service gruppierte Liste der unterstützten Ressourcen finden Sie unter Unterstützte Services.

Loggruppen sind logische Container zum Organisieren von Logs. Logs müssen sich immer innerhalb von Loggruppen befinden. Sie müssen eine Loggruppe erstellen, um ein Log zu aktivieren.

Verwenden Sie Loggruppen, um den Zugriff auf vertrauliche Logs mit einer IAM-Policy zu begrenzen. Bei Loggruppen sind keine komplexen Compartment-Hierarchien für die Sicherung Ihrer Logs erforderlich. Beispiel: Angenommen, Sie speichern Logs für den gesamten Mandanten in einer Standardloggruppe in einem einzelnen Compartment. Sie erteilen Logadministratoren wie üblich mit einer IAM-Policy Zugriff auf das Compartment. Angenommen, einige Projekte enthalten personenbezogene Daten (PII), und diese Logs können nur von einer ausgewählten Gruppe von Logadministratoren angezeigt werden. Mit Loggruppen können Sie Logs, die personenbezogene Daten enthalten, einer separaten Loggruppe hinzufügen. Anschließend können Sie mit einer IAM-Policy den Zugriff so einschränken, dass nur eine ausgewählte Gruppe von Logadministratoren über den erweiterten Zugriff verfügt.

Erforderliche IAM-Policy

Um Oracle Cloud Infrastructure verwenden zu können, muss ein Administrator Mitglied einer Gruppe sein, der Sicherheitszugriff in einer Policy von einem Mandantenadministrator erteilt wurde. Dieser Zugriff ist unabhängig davon erforderlich, ob Sie die Konsole oder die REST-API mit einem SDK, einer CLI oder einem anderen Tool verwenden. Wenn Sie eine Meldung erhalten, dass Sie keine Berechtigung haben oder nicht autorisiert sind, fragen sie den Mandantenadministrator, welcher Zugriffstyp Ihnen zugewiesen wurde und In welchem Compartment Ihr Zugriff funktioniert.

Administratoren: Beispiele zu Policys für Logs und Loggruppen finden Sie unter Erforderliche Berechtigungen für die Arbeit mit Logs und Loggruppen.

Wenn Sie mit Policys neu sind, finden Sie weitere Informationen unter Identitätsdomains verwalten und Allgemeine Policys. Weitere Informationen zum Schreiben von Policys für Logging finden Sie unter Details zu Logging.

Erforderliche Berechtigungen für die Arbeit mit Logs und Loggruppen

Damit Servicelogs in einer Ressource aktiviert werden können, muss einem Benutzer der manage-Zugriff auf die Loggruppe sowie Zugriff auf die Ressource erteilt werden. Im Allgemeinen ist inspect-Zugriffs auf die Ressource ausreichend, Sie sollten jedoch dennoch prüfen, ob spezifische Ressourcen vorhanden sind. Der inspect-Zugriff erteilt dem Benutzer die Berechtigung, die Ressource zu aktualisieren. Außerdem erhält der Benutzer die Berechtigung für die Loggruppe, die das Log enthält.

Logs und Loggruppen verwenden den Ressourcentyp log-group. Damit Sie den Inhalt von Logs durchsuchen können, müssen Sie jedoch einen anderen Ressourcentyp verwenden.

Loggruppen und Logobjekte verwalten

Verwenden Sie Verben für Loggruppen, um Gruppen oder Objekte zu verwalten:

Allow group A to use log-groups in compartment C
Allow group B to manage log-groups in compartment C
Allow group D to read log-groups in compartment C

Dadurch können Benutzer in Gruppe A Loggruppen und Logobjekte in Compartment C erstellen, aktualisieren oder löschen.

So stellen Sie Agent-Konfigurationen bereit

Es sind drei verschiedene Zugriffstypen erforderlich:

Zugriff zum Arbeiten mit Konfigurationen.
Zugriff zum Arbeiten mit Loggruppen.
Inspect-Funktionen für dynamische Gruppen oder Gruppen.

Damit Sie auf Konfigurationen zugreifen können, muss die Policy folgendermaßen lauten:

Allow group B to use unified-configuration in compartment X

So erstellen, aktualisieren oder löschen Sie benutzerdefinierte Logs, die als Ziel in einer Konfiguration verwendet werden

Mit dieser Policy können Benutzer in Compartment B Konfigurationen in Compartment X erstellen, aktualisieren oder löschen.

Damit Sie ein Ziel für die von der Konfiguration eingehenden Logs bereitstellen können, benötigen Sie log-groups-Zugriff:

Allow group B to use log-groups in compartment X

So weisen Sie einer Gruppe von Instanzen eine Konfiguration zu

Damit Sie einer Gruppe von Instanzen eine Konfiguration zuweisen können, benötigen Sie inspect-Zugriff auf die dynamische Gruppe oder die Gruppe, die die Instanzen identifiziert:

Allow group B {IDENTITY_DYNAMIC_GROUP_INSPECT} in tenancy  / Allow group B {IDENTITY_GROUP_INSPECT} in tenancy

Instanzen aktivieren, um Logs in den Logging-Service zu übertragen

Damit Instanzen Logs übertragen können, brauchen sie Zugriff. Nur so können sie eine Konfiguration abrufen und die Logs übertragen. log-content steuert diese Berechtigung (wobei X das Compartment ist, in dem sich die Konfigurationen befinden):

Allow dynamic-group production-fleet to use log-content in compartment X

So zeigen Sie Logs an

Damit Sie Logs in der Konsole (Suche) anzeigen können, ist Folgendes erforderlich:

Allow group Searchers to read log-content in compartment X

Beispiel für eine Logsuch-Policy

So erlauben Sie einer Gruppe, den Inhalt von indexierten Logs zu lesen:

allow group GroupA to read log-groups in tenancy
allow group GroupA to read log-content in tenancy

Beispiel-Policys für Logs und Loggruppen

In diesen Beispielen verwenden Policy-Anweisungen GroupA als Namen der Gruppe.

Damit eine Gruppe die Loggruppen im Mandanten (oder in einem Compartment) anzeigen kann, ist inspect-Zugriff erforderlich:

allow group GroupA to inspect log-groups in tenancy

Damit eine Gruppe Metadaten für Logs oder Loggruppen lesen kann, ist read-Zugriff erforderlich:

allow group GroupA to read log-groups in tenancy

Damit eine Gruppe Loggruppen oder die darin enthaltenen Logs aktualisieren kann, ist use-Zugriff erforderlich:

allow group GroupA to use log-groups in tenancy

Um ein Log für eine Ressource zu aktivieren (oder Loggruppen und die darin enthaltenen Logs zu erstellen und zu löschen), ist manage-Zugriff erforderlich:

allow group GroupA to manage log-groups in tenancy

Um die Verwendung bestimmter Loggruppen oder Gruppen zuzulassen, verwenden Sie eine where-Klausel mit der Variablen target.loggroup.id. Beispiel:

Allow group GroupA to manage loggroups in tenancy where 
target.loggroup.id='ocid1.loggroup.oc1.phx.<uniqueID>'

So geben Sie mehrere Loggruppen an:

Allow group GroupA to manage log-groups in tenancy where any {target.loggroup.id='ocid1.loggroup'}

Benutzerdefinierte Logs

Für benutzerdefinierte Logs ist Folgendes erforderlich. Diese Policy ist erforderlich, damit der Benutzer Logs über die Seite Suchen der Konsole durchsuchen kann:

allow group userGroup1 to read log-content in compartment c

Hinweis

Diese Policy bezieht sich zwar auf die Verwendung mit benutzerdefinierten Logs, gilt jedoch auch für alle anderen Logs. LOG_CONTENT_READ ermöglicht das Lesen von Logs aus benutzerdefinierten Logs und OCI-Servicelogs. Sie ist vom Verhalten her identisch mit dieser Policy:

allow group GroupA to read log-content in tenancy

Für den Agent, der den Instanz-Principal auf der virtuellen Maschine zum Senden von Logs verwendet, ist Folgendes erforderlich:

allow dynamic-group dynamicgroup1 to use log-content in compartment c

Hinweis

Wenn eine Benutzergruppe anstelle einer dynamischen Gruppe zum Übertragen benutzerdefinierter Logs verwendet wird, ersetzen Sie den Namen der dynamischen Gruppe durch den Namen der Benutzergruppe in diesen Policys.

Wenn Sie für benutzerdefinierte Logs allow dynamic-group dynamicGroup1 to use log-content in compartment c verwenden, erhalten die Instanzen in dieser dynamischen Gruppe die Berechtigung zum Herunterladen der Konfiguration, zum Senden von Logs und zum Durchsuchen von Logs.

IAM-Policy-Anforderungen für Ressourcen

Damit Sie Servicelogs zu einer Ressource hinzufügen können, müssen Sie nicht nur über die Berechtigungen zum Arbeiten mit der Loggruppe, sondern auch über die Aktualisierungsberechtigung für die Ressource verfügen. Bei vielen Ressourcen wird die Berechtigung zum Aktualisieren mit dem Verb use erteilt. Beispiel: Benutzer, die Buckets in CompartmentA verwenden (use) können, können auch das Logging für einen Bucket in CompartmentA aktivieren.

Bei einigen Ressourcen steht die Berechtigung zum Aktualisieren einer Ressource mit dem Verb use jedoch nicht zur Verfügung. Beispiel: Damit Sie eine Regel für den Events-Service aktualisieren können, benötigen Sie die uneingeschränkte manage-Berechtigung. Damit Sie ein Log für eine Events-Regel (oder für eine andere Ressource, die nicht die Aktualisierungsberechtigung mit dem Verb use enthält) aktivieren können, benötigen Sie die manage-Berechtigung.

Damit eine Gruppe das Logging für diese Ressourcen aktivieren kann, ohne dass die uneingeschränkten manage-Berechtigungen erteilt werden müssen, können Sie eine Policy-Anweisung hinzufügen, um nur die <RESOURCE>_UPDATE-Berechtigung (oder, im Fall des Events-Service, <RESOURCE>_MODIFY) des Verbs manage zu erteilen. Beispiel: Damit die Gruppe "EventUsers" Logs für Events-Regeln in CompartmentA aktivieren kann, können Sie eine Policy schreiben, die der folgenden ähnelt:

Allow group EventUsers to read cloudevents-rules in compartment CompartmentA
Allow group EventUsers to manage cloudevents-rules in compartment CompartmentA 
 where request.permission='EVENTRULE_MODIFY'

Informationen zu Ressourcenberechtigungen finden Sie unter Policy-Referenz.

IAM-Policy für VCN-Flowlogs

Für die Verwaltung von VCN-Flowlogs sind zusätzlich zu den erforderlichen Berechtigungen für die Arbeit mit Logs und Loggruppen auch Lese- und Aktualisierungsberechtigungen für das Subnetz erforderlich.

Damit Sie Subnetzberechtigungen bereitstellen können, verwenden Sie eine der folgenden Policys, die in der Reihenfolge von umfassenderen bis eingeschränkten Berechtigungen aufgeführt werden:

Allow group FlowLogsEnablers to manage virtual-network-family in tenancy

Oder:

Allow group FlowLogsEnablers to manage subnets in tenancy

Oder:

Allow group FlowLogsEnablers to {SUBNET_READ, SUBNET_UPDATE} in tenancy

Diese Gruppe entspricht in etwa dem, was für EventUsers in IAM-Policy-Anforderungen für Ressourcen beschrieben ist.

Beispielszenario

Ihre Firma hat eine Abteilung "Operations". Innerhalb der Abteilung "Operations" gibt es mehrere Kostenstellen. Sie möchten Ressourcen, die zur Abteilung "Operations" gehören, mit der entsprechenden Kostenstelle taggen können.

Erstellen Sie eine Loggruppe mit dem Namen "vertraulich". Geben Sie dabei keine vertraulichen Informationen ein.
Fügen Sie der Loggruppe "vertraulich" Logs mit vertraulichen Daten hinzu.

Eine Mitarbeiterin namens Alice gehört bereits zur Gruppe "BucketManagers". Alice kann Buckets in CompartmentA verwalten. Alice und andere Mitglieder der Gruppe "BucketManagers" sollen Logs für Buckets in CompartmentA aktivieren können.

Um der Gruppe "BucketManagers" Zugriff auf die vertrauliche Datenloggruppe (und nur auf diese) zu erteilen, fügen Sie der Policy "BucketManagers" die folgenden Anweisungen hinzu:

Allow group BucketManagers to manage log-groups in compartment CompartmentA where 
target.loggroups.id='ocid1.lumloggroup.oc1.phx.<uniqueID>'

Alice kann jetzt Logs für Bucket-Ressourcen in CompartmentA aktivieren.

Namen von Logs und Loggruppen

Bei Loggruppennamen muss das erste Zeichen mit einem Buchstaben beginnen. Andernfalls gelten die folgenden Richtlinien sowohl für Lognamen als auch für Loggruppennamen:

Verwenden Sie zwischen 1 und 256 Zeichen.
Gültige Zeichen sind Buchstaben (Groß- oder Kleinbuchstaben), Zahlen, Bindestriche, Unterstriche und Punkte.
Bei Lognamen und Loggruppennamen muss die Groß-/Kleinschreibung beachtet werden. Logging behandelt "write-log" und "WRITE-log" als separate Logs.
Geben Sie dabei keine vertraulichen Informationen ein.