Sicherheit & Datenschutz

Dieses Kapitel bietet einen Überblick über häufig gestellte Fragen zu Informationssicherheit, Datenschutz und Qualitätssicherung.

Datenverarbeitung und Berechtigungen

1. Welche Daten verarbeitet SCEPman?

SCEPman verarbeitet X.509-Zertifikate mithilfe der Protokolle SCEP und EST für die Ausstellung sowie OCSP- und CRL-Protokolle zur Validierung dieser Zertifikate. Jedes Gerätezertifikat muss einen eindeutigen Gerätebezeichner enthalten. Zusätzlich empfehlen wir für Benutzerzertifikate, die folgenden Werte als Teil des Zertifikats zu konfigurieren:

• Benutzername

• E-Mail

• Microsoft Entra ID (Azure AD) UPN

• Gerätekennzeichen

SCEP, EST, OCSP und CRL basieren auf HTTP(S), d.h. die folgenden Daten sind für SCEPman sichtbar:

• Client-IP-Adresse + Port

• User-Agent (Betriebssystem- & Browserinformationen)

Certificate Master führt eine Prüfprotokollierung über Administratoraktivitäten (UPNs).

2. Welche Daten werden von/zugunsten von SCEPman dauerhaft gespeichert und wie?

1. Konfiguration

   • Konfigurationsdaten enthalten immer das SCEPman-CA-Paar aus öffentlichem/privatem Schlüssel und Zertifikat, welches sicher im Azure Key Vault gespeichert wird.

   • Zusätzlich können Konfigurationsdaten Geheimnisse wie statische SCEP-Challenges oder Passwörter enthalten. Der Zweck dieser Parameter wird in der SCEPman-Dokumentation erklärt.

   • Alle Konfigurationsparameter können zur erhöhten Sicherheit im Azure Key Vault gespeichert werden.

2. Ausgestellte Zertifikate

   • Alle ausgestellten Zertifikate werden in einem Azure Storage Account gespeichert - ohne private Schlüssel.

   • Für die Daten, die Teil eines Zertifikats sein könnten, verweisen wir auf Frage 1.

   • Dieses Verhalten kann deaktiviert.

   • Bei Ausstellung von Zertifikaten über Certificate Master wird der Anforderer (Microsoft Entra ID (Azure AD) UPN) gespeichert.

   • Beim Widerruf von Zertifikaten über Certificate Master werden der Widerrufsstatus des Zertifikats und die Identität des Benutzers, der den Widerruf vorgenommen hat (Microsoft Entra ID (Azure AD) UPN), gespeichert.

3. Protokollierung

   Abhängig von der Konfiguration des Kunden für SCEPman kann die Protokollierung aktiviert werden. Je nach Detaillierungsgrad der Protokollierungseinstellungen des Kunden können die Protokolle alle Daten enthalten, die SCEPman verarbeitet. Der Kunde konfiguriert den Speicherort der Protokolle.

4. Externes Log Analytics Workspace

   SCEPman sendet stets eine begrenzte Menge an nicht-geheimen und nicht-personenbezogenen Daten an unser Log Analytics Workspace (LAW). Diese Daten werden für

   • Lizenzierungszwecke

   • und Qualitätssicherung verwendet (z. B. hilft das globale Überwachen von Ausnahmen, allgemeine und weit verbreitete Probleme schnell zu erkennen, sodass wir unseren Kunden rasch Abhilfe bieten und teure Dienstunterbrechungen verhindern können).

   Standardmäßig sendet SCEPman keine personenbezogenen Daten an unser LAW.

   Je nach Protokollierungseinstellungen werden Debug- und andere Informationen an das LAW der glueckkanja-gab AG weitergeleitet. Unsere Support-Ingenieure können den Kundenadministratoren bitten, die Aktivierung der Remote-Debugging-Funktion zur Unterstützung von Support-Anfragen vorzunehmen. In solchen Fällen können Informationen zur Zertifikatsanforderung an unser LAW-Konto gesendet werden, die möglicherweise (der Kunde entscheidet, welche Informationen Teil des Zertifikats sind) personenbezogene Daten wie:

   • Benutzername

   • E-Mail

   • Microsoft Entra ID (Azure AD) UPN

   • Gerätekennzeichen

   Wir löschen periodisch alle protokollierten Daten in einem Intervall von

   • 30 Tagen

3. Wo (geographisch) verarbeitet und speichert SCEPman Daten?

