> 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/sonstiges/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 unter Verwendung der SCEP- und EST-Protokolle für die 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 zum 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 der SCEPman-CA sowie das Zertifikat, das sicher in 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 erläutert. * Alle Konfigurationsparameter können aus Gründen der erhöhten 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 bitte [Frage 1](#id-1.-which-data-is-processed-by-scepman). * Dieses Verhalten kann [deaktiviert](/de/scepman-konfiguration/application-settings/basics.md#appconfig-enablecertificatestorage). * Bei der Ausstellung von Zertifikaten über Certificate Master wird der Anforderer (Microsoft Entra ID (Azure AD) UPN) gespeichert. * Beim Widerrufen von Zertifikaten über Certificate Master werden der Zertifikatswiderrufsstatus und die Identität des Benutzers, der es widerrufen hat (Microsoft Entra ID (Azure AD) UPN), gespeichert. 3. Protokollierung Abhängig von der Konfiguration von SCEPman durch den Kunden kann Protokollierung aktiviert werden. Je nach Protokollierungs-Detailgrad des Kunden können die Protokolle beliebige Daten enthalten, die SCEPman verarbeitet. Der Kunde konfiguriert den Speicherort der Protokolle. 4. Externes Log Analytics Workspace SCEPman sendet immer eine begrenzte Menge an **nicht vertraulichen** und **nicht-personenbezogenen** Daten an unser Log Analytics Workspace (LAW). Diese Daten werden verwendet für * Lizenzierungszwecke. * Qualitätssicherung (z. B. hilft uns das globale Überwachen von Ausnahmen, allgemeine und weit verbreitete Probleme schnell zu erkennen, sodass wir unseren Kunden rasch Abhilfe bieten und dadurch teure Dienstausfälle verhindern können). Standardmäßig sendet SCEPman **keine personenbezogenen Daten** an unser LAW. Je nach Protokolleinstellungen werden Debug- und andere Informationen an das LAW von glueckkanja-gab AG weitergeleitet. Unsere Support-Ingenieure können den Kundenadministrator bitten, [die](/de/scepman-konfiguration/application-settings/basics.md#appconfig-remotedebug) Remote-Debugging-Funktion zur Unterstützung von Fehlersuchanfragen zu aktivieren. 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 enthalten, wie zum Beispiel: * Benutzername * E-Mail * Microsoft Entra ID (Azure AD) UPN * Gerätekennung Wir löschen regelmäßig **alle** protokollierten Daten in einem Intervall von * 30 Tagen ### 3. Wo (geografisch) verarbeitet und speichert SCEPman Daten? SCEPman ist von Grund auf als Azure App (auf Basis einer Lösungsvorlage) umgesetzt, d. h. es wird im Azure Tenant des Kunden bereitgestellt. Somit liegen Datenhoheit einschließlich der Wahl des geografischen Standorts des Hosting-Rechenzentrums in der Hand und nach Präferenz des Kunden. #### Externes Log Analytics Workspace Das externe LAW, das wir zur Erfassung von Telemetrieinformationen zu Zwecken der Lizenzdurchsetzung nutzen (standardmäßig **nicht-personenbezogenen** und **nicht vertraulichen**) befindet sich in **Azure-Rechenzentrum West Europe** . ### 4. Welche Tenant-Berechtigungen muss der Administrator genehmigen? 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, wobei 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-Widerrufsfunktion](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory). 4. Microsoft Graph `IdentityRiskyUser.Read.All`:\ \ Mit dieser Berechtigung kann SCEPman automatisch [Benutzerzertifikate 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 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 erreichbaren Endpunkte stellt SCEPman bereit? #### **SCEPman Core Service** 1. SCEP-Endpunkt(e) * Aufgerufen für SCEP-Anfragen. * Abhängig von der 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 Kernservice von SCEPman anzufordern. * Ermöglicht benutzerdefinierten Anwendungen, Zertifikate vom Kernservice von SCEPman anzufordern. 3. EST-Endpunkt * Aufgerufen für einfache EST-Re-enroll-Anfragen. Kann per Konfiguration aktiviert werden. * Aufgerufen für einfache EST-Enrollment-Anfragen. 4. OCSP-Endpunkt * Aufgerufen für OCSP-Anfragen. 5. Certificate Revocation List (CRL)-Verteilungspunkt * Die Certificate Revocation List (CRL) wird über diesen Endpunkt bereitgestellt. * Kann über [die 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 [die Konfiguration](/de/scepman-konfiguration/application-settings/basics.md#appconfig-anonymoushomepageaccess). 8. SCEPman-Probe-Endpunkt * Integritätsprüfungen: 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 * Integritätsprüfungen: Integrierter App Service Health Check ### 6. Wie sind 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, generische andere MDMs: Geschützt mit einer statischen SCEP-Challenge. Vom Kunden konfigurierbar. Kann in Azure Key Vault gespeichert werden. 2. Enrollment REST API * Integrierte Authentifizierung mit Microsoft Entra ID (Azure AD). 3. EST-Endpunkt * Einfaches Re-enroll: Zertifikatsbasierte Authentifizierung. * Einfaches Enrollment: Integrierte Authentifizierung mit Microsoft Entra ID (Azure AD). 4. OCSP-Endpunkt * Kein Schutz erforderlich. 5. Certificate Revocation List (CRL)-Verteilungspunkt * Zugriffstoken erforderlich. 6. Validierungs-API * Integrierte Authentifizierung mit Microsoft Entra ID (Azure AD). 7. SCEPman-Startseite * Kein Schutz, kann jedoch deaktiviert werden. 8. SCEPman-Probe-Endpunkt * Kein Schutz. #### Certificate Master 1. Certificate Master-Webportal * Integrierte Authentifizierung mit Microsoft Entra ID (Azure AD). * 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, generische 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 Revocation List (CRL)-Verteilungspunkt * HTTP (TCP / 80) 6. Validierungs-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, um SCEPman zu schützen? * Ja. Der vollständige Satz von Microsoft Entra ID (Azure AD) RBAC-Richtlinien kann genutzt werden. ### 2. Können Zugriffsanmeldeinformationen wiederhergestellt werden? Wenn ja, wie? * Anmeldeinformationen: Hängt von den konfigurierten Microsoft Entra ID (Azure AD)-Richtlinien im Tenant des Kunden 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 App Service gespeichert (BitLocker-Verschlüsselung). * Auf Konfigurationsdaten (Azure Key Vault, App Services) können nur autorisierte Benutzer mit den entsprechenden Azure-Berechtigungen zugreifen. #### Kryptografische Schlüssel * Der private CA-Schlüssel wird sicher in Azure Key Vault gespeichert ([FIPS-140-validierter HSM](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#compliance) standardmäßig). * Der private Schlüssel kann weder gelesen noch exportiert werden. * Der private Schlüssel ist vor Löschung durch böswillige Administratoren 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 Private Endpoint und kann nur von SCEPman aus erreicht werden (Standard für SCEPman-Installationen ab Version 2.8 und höher). #### Zertifikatsdatenbank * Die Datenbank verwendet den Table Service eines Azure Storage Account. Daher beruht der Schutz 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 Private Endpoint und kann nur von SCEPman aus erreicht werden (Standard für SCEPman-Installationen ab Version 2.8 und höher). #### Protokolle * Protokolle werden in einem Log Analytics Workspace gespeichert. * Log Analytics verwendet Datenbankverschlüsselung und unterstützt kundenseitig verwaltete 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 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 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, seine 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äteregistrierungsüberprüfung * Geräteprüfung mit Microsoft Entra ID (Azure AD) * Private Endpoints 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 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, wann immer möglich vernünftige und sichere Standardwerte zu verwenden. Wenn also 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, tut SCEPman dies automatisch, sobald gegen den Angriff übliche, nicht speziell auf SCEPman bezogene 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 Geräteaußerbetriebnahme können Sie zusätzlich konfigurieren, Zertifikate zu widerrufen, wenn ein Wipe ausgelöst wird, [wenn Intune den Widerruf anfordert](/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 [der Geräte-Compliance](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationcompliancecheck) oder [dem 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 unterstützt. 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 Standardschlüssellänge. 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ü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-öffentliche Schlüsselpaar für die Root-CA im Azure Key Vault in Ihrem Tenant. Daher ist die Root-CA eindeutig 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, 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 ihr 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 vertrauen wird. ## 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](https://www.cisecurity.org/benchmark/azure/). ### Storage Accounts #### 1. Kann `Öffentlichen Blob-Zugriff zulassen` deaktiviert werden? *Ja*, was tatsächlich bereits die Standardeinstellung für neue SCEPman-Installationen ist. ### App Services #### 2. TLS: Kann `Clientzertifikatsmodus` auf `Require`? *Nein*, gesetzt werden, da dies die Funktionalität von SCEPman beeinträchtigen würde. Das liegt daran, dass SCEPman Clientzertifikate registriert, sodass die Clients noch keine Clientzertifikate zur Authentifizierung haben (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 mutual TLS erzwingen. Der `Clientzertifikatsmodus` 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 - 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 im Betriebssystem integrierten SCEP-Clients von Windows, macOS, iOS, iPadOS, die in IoT-Geräten, die OCSP-Clients auf denselben Plattformen, aber auch NACs verschiedener Anbieter. #### 4. Kann `Nur HTTPS` aktiviert werden? *Nein (nicht für das 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: Wenn Sie TLS für die Überprüfung des Zertifikatswiderrufs verwenden würden (Herunterladen von CRLs oder OCSP), könnte ein Henne-Ei-Problem entstehen, 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 dies nicht viel zusätzliche Sicherheit, 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 das SCEPman-App Service nicht aktiviert werden, sollte aber für das Certificate Master App Service aktiviert werden. #### 5. Kann die minimale eingehende TLS-Version auf 1.3 gesetzt werden? *Nein* für das 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. In bestimmten Fällen möchten wir, dass der Client sich mit einem Zertifikat authentifiziert (EST simple reenroll), daher können Sie Ihre Zertifikate bei TLS 1.3 nicht über 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 zu einem clientseitigen [Fehler während der SCEP-Registrierung](/de/sonstiges/troubleshooting/general.md#some-windows-machines-do-not-enroll-or-renew-certificates)). **Hinweis:** Da nur Browser auf das Certificate Master App Service zugreifen, wird empfohlen, für Certificate Master die minimale eingehende TLS-Version auf 1.3 zu setzen. ## Compliance ### 1. Ist glueckkanja ISO 27001-zertifiziert? Ja. Das Information Security Management System (ISMS) der glueckkanja AG ist gemäß **ISO/IEC 27001:2022** zertifiziert. Der Geltungsbereich der Zertifizierung umfasst: * Produktentwicklung * Managed Services Sie können das aktuelle Zertifikat [hier](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf). ### 2. Lässt glueckkanja seine Sicherheit von externen Experten testen? Ja. Im Jahr 2026 beauftragte die glueckkanja AG ein unabhängiges, spezialisiertes offensives Sicherheitsunternehmen mit einer Red-Team-Bewertung, die unser gesamtes Unternehmen abdeckte. Wir haben uns bewusst für diesen ganzheitlichen Ansatz statt für einen klassischen Penetrationstest entschieden. Statt einzelne Systeme oder Endpunkte auf bekannte Schwachstellen zu prüfen, simulierte das Red Team einen realistischen, fortgeschrittenen Cyberangriff durch einen internen Angreifer auf unsere IT-Infrastruktur, wobei Techniken so miteinander verkettet wurden, wie reale Angreifer es tun. Die Bewertung konzentrierte sich auf: * die Identifizierung von Schwachstellen mit hoher Auswirkung, * die Abbildung vollständiger Angriffspfade durch unsere Umgebung, * die Bewertung potenzieller Vektoren für den unbefugten Zugriff auf Kundenumgebungen, * die Bewertung potenzieller Vektoren für die Durchführung von Supply-Chain-Angriffen. Alle Ergebnisse wurden zusammen mit Empfehlungen zur Minderung dokumentiert und werden im Rahmen unseres nach ISO 27001 zertifizierten Informationssicherheitsmanagementsystems behandelt. Wir werden diese Red-Team-Bewertung jährlich wiederholen. ## DSGVO und Datenresidenz ### 1. Verlassen Daten Europa? * Das hängt von der Wahl des Kunden bezüglich 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 Cloud-Anbieter von Drittparteien 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](/de/scepman-bereitstellung/deployment-guides/enterprise-guide-1.md#overview-azure-resource). | | GitHub Inc (Tochtergesellschaft der Microsoft Corporation) | git code repository, Integration, Testing 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/). Durch die Anwendung von SDL-Praktiken können wir sicheren Code und sichere Bereitstellungen erstellen. Wir haben die [ISO-27001-Informationssicherheitszertifizierung für unsere Produktentwicklung](#id-1.-is-glueckkanja-iso-27001-certified). ### 2. Wie setzen Sie gängige Secure-Design-Praktiken um? So setzen wir [die vom SDL empfohlenen Secure-Design-Praktiken](https://www.microsoft.com/en-us/securityengineering/sdl/practices/secure-by-design): #### Design und Bedrohungsmodellierung als Team Unsere Praxis der Bedrohungsmodellierung basiert auf dem [Empfehlungen des Tufts Security and Privacy Lab](https://tsp.cs.tufts.edu/tmnt/threatmodeling.html). Wir diskutieren Designentscheidungen und potenzielle STRIDE-Bedrohungen in einem heterogenen Team von Entwicklern, unserem [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)und PKI-Beratern sowie dem Support-Team. #### Bevorzugen Sie Plattform-Sicherheit gegenüber individuellem Code Sofern möglich, verwenden wir Funktionen aus .NET oder etablierte Bibliotheken, vorzugsweise Open Source, anstatt das Rad neu zu erfinden. Zum Beispiel verwenden wir Legion of the Bouncy Castle C# zur Arbeit mit kryptografischen Datenstandards. Wir verlassen uns außerdem auf Azure-Dienste wie Key Vault zum Erzeugen kryptografischer Schlüssel, App Services für das Hosten von Webservern, Azure Monitor für die Protokollierung und Azure Storage als Datenbank-Engine. #### Sichere Konfiguration ist der Standard Um das Potenzial menschlicher Fehler zu minimieren, gestalten wir die Produkte so, dass Sie bei Verwendung der Standardwerte eine sichere Konfiguration haben. Zum Beispiel unsere [ARM-Vorlagen](https://github.com/scepman/install) und unser [Terraform-Provider ](https://registry.terraform.io/modules/scepman/scepman/)setzen Konfigurationseinstellungen so, dass 4096-Bit-RSA-Schlüssel mit HSM-Unterstützung verwendet werden, und deaktivieren alle Registrierungsendpunkte außer Intune SCEP und Certificate Master (für die Sie Berechtigungen explizit zuweisen müssen). #### Vertrauen Sie Daten vom Client niemals Als PKI-Software ist die Entscheidung, welchen Daten zu vertrauen ist, der Kern jeder Entscheidung. Schließlich besteht der Zweck von Zertifikaten und ihren Registrierungsprotokollen darin, zu entscheiden, welchen Daten zu vertrauen ist. #### Gehen Sie von einem Sicherheitsvorfall aus Unsere auf Azure Monitor basierende Protokollierung ermöglicht die Überwachung der Vorgänge von SCEPman. 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 Services ermöglicht die Nutzung der Microsoft Defender for Cloud-Dienste, z. B. Defender for App Service. #### Erzwingen Sie das Prinzip der geringsten Rechte 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). #### Minimieren Sie den Schadensradius 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 Bereinigungsschutz](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) mit einem [nicht exportierbaren privaten Schlüssel mit HSM-Unterstützung](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 kein böswilliger Administrator oder 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 selbst ein Global Admin kann ihn vor Ablauf einer 90-Tage-Frist nicht endgültig löschen. Der nicht exportierbare, HSM-gestützte CA-Schlüssel stellt sicher, dass selbst ein Angreifer mit den höchstmöglichen Berechtigungen den CA-Schlüssel nicht stehlen kann. #### Minimieren Sie die Angriffsfläche Wir stellen sicher, dass nur diejenigen Schnittstellen freigegeben werden, die für die vom Kunden durchgeführten Operationen erforderlich sind. Wenn ein SCEP-Endpunkt nicht konfiguriert ist, werden SCEP-Anfragen nicht einmal verarbeitet. Mithilfe von [Private Endpoints](/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. #### Berücksichtigen Sie Missbrauchsszenarien Wenn SCEPman eine autorisierte Certificate Signing Request (CSR) erhält, unterliegt sie dennoch mehreren konfigurierbaren Einschränkungen. Beispielsweise kann die Laufzeit niemals den [konfigurierten maximalen Gültigkeitszeitraum](/de/scepman-konfiguration/application-settings/certificates.md#appconfig-validityperioddays)selbst wenn dies angefordert wurde. #### Sicherheitsereignisse überwachen und darauf alarmieren Wenn SCEPman Sicherheitsereignisse erkennt, protokolliert es sie auf Warnungs- oder Fehlerstufe. Durch die Integration mit Azure Monitor und Azure Event Hub können Sie [Warnungen konfigurieren](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) oder Ereignisse mit einem SIEM analysieren. ### 3. Wie sichern Sie Ihre eigene Entwicklungsumgebung ab? Als Teil eines Unternehmens, das auch CSOC-Services und Sicherheitsberatung anbietet, haben wir hohe Sicherheitsstandards für unsere Geräte, Prozesse und das Sicherheitsbewusstsein der Nutzer. Wir sind Teil von Microsoft MISA, ISO 27001-zertifiziert und Microsoft Partner of the Year mit unseren Sicherheitsangeboten. Unsere Quellcode-Repositories verfügen über 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 verringern. ### 4. Ist SCEPman Teil eines Bug-Bounty-Programms? Nein. ### 5. Welche QA-Maßnahmen sind implementiert? * Wir stellen SCEPman in einem internen, Beta- und Produktionskanal bereit * Jede Produktionsfreigabe muss zunächst 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 * Code-Analyse durch Drittanbieter, z. B. Sonar, Dependabot und andere ### 6. Führen Sie regelmäßig Penetrationstests durch? Nicht in Form eines klassischen Penetrationstests von SCEPman. Stattdessen unterzieht sich glueckkanja AG einer jährlichen Red-Team-Bewertung durch einen unabhängigen externen Spezialisten, die über einen klassischen Penetrationstest hinausgeht (siehe [Lässt glueckkanja seine Sicherheit von externen Experten testen?](#id-2.-does-glueckkanja-have-its-security-tested-by-external-experts)). Im Rahmen unserer Secure Development Practices setzen wir Tools ein (z. B. statische Codeanalyse), die die Codebasis nach CVEs und anderen gängigen Exploits (einschließlich Abhängigkeiten wie Bibliotheken von Drittanbietern) durchsuchen, 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 nutzen wir „Penetration Test-as-a-Service“-Tools von Drittanbietern. Im ersten Fall sehen wir einen inhärenten Interessenkonflikt. Im zweiten Fall sehen wir, da typische Penetrationstest-Dienste oft einfach die freigegebenen Endpunkte gegen CVEs und andere bekannte Exploits prüfen, keinen Vorteil gegenüber den Prüfungen, die wir bereits mithilfe statischer Codeanalyse durchführen. Stattdessen setzen wir auf einen ganzheitlichen Ansatz: 2026 simulierte ein unabhängiges Red Team einen realistischen, fortgeschrittenen Angriff auf glueckkanja AG, ausdrücklich einschließlich Angriffswegen in Kundenumgebungen und Supply-Chain-Angriffen. Anstatt isolierte Endpunkte zu testen, bewertet diese Prüfung vollständige Angriffspfade in unserer Organisation, was wir für die Sicherheit unserer Kunden als deutlich aussagekräftiger ansehen. Wir wiederholen diese Bewertung jährlich. Wenn Sie eigene 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.scepman.com/de/sonstiges/security-faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.