> 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/fr/autres/security-faq.md). # Sécurité et confidentialité Ce chapitre fournit un aperçu des questions fréquemment posées concernant la sécurité de l'information, la confidentialité et l'assurance qualité. ## Traitement des données et permissions ### 1. Quelles données sont traitées par SCEPman ? SCEPman traite les certificats X.509 en utilisant les protocoles SCEP et EST pour l'émission, et les protocoles OCSP et CRL pour valider ces certificats. Chaque **certificat d'appareil** doit contenir un identifiant d'appareil unique. En outre, pour **certificats utilisateur**, nous recommandons de configurer les valeurs suivantes dans le certificat : * Nom d'utilisateur * E-mail * Microsoft Entra ID (Azure AD) UPN * Identifiant d'appareil SCEP, EST, OCSP et CRL reposent sur HTTP(S), c'est-à-dire que les données suivantes sont visibles pour SCEPman : * Adresse IP cliente + port * User agent (informations sur le système d'exploitation et le navigateur) Certificate Master conserve une piste d'audit des activités des administrateurs (UPN). ### 2. Quelles données sont stockées de manière persistante par/pour le compte de SCEPman et comment ? 1. Configuration * Les données de configuration contiennent toujours la paire de clés publique/privée de l'AC SCEPman et son certificat, qui sont stockés de manière sécurisée dans Azure Key Vault. * En outre, les données de configuration peuvent contenir des secrets tels que des défis SCEP statiques ou des mots de passe. L'objectif de ces paramètres est expliqué dans la documentation SCEPman. * Tous les paramètres de configuration peuvent être stockés dans Azure Key Vault pour une sécurité renforcée. 2. Certificats émis * Tous les certificats émis sont stockés dans un Azure Storage Account - *à l'exception des clés privées*. * Pour les données qui peuvent faire partie d'un certificat, veuillez vous référer à [la question 1](#id-1.-which-data-is-processed-by-scepman). * Ce comportement peut être [désactivé](/fr/configuration-de-scepman/application-settings/basics.md#appconfig-enablecertificatestorage). * Lors de l'émission de certificats via Certificate Master, le demandeur (Microsoft Entra ID (Azure AD) UPN) est stocké. * Lors de la révocation de certificats via Certificate Master, l'état de révocation du certificat et l'identité de l'utilisateur qui l'a révoqué (Microsoft Entra ID (Azure AD) UPN) sont stockés. 3. Journalisation Selon la configuration de SCEPman par le client, la journalisation peut être activée. En fonction des paramètres de verbosité de journalisation du client, les journaux peuvent contenir toutes les données traitées par SCEPman. Le client configure l'emplacement de stockage des journaux. 4. Espace de travail Log Analytics externe SCEPman envoie toujours une quantité limitée de **non secrètes** et **non personnelles** données vers notre Log Analytics Workspace (LAW). Ces données sont utilisées pour * des fins de licence. * Assurance qualité (par exemple, surveiller les exceptions à l'échelle mondiale nous aide à reconnaître rapidement les problèmes généraux et répandus, ce qui nous permet de fournir rapidement une solution à nos clients et d'éviter ainsi des interruptions de service coûteuses). Par défaut, SCEPman ne **n'envoie aucune donnée personnelle** à notre LAW. Selon les paramètres de journalisation, les informations de débogage et autres sont transférées vers le LAW de glueckkanja-gab AG. Nos ingénieurs support peuvent demander à [activer](/fr/configuration-de-scepman/application-settings/basics.md#appconfig-remotedebug) la fonctionnalité de débogage à distance à l'administrateur du client dans le cadre du traitement des demandes de support. Dans ce cas, des informations sur la demande de certificat peuvent être envoyées à notre compte LAW, contenant éventuellement (le client décide quelles informations font partie du certificat) des données personnelles telles que : * Nom d'utilisateur * E-mail * Microsoft Entra ID (Azure AD) UPN * Identifiant d'appareil Nous supprimons périodiquement **toutes les** données journalisées à un intervalle de * 30 jours ### 3. Où (géographiquement) SCEPman traite-t-il et stocke-t-il les données ? Par conception, SCEPman est implémenté sous forme d'application Azure (basée sur un modèle de solution), c'est-à-dire déployé dans le locataire Azure du client. Ainsi, la souveraineté des données, y compris le choix de la géolocalisation du centre de données d'hébergement, relève de la décision et de la préférence du client. #### Espace de travail Log Analytics externe Le LAW externe que nous utilisons pour collecter (par défaut **non personnelles** et **non secrètes**) des informations de télémétrie à des fins de gestion de licence est situé dans **Europe de l'Ouest d'Azure** centre de données. ### 4. Quelles permissions du locataire l'administrateur doit-il approuver ? SCEPman s'appuie sur les Managed Identities pour mettre en œuvre un modèle d'autorisation sécurisé dans votre locataire Azure. #### Intune 1. Intune `scep_challenge_provider` :\n\nAvec cette autorisation, SCEPman peut transmettre la demande de certificat à Intune et vérifier que la demande de certificat provient d'Intune, ce qui ajoute une couche de sécurité supplémentaire. 2. Microsoft Graph `Directory.Read.All` :\n\nAvec cette autorisation, SCEPman peut consulter Microsoft Entra ID (Azure AD) afin de vérifier si le certificat utilisateur ou d'appareil provient d'un utilisateur ou d'un appareil autorisé. 3. Microsoft Graph `DeviceManagementManagedDevices.Read.All` et `DeviceManagementConfiguration.Read.All` :\n\nAvec ces autorisations, SCEPman demande la liste des certificats émis via Intune lors de l'utilisation de la [fonctionnalité de révocation EndpointList](/fr/configuration-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory). 4. Microsoft Graph `IdentityRiskyUser.Read.All` :\n\nCette autorisation permet à SCEPman de [révoquer automatiquement les certificats utilisateur si le risque utilisateur AAD dépasse un seuil configuré](/fr/configuration-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-userriskcheck). #### Jamf Pro 1. Autorisations de lecture sur les utilisateurs, les ordinateurs et les appareils\n\nAvec ces autorisations, SCEPman peut consulter Jamf Pro afin de vérifier si le certificat utilisateur ou d'appareil provient d'un utilisateur ou d'un appareil autorisé. #### Certificate Master 1. Microsoft Graph `User.Read` (via l'enregistrement d'application) :\n\nAvec cette autorisation, Certificate Master détermine qui demande ou révoque manuellement un certificat. 2. Microsoft Graph `DeviceManagementManagedDevices.Read.All` et `DeviceManagementConfiguration.Read.All` (en tant que Managed Identity) :\n\nAvec ces autorisations, Certificate Master demande la liste des certificats émis via Intune. Les administrateurs peuvent examiner et révoquer manuellement ces certificats. ### 5. Quels points de terminaison accessibles de l'extérieur SCEPman expose-t-il ? #### **Service principal de SCEPman** 1. point(s) de terminaison SCEP * Appelé pour les demandes SCEP. * Selon la configuration, SCEPman peut exposer plusieurs points de terminaison SCEP pour Intune, Jamf Pro, les DC, d'autres MDM génériques. 2. API REST d'inscription * Permet à Certificate Master de demander des certificats au service principal de SCEPman. * Permet aux applications personnalisées de demander des certificats au service principal de SCEPman. 3. point de terminaison EST * Appelé pour les demandes simples de réinscription EST. Peut être activé via la configuration. * Appelé pour les demandes d'inscription simples EST. 4. point de terminaison OCSP * Appelé pour les demandes OCSP. 5. Point de distribution des certificats (CDP) * La liste de révocation des certificats (CRL) est mise à disposition via ce point de terminaison. * Peut être activé via [la configuration](/fr/configuration-de-scepman/application-settings/crl.md). 6. API de validation * Permet à Certificate Master d'évaluer l'état de révocation automatique d'un certificat. 7. Page d'accueil de SCEPman * Affiche publiquement les informations de statut de base de SCEPman (aucun secret). * Lecture seule. * Peut être désactivé via [la configuration](/fr/configuration-de-scepman/application-settings/basics.md#appconfig-anonymoushomepageaccess). 8. point de terminaison de sonde SCEPman * Vérifications de santé : vérification de santé intégrée d'App Service, sondage de Traffic Manager, sondage d'Application Gateway. #### Certificate Master 1. Portail web Certificate Master * Émettre manuellement des certificats serveur et signer des CSR. * Révoquer manuellement les certificats émis via Certificate Master. * Afficher la liste des certificats émis manuellement. 2. point de terminaison de sonde Certificate Master * Vérifications de santé : vérification de santé intégrée d'App Service ### 6. Comment les points de terminaison de la question 5 sont-ils protégés ? #### Service principal de SCEPman 1. point(s) de terminaison SCEP * Intune : protégé via l'API de défi Intune ([Microsoft Docs](https://docs.microsoft.com/en-us/mem/intune/protect/scep-libraries-apis)) * Jamf Pro, DC, autres MDM génériques : protégé par un défi SCEP statique. Configurable par le client. Peut être stocké dans Azure Key Vault. 2. API REST d'inscription * Authentification intégrée Microsoft Entra ID (Azure AD). 3. point de terminaison EST * Réinscription simple : authentification par certificat. * Inscription simple : authentification intégrée Microsoft Entra ID (Azure AD). 4. point de terminaison OCSP * Aucune protection requise. 5. Point de distribution des certificats (CDP) * Jeton d'accès requis. 6. API de validation * Authentification intégrée Microsoft Entra ID (Azure AD). 7. Page d'accueil de SCEPman * Aucune protection, mais peut être désactivée. 8. point de terminaison de sonde SCEPman * Aucune protection. #### Certificate Master 1. Portail web Certificate Master * Authentification intégrée Microsoft Entra ID (Azure AD). * Microsoft Entra ID (Azure AD) [Attributions de rôles](/fr/configuration-de-scepman/rbac.md). 2. point de terminaison de sonde Certificate Master * Aucune protection. ### 7. Quels ports et protocoles sont utilisés par les points de terminaison de la question 6 ? **Service principal de SCEPman** 1. point(s) de terminaison SCEP * Intune : HTTPS (TCP / 443) * Jamf Pro, DC, autres MDM génériques : HTTPS (TCP / 443) 2. API REST d'inscription * HTTPS (TCP / 443) 3. point de terminaison EST * HTTPS (TCP / 443) 4. point de terminaison OCSP * HTTP (TCP / 80) 5. Point de distribution des certificats (CDP) * HTTP (TCP / 80) 6. API de validation * Non utilisé par des services externes. 7. Page d'accueil de SCEPman * HTTPS (TCP / 443) 8. point de terminaison de sonde SCEPman * HTTPS (TCP / 443) #### Certificate Master 1. Portail web Certificate Master * HTTPS (TCP / 443) 2. point de terminaison de sonde Certificate Master * HTTPS (TCP / 443) ## Identité ### 1. Existe-t-il des contrôles d'accès conditionnel / basés sur les rôles pour protéger SCEPman ? * Oui. L'ensemble complet des politiques RBAC de Microsoft Entra ID (Azure AD) peut être exploité. ### 2. Les informations d'identification d'accès peuvent-elles être récupérées ? Si oui, comment ? * Informations d'identification de connexion : cela dépend des stratégies Microsoft Entra ID (Azure AD) configurées dans le tenant du client. * Défi SCEP statique : les utilisateurs autorisés peuvent accéder au défi. ## Protection des données ### 1. Comment les *données au repos* sont-elles protégées contre les accès non autorisés ? #### Données de configuration * Les données de configuration peuvent être stockées en toute sécurité dans Azure Key Vault (version >= 1.7). * Si le choix est fait de ne pas stocker les données de configuration dans Azure Key Vault, elles sont stockées sur App Service (chiffrement BitLocker). * Les données de configuration (Azure Key Vault, App Services) ne peuvent être consultées que par des utilisateurs autorisés disposant des permissions Azure appropriées. #### Clés cryptographiques * La clé privée de l'AC est stockée de manière sécurisée dans Azure Key Vault ([HSM validé FIPS 140](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#compliance) par défaut). * La clé privée ne peut être ni lue ni exportée. * La clé privée est protégée contre la suppression par des administrateurs malveillants ([la protection contre la purge et la suppression réversible](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) sont activées par défaut). * Azure Key Vault utilise un point de terminaison privé et ne peut être accessible qu'à partir de SCEPman (par défaut pour les installations SCEPman de version 2.8 et supérieure). #### Base de données des certificats * La base de données utilise le service Table d'un Azure Storage Account. La protection repose donc sur les mécanismes intégrés à Azure. * En particulier, Azure utilise un accès basé sur les rôles pour gérer les permissions aux données. * Azure Storage utilise le chiffrement de la base de données et prend en charge les clés gérées par le client. * L'Azure Storage Account utilise un point de terminaison privé et ne peut être accessible qu'à partir de SCEPman (par défaut pour les installations SCEPman de version 2.8 et supérieure). #### Journaux * Les journaux sont stockés dans un Log Analytics Workspace. * Log Analytics utilise le chiffrement de la base de données et prend en charge les clés gérées par le client. ### 2. Comment les *données en transit* sont-elles protégées contre les accès non autorisés ? * SCEP : * Utilise TLS par défaut (TLS 1.2 minimum - les politiques Microsoft s'appliquent). * Les demandes SCEP sont chiffrées avec le certificat de l'AC et signées avec le certificat client. * Les réponses SCEP sont chiffrées avec le certificat client et signées avec le certificat de l'AC. * OCSP : * Les requêtes OCSP ne devraient pas être chiffrées afin d'éviter le problème de l'œuf et de la poule. * Les réponses OCSP sont signées par le certificat de l'AC. * API REST d'inscription et EST : * Impose TLS (TLS 1.2 minimum - les politiques Microsoft s'appliquent). * Portail web Certificate Master : * Impose TLS (TLS 1.2 minimum - les politiques Microsoft s'appliquent). * Communication entre les composants Azure de SCEPman : * TLS (TLS 1.2 minimum - les politiques Microsoft s'appliquent). ## Sécurité dès la conception ### 1. SCEPman emploie-t-il une stratégie de défense en profondeur ? #### Composants Azure La philosophie de conception de SCEPman suit l'approche consistant à minimiser son exposition aux menaces de sécurité externes en réduisant les interfaces externes au minimum requis. En outre, les technologies suivantes sont utilisées pour détecter et atténuer les menaces internes et externes à différents niveaux : * Key Vault * App Insights * Vérification de l'inscription des appareils Intune * Vérification d'appareil Microsoft Entra ID (Azure AD) * Points de terminaison privés Comme SCEPman est construit sur des composants Azure, vous pouvez utiliser Microsoft Defender (MD) for Cloud, par exemple MD for App Service, MD for Storage ou MD for Key Vault. #### Validité des certificats En tant que PKI cloud, SCEPman est responsable de l'émission et de la révocation des certificats numériques. Ces certificats, conjointement avec leurs clés privées, authentifient des appareils ou des utilisateurs et donnent accès à d'autres ressources. Par conséquent, la sécurité des processus d'émission et de révocation des certificats est un objectif de conception très important. Un haut niveau de sécurité nécessite également un haut niveau de facilité d'utilisation, car des processus complexes et opaques ont une surface d'attaque plus grande et un risque d'erreur humaine plus élevé. Bien que SCEPman offre de nombreuses options de configuration si nécessaire, nous avons cherché à utiliser des valeurs par défaut raisonnables et sécurisées partout où cela était possible. Ainsi, si une clé privée est compromise, SCEPman peut révoquer le certificat correspondant en temps réel. Pour les certificats inscrits via Intune et Jamf Pro, SCEPman le fait automatiquement dès que des contre-mesures courantes, non spécifiques à SCEPman, sont prises contre l'attaque. Vous devez simplement [supprimer l'objet Intune correspondant](/fr/configuration-de-scepman/device-directories.md) ou l'objet Jamf Pro. Selon vos processus de retrait des appareils, vous pouvez également configurer [la révocation des certificats lorsqu'un effacement est déclenché](/fr/configuration-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationrevokecertificatesonwipe), lorsque [Intune demande la révocation](/fr/configuration-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationdevicedirectory), selon [la conformité de l'appareil](/fr/configuration-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationcompliancecheck) ou [le niveau de risque de l'utilisateur](/fr/configuration-de-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationuserriskcheck), ou vous pouvez révoquer manuellement des certificats individuels via le composant Certificate Master. [Certificats créés manuellement](/fr/gestion-des-certificats/certificate-master.md) nécessitent toujours une révocation manuelle. ### 2. Quelles technologies, piles, plateformes ont été utilisées pour concevoir SCEPman ? * `C#` * `ASP.NET Core MVC` * `Bouncy Castle Crypto API` * `Azure (App Service, Key Vault, Storage Account, Log Analytics)` ### 3. Quels algorithmes cryptographiques et quelles tailles de clé SCEPman prend-il en charge ? Pour les clés des certificats émis, Certificate Master n'impose aucune restriction lors de l'utilisation de la méthode CSR. Pour les certificats basés sur des formulaires, RSA avec 2048 ou 4096 bits sont les algorithmes et tailles de clé pris en charge. Pour les certificats inscrits via SCEP, Intune prend en charge des clés RSA jusqu'à 4096 bits sur toutes les plateformes, ce que SCEPman prend également en charge. Lors de l'utilisation du KSP de la plateforme (TPM), Windows prend en charge au maximum des clés RSA de 2048 bits. Lors de l'utilisation du point de terminaison SCEP statique, tous les algorithmes et tailles de clé courants sont pris en charge (en particulier ceux que [la bibliothèque cryptographique Bouncy Castle pour C# prend en charge](https://www.bouncycastle.org/csharp/)). Pour la clé de l'AC, SCEPman prend uniquement en charge RSA. RSA 4096 bits est la taille de clé par défaut. 4096 bits est actuellement le maximum pris en charge par Azure Key Vault. Si vous utilisez un certificat d'AC intermédiaire, vous pouvez également utiliser toute taille de clé prise en charge par Key Vault, mais il doit s'agir d'une clé RSA. Pour les scénarios qui ne nécessitent pas SCEP, une AC ECC peut être créée, prenant en charge les courbes elliptiques suivantes : P-256, secp256k1/P-256K, P-384, P-521. ### 4. L'AC créée par SCEPman est-elle unique ? Oui Détails : * SCEPman génère la paire de clés privée/publique de l'AC racine dans Azure Key Vault de votre locataire. Par conséquent, l'AC racine est unique à votre instance SCEPman personnelle et vous avez un contrôle total sur l'AC, son certificat et la clé privée correspondante. * L'accès à cette AC est contrôlé via des stratégies d'accès Key Vault que vous pouvez modifier si vous le souhaitez. Par défaut, seule votre propre instance SCEPman et personne d'autre (pas même un administrateur) ne peut utiliser le certificat, mais un administrateur de l'abonnement peut accorder des permissions supplémentaires. * Ainsi, les autres clients SCEPman ne pourront pas se connecter à votre VPN, quelle que soit la configuration de leur SCEPman. S'ils choisissent le même nom d'organisation, ils disposeront tout de même de leur propre paire de clés et donc d'un autre certificat d'AC que votre passerelle VPN ne fera pas confiance. ## Azure CIS Cette section couvre les questions qui se posent lors de la définition de politiques de cyberdéfense pour votre environnement Azure ou lors de l'utilisation de cadres de bonnes pratiques tels que le [CIS Microsoft Azure Foundations Benchmark](https://www.cisecurity.org/benchmark/azure/). ### Storage Accounts #### 1. Peut-on `Autoriser l'accès public aux blobs` être désactivé ? *Oui*, ce qui est en fait déjà la valeur par défaut pour les nouvelles installations de SCEPman. ### App Services #### 2. TLS : peut-on `Mode du certificat client` être défini sur `Exiger`? *Non*, car cela casserait la fonctionnalité de SCEPman. En effet, SCEPman inscrit des certificats client, de sorte que les clients ne disposent pas encore de certificats client pour s'authentifier (problème de l'œuf et de la poule). Cela ne pose toutefois pas de problème de sécurité, car le protocole SCEP utilise ses propres mécanismes d'authentification via le défi SCEP. SCEPman a donc besoin d'une exemption des politiques imposant le TLS mutuel. Le `Mode du certificat client` doit être défini sur `Ignorer` ou `Facultatif`. #### 3. Peut-on `version HTTP` être défini sur `2.0`? Bien que SCEPman devrait fonctionner avec toutes les versions HTTP disponibles, à ce jour, nous ne prenons en charge que la version par défaut `HTTP 1.1` - principalement en raison d'un manque de tests. Lorsque vous modifiez ce paramètre - à vos risques et périls - veuillez garder à l'esprit que ce n'est pas seulement SCEPman qui doit prendre en charge la version HTTP plus récente. Les différents types de clients doivent également prendre en charge cette version de HTTP, à savoir les clients SCEP intégrés au système d'exploitation de Windows, macOS, iOS, iPadOS, ceux des appareils IoT, les clients OCSP sur les mêmes plateformes, mais aussi les NAC de différents fournisseurs. #### 4. Peut-on `HTTPS uniquement` être activé ? *Non (pas pour SCEPman App Service)*, car cela casserait la fonctionnalité de répondeur OCSP de SCEPman en combinaison avec de nombreux clients OCSP et appareils de fournisseurs. OCSP est un protocole qui est plus souvent fourni via HTTP que HTTPS. L'une des raisons est que, si vous utilisiez TLS pour la vérification de la révocation des certificats (téléchargement des CRL ou OCSP), il pourrait y avoir un problème de l'œuf et de la poule, où le client ou l'appareil ne peut pas établir la connexion TLS vers le point de terminaison OCSP, car le certificat du serveur doit d'abord être vérifié via OCSP. Cela n'ajoute pas non plus beaucoup de sécurité, car les réponses OCSP sont de toute façon signées cryptographiquement et ne peuvent donc pas être usurpées. SCEPman a donc besoin d'une exemption des politiques imposant TLS. **Remarque :** **`HTTPS uniquement`** ne peut pas être activé pour le SCEPman App Service, mais il devrait être activé pour le Certificate Master App Service. #### 5. La version TLS minimale entrante peut-elle être définie sur 1.3 ? *Non* pour le SCEPman App Service, car TLS 1.3 ne prend pas en charge la renégociation. Cela signifie qu'une fois la connexion établie, le serveur ne peut pas demander au client de présenter un certificat client. Nous voulons que le client s'authentifie avec un certificat dans certaines circonstances (réinscription simple EST), donc si vous définissez TLS sur 1.3, vous ne pourrez pas renouveler vos certificats via EST. De plus, tous les clients SCEP ne prennent pas en charge TLS 1.3. Un exemple important est le client SCEP intégré à Windows 8, 10 et 11, qui à la date de 2025-07 ne prend pas en charge TLS 1.3 (il y aura une erreur côté client [lors de l'inscription SCEP](/fr/autres/troubleshooting/general.md#some-windows-machines-do-not-enroll-or-renew-certificates)). **Remarque :** Comme seuls les navigateurs accèdent au Certificate Master App Service, il est recommandé de définir la version TLS minimale entrante de Certificate Master sur 1.3. ## Conformité ### 1. glueckkanja est-elle certifiée ISO 27001 ? Oui. Le système de management de la sécurité de l'information (SMSI) de glueckkanja AG est certifié selon **ISO/IEC 27001:2022**. Le périmètre de la certification couvre : * Développement de produits * Services managés Vous pouvez consulter le certificat actuel [ici](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf). ### 2. glueckkanja fait-elle tester sa sécurité par des experts externes ? Oui. En 2026, glueckkanja AG a mandaté une société indépendante spécialisée en sécurité offensive pour mener une évaluation Red Team couvrant l'ensemble de notre entreprise. Nous avons délibérément choisi cette approche holistique plutôt qu'un test d'intrusion classique. Au lieu de vérifier des systèmes ou des points de terminaison individuels par rapport à des vulnérabilités connues, l'équipe Red Team a simulé une cyberattaque réaliste et avancée menée par un attaquant interne contre notre infrastructure informatique, en enchaînant les techniques comme le font les véritables adversaires. L'évaluation s'est concentrée sur : * l'identification de vulnérabilités à fort impact, * la cartographie de chemins d'attaque complets à travers notre environnement, * l'évaluation des vecteurs potentiels permettant d'obtenir un accès non autorisé aux environnements clients, * l'évaluation des vecteurs potentiels permettant de mener des attaques de la chaîne d'approvisionnement. Tous les constats ont été documentés avec des recommandations d'atténuation et sont traités dans le cadre de notre système de management de la sécurité de l'information certifié ISO 27001. Nous répéterons cette évaluation Red Team chaque année. ## RGPD et résidence des données ### 1. Les données quittent-elles l'Europe ? * Cela dépend du choix du client concernant le centre de données Azure dans lequel SCEPman et ses composants doivent être déployés. * Un déploiement complet de SCEPman, y compris tous ses composants, dans des centres de données Azure européens est possible. ### 2. Sur quels fournisseurs cloud tiers SCEPman s'appuie-t-il et pourquoi ? | Entreprise | Services | Contact | Objectif | | --------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | Microsoft Corporation | Services cloud (Azure) | Building 3, Carmanhall Road Sandyford,\nIndustrial Estate 18, Dublin,\nIrlande | Voir [ici](/fr/deploiement-de-scepman/deployment-guides/enterprise-guide-1.md#overview-azure-resource). | | GitHub Inc (filiale de Microsoft Corporation) | dépôt de code git, intégration, tests et automatisation des mises en production, stockage |

