Dell Command | Configuration sécurisée du BIOS : offre SaaS via Microsoft Azure Marketplace

Produits concernés :

• Prend en charge Dell Command Secure BIOS Configuration.
• Appareils clients professionnels Dell (ordinateurs portables, ordinateurs de bureau, stations de travail)

Sommaire :

• Introduction
• Modèle de déploiement : hébergé par le client sur Azure
• DCSBC Cloud vs. DCSBC On-Premises (DCC)
• Infrastructure en tant que code (Terraform)
• Conditions préalables
• Mise en route -- Accès au portail infonuagique de DCSBC
• Création de stratégies BIOS
  • Workflow de la politique d’authentification
  • Workflow de la politique des paramètres du BIOS
  • Workflow de la politique de déprovisionnement
• Conditions requises pour le certificat et téléchargement
• Publier des stratégies sur Microsoft Intune
• Contrôles de sécurité
• Foire aux questions

Introduction

Les interfaces de facilité de gestion s’appuient sur des interfaces ouvertes ou des commandes authentifiées par mot de passe. L’authentification par mot de passe est vulnérable aux attaques par force brute ou par dictionnaire, et est donc moins sécurisée que l’authentification par clé. Une meilleure interface de facilité de gestion authentifiée est nécessaire pour assurer la protection de l’intégrité et de la confidentialité des données et des commandes. Dell Command | La configuration sécurisée du BIOS (DCSBC) est une approche permettant de s’affranchir de l’authentification des commandes DACI avec des mots de passe du BIOS. DCSBC fournit une communication fiable en créant une interface qui utilise des mécanismes d’authentification PKI (Public Key Infrastructure) et des canaux chiffrés pour transmettre des messages entre la plate-forme et un client. Cette approche garantit à la fois intégrité et confidentialité pour protéger les données des clients.
DCSBC Cloud étend cette fonctionnalité à un modèle SaaS hébergé dans le Cloud et déployé dans l’abonnement Azure du client. Au lieu d’installer et de gérer un serveur DCSBC sur site avec Dell Command | Configure (DCC), les administrateurs informatiques accèdent à un portail web hébergé dans leur propre environnement Azure. L’ensemble de l’infrastructure est provisionné automatiquement via Terraform (Infrastructure as Code). Les stratégies sont créées par le biais d’un portail Web guidé, étape par étape, et publiées directement sur Microsoft Intune, sans configuration de serveur local, sans génération d’exécutable autonome (SCE) et sans installation d’agent de point de terminaison requise.

Principaux avantages de DCSBC Cloud :

• Le client est propriétaire de ses données :Toute l’infrastructure s’exécute dans le cadre de l’abonnement Azure du client. Les règles du BIOS, les clés cryptographiques, les données de configuration et les journaux d’audit restent sous l’entière propriété et le contrôle du client. Dell n’a pas accès aux données des clients.
• Souveraineté et conformité des données : Les clients choisissent la région Azure pour le déploiement, ce qui garantit que les exigences de résidence des données sont satisfaites. Toutes les données restent dans la zone géographique sélectionnée.
• Infrastructure en tant que code : L’ensemble de la solution est provisionné via Terraform, ce qui permet des déploiements d’infrastructure reproductibles, auditables et contrôlés par version.
• Pas d’infrastructure sur site : Élimine la nécessité d’installer et de gérer un serveur DCSBC avec Dell Command | Configurez.
• Gestion des règles basée sur le Web : Créez et gérez les règles du BIOS à partir de n’importe quel navigateur à l’aide d’un assistant étape par étape intuitif.
• Intégration native d’Intune : Les règles sont publiées directement dans Microsoft Intune en tant qu’applications Win32 lignes de produits en un seul clic.
• Déploiement sans agent : Aucun agent requis sur les points de terminaison. Le package déployé est autonome.
• Signature HSM gérée par Azure : Toutes les charges utiles du BIOS sont signées de manière cryptographique à l’aide d’Azure Managed HSM (RS384), ce qui garantit que seules les modifications autorisées atteignent les appareils.
• Architecture Zero-Trust : La confiance n’existe qu’entre le BIOS et le service Cloud DCSBC ; Aucune confiance n’est requise sur le client/point de terminaison.
• Prévention intégrée des attaques par relecture : chaque session du BIOS utilise des nonces cryptographiques uniques et des échanges de clés éphémères, ce qui garantit que les charges utiles précédemment capturées ne peuvent pas être réutilisées ou relues sur des appareils.
• Charges utiles liées à un périphérique de manière cryptographique : les charges utiles de configuration du BIOS sont liées de manière cryptographique à chaque périphérique individuel lors de l’établissement de la session, empêchant les charges utiles destinées à un périphérique d’être appliquées à un autre.

