Sicherheit und Datenschutz

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

Datenverarbeitung und Berechtigungen

1. Welche Daten werden von SCEPman verarbeitet?

SCEPman verarbeitet X.509-Zertifikate unter Verwendung der SCEP- und EST-Protokolle zur Ausstellung sowie der OCSP- und CRL-Protokolle zur Validierung dieser Zertifikate. Jedes Gerätezertifikat muss eine eindeutige Gerätekennung 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ätekennung

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 (Informationen zu Betriebssystem und Browser)

Certificate Master führt einen Audit-Trail über Administratoraktivitäten (UPNs).

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

1. Konfiguration

   • Konfigurationsdaten enthalten immer das öffentliche/private Schlüsselpaar und Zertifikat der SCEPman-CA, das sicher in Azure Key Vault gespeichert wird.

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

   • Alle Konfigurationsparameter können für erhöhte Sicherheit in 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önnen, siehe Frage 1.

   • Dieses Verhalten kann deaktiviert.

   • Wenn Zertifikate über Certificate Master ausgestellt werden, wird der Anforderer (Microsoft Entra ID (Azure AD) UPN) gespeichert.

   • Wenn Zertifikate über Certificate Master widerrufen werden, werden der Zertifikatswiderrufsstatus und die Identität des Benutzers, der ihn widerrufen hat (Microsoft Entra ID (Azure AD) UPN), gespeichert.

3. Logging

   Basierend auf der Konfiguration von SCEPman beim Kunden kann Logging aktiviert werden. Abhängig von den Einstellungen des Kunden zur Protokollierungsdetailtiefe können die Protokolle beliebige Daten enthalten, die SCEPman verarbeitet. Der Kunde konfiguriert den Speicherort der Protokolle.

4. Externer Log Analytics Workspace

   SCEPman sendet immer eine begrenzte Menge nicht-geheimer und nicht-personenbezogener Daten an unseren Log Analytics Workspace (LAW). Diese Daten werden verwendet für

   • Lizenzierungszwecke.

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

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

   Abhängig von den Protokolleinstellungen werden Debug- und andere Informationen an den LAW der glueckkanja-gab AG weitergeleitet. Unsere Support-Ingenieure können den Kunden-Administrator bitten, zu aktivieren die Remote-Debugging-Funktion zur Unterstützung bei Fehlerbehebungsanfragen. In solchen Fällen können Informationen zur Zertifikatsanforderung an unser LAW-Konto gesendet werden und möglicherweise (der Kunde entscheidet, welche Informationen Teil des Zertifikats sind) personenbezogene Daten enthalten wie:

   • Benutzername

   • E-Mail

   • Microsoft Entra ID (Azure AD) UPN

   • Gerätekennung

   Wir löschen regelmäßig alle protokollierte Daten in einem Intervall von

   • 30 Tage

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

SCEPman ist konstruktionsbedingt als Azure App (lösungsvorlagenbasiert) umgesetzt, d. h. sie wird im Azure-Tenant des Kunden bereitgestellt. Damit liegen Datensouveränität einschließlich der Wahl der geografischen Lage des Hosting-Rechenzentrums in den Händen und nach dem Wunsch des Kunden.

Externer Log Analytics Workspace

Der externe LAW, den wir zur Erfassung (standardmäßig nicht-personenbezogener und nicht-geheimer) von Telemetriedaten für Lizenzdurchsetzungszwecke nutzen, befindet sich in West-Europe-Rechenzentrum von Azure .

4. Welchen Tenant-Berechtigungen muss der Administrator zustimmen?

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

Intune

1. Intune scep_challenge_provider: Mit dieser Berechtigung kann SCEPman die Zertifikatsanforderung an Intune weiterleiten und überprüfen, dass die Zertifikatsanforderung von Intune stammt, wodurch Letzteres eine zusätzliche Sicherheitsebene hinzufügt.

2. Microsoft Graph 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.

3. Microsoft Graph DeviceManagementManagedDevices.Read.All und DeviceManagementConfiguration.Read.All: Mit diesen Berechtigungen fordert SCEPman über Intune die Liste der ausgestellten Zertifikate an, wenn die EndpointList-Revocation-Funktion.

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

Jamf Pro

1. Leseberechtigungen für 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. Microsoft Graph User.Read (über App Registration): Mit dieser Berechtigung ermittelt Certificate Master, wer ein Zertifikat manuell anfordert oder widerruft.

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

5. Welche extern erreichbaren Endpunkte stellt SCEPman bereit?

SCEPman Core Service

1. SCEP-endpoint(s)

   • Wird für SCEP-Anfragen aufgerufen.

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

2. Enrollment REST API

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

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

3. EST-endpoint

   • Wird für EST-Simple-Re-Enrollment-Anfragen aufgerufen. Kann über die Konfiguration aktiviert werden.

   • Wird für EST-Simple-Enrollment-Anfragen aufgerufen.

4. OCSP-endpoint

   • Wird für OCSP-Anfragen aufgerufen.

5. Certificate Distribution Point (CDP)

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

   • Kann aktiviert werden über Konfiguration.

6. Validation API

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

7. SCEPman-Startseite

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

   • Nur Lesezugriff.

   • Kann deaktiviert werden über Konfiguration.

8. SCEPman Probe-Endpunkt

   • Health Checks: Integrierter App Service Health Check, Traffic Manager-Probing, Application Gateway-Probing.

Certificate Master

1. Certificate Master Webportal

   • Serverzertifikate manuell ausstellen und CSRs signieren.

   • Über Certificate Master ausgestellte Zertifikate manuell widerrufen.

   • Liste der manuell ausgestellten Zertifikate anzeigen.

2. Certificate Master Probe-Endpunkt

   • Health Checks: Integrierter App Service Health Check

6. Wie sind die Endpunkte aus 5. geschützt?

SCEPman Core Service

1. SCEP-endpoint(s)

   • Intune: Geschützt über die Intune Challenge API (Microsoft Docs)

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

2. Enrollment REST API

   • In Microsoft Entra ID (Azure AD) integrierte Authentifizierung.

3. EST-endpoint

   • Simple Re-Enroll: Zertifikatsbasierte Authentifizierung.

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

4. OCSP-endpoint

   • Kein Schutz erforderlich.

5. Certificate Distribution Point (CDP)

   • Zugriffstoken erforderlich.

6. Validation API

   • In Microsoft Entra ID (Azure AD) integrierte Authentifizierung.

7. SCEPman-Startseite

   • Kein Schutz, kann aber deaktiviert werden.

8. SCEPman Probe-Endpunkt

   • Kein Schutz.

Certificate Master

1. Certificate Master Webportal

   • In Microsoft Entra ID (Azure AD) integrierte Authentifizierung.

   • Microsoft Entra ID (Azure AD) Rollenzuweisungen.

2. Certificate Master Probe-Endpunkt

   • Kein Schutz.

7. Welche Ports und Protokolle werden von den Endpunkten aus Frage 6 verwendet?

SCEPman Core Service

1. SCEP-endpoint(s)

   • Intune: HTTPS (TCP / 443)

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

2. Enrollment REST API

   • HTTPS (TCP / 443)

3. EST-endpoint

   • HTTPS (TCP / 443)

4. OCSP-endpoint

   • HTTP (TCP / 80)

5. Certificate Distribution Point (CDP)

   • HTTP (TCP / 80)

6. Validation API

   • Wird von externen Diensten nicht verwendet.

7. SCEPman-Startseite

   • HTTPS (TCP / 443)

8. SCEPman Probe-Endpunkt

   • HTTPS (TCP / 443)

Certificate Master

1. Certificate Master Webportal

   • HTTPS (TCP / 443)

2. Certificate Master Probe-Endpunkt

   • HTTPS (TCP / 443)

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?

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

• Statische SCEP-Challenge: Autorisierte Benutzer dürfen auf die Challenge zugreifen.

Datenschutz

1. Wie werden Daten im Ruhezustand gegen unbefugten Zugriff geschützt?

