AD vertrauliche Attribute: Lesezugriff prüfen

Was sind vertrauliche AD-Attribute?

AD vertrauliche Attribute sind Verzeichnisattribute, für die eine zusätzliche Prüfung des Lesezugriffs gilt. Ermitteln Sie zunächst, welche benutzerdefinierten Attribute tatsächlich sensible Geschäftsdaten enthalten, und prüfen Sie anschließend, wer sie lesen kann. Ein bloßer Hinweis auf die Datenklassifizierung belegt weder eine Offenlegung von Daten noch einen fehlenden Attributschutz oder die Nichterfüllung einer Compliance-Anforderung durch die Organisation.

Dieser Leitfaden verwendet ein eng begrenztes Beispiel: ein benutzerdefiniertes Attribut, das für einen bestimmten Geschäftszweck freigegeben wurde, mit einem benannten Verantwortlichen und einer dokumentierten Liste von Leseberechtigten. Er beschreibt ein Prüfverfahren im Labor mit künstlichen Testwerten. Für diesen Artikel wurde kein Active-Directory-Test durchgeführt. Keines der nachfolgend erwarteten Ergebnisse wird als beobachtetes Ergebnis dargestellt.

Das nützliche Arbeitsergebnis ist ein Entscheidungsprotokoll zum Lesezugriff: die Klassifizierung des Attributs, seine Eignung auf Schemaebene, die effektiv leseberechtigten Identitäten, das erwartete Anwendungsverhalten und jede gemessene Abweichung davon. Vervollständigen Sie dieses Protokoll, bevor Sie eine Schemaänderung vorschlagen.

So funktioniert die Prüfung des vertraulichen Lesezugriffs

Die MS-ADTS-Definition von searchFlags kennzeichnet fCONFIDENTIAL als Bit 0x80 (128). Es erfordert eine erweiterte Zugriffsprüfung. Andere Flags haben eigene Bedeutungen. Deshalb ist es wichtig, den gesamten vorhandenen Wert zu dokumentieren.

Für ein Attribut mit diesem Flag verlangt MS-ADTS Extended Access Checks sowohl READ_PROPERTY als auch CONTROL_ACCESS. Ohne die erforderlichen Rechte wird der Wert in zurückgegebenen Attributen und im LDAP-Filter als nicht vorhanden behandelt. Ein fehlender Wert reicht daher nicht aus, um eine Zugriffsbeschränkung von einem leeren Attribut zu unterscheiden.

Microsofts Leitfaden zu vertraulichen Attributen schließt Attribute des Basisschemas aus, die durch FLAG_SCHEMA_BASE_OBJECT (0x10) in systemFlags gekennzeichnet sind. Sein Beispiel unterscheidet employeeID, ein Basisattribut, von einem geeigneten Attribut. Eine sensible geschäftliche Bedeutung hebt diese Schemabeschränkung nicht auf.

Derselbe Leitfaden erklärt, dass Full Control CONTROL_ACCESS einschließt und dass generische Berechtigungszuweisungen weiter reichen können als attributspezifische ACEs. Sowohl explizite als auch geerbte Zuweisungen sind relevant. Behandeln Sie einen Screenshot eines einzelnen Berechtigungseintrags als Grundlage für die Prüfung, nicht als vollständige Antwort zum effektiven Zugriff.

Erkennung: Ein freigegebenes Attributinventar erstellen

Schritt 1 — Klassifizierung und Verantwortlichen festlegen

Fragen Sie den Datenverantwortlichen, welche benutzerdefinierten Attribute Informationen enthalten, deren Lesezugriff eingeschränkt werden muss. Dokumentieren Sie die freigegebene Klassifizierung und den Zweck, ohne Produktionswerte in die Prüfung zu übernehmen. Ein Feldname wie „private“ oder „confidential“ ist keine freigegebene Klassifizierung.

Erfassen Sie für jeden Kandidaten seinen LDAP-Anzeigenamen, den DN des Schemaobjekts, die verwendenden Objektklassen, den fachlich Verantwortlichen, die berechtigten Leser und die nutzenden Anwendungen. Klären Sie außerdem, wer eine Änderung genehmigen darf. Wenn Verantwortung oder Klassifizierung ungeklärt sind, lassen Sie die Zugriffserwartung offen und geben Sie die Frage an das zuständige Team weiter.