Retour au début

Modèle de déploiement : hébergé par le client sur Azure

Contrairement aux offres SaaS traditionnelles où le fournisseur héberge l’infrastructure, DCSBC Cloud est déployé dans l’abonnement Microsoft Azure du client. Cette architecture offre plusieurs avantages stratégiques :

• Propriété et contrôle des données : Toutes les ressources Azure (calcul, stockage, base de données, HSM, gestion de réseau) sont provisionnées au sein du client et de l’abonnement Azure du client. Les configurations des règles du BIOS, les clés de signature cryptographique, les données de session et les journaux d’audit sont stockés dans Azure SQL Database, Azure Key Vault/Managed HSM et le compte de stockage Azure du client. Dell Technologies n’a pas accès aux données, aux clés ou à l’infrastructure du client. Le client conserve le contrôle administratif total.
• Souveraineté et conformité des données : Le client sélectionne la région Azure pour le déploiement (par exemple, États-Unis Est 2, Europe Ouest, Est de l’Australie). Toutes les ressources sont provisionnées dans cette zone géographique unique.
  Le stockage utilise le stockage localement redondant (LRS) par défaut, ce qui garantit que les données ne quittent pas la région sélectionnée. Cela peut être configuré pour un stockage géoredondant (GRS) ou un stockage redondant interzone (ZRS) en fonction des besoins du client. Le modèle hébergé par le client prend en charge la conformité aux réglementations en matière de résidence des données (RGPD, lois sur la souveraineté des données, mandats spécifiques au secteur), car le client contrôle l’emplacement des données.
• Isolement du client : Chaque client dispose d’un déploiement entièrement isolé : son propre groupe de ressources, son réseau virtuel, ses sous-réseaux, ses bases de données, ses coffres de clés et toutes les autres ressources. L’isolation du réseau est appliquée via des points de terminaison privés, des groupes de sécurité réseau et le Pare-feu Azure.
• Transparence des coûts : Tous les coûts liés aux ressources Azure apparaissent dans la facturation Azure du client, ce qui offre une visibilité complète sur les dépenses d’infrastructure. Le client peut tirer parti des engagements Azure existants (MACC : engagement de consommation Microsoft Azure) et des instances réservées.

Retour au début

DCSBC Cloud vs. DCSBC On-Premises (DCC)

Remarque :
Les deux solutions partagent le même protocole sous-jacent au niveau du BIOS, y compris les commandes basées sur les sessions avec échange de clés Diffie-Hellman, la protection contre la relecture basée sur nonce et l’authentification PKI. Les stratégies créées avec l’une ou l’autre de ces solutions sont compatibles avec les mêmes implémentations de BIOS de clients professionnels Dell.

Retour au début

Infrastructure en tant que code (Terraform)

L’ensemble de l’infrastructure DCSBC Cloud est provisionnée à l’aide de Terraform (HashiCorp), ce qui permet des déploiements reproductibles, auditables et contrôlés par version. La configuration de Terraform est modulaire et paramétrée, ce qui permet de personnaliser le déploiement de chaque client en fonction de sa région Azure, des conventions de nommage et des exigences d’évolutivité.
Présentation de la configuration de Terraform :

