# Sécurité et confidentialité ## Traitement des données et autorisations ### 1. Quelles données sont traitées par SCEPman ? SCEPman traite des certificats X.509 en utilisant les protocoles SCEP et EST pour l’émission, ainsi que les protocoles OCSP et CRL pour valider ces certificats. Chaque **certificat d’appareil** doit contenir un identifiant unique de l’appareil. En outre, pour les **certificats utilisateur**, nous recommandons de configurer les valeurs suivantes dans le certificat : * Nom d’utilisateur * E-mail * UPN Microsoft Entra ID (Azure AD) * Identifiant de l’appareil SCEP, EST, OCSP et CRL s’appuient sur HTTP(S), c.-à-d. que les données suivantes sont visibles pour SCEPman : * Adresse IP du client + 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 publiques/privées de l’AC SCEPman et le 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 challenges 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 compte de stockage Azure - *à l’exception des clés privées*. * Pour les données pouvant faire partie d’un certificat, veuillez vous référer à [question 1](#id-1.-which-data-is-processed-by-scepman). * Ce comportement peut être [désactivé](https://docs.scepman.com/fr/configuration-scepman/application-settings/basics#appconfig-enablecertificatestorage). * Lors de l’émission de certificats via Certificate Master, le demandeur (UPN Microsoft Entra ID (Azure AD)) 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é (UPN Microsoft Entra ID (Azure AD)) sont stockés. 3. Journalisation Selon la configuration de SCEPman par le client, la journalisation peut être activée. Selon les paramètres de verbosité des journaux du client, les journaux peuvent contenir n’importe quelles données que SCEPman traite. Le client configure l’emplacement de stockage des journaux. 4. Log Analytics Workspace externe SCEPman envoie toujours une quantité limitée de **non secrètes** et **non personnelles** données à notre Log Analytics Workspace (LAW). Ces données sont utilisées à des fins de * licence. * Assurance qualité (par exemple, la surveillance mondiale des exceptions 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 n’ **envoie aucune donnée personnelle** à notre LAW. Selon les paramètres de journalisation, les informations de débogage et autres sont transmises au LAW de glueckkanja-gab AG. Nos ingénieurs du support peuvent demander à [activer](https://docs.scepman.com/fr/configuration-scepman/application-settings/basics#appconfig-remotedebug) la fonction de débogage à distance de l’administrateur client afin d’aider à résoudre les demandes de support. Dans de tels cas, des informations relatives à la demande de certificat peuvent être envoyées à notre compte LAW, pouvant éventuellement (le client décide quelles informations font partie du certificat) contenir des données personnelles telles que : * Nom d’utilisateur * E-mail * UPN Microsoft Entra ID (Azure AD) * Identifiant de l’appareil Nous supprimons périodiquement **tous** 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 réalisé sous la forme d’une application Azure (basée sur un modèle de solution), c’est-à-dire qu’il est déployé dans le tenant Azure du client. En tant que tel, la souveraineté des données, y compris le choix de la géolocalisation du centre de données d’hébergement, relève des mains et des préférences du client. #### Log Analytics Workspace 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 contrôle des licences est situé dans **le centre de données Azure West Europe** . ### 4. À quelles autorisations du tenant l’administrateur doit-il consentir ? SCEPman utilise des identités managées pour mettre en œuvre un modèle d’autorisations sécurisé dans votre tenant Azure. #### Intune 1. Intune `scep_challenge_provider`:\ \ Avec cette autorisation, SCEPman peut transmettre la demande de certificat à Intune et vérifier qu’elle provient d’Intune, ce qui ajoute un niveau de sécurité supplémentaire. 2. Microsoft Graph `Directory.Read.All`:\ \ Avec cette autorisation, SCEPman peut interroger Microsoft Entra ID (Azure AD) afin de vérifier si le certificat utilisateur ou appareil provient d’un utilisateur ou appareil autorisé. 3. Microsoft Graph `DeviceManagementManagedDevices.Read.All` et `DeviceManagementConfiguration.Read.All`:\ \ Avec ces autorisations, SCEPman demande la liste des certificats émis via Intune lors de l’utilisation de la [fonction de révocation EndpointList](https://docs.scepman.com/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory). 4. Microsoft Graph `IdentityRiskyUser.Read.All`:\ \ Cette autorisation permet à SCEPman de [révoquer automatiquement les certificats utilisateur si le risque utilisateur AAD dépasse un seuil configuré](https://docs.scepman.com/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-userriskcheck). #### Jamf Pro 1. Autorisations de lecture sur les utilisateurs, ordinateurs et appareils\ \ Avec ces autorisations, SCEPman peut interroger Jamf Pro afin de vérifier si le certificat utilisateur ou appareil provient d’un utilisateur ou appareil autorisé. #### Certificate Master 1. Microsoft Graph `User.Read` (via l’enregistrement d’application) :\ \ Avec cette autorisation, Certificate Master détermine qui demande ou révoque manuellement un certificat. 2. Micrsoft Graph `DeviceManagementManagedDevices.Read.All` et `DeviceManagementConfiguration.Read.All` (en tant qu’identité managée) :\ \ Avec 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 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, des autres MDM génériques. 2. API REST d’enrôlement * Permet à Certificate Master de demander des certificats au service principal de SCEPman. * Permet à des applications personnalisées de demander des certificats au service principal de SCEPman. 3. Point de terminaison EST * Appelé pour les demandes de réinscription simple EST. Peut être activé via la configuration. * Appelé pour les demandes d’inscription simple 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 rendue disponible via ce point de terminaison. * Peut être activé via [la configuration](https://docs.scepman.com/fr/configuration-scepman/application-settings/crl). 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 base sur l’état de SCEPman (aucun secret). * Lecture seule. * Peut être désactivé via [la configuration](https://docs.scepman.com/fr/configuration-scepman/application-settings/basics#appconfig-anonymoushomepageaccess). 8. point de terminaison de supervision SCEPman * Contrôles d’intégrité : contrôle d’intégrité intégré d’App Service, supervision de Traffic Manager, supervision 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 supervision Certificate Master * Contrôles d’intégrité : contrôle d’intégrité intégré d’App Service ### 6. Comment les points de terminaison de la question 5 sont-ils protégés ? #### Service principal SCEPman 1. Point(s) de terminaison SCEP * Intune : protégé via l’API Intune Challenge ([Microsoft Docs](https://docs.microsoft.com/en-us/mem/intune/protect/scep-libraries-apis)) * Jamf Pro, DC, autres MDM génériques : protégés par un challenge SCEP statique. Configurable par le client. Peut être stocké dans Azure Key Vault. 2. API REST d’enrôlement * Authentification intégrée Microsoft Entra ID (Azure AD). 3. Point de terminaison EST * Simple re-enroll : authentification par certificat. * Simple enroll : 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 supervision SCEPman * Aucune protection. #### Certificate Master 1. Portail web Certificate Master * Authentification intégrée Microsoft Entra ID (Azure AD). * Microsoft Entra ID (Azure AD) [Affectations de rôles](https://docs.scepman.com/fr/configuration-scepman/rbac). 2. point de terminaison de supervision Certificate Master * Aucune protection. ### 7. Quels ports et protocoles sont utilisés par les points de terminaison de la question 6 ? **Service principal 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’enrôlement * 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 les services externes. 7. Page d’accueil de SCEPman * HTTPS (TCP / 443) 8. point de terminaison de supervision SCEPman * HTTPS (TCP / 443) #### Certificate Master 1. Portail web Certificate Master * HTTPS (TCP / 443) 2. point de terminaison de supervision 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 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 ? * Identifiants de connexion : dépendent des politiques Microsoft Entra ID (Azure AD) configurées dans le tenant du client. * Challenge SCEP statique : les utilisateurs autorisés peuvent accéder au challenge. ## 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 de manière sécurisée dans Azure Key Vault (version >= 1.7). * Si les données de configuration ne sont pas stockées dans Azure Key Vault, elles sont stockées sur AppService (chiffrement BitLocker) * Toute donnée de configuration (Azure Key Vault, App Services) ne peut être accessible que par des utilisateurs autorisés disposant des autorisations 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 pas être 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 (paramètre 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 compte de stockage Azure. Ainsi, la protection repose sur les mécanismes intégrés à Azure. * En particulier, Azure utilise un accès basé sur les rôles pour gérer les autorisations aux données. * Azure Storage utilise le chiffrement de base de données et prend en charge les clés gérées par le client. * Le compte de stockage Azure utilise un point de terminaison privé et ne peut être accessible qu’à partir de SCEPman (paramètre par défaut pour les installations SCEPman de version 2.8 et supérieure). #### Journaux * Les journaux sont stockés dans un espace de travail Log Analytics. * Log Analytics utilise le chiffrement de 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 requêtes 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 doivent pas être chiffrées afin d’éviter les problèmes 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 utilise-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. Par ailleurs, les technologies suivantes sont utilisées pour reconnaître 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 de l’appareil Microsoft Entra ID (Azure AD) * Points de terminaison privés Comme SCEPman est construit sur des composants Azure, vous pouvez utiliser des outils Microsoft Defender (MD) for Cloud tels que 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, associés à leurs clés privées, authentifient les appareils ou les 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 niveau élevé de sécurité nécessite également un niveau élevé de facilité d’utilisation, car des processus compliqués et peu transparents ont une surface d’attaque plus large et un plus grand potentiel d’erreur humaine. Bien que SCEPman offre de nombreuses options de configuration si nécessaire, nous avons cherché à utiliser des paramètres par défaut raisonnables et sûrs 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. Il vous suffit de [supprimer l’objet Intune correspondant](https://docs.scepman.com/fr/configuration-scepman/device-directories) ou l’objet Jamf Pro. Selon vos processus de mise hors service des appareils, vous pouvez également configurer pour [révoquer les certificats lorsqu’un effacement est déclenché](https://docs.scepman.com/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationrevokecertificatesonwipe), lorsque [Intune demande la révocation](https://docs.scepman.com/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationdevicedirectory), en fonction de [la conformité de l’appareil](https://docs.scepman.com/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationcompliancecheck) ou [du niveau de risque utilisateur](https://docs.scepman.com/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationuserriskcheck), ou vous pouvez révoquer manuellement des certificats individuels via le composant Certificate Master. [Les certificats créés manuellement](https://docs.scepman.com/fr/gestion-des-certificats/certificate-master) 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 tailles de clés 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 est l’algorithme et la taille 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és 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 ne prend en charge que 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 elle doit être 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 pour l’AC racine dans Azure Key Vault de votre tenant. 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 (y compris aucun administrateur) ne peut utiliser le certificat, mais un administrateur de l’abonnement peut accorder des autorisations supplémentaires. * Par conséquent, 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 toujours de leur propre paire de clés et donc d’un autre certificat d’AC auquel votre passerelle VPN n’accordera pas sa confiance. ## Azure CIS Cette section couvre les questions qui se posent lors de la définition des politiques de cyberdéfense pour votre environnement Azure ou du travail avec des cadres de bonnes pratiques tels que le [CIS Microsoft Azure Foundations Benchmark](https://www.cisecurity.org/benchmark/azure/). ### Comptes de stockage #### 1. Peut-on `Autoriser l’accès public aux blobs` être désactivé ? *Oui*, ce qui est en fait déjà le paramètre par défaut pour les nouvelles installations SCEPman. ### App Services #### 2. TLS : Peut-on `Mode du certificat client` être défini sur `Require`? *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). Ce n’est toutefois pas un problème de sécurité, car le protocole SCEP utilise ses propres mécanismes d’authentification via le challenge SCEP. SCEPman a donc besoin d’une exemption des politiques imposant le TLS mutuel. Le `Mode du certificat client` doit être défini sur `Ignore` 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. Lors de la modification de ce paramètre - à vos risques et périls - veuillez considérer que SCEPman n’est pas le seul à devoir prendre en charge la version HTTP la plus récente. Les différents types de clients doivent également prendre en charge cette version d’HTTP, c’est-à-dire les clients SCEP intégrés au système des systèmes Windows, macOS, iOS, iPadOS, ceux des appareils IoT, les clients OCSP sur ces mêmes plateformes, mais aussi les NAC de différents fournisseurs. #### 4. Peut-on `HTTPS Only` être activé ? *Non (pas pour le service App Service SCEPman)*, 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 couramment fourni via HTTP que via 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’appliance ne peut pas établir la connexion TLS au point de terminaison OCSP, car le certificat du serveur doit d’abord être vérifié via OCSP. Cela n’apporte 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 Only`** ne peut pas être activé pour le service App Service SCEPman, mais il devrait être activé pour le service App Service Certificate Master. #### 5. La version TLS inbound minimale peut-elle être définie sur 1.3 ? *Non* pour le service App Service SCEPman, 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 certains cas (réinscription simple EST), donc si vous définissez TLS sur 1.3, vous ne pourrez pas renouveler vos certificats à l’aide d’EST. En outre, 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](https://docs.scepman.com/fr/troubleshooting/general#some-windows-machines-do-not-enroll-or-renew-certificates)). **Remarque :** Comme seuls les navigateurs accèdent au service App Service Certificate Master, il est recommandé pour Certificate Master de définir la version TLS inbound minimale sur 1.3. ## RGPD et résidence des données ### 1. Les données quittent-elles l’Europe ? * Cela dépend du choix du client quant au 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,
Industrial Estate 18, Dublin,
Ireland

