Microsoft Cloud PKI: Intune-Zertifikate einführen

Wir klären das Zugangsszenario, erstellen das Profilkonzept und begleiten einen begrenzten Pilot. Zum Ergebnis gehören Konfiguration, Prüfnachweise und betriebliche Zuständigkeiten. Der Umfang wird vor Beginn vereinbart; ein allgemeiner Umbau der gesamten Unternehmens-PKI gehört nicht automatisch dazu.

Maßgeblich sind Intune-Einschreibung und Unterstützung des passenden SCEP-Profils. Wir prüfen die tatsächlich eingesetzten Plattformen und Verwaltungsmodi, statt jede Geräteklasse pauschal einzuschließen. Die freigegebene Gerätematrix benennt auch Ausnahmen und noch ungeprüfte Kombinationen.

Hilfreich sind eine Geräteübersicht, bestehende Intune-Profile, das gewünschte WLAN- oder VPN-Szenario und Ansprechpartner für Identität und Netzwerk. Wir erfassen außerdem vorhandene CAs und bekannte Zugriffsprobleme. Fehlende Informationen werden als Voraussetzungen mit Verantwortlichen festgehalten.

Wir gleichen die vorgesehenen Nutzer und Geräte mit den aktuellen Lizenzbedingungen und dem vorhandenen Vertrag ab. Kosten werden getrennt von Implementierungs- und Betriebsaufwand ausgewiesen. Ein bestehender Intune-Vertrag wird nicht ohne Prüfung als ausreichende Berechtigung behandelt.

Zur Wahl stehen eine Cloud-Hierarchie und die Anbindung einer privaten CA über BYOCA. Wir bewerten vorhandene Vertrauensbeziehungen, Betriebskompetenz und Änderungsfolgen. Die Entscheidungsvorlage nennt die gewählte Variante und die Voraussetzungen der beteiligten Teams.

Das Konzept verbindet Vertrauens- und SCEP-Profile mit den vereinbarten Zielgruppen. Identitätsbezug und Zertifikatsanforderungen werden auf das Zugangsszenario abgestimmt. Wir prüfen Überschneidungen mit vorhandenen Profilen, bevor eine größere Gerätegruppe eine neue Zuweisung erhält.

Geräte müssen auch dem angesprochenen Authentifizierungsdienst vertrauen. Dessen TLS-Serverzertifikate werden nicht durch Microsoft Cloud PKI bereitgestellt. Im Projekt prüfen wir deshalb beide Richtungen der Vertrauensbeziehung und dokumentieren, welches Team die jeweilige Zertifikatskette verantwortet.

Nein. Der Zugangsdienst muss die nachgewiesene Identität einer zulässigen Berechtigung zuordnen. Wir testen deshalb auch negative Fälle, etwa eine nicht freigegebene Identität. Erfolgreiche Zertifikatsausstellung und erfolgreiche Autorisierung werden als getrennte Prüfergebnisse dokumentiert.

Wir wählen gemeinsam repräsentative Geräte und einen überschaubaren Zugangspfad. Erfolgskriterien werden vor der Konfiguration festgelegt. Der Pilot soll reale Abhängigkeiten zeigen, ohne eine vollständige Produktionsumstellung vorwegzunehmen. Ausnahmen und notwendige Folgeprüfungen bleiben sichtbar.

Wir prüfen den vorgesehenen Lebenszyklus anhand ausgewählter Geräte und dokumentieren, was bei Austausch oder erneuter Registrierung zu beachten ist. Neue Konfigurationen werden mit den vorhandenen Zugriffswegen abgestimmt. Ein einmaliger Anmeldetest ersetzt keinen Nachweis des späteren Betriebs.

Der Ablauf verbindet Meldung, Entscheidung, Zertifikatswiderruf und Maßnahmen am betroffenen Gerät oder Konto. Wir stimmen die Reihenfolge mit den zuständigen Teams ab. Ein veröffentlichter Widerruf allein wird nicht als Nachweis behandelt, dass jede bestehende Verbindung sofort beendet wurde.

Wir ordnen Fehler dem betroffenen Schritt zu: Zuweisung, Anforderung, Installation oder Anmeldung. Geräteinformationen und Protokolle des Zugangsdienstes werden über passende Zeitpunkte und Identitäten zusammengeführt. Die Betriebsanleitung benennt die benötigten Nachweise und die nächste zuständige Stelle.

Wir ordnen die verfügbaren Zertifikats- und Profilberichte konkreten Betriebsfragen zu. Dazu gehören ein benannter Prüfrhythmus und Eskalationswege. Berichtsstände werden mit ihrem Zeitbezug gelesen; ein Dashboard ersetzt weder einen realen Anmeldetest noch eine vollständige Sicherheitsüberwachung.

Microsoft Cloud PKI wird über Intune verwaltet. Ein gesondertes Azure-Key-Vault-Projekt erhält deshalb einen eigenen Anwendungsfall und Auftrag. In der Übergabe halten wir fest, welche administrativen Oberflächen für den vereinbarten Betrieb tatsächlich benötigt werden.

Diese Anwendungen sind nicht Teil des beschriebenen WLAN-/VPN-Pilots. Dafür wären eigene Anforderungen an Zertifikatstyp, Schlüsselverteilung, Anwendung und Wiederherstellung zu prüfen. Wir benennen solche Wünsche als separate Arbeitspakete, statt allgemeine PKI-Funktionen dem Projekt pauschal zuzurechnen.

Vor einer Ablösung erfassen wir die noch versorgten Anwendungen und deren Verantwortliche. Der Pilot ist kein Auftrag, eine bestehende CA abzuschalten. Die Entscheidung über Migration oder parallelen Betrieb folgt den nachgewiesenen Abhängigkeiten und einem abgestimmten Übergangsplan.

Er enthält Zielgruppen, Reihenfolge, Kommunikationsbedarf, Prüfungen und Abbruchkriterien. Nach jeder vereinbarten Stufe werden Ergebnisse bewertet. Offene Ausnahmen erhalten einen Verantwortlichen. Die Ausweitung basiert auf belegten Pilotergebnissen und wird nicht aus einer pauschalen Zeitersparnis abgeleitet.

Die Übergabe umfasst das freigegebene Profilkonzept, Zuweisungen, Prüfergebnisse und eine Anleitung für typische Supportfälle. Hinzu kommen Zuständigkeiten und bekannte Einschränkungen. Wir trennen eingerichtete Funktionen, tatsächlich geprüfte Abläufe und noch offene Maßnahmen.

Wir benennen einen Verantwortlichen für die Bewertung neuer Funktionen und Einschränkungen. Änderungen an Profilen oder Vertrauensbeziehungen werden mit gezielten Tests verbunden. Eine Roadmap ist eine überprüfbare Planung; sie ersetzt keine Bestätigung, dass eine angekündigte Funktion heute unterstützt wird.

Nein. Der Projektabschluss belegt nur den vereinbarten und geprüften Einführungsumfang. Eine Bewertung zukünftiger kryptografischer Verfahren benötigt eine separate Bestandsaufnahme der Abhängigkeiten, aktuelle Produktnachweise und Interoperabilitätstests. Daraus wird eine eigene Änderungsplanung abgeleitet.