• Version Terraform : >= 1.3.0
• Fournisseur AzureRM : ~> 4.37.0
• Gestion de l’état : État distant stocké dans le compte de stockage Azure (authentification Azure AD)
• Ressources Azure provisionnées : Les ressources suivantes sont automatiquement provisionnées dans l’abonnement Azure du client :

Retour au début

Conditions préalables

Avant d’utiliser DCSBC Cloud, assurez-vous que les conditions préalables suivantes sont remplies :

• Abonnement Microsoft Azure : abonnement Azure actif avec un locataire ID Azure Entra (Azure AD).
• Microsoft Intune : environnement Microsoft Intune actif configuré pour la gestion des appareils.
• Appareils clients professionnels Dell : les appareils cibles doivent être des ordinateurs portables, des ordinateurs de bureau ou des stations de travail Dell professionnels dotés d’un BIOS compatible DCSBC, inscrits dans Microsoft Intune.
• Azure Managed HSM ou Azure Key Vault : instance Azure Managed HSM ou Key Vault provisionnée avec des clés RSA-HSM qui correspondent aux certificats utilisés pour l’authentification du BIOS. La clé privée doit résider dans le HSM ; Seul le certificat public (.pem) est téléchargé sur le portail DCSBC Cloud.
• Certificats X.509 : certificats RSA répondant aux exigences suivantes :
  • Longueur de clé : RSA 3072 bits (exactement)
  • Format : PEM (extension de fichier .pem)
  • Version : X.509 v3
  • Taille de fichier : 8 Ko maximum
  • Algorithme : RSA (OID 1.2.840.113549.1.1.1)
• Navigateur pris en charge : navigateur Web moderne (Microsoft Edge, Google Chrome, Mozilla Firefox).

Retour au début

Mise en route -- Accès au portail infonuagique de DCSBC

• S’abonner - Acheter Dell Command | Configuration sécurisée du BIOS Cloud via Microsoft Azure Marketplace.
• Ouvrir une session : accédez à l’URL du portail Cloud DCSBC fournie au moment de l’abonnement. Connectez-vous à l’aide de vos informations d’identification Microsoft Entra ID (Azure AD). Le portail utilise Microsoft Authentication Library (MSAL) pour l’authentification unique.
• Page de destination : après l’authentification, vous êtes redirigé vers le tableau de bord des règles du BIOS. Cette option vous permet d’effectuer les opérations suivantes :
  • Afficher les règles du BIOS existantes publiées sur votre client Intune
  • Créer une nouvelle stratégie à l’aide du portail Web étape par étape

Retour au début

Création de stratégies BIOS

Sur la page Règles du BIOS, cliquez sur Créer une nouvelle stratégie. Vous verrez trois types de règles :

Sélectionnez un type de règle pour démarrer l’Assistant guidé. Ces stratégies sont déployées directement à partir d’Intune sur vos points de terminaison sans nécessiter l’installation d’agents de point de terminaison.

Remarque :

Dans une instance donnée, une seule clé de provisionnement peut être provisionnée sur une machine cliente.

Remarque :

Il est possible de provisionner jusqu’à sept clés de commande sur une machine cliente à un moment donné.

Workflow de la politique d’authentification

L’Assistant Stratégie d’authentification comporte 3 étapes :

Étape 1 -- Nommez votre politique

• Saisissez un nom de politique (obligatoire, 488 caractères maximum). Un AUTH_ de préfixe et un suffixe d’horodatage _DD.MM.YY_HH :mm_UTC sont ajoutés automatiquement.
• Saisissez une description facultative (1 000 caractères maximum).
• Le nom complet de la politique (y compris le préfixe et le suffixe, 512 caractères maximum) est prévisualisé avant de continuer.
• Les noms de règles en double sont détectés automatiquement en effectuant une vérification par rapport aux règles publiées existantes dans Intune.