88 Colin P Kelly Jr St,

San Francisco,

CA 94107,

États-Unis

| Dépôt de code, pipeline CI/CD, stockage binaire | ## Pratiques de développement sécurisé ### 1. Qu'est-ce qui garantit que SCEPman est un logiciel sécurisé ? Notre développement logiciel repose sur le [Microsoft Security Development Lifecycle](https://www.microsoft.com/en-us/securityengineering/sdl/). L'application des pratiques SDL nous aide à créer un code et des déploiements sécurisés. Nous disposons de la [certification de sécurité de l'information ISO 27001 pour notre développement de produits](#id-1.-is-glueckkanja-iso-27001-certified). ### 2. Comment mettez-vous en œuvre les pratiques courantes de conception sécurisée ? Voici comment nous mettons en œuvre [les pratiques de conception sécurisée recommandées par le SDL](https://www.microsoft.com/en-us/securityengineering/sdl/practices/secure-by-design): #### Concevoir et modéliser les menaces en équipe Notre pratique de modélisation des menaces est basée sur le [recommandations du Tufts Security and Privacy Lab](https://tsp.cs.tufts.edu/tmnt/threatmodeling.html). Nous discutons des décisions de conception et des menaces STRIDE potentielles au sein d'une équipe hétérogène de développeurs, notre [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)ainsi que des consultants PKI et du personnel de support. #### Privilégier la sécurité de la plateforme au code personnalisé Dans la mesure du possible, nous utilisons les fonctionnalités de .NET ou des bibliothèques établies, de préférence open source, plutôt que de réinventer la roue. Par exemple, nous utilisons Legion of the Bouncy Castle C# pour travailler avec des standards de données cryptographiques. Nous nous appuyons également sur des services Azure comme Key Vault pour générer des clés cryptographiques, App Services pour l’hébergement du serveur web, Azure Monitor pour la journalisation et Azure Storage comme moteur de base de données. #### La configuration sécurisée est la valeur par défaut Afin de minimiser le risque d’erreur humaine, nous concevons les produits de sorte que vous disposiez d’une configuration sécurisée si vous utilisez les paramètres par défaut. Par exemple, nos [modèles ARM](https://github.com/scepman/install) et notre [fournisseur Terraform ](https://registry.terraform.io/modules/scepman/scepman/)définissent les paramètres de configuration pour utiliser des clés RSA de 4096 bits protégées par HSM, et ils désactivent tous les points de terminaison d’enrôlement sauf Intune SCEP et Certificate Master (pour lesquels vous devez attribuer explicitement des autorisations). #### Ne faites jamais confiance aux données provenant du client En tant que logiciel PKI, décider quelles données doivent être dignes de confiance est au cœur de chaque décision. Après tout, le but des certificats et de leurs protocoles d’enrôlement est de décider quelles données sont dignes de confiance. #### Supposer une compromission Notre journalisation basée sur Azure Monitor permet la surveillance des opérations de SCEPman. Elle s’intègre facilement aux systèmes SIEM comme Sentinel pour détecter les attaquants ayant réussi, par exemple s’ils ont réussi à inscrire des certificats sans autorisation. Notre intégration avec les services Azure permet d’exploiter les services Microsoft Defender for Cloud, par exemple Defender for App Service. #### Appliquer le principe du moindre privilège Le modèle RBAC de Certificate Master vous permet d’attribuer aux utilisateurs uniquement les autorisations dont ils ont besoin. SCEPman utilise des identités gérées qui n’ont que [les autorisations nécessaires au fonctionnement](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to). #### Réduire au minimum le rayon d’impact Nous nous efforçons de minimiser les dommages possibles en cas d’attaque réussie. Par exemple, notre installation par défaut active le Key Vault[ fonctionnalité de suppression réversible avec protection contre la purge](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) avec une [clé privée non exportable protégée par HSM](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#hsm-protected-keys) pour l’autorité de certification. La suppression réversible avec protection contre la purge garantit qu’aucun administrateur malveillant ni aucun compte administrateur compromis ne peut supprimer la clé privée de l’AC. La clé privée peut être restaurée en quelques minutes pour poursuivre les opérations normales, et même un Global Admin ne peut pas la purger avant un délai de 90 jours. La clé d’AC protégée par HSM et non exportable garantit qu’un attaquant disposant des privilèges les plus élevés possibles ne peut pas voler la clé d’AC. #### Réduire au minimum la surface d’attaque Nous veillons à n’exposer que les interfaces requises pour les opérations du client. Si un point de terminaison SCEP n’est pas configuré, les requêtes SCEP ne sont même pas traitées. En utilisant [Points de terminaison privés](/fr/configuration-azure/private-endpoints.md), nous nous assurons que deux services dont dépend SCEPman, Azure Key Vault et Azure Storage, ne sont pas accessibles depuis Internet. #### Prendre en compte les cas d’abus Lorsque SCEPman reçoit une demande de signature de certificat autorisée (CSR), elle reste soumise à plusieurs restrictions configurables. Par exemple, la durée de vie ne peut jamais dépasser la [durée de validité maximale configurée](/fr/configuration-de-scepman/application-settings/certificates.md#appconfig-validityperioddays), même si cela a été demandé. #### Surveiller les événements de sécurité et déclencher des alertes Lorsque SCEPman détecte des événements de sécurité, il les consigne au niveau Avertissement ou Erreur. Les intégrations Azure Monitor et Azure Event Hub vous permettent de [configurer des alertes](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) ou analyser les événements avec un SIEM. ### 3. Comment sécurisez-vous votre propre environnement de développement ? En tant que société qui fournit également des services CSOC et des conseils en sécurité, nous appliquons des normes de sécurité élevées à nos appareils, nos processus et la sensibilisation de nos utilisateurs. Nous faisons partie de Microsoft MISA, sommes certifiés ISO 27001 et Microsoft Partner of the Year pour nos offres de sécurité. Nos dépôts de code source appliquent des règles de protection des branches et nous n’attribuons aux dépôts et aux pipelines de déploiement, pour les comptes développeurs individuels, que les principes les moins nécessaires. Nous automatisons les tests et les déploiements lorsque cela est possible afin de réduire la surface d’attaque liée à des comptes compromis. ### 4. SCEPman fait-il partie d’un programme de bug bounty ? Non. ### 5. Quelles mesures d’assurance qualité sont en place ? * Nous fournissons SCEPman via un canal interne, bêta et de production * Chaque version de production doit d’abord passer par les canaux interne et bêta, en franchissant les étapes d’assurance qualité pertinentes dans le cadre de notre processus CI * Tests unitaires * Relecture par les pairs * Tests d’intégration * Tests de stress * Tests fondés sur l’expérience * Analyse de code tierce partie, par exemple Sonar, Dependabot et autres ### 6. Réalisez-vous régulièrement des tests de pénétration ? Pas sous la forme d’un test de pénétration classique de SCEPman. À la place, glueckkanja AG fait l’objet d’une évaluation Red Team annuelle réalisée par un spécialiste externe indépendant, qui va au-delà d’un test de pénétration classique (voir [La sécurité de glueckkanja est-elle testée par des experts externes ?](#id-2.-does-glueckkanja-have-its-security-tested-by-external-experts)). Dans le cadre de nos pratiques de développement sécurisé, nous utilisons des outils (par exemple l’analyse statique du code) qui parcourent la base de code à la recherche de CVE et d’autres exploits courants (y compris les dépendances telles que les bibliothèques tierces) susceptibles d’affecter la sécurité des points de terminaison exposés par SCEPman. Avant toute publication, toute découverte pertinente est évaluée et corrigée afin de garantir que SCEPman reste exempt de toute vulnérabilité connue. Nous ne réalisons nous-mêmes aucun test de pénétration et nous n’utilisons pas non plus d’outils tiers de type « Penetration Test-as-a-Service ». Pour le premier cas, nous y voyons un conflit d’intérêts inhérent. Pour le second, comme les services de test de pénétration typiques se contentent souvent de vérifier les points de terminaison exposés par rapport aux CVE et autres exploits connus, nous n’y voyons aucun avantage par rapport aux vérifications que nous effectuons déjà au moyen de l’analyse statique du code. Nous nous appuyons plutôt sur une approche holistique : en 2026, une Red Team indépendante a simulé une attaque réaliste et avancée contre glueckkanja AG, incluant explicitement des chemins d’attaque vers les environnements clients et des attaques sur la chaîne d’approvisionnement. Plutôt que de tester des points de terminaison isolés, cette évaluation examine des chemins d’attaque complets à travers notre organisation, ce que nous considérons comme bien plus pertinent pour la sécurité de nos clients. Nous répétons cette évaluation chaque année. Si vous souhaitez effectuer vos propres tests de pénétration, veuillez [nous contacter](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29) et nous faire part de vos besoins. --- # 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/fr/autres/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.