Dell Command | Sikker BIOS-konfigurasjon – SaaS-tilbud via Microsoft Azure Marketplace

Berørte produkter:

• Dell Command | Sikker BIOS-konfigurasjon
• Kommersielle Dell-klientenheter (bærbare PC-er, stasjonære datamaskiner, arbeidsstasjoner)

Innholdsfortegnelse:

• Introduksjon
• Distribusjonsmodell – driftes av Azure av kunden
• DCSBC Cloud kontra DCSBC lokalt (DCC)
• Infrastruktur som kode (Terraform)
• Forutsetninger
• Komme i gang – få tilgang til DCSBC Cloud Portal
• Opprette BIOS-policyer
  • Arbeidsflyt for godkjenningspolicy
  • Arbeidsflyt for policyer for BIOS-innstillinger
  • Arbeidsflyt for oppheving av provisjonering
• Sertifikatkrav og opplasting
• Publisere policyer til Microsoft Intune
• Sikkerhetskontroller
• Vanlige spørsmål

Introduksjon

Administrasjonsgrensesnitt er avhengige av åpne grensesnitt eller passordgodkjente kommandoer. Passordautentisering er sårbar for brute-force eller ordbokangrep, og dermed mindre sikker sammenlignet med nøkkelbasert autentisering. Et bedre godkjent administrasjonsgrensesnitt er nødvendig for å gi integritet og konfidensialitetsbeskyttelse av dataene og kommandoene. Dell Command | Konfigurasjon av sikker BIOS (DCSBC) er en tilnærming for å gå bort fra godkjenning av DACI-kommandoer med BIOS-passord. DCSBC gir klarert kommunikasjon ved å opprette et grensesnitt som bruker PKI-godkjenningsmekanismer (Public Key Infrastructure) og krypterte kanaler for å sende meldinger mellom plattformen og en klient. Denne tilnærmingen gir både integritet og konfidensialitet for å beskytte kundedata.
DCSBC Cloud utvider denne funksjonen til en nettskybasert SaaS-modell distribuert til kundens eget Azure-abonnement. I stedet for å installere og vedlikeholde en DCSBC-server lokalt med Dell Command | Konfigurere (DCC), IT-administratorer får tilgang til en nettbasert portal driftet i sitt eget Azure-miljø. Hele infrastrukturen klargjøres automatisk via Terraform (infrastruktur som kode). Policyer opprettes gjennom en veiledet, trinnvis nettportal og publiseres direkte til Microsoft Intune – uten konfigurasjon av lokal server, ingen generering av selvstendig kjørbar fil (SCE) og uten behov for installasjon av endepunktagent.

Viktige fordeler med DCSBC Cloud:

• Kunden eier sine data -All infrastruktur kjører i kundens Azure-abonnement. BIOS-policyer, kryptografiske nøkler, konfigurasjonsdata og revisjonslogger forblir under kundens fullstendige eierskap og kontroll. Dell har ikke tilgang til kundedata.
• Datasuverenitet og overholdelse - Kunder velger Azure-området for distribusjon, noe som sikrer at kravene til datalagring oppfylles. Alle data forblir innenfor det valgte området.
• Infrastruktur som kode – Hele løsningen klargjøres via Terraform, noe som gir repeterbare, reviderbare og versjonskontrollerte infrastrukturimplementeringer.
• Ingen lokal infrastruktur – Eliminerer behovet for å installere og vedlikeholde en DCSBC-server med Dell Command | Konfigurere.
• Nettbasert policyadministrasjon - Opprett og administrer BIOS-policyer fra en hvilken som helst nettleser ved hjelp av en intuitiv, trinnvis veiviser.
• Native Intune-integrering – Policyer publiseres direkte til Microsoft Intune som Win32 LOB-apper med ett enkelt klikk.
• Agentløs implementering – Ingen agent kreves på endepunkter. Den distribuerte pakken er selvstendig.
• Azure-administrert HSM-signering – Alle BIOS-nyttelaster er kryptografisk signert ved hjelp av Azure Managed HSM (RS384), noe som sikrer at bare autoriserte endringer når enhetene.
• Arkitektur med nulltillit – Det finnes bare klarering mellom BIOS og DCSBC Cloud-tjenesten. Det kreves ingen tillit på klienten/endepunktet.
• Innebygd forhindring av replay-angrep – Hver BIOS-økt bruker unike kryptografiske nonces og flyktige nøkkelutvekslinger, noe som sikrer at tidligere registrerte nyttelaster ikke kan brukes på nytt eller spilles av på nytt mot enheter.
• Kryptografisk enhetsbundet nyttelast – nyttelastene for BIOS-konfigurasjon er kryptografisk bundet til hver enkelt enhet under etablering av økten, noe som forhindrer at nyttelast som er ment for én enhet, brukes på en annen.

