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 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 et les protocoles OCSP et CRL pour la validation de ces certificats. Chaque certificat d'appareil doit contenir un identifiant d'appareil unique. De plus, pour certificats d'utilisateur, nous recommandons de configurer les valeurs suivantes en tant que partie du certificat :

• Nom d'utilisateur

• E-mail

• Microsoft Entra ID (Azure AD) UPN

• Identifiant de l'appareil

SCEP, EST, OCSP et CRL reposent sur HTTP(S), c.-à-d. les données suivantes sont visibles par SCEPman :

• Adresse IP du client + port

• Agent utilisateur (informations sur le système d'exploitation et le navigateur)

Certificate Master conserve une piste d'audit sur l'activité des administrateurs (UPN).

2. Quelles données sont stockées de façon persistante par / pour SCEPman et comment ?

1. Configuration

   • Les données de configuration contiennent toujours la paire clé publique/privée et le certificat de la CA SCEPman, qui sont stockés de manière sécurisée dans Azure Key Vault.

   • De plus, les données de configuration peuvent contenir des secrets tels que des challenges SCEP statiques ou des mots de passe. L'objet de ces paramètres est expliqué dans la documentation de 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'exclusion des clés privées.

   • Pour les données qui pourraient faire partie d'un certificat, veuillez vous référer à question 1.

   • Ce comportement peut être désactivé.

   • 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 du niveau de détail de journalisation configuré par le client, les journaux peuvent contenir toutes les données que SCEPman traite. 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 confidentiel et non personnel données vers notre Log Analytics Workspace (LAW). Ces données sont utilisées pour

   • des fins de licence.

   • Assurance qualité (par ex. la surveillance des exceptions à l'échelle mondiale nous aide à reconnaître rapidement des problèmes généraux et répandus, nous permettant d'apporter des remèdes à nos clients rapidement, évitant 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 de support peuvent demander d' activer la fonctionnalité de débogage à distance par l'administrateur client pour aider aux enquêtes de dépannage. Dans de tels cas, des informations sur la requête 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 de l'appareil

   Nous supprimons périodiquement toutes les données consigné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é comme une application Azure (basée sur un modèle de solution), c.-à-d. il est déployé dans le locataire 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, est entre les mains et selon la préférence du client.

Espace de travail Log Analytics externe

Le LAW externe que nous utilisons pour collecter (par défaut non personnel et non confidentiel) des informations télémétriques à des fins d'application des licences est situé en Europe de l'Ouest d'Azure centre de données.

4. Quelles autorisations de locataire l'administrateur doit-il consentir ?

SCEPman exploite les identités gérées pour mettre en œuvre un modèle d'autorisations sécurisé dans votre locataire Azure.

Intune

1. Intune scep_challenge_provider: Avec 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 supplémentaire de sécurité.

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 d'un 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.

4. Microsoft Graph IdentityRiskyUser.Read.All: Cette autorisation permet à SCEPman de révoquer automatiquement les certificats utilisateur si le risque d'utilisateur AAD dépasse un seuil configuré.

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 d'un appareil autorisé.

Certificate Master

1. Microsoft Graph User.Read (via 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é géré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 depuis l'extérieur SCEPman expose-t-il ?

Service central SCEPman

1. Point(s) de terminaison SCEP

   • Invoqué pour les requêtes SCEP.

   • Selon la configuration, SCEPman peut exposer plusieurs points de terminaison SCEP pour Intune, Jamf Pro, DCs, autres MDMs génériques.

2. API REST d'enrôlement

   • Permet à Certificate Master de demander des certificats au service central de SCEPman.

   • Permet aux applications personnalisées de demander des certificats au service central de SCEPman.

3. Point de terminaison EST

   • Invoqué pour les requêtes de ré-enrôlement simple EST. Peut être activé via la configuration.

   • Invoqué pour les requêtes d'enrôlement simple EST.

4. Point de terminaison OCSP

   • Invoqué pour les requêtes OCSP.

5. Point de distribution de certificats (CDP)

   • La liste de révocation des certificats (CRL) est mise à disposition via ce point de terminaison.

   • Peut être activé via la configuration.

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ée via la configuration.

8. Point de terminaison de sonde SCEPman

   • Vérifications d'intégrité : vérification d'intégrité intégrée d'App Service, sondage Traffic Manager, sondage Application Gateway.

Certificate Master

1. Portail web Certificate Master

   • Émettre manuellement des certificats de 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 d'intégrité : vérification d'intégrité intégrée d'App Service

6. Comment les points de terminaison de la question 5 sont-ils protégés ?

Service central SCEPman

1. Point(s) de terminaison SCEP

   • Intune : Protégé via l'API Intune Challenge (Microsoft Docs)

   • Jamf Pro, DCs, autres MDMs génériques : Protégés avec 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

   • Ré-enrôlement simple : authentification basée sur certificat.

   • Enrôlement simple : authentification intégrée Microsoft Entra ID (Azure AD).

4. Point de terminaison OCSP

   • Aucune protection requise.

5. Point de distribution de 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

   • Pas de protection mais peut être désactivé.

8. Point de terminaison de sonde SCEPman

   • Pas de 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ôle.

2. Point de terminaison de sonde Certificate Master

   • Pas de protection.

7. Quels ports et protocoles sont utilisés par les points de terminaison de la question 6 ?

Service central SCEPman

1. Point(s) de terminaison SCEP

   • Intune : HTTPS (TCP / 443)

   • Jamf Pro, DCs, autres MDMs 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 de 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 conditionnels / 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 identifiants d'accès peuvent-ils être récupérés ? Si oui, comment ?

• Identifiants de connexion : dépend des politiques Microsoft Entra ID (Azure AD) configurées dans le locataire 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 l'accès non autorisé ?

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 accédée que par des utilisateurs autorisés disposant des autorisations Azure pertinentes.

Clés cryptographiques

• La clé privée de la CA est stockée de manière sécurisée dans Azure Key Vault (HSM validé FIPS 140 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 douce sont activées par défaut).

• Azure Key Vault utilise un endpoint privé et ne peut être accédé que depuis SCEPman (par défaut pour les installations SCEPman de la version 2.8 et supérieures).

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 le contrôle d'accès basé sur les rôles pour gérer les autorisations sur les 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.

• Le compte de stockage Azure utilise un endpoint privé et ne peut être accédé que depuis SCEPman (par défaut pour les installations SCEPman de la version 2.8 et supérieures).

Journaux

• Les journaux sont stockés dans un espace de travail Log Analytics.

• 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 l'accès non autorisé ?

• SCEP :

  • Utilise TLS par défaut (TLS 1.2 minimum - les politiques Microsoft s'appliquent).

  • Les requêtes SCEP sont chiffrées pour le certificat de la CA et signées avec le certificat du client.

  • Les réponses SCEP sont chiffrées pour le certificat du client et signées avec le certificat de la CA.

• OCSP :

  • Les requêtes OCSP ne devraient pas être chiffrées pour éviter des problèmes de type poule-œuf.

  • Les réponses OCSP sont signées par le certificat de la CA.

• API REST d'enrôlement 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é par 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 plus de cela, 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 d'enrôlement d'appareil Intune

• Vérification d'appareil Microsoft Entra ID (Azure AD)

• Endpoints privés

Étant donné que SCEPman est construit sur des composants Azure, vous pouvez utiliser Microsoft Defender (MD) pour Cloud, tels que MD pour App Service, MD pour Storage, ou MD pour 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 accordent l'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é exige également un haut niveau de commodité pour l'utilisateur, car des processus compliqués et opaques ont une surface d'attaque plus grande et un potentiel d'erreur humaine plus élevé. Bien que SCEPman offre de nombreuses options de configuration si nécessaire, nous nous efforçons d'utiliser des valeurs par défaut raisonnables et sécurisées chaque fois que possible.

Ainsi, si une clé privée est compromise, SCEPman peut révoquer le certificat correspondant en temps réel. Pour les certificats enrôlés 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 ou l'objet Jamf Pro.

Selon vos processus de mise hors service des appareils, vous pouvez en outre configurer pour révoquer les certificats lorsqu'un effacement est déclenché, lorsque Intune demande la révocation, en fonction de la conformité de l'appareil ou le niveau de risque de l'utilisateur, ou vous pouvez révoquer manuellement des certificats individuels via le composant Certificate Master.

Les certificats créés manuellement exigent 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, compte de stockage, Log Analytics)

3. Quels algorithmes cryptographiques et tailles de clé SCEPman prend-il en charge ?

Pour les clés des certificats émis, Certificate Master n'a pas de restrictions lorsqu'il utilise 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 enrôlés via SCEP, Intune prend en charge jusqu'à des clés RSA 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 2048 bits. Lors de l'utilisation du point de terminaison SCEP statique, tous les algorithmes et tailles de clé courants sont pris en charge (spécifiquement ceux que la bibliothèque cryptographique Bouncy Castle pour C# prend en charge).

Pour la clé de la CA, SCEPman ne prend en charge que RSA. RSA 4096 bits est la taille de clé par défaut. 4096 bits est actuellement la taille maximale prise en charge par Azure Key Vault. Si vous utilisez un certificat de CA 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 CA ECC peut être créée, prenant en charge les courbes elliptiques suivantes : P-256, secp256k1/P-256K, P-384, P-521.

4. La CA créée par SCEPman est-elle unique ?

Oui

Détails :

• SCEPman génère la paire clé privée-publique pour la Root CA dans Azure Key Vault de votre locataire. Par conséquent, la Root CA est unique pour votre instance SCEPman personnelle et vous avez le contrôle total sur la CA, son certificat et la clé privée correspondante.

• L'accès à cette CA est contrôlé via les politiques d'accès du Key Vault que vous pouvez modifier si vous le souhaitez. Par défaut, seule votre propre instance SCEPman et personne d'autre (même pas un administrateur) peut utiliser le certificat, mais un administrateur d'abonnement peut accorder des autorisations supplémentaires.

• Par conséquent, les autres clients SCEPman ne pourront pas se connecter à votre VPN, peu importe la façon dont ils configurent leur SCEPman. S'ils choisissent le même nom d'organisation, ils auront quand même leur propre paire de clés et donc un autre certificat de CA 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 du travail avec des cadres de bonnes pratiques tels que le CIS Microsoft Azure Foundations Benchmark.

Comptes de stockage

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 : Le mode certificat client peut-il être défini sur Exiger?

Non, car cela casserait la fonctionnalité de SCEPman. En effet, SCEPman enrôle des certificats client, donc les clients n'ont pas encore de certificats client pour s'authentifier (problème poule-œuf). Ce n'est cependant pas un problème de sécurité, car le protocole SCEP utilise ses propres mécanismes d'authentification via le challenge SCEP. Par conséquent, SCEPman a besoin d'une exemption des politiques imposant le TLS mutuel. Le mode certificat client doit être défini sur Ignorer ou Optionnel.

3. La version HTTP peut-il être défini sur 2.0?

Bien que SCEPman devrait fonctionner avec n'importe laquelle des versions HTTP disponibles, à ce jour, nous ne prenons en charge que par défaut HTTP 1.1 - principalement en raison d'un manque de tests.

Lors du changement de ce paramètre - à vos risques et périls - veuillez considérer que ce n'est pas seulement SCEPman qui doit prendre en charge la nouvelle version HTTP. Les différents types de clients doivent également prendre en charge cette version HTTP, c.-à-d. 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 NACs de différents fournisseurs.

4. Peut-on HTTPS uniquement être activé ?

Non (pas pour l'App Service SCEPman), car cela casserait la fonctionnalité de répondeur OCSP de SCEPman en combinaison avec de nombreux clients OCSP et appliances fournisseurs. OCSP est un protocole qui est plus couramment fourni sur HTTP que sur HTTPS. L'une des raisons est que si vous utilisiez TLS pour la vérification de révocation des certificats (téléchargement des CRL ou OCSP), il pourrait y avoir un problème poule-et-œuf, 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'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. Par conséquent, SCEPman a besoin d'une exemption des politiques imposant TLS.

Remarque : HTTPS uniquement ne peut pas être activé pour l'App Service SCEPman, mais il devrait être activé pour l'App Service Certificate Master.

5. La version TLS minimale entrante peut-elle être définie sur 1.3 ?

Non pour l'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 souhaitons que le client s'authentifie avec un certificat dans certaines circonstances (ré-enrôlement simple EST), donc si vous définissez TLS sur 1.3, vous ne pourrez pas renouveler vos certificats en utilisant 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, au 2025-07, ne prend pas en charge TLS 1.3 (il y aura une erreur côté client lors de l'enrôlement SCEP).

Remarque : Comme seuls les navigateurs accèdent à l'App Service Certificate Master, il est recommandé pour Certificate Master de définir la version TLS minimale entrante 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 concernant le centre de données Azure dans lequel SCEPman et ses composants doivent être déployés.

• Un déploiement complet de SCEPman incluant tous ses composants dans des centres de données Azure européens est possible.

2. De quels fournisseurs cloud tiers SCEPman dépend-il et pourquoi ?

Société	Services	Contact	Objet
Microsoft Corporation	Services cloud (Azure)	Building 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublin, Irlande	Voir ici.
GitHub Inc (filiale de Microsoft Corporation)	dépôt de code git, intégration, tests et automatisation des releases, 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. L'application des pratiques SDL nous aide à créer du code et des déploiements sécurisés. Nous disposons de la certification ISO 27001 pour la sécurité de l'information pour le développement de notre produit.

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:

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. Nous discutons des décisions de conception et des menaces potentielles STRIDE au sein d'une équipe hétérogène de développeurs, notre CSOC et consultants PKI, ainsi que l'équipe de support.

Préférer la sécurité de la plateforme au code personnalisé

Lorsque cela est possible, nous utilisons des 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 la bibliothèque Bouncy Castle pour C# pour travailler avec les standards de données cryptographiques. Nous nous appuyons également sur les services Azure comme Key Vault pour la génération de 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 potentiel d'erreur humaine, nous concevons les produits de sorte que vous disposiez d'une configuration sécurisée si vous utilisez les valeurs par défaut. Par exemple, nos templates ARM et notre provider Terraform définissent des paramètres de configuration pour utiliser des clés RSA HSM de 4096 bits, et ils désactivent tous les points d'enrôlement sauf Intune SCEP et Certificate Master (pour lesquels vous devez explicitement attribuer des autorisations).

Ne jamais faire confiance aux données provenant du client

En tant que logiciel PKI, décider quelles données il faut considérer comme fiables est au cœur de chaque décision. Après tout, l'objet des certificats et de leurs protocoles d'enrôlement est de décider quelles données il faut faire confiance.

Supposer une compromission

Notre journalisation basée sur Azure Monitor permet la surveillance des opérations de SCEPman. Elle s'intègre facilement avec des systèmes SIEM comme Sentinel pour détecter des attaquants réussis, par ex. s'ils ont réussi à enrôler des certificats sans autorisation. Notre intégration avec les services Azure permet d'exploiter les services Microsoft Defender for Cloud, par ex. Defender for App Service.

Appliquer le principe du moindre privilège

Notre modèle RBAC pour Certificate Master permet d'attribuer seulement les autorisations dont les utilisateurs ont réellement besoin.

SCEPman utilise des identités gérées qui n'ont que les autorisations nécessaires au fonctionnement.

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é de suppression douce du Key Vault avec protection contre la purge avec une clé privée HSM non exportable pour l'autorité de certification. La suppression douce avec protection contre la purge s'assure qu'aucun administrateur malveillant ou compte administrateur compromis ne peut supprimer la clé privée de la CA -- elle peut être restaurée en quelques minutes pour reprendre les opérations normales et même un administrateur global ne peut pas la purger avant une période de 90 jours. La clé de CA HSM non exportable garantit que même un attaquant ayant les privilèges les plus élevés ne puisse pas voler la clé de la CA.

Minimiser la surface d'attaque

Nous veillons à n'exposer que les interfaces requises pour les opérations par 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 Endpoints privés, nous nous assurons que deux services dont dépend SCEPman, Azure Key Vault et Azure Storage, ne sont pas accessibles via Internet.

Prendre en compte les cas d'abus

Lorsque SCEPman reçoit des demandes de signature de certificats (CSR) autorisées, elles restent soumises à plusieurs restrictions configurables. Par exemple, la durée de vie ne peut jamais dépasser la période de validité maximale configurée, 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 des alertes 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 que société qui fournit également des services CSOC et du conseil 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 partenaire Microsoft de l'année avec nos offres de sécurité.

Nos dépôts source ont des règles de protection des branches et nous attribuons seulement les principes d'accès les plus nécessaires aux dépôts et pipelines de déploiement pour les comptes développeurs individuels. Nous automatisons les tests et les déploiements lorsque c'est possible pour réduire la surface d'attaque liée à des comptes compromis.

4. SCEPman fait-il partie d'un programme de prime aux bugs ?

Non.

5. Quelles mesures d'assurance qualité sont en place ?

• Nous fournissons SCEPman sur un canal interne, bêta et production

• Chaque version de production doit passer d'abord par les canaux interne et bêta, en réussissant les contrôles QA pertinents dans le cadre de notre processus CI

  • Tests unitaires

  • Revue par les pairs

  • Tests d'intégration

  • Tests de résistance

  • Tests basés sur l'expérience

  • Analyse de code tierce, par ex. Sonar, Dependabot, et autres

6. Effectuez-vous régulièrement des tests d'intrusion ?

Non.

Dans le cadre de nos pratiques de développement sécurisé, nous utilisons des outils (ex. analyse statique de code) qui scannent la base de code à la recherche de CVE et autres exploits courants (y compris les dépendances comme les bibliothèques tierces) pouvant impacter la sécurité des points de terminaison exposés par SCEPman. Avant toute version, les résultats pertinents sont évalués et corrigés, afin de garantir que SCEPman reste exempt de vulnérabilités connues. Nous n'effectuons ni tests d'intrusion nous-mêmes, ni n'utilisons d'outils tiers de « Penetration Test-as-a-Service ». Pour le premier, nous voyons un conflit d'intérêts inhérent. Pour le second, étant donné que les services typiques de tests d'intrusion vérifient souvent simplement les points de terminaison exposés contre des CVE et autres exploits connus, nous ne voyons pas de valeur ajoutée par rapport aux vérifications que nous effectuons déjà via l'analyse statique du code. Si vous souhaitez effectuer vos propres tests d'intrusion, veuillez nous contacter et parlez-nous de vos exigences.