IT-Sicherheit
Sicherheitskonzepte beschreiben häufig den Soll-Zustand. Für eine technische Begutachtung ist entscheidend, welche Konfiguration tatsächlich aktiv ist und welche Zugriffswege sich daraus ergeben. Rollen, Identitäten, Policies, Netzgrenzen und privilegierte Konten werden deshalb als konkrete technische Artefakte untersucht.
Kurzantwort
Die Prüfung vergleicht dokumentierte Sicherheitsanforderungen mit der wirksamen Konfiguration. Untersucht werden Identitäten, Rollen, Authentisierung, Autorisierung, privilegierte Zugänge, Service Accounts und relevante Netzwerk- oder Applikationsgrenzen. Das Vorhandensein eines Controls beweist nicht automatisch seine Wirksamkeit im konkreten System.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Soll-Konzept und Ist-Konfiguration trennen
Richtlinien, Architekturdiagramme und Berechtigungskonzepte sind wichtige Referenzen, aber keine unmittelbaren Nachweise des produktiven Zustands. Der Ist-Zustand wird aus Konfigurationsdateien, Policies, IAM-Systemen, Datenbankrechten, Applikationsrollen und gegebenenfalls reproduzierbaren Zugriffstests abgeleitet.
Abweichungen können beabsichtigt, historisch gewachsen oder fehlerhaft sein. Die technische Begutachtung dokumentiert zunächst die Abweichung und ihren Wirkbereich.
Ob eine Abweichung organisatorisch genehmigt oder rechtlich relevant ist, wird getrennt behandelt.
2. Identitäten und Authentisierung
Zu prüfen ist, welche Identitäten existieren, wie sie authentisiert werden und welche technischen Faktoren den Zugriff ermöglichen. Lokale Konten, SSO, API-Schlüssel, Zertifikate und Service Accounts können parallel vorkommen.
Wichtig ist die effektive Konfiguration: Ein vorgesehenes MFA-Verfahren kann beispielsweise für einzelne privilegierte oder technische Konten nicht gelten. Solche Ausnahmen sind für die technische Bewertung relevant.
Geheimnisse selbst werden nicht unnötig offengelegt. Für den Befund genügt häufig die Identifikation von Typ, Gültigkeitsbereich und sicherem Fingerprint.
3. Autorisierung und effektive Berechtigungen
Rollen- und Gruppenmodelle können durch Vererbung, verschachtelte Gruppen oder Ressourcenrichtlinien komplex werden. Deshalb sollte soweit möglich die effektive Berechtigung auf relevante Ressourcen bestimmt werden.
Bei Cloud- und Plattformdiensten können mehrere Policy-Ebenen zusammenwirken. Ein einzelner Screenshot einer Rolle bildet dann nicht zwingend den gesamten Zugriffspfad ab.
Die Prüfung sollte besonders privilegierte Rechte, administrative Schnittstellen und maschinelle Konten berücksichtigen, weil sie einen größeren Wirkbereich besitzen können.
4. Konfigurationsänderungen und Nachvollziehbarkeit
Sicherheitskonfiguration ist zeitabhängig. Auditlogs, Infrastructure-as-Code, Repository-Historie und Änderungsprotokolle können helfen, einen früheren Zustand zu rekonstruieren.
Fehlen historische Daten, kann nur der aktuelle Stand belastbar festgestellt werden. Aus ihm darf nicht ohne weitere Evidenz auf einen früheren Zustand geschlossen werden.
Bei wiederholbaren Konfigurationsprüfungen sollten verwendete Werkzeuge, Versionen und relevante Parameter dokumentiert werden.
5. Technische Bewertung und Grenzen
NIST SP 800-53 strukturiert Sicherheits- und Datenschutzkontrollen unter anderem in Access Control, Identification and Authentication, Configuration Management und Audit and Accountability. Diese Kategorien können als Such- und Strukturierungshilfe dienen.
Ein konkretes System wird jedoch nicht allein dadurch „konform“, dass einzelne Kontrollen wiedererkennbar sind. Bewertungsmaßstab, Systemkontext und tatsächlich beobachtete Umsetzung müssen zusammengeführt werden.
Der Gutachtenbefund sollte deshalb klar zwischen vorhandener Konfiguration, effektiver Wirkung, dokumentierter Anforderung und verbleibender Unsicherheit unterscheiden.
6. Effektive Berechtigungsmatrix und Pfadanalyse
Eine Berechtigungsmatrix sollte nicht nur nominelle Rollen auflisten, sondern effektive Rechte abbilden. Dazu gehören direkte Zuweisungen, Gruppen, verschachtelte Gruppen, Vererbung, temporäre Elevation, Service-Identitäten und technische Ausnahmen. In Cloud-Umgebungen können zusätzlich ressourcenbasierte Policies oder organisationsweite Regeln wirken.
Für privilegierte Aktionen ist eine Pfadanalyse hilfreich: Welche Identität kann über welchen Mechanismus eine bestimmte Ressource erreichen oder eine bestimmte Aktion ausführen? Ein Konto ohne direktes Administratorrecht kann beispielsweise über Gruppenmitgliedschaft, Delegation oder einen Service Account dennoch privilegierte Wirkung entfalten.
Konfigurationsänderungen werden soweit möglich zeitlich eingeordnet. Auditlogs, Infrastructure-as-Code-Historien, Konfigurationsmanagement oder Cloud-Change-Historien können zeigen, wann eine Abweichung entstand und ob sie dauerhaft oder nur vorübergehend bestand.
Bei zeitkritischen Fragestellungen reicht die heutige Konfiguration nicht aus. Eine aktuell korrekte Berechtigung kann eine frühere Fehlkonfiguration überdecken. Soweit verfügbar, werden deshalb Historien aus Identity-Providern, Cloud-Auditlogs, Infrastructure-as-Code-Repositories oder Konfigurationsmanagement herangezogen. Fehlt eine solche Historie, muss die Aussage ausdrücklich auf den gegenwärtig beobachtbaren Zustand begrenzt werden.
Warum reicht eine Rollenliste nicht aus?
Rollenlisten zeigen häufig nur eine organisatorische Sicht. Effektive Zugriffe können aus mehreren technischen Ebenen zusammengesetzt sein.
NIST SP 800-53 führt unter anderem Control Families für Access Control, Identification and Authentication sowie Configuration Management. Für eine Begutachtung werden diese Kategorien auf den konkreten Systemzustand und die tatsächlichen technischen Mechanismen abgebildet.
Entscheidend ist daher die wirksame Autorisierung zum relevanten Zeitpunkt, nicht nur die vorgesehene Rollenbezeichnung.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Ist der technische Referenz- oder Sollzustand für das konkrete System festgelegt?
- Sind Identitätsquellen, Authentisierungsverfahren und privilegierte Konten vollständig erfasst?
- Sind direkte und indirekte Gruppen- oder Rollenvererbungen berücksichtigt?
- Sind Service Accounts, API-Schlüssel und technische Delegationen einbezogen?
- Ist nachvollziehbar, welche Rechte zum relevanten Zeitpunkt tatsächlich wirksam waren?
- Sind relevante Konfigurations- und Berechtigungsänderungen zeitlich rekonstruierbar?
- Sind Referenzmaßstab, technischer Befund und rechtliche Bewertung sauber getrennt?
Konstruiertes Beispiel
Ein Administrationsportal ist laut Konzept nur für eine Administratorgruppe erreichbar. Die effektive Cloud-Policy gewährt jedoch zusätzlich einem Service Account Schreibrechte. Der technische Befund besteht in dieser wirksamen Berechtigung und ihrem Scope. Ob sie organisatorisch zulässig war, erfordert zusätzliche Einordnung.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Amtliche technische Leitlinie NIST SP 800-53 Rev. 5 mit den Kontrollfamilien Access Control, Identification and Authentication, Configuration Management und Audit and Accountability. Quelle öffnen.
- Eigene Methodik Quellen und Methodik. Quelle öffnen.
- Amtliche technische Leitlinie BSI-Mindeststandard zur Protokollierung und Detektion mit Anforderungen an die Protokollierung von Benutzer-, Rechte- und Privilegienänderungen. Quelle öffnen.
Weiterführende Beiträge
- Schwachstellen technisch untersuchen
- Protokolldaten technisch auswerten
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich IT-Sicherheit
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
IT-Sicherheitsgutachten ansehen