Ein kleines Prüfblatt ist nützlicher als eine pauschale Liste sämtlicher Attribute:

Beschränken Sie das Inventar auf tatsächlich sensible benutzerdefinierte Attribute. Wenn die Untersuchung Zugangsdaten in gewöhnlichen Notizfeldern aufdeckt, folgen Sie dem gesonderten Verfahren zur Beseitigung offengelegter Passwörter und zu deren Rotation. Eine Änderung des Vertraulichkeitsflags ersetzt nicht die Behandlung dieser Offenlegung.

Schritt 2 — Das Schema vor einer möglichen Änderung lesen

Verwenden Sie einen dafür vorgesehenen Domänencontroller im Labor und einen bekannten Kandidaten aus dem freigegebenen Inventar. Diese Beispiele setzen das PowerShell-Modul ActiveDirectory voraus. Ersetzen Sie den Beispielserver und das Attribut durch entsprechende Laborwerte. Führen Sie die Befehle im Rahmen dieses Verfahrens nicht in der Produktion aus.

Die Dokumentation zu Get-ADRootDSE stellt schemaNamingContext bereit. Get-ADObject unterstützt LDAP-Filter, eine Suchbasis, einen expliziten Server und zusätzliche Eigenschaften. Das folgende Beispiel kombiniert diese dokumentierten Parameter ausschließlich zum Lesen:

$dc = 'dc01.lab.example'
$schema = (Get-ADRootDSE -Server $dc).schemaNamingContext
Get-ADObject -Server $dc -SearchBase $schema -LDAPFilter '(lDAPDisplayName=labSensitiveReference)' -Properties lDAPDisplayName,searchFlags,systemFlags,schemaIDGUID,attributeSecurityGUID

Dokumentieren Sie den DN des zurückgegebenen Objekts und die vollständigen Flag-Werte. Wenn die Abfrage fehlschlägt oder das vorgesehene Attribut nicht identifiziert, beenden Sie die Bewertung dieses Kandidaten. Machen Sie aus einer erfolglosen Suche weder „nicht vertraulich“ noch „geeignet“.

Prüfen Sie, ob das Vertraulichkeitsbit bereits vorhanden ist und ob das Basisschema-Bit die vorgesehene Verwendung ausschließt. Bewahren Sie die vorhandenen Flag-Werte einschließlich der sonstigen Bits als Nachweis auf. In dieser Phase entsteht eine Eignungsbewertung, keine Aufforderung, jedes sensibel wirkende Feld auf 128 zu setzen.

Schritt 3 — Den effektiven Lesezugriff erklären

Prüfen Sie für jeden freigegebenen Leser und jede repräsentative Identität außerhalb dieser Gruppe den Sicherheitsdeskriptor des Zielobjekts sowie die relevante Vererbung aus übergeordneten Containern. Berücksichtigen Sie den Gruppenkontext, geltende Verweigerungen, den Geltungsbereich für Attribute oder Eigenschaftssätze, generische ACEs und eine gegebenenfalls deaktivierte Vererbung. Dokumentieren Sie die Begründung der Zugriffserwartung.

Prüfen Sie READ_PROPERTY und, sofern Vertraulichkeit gilt, CONTROL_ACCESS getrennt. Die Fähigkeit eines Lesers, das Objekt zu durchsuchen, beantwortet nicht die Frage, ob er den Kandidatenwert erhalten kann. Ebenso kann eine eng beschriebene Anwendungsrolle über eine andere Gruppe oder einen geerbten Eintrag dennoch weitreichenden Zugriff erhalten.

Achten Sie besonders auf Full Control und generische Zuweisungen von control-access-Rechten. Die praktische Frage lautet, ob diese Zuweisungen einer Identität das zusätzliche Recht bereits geben, nicht ob eine ACE zufällig den Attributnamen enthält. Dokumentieren Sie den Ursprung der Zuweisung, damit ein späterer Prüfer die Begründung nachvollziehen kann.

Diese Prüfung betrifft die Vereinbarung zum Lesen eines benutzerdefinierten Attributs. Für die gesonderte Untersuchung von Schema-Schreibberechtigungen und defaultSecurityDescriptor verwenden Sie das Audit der Schemaberechtigungen und des Standard-Sicherheitsdeskriptors.