SCEPman ist als Azure-App (lösungs-Template-basiert) konzipiert und wird in das Azure-Mandant (Tenant) des Kunden bereitgestellt. Die Datensouveränität einschließlich der Wahl des geografischen Standorts des Hosting-Rechenzentrums liegt somit im Ermessen und in der Präferenz des Kunden.

Externes Log Analytics Workspace

Das externe LAW, das wir standardmäßig zur Erfassung von Telemetrieinformationen für Lizenzdurchsetzungszwecke nutzen, befindet sich in nicht-personenbezogenen und nicht-geheimenAzure's West Europe Rechenzentrum. 4. Welchen Tenant-Berechtigungen muss der Admin zustimmen?

SCEPman verwendet Managed Identities, um ein sicheres Berechtigungsmodell in Ihrem Azure-Tenant zu implementieren.

Intune

scep_challenge_provider

1. scep_challenge_provider : Mit dieser Berechtigung kann SCEPman die Zertifikatsanforderung an Intune weiterleiten und verifizieren, dass die Zertifikatsanforderung von Intune stammt, wobei Letzteres eine zusätzliche Sicherheitsebene darstellt.Microsoft Graph

2. Directory.Read.All : Mit dieser Berechtigung kann SCEPman Microsoft Entra ID (Azure AD) konsultieren, um zu prüfen, ob das Benutzer- oder Gerätezertifikat von einem autorisierten Benutzer oder Gerät stammt.DeviceManagementManagedDevices.Read.All

3. Directory.Read.All DeviceManagementConfiguration.Read.All und : Mit diesen Berechtigungen fordert SCEPman die Liste der ausgestellten Zertifikate über Intune an, wenn dieEndpointList-Widerrufs-Funktion verwendet wird..

4. Directory.Read.All IdentityRiskyUser.Read.All: Diese Berechtigung ermöglicht SCEPman, automatisch Benutzerzertifikate zu widerrufen, wenn das AAD-Benutzerrisiko einen konfigurierten Schwellenwert übersteigt.

Jamf Pro

1. Lesezugriffe auf Benutzer, Computer und Geräte Mit diesen Berechtigungen kann SCEPman Jamf Pro konsultieren, um zu prüfen, ob das Benutzer- oder Gerätezertifikat von einem autorisierten Benutzer oder Gerät stammt.

Certificate Master

1. Directory.Read.All User.Read (über App-Registrierung): Mit dieser Berechtigung ermittelt Certificate Master, wer manuell ein Zertifikat anfordert oder widerruft.

2. Microsoft Graph DeviceManagementConfiguration.Read.All und : Mit diesen Berechtigungen fordert SCEPman die Liste der ausgestellten Zertifikate über Intune an, wenn die (als Managed Identity): Mit diesen Berechtigungen fordert Certificate Master die Liste der ausgestellten Zertifikate über Intune an. Administratoren können diese Zertifikate prüfen und manuell widerrufen.

5. Welche extern erreichbaren Endpunkte stellt SCEPman bereit?

SCEPman Core Service

1. SCEP-Endpunkt(e)

   • Für SCEP-Anfragen aufgerufen.

   • Je nach Konfiguration kann SCEPman mehrere SCEP-Endpunkte für Intune, Jamf Pro, DCs und generische andere MDMs bereitstellen.

2. Enrollment REST API

   • Ermöglicht Certificate Master, Zertifikate vom SCEPman-Core-Service anzufordern.

   • Ermöglicht benutzerdefinierten Anwendungen, Zertifikate vom SCEPman-Core-Service anzufordern.

3. EST-Endpunkt

   • Für EST simple re-enroll-Anfragen aufgerufen. Kann über die Konfiguration aktiviert werden.

   • Für EST simple enroll-Anfragen aufgerufen.

4. OCSP-Endpunkt

   • Für OCSP-Anfragen aufgerufen.

5. Certificate Distribution Point (CDP)

   • Die Certificate Revocation List (CRL) wird über diesen Endpunkt bereitgestellt.

   • Kann über Konfiguration.

6. aktiviert werden.

   • Validation API

7. Ermöglicht Certificate Master, den automatischen Widerrufsstatus eines Zertifikats zu bewerten.

   • SCEPman-Homepage

   • Zeigt die grundlegenden Statusinformationen von SCEPman öffentlich an (keine Geheimnisse).

   • Nur lesend. Konfiguration.

8. Kann über

   • SCEPman Probe-Endpunkt

Certificate Master

1. Health Checks: Integrierter App Service Health Check, Traffic Manager Probes, Application Gateway Probes.

   • Certificate Master Webportal

   • Manuelles Ausstellen von Serverzertifikaten und Signieren von CSRs.

   • Manuelles Widerrufen von über Certificate Master ausgestellten Zertifikaten.

2. Anzeigen der Liste manuell ausgestellter Zertifikate.

   • Certificate Master Probe-Endpunkt

Health Checks: Integrierter App Service Health Check

SCEPman Core Service

1. SCEP-Endpunkt(e)

   • 6. Wie sind die in Punkt 5 genannten Endpunkte geschützt?Intune: Geschützt über die Intune Challenge API ()

   • Microsoft Docs

2. Enrollment REST API

   • Jamf Pro, DCs, generische andere MDMs: Geschützt mit einer statischen SCEP-Challenge. Vom Kunden konfigurierbar. Kann im Azure Key Vault gespeichert werden.

3. EST-Endpunkt

   • Microsoft Entra ID (Azure AD) integrierte Authentifizierung.

   • Simple re-enroll: Zertifikatbasierte Authentifizierung.

4. OCSP-Endpunkt

   • Simple enroll: Microsoft Entra ID (Azure AD) integrierte Authentifizierung.

5. Certificate Distribution Point (CDP)

   • Kein Schutz erforderlich.

6. aktiviert werden.

   • Jamf Pro, DCs, generische andere MDMs: Geschützt mit einer statischen SCEP-Challenge. Vom Kunden konfigurierbar. Kann im Azure Key Vault gespeichert werden.

7. Ermöglicht Certificate Master, den automatischen Widerrufsstatus eines Zertifikats zu bewerten.

   • Zugriffstoken erforderlich.

8. Kann über

   • Kein Schutz, kann jedoch deaktiviert werden.

Certificate Master

1. Health Checks: Integrierter App Service Health Check, Traffic Manager Probes, Application Gateway Probes.

   • Jamf Pro, DCs, generische andere MDMs: Geschützt mit einer statischen SCEP-Challenge. Vom Kunden konfigurierbar. Kann im Azure Key Vault gespeichert werden.

   • Kein Schutz. Microsoft Entra ID (Azure AD).

2. Anzeigen der Liste manuell ausgestellter Zertifikate.

   • Kein Schutz, kann jedoch deaktiviert werden.

Rollen-Zuweisungen

SCEPman Core Service

1. SCEP-Endpunkt(e)

   • 7. Welche Ports und Protokolle werden von den in Frage 6 genannten Endpunkten verwendet?

   • Intune: HTTPS (TCP / 443)

2. Enrollment REST API

   • Jamf Pro, DCs, generische andere MDMs: HTTPS (TCP / 443)

3. EST-Endpunkt

   • Jamf Pro, DCs, generische andere MDMs: HTTPS (TCP / 443)

4. OCSP-Endpunkt

   • HTTPS (TCP / 443)

5. Certificate Distribution Point (CDP)

   • HTTPS (TCP / 443)

6. aktiviert werden.

   • HTTP (TCP / 80)

7. Ermöglicht Certificate Master, den automatischen Widerrufsstatus eines Zertifikats zu bewerten.

   • Jamf Pro, DCs, generische andere MDMs: HTTPS (TCP / 443)

8. Kann über

   • Jamf Pro, DCs, generische andere MDMs: HTTPS (TCP / 443)

Certificate Master

1. Health Checks: Integrierter App Service Health Check, Traffic Manager Probes, Application Gateway Probes.

   • Jamf Pro, DCs, generische andere MDMs: HTTPS (TCP / 443)

2. Anzeigen der Liste manuell ausgestellter Zertifikate.

   • Jamf Pro, DCs, generische andere MDMs: HTTPS (TCP / 443)

Wird von externen Diensten nicht verwendet.

Identität

• 1. Gibt es Conditional Access / rollenbasierte Zugriffskontrollen zum Schutz von SCEPman?

Ja. Der vollständige Satz der Microsoft Entra ID (Azure AD) RBAC-Richtlinien kann genutzt werden.

• 2. Können Zugangsdaten wiederhergestellt werden? Wenn ja, wie?

