• Startseite
  • Blog
  • Apples iOS-Geräte und die Planung des Lebenszyklus von Zertifikaten

Apples iOS-Geräte und die Planung des Lebenszyklus von Zertifikaten

iOS-Geräte wie iPads und iPhones werden schnell zu einem Teil der IT-Landschaft von Unternehmen, ein Trend, der manchmal als "Consumerization of IT" bezeichnet wird. Aus der Sicht eines Sicherheitsexperten gibt es hier eine Reihe von Faktoren, die Anlass zur Sorge geben, darunter die Aussicht auf nicht oder nur unzureichend verwaltete Geräte, die auf Unternehmensdaten zugreifen, die Vielfalt der Geräte und Formfaktoren und die rasche Verbreitung, um nur einige zu nennen.

Die Public Key Infrastructure (PKI) des Unternehmens und digitale Zertifikate können dabei helfen. iPhones und iPads sind von Haus aus in der Lage, digitale Zertifikate für die Authentifizierung gegenüber Unternehmensnetzwerken und -daten auf verschiedene Weise zu verwenden:

  • Drahtlose Unternehmensnetzwerke (802.1X und EAP-TLS)
  • VPN-Gateways über den integrierten Cisco-Client
  • Microsoft ActiveSync
  • Wechselseitig authentifizierte SSL Websites über den Safari-Browser

Jede dieser Möglichkeiten erlaubt es einer Organisation, den Zugriff auf die oben genannten Ressourcen zu beschränken auf NUR Geräte zuzulassen, die ein Zertifikat von der PKI des Unternehmens erhalten haben. In Kombination mit robusten Kontrollmechanismen für die Ausstellung von Zertifikaten und organisatorischen Richtlinieneinstellungen wie Passcodes und Remote-Wipe-Funktionen (z. B. über ActiveSync) kann dies eine gewisse Kontrolle über die Situation bringen, und zwar auf relativ skalierbare Weise. Darüber hinaus kann die Verwendung von Zertifikaten die Notwendigkeit verringern, dass jede iOS-Anwendung den Benutzernamen und das Kennwort des Benutzers erfasst und speichert, was ebenfalls eine gute Sache ist.

Wie bei jeder PKI-fähigen Anwendung erfordert eine ordnungsgemäße Implementierung eine sorgfältige Planung des Lebenszyklus der Zertifikate. Oft gibt es noch weitere Aspekte, aber die gesamte Zertifikatsplanung sollte Bereiche wie diese umfassen:

  • Ausstellung: Welche Benutzer und/oder Geräte benötigen Zertifikate, und wie werden sie ausgestellt?
  • Erneuerung: Alle Zertifikate laufen ab, in der Regel nach 1 bis 2 Jahren. Ein klar definiertes Verfahren für die Erneuerung kann später große Probleme verhindern. Bei der Planung sollte festgelegt werden, wer für die Identifizierung von Zertifikaten zuständig ist, die bald ablaufen, und welcher Prozess für die Erneuerung von ablaufenden Zertifikaten erforderlich ist.
  • Entzug: Wenn ein Gerät verloren geht oder der Verdacht besteht, dass der private Schlüssel eines Zertifikats kompromittiert wurde, sollten Zertifikate widerrufen werden, um zu verhindern, dass sie weiterhin als gültige Unternehmensnachweise gelten.
  • Ersetzen: Wenn ein Zertifikat versehentlich gelöscht wird oder anderweitig verloren geht, muss es entweder wiederhergestellt (im Falle von Verschlüsselungszertifikaten) oder vollständig ersetzt werden. Häufig können die Bemühungen hier die für die Ausstellung oder Erneuerung verwendeten nachahmen.

Für die Ausstellung von Zertifikaten für iPhones oder iPads gibt es zwei allgemeine Optionen:

  1. Erstellen Sie eine PKCS#12-Datei (.pfx), die das Zertifikat und den privaten Schlüssel enthält. Diese kann auf dem Gerät installiert werden, indem der Safari-Browser auf einen Webserver mit der Datei zeigt oder indem die .pfx-Datei in ein iOS-Profil aufgenommen wird.
  2. Konfigurieren Sie das Gerät für die Anmeldung für ein Zertifikat über SCEP (Simple Certificate Enrollment Protocol) in einem iOS-Profil (.mobileconfig-Datei). Microsoft-Zertifizierungsstellen unterstützen SCEP von Haus aus als zusätzliche Rolle auf den Betriebssystemen Windows Server 2008 und Server 2008 R2.

Es gibt jedoch einige Probleme mit beiden Ansätzen. CSS hält .pfx-Dateien von Natur aus für etwas gefährlich: Da es sich um Dateien handelt, sind sie recht mobil, und es kann schwierig sein, zu kontrollieren, wo sie hingehen. Außerdem sind sie anfällig für das Erraten von Offline-Kennwörtern, und sobald das Kennwort erraten wurde, ist der Schlüssel gefährdet. Und schließlich wird die "Nichtabstreitbarkeit" der PKI geschwächt: Da der Schlüssel zentral erstellt wird, ist es schwierig, mit 100%iger Sicherheit zu bestätigen, dass nur dass nur der Inhaber des Zertifikats Zugang zum privaten Schlüssel hatte.

SCEP-basiertes Enrollment ist aus Sicherheitsgründen definitiv die bessere Option, da der private Schlüssel auf dem Gerät generiert wird und nicht exportiert werden kann. Das Hauptproblem hier ist ein Größenproblem: Das iOS-Profil platziert Zertifikatsinhalte wie den Subject (Distinguished Name), und das SCEP-Einmal-"Challenge"-Passwort in die Konfigurationsinformationen. Die .mobileconfig-Profile können also nicht von mehreren Geräten gemeinsam genutzt werden - jedes Gerät benötigt sein eigenes. Es ist möglich, die Einstellungen für das Challenge-Passwort so zu ändern, dass die Challenges wiederverwendet werden können, aber es sollte beachtet werden, dass dies eine schreckliche Idee ist - so wie SCEP funktioniert, sind Active Directory-Anmeldeinformationen nicht involviert, so dass die Challenge wirklich der einzige Faktor, der zur Authentifizierung der Zertifikatsanforderung verwendet wird.

Schließlich werden die Zertifikate unabhängig von der Ausstellungsmethode ablaufen, und iOS tut derzeit nichts, um dies automatisch zu handhaben. Wie oben erwähnt, muss also eine Art Prozess eingerichtet werden, um den bevorstehenden Ablauf von Zertifikaten zu handhaben.

Ab morgen verfügbar: Verwendung des CSS Certificate Reporting Tools zur Verwaltung von Zertifikaten für iPads und iPhones.

Mehr erfahren>>>