HCL Domino · ACL · Security · Auditing

Effektive ACL-Zugriffsrechte in HCL Domino verstehen

Einen Blick in die ACL einer Domino-Datenbank zu werfen, ist einfach. Den tatsächlich effektiven Zugriff eines bestimmten Benutzers zu ermitteln, kann dagegen erheblich schwieriger sein – insbesondere dann, wenn Zugriffsrechte über Gruppen, verschachtelte Gruppen, Rollen und ACL-Flags zustande kommen.

Ein Benutzer muss nicht einmal explizit in der ACL einer Datenbank eingetragen sein und kann trotzdem über eine oder mehrere Gruppenzugehörigkeiten weitreichende Zugriffsrechte besitzen.

Die entscheidende Frage lautet deshalb nicht nur: „Ist dieser Benutzer in der ACL eingetragen?“

Viel wichtiger ist: „Welchen effektiven ACL-Zugriff hat dieser Benutzer aktuell tatsächlich auf diese Datenbank?“

In einer größeren Domino-Umgebung wird daraus sehr schnell die eigentliche Herausforderung: Lässt sich diese Frage zuverlässig für jeden Benutzer, jede Datenbank und jeden Server beantworten?
Analyse effektiver ACL-Zugriffsrechte Benutzer · verschachtelte Gruppen · ACLs · Rollen · Access Flags Domino-Benutzer Benutzeridentitäten direkte Gruppen verschachtelte Gruppen vollständige Names Lists API Engine Gruppen auflösen ACLs + Historie lesen effektiven Zugriff berechnen Domino-ACLs mehrere Server Zugriffsebenen Rollen / Privilegien ACL-Flags Benutzer × Datenbank = effektiver ACL-Zugriff Reporting · Auditing · Monitoring · Alerts · eigene Verarbeitung
Das praktische Problem

Ein ACL-Eintrag ist nicht dasselbe wie effektiver Zugriff

In einer kleinen Domino-Umgebung kann es ausreichen, die ACL einer Datenbank manuell zu kontrollieren. In einer Infrastruktur, die über viele Jahre gewachsen ist, kann der tatsächliche Zugriffsweg jedoch wesentlich weniger offensichtlich sein.

Ein Benutzer kann seine Rechte über eine direkt zugewiesene Gruppe, über mehrere Ebenen verschachtelter Gruppen, über Organisationseinträge oder über andere ACL-Einträge erhalten, die in die Domino-Zugriffsberechnung einfließen.

Was in der ACL sichtbar ist
  • die in der Datenbank-ACL gespeicherten Einträge
  • Benutzer, Gruppen und hierarchische Namen
  • konfigurierte Zugriffsebenen
  • Rollen und Privilegien
  • ACL-Access-Flags
Was tatsächlich relevant ist
  • zu welchen Gruppen ein bestimmter Benutzer gehört
  • welche verschachtelten Gruppen beteiligt sind
  • welche ACL-Einträge dadurch für diesen Benutzer gelten
  • welche Zugriffsebene letztlich effektiv ist
  • welche Rollen, Privilegien und Flags dadurch wirksam werden
Diese Unterscheidung wird insbesondere bei internen Audits, Least-Privilege-Prüfungen, Compliance-Kontrollen und Security-Analysen wichtig.
Ziel der Demo

Aufbau einer Matrix effektiver Zugriffsrechte

Das zugehörige Engine-Skript demonstriert, wie sich diese Fragen programmatisch über mehrere Domino-Server und Datenbanken hinweg analysieren lassen.

Die Demo ermittelt zunächst die Domino-Benutzer und erzeugt für jeden Benutzer eine vollständige Names List einschließlich direkter und indirekter Gruppenzugehörigkeiten. Anschließend werden die Datenbanken der konfigurierten Server ermittelt, deren ACLs gelesen und jeder Benutzer gegen jede erfolgreich gelesene ACL ausgewertet.

  • Domino-Benutzer aus dem Domino Directory ermitteln
  • direkte und verschachtelte Gruppenzugehörigkeiten auflösen
  • Datenbanken auf einem oder mehreren Domino-Servern ermitteln
  • die ursprünglichen ACL-Einträge jeder Datenbank lesen
  • die verfügbare ACL-Historie auslesen
  • den effektiven Zugriff für jede Benutzer-/Datenbank-Kombination berechnen
  • Zugriffsebenen, Rollen, Privilegien und ACL-Flags speichern
  • die Ergebnisse in eine zentrale Domino-Reporting-Datenbank schreiben