• Anmeldeinformationen: Hängt von den konfigurierten Microsoft Entra ID (Azure AD)-Richtlinien im Kunden-Tenant ab.

Statische SCEP-Challenge: Berechtigte Benutzer können auf die Challenge zugreifen.

Datenschutz 1. Wie ist data at-rest

gegen unbefugten Zugriff geschützt?

• Konfigurationsdaten

• Konfigurationsdaten können sicher im Azure Key Vault gespeichert werden (Version >= 1.7).

• Wenn Konfigurationsdaten nicht im Azure Key Vault gespeichert werden, werden sie im AppService gespeichert (BitLocker-Verschlüsselung).

Auf jegliche Konfigurationsdaten (Azure Key Vault, App Services) kann nur von autorisierten Benutzern mit den entsprechenden Azure-Berechtigungen zugegriffen werden.

• Kryptografische SchlüsselDer CA-Private-Key wird sicher im Azure Key Vault gespeichert ( FIPS 140 validiertes HSM

• standardmäßig).

• Der Private Key kann nicht gelesen oder exportiert werden.Der Private Key ist vor Löschung durch böswillige Administratoren geschützt ( Purge Protection und Soft Delete

• sind standardmäßig aktiviert).

Azure Key Vault verwendet einen privaten Endpunkt und kann nur von SCEPman aus zugegriffen werden (Standard für SCEPman-Installationen ab Version 2.8).

• Zertifikatsdatenbank

• Die Datenbank verwendet den Table-Dienst eines Azure Storage Accounts. Der Schutz beruht somit auf den in Azure integrierten Mechanismen.

• Insbesondere verwendet Azure rollenbasierten Zugriff, um Berechtigungen für die Daten zu verwalten.

• Azure Storage verwendet Datenbankverschlüsselung und unterstützt kundenseitig verwaltete Schlüssel.

Der Azure Storage Account verwendet einen privaten Endpunkt und kann nur von SCEPman aus zugegriffen werden (Standard für SCEPman-Installationen ab Version 2.8).

• Protokolle

• Protokolle werden in einem Log Analytics Workspace gespeichert.

Log Analytics verwendet Datenbankverschlüsselung und unterstützt kundenseitig verwaltete Schlüssel. 2. Wie ist data at-rest

• data in transit

  • geschützt?

  • SCEP:

  • Verwendet standardmäßig TLS (mindestens TLS 1.2 - Microsoft-Richtlinien gelten).

• SCEP-Anfragen sind an das CA-Zertifikat verschlüsselt und mit dem Client-Zertifikat signiert.

  • SCEP-Antworten sind an das Client-Zertifikat verschlüsselt und mit dem CA-Zertifikat signiert.

  • OCSP:

• OCSP-Anfragen sollten nicht verschlüsselt werden, um Henne-Ei-Probleme zu vermeiden.

  • OCSP-Antworten werden mit dem CA-Zertifikat signiert.

• Enrollment REST API und EST:

  • OCSP-Antworten werden mit dem CA-Zertifikat signiert.

• Erzwingen TLS (mindestens TLS 1.2 - Microsoft-Richtlinien gelten).

  • Certificate Master Webportal:

Kommunikation zwischen SCEPman Azure-Komponenten:

TLS (mindestens TLS 1.2 - Microsoft-Richtlinien gelten).

Security by Design

1. Verfolgt SCEPman eine Defense-in-Depth-Strategie?

• Azure-Komponenten

• Die Designphilosophie von SCEPman zielt darauf ab, die Angriffsfläche gegenüber externen Sicherheitsbedrohungen zu minimieren, indem externe Schnittstellen auf das erforderliche Minimum reduziert werden. Darüber hinaus werden die folgenden Technologien verwendet, um interne und externe Bedrohungen auf verschiedenen Ebenen zu erkennen und zu mindern:

• Key Vault

• App Insights

• Intune Gerätebereitstellungsverifikation

Microsoft Entra ID (Azure AD) Geräteprüfung

Private Endpunkte

Da SCEPman auf Azure-Komponenten basiert, können Sie Microsoft Defender (MD) für Cloud-Tools wie MD für App Service, MD für Storage oder MD für Key Vault nutzen.

