Das Ding mit dem Passwort

von

Eigentlich wollte ich diesen Blog-Artikel schon seit einer Weile fertig gehabt haben. Aber wie das so ist, kommt manches eben anders. So kam es, dass mir z.B. Solarwinds mit ihrem Passwortleak[1] dazwischen gekommen ist. Kurz zusammengefasst kann man wohl sagen, dass hier eine Kombination aus einem schwachen Passwort (solarwinds123) und dessen Veröffentlichung auf GitHub die Firma Solarwinds in arge Schwierigkeiten bringt.

Aber wie gesagt, der Sinn des Beitrags sollte nicht das Solarwinds-Thema sein, sondern soll um Passwörter und den Umgang mit diesen gehen.

Passwort-Arten

Es gibt aus meiner Sicht verschiedene Arten von Passwörtern oder besser gesagt verschiedene Arten derer Verwendung. Diese fasse ich wie folgt zusammen:

  1. Persönliche Arbeitsaccounts, deren Kennwörter die häufig eingegeben werden, z.B. zur Anmeldung am PC.
  2. Privilegierte Benutzerkonten, z.B. Admin-Accounts
  3. Utility Accounts, z.B. Durchführen von geplanten Aufgaben
  4. Service Accounts, z.B. für das Starten von Serverdiensten
  5. Authentifizierungstoken, z.B. für das „kennwortgeschützte“ Abrufen von Updates

Persönliche Arbeitsaccounts

Ich glaube so ziemlich jeder kennt es. Der Account, mit dem täglich gearbeitet wird ist praktisch ständig im Beschlag. Wird der Arbeitsplatz kurz verlassen, so soll aus Sicherheitsgründen der PC gesperrt werden. Spätestens jedoch zu Arbeitsbeginn wird meistens das Kennwort eingegeben. Obendrein soll das Kennwort auch gerne mal alle 90 Tage – oder früher – geändert werden und freilich dürfen die letzten > 10 Passwörter nicht wiederverwendet werden.
Wozu führt das? Aus meiner Sicht und Erfahrung führt das dazu, dass sich die Mitarbeiter Saisonkennwörter zulegen. Also beispielsweise Sommer-2020, Herbst-2020 oder Solarwinds123 (scnr). Diese Kennwörter sind zwar nach den üblichen Kriterien „komplex“, weil sie Groß- und Kleinbuchstaben sowie Zahlen und Sonderzeichen verwenden. Aber so richtig sicher sind sie nicht.
Das zeigt, dass die Kombination häufiges Wechseln und häufige Eingabe eher zu einer Verringerung der Sicherheit führt als andersrum.

Um Saisonkennwörter zu reduzieren kann Windows Hello, also biometrische Merkmale, PIN oder Sicherheitsschlüssel „anstelle“ des Kennworts verwendet werden. Insbesondere PIN und Sicherheitsschlüssel halte ich gute Mittel. Aber das bedient erstmal nur die bequeme Anmeldung und löst die eigentlich Situation nicht. Nicht umsonst haben BSI[2] und NIST[3] die entsprechenden Passagen zum regelmäßigen Kennwortwechsel für diese Account-Art aus ihren Richtlinien entfernt. Viel besser wäre es Mitarbeitern(innen), Freunden(innen), etc. zu verdeutlichen warum ein starkes Passwort wichtig ist und am besten so komplex ist, dass es in einem Kennworttresor aufgehoben wird.
Um den Schutz des Benutzerkontos wieder zu erhöhen, sollte dann noch eine Multi-Faktor-Lösung (Multi-Faktor-Authentication, kurz MFA) implementiert werden. Diese kann z.B. dann auslösen, wenn ein Anmeldeversuch nicht von einem bekannten Gerät kommt, das auch einen gesunden („Healthy“) Status erhält – in Azure AD Premium ist so eine Funktion beispielsweise enthalten.

Privilegierte Benutzerkonten

Diese Art der Benutzerkonten sollten die Anforderung haben lange und komplexe Kennworte zu verwenden. Außerdem sollten noch zusätzlich die Schutzmaßnahmen wie MFA angewendet werden. Des Weiteren sind hier die Ansätze zu Just-in-Time und Just-Enough-Permissions, also Privilegien (Berechtigungen, Rollen) nur für den benötigten Zeitraum und in benötigter Menge zu erhalten. Auch hier bietet Azure AD Premium (P2) Lösungen für Microsofteigenen Produkte an.

Utility und Service Accounts

… oder Accounts ohne interaktive Anmeldung sollten stets sehr lange und sehr komplexe Kennworte verwenden. Außerdem sollte die Anmeldung strikt auf die notwendigen Systeme eingegrenzt werden. Wird dann auch noch zuverlässig die Verwendung der Anmeldung überwacht, so kann sicherlich die Häufigkeit der Kennwortwechsel reduziert werden. Das verringert dann auch die betrieblichen Aufwände ohne das Risiko eine Kompromittierung wirklich zu erhöhen.
Microsoft Active Directory bietet mit den (Group) Managed Service Accounts[4] auch eine eigene Type von Benutzerkonten, deren Kennwortwechsel das Active Directory zusammen mit dem dazugehörigen Server(n) übernimmt.

Authentifizierungstoken

Bei Token ist die Lage nun tatsächlich etwas anders. Tokens sollten nur eine möglichst kurze Lebensdauer haben. Frei nach dem Grundsatz: [Lebensdauer] lange genug um die Aufgabe zu erfüllen, aber so kurz wie möglich und im Bedarfsfall die Lebensdauer verlängern oder ein neues Token anfordern.

  1. https://www.businessinsider.com/solarwinds-warned-weak-123-password-could-expose-firm-report-2020-12
  2. https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/bausteine/ORP/ORP_4_Identit%C3%A4ts-_und_Berechtigungsmanagement.html?nn=10137172#doc10095784bodyText12
  3. https://pages.nist.gov/800-63-3/sp800-63b.html
  4. https://docs.microsoft.com/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview