> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/de/andere/security-faq.md). # Sicherheit & 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 mithilfe 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 der Administratoraktivitäten (UPNs). ### 2. Welche Daten werden von/im Auftrag von SCEPman dauerhaft gespeichert und wie? 1. Konfiguration * Konfigurationsdaten enthalten immer das öffentliche/private Schlüsselpaar der SCEPman-CA sowie das Zertifikat, die sicher in Azure Key Vault gespeichert werden. * Zusätzlich können Konfigurationsdaten Geheimnisse wie statische SCEP-Challenges oder Passwörter enthalten. Der Zweck dieser Parameter wird in der SCEPman-Dokumentation erläutert. * Alle Konfigurationsparameter können aus Sicherheitsgründen 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](#id-1.-which-data-is-processed-by-scepman). * Dieses Verhalten kann [deaktiviert werden](/de/scepman-konfiguration/application-settings/basics.md#appconfig-enablecertificatestorage). * Beim Ausstellen von Zertifikaten über Certificate Master wird der Antragsteller (Microsoft Entra ID (Azure AD) UPN) gespeichert. * Beim Widerrufen von Zertifikaten über Certificate Master werden der Widerrufsstatus des Zertifikats und die Identität des Benutzers, der es widerrufen hat (Microsoft Entra ID (Azure AD) UPN), gespeichert. 3. Protokollierung Basierend auf der SCEPman-Konfiguration des Kunden kann die Protokollierung aktiviert werden. Abhängig von den Einstellungen zur Protokollierungs-Detailtiefe des Kunden können die Protokolle alle Daten enthalten, die SCEPman verarbeitet. Der Kunde konfiguriert den Speicherort der Protokolle. 4. Externer Log Analytics Workspace SCEPman sendet immer eine begrenzte Menge an **nicht geheimen** und **nicht personenbezogenen** Daten an unser 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 schaffen und so teure Dienstausfälle verhindern können). Standardmäßig sendet SCEPman **keine personenbezogenen Daten** an unser LAW. Abhängig von den Protokollierungseinstellungen werden Debug- und andere Informationen an das LAW von glueckkanja-gab AG weitergeleitet. Unsere Support-Ingenieure können den Kundenadministrator bitten, [zu aktivieren](/de/scepman-konfiguration/application-settings/basics.md#appconfig-remotedebug) die Remote-Debugging-Funktion zur Unterstützung von Troubleshooting-Anfragen. 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 zum Beispiel: * Benutzername * E-Mail * Microsoft Entra ID (Azure AD) UPN * Gerätekennung Wir löschen regelmäßig **alle** protokollierten Daten im Abstand von * 30 Tagen ### 3. Wo (geografisch) verarbeitet und speichert SCEPman Daten? SCEPman ist konzeptionell als Azure-App (auf Grundlage einer Solution-Template) umgesetzt, d. h. sie wird im Azure Tenant des Kunden bereitgestellt. Damit liegt die Datenhoheit einschließlich der Wahl des geografischen Standorts des Hosting-Rechenzentrums in den Händen und im Ermessen des Kunden. #### Externer Log Analytics Workspace Der externe LAW, den wir zum Erfassen von (standardmäßig **nicht personenbezogenen** und **nicht geheimen**) Telemetriedaten für Zwecke der Lizenzdurchsetzung verwenden, befindet sich im **Azure-Rechenzentrum West Europe** Rechenzentrum. ### 4. Welchen Tenant-Berechtigungen muss der Administrator zustimmen? SCEPman nutzt Managed Identities, um in Ihrem Azure Tenant ein sicheres Berechtigungsmodell umzusetzen. #### 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-Widerrufsfeature](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory). 4. Microsoft Graph `IdentityRiskyUser.Read.All`:\ \ Diese Berechtigung ermöglicht es SCEPman, automatisch [Benutzerzertifikate zu widerrufen, wenn das AAD-Benutzerrisiko einen konfigurierten Schwellenwert überschreitet](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-userriskcheck). #### 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 die App-Registrierung):\ \ Mit dieser Berechtigung bestimmt Certificate Master, wer ein Zertifikat manuell anfordert oder widerruft. 2. Microsoft 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 zugänglichen Endpunkte stellt SCEPman bereit? #### **SCEPman Core Service** 1. SCEP-Endpunkt(e) * Wird für SCEP-Anfragen aufgerufen. * Abhängig von der 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 SCEPman-Kerndienst anzufordern. * Ermöglicht benutzerdefinierten Anwendungen, Zertifikate vom SCEPman-Kerndienst anzufordern. 3. EST-Endpunkt * Wird für EST Simple-Reenroll-Anfragen aufgerufen. Kann über die Konfiguration aktiviert werden. * Wird für EST Simple-Enroll-Anfragen aufgerufen. 4. OCSP-Endpunkt * 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](/de/scepman-konfiguration/application-settings/crl.md). 6. Validierungs-API * Ermöglicht Certificate Master, den automatischen Widerrufsstatus eines Zertifikats zu bewerten. 7. SCEPman-Startseite * Zeigt öffentlich SCEPmans grundlegende Statusinformationen an (keine Geheimnisse). * Nur lesbar. * Kann deaktiviert werden über [Konfiguration](/de/scepman-konfiguration/application-settings/basics.md#appconfig-anonymoushomepageaccess). 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 manuell ausgestellter Zertifikate anzeigen. 2. Certificate Master Probe-Endpunkt * Health Checks: Integrierter App Service Health Check ### 6. Wie werden die Endpunkte aus Frage 5 geschützt? #### SCEPman Core Service 1. SCEP-Endpunkt(e) * Intune: Geschützt über die Intune Challenge API ([Microsoft Docs](https://docs.microsoft.com/en-us/mem/intune/protect/scep-libraries-apis)) * 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 * Microsoft Entra ID (Azure AD)-integrierte Authentifizierung. 3. EST-Endpunkt * Simple Re-enroll: Zertifikatsbasierte Authentifizierung. * Simple Enroll: Microsoft Entra ID (Azure AD)-integrierte Authentifizierung. 4. OCSP-Endpunkt * Kein Schutz erforderlich. 5. Certificate Distribution Point (CDP) * Zugriffstoken erforderlich. 6. Validierungs-API * Microsoft Entra ID (Azure AD)-integrierte Authentifizierung. 7. SCEPman-Startseite * Kein Schutz, kann jedoch deaktiviert werden. 8. SCEPman Probe-Endpunkt * Kein Schutz. #### Certificate Master 1. Certificate Master-Webportal * Microsoft Entra ID (Azure AD)-integrierte Authentifizierung. * Microsoft Entra ID (Azure AD) [Rollenzuweisungen](/de/scepman-konfiguration/rbac.md). 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-Endpunkt(e) * Intune: HTTPS (TCP / 443) * Jamf Pro, DCs, allgemeine andere MDMs: HTTPS (TCP / 443) 2. Enrollment-REST-API * HTTPS (TCP / 443) 3. EST-Endpunkt * HTTPS (TCP / 443) 4. OCSP-Endpunkt * HTTP (TCP / 80) 5. Certificate Distribution Point (CDP) * HTTP (TCP / 80) 6. Validierungs-API * Wird nicht von externen Diensten 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, um SCEPman zu schützen? * Ja. Der gesamte Satz der Microsoft Entra ID (Azure AD) RBAC-Richtlinien kann genutzt werden. ### 2. Können Zugriffsdaten wiederhergestellt werden? Wenn ja, wie? * Anmeldedaten: Hängt von den konfigurierten Microsoft Entra ID (Azure AD)-Richtlinien im Kundentenant ab. * Statische SCEP-Challenge: Autorisierte Benutzer können auf die Challenge zugreifen. ## Datenschutz ### 1. Wie werden *Daten im Ruhezustand* vor unbefugtem 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 sollen, werden sie auf dem 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](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#compliance) standardmäßig). * Der private Schlüssel kann nicht gelesen oder exportiert werden. * Der private Schlüssel ist vor dem Löschen durch rogue Admins geschützt ([Purge Protection und Soft Delete](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) sind standardmäßig aktiviert). * Azure Key Vault verwendet einen privaten Endpunkt und kann nur von SCEPman aus erreicht werden (Standard für SCEPman-Installationen ab Version 2.8). #### Zertifikatsdatenbank * Die Datenbank verwendet den Table-Service eines Azure Storage Account. Daher stützt sich der Schutz auf die 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 kundenverwaltete Schlüssel. * Der Azure Storage Account verwendet einen privaten Endpunkt und kann nur von SCEPman aus erreicht werden (Standard für SCEPman-Installationen ab Version 2.8). #### Protokolle * Protokolle werden in einem Log-Analytics-Arbeitsbereich gespeichert. * Log Analytics verwendet Datenbankverschlüsselung und unterstützt kundenverwaltete Schlüssel. ### 2. Wie werden *Daten während der Übertragung* vor unbefugtem 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 Clientzertifikat signiert. * SCEP-Antworten werden an das Clientzertifikat 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 durch das 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 SCEPman-Azure-Komponenten: * TLS (mindestens TLS 1.2 - Microsoft-Richtlinien gelten). ## Sicherheit durch Design ### 1. Verwendet SCEPman eine Defense-in-Depth-Strategie? #### Azure-Komponenten SCEPmans Designphilosophie folgt dem Ansatz, 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äteregistrierungsprüfung * Microsoft Entra ID (Azure AD)-Geräteprüfung * 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 Ausstellung und zum Widerruf von Zertifikaten ein sehr wichtiges Designziel. Ein hohes Maß an Sicherheit erfordert auch ein hohes Maß an Benutzerfreundlichkeit, weil 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, wann immer 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. Bei Zertifikaten, die über Intune und Jamf Pro registriert wurden, tut SCEPman dies automatisch, sobald gegen den Angriff übliche, nicht SCEPman-spezifische Gegenmaßnahmen ergriffen werden. Sie müssen nur [das entsprechende Intune](/de/scepman-konfiguration/device-directories.md) - 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](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationrevokecertificatesonwipe), wenn [Intune den Widerruf anfordert](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationdevicedirectory), abhängig von [Gerätekonformität](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationcompliancecheck) oder [Benutzerrisikoniveau](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationuserriskcheck), oder Sie können einzelne Zertifikate manuell über die Certificate Master-Komponente widerrufen. [Manuell erstellte Zertifikate](/de/zertifikatsverwaltung/certificate-master.md) erfordern immer einen manuellen Widerruf. ### 2. Welche Technologien, Stacks und Plattformen wurden zur Entwicklung 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 werden RSA mit 2048 oder 4096 Bit als unterstützte Algorithmen und Schlüssellängen verwendet. Für SCEP-registrierte Zertifikate unterstützt Intune auf allen Plattformen RSA-Schlüssel mit bis zu 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üssellängen unterstützt (insbesondere diejenigen, die [die kryptografische Bibliothek Bouncy Castle für C# unterstützt](https://www.bouncycastle.org/csharp/)). Für den CA-Schlüssel unterstützt SCEPman nur RSA. RSA mit 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 erstellte CA eindeutig? Ja Details: * SCEPman generiert 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 volle 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, aber ein Abonnementadministrator kann zusätzliche Berechtigungen gewähren. * Daher können andere SCEPman-Kunden keine Verbindung zu Ihrem VPN herstellen, ganz gleich, wie sie ihren SCEPman konfigurieren. Wenn sie denselben Organisationsnamen wählen, verfügen sie dennoch über ihr eigenes Schlüsselpaar und damit über ein anderes CA-Zertifikat, dem Ihr VPN-Gateway nicht vertraut. ## Azure CIS Dieser Abschnitt behandelt Fragen, die beim Definieren von Cyber-Defense-Richtlinien für Ihre Azure-Umgebung oder bei der Arbeit mit Best-Practice-Frameworks wie dem [CIS Microsoft Azure Foundations Benchmark](https://www.cisecurity.org/benchmark/azure/). ### Storage Accounts #### 1. Kann `Öffentlichen Blob-Zugriff zulassen` deaktiviert werden? *Ja*, das ist für neue SCEPman-Installationen tatsächlich bereits der Standard. ### App Services #### 2. TLS: Kann `Client certificate mode` auf `Erforderlich`? *Nein*, da dies die Funktionalität von SCEPman beeinträchtigen würde. Das liegt daran, dass SCEPman Clientzertifikate ausstellt, sodass die Clients noch keine Clientzertifikate haben, mit denen sie sich authentifizieren können (Henne-Ei-Problem). Das ist jedoch kein Sicherheitsproblem, da das SCEP-Protokoll seine eigenen Authentifizierungsmechanismen über die SCEP-Challenge verwendet. Daher benötigt SCEPman eine Ausnahme von Richtlinien, die gegenseitiges TLS erzwingen. Der `Client certificate mode` muss auf `Ignorieren` 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 den Standard `HTTP 1.1` - hauptsächlich aufgrund fehlender 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 verschiedenen Arten von Clients müssen diese HTTP-Version unterstützen, d. h. die in das Betriebssystem integrierten SCEP-Clients von Windows, macOS, iOS und iPadOS, die auf IoT-Geräten, die OCSP-Clients auf denselben Plattformen, aber auch NACs verschiedener Hersteller. #### 4. Kann `Nur HTTPS` 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: Wenn Sie TLS für die Prüfung des Zertifikatswiderrufs verwendet hätten (Herunterladen von CRLs oder OCSP), könnte ein Henne-Ei-Problem entstehen, bei dem der Client oder die Appliance keine TLS-Verbindung zum OCSP-Endpunkt aufbauen kann, weil das Serverzertifikat zuerst über OCSP überprüft werden muss. Außerdem erhöht es die Sicherheit nicht wesentlich, 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. **Hinweis:** **`Nur HTTPS`** kann für den SCEPman App Service nicht 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, sobald eine Verbindung hergestellt ist, den Client nicht mehr auffordern kann, ein Clientzertifikat vorzulegen. Wir möchten, dass sich der Client unter bestimmten Umständen mit einem Zertifikat authentifiziert (EST Simple-Reenroll), sodass Sie, wenn Sie TLS auf 1.3 setzen, Ihre Zertifikate nicht mehr über EST erneuern können. 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 während der SCEP-Registrierung einen clientseitigen [Fehler während der SCEP-Registrierung](/de/andere/troubleshooting/general.md#some-windows-machines-do-not-enroll-or-renew-certificates)). **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. Verlässt Daten Europa? * Dies 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 seiner Komponenten in europäischen Azure-Rechenzentren ist möglich. ### 2. Auf welche Cloud-Anbieter von Drittanbietern ist SCEPman angewiesen und warum? | Unternehmen | Dienste | Kontakt | Zweck | | ---------------------------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Microsoft Corporation | Cloud-Dienste (Azure) |

Building 3, Carmanhall Road Sandyford,
Industrial Estate 18, Dublin,
Irland

| Siehe [hier](/de/scepman-bereitstellung/deployment-guides/enterprise-guide-1.md#overview-azure-resource). | | 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 Entwicklungspraktiken ### 1. Was stellt sicher, dass SCEPman sichere Software ist? Unsere Softwareentwicklung basiert auf dem [Microsoft Security Development Lifecycle](https://www.microsoft.com/en-us/securityengineering/sdl/). Die Anwendung von SDL-Praktiken hilft uns dabei, sicheren Code und sichere Bereitstellungen zu erstellen. [Wir verfügen für unsere Produktentwicklung über die Informationssicherheitszertifizierung ISO 27001.](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf) ### 2. Wie setzen Sie gängige Secure-Design-Praktiken um? So setzen wir [vom SDL empfohlene Secure Design Practices](https://www.microsoft.com/en-us/securityengineering/sdl/practices/secure-by-design): #### Design- und Threat-Modeling im Team Unsere Threat-Modeling-Praxis basiert auf den [Empfehlungen des Tufts Security and Privacy Lab](https://tsp.cs.tufts.edu/tmnt/threatmodeling.html). Wir besprechen Designentscheidungen und potenzielle STRIDE-Bedrohungen in einem heterogenen Team aus Entwicklern, unserem [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)und PKI-Beratern sowie dem Support-Team. #### Plattformsicherheit gegenüber individuellem Code bevorzugen Wo möglich, verwenden wir Funktionalität 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 verlassen uns auch auf Azure-Dienste wie Key Vault zur Erzeugung kryptografischer Schlüssel, App Services für das Webserver-Hosting, Azure Monitor für die Protokollierung 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-Templates](https://github.com/scepman/install) und unser [Terraform-Provider ](https://registry.terraform.io/modules/scepman/scepman/)die Konfiguration so, dass 4096-Bit-RSA-Schlüssel mit HSM-Unterstützung verwendet werden, und sie deaktivieren alle Registrierungsendpunkte außer Intune SCEP und Certificate Master (für die Sie Berechtigungen explizit zuweisen müssen). #### Daten vom Client niemals vertrauen Als PKI-Software steht die Entscheidung darüber, welchen Daten vertraut werden soll, im Zentrum jeder Entscheidung. Schließlich besteht der Zweck von Zertifikaten und ihren Registrierungsprotokollen darin, zu entscheiden, welchen Daten vertraut wird. #### Von einem Sicherheitsvorfall ausgehen Unsere auf Azure Monitor basierende Protokollierung ermöglicht die Überwachung der SCEPman-Operationen. Sie lässt sich leicht 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. #### Das Prinzip der geringsten Privilegien durchsetzen Das RBAC-Modell von Certificate Master ermöglicht es Ihnen, Benutzern nur die Berechtigungen zuzuweisen, die sie benötigen. SCEPman verwendet Managed Identities, die nur über [die für den Betrieb erforderlichen Berechtigungen verfügen](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to). #### Blast Radius minimieren Wir sind bestrebt, den möglichen Schaden im Falle eines erfolgreichen Angriffs zu minimieren. Beispielsweise aktiviert unsere Standardinstallation das Key Vault[ Soft-Delete-Funktion mit Purge Protection](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) mit einem [nicht exportierbaren, HSM-gestützten privaten Schlüssel](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#hsm-protected-keys) für die Zertifizierungsstelle. Soft Delete mit Purge Protection stellt sicher, dass weder ein böswilliger Administrator noch ein kompromittiertes Administratorkonto den privaten Schlüssel der CA löschen kann. Der private Schlüssel kann innerhalb von Minuten wiederhergestellt werden, um den normalen Betrieb fortzusetzen, und nicht einmal ein Global Admin kann ihn vor Ablauf einer 90-Tage-Frist endgültig löschen. Der nicht exportierbare, HSM-gestützte CA-Schlüssel stellt sicher, dass selbst ein Angreifer mit den höchstmöglichen Rechten den CA-Schlüssel nicht stehlen kann. #### Angriffsfläche minimieren Wir stellen sicher, dass nur diejenigen 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. Unter Verwendung von [Private Endpunkte](/de/azure-konfiguration/private-endpoints.md), 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 Einschränkungen. Beispielsweise kann die Lebensdauer niemals den [konfigurierten maximalen Gültigkeitszeitraum](/de/scepman-konfiguration/application-settings/certificates.md#appconfig-validityperioddays)überschreiten, selbst wenn dies angefordert wurde. #### Sicherheitsereignisse überwachen und warnen Wenn SCEPman Sicherheitsereignisse erkennt, protokolliert es sie auf Warnungs- oder Fehlerstufe. Integrationen mit Azure Monitor und Azure Event Hub ermöglichen es Ihnen, [Warnungen zu konfigurieren](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) oder Ereignisse 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 Sicherheitsbewusstsein unserer Benutzer. Wir sind Teil von Microsoft MISA, ISO 27001-zertifiziert und mit unseren Security-Angeboten Microsoft Partner of the Year. Unsere Quellcode-Repositories haben Branch-Protection-Regeln, und wir weisen den Repositories und Bereitstellungspipelines einzelnen Entwicklerkonten nur die unbedingt notwendigen Berechtigungen zu. Wir automatisieren Tests und Bereitstellungen, wo immer 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 über einen internen-, Beta- und Produktionskanal bereit * Jede Produktionsversion muss zuerst den internen- und den 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 durch Dritte, 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 den Codebestand auf CVEs und andere gängige Exploits (einschließlich Abhängigkeiten wie Bibliotheken von Drittanbietern) scannen, die die Sicherheit der von SCEPman exponierten Endpunkte beeinträchtigen könnten. Vor jeder Freigabe werden alle relevanten Funde bewertet und behoben, damit 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“. Im ersten Fall sehen wir einen inhärenten Interessenkonflikt. Im zweiten Fall sehen wir, da typische Penetrationstest-Services oft einfach die exponierten Endpunkte gegen CVEs und andere bekannte Exploits prüfen, keinen Vorteil gegenüber den Prüfungen, die wir bereits mittels statischer Codeanalyse durchführen. Wenn Sie Ihre eigenen Penetrationstests durchführen möchten, bitte [kontaktieren Sie uns](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29) und teilen Sie uns Ihre Anforderungen mit. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.scepman.com/de/andere/security-faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.