Konfigurationsdaten

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

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

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

Kryptografische Schlüssel

• Der private CA-Schlüssel wird sicher in Azure Key Vault gespeichert (FIPS 140-validiertes HSM standardmäßig).

• Der private Schlüssel kann nicht gelesen oder exportiert werden.

• Der private Schlüssel ist gegen das Löschen durch unberechtigte 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 Account. Der Schutz beruht daher auf den in Azure integrierten Mechanismen.

• Insbesondere verwendet Azure rollenbasierten Zugriff zur Verwaltung der Berechtigungen für die Daten.

• Azure Storage verwendet Datenbankverschlüsselung und unterstützt vom Kunden 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 vom Kunden verwaltete Schlüssel.

2. Wie werden Daten während der Übertragung gegen unbefugten Zugriff geschützt?

• SCEP:

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

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

  • SCEP-Antworten werden 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 vom CA-Zertifikat signiert.

• Enrollment-REST-API und EST:

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

• Certificate Master Webportal:

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

• Kommunikation zwischen den Azure-Komponenten von SCEPman:

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

Security by Design

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

Azure-Komponenten

Die Designphilosophie von SCEPman folgt dem Ansatz, die Exposition 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 abzumildern:

• Key Vault

• App Insights

• Verifizierung der Intune-Gerätebereitstellung

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

• Private Endpunkte

Da SCEPman auf Azure-Komponenten aufbaut, können Sie Microsoft Defender (MD) for Cloud-Tools wie MD for App Service, MD for Storage oder MD for Key Vault verwenden.

Zertifikatsgültigkeit

Als Cloud-PKI ist SCEPman für die Ausstellung und den Widerruf digitaler Zertifikate verantwortlich. Diese Zertifikate authentifizieren zusammen mit ihren privaten Schlüsseln Geräte oder Benutzer und gewähren Zugriff auf andere Ressourcen. Daher ist die Sicherheit der Prozesse zur Zertifikatsausstellung und zum Zertifikatswiderruf ein sehr wichtiges Designziel. Ein hohes Sicherheitsniveau erfordert auch ein hohes Maß an Benutzerfreundlichkeit, da komplizierte und intransparente Prozesse eine größere Angriffsfläche und ein höheres Potenzial für menschliche Fehler haben. Obwohl SCEPman bei Bedarf viele Konfigurationsoptionen bietet, haben wir uns bemüht, soweit möglich vernünftige und sichere Standardwerte zu verwenden.

Daher kann SCEPman, wenn ein privater Schlüssel kompromittiert wurde, das entsprechende Zertifikat in Echtzeit widerrufen. Für Zertifikate, die über Intune und Jamf Pro ausgestellt wurden, macht SCEPman dies automatisch, sobald allgemeine, nicht SCEPman-spezifische Gegenmaßnahmen gegen den Angriff ergriffen werden. Sie müssen lediglich das entsprechende Intune - oder Jamf-Pro-Objekt löschen.

Abhängig von Ihren Prozessen zur Außerbetriebnahme von Geräten können Sie zusätzlich konfigurieren, Zertifikate zu widerrufen, wenn ein Wipe ausgelöst wird, wenn Intune den Widerruf anfordert, abhängig von Gerätekonformität oder Benutzerrisikoniveau, oder Sie können einzelne Zertifikate manuell über die Komponente Certificate Master widerrufen.

Manuell erstellte Zertifikate erfordern immer einen manuellen Widerruf.

2. Welche Technologien, Stacks und Plattformen wurden für das Design 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üsselgrößen 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 werden RSA mit 2048 oder 4096 Bit als unterstützte Algorithmen und Schlüsselgrößen unterstützt.

