Zugriffssteuerungslisten Erkunden

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 9 Minuten Lesedauer

    • Untersuchen Sie Zugriffssteuerungslisten (ACLs).

    Alle Regeln für Zugriffssteuerungslisten geben Folgendes an:
    • Die Entscheidungstyp , Regeltyp Und Vorgang Welche die ACL definiert
    • Die Objekt Wird gesichert
    • Die Bedingungen Erforderlich für den Zugriff auf das Objekt

    Komponenten der ACL

    Der Entscheidungstyp definiert, ob Anwender auf das Objekt zugreifen dürfen, wenn Bedingungen erfüllt sind, oder verweigert den Zugriff auf das Objekt, es sei denn, die Bedingungen sind erfüllt.

    Entscheidungstyp Beschreibung
    Verweigern – Es Sei Denn Beschränken Sie den Zugriff auf die Ressource, indem Sie den Zugriff explizit verweigern, es sei denn, Bedingungen werden übergeben. Weitere Informationen finden Sie unter acl-denial-behavior.html#acl-denial-behavior__section_qnd_snl_zbc.
    Zulassen, Wenn Zugriff auf Ressource zulassen, wenn Bedingungen übergeben werden.

    Die Objekt Ist das Ziel, auf das der Zugriff gesteuert werden muss. Jedes Objekt besteht aus einem Typ und einem Namen, die eine bestimmte Tabelle, ein bestimmtes Feld oder einen bestimmten Datensatz eindeutig identifizieren. Mit Gilt für Feldanwender haben eine granulare Kontrolle darüber, für welche spezifischen Datensätze diese ACL gilt.

    Beispielsweise geben alle diese Einträge ein Objekt an:

    Typ Name Objekt gesichert
    record [Incident].[--keine--] Die Incident-Tabelle.
    record [Incident].[aktiv] Das Feld aktiv in der Incident-Tabelle.
    record [incident]

    Gilt für: Priorität = P1

    		 Nur Incidents mit Priorität 1 in der Incident-Tabelle.
    REST_Endpoint User_role_inheritance Der Datensatz für die geskriptete REST API user_role_inheritance.

    Jeweils Vorgang Beschreibt einen gültigen Aktion Das System kann das angegebene Objekt übernehmen. Einige Objekte, z. B. Datensätze, unterstützen mehrere Vorgänge, während andere Objekte, z. B. ein REST_Endpoint, nur einen Vorgang unterstützen.

    Beispiel: Alle diese Einträge geben einen Vorgang an:

    Typ Name Vorgang Vorgang gesichert
    record [Incident].[--keine--] Erstellen Erstellen von Datensätzen in der Incident-Tabelle.
    record [Incident].[aktiv] Schreiben Das Feld aktiv in der Incident-Tabelle wird aktualisiert.
    REST_Endpoint User_role_inheritance ausführen Ausführung der geskripteten REST API user_role_inheritance.
    Die Bedingungen Geben Sie an, wann jemand auf das benannte Objekt und den benannten Vorgang zugreifen kann. Sicherheitsadministratoren können Bedingungsanforderungen angeben, indem sie Folgendes hinzufügen:
    • Eine oder mehrere Anwenderrollen für den Erfordert Rolle Liste.
    • Mindestens ein Sicherheitsattribut muss als „wahr“ ausgewertet werden.
    • Mindestens eine Datenbedingung.
    • Ein Skript, das als „wahr“ oder „falsch“ ausgewertet oder festgelegt wird Antwort Variable auf „wahr“ oder „falsch“.

    Um Zugriff auf ein Objekt und einen Vorgang zu erhalten, muss ein Anwender alle in einer Zugriffssteuerung aufgeführten Bedingungen erfüllen. Diese Zugriffssteuerung schränkt beispielsweise den Zugriff auf die Anzeige von Vorgängen in der Incident-Tabelle ein.

    ACL für einen Incident-Datensatz.

    Um einen Datensatz in der Incident-Tabelle zu aktualisieren, muss ein Anwender über die aufgelisteten Rollen verfügen, und der Datensatz muss die Bedingung erfüllen.

    Bedingungstyp Anforderung Beschreibung
    Erfordert Rolle Erfordert Rolle : itil Erlauben Sie nur Anwendern mit der Rolle itil, Incidents zu aktualisieren.
    Sicherheitsattribute UserIsAuthenticated Nur authentifizierte Anwender zum Aktualisieren von Incidents.
    Datenbedingung [Incident-Status] [ist nicht] [Geschlossen] Nur Aktualisierungen aktiver Incident-Datensätze zulassen.

    Gilt für Verhalten

    Die Gilt für Das Feld bestimmt, ob eine ACL für Datensätze gilt, während die Datenbedingung eine bereits angewendete ACL auswertet. Gilt für Gibt an, ob sich die ACL auf einen bestimmten Datensatz auswirkt. Wenn sie leer ist, gilt die ACL für alle Datensätze. Gilt für Kann für die granulare ACL-Durchsetzung verwendet werden, während „Datenbedingung“ ein Bewertungskriterium ist.

    Hinweis:
    Gilt für Ist Groß-/Kleinschreibung beachten.

    Standardmäßiges Verhalten ablehnen

    Standardmäßig verweigert die ACL-Engine den Zugriff vollständig, wenn eine ACL leer oder ungültig ist. Leere ACLs sind als ACLs ohne eine oder mehrere dieser Komponenten definiert:
    • Definierte Rolle
    • Sicherheitsattribut
    • Datenbedingung
    • Skript
    Ungültige ACLs sind definiert als:
    • ACLs mit Rollen, die nicht vorhanden sind (z. B. keine Zeile in der Datenbank)
    • ACLs mit nicht vorhandenen Sicherheitsattributen (z. B. keine Zeile in der Datenbank)
    • ACLs mit einem Skript, das „answer=true“ oder „wahr“ enthält

    Wenn das System erkennt, dass der Anwender eine ACL erstellt, fordert es den Anwender auf, eine Rolle oder ein vorhandenes Sicherheitsattribut auszuwählen.

    System fordert den Anwender zur Auswahl auf.

    ACL-Bewertungsprozess

    Eine ACL-Regel gewährt einem Anwender nur Zugriff auf ein Objekt, wenn der Anwender alle Bedingungen erfüllt, die für die übereinstimmende ACL-Regel erforderlich sind.

    • Die Bedingung muss bis ausgewertet werden Wahr .
    • Das Skript muss bis ausgewertet werden Wahr Oder geben Sie eine Antwortvariable mit dem Wert zurück Wahr .
    • Der Anwender muss über eine der Rollen in der Liste der erforderlichen Rollen verfügen. Wenn die Liste leer ist, wird diese Bedingung als ausgewertet Wahr .
    • [Nur Datensatz-ACL-Regeln] die übereinstimmenden ACL-Regeln auf Tabellenebene und Feldebene müssen beide als ausgewertet werden Wahr .
    Abbildung : 1. ACL-Auswertungsbedingungen
    ACL-Auswertungsbedingungen

    Wenn eine Sitzung Daten anfordert, sucht das System nach Zugriffssteuerungsregeln, die dem angeforderten Objekt und Vorgang entsprechen. Wenn eine übereinstimmende Zugriffssteuerungsregel vorhanden ist, bewertet das System, ob der Anwender über die Bedingungen verfügt, die für den Zugriff auf das Objekt und den Vorgang erforderlich sind. Wenn eine Zugriffssteuerungsregel mehr als eine Bedingung angibt, muss der Anwender alle Bedingungen erfüllen, um Zugriff auf das Objekt und den Vorgang zu erhalten. Wenn eine Bedingungsprüfung fehlschlägt, kann der Anwender nicht auf das übereinstimmende Objekt und den entsprechenden Vorgang zugreifen.

    Wenn ein Anwender die Bedingungen der ersten Übereinstimmungsregel nicht erfüllt, wertet das System die Bedingungen der nächsten übereinstimmenden Zugriffssteuerungsregel aus, wie in der Verarbeitungsreihenfolge der Zugriffssteuerung angegeben. Wenn der Anwender die Bedingungen einer übereinstimmenden Zugriffssteuerungsregel nicht erfüllt, verweigert das System den Zugriff auf das angeforderte Objekt und den angeforderten Vorgang.
    Hinweis:
    Wenn keine übereinstimmenden Zugriffssteuerungsregeln für das angeforderte Objekt und den angeforderten Vorgang vorhanden sind, gewährt das System dem Anwender Zugriff darauf. In der Praxis findet das System selten keine übereinstimmenden Regeln, da das System über eine Reihe von standardmäßigen Zugriffssteuerungsregeln verfügt, die alle Datensatzvorgänge schützen.

    Die Auswirkungen, die der Zugriff auf ein Objekt verweigert wird, hängen von der ACL-Regel ab, die der Anwender fehlgeschlagen ist. Wenn beispielsweise eine ACL-Regel für Lesevorgänge fehlschlägt, kann der Anwender das Objekt nicht sehen. Je nach gesichertem Objekt blendet die ACL-Regel ein Feld in einem Formular aus, blendet Zeilen in einer Liste aus oder verhindert, dass ein Anwender auf eine UI-Seite zugreift. Die folgende Tabelle enthält eine vollständige Liste der Ergebnisse des Fehlschlags einer ACL-Regel für einen bestimmten Vorgang und Objekttyp.

    ACL-Prüfungen vor und nach der Abfrage

    Ihre Instanz überprüft ACL-Regeln sowohl vor als auch nachdem ein Anwender eine Abfrage erstellt hat. Da vor und nach einer Abfrage verschiedene Informationen verfügbar sind, können die Ergebnisse unterschiedlich sein.
    ACL-Prüfung vorab abfragen

    Bevor Ihre Instanz eine Datenbankabfrage ausführt, überprüft sie die ACL-Regeln für jedes Feld in der abgefragten Tabelle, um zu bestimmen, auf welche Felder ein Anwender zugreifen kann. Diese Prüfung untersucht nur die Rollen des Anwenders und überprüft, ob diese Rollen Zugriff auf Felder zulassen. Da diese Prüfung vor der Abfrage ausgeführt wird, hat die ACL keinen Zugriff auf die Datensätze in der Tabelle, daher kann sie diese Daten nicht berücksichtigen. Skripts und Bedingungen, die davon abhängen, den Inhalt eines Datensatzes zu kennen, werden nicht ausgewertet.

    Wenn der Anwender zu diesem Zeitpunkt keinen Lesezugriff hat, wird dem Anwender der Wert für das Feld nicht angezeigt.

    ACL-Prüfung nach Abfrage

    Nach der Abfrage überprüft Ihre Instanz jeden von der Abfrage zurückgegebenen Datensatz. Während dieser Prüfung gibt es Kontext für die ACL, sodass die Rollen-, Bedingungs- und Skriptabschnitte der ACL ausgewertet werden. Wenn der Anwender zu diesem Zeitpunkt keinen Lesezugriff hat, wird dem Anwender der Wert für das Feld nicht angezeigt. Der Anwender sieht jedoch die Feldbezeichnung, wenn seine Rollen den Zugriff auf das Feld zulassen.

    Vorgang Ergebnisse des Fehlschlags einer ACL-Regel für ein Objekt
    ausführen Anwender kann keine Skripts auf einem Datensatz oder einer UI-Seite ausführen.
    Erstellen Anwender kann nicht sehen Neu UI-Aktion aus Formularen. Der Anwender kann auch keine Datensätze mithilfe von API-Protokollen wie Webservices in eine Tabelle einfügen.

    A Erstellen ACL mit einer Bedingung, die erfordert, dass ein Feld einen bestimmten Wert enthält, kann als falsch ausgewertet werden. Felder in neuen Datensätzen werden als leer betrachtet, bis der Datensatz gespeichert wurde.
    gelesen Der Anwender kann das Objekt in Formularen oder Listen nicht sehen. Der Anwender kann auch keine Datensätze mit API-Protokollen wie Webservices abrufen.
    Schreiben Der Anwender sieht ein schreibgeschütztes Feld in Formularen und Listen, und der Anwender kann Datensätze nicht mithilfe von API-Protokollen wie Webservices aktualisieren.
    löschen Anwender kann nicht sehen Löschen UI-Aktion aus Formularen. Der Anwender kann auch keine Datensätze aus einer Tabelle mithilfe von API-Protokollen wie Webservices entfernen.
    Edit_Task_Relations Anwender kann keine Beziehungen zwischen Aufgabentabellen definieren.
    Edit_ci_Relations Anwender kann keine Beziehungen zwischen Konfigurationselement-Tabellen [cmdb_ci] definieren.
    Save_as_template Wird verwendet, um die Felder zu steuern, die beim Erstellen einer Vorlage gespeichert werden sollen.
    Add_to_list Anwender kann bestimmte Spalten in der Listenmechanik nicht anzeigen oder personalisieren.
    List_Edit Anwender kann Datensätze (Zeilen) aus einer Liste nicht aktualisieren.
    report_on Anwender kann keinen Bericht in der ACL-Tabelle erstellen. Weitere Informationen finden Sie unter Beschränken Sie die Berichterstellung mit einer ACL-Regel .
    report_view Der Anwender kann den Inhalt eines Berichts nicht in der ACL-Tabelle oder im ACL-Feld anzeigen. Weitere Informationen finden Sie unter Reporting.
    Personalize_choices Anwender kann nicht mit der rechten Maustaste auf ein Listenfeld klicken und auswählen Konfigurieren Sie Auswahlmöglichkeiten .

    ACL-übereinstimmende Anforderungen für Objekte

    Objekttyp Übereinstimmende ACL-Regeln, die für den Zugriff auf das Objekt erforderlich sind Vorhandene Platzhalter-ACL-Regeln
    Vom Client aufrufbare Skripteinbindungen Anwender müssen die Bedingungen von zwei ACL-Regeln erfüllen:
    1. Alle ACL-Regeln mit Platzhaltern für das Objekt (wenn für den Vorgang eine ACL-Regel vorhanden ist).
    2. Die erste ACL-Regel, die dem Namen des Objekts entspricht (wenn für den Vorgang eine ACL-Regel vorhanden ist).
    		 Standardmäßig gibt es keine Platzhalterregeln (*) für diese Objekttypen. Wenn Sie eine Platzhalter-ACL-Regel für eines dieser Objekte erstellen, gilt die ACL-Regel für alle Objekte dieses Typs.
    Prozessoren
    UI-Seiten Anwender müssen die Bedingungen von zwei ACL-Regeln erfüllen:
    1. Die erste ACL-Regel, die dem Feld des Datensatzes entspricht (wenn für den Vorgang eine ACL-Regel vorhanden ist).
    2. Die erste ACL-Regel, die der Tabelle des Datensatzes entspricht (wenn für den Vorgang eine ACL-Regel vorhanden ist).
    		 Standardmäßig gibt es Platzhaltertabellenregeln (*) für die Vorgänge „Erstellen“, „Lesen“, „Schreiben“ und „Löschen“ sowie Platzhalterfeldregeln (*.*) für die Vorgänge „Personalize_choices“, „create“ und „Save_as_template“. Wenn Sie eine Tabelle erstellen, erstellen Sie ACL-Regeln für die Tabelle, es sei denn, Sie möchten die bereitgestellten ACL-Regeln mit Platzhaltern verwenden.
    Datensatz
    Hinweis:
    Das Standardverhalten des Sicherheitsmanagers ( glide.sm.default_mode Die Eigenschaft ) bestimmt, ob Anwender auf Objekte zugreifen können, die nur ACL-Regeln für Platzhaltertabellen entsprechen. Wenn diese Eigenschaft auf festgelegt ist Zugriff verweigern , Nur Administratoren können auf Objekte zugreifen, die den ACL-Regeln der Platzhaltertabelle entsprechen.
    Hinweis:
    Die ACL-Regel für Platzhalterfeld (*.*) für den Erstellungsvorgang verwendet dieselben Bedingungen wie der Schreibvorgang. Dies bedeutet, dass die Erstellungsbedingungen mit den Schreibbedingungen identisch sind, es sei denn, Sie definieren eine explizite ACL-Regel für Erstellungsvorgänge.

    Mehrere ACL-Regeln am selben Punkt in der Verarbeitungsreihenfolge

    Wenn zwei oder mehr Regeln an demselben Punkt in der Verarbeitungsreihenfolge übereinstimmen, muss der Anwender eine der ACL-Regelbedingungen übergeben, um auf das Objekt zuzugreifen. Wenn Sie beispielsweise ACL-Regeln für zwei Felder erstellen incident.number, Dann hat ein Anwender, der eine Regel übergibt, Zugriff auf das Nummernfeld, unabhängig davon, ob der Anwender eine andere Feld-ACL-Regel am selben Punkt in der Verarbeitungsreihenfolge fehlgeschlagen ist.

    Erforderliche Rolle

    Normale Administratorbenutzer können Zugriffssteuerungsregeln anzeigen und debuggen. Um jedoch vorhandene Zugriffssteuerungsregeln zu erstellen oder zu aktualisieren, müssen Administratoren Berechtigungen auf die Rolle „Security_admin“ erhöhen. Siehe Auf eine privilegierte Rolle hochstufen für Anweisungen.

    ACL-Regeln in bereichsbezogenen Anwendungen

    Sie können ACL-Regeln für Objekte im selben Umfang wie die ACL-Regel erstellen. Sie können auch ACL-Regeln für Tabellen mit mindestens einem Feld erstellen, das sich im gleichen Umfang wie die ACL-Regel befindet.

    Für Tabellen, die sich in einem anderen Umfang als der ACL-Regeldatensatz befinden, sind die Arten von Regeln beschränkt.
    • Sie können eine ACL-Regel für jede Tabelle, UI-Seite oder ein anderes Objekt erstellen, das sich im selben Umfang wie die ACL-Regel befindet.
    • Sie können eine ACL für ein Feld erstellen, das sich im selben Umfang wie die ACL-Regel befindet.
      • Wenn sich die Tabelle im selben Umfang befindet, können Sie ein Skript zum Auswerten von Bedingungen verwenden.
      • Wenn sich die Tabelle in einem anderen Bereich befindet, können Sie kein Skript zum Auswerten von Bedingungen verwenden.
    • Sie können keine ACL-Regeln für Objekte erstellen oder ändern, die sich in einem anderen Bereich als der Anwendung befinden, die Sie in der Anwendungsauswahl ausgewählt haben, einschließlich dem Hinzufügen einer Rolle zu einer ACL in einem anderen Bereich.
    • Sie können Platzhaltertabellenregeln (*) nur im globalen Bereich erstellen.
    • Sie können Platzhalterfeldregeln (*) nur für Tabellen im selben Umfang wie die ACL-Regel erstellen.