Laborprüfung: Zwei Leseridentitäten vergleichen

Schritt 4 — Einen bekannten künstlichen Testwert bereitstellen

Bereiten Sie ein isoliertes Testobjekt mit einem eindeutig künstlichen Wert im freigegebenen Kandidatenattribut vor. Lassen Sie den Laborverantwortlichen bestätigen, dass der Wert existiert, erfassen Sie seine Kennung im Testprotokoll und dokumentieren Sie den Aufbau. Verwenden Sie keine echten Personaldaten, betrieblichen Geheimnisse oder Exporte eines Produktionsverzeichnisses.

Wählen Sie eine Identität, der der Verantwortliche das Lesen des Werts erlaubt hat, und eine repräsentative Identität, die ihn nicht lesen soll. Dokumentieren Sie deren Gruppenkontext. Keine der beiden Identitäten darf stillschweigend durch das Administratorkonto ersetzt werden, das zur Schemaprüfung verwendet wurde.

Verwenden Sie für beide Lesevorgänge denselben Endpunkt, dasselbe Objekt und dasselbe angeforderte Attribut. Der dokumentierte credential-Parameter von Get-ADObject akzeptiert einen Kontonamen und fragt nach dessen Passwort. Dies sind vorgeschlagene Laborbefehle, keine protokollierten Ausführungen:

Get-ADObject -Server 'dc01.lab.example' -Identity 'CN=ReadContractTest,OU=Lab,DC=lab,DC=example' -Properties labSensitiveReference -Credential 'LAB\ApprovedReader'

Get-ADObject -Server 'dc01.lab.example' -Identity 'CN=ReadContractTest,OU=Lab,DC=lab,DC=example' -Properties labSensitiveReference -Credential 'LAB\OutsideReader'

Prüfen Sie die angeforderte Eigenschaft in jedem zurückgegebenen Objekt. Dokumentieren Sie, ob sie die bekannte Testkennung enthält, fehlt oder leer ist oder ob der Befehl einen Fehler meldet. Unterscheiden Sie fehlgeschlagene Authentifizierung, Verbindungsfehler und fehlende Testdaten von einer Zugriffsbeschränkung.

Schritt 5 — Den Unterschied dokumentieren, ohne einen Erfolg zu erfinden

Die folgende Tabelle legt zu prüfende Erwartungen fest. Sie enthält kein gemessenes Ergebnis:

Wenn beide Identitäten die Kennung lesen, untersuchen Sie die effektiven Zuweisungen und den aktuellen Flag-Zustand. Wenn keine sie liest, prüfen Sie zunächst den Testaufbau, den Endpunkt, die Zugangsdaten und die angeforderte Eigenschaft. Wenn der freigegebene Leser erfolgreich ist und der andere nicht, bewahren Sie die Nachweise mit ihrem Geltungsbereich auf: Der Vergleich deckt diese Identitäten und diese Konfiguration ab.

Verallgemeinern Sie einen einzelnen Vergleich nicht zu einem Beweis dafür, dass jeder Benutzer und jede Anwendung korrekt eingeschränkt ist. Ergänzen Sie repräsentative Lesergruppen und Vererbungsgrenzen entsprechend dem freigegebenen Inventar. Dokumentieren Sie für jeden Fall Datum, ausführende Person, Endpunkt, Schemawerte, Abfrage, Identitätskontext, Ergebnis und offene Fragen.

Reproduzieren Sie bei Anwendungen mit einem anderen Abfrageweg diesen Weg gesondert mit künstlichen Daten. Die searchFlags-Spezifikation weist auf Verhaltensunterschiede bei DirSync-Steuerelementen hin. Dokumentieren Sie gegebenenfalls diese Steuerelemente und das Clientverhalten. Ein PowerShell-Lesevorgang allein validiert nicht die Synchronisationsvereinbarung einer Anwendung.

Abhilfe: Vor einer Schemaänderung entscheiden (Remediation)

Schritt 6 — Die Maßnahme aus den Nachweisen ableiten

Wenn Klassifizierung oder Verantwortlichkeit fehlen, holen Sie zuerst diese Entscheidung ein. Wenn der aktuelle Zugriff bereits der freigegebenen Vereinbarung entspricht, bewahren Sie die Nachweise und den Prüfplan auf. Wenn eine Lücke beim Lesezugriff gemessen wird, schlagen Sie eine konkrete Korrektur vor und nennen Sie die betroffenen Identitäten und Anwendungen.