Tilbake til toppen

Distribusjonsmodell – driftes av Azure av kunden

I motsetning til tradisjonelle SaaS-tilbud der leverandøren er vert for infrastrukturen, distribueres DCSBC Cloud til kundens eget Microsoft Azure-abonnement. Denne arkitekturen gir flere kritiske fordeler:

• Dataeierskap og -kontroll: Alle Azure-ressurser – databehandling, lagring, database, HSM, nettverk – klargjøres i kundens Azure-leier og abonnement. BIOS-policykonfigurasjoner, kryptografiske signeringsnøkler, øktdata og revisjonslogger lagres i kundens egen Azure SQL Database, Azure Key Vault / administrert HSM- og Azure Storage-konto. Dell Technologies har ikke tilgang til kundens data, nøkler eller infrastruktur. Kunden beholder full administrativ kontroll.
• Datasuverenitet og overholdelse: Kunden velger Azure-området for distribusjon (f.eks. USA, øst 2, Vest-Europa, Australia, øst). Alle ressurser klargjøres innenfor ett enkelt område.
  Storage bruker lokalt redundant lagring (LRS) som standard, noe som sikrer at data ikke forlater det valgte området. Dette kan konfigureres til georedundant lagring (GRS) eller soneredundant lagring (ZRS) basert på kundens krav. Den kundebaserte modellen støtter overholdelse av datalagringsforskrifter (GDPR, lover om datasuverenitet, bransjespesifikke mandater) siden kunden kontrollerer hvor dataene ligger.
• Leietakerisolasjon: Hver kunde får en fullstendig isolert distribusjon: sin egen ressursgruppe, virtuelle nettverk, delnett, databaser, nøkkelhvelv og alle andre ressurser. Nettverksisolering håndheves gjennom private endepunkter, nettverkssikkerhetsgrupper og Azure-brannmur.
• Kostnadstransparens: Alle Azure-ressurskostnader vises i kundens egen Azure-fakturering, noe som gir full oversikt over infrastrukturutgiftene. Kunden kan dra nytte av eksisterende Azure-forpliktelser (MACC – forbruksforpliktelse for Microsoft Azure) og reserverte forekomster.

Tilbake til toppen

DCSBC Cloud kontra DCSBC lokalt (DCC)

Merk:
Begge løsningene deler den samme underliggende BIOS-nivåprotokollen, inkludert øktbaserte kommandoer med Diffie-Hellman-nøkkelutveksling, engangsbasert replay-beskyttelse og PKI-godkjenning. Policyer som er opprettet med begge løsningene, er kompatible med de samme kommersielle BIOS-implementeringene fra Dell.

Tilbake til toppen

Infrastruktur som kode (Terraform)

Hele DCSBC Cloud-infrastrukturen klargjøres ved hjelp av Terraform (HashiCorp), og gir repeterbare, reviderbare og versjonskontrollerte implementeringer. Terraform-konfigurasjonen er modulær og parametrisert, slik at hver kundedistribusjon kan tilpasses for Azure-området, navnekonvensjoner og skaleringskrav.
Oversikt over Terraform-konfigurasjon:

• Terraform versjon: >= 1.3.0
• AzureRM-leverandør: ~> 4.37.0
• Statlig styring: Ekstern tilstand lagret i Azure Storage-konto (Azure AD-autorisasjon)
• Azure-ressurser klargjort: Følgende ressurser klargjøres automatisk i kundens Azure-abonnement:

Tilbake til toppen

Forutsetninger

Før du bruker DCSBC Cloud, må du sørge for at følgende forutsetninger er oppfylt:

• Microsoft Azure-abonnement – et aktivt Azure-abonnement med en Azure Entra-ID (Azure AD)-leier.
• Microsoft Intune – Et aktivt Microsoft Intune-miljø konfigurert for enhetsadministrasjon.
• Kommersielle Dell-klientenheter – målenheter må være kommersielle bærbare og stasjonære PC-er eller arbeidsstasjoner fra Dell med DCSBC-kompatibel BIOS, registrert i Microsoft Intune.
• Azure Managed HSM eller Azure Key Vault – en Azure-administrert HSM- eller Key Vault-forekomst klargjort med RSA-HSM-nøkler som samsvarer med sertifikatene som brukes til BIOS-godkjenning. Den private nøkkelen må ligge i HSM; bare det offentlige sertifikatet (.pem) lastes opp til DCSBC Cloud Portal.
• X.509-sertifikater - RSA-sertifikater som oppfyller følgende krav:
  • Nøkkellengde: 3072-bit RSA (nøyaktig)
  • Format: PEM (.pem filtype)
  • Versjon: X.509 v3
  • Filstørrelse: Maks. 8 KB
  • Algoritme: RSA (OID 1.2.840.113549.1.1.1)
• Støttet nettleser - En moderne nettleser (Microsoft Edge, Google Chrome, Mozilla Firefox).

Tilbake til toppen

Komme i gang – få tilgang til DCSBC Cloud Portal

• Abonner – kjøp Dell Command | Sikker BIOS-konfigurasjonsnettsky via Microsoft Azure Marketplace.
• Logg på – Naviger til URL-adressen for DCSBC Cloud-portalen som du fikk ved abonnement. Logg på med legitimasjonen for Microsoft Entra ID (Azure AD). Portalen bruker Microsoft Authentication Library (MSAL) for enkel pålogging.
• Destinasjonsside – Etter godkjenning omdirigeres du til instrumentbordet for BIOS-policyer. Herfra kan du:
  • Vise eksisterende BIOS-policyer som er publisert i Intune-leieren
  • Opprett en ny policy ved hjelp av den trinnvise nettportalen

Tilbake til toppen

Opprette BIOS-policyer

Fra siden BIOS-policyer klikker du på Opprett en ny policy. Du vil se tre policytyper:

Velg en policytype for å starte den veiledede veiviseren. Disse policyene distribueres direkte fra Intune til endepunktene dine uten at det kreves installasjon av noen endepunktagenter.

Merk:

I alle tilfeller kan bare én klargjøringsnøkkel klargjøres på en klientmaskin.

Merk:

Opptil sju kommandonøkler kan klargjøres på en klientmaskin i en gitt forekomst.

Arbeidsflyt for godkjenningspolicy

Veiviseren for godkjenningspolicy har tre trinn:

Trinn 1 - Navngi politikken din

• Skriv inn et policynavn (obligatorisk, maks. 488 tegn). Prefikset AUTH_ og tidsangivelsessuffikset _DD.MM.YY_HH:mm_UTC legges til automatisk.
• Skriv inn en valgfri beskrivelse (maks. 1000 tegn).
• Det fullstendige retningslinjenavnet (inkludert prefiks og suffiks, maks. 512 tegn) forhåndsvises før du fortsetter.
• Dupliserte policynavn oppdages automatisk ved kontroll mot eksisterende publiserte policyer i Intune.

Trinn 2 – Administrer BIOS-sikkerhet (sertifikatopplasting)