Das Beispiel konzentriert sich bewusst auf das zentrale ACL- und Gruppenauflösungs-Szenario. Domino bietet darüber hinaus weitere ACL-Eigenschaften und Sicherheitsmechanismen – beispielsweise den maximalen Internetzugriff per Name und Passwort sowie besondere administrative Zugriffsrechte –, die ebenfalls in weiterführende Analyse-Workflows einbezogen werden könnten. Die API-Engine stellt auch für solche Informationen entsprechende Funktionen bereit; sie wurden hier jedoch bewusst weggelassen, um das Beispiel übersichtlich und auf den Kern des Themas fokussiert zu halten.

Das Ergebnis ist eine Datenbasis, die sich aus beiden Richtungen betrachten lässt: Auf welche Datenbanken hat dieser Benutzer Zugriff? oder Welche Benutzer besitzen effektiven Zugriff auf diese Datenbank?
Effiziente Verarbeitung

Einmal auflösen, einmal lesen, im Speicher wiederverwenden

Eine einfache Implementierung könnte für jeden Benutzer erneut die Gruppenstruktur auflösen und für jede einzelne Auswertung die betreffende Datenbank erneut öffnen und deren ACL lesen. Das würde unnötigen Aufwand erzeugen.

Die Demo trennt deshalb die Vorbereitung von der eigentlichen Auswertung.

Names Lists der Benutzer Die vollständige Names List jedes Benutzers wird einmal aufgelöst und während der Verarbeitung der konfigurierten Server im Speicher gehalten.
Datenbank-ACLs Jede ACL wird einmal als In-Memory-Struktur gelesen und anschließend für alle Benutzer wiederverwendet, die gegen diese Datenbank ausgewertet werden.
Datenbank-Handles Die Datenbanken müssen nur so lange geöffnet bleiben, wie ihre ACL und gegebenenfalls optionale Dokumentinformationen gelesen werden.
Berechnung des effektiven Zugriffs Die eigentliche Benutzer-/Datenbank-Matrix wird aus den bereits vorbereiteten Names Lists und ACL-Strukturen berechnet, ohne jede Datenbank für jeden Benutzer erneut öffnen zu müssen.
Diese Architektur hält die eigentliche Zugriffsberechnung kompakt und vermeidet, dass aufwendige Vorbereitungsschritte für jede Benutzer-/Datenbank-Kombination erneut ausgeführt werden müssen.
Engine-Skript-Beispiel

Der Kern der effektiven ACL-Zugriffsberechnung

Das vollständige Beispielskript enthält zusätzlich die Ermittlung der Datenbanken, Reporting-Dokumente, ACL-Historie, Fehlerbehandlung und die optionale Analyse dokumentbasierter Zugriffsrechte. Die eigentliche Berechnung des effektiven ACL-Zugriffs bleibt dennoch vergleichsweise kompakt.

Engine-Skript-Auszug Effektiver ACL-Zugriff
/* Benutzer einschließlich direkter und verschachtelter Gruppen auflösen. */
UserGroups := @ResolveUserGroups(UserName; hNamesList);

/* Domino-Datenbank öffnen und eine In-Memory-Kopie ihrer ACL erzeugen. */
DBh := @OpenDB(ServerName + "!!" + DBPath);
hACL := @ReadACL(DBh);

/* Für die ACL-Auswertung wird die Datenbank selbst nicht mehr benötigt. */
DBh := @CloseDB(DBh);

/* Den effektiven ACL-Zugriff dieses Benutzers ermitteln. */
Result := @ACLGetEffectiveUserAccess(
    hACL;
    hNamesList;
    UserLevel;
    UserPrivileges;
    UserPrivilegeNames
);

@LogReport(UserLevel);
@LogReport(UserPrivileges);
@LogReport(UserPrivilegeNames);

/* Temporäre In-Memory-Strukturen wieder freigeben. */
hACL := @ReleaseACL(hACL);
Result := @DestroyNameList(hNamesList);

Die vollständige Demo erweitert dieses Prinzip zu einer kompletten Matrix über alle konfigurierten Benutzer, Datenbanken und Server.

Reporting-Perspektiven

