Dell Command | Configurazione sicura del BIOS - Offerta SaaS tramite Microsoft Azure Marketplace

Prodotti interessati:

• Supporta la Configurazione del BIOS Dell Command Secure.
• Dispositivi client commerciali Dell (notebook, desktop, workstation)

Sommario:

• Introduzione
• Modello di deployment: in hosting del cliente su Azure
• DCSBC cloud vs. DCSBC on-premise (DCC)
• Infrastructure-as-Code (Terraform)
• Prerequisiti
• Guida introduttiva: accesso al portale cloud DCSBC
• Creazione di policy del BIOS
  • Flusso di lavoro dei criteri di autenticazione
  • Flusso di lavoro dei criteri delle impostazioni del BIOS
  • Flusso di lavoro delle policy di deprovisioning
• Requisiti e upload dei certificati
• Pubblicazione di criteri in Microsoft Intune
• Controlli di sicurezza
• Domande frequenti

Introduzione

Le interfacce di gestibilità si basano su interfacce aperte o comandi autenticati tramite password. L'autenticazione della password è vulnerabile agli attacchi di forza bruta o a dizionario, quindi meno sicura rispetto all'autenticazione basata su chiave. È necessaria una migliore interfaccia di gestibilità autenticata per fornire protezioni dell'integrità e della riservatezza dei dati e dei comandi. Dell Command | Secure BIOS Configuration (DCSBC) è un approccio per evitare l'autenticazione dei comandi DACI con le password del BIOS. DCSBC fornisce una comunicazione affidabile creando un'interfaccia che utilizza meccanismi di autenticazione PKI (Public Key Infrastructure) e canali crittografati per passare i messaggi tra la piattaforma e un client. Questo approccio garantisce integrità e riservatezza per proteggere i dati dei clienti.
DCSBC Cloud estende questa funzionalità a un modello SaaS ospitato nel cloud implementato nell'abbonamento Azure del cliente. Invece di installare e gestire un server DCSBC on-premise con Dell Command | Configure (DCC), gli amministratori IT accedono a un portale web-based ospitato all'interno del proprio ambiente Azure. Il provisioning dell'intera infrastruttura avviene automaticamente tramite Terraform (Infrastructure as Code). Le policy vengono create tramite un portale Web con istruzioni dettagliate e pubblicate direttamente in Microsoft Intune, senza configurare un server locale, senza generare SCE (Self-Contained Executable) e senza richiedere l'installazione di agent endpoint.

Vantaggi principali del cloud DCSBC:

• Il cliente possiede i propri dati:Tutta l'infrastruttura viene eseguita nella sottoscrizione di Azure del cliente. Le policy del BIOS, le chiavi crittografiche, i dati di configurazione e gli audit log rimangono sotto la completa proprietà e controllo del cliente. Dell non ha accesso ai dati del cliente.
• Conformità e sovranità dei dati: I clienti scelgono l'area di Azure per il deployment, garantendo il rispetto dei requisiti di residenza dei dati. Tutti i dati rimangono all'interno dell'area selezionata.
• Infrastructure-as-Code - L'intera soluzione viene fornita tramite Terraform, fornendo implementazioni dell'infrastruttura ripetibili, verificabili e controllate dalla versione.
• Nessuna infrastruttura on-premise - Elimina la necessità di installare e gestire un server DCSBC con Dell Command | Configurazione.
• Gestione delle policy web-based - Crea e gestisci le policy del BIOS da qualsiasi browser utilizzando un'intuitiva procedura guidata passo-passo.
• Integrazione nativa con Intune: I criteri vengono pubblicati direttamente in Microsoft Intune come app line-of-business Win32 con un solo clic.
• Deployment senza agent - Nessun agent richiesto sugli endpoint. Il pacchetto implementato è indipendente.
• Firma del modulo di protezione hardware gestita di Azure - Tutti i payload del BIOS sono firmati crittograficamente usando il modulo di protezione hardware gestito di Azure (RS384), garantendo che solo le modifiche autorizzate raggiungano i dispositivi.
• Architettura Zero Trust - L'attendibilità esiste solo tra il BIOS e il servizio cloud DCSBC; Non è richiesta alcuna attendibilità sul client/endpoint.
• Prevenzione integrata degli attacchi replay: ogni sessione del BIOS utilizza nonce crittografici univoci e scambi di chiavi effimere, garantendo che i payload acquisiti in precedenza non possano essere riutilizzati o riprodotti contro i dispositivi.
• Payload crittograficamente legati al dispositivo : i payload di configurazione del BIOS sono associati crittograficamente a ogni singolo dispositivo durante la creazione della sessione, impedendo l'applicazione dei payload destinati a un dispositivo a un altro.