• Last opp opptil tre sertifikater totalt:
  • 1 Klargjøringssertifikat (obligatorisk) – brukes til å godkjenne sikker tilkobling for klargjøringsoperasjoner.
  • Opptil to kommandosertifikater – brukes til å signere nyttelast for BIOS-konfigurasjonsendringer.
• For hvert sertifikat velger du: 
  • Type: Provisjonering eller kommando
  • Politiske tiltak: Add (klargjør en ny nøkkel)
• Sertifikater valideres på klientsiden (se Sertifikatkrav og Last opp).
• Neste-knappen blir aktivert når:
  • Et provisjoneringssertifikat lastes opp
  • 1 Kommandosertifikatet er lastet opp

Trinn 3 – Se gjennom og publiser

• Se gjennom policynavnet, beskrivelsen og typen.
• Klikk Publiser for å publisere policyen til Microsoft Intune (se Publiseringspolicyer til Microsoft Intune).

Tilbake til toppen

Arbeidsflyt for policyer for BIOS-innstillinger

Veiviseren for BIOS-innstillinger har 4 eller 5 trinn (avhengig av om det finnes eksisterende BIOS-policyer i Intune):

Trinn 1 - Kopier og rediger, eller Start fra bunnen av (betinget - vises bare hvis eksisterende retningslinjer eksisterer)

• Start en tom policyfil – begynn med en tom konfigurasjon.
• Kopier og rediger deretter – kopier BIOS-attributtverdier fra en eksisterende, publisert retningslinje og endre dem. En modal viser en søkbar, sorterbar, paginert liste over eksisterende BIOS-policyer.

Trinn 2 - Navngi politikken din

• Samme som for godkjenningspolicy, men med prefikset BIOS_.

Trinn 3 – Velg BIOS-attributter og -verdier

• En tabell viser alle tilgjengelige BIOS-attributter fra Dell-attributtregisteret.
• Søk etter attributter etter navn, filtrer etter kategori, og veksle for å vise bare valgte attributter.
• Velg et attributt ved å klikke i avmerkingsboksen, og konfigurer deretter verdien:
  • Opplisting av attributter (f.eks. SecureBoot, WakeOnLan) – Velg fra en rullegardinliste med tillatte verdier.
  • Heltallsattributter (f.eks. AutoOnHr, CustomChargeStart) - Skriv inn et tall innenfor min-max-området.
  • Strengattributter (f.eks. AssetTag) – Skriv inn tekst på opptil 80 tegn.
  • Egendefinerte funksjoner (f.eks. AutoOn-planlegging, batteriladekonfigurasjon, farge på tastaturbakgrunnsbelysning) - Klikk på "Vis/endre" for å åpne en dedikert konfigurasjonsmodal.
• Et panel for forhåndsvisning av kode viser en direkte forhåndsvisning av den valgte konfigurasjonen i CCTK-format:

[cctk]

SecureBoot=Enabled

WakeOnLan=LanOnly

AutoOn=SelectDays

AutoOnMon=Enabled

AutoOnTue=Enabled

• Neste-knappen deaktiveres hvis ingen attributter er valgt eller et valgt attributt har en ugyldig verdi.

Trinn 4 – administrer BIOS-sikkerhet

• Last opp det samme kommandosertifikatet som ble brukt for godkjenningspolicyen.
• Det kreves ett kommandosertifikat for å fortsette.

Trinn 5 – Se gjennom og publiser

• Se gjennom og publiser til Microsoft Intune.

Tilbake til toppen

Arbeidsflyt for oppheving av provisjonering

Veiviseren for deprovisioning policy har tre trinn:

Trinn 1 - Navngi politikken din

• Samme som for andre retningslinjer, med prefikset DPRV_.

Trinn 2 – Administrer BIOS-sikkerhet

• Last opp det samme klargjøringssertifikatet som ble brukt for godkjenningspolicyen.
• Det kreves ett provisjoneringssertifikat.
• Merk: Utløpte sertifikater er tillatt for oppheving av klargjøringsoperasjoner, siden formålet er å fjerne klargjøring fra enheter.