Zertifikatsgültigkeit Als Cloud-PKI ist SCEPman für die Ausstellung und den Widerruf digitaler Zertifikate verantwortlich. Diese Zertifikate in Verbindung mit ihren privaten Schlüsseln authentifizieren Geräte oder Benutzer und gewähren Zugriff auf andere Ressourcen. Daher ist die Sicherheit der Ausstellung und des Widerrufs von Zertifikaten ein wichtiges Designziel. Ein hohes Sicherheitsniveau erfordert auch ein hohes Maß an Benutzerkomfort, da komplizierte und intransparente Prozesse eine größere Angriffsfläche und ein höheres Potenzial für menschliche Fehler bieten. Obwohl SCEPman viele Konfigurationsoptionen bietet, streben wir danach, überall dort, wo möglich, vernünftige und sichere Standardeinstellungen zu verwenden. Wenn ein privater Schlüssel kompromittiert wird, kann SCEPman das entsprechende Zertifikat in Echtzeit widerrufen. Für Zertifikate, die über Intune und Jamf Pro registriert wurden, erfolgt dieser Widerruf automatisch, sobald allgemeine Gegenmaßnahmen, die nicht spezifisch für SCEPman sind, gegen den Angriff ergriffen werden. Sie müssen lediglich

das entsprechende Intune-Objekt löschen oder das Jamf Pro-Objekt.Abhängig von Ihren Geräteaußerbetriebnahmeprozessen können Sie zusätzlich konfigurieren, Zertifikate beim Auslösen eines Wipes zu widerrufen, wenn Intune einen Widerruf anfordert , abhängig von Geräte-Complianceoder

Benutzerrisiko-Level , oder Sie können einzelne Zertifikate manuell über die Komponente Certificate Master widerrufen.

Manuell erstellte Zertifikate

• erfordern stets einen manuellen Widerruf.

• 2. Welche Technologien, Stacks, Plattformen wurden bei der Gestaltung von SCEPman verwendet?

• C#

• ASP.NET Core MVC

Bouncy Castle Crypto API

Azure (App Service, Key Vault, Storage Account, Log Analytics)

3. Welche kryptografischen Algorithmen und Schlüssellängen unterstützt SCEPman? Für die Schlüssel ausgestellter Zertifikate hat Certificate Master bei Verwendung der CSR-Methode keine Einschränkungen. Für formularbasierte Zertifikate sind RSA mit 2048 oder 4096 Bit die unterstützten Algorithmen und Schlüssellängen.).

