Zugriffssteuerungslisten erkunden

Erkunden Sie Zugriffssteuerungslisten (ACLs).

Alle Regeln für Zugriffssteuerungslisten legen Folgendes fest:

• Der Entscheidungstyp, der Regeltyp und der Vorgang, die die ACL definieren
• Das Objekt, das gesichert wird
• Die für den Zugriff auf das Objekt erforderlichen Bedingungen

Komponenten der ACL

Der Entscheidungstyp definiert, ob Benutzer auf das Objekt zugreifen dürfen, wenn die Bedingungen erfüllt sind, oder ob der Zugriff auf das Objekt verweigert wird, wenn die Bedingungen nicht erfüllt sind.

Entscheidungstyp	Beschreibung
Verweigern-Unless	Beschränken Sie den Zugriff auf die Ressource, indem Sie den Zugriff explizit verweigern, sofern keine Bedingungen übergeben werden. 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.

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

Alle diese Einträge geben beispielsweise ein Objekt an:

Typ	Name	Objekt gesichert
record	[Incident].[--Keine--]	Die Incident-Tabelle.
record	[Incident].[Aktiv]	Feld „Aktiv“ in der Incident-Tabelle
record	[incident] Betrifft: 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“.

Jeder Vorgang beschreibt eine gültige Aktion, die das System für das angegebene Objekt ausführen kann. Einige Objekte, z. B. Datensätze, unterstützen mehrere Vorgänge, während andere Objekte, z. B. ein REST-Endpunkt, nur einen Vorgang unterstützen.

Alle diese Einträge geben beispielsweise einen Vorgang an:

Typ	Name	Vorgang	Vorgang gesichert
record	[Incident].[--Keine--]	Erstellen	Datensätze in der Incident-Tabelle erstellen.
record	[Incident].[Aktiv]	write	Das Feld „Aktiv“ in der Incident-Tabelle wird aktualisiert.
REST_Endpoint	user_role_inheritance	ausführen	Ausführen der geskripteten REST API „user_role_inheritance“.

Die Bedingungen geben an, wann ein Benutzer auf das benannte Objekt und den benannten Vorgang zugreifen kann. Sicherheitsadministratoren können Bedingungsanforderungen angeben, indem sie Folgendes hinzufügen:

• Mindestens eine Anwenderrolle für die Liste „Erfordert Rolle“.
• Mindestens ein Sicherheitsattribut muss als „wahr“ ausgewertet werden.
• Mindestens eine Datenbedingung
• Ein Skript, das „wahr“ oder „falsch“ ergibt oder das die Antwortvariable auf „wahr“ oder „falsch“ setzt.

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

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

Bedingungstyp	Anforderung	Beschreibung
Erfordert Rolle	Erfordert die Rolleitil	Erlauben Sie nur Benutzern mit der Rolle „itil“, Incidents zu aktualisieren.
Sicherheitsattribute	UserIsAuthenticated	Nur authentifizierte Anwender dürfen Incidents aktualisieren.
Datenbedingung	[Incident-Status] [ist nicht] [Geschlossen]	Lassen Sie nur Aktualisierungen für aktive Incident-Datensätze zu.

Standardmäßig ablehnen

Standardmäßig verweigert die ACL-Engine den Zugriff vollständig, wenn eine ACL leer oder ungültig ist. Leere ACLs werden als ACLs ohne eine oder mehrere der folgenden Komponenten definiert:

• Definierte Rolle
• Sicherheitsattribut
• Datenbedingung
• Skript

Ungültige ACLs sind definiert als:

• ACLs mit Rollen, die nicht vorhanden sind (haben z. B. keine Zeile in der Datenbank)
• ACLs mit Sicherheitsattributen, die nicht vorhanden sind (haben 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.

ACL-Bewertungsprozess

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

• Die Bedingung muss als trueausgewertet werden.
• Das Skript muss als true ausgewertet werden oder eine Antwortvariable mit dem Wert truezurückgeben.
• Der Benutzer muss eine der Rollen in der Liste der erforderlichen Rollen aufweisen. Wenn die Liste leer ist, wird diese Bedingung als trueausgewertet.
• [Nur Datensatz-ACL-Regeln] Die übereinstimmenden ACL-Regeln auf Tabellenebene und Feldebene müssen als trueausgewertet werden.

Abbildung : 1. ACL-Bewertungsbedingungen

Immer wenn eine Sitzung Daten anfordert, sucht das System nach Zugriffssteuerungsregeln, die dem angeforderten Objekt und Vorgang entsprechen. Wenn eine übereinstimmende Zugriffssteuerungsregel vorhanden ist, wertet das System aus, ob der Benutzer über die erforderlichen Bedingungen für den Zugriff auf das Objekt und den Vorgang verfügt. Wenn eine Zugriffssteuerungsregel mehr als eine Bedingung angibt, muss der Benutzer 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 entsprechende Objekt und den entsprechenden Vorgang zugreifen.

Wenn ein Benutzer die Bedingungen der ersten Übereinstimmungsregel nicht erfüllt, wertet das System die Bedingungen der nächsten übereinstimmenden Zugriffssteuerungsregel gemäß der Verarbeitungsreihenfolge der Zugriffssteuerung aus. Wenn ein Benutzer die Bedingungen einer übereinstimmenden Zugriffssteuerungsregel nicht erfüllt, verweigert das System den Zugriff auf das angeforderte Objekt und den angeforderten Vorgang.

Hinweis:

Wenn für das angeforderte Objekt und den angeforderten Vorgang keine übereinstimmenden Zugriffssteuerungsregeln vorhanden sind, gewährt das System dem Benutzer Zugriff darauf. In der Praxis kommt es selten vor, dass das System keine übereinstimmenden Regeln findet, da das System über eine Reihe von standardmäßigen Zugriffssteuerungsregeln verfügt, die alle Datensatzvorgänge schützen.

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

ACL-Prüfungen vor und nach der Abfrage

Ihre Instanz von prüft ACL-Regeln sowohl vor als auch nach dem Stellen einer Abfrage durch einen Anwender. Da vor und nach einer Abfrage unterschiedliche Informationen verfügbar sind, können die Ergebnisse unterschiedlich sein.

ACL-Prüfung vor der Abfrage

Bevor Ihre Instanz eine Datenbankabfrage ausführt, prüft sie die ACL-Regeln für jedes Feld in der abgefragten Tabelle, um zu bestimmen, auf welche Felder ein Benutzer zugreifen darf. Diese Prüfung berücksichtigt nur die Rollen des Anwenders und prüft, ob diese Rollen Zugriff auf Felder gewähren. Da diese Prüfung vor der Abfrage ausgeführt wird, hat die ACL keinen Zugriff auf die Datensätze in der Tabelle und kann diese Daten daher nicht berücksichtigen. Skripts und Bedingungen, die auf der Kenntnis des Inhalts eines Datensatzes beruhen, werden nicht ausgewertet.

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

ACL-Prüfung nach der Abfrage

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

Vorgang	Ergebnisse des Fehlschlagens einer ACL-Regel für ein Objekt
ausführen	Anwender können keine Skripts für einen Datensatz oder eine UI-Seite ausführen.
Erstellen	Anwender können die UI-Aktion „ Neu “ in Formularen nicht sehen. Der Benutzer kann auch keine Datensätze mithilfe von API-Protokollen wie Webdiensten in eine Tabelle einfügen. Eine ACL mit einer Bedingung erstellen, die erfordert, dass ein Feld, das einen bestimmten Wert enthält, immer als „falsch“ ausgewertet wird. Felder in neuen Datensätzen gelten als leer, bis der Datensatz gespeichert wird.
gelesen	Der Anwender kann das Objekt nicht in Formularen oder Listen anzeigen. Der Benutzer kann auch keine Datensätze mit API-Protokollen wie Webdiensten abrufen.
write	Dem Anwender wird in Formularen und Listen ein schreibgeschütztes Feld angezeigt, und er kann Datensätze nicht mit API-Protokollen wie Webdiensten aktualisieren.
delete	Der Anwender kann die UI-Aktion „Löschen “ in Formularen nicht sehen. Der Benutzer kann auch keine Datensätze mithilfe von API-Protokollen wie Webdiensten aus einer Tabelle entfernen.
edit_task_relations	Anwender kann keine Beziehungen zwischen Aufgabentabellen definieren.
edit_ci_beziehungen	Der Benutzer kann keine Beziehungen zwischen Tabellen für Konfigurationselemente [cmdb_ci] definieren.
save_as_template	Wird verwendet, um die Felder zu steuern, die gespeichert werden sollen, wenn eine Vorlage erstellt wird.
add_to_list	Anwender können bestimmte Spalten in der Listenmechanik nicht anzeigen oder personalisieren.
list_edit	Anwender kann keine Datensätze (Zeilen) aus einer Liste aktualisieren.
report_on	Anwender kann keinen Bericht in der ACL-Tabelle erstellen. Weitere Informationen finden Sie unter Berichterstellung mit einer ACL-Regel einschränken.
report_view	Der Anwender kann den Inhalt eines Berichts in der ACL-Tabelle oder im ACL-Feld nicht anzeigen. Weitere Informationen finden Sie unter Reporting.
personalize_choices	Der Benutzer kann nicht mit der rechten Maustaste auf ein Listenfeld klicken und Auswahlmöglichkeiten konfigurierenauswählen.

ACL, die den Anforderungen für Objekte entspricht

Objekttyp	Übereinstimmende ACL-Regeln für Zugriffsobjekt erforderlich	Vorhandene Platzhalter-ACL-Regeln
Vom Client aufrufbare Skripteinbindungen	Benutzer müssen die Bedingungen von zwei ACL-Regeln erfüllen: Alle ACL-Regeln mit Platzhaltern für das Objekt (sofern für den Vorgang eine ACL-Regel vorhanden ist). Die erste ACL-Regel, die dem Namen des Objekts entspricht (sofern für den Vorgang eine ACL-Regel vorhanden ist).	Standardmäßig sind für diese Objekttypen keine Platzhalterregeln (*) vorhanden. 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	Benutzer müssen die Bedingungen von zwei ACL-Regeln erfüllen: Die erste ACL-Regel, die dem Feld des Datensatzes entspricht (sofern für den Vorgang eine ACL-Regel vorhanden ist). Die erste ACL-Regel, die der Tabelle des Datensatzes entspricht (sofern für den Vorgang eine ACL-Regel vorhanden ist).	Standardmäßig gibt es Platzhalter-Tabellenregeln (*) für die Vorgänge zum Erstellen, Lesen, Schreiben und Löschen sowie Platzhalter-Feldregeln (*.*) 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 für Platzhalter verwenden.
Datensatz

Hinweis:

Die Eigenschaft Security Manager-Standardverhalten (glide.sm.default_mode) bestimmt, ob Benutzer auf Objekte zugreifen können, die nur mit ACL-Regeln der Platzhaltertabelle übereinstimmen. Wenn diese Eigenschaft auf Zugriff verweigernfestgelegt ist, können nur Administratoren auf Objekte zugreifen, die den ACL-Regeln der Platzhaltertabelle entsprechen.

Hinweis:

Die ACL-Regel für das Platzhalterfeld (*.*) für den Erstellungsvorgang verwendet dieselben Bedingungen wie der Schreibvorgang. Dies bedeutet, dass die Erstellungsbedingungen mit den Schreibbedingungen übereinstimmen, es sei denn, Sie definieren eine explizite ACL-Regel für den Erstellungsvorgang.

Mehrere ACL-Regeln am selben Punkt in der Verarbeitungsreihenfolge

Wenn zwei oder mehr Regeln am selben Punkt in der Verarbeitungsreihenfolge übereinstimmen, muss der Benutzer eine beliebige ACL-Regelbedingung übergeben, um auf das Objekt zuzugreifen. Wenn Sie beispielsweise zwei Feld-ACL-Regeln für incident.numbererstellen, hat ein Benutzer, der eine Regel übergibt, Zugriff auf das Zahlenfeld, unabhängig davon, ob der Benutzer eine andere Feld-ACL-Regel am selben Punkt in der Verarbeitungsreihenfolge verfehlt hat.

Erforderliche Rolle

Normale Administratorbenutzer können Zugriffssteuerungsregeln anzeigen und debuggen. Um jedoch vorhandene Zugriffssteuerungsregeln zu erstellen oder zu aktualisieren, müssen Administratoren Berechtigungen für 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 gleichen Umfang wie die ACL-Regel erstellen. Sie können ACL-Regeln auch 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 Bereich als der ACL-Regeldatensatz befinden, sind die Regeltypen eingeschränkt.

• Sie können eine ACL-Regel für jede Tabelle, UI-Seite oder ein anderes Objekt erstellen, das sich im selben Bereich wie die ACL-Regel befindet.
• Sie können eine ACL für ein Feld erstellen, das sich im gleichen Umfang wie die ACL-Regel befindet.
  • Wenn sich die Tabelle im gleichen Bereich befindet, können Sie ein Skript verwenden, um Bedingungen auszuwerten.
  • 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 die in der Anwendungsauswahl ausgewählte Anwendung befinden, einschließlich durch Hinzufügen einer Rolle zu einer ACL in einem anderen Bereich.
• Sie können Platzhalter-Tabellenregeln (*) nur im globalen Bereich erstellen.
• Sie können Platzhalter-Feldregeln (*) nur für Tabellen erstellen, die sich im gleichen Umfang wie die ACL-Regel befinden.