Unternehmen verwenden Mobile Device Management (MDM) Produkte um mobile Geräte wie Smartphones, Tablet-Computer oder Desktopsysteme über das Internet (Over-the-Air, OTA) zu verwalten, zu konfigurieren und zu aktualisieren.
Gängige Mobile Device Management Produkte sind:
- Microsoft Intune
- VMware Workspace One (zuvor bekannt unter dem Markennamen AirWatch)
- Ivanti MobileIron UEM
- Jamf Pro
- Baramundi Enterprise Mobility Management
- BlackBerry Enterprise Mobility Suite
- Sophos Mobile Control
- SOTI MobiControl
TameMyCerts ist ein Policy Modul, um die Microsoft Zertifizierungsstelle (Active Directory Certificate Services) abzusichern. Es erweitert die Funktionen der Zertifizierungsstelle und ermöglicht die erweitere Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikatausstellungen zu ermöglichen. TameMyCerts ist einzigartig im Microsoft-Ökosystem und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden.
TameMyCerts ist Open Source und kann kostenfrei verwendet werden. Für den Einsatz im Unternehmensbereich empfiehlt sich jedoch der Abschluss eines Wartungsvertrags. Dies stellt sicher, dass Sie qualifizierte Unterstützung erhalten und dass das Modul langfristig in hoher Qualität weiterentwickelt werden kann.
Funktionsweise
All diese Systeme verwenden in Verbindung mit einer Microsoft-Zertifizierungsstelle ein vergleichbares Konzept: Sie agieren als Mittelsmann zwischen dem verwalteten Gerät, dem Verzeichnisdienst des Unternehmens und der Zertifizierungsstelle. In PKI-Begriffen gedacht führen sie die Rolle der Registrierungsstelle (engl. Registration Authority, RA) aus. Alle verwenden sie eine Art Connector, um Zertifikatanträge an die Microsoft AD CS Zertifizierungsstelle zu übertragen.
Alle gängigen MDM-Systeme erfordern daher, dass die konfigurierte Zertifikatvorlage als Offline-Zertifikatvorlage eingerichtet wird, d.h. dass die im Zertifikat enthaltene und durch die Zertifizierungsstelle bestätigte Identität vom Antragsteller, also dem MDM-System vorgegeben wird ("Enrollee supplies Subject").
Die Zertifizierungsstelle hat somit keinerlei Kenntnis über den beantragten Zertifikatinhalt, sie stellt die Zertifikatanforderungen blind aus und muss dem MDM-System hierbei vollständig vertrauen.
Fehlausstellungen durch das MDM-System sind nicht unüblich
Es ist nun leider nicht unüblich, dass es zu Fehlausstellungen durch das MDM-System oder mit dessen Berechtigungen kommt. Mögliche Gründe können sein:
- Fehlkonfiguration des MDM-Systems.
- Fehlverhalten des MDM-Systems. Beispielsweise kann es vorkommen, dass Zertifikate für Geräte beantragt werden, die keinem existierenden Benutzer mehr zugeordnet sind. In diesem Fall kann es zur Beantragung von Zertifikaten mit leeren Identitäten kommen.
- Kompromittierung des verwendeten Dienstkontos und Ausnutzen von dessen Beantragungs-Berechtigungen (siehe ESC1-Angriff).
Somit sind Sicherheits- und Datenschutzvorfällen Tür und Tor geöffnet.
Die üblichen Installationen von MDM-Systemen in Verbindung mit den Microsoft Active Directory Certificate Services sind somit anfällig für das Schweizer-Käse-Modell, in welchem kleine Lücken, die sich durch die Kette aller beteiligten Systeme ziehen, zu großem Schaden führen können.
Konkretes Beispiel: Einem verwalteten Gerät ist kein gültiger Benutzer zugeordnet
In der Praxis kommt es mit MDM-Systemen immer wieder einmal vor, dass einem verwalteten Endgerät kein gültiges Benutzerkonto zugewiesen ist.
In einem einfachen Fall wäre beispielsweise konfiguriert, dass der Subject Distinguished Name (DN) eines Zertifikats einen commonName mit der Variable des Benutzernamens beinhaltet.
CN={EnrollmentUser}
In diesem Beispiel wird die Syntax von VMware Workspace One verwendet, alle gängigen MDM-Systeme funktionieren jedoch auf vergleichbare Weise.
Ist diese Variable nun leer, weil dem Endgerät kein gültiges Benutzerkonto zugewiesen ist, wird unter Umständen ein Zertifikatantrag mit einem leeren Subject Distinguished Name (DN) erzeugt. Hier verhalten sich MDM-Systeme offenbar unterschiedlich:
- Baramundi Enterprise Mobility Management erzeugt in diesem Fall eine leere Sequenz und die Zertifizierungsstelle wird den Zertifikatantrag mit der Fehlermeldung "Error Parsing Request The request subject name is invalid or too long. 0x80094001 (-2146877439 CERTSRV_E_BAD_REQUESTSUBJECT)" ablehnen.
- VMware Workspace One wird einen Zertifikatantrag mit einem Subject Distinguished Name (DN) erzeugen, welcher einen leeren commonName beinhaltet. Ein solcher Zertifikatantrag wird durch die Zertifizierungsstelle ausgestellt. Das resultierende Zertifikat wird jedoch keine Identität beinhalten.
Hat man nun noch das Pech, dass die Anwendung, welche das Zertifikat bei der Anmeldung überprüft (z.B. ein Single Sign-On (SSO) System) mit einem solchen Fall nicht adäquat umgehen kann, kann es vorkommen, dass mit einem solchen Zertifikat bei der Anmeldung die Identität eines anderen, gültigen Benutzers zugewiesen wird. Fertig ist der Datenschutz- und Sicherheitsvorfall.
Die Lösung: TameMyCerts
Das TameMyCerts Policy Modul für die Microsoft Active Directory Certificate Services kann de Lücke auf Ebene der Zertifizierungsstelle schließen, indem Zertifikatanträge durch die Erzwingung eines feingranularen Regelwerks kontrolliert werden können.
Zu den Möglichkeiten gehört unter Anderem:
- Erzwingen von Syntaxregeln für den beantragten Subject Distinguished Name und Subject Alternative Name.
- Herstellen einer Verbindung zwischen der beantragten Identität im Zertifikat und dem dazugehörigen Objekt im Active Directory. Anwenden von Regeln gegen das zugehörige Objekt, z.B. anhand des Status (Aktiv oder Deaktiviert), Mitgliedschaft in Gruppen oder Organisationseinheiten und weiterer Kriterien.
- Modifizieren des beantragten Zertifikatinhalts vor der Ausstellung des Zertifikats. Übertragen oder Entfernen von Zertifikat-Feldern, Hinzufügen von statischen Werten oder von Werten aus dem zugehörigen Active Directory Objekt.
Zertifikatanforderungen, welche gegen die definierten Regeln verstoßen werden abgelehnt und der Vorfall protokolliert. Somit kann auch eine Alarmierung eingerichtet werden, um potentiellen Sicherheitsvorfällen nachgehen zu können.
Microsoft Intune nutzt den Network Device Enrollment Service (NDES) als Connector zwischen Intune und der Zertifizierungsstelle. NDES, wie auch die Zertifizierungsstelle selbst, können mit Policy-Modulen erweitert werden. Microsoft stellt für Intune ein Policy Modul für NDES zur Verfügung, somit kann kein weiteres Policy Modul an eine NDES-Instanz, welche für Intune konfiguriert wurde, hinzugefügt werden. Da TameMyCerts jedoch auf Ebene der Zertifizierungsstelle operiert und auf dieser installiert wird, kann man die Vorteile beider Module problemlos miteinander kombinieren.
Weiterführende Links:
- Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für Microsoft Active Directory Certificate Services
- Grundlagen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)
Deutsch 
English