Eine vorgeschlagene Schemaänderung benötigt eine gesonderte dokumentierte Entscheidung. Berücksichtigen Sie die Eignung des Attributs, seine ursprünglichen Flag-Werte, die erforderlichen Leser, den Geltungsbereich der Zuweisungen, die für die Umsetzung verantwortliche Person, den Kompatibilitätsplan für nutzende Anwendungen, die Prüfkriterien und das Rücksetzverfahren. Bewahren Sie die sonstigen searchFlags-Bits in der vorgeschlagenen Konfiguration. Behandeln Sie 128 nicht als universellen Ersatzwert.

Microsoft empfiehlt, Attributänderungen in einem Labor zu testen, das die Produktionsgesamtstruktur widerspiegelt. Validieren Sie dort die genaue vorgeschlagene Kombination aus Schemakonfiguration und Berechtigungen. Der historische Leitfaden enthält versionsspezifische Werkzeuganweisungen. Prüfen Sie vor der Umsetzung deren Eignung für die Zielumgebung.

Schritt 7 — Kompatibilität und Rücksetzung validieren

Fragen Sie den Verantwortlichen jeder nutzenden Anwendung, welcher Vorgang vom Attribut abhängt und unter welcher Identität er ausgeführt wird. Validieren Sie die freigegebene Funktion mit künstlichen Testwerten, einschließlich des Umgangs der Anwendung mit einer unlesbaren oder fehlenden Eigenschaft. Ein autorisierter Verzeichnis-Lesezugriff und ein funktionierender Geschäftsprozess sind getrennte Abnahmeprüfungen.

Definieren Sie das Rücksetzverfahren vor der Bereitstellungsfreigabe: Dokumentieren Sie den ursprünglichen Schema-Flag-Wert, die genau betroffenen Berechtigungseinträge, wer sie wiederherstellen darf und wie die Wiederherstellung geprüft würde. Die Rückkehr zu einer früheren Konfiguration kann das Lesen erneut ermöglichen. Berücksichtigen Sie diese Folge in der Entscheidung. Beschreiben Sie eine Rücksetzung nicht als Löschung zuvor gelesener oder kopierter Daten.

Die Prüfung ist erst abgeschlossen, wenn drei Fragen ausdrücklich beantwortet sind: Welche Daten haben eine freigegebene Klassifizierung und einen Verantwortlichen? Ist das Attribut geeignet, und welche effektiven Rechte ermöglichen den Zugriff? Welche berechtigten nutzenden Anwendungen müssen nach einer möglichen Änderung kompatibel bleiben? Weisen Sie jede offene Antwort einem Verantwortlichen zu, statt die Bewertung als abgeschlossen zu markieren.

Wie EtcSec dies erkennt

DATA_CLASSIFICATION_MISSING ist ein informativer Prüfungshinweis in etc-collector. Beim Collector-Commit 0423094759d50002457031317098417993e19510 definiert public/internal/audit/detectors/ad/compliance/industry/data-classification.go:23 eine Detect()-Funktion, die sowohl data als auch ctx ignoriert und keinen Provider verwendet.

Sie liefert immer genau einen Befund mit dem Schweregrad Info und einem festen Count: 1. Titel, Beschreibung, Beispiele sensibler Daten und Empfehlungen sind statisch. Die Zahl steht nicht für die Anzahl offengelegter Attribute, fehlender Klassifizierungen oder fehlgeschlagener Lesetests.

Dieser Detektor misst weder Datenklassifizierung noch die Konfiguration vertraulicher Attribute, effektive Rechte oder die Kompatibilität nutzender Anwendungen. Sein Befund liefert keinen Nachweis für eine Offenlegung oder einen Compliance-Verstoß. Verwenden Sie ihn, um das oben beschriebene Inventar und das Entscheidungsprotokoll im Labor anzustoßen. Halten Sie diese manuellen Beobachtungen von der Detektorausgabe getrennt.

Technische Quellen und Collector-Implementierung wurden am 4. Oktober 2026 geprüft. Der Laborvergleich bleibt ein Verfahren, das der Leser mit freigegebenen künstlichen Testdaten selbst ausführen muss.