Torna all'inizio

Modello di deployment: in hosting del cliente su Azure

A differenza delle tradizionali offerte SaaS in cui il vendor ospita l'infrastruttura, DCSBC Cloud viene implementato nell'abbonamento Microsoft Azure del cliente. Questa architettura offre diversi vantaggi critici:

• Proprietà e controllo dei dati: Tutte le risorse di Azure, ovvero elaborazione, archiviazione, database, HSM e rete, vengono sottoposte a provisioning all'interno del tenant e della sottoscrizione di Azure del cliente. Le configurazioni dei criteri del BIOS, le chiavi di firma crittografica, i dati di sessione e i log di controllo vengono archiviati nel database SQL di Azure, nel vault di chiavi di Azure/Managed HSM e nell'account di archiviazione di Azure del cliente. Dell Technologies non ha accesso ai dati, alle chiavi o all'infrastruttura del cliente. Il cliente mantiene il pieno controllo amministrativo.
• Conformità e sovranità dei dati: Il cliente seleziona l'area di Azure per il deployment (ad esempio, Stati Uniti orientali 2, Europa occidentale, Australia orientale). Il provisioning di tutte le risorse viene eseguito all'interno di questa singola area.
  Lo storage utilizza lo storage con ridondanza locale (LRS) per impostazione predefinita, garantendo che i dati non lascino l'area selezionata. Questa operazione può essere configurata per l'archiviazione con ridondanza geografica (GRS) o l'archiviazione con ridondanza della zona (ZRS) in base ai requisiti del cliente. Il modello ospitato dal cliente supporta la conformità alle normative sulla residenza dei dati (GDPR, leggi sulla sovranità dei dati, mandati specifici del settore) poiché il cliente controlla dove risiedono i dati.
• Isolamento tenant: Ogni cliente ottiene una distribuzione completamente isolata: il proprio gruppo di risorse, la rete virtuale, le subnet, i database, gli insiemi di credenziali delle chiavi e tutte le altre risorse. L'isolamento della rete viene applicato tramite endpoint privati, gruppi di sicurezza di rete e Firewall di Azure.
• Trasparenza dei costi: Tutti i costi delle risorse Azure vengono visualizzati nella fatturazione Azure del cliente, fornendo una visibilità completa sulla spesa per l'infrastruttura. Il cliente può sfruttare gli impegni di Azure esistenti (MACC, Impegno di consumo di Microsoft Azure) e le istanze riservate.

Torna all'inizio

DCSBC cloud vs. DCSBC on-premise (DCC)

Nota:
Entrambe le soluzioni condividono lo stesso protocollo sottostante a livello di BIOS, inclusi i comandi basati su sessione con scambio di chiavi Diffie-Hellman, la protezione della riproduzione basata su nonce e l'autenticazione PKI. Le policy create con entrambe le soluzioni sono compatibili con le stesse implementazioni del BIOS del client commerciale Dell.

Torna all'inizio

Infrastructure-as-Code (Terraform)

L'intera infrastruttura cloud DCSBC viene fornita tramite Terraform (HashiCorp), fornendo implementazioni ripetibili, verificabili e controllate dalla versione. La configurazione Terraform è modulare e parametrizzata e consente di personalizzare ogni deployment del cliente in base all'area di Azure, alle convenzioni di denominazione e ai requisiti di scalabilità.
Panoramica della configurazione Terraform:

• Versione Terraform: >= 1.3.0
• Provider AzureRM : ~> 4.37.0
• Gestione dello stato: Stato remoto archiviato nell'account di archiviazione di Azure (autenticazione Azure AD)
• Risorse Azure di cui è stato effettuato il provisioning: Le risorse seguenti vengono automaticamente sottoposte a provisioning nella sottoscrizione di Azure del cliente:

Torna all'inizio

Prerequisiti

Prima di utilizzare DCSBC Cloud, verificare che siano soddisfatti i seguenti prerequisiti:

• Abbonamento di Microsoft Azure : abbonamento Azure attivo con un tenant ID Azure Entra (Azure AD).
• Microsoft Intune : un ambiente Microsoft Intune attivo configurato per la gestione dei dispositivi.
• Dispositivi client commerciali Dell : i dispositivi di destinazione devono essere notebook, desktop o workstation commerciali Dell con BIOS compatibile con DCSBC registrati in Microsoft Intune.
• Azure Managed HSM or Azure Key Vault : un'istanza di Azure Managed HSM or Key Vault di cui è stato eseguito il provisioning con chiavi RSA-HSM che corrispondono ai certificati usati per l'autenticazione del BIOS. La chiave privata deve risiedere nel modulo di protezione hardware. solo il certificato pubblico (.pem) viene caricato sul portale cloud DCSBC.
• Certificati X.509 - Certificati RSA che soddisfano i seguenti requisiti:
  • Lunghezza chiave: RSA a 3072 bit (esattamente)
  • Formato: PEM (estensione file .pem)
  • Versione: X.509 v3
  • Dimensione del file: massimo 8 KB
  • Algoritmo: RSA (OID 1.2.840.113549.1.1.1)
• Browser supportato : un browser Web moderno (Microsoft Edge, Google Chrome, Mozilla Firefox).

Torna all'inizio

Guida introduttiva: accesso al portale cloud DCSBC

• Abbonati - Acquista Dell Command | Cloud di configurazione del BIOS protetto tramite Microsoft Azure Marketplace.
• Accedi : accedere all'URL del portale cloud DCSBC fornito al momento dell'abbonamento. Accedere con le credenziali dell'ID Microsoft Entra (Azure AD). Il portale usa Microsoft Authentication Library (MSAL) per l'accesso Single Sign-On.
• Pagina di destinazione : dopo l'autenticazione, si viene indirizzati al dashboard delle policy del BIOS. Da qui puoi:
  • Visualizzare le policy del BIOS esistenti pubblicate nel tenant Intune
  • Creazione di una nuova policy mediante il portale Web con istruzioni dettagliate

Torna all'inizio

Creazione di policy del BIOS

Dalla pagina BIOS Policies, cliccare su Create a new policy. Verranno visualizzati tre tipi di policy:

Selezionare un tipo di policy per avviare la procedura guidata guidata. Questi criteri vengono distribuiti direttamente da Intune agli endpoint senza richiedere l'installazione di agenti di endpoint.

Nota:

In ogni istanza specificata, è possibile eseguire il provisioning di una sola chiave di provisioning su un computer client.

Nota:

È possibile eseguire il provisioning di un massimo di sette chiavi di comando su un computer client in una determinata istanza.

Flusso di lavoro dei criteri di autenticazione

La procedura guidata Authentication Policy prevede 3 passaggi:

Passaggio 1 - Assegna un nome alla tua polizza

• Immettere un nome per la policy (obbligatorio, max. 488 caratteri). Vengono aggiunti automaticamente un AUTH_ di prefisso e un suffisso di data e ora _DD.MM.YY_HH:mm_UTC.
• Immettere una descrizione facoltativa (massimo 1.000 caratteri).
• Prima di procedere, viene visualizzata in anteprima il nome completo della policy (inclusi prefisso e suffisso, massimo 512 caratteri).
• I nomi dei criteri duplicati vengono rilevati automaticamente controllando i criteri pubblicati esistenti in Intune.