Étape 2 -- Gestion de la sécurité du BIOS (téléchargement du certificat)

• Téléchargez jusqu’à 3 certificats au total :
  • 1 Certificat de provisionnement (obligatoire) : utilisé pour authentifier la connectivité sécurisée pour les opérations de provisionnement.
  • Jusqu’à 2 certificats de commande : utilisés pour signer les charges utiles pour les modifications de configuration du BIOS.
• Pour chaque certificat, sélectionnez : 
  • Tapez : Provisionnement ou commande
  • Action de stratégie : Ajouter (provisionner une nouvelle clé)
• Les certificats sont validés côté client (voir Certificats requis et téléchargement).
• Le bouton Next devient activé dans les cas suivants :
  • Un certificat de provisionnement est téléchargé
  • 1 certificat de commande téléchargé

Étape 3 -- Vérification et publication

• Vérifiez le nom, la description et le type de la stratégie.
• Cliquez sur Publier pour publier la stratégie sur Microsoft Intune (voir Publication de stratégies sur Microsoft Intune).

Retour au début

Workflow de la politique des paramètres du BIOS

L’Assistant Règles des paramètres du BIOS comporte 4 ou 5 étapes (selon que des stratégies de BIOS existantes existent ou non dans Intune) :

Étape 1 : copier et modifier, ou démarrer à partir de zéro (sous réserve de l’existence de règles existantes)

• Démarrer un fichier de règles vierge : démarrer avec une configuration vide.
• Copier, puis modifier : copiez les valeurs d’attribut du BIOS à partir d’une stratégie publiée existante et modifiez-les. Une fenêtre modale affiche une liste paginée, consultable et triable des stratégies existantes du BIOS.

Étape 2 : donnez un nom à votre politique

• Identique à la stratégie d’authentification, mais avec le préfixe BIOS_.

Étape 3 -- Choisir les attributs et valeurs du BIOS

• Un tableau affiche tous les attributs du BIOS disponibles dans le registre d’attributs Dell.
• Recherchez des attributs par nom, filtrez par catégorie et basculez pour afficher uniquement les attributs sélectionnés.
• Sélectionnez un attribut en cochant sa case, puis configurez sa valeur :
  • Enum attributes (e.g., SecureBoot, WakeOnLan) : sélectionnez des valeurs autorisées dans une liste déroulante.
  • Attributs entiers (par exemple, AutoOnHr, CustomChargeStart) -- Entrez un nombre compris dans la plage min-max.
  • Attributs de chaîne (par exemple, AssetTag) : saisissez du texte contenant jusqu’à 80 caractères.
  • Fonctionnalités personnalisées (par exemple, planification AutoOn, configuration du niveau de charge de la batterie, couleur du rétroéclairage du clavier) : cliquez sur « View/Change » pour ouvrir une fenêtre modale de configuration dédiée.
• Un panneau Code Preview affiche un aperçu en direct de la configuration sélectionnée au format CCTK :

[cctk]

SecureBoot=Enabled

WakeOnLan=LanOnly

AutoOn=SelectDays

AutoOnMon=Enabled

AutoOnTue=Enabled

• Le bouton Suivant est désactivé si aucun attribut n’est sélectionné ou si un attribut sélectionné a une valeur non valide.

Étape 4 -- Gestion de la sécurité du BIOS

• Téléchargez le même certificat de commande que celui utilisé pour la politique d’authentification.
• Un certificat de commande est requis pour continuer.

Étape 5 -- Réviser et publier

• Révisez et publiez sur Microsoft Intune.

Retour au début

Workflow de la politique de déprovisionnement

L’Assistant Deprovisioning Policy comporte 3 étapes :

Étape 1 -- Nommez votre politique

• Identique aux autres règles, avec le préfixe DPRV_.

Étape 2 -- Gestion de la sécurité du BIOS