Für SCEP-registrierte Zertifikate unterstützt Intune auf allen Plattformen bis zu RSA-4096-Bit-Schlüssel, was SCEPman ebenfalls unterstützt. Bei Verwendung des Plattform-KSP (TPM) unterstützt Windows höchstens RSA-2048-Bit-Schlüssel. Bei Verwendung des statischen SCEP-Endpunkts werden alle gängigen Algorithmen und Schlüssellängen unterstützt (insbesondere diejenigen, die

die Bouncy Castle Kryptografiebibliothek für C# unterstützt

Für den CA-Schlüssel unterstützt SCEPman nur RSA. RSA 4096 Bit ist die Standard-Schlüssellänge. 4096 Bit ist derzeit das Maximum, das Azure Key Vault unterstützt. Wenn Sie ein Intermediate-CA-Zertifikat verwenden, können Sie auch jede von Key Vault unterstützte Schlüssellänge verwenden, es muss jedoch ein RSA-Schlüssel sein.

Für Szenarien, die kein SCEP erfordern, kann eine ECC-CA erstellt werden, die die folgenden elliptischen Kurven unterstützt: P-256, secp256k1/P-256K, P-384, P-521.

4. Ist die von SCEPman erzeugte CA einzigartig?

• Ja

• Details:

• SCEPman erzeugt das private-public Schlüsselpaar für die Root-CA im Azure Key Vault in Ihrem Tenant. Daher ist die Root-CA einzigartig für Ihre persönliche SCEPman-Instanz und Sie haben die vollständige Kontrolle über die CA, ihr Zertifikat und den entsprechenden privaten Schlüssel.

Der Zugriff auf diese CA wird über Key Vault-Zugriffsrichtlinien gesteuert, die Sie bei Bedarf ändern können. Standardmäßig darf nur Ihre eigene SCEPman-Instanz und sonst niemand (auch kein Administrator) das Zertifikat verwenden, jedoch kann ein Abonnement-Administrator zusätzliche Berechtigungen gewähren.

Daher können andere SCEPman-Kunden nicht mit Ihrem VPN verbinden, egal wie sie ihren SCEPman konfigurieren. Wenn sie denselben Organisationsnamen wählen, haben sie trotzdem ihr eigenes Schlüsselpaar und damit ein anderes CA-Zertifikat, dem Ihr VPN-Gateway nicht vertraut. Azure CIS.

Dieser Abschnitt behandelt Fragen, die bei der Definition von Cyberabwehr-Richtlinien für Ihre Azure-Umgebung oder bei der Arbeit mit Best-Practice-Frameworks wie dem

CIS Microsoft Azure Foundations Benchmark auftreten. Storage Accounts

Für Szenarien, die kein SCEP erfordern, kann eine ECC-CA erstellt werden, die die folgenden elliptischen Kurven unterstützt: P-256, secp256k1/P-256K, P-384, P-521.1. Kann

Allow Blob public access

deaktiviert werden? , das ist tatsächlich bereits die Voreinstellung für neue SCEPman-Installationen. App Services 2. TLS: Kann?

Client certificate modeauf , das ist tatsächlich bereits die Voreinstellung für neue SCEPman-Installationen. Require gesetzt werden? , abhängig von Nein.

, da dies die Funktionalität von SCEPman beeinträchtigen würde. Der Grund ist, dass SCEPman Client-Zertifikate registriert, sodass die Clients noch keine Client-Zertifikate zur Authentifizierung besitzen (Henne-Ei-Problem). Das ist allerdings kein Sicherheitsproblem, da das SCEP-Protokoll eigene Authentifizierungsmechanismen über die SCEP-Challenge verwendet. Daher benötigt SCEPman eine Ausnahme von Richtlinien, die gegenseitiges TLS erzwingen. Der muss auf App Services 2.0?

Ignore gesetzt werden Optional

3. Kann die

HTTP-Version geändert werden? Obwohl SCEPman mit jeder der verfügbaren HTTP-Versionen funktionieren sollte, unterstützen wir derzeit nur die Standard-

HTTP 1.1- hauptsächlich aus Mangel an Tests.

Wenn Sie diese Einstellung auf eigenes Risiko ändern, bedenken Sie bitte, dass nicht nur SCEPman die neuere HTTP-Version unterstützen muss. Auch die unterschiedlichen Client-Typen müssen diese HTTP-Version unterstützen, d. h. die OS-integrierten SCEP-Clients von Windows, macOS, iOS, iPadOS, die in IoT-Geräten, die OCSP-Clients auf denselben Plattformen sowie NACs verschiedener Anbieter. geändert werden? 4. Kann

HTTPS Only

Client certificate mode aktiviert werden?

Nein (nicht für den SCEPman App Service) , da dies die OCSP-Responder-Funktionalität von SCEPman in Kombination mit vielen OCSP-Clients und Geräte-Appliances beeinträchtigen würde. OCSP ist ein Protokoll, das häufiger über HTTP als über HTTPS bereitgestellt wird. Einer der Gründe ist, dass bei Verwendung von TLS für die Zertifikats-Widerrufsprüfung (Herunterladen von CRLs oder OCSP) ein Henne-und-Ei-Problem auftreten kann, bei dem der Client oder die Appliance keine TLS-Verbindung zum OCSP-Endpunkt herstellen kann, weil das Serverzertifikat zuerst über OCSP überprüft werden müsste. Es fügt auch nicht viel zusätzliche Sicherheit hinzu, da OCSP-Antworten ohnehin kryptografisch signiert sind und daher nicht gefälscht werden können. Daher benötigt SCEPman eine Ausnahme von Richtlinien, die TLS erzwingen.).

Wenn Sie diese Einstellung auf eigenes Risiko ändern, bedenken Sie bitte, dass nicht nur SCEPman die neuere HTTP-Version unterstützen muss. Auch die unterschiedlichen Client-Typen müssen diese HTTP-Version unterstützen, d. h. die OS-integrierten SCEP-Clients von Windows, macOS, iOS, iPadOS, die in IoT-Geräten, die OCSP-Clients auf denselben Plattformen sowie NACs verschiedener Anbieter. Hinweis:

kann für den SCEPman App Service nicht aktiviert werden, sollte jedoch für den Certificate Master App Service aktiviert werden.

5. Kann die minimale eingehende TLS-Version auf 1.3 gesetzt werden?