Passaggio 2 - Gestione della sicurezza del BIOS (caricamento del certificato)

• Carica fino a 3 certificati in totale:
  • 1 Certificato di provisioning (obbligatorio): utilizzato per autenticare la connettività sicura per le operazioni di provisioning.
  • Fino a 2 certificati di comando, utilizzati per firmare i payload per le modifiche alla configurazione del BIOS.
• Per ogni certificato, selezionare: 
  • Tipo: Provisioning o comando
  • Azione politica: Aggiunta (provisioning di una nuova chiave)
• I certificati vengono convalidati lato client (vedere Requisiti dei certificati e upload).
• Il pulsante Next viene abilitato quando:
  • Viene caricato un certificato di provisioning
  • 1 certificato di comando caricato

Passo 3 - Rivedi e pubblica

• Rivedere il nome, la descrizione e il tipo di policy.
• Cliccare su Pubblica per pubblicare la policy in Microsoft Intune (vedere Pubblicazione delle policy in Microsoft Intune).

Torna all'inizio

Flusso di lavoro dei criteri delle impostazioni del BIOS

La procedura guidata dei criteri delle impostazioni del BIOS prevede 4 o 5 passaggi (a seconda che esistano o meno criteri del BIOS esistenti in Intune):

Passaggio 1 - Copiare e modificare o iniziare da zero (condizionale -- visualizzato solo se esistono policy esistenti)

• Avvio di un file di criteri vuoto: iniziare con una configurazione vuota.
• Copy then edit : consente di copiare i valori degli attributi del BIOS da una policy pubblicata esistente e di modificarli. Una finestra modale mostra un elenco ricercabile, ordinabile e impaginato delle policy del BIOS esistenti.

Passaggio 2: assegnare un nome alla polizza

• Come i criteri di autenticazione, ma con il prefisso BIOS_.

Passo 3 -- Scegli gli attributi e i valori del BIOS

• Una tabella visualizza tutti gli attributi del BIOS disponibili nel registro degli attributi Dell.
• Cerca gli attributi per nome, filtra per categoria e attiva o disattiva per visualizzare solo gli attributi selezionati.
• Selezionare un attributo cliccando sulla relativa casella di controllo, quindi configurarne il valore:
  • Attributi enumerazione (ad esempio, SecureBoot, WakeOnLan): selezionare da un elenco a discesa di valori consentiti.
  • Attributi numeri interi (ad esempio, AutoOnHr, CustomChargeStart): immettere un numero entro l'intervallo min-max.
  • Attributi stringa (ad esempio, AssetTag): inserisci un testo fino a 80 caratteri.
  • Funzioni personalizzate (ad esempio, pianificazione AutoOn, configurazione della carica della batteria, colore della retroilluminazione della tastiera): cliccare su "Visualizza/Cambia" per aprire una finestra modale di configurazione dedicata.
• Un pannello Anteprima codice mostra un'anteprima in tempo reale della configurazione selezionata in formato CCTK:

[cctk]

SecureBoot=Enabled

WakeOnLan=LanOnly

AutoOn=SelectDays

AutoOnMon=Enabled

AutoOnTue=Enabled

• Il pulsante Next è disabilitato se non sono selezionati attributi o se un attributo selezionato ha un valore non valido.

Passaggio 4 - Gestire la sicurezza del BIOS

• Caricare lo stesso certificato Command utilizzato per la policy di autenticazione.
• Per procedere è necessario un certificato di comando.

Passo 5 - Rivedi e pubblica

• Rivedi e pubblica su Microsoft Intune.

Torna all'inizio

Flusso di lavoro delle policy di deprovisioning

La procedura guidata della policy di deprovisioning prevede 3 passaggi:

Passaggio 1 - Assegna un nome alla tua polizza

• Uguale agli altri criteri, con il prefisso DPRV_.

Passo 2 - Gestire la sicurezza del BIOS