• Téléchargez le même certificat de provisionnement que celui utilisé pour la stratégie d’authentification.
• Un certificat de provisionnement est requis.
• Remarque : Les certificats expirés sont autorisés pour les opérations de déprovisionnement, car l’objectif est de supprimer le provisionnement des appareils.

Étape 3 -- Vérification et publication

• Révisez et publiez. La règle de déprovisionnement utilise une opération Clear DACI pour supprimer toutes les clés provisionnées des appareils cibles.

Retour au début

Conditions requises pour le certificat et téléchargement

DCSBC Cloud nécessite des certificats X.509 au format PEM pour la signature des charges utiles du BIOS. La clé privée doit être stockée dans Azure Managed HSM ou Azure Premium Key Vault ; seul le certificat public est téléchargé sur le portail DCSBC.

Règles de validation des certificats :

La validation est effectuée côté client. Une fois qu’un certificat est chargé, le portail affiche les éléments suivants :

• Badge d’état de validation (Réussite/Échec)
• Publié le
• Date de fin de validité (s’affiche en rouge en cas d’expiration)
• Détails de l’émetteur : nom commun (CN), unité organisationnelle (OU), organisation (O), emplacement (L)

Messages d’erreur :

• Téléversez un fichier zip valide -- Le fichier n’est pas au format PEM ou a une extension incorrecte.
• « Le nom du fichier contient des caractères non valides. » -- Le nom du fichier contient des espaces ou des caractères spéciaux.
• « La taille maximale du fichier est de 8 Ko » : le fichier dépasse la limite de 8 Ko.
• « Ce fichier n’est pas valide, est corrompu ou est vide. Sélectionnez un autre fichier avec un certificat x509 valide et réessayez. » --Le certificat n’a pas pu être analysé ou échoue à la validation X.509 v3 / RSA / 3072 bits.
• « Ce certificat ne peut pas être utilisé. » -- Le certificat a expiré et l’action de la stratégie est « Ajouter ».

Retour au début

Publier des stratégies sur Microsoft Intune

Après avoir terminé l’Assistant de stratégie, cliquez sur le bouton Publier à l’étape Vérifier et publier. Le portail exécute un pipeline de publication automatisé en 11 étapes :

Une barre de progression et un suivi détaillé des étapes affichent l’état de la publication en temps réel. Une fois l’opération terminée avec succès :

• Le message « La stratégie {policyName} a été publiée sur Intune et sera disponible dans quelques minutes » s’affiche.
• Afficher dans Intune : ouvre le portail d’administration Microsoft Intune dans un nouvel onglet.
• Revenir aux stratégies : permet de revenir au tableau de bord des stratégies du BIOS.

Gestion des erreurs : En cas d’échec d’une étape, un message d’erreur s’affiche avec un bouton Réessayer (jusqu’à 3 tentatives). Les erreurs courantes incluent les délais d’expiration de l’API Intune, les échecs de téléchargement du stockage et les retards de validation de fichier.

Retour au début

Contrôles de sécurité

DCSBC Cloud met en œuvre une sécurité de défense en profondeur sur toutes les couches de l’infrastructure. Étant donné que la solution s’exécute dans l’abonnement Azure du client, tous les contrôles de sécurité sont auditables et sous la gouvernance du client.

Sécurité réseau

• Les points de terminaison privés garantissent que le trafic entre les services Azure (base de données, coffre de clés, HSM, stockage, services d’application) ne traverse jamais l’Internet public.
• L’accès au réseau public est désactivé par défaut pour tous les services du plan de données. Seuls la passerelle API et les points de terminaison CDN sont accessibles publiquement.
• Les groupes de sécurité réseau (NSG) contrôlent le trafic entrant et sortant pour chaque sous-réseau à l’aide de règles granulaires.
• Isolement du réseau virtuel : toutes les ressources sont déployées au sein d’un même réseau virtuel avec des sous-réseaux séparés pour chaque niveau de service.

Sécurité des applications