Für SCEP-bereitgestellte Zertifikate unterstützt Intune auf allen Plattformen RSA-Schlüssel bis 4096 Bit, was SCEPman ebenfalls unterstützt. Bei Verwendung des Plattform-KSP (TPM) unterstützt Windows höchstens RSA-Schlüssel mit 2048 Bit. Bei Verwendung des statischen SCEP-Endpunkts werden alle gängigen Algorithmen und Schlüsselgrößen unterstützt (insbesondere diejenigen, die die kryptografische Bibliothek Bouncy Castle für C# unterstützt).

Für den CA-Schlüssel unterstützt SCEPman nur RSA. RSA mit 4096 Bit ist die Standard-Schlüsselgröße. 4096 Bit ist derzeit das Maximum, das von Azure Key Vault unterstützt wird. Wenn Sie ein Intermediate-CA-Zertifikat verwenden, können Sie auch jede von Key Vault unterstützte Schlüsselgröße verwenden, jedoch muss es 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 erstellte CA eindeutig?

Ja

Details:

• SCEPman generiert das private-öffentliche 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 volle Kontrolle über die CA, ihr Zertifikat und den zugehörigen privaten Schlüssel.

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

• Daher können andere SCEPman-Kunden keine Verbindung zu Ihrem VPN herstellen, unabhängig davon, wie sie ihren SCEPman konfigurieren. Wenn sie denselben Organisationsnamen wählen, haben sie dennoch 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 Cyberdefense-Richtlinien für Ihre Azure-Umgebung oder bei der Arbeit mit Best-Practice-Frameworks wie dem CIS Microsoft Azure Foundations Benchmark.

Storage Accounts

1. Kann Allow Blob public access deaktiviert werden?

Ja, das ist tatsächlich bereits die Standardeinstellung für neue SCEPman-Installationen.

App-Dienste

2. TLS: Kann Client certificate mode auf Require?

Neingesetzt werden, da dies die Funktionalität von SCEPman beeinträchtigen würde. Der Grund dafür ist, dass SCEPman Clientzertifikate ausstellt, sodass die Clients noch keine Clientzertifikate zur Authentifizierung besitzen (Henne-Ei-Problem). Das ist jedoch kein Sicherheitsproblem, da das SCEP-Protokoll eigene Authentifizierungsmechanismen über die SCEP-Challenge verwendet. Daher benötigt SCEPman eine Ausnahme von Richtlinien, die Mutual TLS erzwingen. Die Client certificate mode muss auf Ignore oder Optional.

3. Kann die HTTP-Version auf 2.0?

Obwohl SCEPman mit jeder der verfügbaren HTTP-Versionen funktionieren sollte, unterstützen wir derzeit nur die Standard- HTTP 1.1 - hauptsächlich aufgrund fehlender Tests.

Wenn Sie diese Einstellung ändern – auf eigenes Risiko – bedenken Sie bitte, dass nicht nur SCEPman die neuere HTTP-Version unterstützen muss. Auch die verschiedenen Arten von Clients müssen diese HTTP-Version unterstützen, d. h. die in Windows, macOS, iOS und iPadOS integrierten SCEP-Clients, die in IoT-Geräten, die OCSP-Clients auf denselben Plattformen, aber auch NACs verschiedener Hersteller.

4. Kann HTTPS Only 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 Herstellergeräten 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 Überprüfung des Zertifikatswiderrufs (Herunterladen von CRLs oder OCSP) ein Henne-Ei-Problem entstehen kann, bei dem der Client oder das Gerät die TLS-Verbindung zum OCSP-Endpunkt nicht herstellen kann, weil das Serverzertifikat zuerst über OCSP überprüft werden muss. Außerdem bringt es nicht viel zusätzliche Sicherheit, da OCSP-Antworten ohnehin kryptografisch signiert sind und daher nicht vorgetäuscht werden können. Daher benötigt SCEPman eine Ausnahme von Richtlinien, die TLS erzwingen.

Hinweis: HTTPS Only kann nicht für den SCEPman App Service aktiviert werden, sollte aber für den Certificate Master App Service aktiviert werden.

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

Nein 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 auffordern kann, ein Clientzertifikat vorzulegen. Wir möchten, dass sich der Client in bestimmten Fällen mit einem Zertifikat authentifiziert (EST Simple Reenroll), daher können Sie bei TLS 1.3 Ihre Zertifikate nicht mit 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 kommt zu einem clientseitigen Fehler während der SCEP-Bereitstellung).