• Caricare lo stesso certificato di provisioning utilizzato per la policy di autenticazione.
• È richiesto un certificato di provisioning.
• Nota: I certificati scaduti sono consentiti per le operazioni di deprovisioning, poiché lo scopo è rimuovere il provisioning dai dispositivi.

Passo 3 - Rivedi e pubblica

• Rivedi e pubblica. La policy di deprovisioning utilizza un'operazione Clear DACI per rimuovere tutte le chiavi sottoposte a provisioning dai dispositivi di destinazione.

Torna all'inizio

Requisiti e upload dei certificati

DCSBC Cloud richiede certificati X.509 in formato PEM per la firma dei payload del BIOS. La chiave privata deve essere archiviata nel modulo di protezione hardware gestito di Azure o in Azure Premium Key Vault. solo il certificato pubblico viene caricato sul portale DCSBC.

Regole di convalida dei certificati:

La convalida viene eseguita sul lato client. Dopo il caricamento di un certificato, il portale visualizza:

• Badge dello stato di convalida (Operazione riuscita/non riuscita)
• Data di emissione
• Data di inizio validità (indicata in rosso se scaduta)
• Dettagli dell'emittente: Nome comune (CN), Unità organizzativa (OU), Organizzazione (O), Posizione (L)

Messaggio di errore:

• "Caricare un file .pem valido." -- Il file non è in formato PEM o ha un'estensione errata.
• "Il nome del file contiene caratteri non validi." -- Il nome del file contiene spazi o caratteri speciali.
• "La dimensione massima del file è 8 KB": il file supera il limite di 8 KB.
• "Questo file non è valido, danneggiato o vuoto. Selezionare un altro file con un certificato x509 valido e riprovare." --Impossibile analizzare il certificato o convalida X.509 v3 / RSA / 3072 bit non riuscita.
• "Impossibile utilizzare questo certificato." -- Il certificato è scaduto e l'azione della policy è "Add".

Torna all'inizio

Pubblicazione di criteri in Microsoft Intune

Dopo aver completato la procedura guidata della policy, cliccare sul pulsante Publish nel passaggio Review and Publish. Il portale esegue una pipeline di pubblicazione automatizzata in 11 fasi:

Una barra di avanzamento e un tracker dettagliato delle fasi mostrano lo stato di pubblicazione in tempo reale. Al termine dell'operazione:

• Viene visualizzato il messaggio "La policy {policyName} è stata pubblicata in Intune e sarà disponibile entro pochi minuti".
• Visualizza in Intune: apre il portale di amministrazione di Microsoft Intune in una nuova scheda.
• Back to Policies: consente di tornare al dashboard delle policy del BIOS.

Gestione degli errori: Se una fase ha esito negativo, viene visualizzato un messaggio di errore con il pulsante Retry (fino a 3 tentativi). Gli errori comuni includono timeout dell'API Intune, errori di caricamento dell'archiviazione e ritardi nel commit dei file.

Torna all'inizio

Controlli di sicurezza

DCSBC Cloud implementa la sicurezza di difesa in profondità su tutti i livelli dell'infrastruttura. Poiché la soluzione viene eseguita nella sottoscrizione di Azure del cliente, tutti i controlli di sicurezza sono controllabili e sotto la governance del cliente.

Sicurezza della rete

• Gli endpoint privati garantiscono che il traffico tra i servizi di Azure (database, insieme di credenziali delle chiavi, modulo di protezione hardware, archiviazione, servizi app) non attraversi mai la rete Internet pubblica.
• L'accesso alla rete pubblica è disabilitato per impostazione predefinita per tutti i servizi piano dati. Solo il gateway API e gli endpoint della rete CDN sono accessibili pubblicamente.
• I gruppi di sicurezza di rete controllano il traffico in entrata e in uscita per ogni subnet con regole granulari.
• Isolamento della rete virtuale: tutte le risorse vengono distribuite all'interno di una singola rete virtuale con subnet separate per ogni livello di servizio.

Sicurezza applicazioni