• Pare-feu d’applications Web (WAF) avec des ensembles de règles gérées OWASP standard en mode Prevention, offrant une protection contre les exploits Web courants (injection SQL, XSS, etc.).
• Le pare-feu au niveau CDN fournit une couche WAF supplémentaire en périphérie.
• Limitation du débit de l’API : la limitation du débit par opération basée sur IP protège les services back-end contre les attaques abusives et par déni de service.
• Validation des jetons Azure AD JWT : tous les appels d’API sont validés pour les jetons d’authentification Azure AD, ce qui garantit que seuls les utilisateurs autorisés peuvent accéder aux services back-end.
• Restrictions CORS : les demandes d’origines croisées sont limitées aux origines autorisées uniquement.

Encryption :

• TLS 1.2 minimum appliqué sur tous les services avec seules les suites de chiffrement fortes autorisées.
• HSM géré par Azure : les opérations de signature cryptographique utilisent des modules de sécurité matérielle validés FIPS 140-2 niveau 3, ce qui garantit que les clés ne sont jamais exposées dans le logiciel.
• Les données au repos sont chiffrées à l’aide du chiffrement de la plateforme Azure sur tous les services de stockage.

Identité et accès :

• Identités gérées (aucune information d’identification stockée) : les identités gérées Azure sont utilisées pour toutes les authentifications de service à service. Aucun mot de passe, chaîne de connexion ou secret n’est stocké dans la configuration de l’application.
• RBAC avec moindre privilège : chaque identité gérée se voit attribuer uniquement les rôles minimum requis, conformément au principe du moindre privilège.
• Azure Bastion : accès administratif sécurisé aux machines virtuelles de gestion sans exposer les adresses IP publiques.

Surveillance et alertes

• Alertes automatisées pour les événements de sécurité et opérationnels critiques, y compris les violations de limitation de débit, les erreurs de back-end, les tentatives d’accès non autorisées, les modèles de blocage WAF, les anomalies de latence d’API et les échecs de signature HSM.
• Journalisation complète des diagnostics sur tous les composants de l’infrastructure : passerelle API, passerelle d’application, applications Web, base de données, coffre de clés et HSM, avec des journaux collectés dans un espace de travail Log Analytics centralisé.
• Tableaux de bord pour une visibilité opérationnelle en temps réel et une analyse des tendances.

Gouvernance :

• Les vérifications de stratégie de prédéploiement (basées sur OPA) appliquent les bases de référence de sécurité avant le provisionnement de l’infrastructure, y compris les restrictions d’accès au réseau public, les versions TLS minimales, les exigences de protection de purge et les contrôles IP publics.
• Le verrouillage des ressources empêche la suppression accidentelle des magasins de données stratégiques (coffres-forts de clés, bases de données, comptes de stockage).

Retour au début

Foire aux questions

Q : J’utilise déjà DCSBC avec Dell Command | Configurer sur site. Puis-je migrer vers DCSBC Cloud ?

Oui Les deux solutions utilisent le même protocole sous-jacent au niveau du BIOS (DACI avec authentification PKI). Les appareils provisionnés avec la solution sur site peuvent être gérés par DCSBC Cloud et vice versa, tant que les mêmes certificats/clés sont utilisés. Vous devez télécharger vos certificats existants sur le portail Cloud DCSBC et vous assurer que les clés privées correspondantes sont disponibles dans Azure Managed HSM ou Key Vault.

Q : Où DCSBC Cloud s’exécute-t-il ? Est-il hébergé par Dell ?

Non. DCSBC Cloud est déployé dans votre propre abonnement Microsoft Azure. Toute l’infrastructure : calcul, stockage, base de données, HSM, gestion de réseau, s’exécute dans votre client Azure. Dell n’héberge ni n’a accès à vos données ou infrastructures. L’ensemble de la solution est provisionné automatiquement à l’aide de Terraform.

Q : Est-ce que Dell a accès aux règles, aux clés ou aux données de configuration du BIOS ?