Trinn 3 – Se gjennom og publiser

• Se gjennom og publiser. Policyen for fjerning av klargjøring bruker en Fjern DACI-operasjon for å fjerne alle klargjorte nøkler fra målenhetene.

Tilbake til toppen

Sertifikatkrav og opplasting

DCSBC Cloud krever X.509-sertifikater i PEM-format for signering av BIOS-nyttelast. Den private nøkkelen må lagres i Azure Managed HSM eller Azure Premium Key Vault. bare det offentlige sertifikatet lastes opp til DCSBC-portalen.

Regler for sertifikatgodkjenning:

Validering utføres på klientsiden. Når et sertifikat er lastet opp, viser portalen:

• Valideringsstatusmerke (vellykket / mislykket)
• Utstedt på dato
• Gyldig til dato (vises i rødt hvis utløpt)
• Utstederdetaljer: Vanlig navn (CN), organisasjonsenhet (OU), organisasjon (O), plassering (L)

Feilmeldinger

• "Last opp en gyldig .pem-fil." - Filen er ikke i PEM-format eller har feil filtype.
• "Filnavnet inneholder ugyldige tegn." -- Filnavnet inneholder mellomrom eller spesialtegn.
• "Maksimal størrelse for filen er 8 KB" -- Filen overskrider grensen på 8 kB.
• "Denne filen er ugyldig, ødelagt eller tom. Velg en annen fil med et gyldig x509-sertifikat, og prøv på nytt." --Sertifikatet kan ikke analyseres eller mislykkes X.509 v3 / RSA / 3072-bit validering.
• "Dette sertifikatet kan ikke brukes." -- Sertifikatet er utløpt, og policyhandlingen er Legg til.

Tilbake til toppen

Publisere policyer til Microsoft Intune

Når du har fullført policyveiviseren, klikker du Publiser-knappen i trinnet Se gjennom og publiser. Portalen utfører en automatisert 11-trinns publiseringspipeline:

En fremdriftslinje og detaljert scenesporing viser publiseringsstatus i sanntid. Etter vellykket gjennomføring:

• Meldingen "{policyName}-policyen er publisert i Intune og vil være tilgjengelig i løpet av få minutter" vises.
• Vis i Intune – åpner administrasjonsportalen for Microsoft Intune i en ny fane.
• Tilbake til policyer – går tilbake til instrumentbordet for BIOS-policyer.

Feilhåndtering: Hvis et trinn mislykkes, vises en feilmelding med knappen Prøv på nytt (opptil 3 nye forsøk). Vanlige feil inkluderer tidsavbrudd for Intune API, feil ved opplasting av lagring og forsinkelser i filutførelse.

Tilbake til toppen

Sikkerhetskontroller

DCSBC Cloud implementerer dyptgående forsvar for sikkerhet på tvers av alle lag av infrastrukturen. Siden løsningen kjører i kundens Azure-abonnement, er alle sikkerhetskontroller reviderbare og under kundens styring.

Nettverkssikkerhet:

• Private endepunkter sikrer at trafikk mellom Azure-tjenester (database, nøkkelhvelv, HSM, lagring, apptjenester) aldri krysser det offentlige Internett.
• Offentlig nettverkstilgang er deaktivert som standard for alle dataplantjenester. Bare API-gatewayen og CDN-endepunktene er offentlig tilgjengelige.
• NSG-er (Network Security Groups) kontrollerer innkommende og utgående trafikk for hvert delnett med detaljerte regler.
• Virtuell nettverksisolasjon – Alle ressurser distribueres i én enkelt VNet med adskilte delnett for hvert tjenestenivå.

Applikasjonssikkerhet:

• Web Application Firewall (WAF) med bransjestandard OWASP-administrerte regelsett i forhindringsmodus, som gir beskyttelse mot vanlige webutnyttelser (SQL-injeksjon, XSS osv.).
• Brannmur på CDN-nivå gir et ekstra WAF-lag på kanten.
• API-hastighetsbegrensning -- Per-operasjon, IP-basert hastighetsbegrensning beskytter backend-tjenester mot misbruk og denial-of-service-angrep.
• Azure AD JWT-tokenvalidering – Alle API-kall valideres for Azure AD-godkjenningstokener, noe som sikrer at bare autoriserte brukere får tilgang til serverdeltjenester.
• CORS-restriksjoner -- Forespørsler på tvers av opprinnelse er begrenset til kun autorisert opprinnelse.

Kryptering

• Minimum TLS 1.2 håndheves på tvers av alle tjenester med bare sterke chiffreringssamlinger tillatt.
• Azure-administrert HSM – Kryptografiske signeringsoperasjoner bruker FIPS 140-2 nivå 3-validerte maskinvaresikkerhetsmoduler, noe som sikrer at nøkler aldri eksponeres i programvare.
• Inaktive data krypteres ved hjelp av Azure-plattformkryptering på tvers av alle lagringstjenester.

Identitet og tilgang:

• Administrerte identiteter (null lagret legitimasjon) – Azure administrerte identiteter brukes for all tjeneste-til-tjeneste-godkjenning. Ingen passord, tilkoblingsstrenger eller hemmeligheter lagres i programkonfigurasjonen.
• Minste privilegium for RBAC – Hver administrerte identitet tilordnes bare de minste nødvendige rollene, i henhold til prinsippet om minste privilegium.
• Azure Bastion – Sikker administrativ tilgang til administrasjons-VM-er uten å eksponere offentlige IP-adresser.

Overvåking og varsling

• Automatiserte varsler for kritiske sikkerhets- og driftshendelser, inkludert hastighetsbegrensende brudd, backend-feil, uautoriserte tilgangsforsøk, WAF-blokkeringsmønstre, API-ventetidsavvik og HSM-signeringsfeil.
• Omfattende diagnoselogging på tvers av alle infrastrukturkomponenter – API gateway, application gateway, webapplikasjoner, database, nøkkelhvelv og HSM – med logger samlet inn i et sentralisert Log Analytics-arbeidsområde.
• Dashbord for driftssynlighet og trendanalyse i sanntid.

Styring og ledelse:

• Policykontroller før implementering (OPA-basert) håndhever sikkerhetsgrunnlinjer før infrastruktur klargjøres, inkludert begrensninger for offentlig nettverkstilgang, minimum TLS-versjoner, krav til tømmingsbeskyttelse og offentlige IP-kontroller.
• Ressurslåser forhindrer utilsiktet sletting av kritiske datalagre (nøkkelhvelv, databaser, lagringskontoer).

Tilbake til toppen

Vanlige spørsmål

Spørsmål: Jeg bruker allerede DCSBC med Dell Command | Konfigurer lokalt. Kan jeg migrere til DCSBC Cloud?

Ja. Begge løsningene bruker samme underliggende protokoll på BIOS-nivå (DACI med PKI-godkjenning). Enheter som klargjøres med den lokale løsningen, kan administreres av DCSBC Cloud og omvendt, så lenge de samme sertifikatene/nøklene brukes. Du må laste opp eksisterende sertifikater til DCSBC Cloud Portal og sørge for at de tilsvarende private nøklene er tilgjengelige i Azure Managed HSM eller Key Vault.

Spørsmål: Hvor kjører DCSBC Cloud? Er det vert for Dell?

Nei. DCSBC Cloud distribueres til ditt eget Microsoft Azure-abonnement. All infrastruktur – databehandling, lagring, database, HSM, nettverk – kjører i Azure-leieren. Dell drifter ikke og har ikke tilgang til dataene eller infrastrukturen din. Hele løsningen klargjøres automatisk ved hjelp av Terraform.

Spørsmål: Har Dell tilgang til BIOS-retningslinjene, -nøklene eller konfigurasjonsdataene mine?

