Certificate Connector
Vergleich des Microsoft Certificate Connector für Intune / Active Directory Certificate Services (ADCS) und SCEPman hinsichtlich Bereitstellungs- und Betriebsaufwand.
Einrichtungsaufwand
< 30 Minuten
3-stufiges Bereitstellungsverfahren für Kernfunktionalität
> 2 - 3 Tage
CDP*-Design und Implementierung
Konfiguration von Zertifikatsvorlagen
Konfigurationskompatibilität – GPOs, Dienstkonten, Connector-Versionen, ...
> + 2 Tage
Zusätzlich zu PKCS:
Zusätzliche(r) Server für NDES
Ein NDES-Server für jeden Zertifikatstyp
Zwei zusätzliche Zertifikatsvorlagen
Schwer zu debuggen
PKI-Wartung
Überwachung des Certificate Connector
Zusätzlich zu PKCS:
Manuelle Erneuerung des Enrolment-Agent-Zertifikats
Serverwartung
Betriebssystem-Updates
Überwachung
Zusätzlich zu PKCS:
Betriebssystem-Updates und Überwachung für mindestens einen zusätzlichen Server
Zertifikatsverwaltung Ausstellung, Erneuerung, Widerruf
Vollautomatische Registrierung und Erneuerung
Option für manuellen Widerruf
Vollautomatische Registrierung und Erneuerung
Manueller Widerruf (Schwierigkeiten beim Durchsuchen der Datenbank)
Wie PKCS.
Verfügbarkeit
Einzelnes Design
App Service SLA: > 99,95 % Verfügbarkeit
Redundantes Design
Traffic Manager SLA: > 99,99 % Verfügbarkeit
Mehrere Ausfallmodi:
Virtualisierungsplattform
Betriebssystem
CDP-Webserver
Redundantes Design
Standby-CA-Server
Zusätzliche CDP-Webserver
Standby-Server für Backup des Certificate Connector
Wie PKCS.
Redundantes Design
Zusätzliche NDES-Server
Skalierbarkeit
Keine Autoskalierung
Skalierung erfordert CA-Cluster
Wie PKCS.
Weiterer Aufwand zur Vervielfältigung von NDES-Servern
Backup
SCEPman ist für die Kernfunktionalität zustandslos, d.h. kein Backup erforderlich.
SCEPman Root-CA wird implizit durch Azure Key Vault (region-redundant) gesichert.
Optionales Storage-Konto kann automatisch gesichert werden.
Regelmäßige CA-Datenbank-Backups
Backup des CA-Schlüssels und der Konfiguration (hohe Compliance- und Sicherheitsanforderungen)
Wie PKCS.
Sicherheit
Entworfen nach dem Zero-Trust-Ansatz (cloud-native)
Verwendung moderner Authentifizierungsverfahren
Automatischer Zertifikatwiderruf in Echtzeit mit OCSP (menschliche Fehler ausgeschlossen)
Für den Einsatz vor Ort konzipiert
Anfällig für "certifried-Angriff"
Erhöhte Angriffsfläche durch zusätzlichen Kommunikationskanal zwischen CA (Tier-0-Asset) und dem Internet
Erhöhte Angriffsfläche durch Nutzung von On-Premises- und Cloud-Konten
Aktualität der CRL hängt vom Aktualisierungsintervall ab
OCSP basiert auf CRL und nicht in Echtzeit
Wie PKCS.
Erfordert eingehenden Zugriff auf NDES (Tier-0-Asset)
Flexibilität
Verwendung standardisierter Schnittstellen (SCEP, OCSP, REST)
Unterstützung mehrerer MDM-Lösungen
Nur Intune wird unterstützt
Proprietäre RPC-Schnittstelle ermöglicht automatische Registrierung von Zertifikaten auf älteren domain-verbundenen Clients
Unterstützung mehrerer MDM-Lösungen möglich (zusätzliche NDES-Instanz erforderlich)
*: CRL Distribution Point
Zuletzt aktualisiert
War das hilfreich?