• Web Application Firewall (WAF) con set di regole gestite OWASP standard del settore in modalità di prevenzione per fornire protezione contro gli exploit web più comuni (SQL injection, XSS e così via).
• Il firewall a livello di rete CDN fornisce un livello WAF aggiuntivo nell'edge.
• Limitazione della velocità delle API: la limitazione della velocità basata su IP per operazione protegge i servizi back-end da abusi e attacchi denial-of-service.
• Convalida del token JWT di Azure AD: tutte le chiamate API vengono convalidate per i token di autenticazione di Azure AD, garantendo che solo gli utenti autorizzati possano accedere ai servizi back-end.
• Restrizioni CORS: le richieste tra le origini sono limitate solo alle origini autorizzate.

Encryption:

• TLS 1.2 minimo applicato a tutti i servizi con solo pacchetti di crittografia avanzati consentiti.
• Modulo di protezione hardware gestito di Azure: le operazioni di firma crittografica usano moduli di sicurezza hardware convalidati FIPS 140-2 livello 3, garantendo che le chiavi non siano mai esposte nel software.
• I dati inattivi vengono crittografati usando la crittografia della piattaforma Azure in tutti i servizi di storage.

Identità e accesso:

• Identità gestite (zero credenziali archiviate): le identità gestite di Azure vengono usate per tutte le autenticazioni da servizio a servizio. Nella configurazione dell'applicazione non vengono archiviate password, stringhe di connessione o segreti.
• RBAC least-privilege: a ogni identità gestita vengono assegnati solo i ruoli minimi richiesti, seguendo il principio del privilegio minimo.
• Azure Bastion -- Accesso amministrativo sicuro alle macchine virtuali di gestione senza esporre IP pubblici.

Monitoraggio e avvisi

• Avvisi automatizzati per eventi operativi e di sicurezza critici, tra cui violazioni dei limiti di velocità, errori di back-end, tentativi di accesso non autorizzati, modelli di blocco WAF, anomalie di latenza API ed errori di firma del modulo di protezione hardware.
• Registrazione diagnostica completa in tutti i componenti dell'infrastruttura, ovvero gateway API, gateway applicazione, applicazioni Web, database, vault di chiavi e modulo di protezione hardware, con i log raccolti in un'area di lavoro Log Analytics centralizzata.
• Dashboard per la visibilità operativa in tempo reale e l'analisi delle tendenze.

Governance:

• I controlli delle policy di pre-deployment (basati su OPA) applicano le baseline di sicurezza prima del provisioning dell'infrastruttura, incluse le restrizioni di accesso alla rete pubblica, le versioni minime di TLS, i requisiti di protezione per l'eliminazione e i controlli IP pubblici.
• I blocchi delle risorse impediscono l'eliminazione accidentale di archivi dati critici (insiemi di credenziali delle chiavi, database, account di archiviazione).

Torna all'inizio

Domande frequenti

D: Uso già DCSBC con Dell Command | Configurazione on-premise. È possibile eseguire la migrazione a DCSBC Cloud?

Sì. Entrambe le soluzioni utilizzano lo stesso protocollo sottostante a livello di BIOS (DACI con autenticazione PKI). I dispositivi forniti con la soluzione on-premise possono essere gestiti da DCSBC Cloud e viceversa, purché vengano utilizzati gli stessi certificati/chiavi. Sarà necessario caricare i certificati esistenti nel portale cloud DCSBC e assicurarsi che le chiavi private corrispondenti siano disponibili in Azure Managed HSM o Key Vault.

D: Dove viene eseguito DCSBC Cloud? È ospitato da Dell?

No. DCSBC Cloud viene implementato nell'abbonamento Microsoft Azure dell'utente. Tutta l'infrastruttura, ovvero elaborazione, archiviazione, database, HSM e rete, viene eseguita nel tenant Azure. Dell non ospita né ha accesso ai dati o all'infrastruttura del Cliente. Il provisioning automatico dell'intera soluzione avviene tramite Terraform.