Hinweis: Da nur Browser auf den Certificate Master App Service zugreifen, wird empfohlen, für Certificate Master die minimale eingehende TLS-Version auf 1.3 zu setzen.

DSGVO und Datenresidenz

1. Verlassen Daten Europa?

• Dies hängt von der Wahl des Azure-Rechenzentrums durch den Kunden 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 Cloud-Anbieter von Drittanbietern stützt sich SCEPman und warum?

Unternehmen	Dienste	Kontakt	Zweck
Microsoft Corporation	Cloud-Dienste (Azure)	Building 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublin, Irland	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ärspeicher

Sichere Entwicklungspraktiken

1. Was stellt sicher, dass SCEPman sichere Software ist?

Unsere Softwareentwicklung basiert auf dem Microsoft Security Development Lifecycle. Der Einsatz von SDL-Praktiken hilft uns, sicheren Code und sichere Bereitstellungen zu erstellen. Für unsere Produktentwicklung verfügen wir über die ISO-27001-Informationssicherheitszertifizierung.

2. Wie setzen Sie gängige Secure Design Practices um?

So setzen wir Secure Design Practices um, die vom SDL empfohlen werden:

Design and Threat Model as a Team

Unsere Threat-Modeling-Praxis basiert auf den Empfehlungen des Tufts Security and Privacy Lab. Wir diskutieren Designentscheidungen und potenzielle STRIDE-Bedrohungen in einem heterogenen Team aus Entwicklern, unserer CSOC - und PKI-Beratern sowie dem Support-Team.

Plattformsicherheit gegenüber Custom Code bevorzugen

Wo möglich, verwenden wir Funktionalitäten aus .NET oder etablierte Bibliotheken, vorzugsweise Open Source, anstatt das Rad neu zu erfinden. Beispielsweise verwenden wir Legion of the Bouncy Castle C# für die Arbeit mit kryptografischen Datenstandards. Wir setzen außerdem auf Azure-Dienste wie Key Vault zur Erzeugung kryptografischer Schlüssel, App Services für das Hosting von Webservern, Azure Monitor für das Logging und Azure Storage als Datenbank-Engine.

Sichere Konfiguration ist der Standard

Um das Potenzial für menschliche Fehler zu minimieren, gestalten wir die Produkte so, dass Sie bei Verwendung der Standardwerte eine sichere Konfiguration haben. Beispielsweise setzen unsere ARM-Vorlagen und unser Terraform-Provider die Konfiguration so, dass 4096-Bit-RSA-Schlüssel mit HSM-Unterstützung verwendet werden, und sie deaktivieren alle Enrollment-Endpunkte außer Intune SCEP und Certificate Master (für die Sie explizit Berechtigungen zuweisen müssen).

Vertrauen Sie niemals Daten vom Client

Als PKI-Software ist die Entscheidung, welchen Daten zu vertrauen ist, das Herzstück jeder Entscheidung. Schließlich besteht der Zweck von Zertifikaten und ihren Enrollment-Protokollen darin, zu entscheiden, welchen Daten zu vertrauen ist.

Breach annehmen

Unser auf Azure Monitor basierendes Logging ermöglicht die Überwachung der Vorgänge von SCEPman. Es lässt sich problemlos in SIEM-Systeme wie Sentinel integrieren, um erfolgreiche Angreifer zu erkennen, z. B. wenn es ihnen gelungen ist, Zertifikate ohne Autorisierung zu registrieren. Unsere Integration mit Azure-Diensten ermöglicht die Nutzung der Microsoft Defender for Cloud-Dienste, z. B. Defender for App Service.

Least Privilege durchsetzen

Unser RBAC-Modell für Certificate Master ermöglicht es, Benutzern nur die Berechtigungen zuzuweisen, die sie wirklich benötigen.

SCEPman verwendet Managed Identities, die nur die für den Betrieb erforderlichen Berechtigungen.