Dieselben Daten beantworten unterschiedliche Security-Fragen

Sobald die berechneten Zugriffsinformationen in der Reporting-Datenbank gespeichert wurden, können Domino-Ansichten dieselben Daten aus unterschiedlichen Blickwinkeln darstellen.

ACL nach Datenbank Anzeige der ursprünglichen ACL-Einträge, Zugriffsebenen, Privilegien, Rollen und Flags der analysierten Datenbanken.
Gruppen nach Benutzer Anzeige des aufgelösten Benutzers einschließlich seiner direkten und indirekten Gruppenzugehörigkeiten.
Benutzerzugriff nach Datenbank Ermitteln, welche Benutzer effektiv Zugriff auf eine bestimmte Datenbank besitzen und mit welcher Zugriffsebene.
Benutzerzugriff nach Benutzer Übersicht über den effektiven Zugriff eines einzelnen Benutzers auf zahlreiche Datenbanken und Domino-Server.
Zugriff nach Privileg Ermitteln, welche Benutzer bestimmte Rollen oder Privilegien innerhalb der analysierten Umgebung erhalten.
Zugriff nach ACL-Flag Kategorisierung des effektiven Zugriffs anhand zusätzlicher ACL-Flags, die bei der Zugriffsberechnung ermittelt wurden.
Diese Ansichten sind lediglich Beispiele. Die berechneten Informationen können genauso gut exportiert, aggregiert, mit Richtlinien verglichen oder an andere Reporting-, Monitoring- oder Security-Systeme weitergegeben werden.
ACL-Historie

Nicht nur den aktuellen Zustand betrachten

Die Demo liest zusätzlich mit @GetACLHistory die in Domino verfügbare ACL-Historie aus und speichert sie zusammen mit der analysierten ACL.

Dadurch erhält ein aktueller Zugriffs-Snapshot zusätzlichen Kontext und es entsteht eine weitere Informationsquelle für Audit- oder Security-Auswertungen.

  • die aktuelle ACL-Konfiguration analysieren
  • die in Domino verfügbare ACL-Historie auslesen
  • aktuelle Zugriffsinformationen mit historischen ACL-Informationen kombinieren
  • die Daten als Grundlage für ein eigenes Change Tracking verwenden
  • projektspezifische Prüfungen oder Benachrichtigungen auslösen
Die Demo selbst erzeugt bewusst bei jedem Lauf einen neuen Reporting-Snapshot. Sie führt keine eigene Historie der vorherigen Scan-Ergebnisse. Eine solche Historisierung, Vergleichslogik oder Alarmierung kann abhängig von den jeweiligen Anforderungen ergänzt werden.
Dokumentbasierte Sicherheit

ACL-Zugriff ist nur eine Sicherheitsebene

Effektiver Zugriff über die Datenbank-ACL bedeutet nicht automatisch, dass ein Benutzer jedes Dokument der Datenbank lesen oder bearbeiten kann. Domino kann zusätzliche dokumentbasierte Zugriffsbeschränkungen über Reader-Names- und Author-Names-Felder anwenden.

Aus diesem Grund enthält das Beispiel optional einen Scan, der Dokumente auf Reader-Names- und Author-Names-Felder untersucht. Werden solche Felder gefunden, erzeugt das Skript ein Reporting-Dokument mit Informationen über Quelldatenbank und Quelldokument sowie einem direkten Domino-Dokumentlink.

Reader Names

Reader-Names-Felder können den Kreis der Benutzer, die ein einzelnes Dokument lesen dürfen, zusätzlich einschränken – selbst wenn über die ACL grundsätzlich Zugriff auf die Datenbank besteht.

Author Names

Author-Names-Felder wirken bei der dokumentbezogenen Bearbeitungsberechtigung für Benutzer mit einer ACL-Zugriffsebene mit, bei der diese zusätzliche Autorenberechtigung erforderlich ist.

Wichtig: Diese Option ist standardmäßig deaktiviert. Das Erkennen von Reader- und Author-Names-Feldern erfordert die Untersuchung einzelner Dokumente. In großen Datenbanken können dies hunderttausende oder Millionen Dokumente sein, sodass der Scan sehr schnell erheblichen Aufwand verursachen kann.

