Identity Protection: Das “Neue” Security Boundary

In der letzten Dekade war die IT Welt verhältnismässig einfach gegliedert: Die interne und externe IT wurden klar voneinander getrennt. Intern liefen unseren geschützten LANs und WANs, welche mit zusätzlichen Funktionen, wie zum Beispiel Network Access Control abgesichert wurden. Extern tummelten sich die User im grossen, bösen Internet, welches immerzu Angriffe gegen die DMZ auslöste. Dazwischen regelte eine oder je nach dem mehrere DMZ den Datenverkehr zwischen interner und externer IT. Entsprechende Gebäudesicherheit sorgte dafür, dass Geräte und Netzwerkverbindungen nur von berechtigten Personen verwendet werden konnten.

Mit dem Einsatz von Outlook Web Access oder Exchange Active Sync wurde aber schon damals das Security Boundary aus der Firma herausgetragen. Damit wurden auch Smartphones zu Systemen, welche geschützt werden mussten. Smartphones, oft im Besitz von Angestellten, verunmöglichen eine strikte Einschränkung der Geräte häufig. Trotzdem muss die IT sicherstellen, dass die konsumierten Daten auf diesen Geräten vor fremden Zugriff geschützt sind.

Mit verschiedenen Methoden wird seither versucht, die Geräte entsprechend abzusichern und den Zugriff für Aussenstehende zu unterbinden. Ausserdem werden immer mehr Dienste im Internet publiziert, ob On-Premises oder in der Cloud zur Verfügung gestellt, spielt für diesen Fall eine untergeordnete Rolle. Was aber oft vergessen geht, ist der Schutz des zugreifenden Accounts, womit wir beim Thema Identity Protection sind. Was nützen bestens abgesicherte Geräte, wenn ein Angreifer ein Gerät, wie beispielsweise ein Smartphone, mittels Username und Passwort in Betrieb nehmen kann?

Das Problem wird umso deutlicher, wenn Azure AD genutzt wird. Dabei wird eine Verbindung des User mit seinem Windows 10 Gerät von ausserhalb der gesicherten Perimeter hergestellt und ermöglicht. Auch wenn heute ausschliesslich mit interner AD und Group Policies gearbeitet wird, die Verwendung von Azure AD in einer Standardkonfiguration, welche als Basis für Exchange Online oder SharePont Online benötigt wird, ermöglicht ein solches hinzufügen von Geräten durch einen User. Azure AD hinzugefügte Geräte (so genanntes «Azure AD Device Join») erhalten einen sehr vertrauenswürdigen Status gegenüber dem Azure AD und den angehängten Diensten wie Exchange Online oder SharePoint Online.

Also gilt es, den Benutzeraccount so sinnvoll wie möglich zu schützen, ohne den Benutzer in seiner täglichen Arbeit zu stark einzuschränken. Ausserdem ist es notwendig, Accounts zu identifizieren, welche keinen zusätzlichen Schutz ermöglichen. Als Beispiel sind spezifische Service Accounts genannt. Eine Möglichkeit für einen zusätzlichen Schutz ist der Einsatz einer Multi-Faktor-Authentisierung (MFA) Lösung. Diese ist beim Azure AD ab P1 Lizensierung inkludiert. Sowohl beim Einsatz wie auch beim Ausrollen einer MFA-Lösung können zusätzliche Einstellungen die Sicherheit entscheidend erhöhen. Beispielsweise dann, wenn ein Benutzer sein MFA nur innerhalb eines gesicherten Perimeters ausrollen kann. Dieses Einstellungsbeispiel zeigt aber auch, dass eine so erhöhte Sicherheit beim Endanwender auf Unverständnis stossen kann. Gerade deshalb muss ein solcher Einsatz gut abgewogen werden.

Ein weiterer Punkt, welcher innerhalb der Identity Protection beleuchtet werden muss, ist die Möglichkeit von Gästen im Azure AD. Falls ein Angreifer von einem Benutzer eingeladen wird, kann dieser sich in einem Chat und mit entsprechender Vorbereitung als eine andere Person ausgeben. Allgemein sollten solchen Phishingmöglichkeiten in allen möglichen Bereichen begegnet werden, so zum Beispiel auch bei der Exchange Online Anti-Phishing Lösung.

Ausserdem sollten Neuerungen verfolgt und implementiert werden. Alte Verfahren, welche nicht mehr verwendet und als Angriffsvektor missbraucht werden können, sollten deaktiviert werden. Als Beispiel für eine solche neue Funktion stellen die FIDO2 kompatible Geräte dar, welche ein Anmelden ohne passwort ermöglichen. Oder, auf der anderen Seite des Anwendungsbereichs sollte die «legacy Authentication» in Exchange Online deaktiviert werden, um damit Password Spray Attacken vorzubeugen.

Martin Wüthrich

Related posts
Antwort hinterlassen