Non. Étant donné que DCSBC Cloud s’exécute entièrement dans le cadre de votre abonnement Azure, toutes les données restent sous votre propriété et votre contrôle. Dell fournit le logiciel et les modèles Terraform, mais n’accède pas à vos données, ne les stocke pas et ne les traite pas.

Q : Puis-je choisir la région Azure dans laquelle effectuer le déploiement ?

Oui La région Azure est un paramètre de la configuration Terraform. Vous pouvez déployer dans n’importe quelle région Azure prise en charge pour répondre à vos exigences de résidence et de conformité des données. Toutes les ressources sont provisionnées dans la zone géographique unique.

Q : Ai-je besoin d’installer Dell Command | Configurer sur le serveur Cloud DCSBC ?

Non. Il n’y a pas de serveur sur site. L’infrastructure est provisionnée dans votre abonnement Azure via Terraform et l’application s’exécute en tant que services gérés par Azure (App Service, application de fonction, application Web statique).

Q : Dois-je installer des logiciels Dell sur les terminaux ?

Non. Les packages .intunewin déployés via Intune sont autonomes et incluent tous les composants nécessaires. Aucune installation d’agent de point de terminaison n’est requise.

Q : Quelles sont les consoles de déploiement prises en charge ?

DCSBC Cloud prend actuellement en charge Microsoft Intune en tant que console de déploiement. DCSBC avec DCC sur site prend en outre en charge SCCM et WorkspaceONE.

Q : Puis-je utiliser mon propre fournisseur HSM au lieu d’un HSM géré par Azure ?

DCSBC Cloud est conçu pour fonctionner avec Azure Managed HSM ou Azure Key Vault. Si vous avez besoin d’un autre fournisseur HSM, envisagez d’utiliser DCSBC sur site avec DCC, qui prend en charge HSM indépendant du fournisseur via le script HSMSigning.bat configurable.

Q : Quelles sont les tailles de clé RSA prises en charge ?

DCSBC Cloud nécessite exactement des clés RSA de 3 072 bits . Les clés d’autres tailles (2 048 bits, 4 096 bits, etc.) seront rejetées lors de la validation du certificat.

Q : Puis-je utiliser le même certificat pour les solutions DCSBC sur site et dans le Cloud ?

Oui, à condition que la clé privée soit accessible dans les deux environnements, stockée dans votre HSM/magasin de certificats local pour la solution sur site, et dans Azure Managed HSM ou Key Vault pour la solution Cloud.

Q : Que se passe-t-il si mon certificat expire ?

Les certificats expirés ne peuvent pas être utilisés pour les opérations d’ajout (provisionnement). Toutefois, les certificats expirés sont acceptés pour les opérations de déprovisionnement, car l’objectif est de supprimer le provisionnement des appareils.

Q : Quels paramètres du BIOS puis-je configurer ?

DCSBC Cloud comprend un registre complet des attributs du BIOS couvrant des catégories telles que la sécurité, la gestion de l’alimentation et des performances, la configuration du système, la vidéo et les configurations avancées. Exemples : SecureBoot, WakeOnLan, ordre de démarrage, planification AutoOn, configuration du niveau de charge de la batterie, couleur de rétroéclairage du clavier et bien d’autres.

Q : Quelle version de Terraform est requise pour déployer DCSBC Cloud ?

Terraform >= 1.3.0 est requis, avec le fournisseur AzureRM ~> 4.37.0.

Q : Puis-je personnaliser le déploiement de Terraform (par exemple, la taille des références SKU, la mise à l’échelle, la redondance du stockage) ?

Oui La configuration de Terraform est entièrement paramétrée via des variables. Vous pouvez personnaliser la référence SKU du plan App Service, le niveau de la base de données, le type de réplication du stockage (LRS/GRS/ZRS), les paramètres de mise à l’échelle automatique d’Application Gateway, etc., en fonction de vos exigences d’évolutivité et de disponibilité.