Blast Radius minimieren

Wir bemühen uns, den möglichen Schaden im Falle eines erfolgreichen Angriffs zu minimieren. Beispielsweise aktiviert unsere Standardinstallation die Key Vault Soft Delete-Funktion mit Purge Protection mit einem nicht exportierbaren, HSM-gestützten privaten Schlüssel für die Zertifizierungsstelle. Soft Delete mit Purge Protection stellt sicher, dass kein unberechtigter 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 selbst ein Global Administrator kann ihn vor Ablauf von 90 Tagen nicht endgültig löschen. Der nicht exportierbare, HSM-gestützte CA-Schlüssel stellt sicher, dass selbst ein Angreifer mit höchstmöglichen Rechten den CA-Schlüssel nicht stehlen kann.

Angriffsfläche minimieren

Wir stellen sicher, dass nur die Schnittstellen bereitgestellt 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 Private Endpunktestellen wir sicher, dass zwei von SCEPman abhängige Dienste, Azure Key Vault und Azure Storage, nicht über das Internet erreichbar sind.

Missbrauchsfälle berücksichtigen

Wenn SCEPman autorisierte Certificate Signing Requests (CSRs) erhält, unterliegt es dennoch mehreren konfigurierbaren Einschränkungen. Beispielsweise kann die Gültigkeitsdauer nie die konfigurierte maximale Gültigkeitsdauerüberschreiten, selbst wenn dies angefordert wurde.

Sicherheitsereignisse überwachen und darauf alarmieren

Wenn SCEPman Sicherheitsereignisse erkennt, werden diese als Warnung oder Fehler in den Protokollen aufgezeichnet. Die Integration mit Azure Monitor und Azure Event Hub erleichtert es, Warnungen zu konfigurieren oder diese Sicherheitsereignisse mit einem SIEM zu analysieren.

3. Wie sichern Sie Ihre eigene Entwicklungsumgebung?

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

Unsere Quellcode-Repositorys verfügen über Branch-Protection-Regeln, und wir weisen einzelnen Entwicklerkonten für die Repositorys und Deployment-Pipelines nur die unbedingt notwendigen Prinzipale zu. Wir automatisieren Tests und Bereitstellungen, 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 implementiert?

• Wir stellen SCEPman über interne, Beta- und Produktionskanäle bereit

• Jede Produktionsfreigabe muss zuerst den internen und Beta-Kanal durchlaufen und dabei im Rahmen unseres CI-Prozesses die relevanten QA-Hürden bestehen

  • Unit-Tests

  • Peer Review

  • Integrationstests

  • Stresstests

  • Erfahrungsbasiertes Testen

  • Codeanalyse von Drittanbietern, z. B. Sonar, Dependabot und andere

6. Führen Sie regelmäßig Penetrationstests durch?

Nein.

Im Rahmen unserer Secure Development Practices verwenden wir Tools (z. B. statische Codeanalyse), die die Codebasis auf CVEs und andere gängige Exploits (einschließlich Abhängigkeiten wie Bibliotheken von Drittanbietern) überprüfen, die die Sicherheit der von SCEPman bereitgestellten Endpunkte beeinträchtigen könnten. Vor jeder Veröffentlichung werden alle relevanten Befunde bewertet und behoben, um sicherzustellen, dass SCEPman frei von bekannten Schwachstellen bleibt. Wir führen weder selbst Penetrationstests durch noch verwenden wir Tools von Drittanbietern für „Penetration Test-as-a-Service“. Für Ersteres sehen wir einen inhärenten Interessenkonflikt. Für Letzteres sehen wir, da typische Penetrationstest-Dienste oft lediglich die exponierten Endpunkte gegen CVEs und andere bekannte Exploits prüfen, keinen zusätzlichen Nutzen gegenüber den Prüfungen, die wir bereits mittels statischer Codeanalyse durchführen. Wenn Sie eigene Penetrationstests durchführen möchten, wenden Sie sich bitte an uns und teilen Sie uns Ihre Anforderungen mit.