> 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/autre/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 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 les **certificats utilisateur**, nous recommandons de configurer les valeurs suivantes dans le 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. que les données suivantes sont visibles pour 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 de l’activité 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 le certificat, qui sont stockés en toute sécurité 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’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’exclusion des clés privées*.
   * Pour les données pouvant faire partie d’un certificat, veuillez vous reporter à [la question 1](#id-1.-which-data-is-processed-by-scepman).
   * Ce comportement peut être [désactivé](/fr/configuration-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 SCEPman du client, la journalisation peut être activée. Selon les paramètres de verbosité de journalisation du client, les journaux peuvent contenir n’importe quelle donnée traitée par SCEPman. Le client configure l’emplacement de stockage des journaux.
4. Log Analytics Workspace externe

   SCEPman envoie toujours une quantité limitée de **données non secrètes** et **non personnelles** à notre Log Analytics Workspace (LAW). Ces données sont utilisées à des fins de

   * licence.
   * Assurance qualité (par exemple, la surveillance globale des exceptions nous aide à reconnaître rapidement les problèmes généraux et répandus, ce qui nous permet d’apporter rapidement une solution à nos clients et d’éviter ainsi des pannes de service coûteuses).

   Par défaut, SCEPman ne **transmet aucune donnée personnelle** à notre LAW.

   Selon les paramètres de journalisation, des informations de débogage et d’autres informations sont transmises au LAW de glueckkanja-gab AG. Nos ingénieurs de support peuvent demander à [activer](/fr/configuration-scepman/application-settings/basics.md#appconfig-remotedebug) la fonctionnalité de débogage à distance depuis l’administrateur du client pour l’aide au dépannage. Dans de tels cas, des informations sur 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
   * Microsoft Entra ID (Azure AD) UPN
   * Identifiant de l’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 réalisé comme une application Azure (basée sur un modèle de solution), c.-à-d. qu’il est déployé dans le locataire Azure du client. À ce titre, la souveraineté des données, y compris le choix de la zone géographique du centre de données d’hébergement, relève du client et de ses préférences.

#### Log Analytics Workspace externe

Le LAW externe que nous utilisons pour collecter (par défaut **non personnelles** et **données non secrètes**) les informations de télémétrie à des fins d’application des licences est situé dans **le centre de données Europe de l’Ouest d’Azure** .

### 4. À quelles autorisations du locataire l’administrateur doit-il consentir ?

SCEPman exploite des identités managé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 de sécurité supplémentaire.
2. Microsoft Graph `Directory.Read.All`:\
   \
   Avec cette autorisation, SCEPman peut consulter 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 [fonctionnalité de révocation EndpointList](/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation.md#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é](/fr/configuration-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\
   \
   Avec ces autorisations, SCEPman peut consulter 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 App Registration) :\
   \
   Avec 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 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 central SCEPman**

1. Point(s) de terminaison SCEP
   * Appelé pour les requêtes 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 central de SCEPman.
   * Permet à des applications personnalisées de demander des certificats au service principal central 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 requêtes OCSP.
5. Point de distribution des certificats (CDP)
   * La liste de révocation de certificats (CRL) est mise à disposition via ce point de terminaison.
   * Peut être activé via [la configuration](/fr/configuration-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 SCEPman
   * Affiche publiquement les informations de base sur l’état de SCEPman (aucun secret).
   * Lecture seule.
   * Peut être désactivé via [la configuration](/fr/configuration-scepman/application-settings/basics.md#appconfig-anonymoushomepageaccess).
8. Point de terminaison de surveillance SCEPman
   * Contrôles de santé : contrôle de santé intégré d’App Service, sondage Traffic Manager, sondage 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 surveillance Certificate Master
   * Contrôles de santé : contrôle de santé intégré d’App Service

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

#### Service principal central SCEPman

1. Point(s) de terminaison SCEP
   * Intune : Protégé via l’API de challenge Intune ([Microsoft Docs](https://docs.microsoft.com/en-us/mem/intune/protect/scep-libraries-apis))
   * Jamf Pro, les DC, d’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’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 SCEPman
   * Aucune protection, mais peut être désactivée.
8. Point de terminaison de surveillance 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-scepman/rbac.md).
2. Point de terminaison de surveillance Certificate Master
   * Aucune protection.

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

**Service principal central SCEPman**

1. Point(s) de terminaison SCEP
   * Intune : HTTPS (TCP / 443)
   * Jamf Pro, les DC, d’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 les services externes.
7. Page d’accueil SCEPman
   * HTTPS (TCP / 443)
8. Point de terminaison de surveillance SCEPman
   * HTTPS (TCP / 443)

#### Certificate Master

1. Portail web Certificate Master
   * HTTPS (TCP / 443)
2. Point de terminaison de surveillance 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 Microsoft Entra ID (Azure AD) peut être utilisé.

### 2. Les identifiants d’accès peuvent-ils être récupérés ? Si oui, comment ?

* Identifiants de connexion : Cela 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 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 l’on choisit de ne pas stocker les données de configuration dans Azure Key Vault, elles sont stockées dans AppService (chiffrement BitLocker)
* Toute donnée de configuration (Azure Key Vault, App Services) ne peut être accessible qu’aux utilisateurs autorisés disposant des autorisations Azure pertinentes.

#### Clés cryptographiques

* La clé privée de l’AC est stockée en toute sécurité 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 autorisations aux données.
* Azure Storage utilise le chiffrement des données et prend en charge les clés gérées par le client.
* Le 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 des 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 pour le certificat de l’AC et signées avec le certificat client.
  * Les réponses SCEP sont chiffrées pour 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 une approche visant à 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 reconnaître et atténuer les menaces internes et externes à différents niveaux :

* Key Vault
* App Insights
* Vérification de l’inscription de l’appareil Intune
* Vérification de l’appareil Microsoft Entra ID (Azure AD)
* Points de terminaison privés

Comme SCEPman repose 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 dans le cloud, SCEPman est responsable de l’émission et de la révocation des certificats numériques. Ces certificats, avec leurs clés privées, authentifient des appareils ou des utilisateurs et leur donnent accès à d’autres ressources. Par conséquent, la sécurité des processus d’émission et de révocation des certificats constitue un objectif de conception très important. Un haut niveau de sécurité exige également un haut niveau de confort pour l’utilisateur, car des processus compliqués et opaques présentent une plus grande surface d’attaque et un risque accru d’erreur humaine. Bien que SCEPman offre de nombreuses options de configuration si nécessaire, nous avons cherché à utiliser autant que possible des valeurs par défaut raisonnables et sécurisées.

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 n’avez qu’à [supprimer l’objet Intune correspondant](/fr/configuration-scepman/device-directories.md) ou l’objet Jamf Pro correspondant.

Selon vos processus de mise hors service des appareils, vous pouvez en outre configurer la [révocation des certificats lorsqu’un effacement est déclenché](/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationrevokecertificatesonwipe), lorsque [Intune demande la révocation](/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationdevicedirectory), en fonction de [la conformité de l’appareil](/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationcompliancecheck) ou [du niveau de risque de l’utilisateur](/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationuserriskcheck), ou vous pouvez révoquer manuellement des certificats individuels via le composant Certificate Master.

[Les certificats créés manuellement](/fr/gestion-des-certificats/certificate-master.md) nécessitent toujours une révocation manuelle.

### 2. Quelles technologies, quels composants, quelles plateformes ont été utilisés 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é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 sont les algorithmes et tailles de clés pris en charge.

Pour les certificats inscrits via SCEP, Intune prend en charge jusqu’aux 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 au plus en charge des clés RSA 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 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 pour 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 les 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), 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, quelle que soit la configuration de leur SCEPman. S’ils choisissent le même nom d’organisation, ils auront toujours leur propre paire de clés et donc un autre certificat d’AC auquel 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 référentiels de bonnes pratiques tels que le [CIS Microsoft Azure Foundations Benchmark](https://www.cisecurity.org/benchmark/azure/).

### Comptes de stockage

#### 1. Peut-on `Allow Blob public access` être désactivé ?

*Oui*, c’est en fait déjà le paramètre par défaut pour les nouvelles installations de SCEPman.

### App Services

#### 2. TLS : le `Client certificate mode` peut-il être défini sur `Require`?

*Non*, car cela casserait le fonctionnement de SCEPman. En effet, SCEPman inscrit des certificats clients, de sorte que les clients ne disposent pas encore de certificats clients pour s’authentifier (problème de l’œuf et de la poule). Cela ne constitue toutefois 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 aux politiques imposant le TLS mutuel. Le `Client certificate mode` doit être défini sur `Ignore` ou `Facultatif`.

#### 3. La `version HTTP` peut-il ê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 valeur 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 nouvelle version HTTP. Les différents types de clients doivent également prendre en charge cette version de 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 NAC de différents fournisseurs.

#### 4. Peut-on `HTTPS Only` ê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 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’appareil ne peut pas établir la connexion TLS au point de terminaison OCSP, parce que le certificat 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 falsifiées. Par conséquent, SCEPman a besoin d’une exemption aux politiques imposant TLS.

**Remarque :** **`HTTPS Only`** ne peut pas être activé pour SCEPman App Service, mais il devrait l’être pour Certificate Master App Service.

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

*Non* pour 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 certains cas (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, en 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/autre/troubleshooting/general.md#some-windows-machines-do-not-enroll-or-renew-certificates)).

**Remarque :** Comme seuls les navigateurs accèdent à Certificate Master App Service, il est recommandé pour Certificate Master de définir la version TLS minimale entrante sur 1.3.

## RGPD et résidence des données <a href="#user-content-gdpr-and-data-residency" id="user-content-gdpr-and-data-residency"></a>

### 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. À quels fournisseurs cloud tiers SCEPman fait-il appel et pourquoi ?

| Entreprise                                    | Services                                                                                  | Contact                                                                                   | Objectif                                                                                             |
| --------------------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| Microsoft Corporation                         | Services cloud (Azure)                                                                    | <p>Building 3, Carmanhall Road Sandyford,<br>Industrial Estate 18, Dublin,<br>Ireland</p> | Voir [ici](/fr/deploiement-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 | <p>88 Colin P Kelly Jr St,</p><p>San Francisco,</p><p>CA 94107,</p><p>United States</p>   | 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 s’appuie sur le [Microsoft Security Development Lifecycle](https://www.microsoft.com/en-us/securityengineering/sdl/). L’utilisation 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 choix de conception et des menaces STRIDE potentielles au sein d’une équipe hétérogène composée de développeurs, de nos [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)et de 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 des 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 de 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 à offrir 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 basées sur HSM, et ils désactivent tous les points de terminaison d’inscription, à l’exception de SCEP Intune et de Certificate Master (pour lesquels vous devez attribuer explicitement des autorisations).

#### Ne jamais faire confiance aux données du client

En tant que logiciel PKI, décider quelles données sont dignes de confiance est au cœur même de toute décision. Après tout, l’objectif 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 la surveillance des opérations de SCEPman. Elle s’intègre facilement à des 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 de tirer parti des 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 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[ la 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 adossée à un HSM](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#hsm-protected-keys) pour l’autorité de certification. Soft Delete avec Purge Protection garantit qu’aucun administrateur malveillant ni aucun compte d’administrateur compromis ne peut supprimer la clé privée de la CA. La clé privée peut être restaurée en quelques minutes pour reprendre les opérations normales, et même un Global Admin ne peut pas la purger avant l’expiration d’un délai de 90 jours. La clé de CA adossée à un 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 CA.

#### Minimiser la surface d’attaque

Nous veillons à n’exposer que les interfaces nécessaires aux 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 validité ne peut jamais dépasser la [période de validité maximale configurée](/fr/configuration-scepman/application-settings/certificates.md#appconfig-validityperioddays), même si cela a été demandé.

#### Surveiller et déclencher des alertes sur les événements de sécurité

Lorsque SCEPman détecte des événements de sécurité, il les journalise 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 d’analyser les événements 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 du conseil en sécurité, nous appliquons 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 avons reçu le titre de Microsoft Partner of the Year pour nos offres de sécurité.

Nos dépôts sources appliquent des règles de protection des branches et nous n’attribuons aux dépôts et aux pipelines de déploiement, pour chaque compte de développeur, que les privilèges minimaux nécessaires. Nous automatisons les tests et les déploiements lorsque c’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 proposons SCEPman via des canaux interne, bêta et 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 résistance
  * Tests fondé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é, 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 les 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, toute découverte pertinente est évaluée et corrigée afin de garantir que SCEPman reste exempt de toute vulnérabilité connue.&#x20;

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 ». Dans le premier cas, nous y voyons un conflit d’intérêts inhérent. Dans le second, comme les services de test d’intrusion classiques se contentent souvent de vérifier les points de terminaison exposés par rapport aux CVE et à d’autres exploits connus, nous n’y voyons aucun avantage par rapport aux contrôles 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.scepman.com/fr/autre/security-faq.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