Das Beispiel öffnet die Quelldokumente dabei nur mit ihren Summary-Informationen und begrenzt die Anzahl der pro Datenbank erzeugten Reader-/Author-Reporting-Dokumente. Diese Begrenzung hält die Demo-Reporting-Datenbank überschaubar, reduziert jedoch nicht die Anzahl der Quelldokumente, die gegebenenfalls untersucht werden müssen.

Über die Demo hinaus

Von der Zugriffsanalyse zum automatisierten Security-Workflow

Die mitgelieferte Reporting-Datenbank ist bewusst einfach gehalten. Sie soll zeigen, welche Informationen ermittelt werden können und wie sich die Ergebnisse für weitere Verarbeitungsschritte bereitstellen lassen.

Sobald die effektiven Zugriffsinformationen programmatisch verfügbar sind, ergeben sich zahlreiche weitere Möglichkeiten.

Automatische Zugriffsprüfungen Effektive Zugriffsrechte mit definierten Security-Richtlinien oder erwarteten Zugriffsebenen vergleichen.
Security-Alerts Benachrichtigungen auslösen, wenn kritische Zugriffsebenen, Rollen oder Privilegien erkannt werden.
Regelmäßige Audit-Läufe Die Analyse periodisch ausführen und ausgewählte Ergebnisse für spätere Vergleiche aufbewahren.
Change Tracking Aktuelle Ergebnisse mit vorherigen Läufen vergleichen und neu hinzugekommene, entfernte oder veränderte Zugriffsrechte erkennen.
Externes Reporting Ergebnisse an SQL, CSV, XML, REST-Dienste oder andere Reporting- und Analysesysteme übergeben.
Individuelle Security-Logik Projektspezifische Regeln rund um Benutzer, Datenbanken, Rollen, Gruppen, ACL-Flags oder dokumentbasierte Sicherheit implementieren.
Dies ist bewusst keine fertige Security-Anwendung. Das Beispiel soll die verfügbaren Bausteine demonstrieren und als Inspiration für kundenspezifische Security-, Audit- und Reporting-Lösungen dienen.
Enthaltenes Evaluation-Beispiel

Die ACL-Analyse in einer Testumgebung ausprobieren

Das aktuelle Domino API Engine Evaluation-Paket enthält das Beispielskript und passende Domino-Testdatenbanken für dieses ACL-Analyse-Szenario.

Das Beispiel ist für eine kontrollierte Nicht-Produktivumgebung vorgesehen. Vor dem Start sollten die konfigurierten Servernamen, Datenbankpfade und insbesondere der optionale Reader-/Author-Dokumenten-Scan geprüft werden.

Evaluation-Setup
  • Das aktuelle Domino API Engine Evaluation-Paket herunterladen und entpacken.
  • Die Engine entsprechend der mitgelieferten README-Datei installieren und konfigurieren.
  • Unbedingt die im aktuellen Evaluation-Paket enthaltenen Binaries verwenden.
  • Die mitgelieferten Beispiel-Datenbanken wie im Paket beschrieben unterhalb des Domino-Data-Verzeichnisses ablegen.
  • Falls erforderlich, DestDBPath im Beispielskript anpassen.
  • Die zu analysierenden Domino-Server konfigurieren oder alternativ die Verarbeitung ausschließlich auf dem lokalen Server aktivieren.
  • Die ACLs der Reporting- und Quelldatenbanken prüfen und bei Bedarf anpassen.
  • Den Reader-/Author-Dokumenten-Scan deaktiviert lassen, sofern dieser nicht ausdrücklich getestet werden soll.
  • Das mitgelieferte ACL-Analyse-Skript aus der Engine-Control-Datenbank starten.
  • Die erzeugten Reporting-Ansichten öffnen und Benutzer, Gruppen, ACLs und effektive Zugriffsrechte auswerten.
Wichtig: Mehrere der in diesem Beispiel verwendeten API-Engine-Funktionen wurden inzwischen für die allgemeine Evaluation freigeschaltet. Deshalb müssen beim Ausführen des Beispiels die Binaries aus dem aktuellen Evaluation-Paket verwendet werden.
Sie möchten effektive ACL-Zugriffsrechte in Ihrer Domino-Umgebung untersuchen? Das Evaluation-Beispiel bietet einen Ausgangspunkt für eigene Zugriffsanalysen, Reporting-, Audit- oder Security-Automatisierungen mit der Domino API Engine.
Szenario besprechen Evaluation herunterladen Funktionsdokumentation