Warum ein Namenskonzept das günstigste Sicherheitsprojekt ist, das Sie je beauftragen

Ein Namenskonzept klingt erst einmal nicht nach Security, sondern nach Tabellen, Abkürzungen und endlosen Diskussionen darüber, ob ein Server nun SRV, SV oder gar keinen Präfix bekommen soll. Das unterschätzt die Wirkung erheblich. Namen tauchen später überall auf – in Active Directory, in Gruppen und Berechtigungen, auf Servern und Service Accounts, in Zertifikaten, im Monitoring, im SIEM, in der Automatisierung, in der CMDB, in Tickets und in den Betriebshandbüchern selbst. Fehlt diesen Namen eine eindeutige Struktur, müssen Menschen ständig interpretieren, und Interpretation ist im IT-Betrieb eine der zuverlässigsten Fehlerquellen, die es gibt.

Ein Name sollte eine Frage beantworten

Nehmen wir eine Gruppe namens APP01. Was ist das – eine Anwendung, eine Administratorgruppe, eine Zugriffsgruppe, ein Server? Produktion oder Test, Lesen oder Ändern? Der Name liefert dazu schlicht keinen Kontext. Eine Gruppe, die nach einem konsistenten Schema benannt ist, lässt dagegen schon am Namen erkennen, um welche Objektklasse, welches System, welche Umgebung und welche Rolle oder Berechtigungsart es geht.

Das Ziel ist dabei nicht, sämtliche Information in einen vierundsechzig Zeichen langen Namen zu quetschen, sondern etwas viel Einfacheres: Gleichartige Objekte müssen gleichartig benannt sein.

Gute Namen machen Berechtigungen prüfbar

Stellen Sie sich zweitausend Active-Directory-Gruppen vor, ein Teil davon nach Anwendungen benannt, ein Teil nach Abteilungen, ein Teil nach Mitarbeitern, ein Teil nach Freigaben und ein Teil nach längst vergessenen Projekten. Niemand weiß mehr genau, ob FIN-Admin eine administrative Rolle ist oder lediglich der Änderungszugriff auf eine Anwendung, die zufällig FIN-Admin heißt. Bei fünf Gruppen ist das lästig. Bei mehreren Tausend ist es ein handfestes Sicherheitsproblem.

Ein konsistentes Schema macht dagegen gezielte Auswertungen überhaupt erst möglich – zeig mir alle privilegierten Gruppen, alle Gruppen für Produktion, alle Rollen einer bestimmten Anwendung, alle Service Accounts einer Plattform, oder alle Objekte, deren Namen nicht dem Standard entsprechen. Struktur wird damit maschinenlesbar, und maschinenlesbar bedeutet automatisierbar.

Automatisierung beginnt bei eindeutigen Regeln

PowerShell ist geduldig und verarbeitet zehntausend Objekte ohne mit der Wimper zu zucken. Was sie nicht kann, ist menschliche Intuition nachzubilden. Wenn ein Skript erkennen soll, welche Gruppen Tier-0 betreffen, zu welcher Anwendung sie gehören, ob sie nur Leserechte vermitteln oder aus welcher Umgebung sie stammen, dann müssen diese Eigenschaften entweder in sauber gepflegten Attributen stecken oder in einem konsistenten Namensmodell sichtbar sein. Ein Namenskonzept ersetzt keine Metadaten – aber es schafft eine zusätzliche, sofort sichtbare Ebene, und genau die zahlt sich spätestens bei der Betriebsautomatisierung aus.

Auch das Monitoring profitiert

Eine SIEM-Meldung wie „Mitglied wurde zu Gruppe GG_APP_PRD_SQL_ADMIN hinzugefügt" lässt schon ohne CMDB-Abfrage grob erkennen, dass diese Änderung vermutlich relevanter ist als „Mitglied wurde zu Gruppe Test123 hinzugefügt". Das ist kein Sicherheitskontrollmechanismus im eigentlichen Sinn, aber gute Benennung reduziert deutlich die Zeit, die jemand braucht, um ein Ereignis richtig einzuordnen – und gerade im Incident Response ist genau diese Zeit oft der entscheidende Faktor.

Ein Namenskonzept darf aber auch nicht zu viel verraten

Es gibt bei alldem auch eine Gegenrichtung, die ich in Projekten immer wieder ansprechen muss: Ein Name sollte nicht zum Architekturhandbuch für einen Angreifer werden. Unnötig detaillierte Informationen über die Sicherheitsklassifizierung, besonders kritische Systeme, interne Projektnamen oder organisatorische Sonderrollen gehören nicht in den Namen selbst. So viel Semantik wie nötig, nicht so viel wie irgend möglich – ein gutes Namenskonzept ist kein Wettbewerb um die längste Abkürzung.

Was ein gutes Namenskonzept festlegen muss

Mindestens geklärt sein sollten die Objektklassen – welche Regeln für Server, Clients, Benutzer, administrative Konten, Service Accounts, Gruppen, Cluster, Freigaben und DNS-Namen jeweils gelten –, die Pflichtbestandteile wie Umgebung, Funktion, Standort, Rolle und laufende Nummer, sowie die Schreibweise: Groß- und Kleinschreibung, erlaubte Sonderzeichen, Trennzeichen, Abkürzungen und Zahlenformate. Und schließlich der Lebenszyklus – was passiert bei einem Umzug, einem Rollenwechsel, einem Systemwechsel, einer Fusion oder einer Stilllegung?

Gerade dieser letzte Punkt wird gern übersehen. Wenn ein Servername einen Standort enthält und der Server fünf Jahre später in ein anderes Rechenzentrum wandert, ist der Name entweder falsch oder muss geändert werden – beides unschön. Deshalb sollte im Namen nur stehen, was tatsächlich stabil genug ist, um Jahre zu überdauern.

Namen sind Infrastruktur

Ein Namenskonzept ist im Vergleich zu den meisten technischen Sicherheitsmaßnahmen erstaunlich günstig zu haben: keine neue Appliance, keine zusätzliche Lizenz, kein Agent, keine komplexe Migrationstechnologie. Trotzdem wirkt diese eine Entscheidung über Jahre weiter, in der Dokumentation, im Betrieb, bei Berechtigungen, in der Automatisierung, im Monitoring, in der Fehlersuche, bei Audits und in jeder späteren Sicherheitsanalyse. Deshalb lohnt es sich, das Thema früh zu klären. Denn eines ist fast immer teurer als ein Namenskonzept – ein Namenskonzept nachträglich in eine bereits gewachsene Umgebung einzuführen.