D: Dell ha accesso alle policy, alle chiavi o ai dati di configurazione del BIOS?

No. Poiché DCSBC Cloud viene eseguito interamente all'interno dell'abbonamento di Azure, tutti i dati rimangono sotto il controllo e la proprietà dell'utente. Dell fornisce il software e i modelli Terraform, ma non accede, archivia o elabora i dati.

D: È possibile scegliere in quale area di Azure eseguire la distribuzione?

Sì. L'area di Azure è un parametro nella configurazione Terraform. È possibile eseguire il deployment in qualsiasi area di Azure supportata per soddisfare i requisiti di residenza e conformità dei dati. Il provisioning di tutte le risorse viene eseguito all'interno della singola regione selezionata.

D: È necessario installare Dell Command | Configurare sul server cloud DCSBC?

No. Non esiste un server on-premise. Il provisioning dell'infrastruttura viene effettuato nella sottoscrizione di Azure tramite Terraform e l'applicazione viene eseguita come servizi gestiti da Azure (servizio app, app per le funzioni, app Web statica).

D: È necessario installare software Dell sui dispositivi endpoint?

No. I pacchetti .intunewin distribuiti tramite Intune sono autonomi e includono tutti i componenti necessari. Non è richiesta l'installazione dell'agent endpoint.

D: Quali console di deployment sono supportate?

DCSBC Cloud attualmente supporta Microsoft Intune come console di deployment. DCSBC on-premise con DCC supporta inoltre SCCM e WorkspaceONE.

D: È possibile usare il proprio provider di protezione hardware anziché il modulo di protezione hardware gestito di Azure?

DCSBC Cloud è progettato per funzionare con Azure Managed HSM o Azure Key Vault. Se è necessario un provider di protezione hardware diverso, prendere in considerazione l'uso di DCSBC locale con DCC, che supporta il modulo di protezione hardware indipendente dal fornitore tramite lo script di HSMSigning.bat configurabile.

D: Quali dimensioni di chiavi RSA sono supportate?

DCSBC Cloud richiede esattamente chiavi RSA a 3072 bit . Le chiavi di altre dimensioni (2048 bit, 4096 bit e così via) verranno rifiutate durante la convalida del certificato.

D: È possibile utilizzare lo stesso certificato sia per le soluzioni DCSBC on-premise che per quelle cloud?

Sì, purché la chiave privata sia accessibile in entrambi gli ambienti, archiviati nel modulo di protezione hardware o nell'archivio certificati locale per la soluzione locale e nel modulo di protezione hardware gestito di Azure o in Key Vault per la soluzione cloud.

D: Cosa succede se il mio certificato scade?

I certificati scaduti non possono essere utilizzati per le operazioni di "aggiunta" (provisioning). Tuttavia, i certificati scaduti vengono accettati per le operazioni di deprovisioning, poiché l'intento è quello di rimuovere il provisioning dai dispositivi.

D: Quali impostazioni del BIOS è possibile configurare?

DCSBC Cloud include un registro completo degli attributi del BIOS che copre categorie come sicurezza, gestione dell'alimentazione e delle prestazioni, configurazione del sistema, video e configurazioni avanzate. Alcuni esempi includono SecureBoot, WakeOnLan, Boot Order, pianificazione AutoOn, Battery Charge Configuration, Keyboard Backlight Color e molti altri.

D. Quale versione di Terraform è necessaria per implementare DCSBC Cloud?

Terraform >= 1.3.0 è obbligatorio, con il provider AzureRM ~> 4.37.0.

D: È possibile personalizzare il deployment di Terraform (ad esempio, dimensioni delle SKU, scalabilità, ridondanza dello storage)?

Sì. La configurazione Terraform è completamente parametrizzata tramite variabili. È possibile personalizzare lo SKU del piano di servizio app, il livello di database, il tipo di replica di archiviazione (LRS/GRS/ZRS), le impostazioni di scalabilità automatica del gateway applicazione e altro ancora in base ai requisiti di scalabilità e disponibilità.