| Voir [ici](https://docs.scepman.com/fr/deploiement-scepman/deployment-guides/enterprise-guide-1#overview-azure-resource). | | GitHub Inc (filiale de Microsoft Corporation) | référentiel 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

| Référentiel de code, pipeline CI/CD, stockage binaire | ## Pratiques de développement sécurisées ### 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 le développement de nos produits.](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf) ### 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 repose sur les [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 potentielles STRIDE au sein d’une équipe hétérogène de développeurs, de nos [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)et consultants PKI, ainsi que de l’équipe 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, au lieu de réinventer la roue. Par exemple, nous utilisons Legion of the Bouncy Castle C# pour travailler avec les normes 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 des serveurs web, Azure Monitor pour la journalisation, et Azure Storage comme moteur de base de données. #### La configuration sécurisée est le paramètre par défaut Afin de minimiser le risque d’erreur humaine, nous concevons les produits de manière à ce que vous disposiez d’une configuration sécurisée si vous utilisez les valeurs 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’inscription à l’exception de SCEP Intune et Certificate Master (pour lesquels vous devez explicitement attribuer des autorisations). #### Ne jamais faire confiance aux données du client En tant que logiciel PKI, décider quelles données faire confiance est au cœur même de chaque décision. Après tout, le but des certificats et de leurs protocoles d’inscription est de déterminer quelles données faire confiance. #### Supposer une compromission Notre journalisation basée sur Azure Monitor permet de surveiller les 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. #### Imposer le moindre privilège Notre modèle RBAC pour Certificate Master permet d’attribuer aux utilisateurs uniquement les autorisations dont ils ont réellement besoin. SCEPman utilise des identités managées qui n’ont que [les autorisations nécessaires au fonctionnement](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to). #### Minimiser 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 la fonctionnalité Key Vault[ 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 — elle peut être restaurée en quelques minutes pour reprendre le fonctionnement normal, et même un administrateur global ne peut pas la purger avant une période de 90 jours. La clé d’AC protégée par HSM et non exportable garantit que même un attaquant disposant des privilèges les plus élevés possibles ne peut pas voler la clé de l’AC. #### Minimiser la surface d’attaque Nous veillons à n’exposer que les interfaces nécessaires au fonctionnement pour le 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](https://docs.scepman.com/fr/configuration-azure/private-endpoints), nous veillons à ce que deux services dont dépend SCEPman, Azure Key Vault et Azure Storage, ne soient pas accessibles depuis Internet. #### Prendre en compte les cas d’abus Lorsque SCEPman reçoit des demandes de signature de certificat autorisées (CSR), il reste soumis à plusieurs restrictions configurables. Par exemple, la durée de vie ne peut jamais dépasser la [période de validité maximale configurée](https://docs.scepman.com/fr/configuration-scepman/application-settings/certificates#appconfig-validityperioddays), même si cela a été demandé. #### Surveiller et alerter sur les événements de sécurité Si SCEPman détecte des événements de sécurité, ils seront consignés comme avertissement ou erreur dans les journaux. L’intégration avec Azure Monitor et Azure Event Hub facilite la [configuration d’alertes](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) ou l’analyse de ces événements de sécurité avec un SIEM. ### 3. Comment sécurisez-vous votre propre environnement de développement ? En tant qu’entreprise qui fournit également des services CSOC et des conseils en sécurité, nous avons des normes de sécurité élevées pour nos appareils, nos processus et la sensibilisation des 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 référentiels de code source disposent de règles de protection des branches et nous n’attribuons aux référentiels et aux pipelines de déploiement, pour les comptes de développeurs individuels, que les droits les plus limités 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 de QA sont en place ? * Nous proposons SCEPman via un canal interne, bêta et production * Chaque version de production doit d’abord passer par les canaux interne et bêta, en franchissant les étapes QA pertinentes dans le cadre de notre processus CI * Tests unitaires * Revue par les pairs * Tests d’intégration * Tests de charge * Tests basés sur l’expérience * Analyse de code par des tiers, par exemple Sonar, Dependabot, et d’autres ### 6. Réalisez-vous régulièrement des tests d’intrusion ? Non. Dans le cadre de nos pratiques de développement sécurisées, nous utilisons des outils (par exemple l’analyse statique du code) qui analysent la base de code à la recherche de CVE et d’autres exploits courants (y compris des dépendances telles que des bibliothèques tierces) susceptibles d’affecter la sécurité des points de terminaison exposés par SCEPman. Avant toute publication, tout résultat pertinent est évalué et remédié, afin de garantir que SCEPman reste exempt de toute vulnérabilité connue. Nous ne réalisons nous-mêmes aucun test d’intrusion et nous n’utilisons pas non plus d’outils tiers de type « Penetration Test-as-a-Service ». Pour les premiers, nous estimons qu’il existe un conflit d’intérêts inhérent. Pour les seconds, comme les services de tests d’intrusion typiques se contentent souvent de vérifier les points de terminaison exposés par rapport aux CVE et autres exploits connus, nous ne voyons aucune valeur ajoutée par rapport aux vérifications que nous effectuons déjà à l’aide de l’analyse statique du code. Si vous souhaitez effectuer vos propres tests d’intrusion, veuillez [nous contacter](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29) et nous faire part de vos besoins.