MFA und Dienstkonten

Allein die Anmeldung an einem Dienst mit einem Benutzernamen und passenden Kennwort wird in vielen Fällen als zu unsicher angesehen. Wenn diese Kombination erraten oder veruntreut wird, dann kann eine andere Person oder Programm sich mit den Rechten Zugang zu Daten und Einstellungen verschaffen. Das ist bei Menschen sehr kritisch, die mit sensiblen Daten arbeiten und ihr Kennwort immer wieder eingeben. Keylogger und Kameras haben ein leichtes Spiel die Zugangsdaten damit zu erhalten.

Ich rate vom Einsatz von "Dienstkonten" in Microsoft 365/EntraID ab und nutze soweit möglich entsprechende App-Registration.

Der weitere Faktor

Für Anwender ist es daher sinnvoll deren Anmeldungen zu überwachen und ggfls. eine Rückfrage zu starten, wenn der ungewöhnlicher Zugriff erfolgt. Für diese Entscheidung gibt es mehrere Kriterien, um nur einige zu nennen:

  • Zeitpunkt
    Ein Mensch hat normaler weise "Arbeitszeiten", in denen er aktiv ist. Wobei das bei ActiveSync schon wieder eingeschränkt werden muss
  • Ort
    Aber Menschen können aktuell mit dem Flugzeug am schnellsten den Ort wechseln. Eine Anmeldung an vielen Ecken der Welt, die über IP-Adressen schon gut lokalisiert werden können, ist zumindest verdächtigt. Wobei auch Gäste-LANs, VPNs, Tor u.a. Dienste hier die Erkennung erschweren. Wer sich aber mit dem Firmen PC im LAN befindet, wird ja wohl kaum von extern per Terminal Dienste, VPN oder Browser auf Dienste zugreifen.
  • Häufigkeit
    Auch bei der zeitlichen Abfolge von Anmeldungen können Ungereimtheiten auffallen. Der normale Office-Worker meldet sich einmal an und bekommt sein Ticket, welches einige Zeit gültig ist.

Kreditkartefirmen nutzen übrigens ähnliche Funktionen um Missbrauch zu erkennen. Wer also heute in Deutschland an einer Tankstelle die Karte "durchzieht", kann kaum ein paar Minuten später in einem fernen Land eine Zahlung ausführen. Wobei auch hier das Internet mit den Bestellmöglichkeiten neue Herausforderungen stellt.

Besonderheit Dienstkonten

Wann immer es Ungereimtheiten gibt, kann ein Dienst einen Anwender zu einer weiteren Authentifizierung auffordern. Der Service sollte das natürlich vom User-Agent abhängig machen. Wenn der Client ein Browser ist, dann kann der Anwender den Hinweis auch lesen und die Rückfrage beantworten. Andere Zugriffe könnten z.B.: durch ein Token, SMS, Telefonanruf abgesichert werden.

Wenn es sich aber z.B.: um ein Mobilgerät oder einen automatischen Prozess handelt, dann gibt es meist weder die GUI zum Anzeigen noch den Anwender zum anschauen einer Warnung oder Rückfrage. Der Service muss bei unklarer Berechtigung den Zugriff blockieren.