Nei. Siden DCSBC Cloud kjører helt innenfor Azure-abonnementet ditt, forblir alle data under ditt eierskap og kontroll. Dell leverer programvaren og Terraform-malene, men får ikke tilgang til, lagrer eller behandler ikke dataene dine.

Spørsmål: Kan jeg velge hvilket Azure-område jeg vil distribuere i?

Ja. Azure-området er en parameter i Terraform-konfigurasjonen. Du kan distribuere til et hvilket som helst støttet Azure-område for å oppfylle kravene til datalagring og forskriftssamsvar. Alle ressurser klargjøres i det enkeltvalgte området.

Sp.: Må jeg installere Dell Command | Konfigurere på DCSBC Cloud-serveren?

Nei. Det finnes ingen lokal server. Infrastrukturen klargjøres i Azure-abonnementet via Terraform, og programmet kjører som Azure-administrerte tjenester (App Service, Function App, Static Web App).

Sp: Må jeg installere Dell-programvare på endepunktsenhetene?

Nei. .intunewin-pakkene som distribueres via Intune, er selvstendige og inkluderer alle nødvendige komponenter. Ingen installasjon av endepunktagent er nødvendig.

Spørsmål: Hvilke distribusjonskonsoller støttes?

DCSBC Cloud støtter for øyeblikket Microsoft Intune som distribusjonskonsoll. Den lokale DCSBC-en med DCC støtter i tillegg SCCM og WorkspaceONE.

Spørsmål: Kan jeg bruke min egen HSM-leverandør i stedet for Azure Managed HSM?

DCSBC Cloud er utformet for å fungere med Azure Managed HSM eller Azure Key Vault. Hvis du trenger en annen HSM-leverandør, bør du vurdere å bruke DCSBC lokalt med DCC, som støtter leverandøragnostisk HSM via det konfigurerbare HSMSigning.bat-skriptet.

Spørsmål: Hvilke RSA-nøkkelstørrelser støttes?

DCSBC Cloud krever nøyaktig 3072-biters RSA-nøkler . Nøkler av andre størrelser (2048-biters, 4096-biters osv.) vil bli avvist under sertifikatvalideringen.

Spørsmål: Kan jeg bruke det samme sertifikatet for DCSBC-løsninger både lokalt og i skyen?

Ja, så lenge den private nøkkelen er tilgjengelig i begge miljøer – lagret i ditt lokale HSM-/sertifikatlager for den lokale løsningen, og i Azure Managed HSM eller Key Vault for skyløsningen.

Q: Hva skjer hvis sertifikatet mitt utløper?

Utløpte sertifikater kan ikke brukes for "Legg til" (klargjøring) operasjoner. Utløpte sertifikater godtas imidlertid for deprovisioning-operasjoner, siden hensikten er å fjerne klargjøring fra enheter.

Sp: Hvilke BIOS-innstillinger kan jeg konfigurere?

DCSBC Cloud inkluderer et omfattende BIOS-attributtregister som dekker kategorier som sikkerhet, strøm- og ytelsesadministrasjon, systemkonfigurasjon, video og avanserte konfigurasjoner. Eksempler inkluderer SecureBoot, WakeOnLan, oppstartsrekkefølge, AutoOn-planlegging, batteriladekonfigurasjon, farge på tastaturbakgrunnsbelysning og mange flere.

Spørsmål: Hvilken Terraform-versjon kreves for å distribuere DCSBC Cloud?

Terraform >= 1.3.0 kreves, med AzureRM-leverandøren ~> 4.37.0.

Spørsmål: Kan jeg tilpasse Terraform-distribusjonen (f.eks. SKU-størrelser, skalering, lagringsredundans)?

Ja. Terraform-konfigurasjonen er fullstendig parametrisert via variabler. Du kan tilpasse SKU-en for App Service-abonnementet, databasenivået, lagringsreplikeringstypen (LRS/GRS/ZRS), Application Gateways autoskaleringsinnstillinger og mer, basert på kravene dine til skalering og tilgjengelighet.