• für den SCEPman App Service, da TLS 1.3 keine Neuverhandlung unterstützt. Das bedeutet, dass der Server nach dem Aufbau einer Verbindung den Client nicht dazu auffordern kann, ein Client-Zertifikat vorzulegen. Wir möchten, dass sich der Client unter bestimmten Umständen mit einem Zertifikat authentifiziert (EST simple re-enroll). Wenn Sie TLS auf 1.3 setzen, können Sie Ihre Zertifikate nicht mehr per EST erneuern.

• Außerdem unterstützen nicht alle SCEP-Clients TLS 1.3. Ein wichtiges Beispiel ist der in Windows 8, 10 und 11 integrierte SCEP-Client, der (Stand 2025-07) TLS 1.3 nicht unterstützt (es wird auf Client-Seite ein

Fehler während der SCEP-Registrierung

empfohlen, für Certificate Master die minimale eingehende TLS-Version auf 1.3 zu setzen, da nur Browser auf den Certificate Master App Service zugreifen.	DSGVO und Datenlokation	1. Verlassen Daten Europa?	Das hängt von der Wahl des Kunden hinsichtlich des Azure-Rechenzentrums ab, in dem SCEPman und seine Komponenten bereitgestellt werden sollen.
Eine vollständige Bereitstellung von SCEPman einschließlich aller Komponenten in europäischen Azure-Rechenzentren ist möglich.	2. Auf welche Drittanbieter-Cloud-Provider ist SCEPman angewiesen und warum?	Unternehmen	Dienste Kontakt.
Zweck	Microsoft Corporation	Cloud-Dienste (Azure) Building 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublin, Ireland Siehe hier	GitHub Inc (Tochtergesellschaft der Microsoft Corporation)

Git-Code-Repository, Integration, Test- und Release-Automatisierung, Speicherung

88 Colin P Kelly Jr St,

San Francisco, CA 94107,Vereinigte Staaten Code-Repository, CI/CD-Pipeline, Binärspeicherung

Sichere Entwicklungspraxis

1. Was stellt sicher, dass SCEPman sichere Software ist? Unsere Softwareentwicklung basiert auf dem:

Microsoft Security Development Lifecycle

. Durch die Anwendung von SDL-Praktiken helfen wir, sicheren Code und sichere Deployments zu erstellen. Wir verfügen über die ISO-27001-Informationssicherheitszertifizierung für unsere Produktentwicklung.2. Wie setzen Sie gängige Secure Design Practices um? So implementieren wir Secure Design Practices, die vom SDL empfohlen werden

Design- und Bedrohungsmodell als Team

Unsere Threat-Modelling-Praxis basiert auf den

Empfehlungen des Tufts Security and Privacy Lab

. Wir diskutieren Designentscheidungen und potenzielle STRIDE-Bedrohungen in einem heterogenen Team aus Entwicklern, unserem CSOC und PKI-Beratern sowie dem Support-Team. Bevorzugen von Plattform-Sicherheit gegenüber benutzerdefiniertem Code Wo möglich verwenden wir Funktionalität aus .NET oder etablierten Bibliotheken, vorzugsweise Open Source, anstatt das Rad neu zu erfinden. Zum Beispiel verwenden wir Legion of the Bouncy Castle für C#, um mit kryptografischen Datenstandards zu arbeiten. Wir verlassen uns außerdem auf Azure-Dienste wie Key Vault zur Erzeugung kryptografischer Schlüssel, App Services für Webhosting, Azure Monitor für Protokollierung und Azure Storage als Datenbank-Engine.

Sichere Konfiguration ist Standard

Um das Potenzial menschlicher Fehler zu minimieren, entwerfen wir die Produkte so, dass Sie bei Verwendung der Standardwerte eine sichere Konfiguration haben. Zum Beispiel setzen unsere

ARM-Templates

und unser

Terraform-Provider

Konfigurationseinstellungen, um 4096-Bit-HSM-gestützte RSA-Schlüssel zu verwenden, und sie deaktivieren alle Enrollment-Endpunkte außer Intune SCEP und Certificate Master (für die Sie explizit Berechtigungen zuweisen müssen).

Vertraue niemals Daten vom Client Als PKI-Software steht die Entscheidung, welchen Daten vertraut wird, im Mittelpunkt jeder Entscheidung. Schließlich besteht der Zweck von Zertifikaten und ihren Enrollment-Protokollen darin, zu entscheiden, welchen Daten vertraut wird..

Assume Breach

Unsere Protokollierung basierend auf Azure Monitor ermöglicht die Überwachung der SCEPman-Operationen. Sie integriert sich leicht in SIEM-Systeme wie Sentinel, um erfolgreiche Angreifer zu erkennen, z. B. wenn es ihnen gelingt, ohne Autorisierung Zertifikate zu registrieren. Unsere Integration mit Azure-Diensten ermöglicht die Nutzung der Microsoft Defender for Cloud-Services, z. B. Defender for App Service. Durchsetzung des Prinzips der geringsten Rechte Unser RBAC-Modell für Certificate Master erlaubt es, Benutzern nur die Berechtigungen zuzuweisen, die sie wirklich benötigen. SCEPman verwendet Managed Identities, die nur die für den Betrieb benötigten Berechtigungen haben

Minimieren der Schadensausbreitung

Wir bemühen uns, den möglichen Schaden im Falle eines erfolgreichen Angriffs zu minimieren. Zum Beispiel aktiviert unsere Standardinstallation die Key Vault

Soft Delete-Funktion mit Purge Protection Intune Gerätebereitstellungsverifikationmit einem

nicht exportierbaren HSM-gestützten privaten Schlüssel

für die Zertifizierungsstelle. Soft Delete mit Purge Protection stellt sicher, dass kein böswilliger Administrator oder kompromittiertes Administratorkonto den privaten Schlüssel der CA löschen kann – er kann innerhalb von Minuten wiederhergestellt werden, um den normalen Betrieb fortzusetzen, und nicht einmal ein Global Admin kann ihn vor Ablauf einer 90-tägigen Frist endgültig löschen. Der nicht exportierbare HSM-gestützte CA-Schlüssel stellt sicher, dass selbst ein Angreifer mit den höchsten möglichen Rechten den CA-Schlüssel nicht stehlen kann. Minimieren der AngriffsflächeWir stellen sicher, dass nur die Schnittstellen exponiert werden, die für den Betrieb durch den Kunden erforderlich sind. Wenn ein SCEP-Endpunkt nicht konfiguriert ist, werden SCEP-Anfragen nicht einmal verarbeitet.

Durch die Verwendung von

stellen wir sicher, dass zwei Dienste, von denen SCEPman abhängt, Azure Key Vault und Azure Storage, nicht über das Internet erreichbar sind. Missbrauchsfälle berücksichtigen Wenn SCEPman eine autorisierte Certificate Signing Request (CSR) erhält, unterliegt sie dennoch mehreren konfigurierbaren Beschränkungen. Zum Beispiel kann die Lebensdauer niemals das

konfigurierte maximale Gültigkeitszeitraum

überschreiten, selbst wenn dies angefordert wurde.

Sicherheitsereignisse überwachen und Alarmieren

Wenn SCEPman Sicherheitsereignisse erkennt, werden diese als Warnung oder Fehler in den Logs protokolliert. Die Integration mit Azure Monitor und Azure Event Hub erleichtert es,

Alarme zu konfigurieren

oder diese Sicherheitsereignisse mit einem SIEM zu analysieren.

• 3. Wie sichern Sie Ihre eigene Entwicklungsumgebung?

• Als Teil eines Unternehmens, das auch CSOC-Dienste und Sicherheitsberatung anbietet, haben wir hohe Sicherheitsstandards für unsere Geräte, Prozesse und das Bewusstsein der Benutzer. Wir sind Teil von Microsoft MISA, ISO-27001-zertifiziert und Microsoft Partner of the Year mit unseren Sicherheitsangeboten.

  • Unsere Quellrepositories verfügen über Branch-Protection-Regeln und wir weisen nur die minimal notwendigen Prinzipale für die Repositories und Deployment-Pipelines einzelnen Entwicklerkonten zu. Wir automatisieren Tests und Deployments, wo möglich, um die Angriffsfläche durch kompromittierte Konten zu reduzieren.

  • 4. Ist SCEPman Teil eines Bug-Bounty-Programms?

  • Nein.

  • 5. Welche QA-Maßnahmen sind vorhanden?

  • Wir stellen SCEPman auf einem internen, Beta- und Produktionskanal bereit

  • Jeder Produktions-Release muss zuerst den internen und Beta-Kanal durchlaufen und die relevanten QA-Hürden im Rahmen unseres CI-Prozesses bestehen

Unit-Tests

Alarme zu konfigurieren

Peer-Review Integrationstests Stresstests