Genau das ist aber natürlich problematisch für Dienste, die ohne Interaktion im Hintergrund arbeiten. Dazu zählt z.B. der AADConnect-Service, der Benutzer aus dem lokalen Active Directory mit den Identitäten in der Cloud abgleicht. Viele Firmen haben aber auch weitere Prozesse, die regelmäßig sich an Diensten anmelden um Aktionen auszuführen. Was mir so einfällt.

  • Provisioning von Office 365
    z.B.: damit Benutzer in der Cloud bestimmte zusätzliche Einstellungen erhalten, die nicht On-Premises eingetragen werden können (Exchange POP3/IMAP4, ActiveSync Quarantäne, Lizenzvergabe
  • Reporting
    Andere Skripte lesen Daten von einem Service z.B.: für Abrechnungszwecke o.ä. aus
  • Test-Aufgaben
    Um die Erreichbarkeit, Funktion und Performance eines Dienstes zu prüfen, sind ebenfalls synthetische Transaktionen erforderlich, die natürlich eine Anmeldung erfordern

Das sind nur ein paar Beispiele für automatisierte Zugriffe auf Dienste, die bei der Form der Anmeldung mit berücksichtig werden müssen.

Lösung für Dienste

Berücksichtigung bedeutet, dass abgestimmt auf den Service, den Client und die Sicherheitsbelange eine passende Konfiguration gefunden werden muss. So eine Entscheidung ist in der Regel auch keine generelle Lösung sondern pro Fall individuell. Folgende Optionen fallen mir ein:

  • MFA-Tauglichkeit
    Die einfachste Lösung für den Betreiber der Plattform ist natürlich, wenn der Client MFA unterstützt. Wenn es dabei aber um die Eingabe von Einmal-Tokens, die Lösung von Capthas oder zusätzliche "Geheimfragen" o.ä. geht, dann werden Sie bei automatisierten Prozessen hier nicht weiter kommen. Diese MFA-Optionen sind doch auf Menschen ausgelegt, deren Zugang abhängig von Clients, Ort und Applikation gesichert werden muss
  • Alternative MFA-Vorgaben
    Für automatisierte Aufgaben können Sie aber in der Regel andere Kriterien als zusätzlichen Schutz einsetzen. Die drei im vorigen Kapitel genannten Dienste sind in der Reegel sowohl hinsichtlich des Standorts als auch des ausführenden Systems statisch. In Office 365 können Sie über Conditional Access konfigurieren, dass bestimmte Konten auf bestimmte Dienste von bekannten IP-Adressen zugreifen können. Damit ist die IP-Adresse, mit der sich der Client am Dienst meldet, der weitere Faktor. Wenn ein Angreifer die Zugangsdaten also erlangt hat, kann er diese dennoch nicht von einem anderen fremden System nutzen. Allerdings wäre der interne Missbrauch möglich, wenn andere Clients z.B. den gleichen Proxy nutzen.
    Eine andere Option wäre die Qualifizierung des Endgeräts z.B. anhand eines Computer oder Benutzer-Zertifikats, welches beim Verbindungsaufbau mit verwendet werden muss. Ein sicher, z.B. als Smartcard, abgelegtes Zertifikat ist kaum zu duplizieren. Allerdings muss der Service dann eine Anmeldung per Zertifikat auch erfordern.
  • App-Kennworte
    Schon immer gibt es z.B.: bei Office 365 die Funktion, ein "App Password" zu erhalten. Bestimmte Clients können einfach keine MFA-Anmeldung und man möchte verhindern, dass auf diesen Prozessen natürlich das allgemeine Kennwort hinterlegt wird. Für den Benutzer können daher weitere komplexe und lange Kennworte angelegt werden, die dann in der Applikation hinterlegt werden können. Automatische Prozesse (u.a. auch ActiveSync) konnten so weiter arbeiten, selbst wenn der Anwender sein Hauptkennwort ändert. Diese Applikationskennworte sind aber nicht dazu geeignet sich dann interaktiv anzumelden.
  • Service-Rechte
    Eine besondere Form der App-Kennworte stellen "App" in der Cloud da, die Sie als Benutzer oder Admin berechtigen. Hier verwalten nicht sie als Anwender ein Kennwort, welches sie an den Service geben sondern der Service hat einen "Secret" und eine Client-ID, mit der er dann quasi "in ihrem Auftrag" auf ihre Daten zugreift. Sie als Besitzer der Daten erlauben also einer Applikation den Zugriff, die sich dazu natürlich ausweisen muss. Das ist in etwas so wie eine App auf dem Smartphone, der sie bestimmte Rechte einräumen. Damit erlauben Sie in der Regel auch aktualisierten Applikationen diese Zugriffe
  • Absolute Ausnahme von MFA
    Wenn all dies nicht geht, weil der Services keine weitere Differenzierung erlaubt oder ihre Client-Software keine App-Kennworte oder andere Verfahrung unterstützt, dann bleibt nur die "Ausnahme", dass diese Zugangsdaten keinen strengeren MFA-Vorgaben unterworfen werden. Das klingt schlimmer als es ist, denn letztlich hängt es nur am Dienstkonto und dem Kennwort, welches natürlich zu schützen ist. Auch wenn das nie zu 100% möglich ist, so kann der Schutz allein durch organisatorische Maßnahmen schon sehr hoch angesetzt werden. Zudem können die meisten Services zumindest eine Überwachung der Anmeldungen durchführen und zumindest melden.

Wer Dienstkonten nutzt, die nicht einmal auf Computer oder IP-Adresse beschränkt sind, sollte für jeden Dienst zumindest eigene Konten verwalten, so dass der Schaden überschaubar bleibt. Auf jeden Fall ist es keine gute Idee mit einem "Super Dienstkonto", welches noch Domänen Administrator ist, sehr viele Dienste an unterschiedlichen Orten laufen zu lassen. Viele Dienste und Programme können relativ einfach auf "Local System" oder "Network System" reduziert werden. Sie müssen nur die erforderlichen Berechtigungen ermitteln und vergeben.

Wichtig!
Vergessen Sie dabei aber nicht zu dokumentieren, welches Dienstkonto wo hinterlegt ist, damit Sie das Kennwort dennoch schnell ändern können.

Es klingt wie Allgemeinwissen. Praktisch ist es das wohl auch aber in der Realität wird genau das nicht umgesetzt.

Location oder Device als Schlüssel

MFA ist wichtig, wenn die Anwender von verschiedenen Geräten aus uznbekannten Orten auf Dienste zugreifen wollen. DAs ist eine ganz neue Herausforderung die früher püer VPN gelöst wurde. In der Cloud liegen die Daten aber nicht mehr im internen Netzwerk. In der Vergangenheit war es aber absolut in Ordnung, wenn Anwender auf einem Firmencomputer im internen Netzwerk unterwegs waren. HIer haben die wenigsten Firmen über MFA nachgedacht.

Nur weil die Daten aber nun in der Cloud sind, sollte die Anwender nicht über GEbühr gegängelt werden. Was spricht eigentlich dagegen, dass Anwender aus "vertrauenswürdigen Netzwerken" einfach so auf Office 365 und andere Dienste zugreifen?. Ab dem Moment kommt der Begriff "Conditional Access" in den Blickpunkt. Die Anforderungen an die zusätzliche Absicherung per MFA wird von Faktoren abhängig gemacht. Für ein Dienstkonto ist das natürlich auch gültig und ein Services ist in der Regel Standortgebunden. Teilweise läuft er auch auf bekannten Computern. Wie wäre es da, wenn Sie den Zugriff auf OFfice 365 für dieses DIenstkonto auf eben diesen Client oder zumindest Standort beschränken?

Über die Verwaltung in Azure können Sie "Locations" definieren und diese dann in den Regel verwenden. So kann der Zugriff über ausgewählte Benutzer oder Gruppen auf zu definierende Dienste und Programme und den Client mit entsprechenden Faktoren erzwungen werden. In den meisten Fällen sollte das ein hinreichend "sicherer" Faktor sein, um den Zugriff für dieses Konto zu reglementieren. Ansonsten stelle ich einfach mal die Frage, wie sie denn den Computer besonders geschützt haben, auf dem mit dem Dienstkonto der entsprechende Code ausgeführt wird.

Weitere Links