Dell Command | Sichere BIOS-Konfiguration – SaaS-Angebot über Microsoft Azure Marketplace

Betroffene Produkte:

• Unterstützt Dell Command Secure BIOS Configuration.
• Dell Client-Geräte (Laptops, Desktop-PCs, Workstations)

Inhaltsverzeichnis:

• Einführung
• Bereitstellungsmodell – vom Kunden gehostet auf Azure
• DCSBC Cloud im Vergleich zu DCSBC On-Premise (DCC)
• Infrastructure as Code (Terraform)
• Voraussetzungen
• Erste Schritte – Zugriff auf das DCSBC-Cloud-Portal
• Erstellen von BIOS-Richtlinien
  • Workflow für Authentifizierungsrichtlinien
  • Workflow für BIOS-Einstellungsrichtlinien
  • Workflow für Aufhebungsrichtlinie
• Zertifikatanforderungen und Upload
• Veröffentlichen von Policies in Microsoft Intune
• Sicherheitskontrollen
• FAQs

Einführung

Verwaltungsschnittstellen basieren auf offenen Schnittstellen oder kennwortauthentifizierten Befehlen. Die Kennwortauthentifizierung ist anfällig für Brute-Force- oder Wörterbuchangriffe und daher im Vergleich zur schlüsselbasierten Authentifizierung weniger sicher. Eine besser authentifizierte Verwaltbarkeitsschnittstelle ist erforderlich, um Integrität und Vertraulichkeit der Daten und Befehle zu schützen. Dell Command | Die sichere BIOS-Konfiguration (DCSBC) ist ein Ansatz zur Abkehr von der Authentifizierung von DACI-Befehlen mit BIOS-Kennwörtern. DCSBC bietet vertrauenswürdige Kommunikation durch Erstellen einer Schnittstelle, die PKI-Authentifizierungsmechanismen (Public Key Infrastructure) und verschlüsselte Kanäle verwendet, um Nachrichten zwischen der Plattform und einem Client weiterzuleiten. Dieser Ansatz bietet Integrität und Vertraulichkeit zum Schutz von Kundendaten.
DCSBC Cloud erweitert diese Funktion auf ein in der Cloud gehostetes SaaS-Modell, das im Azure-Abonnement des Kunden bereitgestellt wird. Anstatt einen DCSBC-Server vor Ort mit Dell Command | Configure (DCC) verwenden IT-Administratoren den Zugriff auf ein webbasiertes Portal, das in ihrer eigenen Azure-Umgebung gehostet wird. Die gesamte Infrastruktur wird automatisch über Terraform (Infrastructure as Code) bereitgestellt. Policies werden über ein Schritt-für-Schritt-Webportal erstellt und direkt in Microsoft Intune veröffentlicht – ohne lokale Servereinrichtung, ohne Erstellung von SCE (Self-Contained Executable) und ohne Installation eines Endpunkt-Agent.

Die wichtigsten Vorteile von DCSBC Cloud:

• Der Kunde ist Eigentümer seiner Daten –Die gesamte Infrastruktur wird im Azure-Abonnement des Kunden ausgeführt. BIOS-Richtlinien, kryptografische Schlüssel, Konfigurationsdaten und Auditprotokolle bleiben unter dem vollständigen Eigentum und der Kontrolle des Kunden. Dell hat keinen Zugriff auf Kundendaten.
• Datenhoheit und Compliance – Kunden wählen die Azure-Region für die Bereitstellung aus, um sicherzustellen, dass die Anforderungen an den Datenspeicherort erfüllt sind. Alle Daten bleiben innerhalb der ausgewählten Region.
• Infrastructure as Code: Die gesamte Lösung wird über Terraform bereitgestellt und bietet wiederholbare, überprüfbare und versionsgesteuerte Infrastrukturbereitstellungen.
• Keine On-Premise-Infrastruktur – Keine Installation und Wartung eines DCSBC-Servers mehr erforderlich dank Dell Command | Konfigurieren Sie.
• Webbasiertes Policy-Management: Erstellen und managen Sie BIOS-Policies mit einem intuitiven Schritt-für-Schritt-Assistenten von jedem Browser aus.
• Native Intune-Integration – Policies werden mit einem einzigen Klick direkt in Microsoft Intune als Win32-LOB-Apps veröffentlicht.
• Bereitstellung ohne Agent: Auf Endpunkten ist kein Agent erforderlich. Das bereitgestellte Paket ist eigenständig.
• Azure Managed HSM-Signatur – Alle BIOS-Payloads werden mithilfe von Azure Managed HSM (RS384) kryptografisch signiert, um sicherzustellen, dass nur autorisierte Änderungen die Geräte erreichen.
• Zero-Trust-Architektur – Die Vertrauensbeziehung besteht nur zwischen dem BIOS und dem DCSBC-Cloudservice. Auf dem Client/Endpunkt ist keine Vertrauensstellung erforderlich.
• Integrierte Prävention von Replay-Angriffen: Jede BIOS-Sitzung verwendet eindeutige kryptografische Nonces und kurzlebigen Schlüsselaustausch, um sicherzustellen, dass zuvor erfasste Payloads nicht wiederverwendet oder gegen Geräte wiedergegeben werden können.
• Kryptografisch gerätegebundene Payloads – BIOS-Konfigurations-Payloads sind während der Einrichtung der Sitzung kryptografisch an jedes einzelne Gerät gebunden, wodurch verhindert wird, dass Payloads, die für ein Gerät vorgesehen sind, auf ein anderes angewendet werden.

Zurück zum Anfang

Bereitstellungsmodell – vom Kunden gehostet auf Azure

Im Gegensatz zu herkömmlichen SaaS-Angeboten, bei denen der Anbieter die Infrastruktur hostet, wird DCSBC Cloud im Microsoft Azure-Abonnement des Kunden bereitgestellt. Diese Architektur bietet mehrere entscheidende Vorteile:

• Dateneigentum und -kontrolle: Alle Azure-Ressourcen – Compute, Storage, Datenbank, HSM, Netzwerke – werden innerhalb des Azure-Mandanten und -Abonnements des Kunden bereitgestellt. BIOS-Policy-Konfigurationen, kryptografische Signaturschlüssel, Sitzungsdaten und Auditprotokolle werden in der Azure SQL-Datenbank, in Azure Key Vault/Managed HSM und im Azure-Storage-Konto gespeichert. Dell Technologies hat keinen Zugriff auf die Daten, Schlüssel oder Infrastruktur des Kunden. Der Kunde behält die vollständige administrative Kontrolle.
• Datenhoheit und Compliance: Der Kunde wählt die Azure-Region für die Bereitstellung aus (z. B. "USA, Osten 2", "Europa, Westen", "Australien, Osten"). Alle Ressourcen werden in dieser einzelnen Region bereitgestellt.
  Storage verwendet standardmäßig LRS (Local Redundant Storage, lokal redundanten Speicher), um sicherzustellen, dass die Daten die ausgewählte Region nicht verlassen. Dies kann je nach Kundenanforderungen auf Georedundanten Speicher (GRS) oder zonenredundanten Speicher (ZRS) konfiguriert werden. Das vom Kunden gehostete Modell unterstützt die Compliance mit Datenresidenzbestimmungen (DSGVO, Datenhoheitsgesetze, branchenspezifische Vorgaben), da der Kunde kontrolliert, wo sich die Daten befinden.
• Mandantenisolierung: Jeder Kunde erhält eine vollständig isolierte Bereitstellung: seine eigene Ressourcengruppe, sein eigenes virtuelles Netzwerk, Subnetze, Datenbanken, Schlüsseltresore und alle anderen Ressourcen. Die Netzwerkisolierung wird über private Endpunkte, Netzwerksicherheitsgruppen und Azure Firewall erzwungen.
• Kostentransparenz: Alle Azure-Ressourcenkosten werden in der Azure-Fakturierung des Kunden aufgeführt und bieten so einen vollständigen Einblick in die Infrastrukturausgaben. Der Kunde kann vorhandene Azure-Verpflichtungen (MACC – Microsoft Azure Consumption Commitment) und reservierte Instanzen nutzen.

Zurück zum Anfang

DCSBC Cloud im Vergleich zu DCSBC On-Premise (DCC)

Hinweis:
Beide Lösungen verwenden dasselbe zugrunde liegende Protokoll auf BIOS-Ebene, einschließlich sitzungsbasierter Befehle mit Diffie-Hellman-Schlüsselaustausch, Nonce-basiertem Replay-Schutz und PKI-Authentifizierung. Policies, die mit beiden Lösungen erstellt wurden, sind mit denselben kommerziellen Dell Client-BIOS-Implementierungen kompatibel.

Zurück zum Anfang

Infrastructure as Code (Terraform)

Die gesamte DCSBC Cloud-Infrastruktur wird mit Terraform (HashiCorp) bereitgestellt und bietet wiederholbare, überprüfbare und versionsgesteuerte Bereitstellungen. Die Terraform-Konfiguration ist modular und parametrisiert, sodass jede Kundenbereitstellung an die Azure-Region, Benennungskonventionen und Skalierungsanforderungen angepasst werden kann.
Übersicht über die Terraform-Konfiguration:

• Terraform-Version: >= 1.3.0
• AzureRM-Anbieter: ~> 4.37.0
• Zustandsverwaltung: In Azure Storage-Konto gespeicherter Remotestatus (Azure AD-Authentifizierung)
• Bereitgestellte Azure-Ressourcen: Die folgenden Ressourcen werden automatisch im Azure-Abonnement des Kunden bereitgestellt:

Zurück zum Anfang

Voraussetzungen

Bevor Sie DCSBC Cloud verwenden, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:

• Microsoft Azure-Abonnement : Ein aktives Azure-Abonnement mit einem Azure Entra ID-Mandanten (Azure AD).
• Microsoft Intune – Eine aktive Microsoft Intune-Umgebung, die für das Gerätemanagement konfiguriert ist.
• Dell Client-Geräte : Zielgeräte müssen Dell Laptops, Desktop-PCs oder Workstations mit DCSBC-fähigem BIOS sein, die in Microsoft Intune registriert sind.
• Azure Managed HSM oder Azure Key Vault : Eine Azure Managed HSM- oder Key Vault-Instanz, die mit RSA-HSM-Schlüsseln bereitgestellt wird, die den für die BIOS-Authentifizierung verwendeten Zertifikaten entsprechen. Der private Schlüssel muss sich im HSM befinden. Nur das öffentliche Zertifikat (.pem) wird in das DCSBC Cloud-Portal hochgeladen.
• X.509-Zertifikate – RSA-Zertifikate, die die folgenden Anforderungen erfüllen:
  • Schlüssellänge: 3072-Bit RSA (genau)
  • Format: PEM (.pem-Dateierweiterung)
  • Version: X.509 v3
  • Dateigröße: maximal 8 KB
  • Algorithmus: RSA (OID 1.2.840.113549.1.1.1)
• Unterstützter Browser – Ein moderner Webbrowser (Microsoft Edge, Google Chrome, Mozilla Firefox).

Zurück zum Anfang

Erste Schritte – Zugriff auf das DCSBC-Cloud-Portal

• Abonnieren – Dell Command kaufen | Sichere BIOS-Konfigurations-Cloud über den Microsoft Azure Marketplace.
• Anmelden : Navigieren Sie zur bei der Anmeldung angegebenen DCSBC Cloud-Portal-URL. Melden Sie sich mit Ihren Microsoft Entra ID (Azure AD)-Anmeldeinformationen an. Das Portal verwendet Microsoft Authentication Library (MSAL) für einmaliges Anmelden.
• Landingpage : Nach der Authentifizierung werden Sie zum Dashboard "BIOS Policies" weitergeleitet. Hier können Sie:
  • Anzeigen vorhandener BIOS-Richtlinien, die für Ihren Intune-Mandanten veröffentlicht wurden
  • Erstellen einer neuen Policy über das schrittweise Webportal

Zurück zum Anfang

Erstellen von BIOS-Richtlinien

Klicken Sie auf der Seite BIOS Policies auf Create a new policy. Es werden drei Typen von Policies angezeigt:

Wählen Sie einen Richtlinientyp aus, um den Assistenten mit Anleitung zu starten. Diese Policies werden direkt von Intune auf Ihren Endpunkten bereitgestellt, ohne dass eine Installation von Endpunkt-Agents erforderlich ist.

Hinweis:

In jeder Instanz kann nur ein Bereitstellungsschlüssel auf einem Clientcomputer bereitgestellt werden.

Hinweis:

Bis zu sieben Befehlsschlüssel können auf einem Clientcomputer zu jeder beliebigen Instanz bereitgestellt werden.

Workflow für Authentifizierungsrichtlinien

Der Assistent für die Authentifizierungs-Policy umfasst 3 Schritte:

Schritt 1: Benennen der Policy

• Geben Sie einen Policy-Namen ein (erforderlich, max. 488 Zeichen). Ein Präfix-AUTH_ und ein Zeitstempelsuffix _DD.MM.YY_HH:mm_UTC werden automatisch hinzugefügt.
• Geben Sie eine optionale Beschreibung ein (max. 1.000 Zeichen).
• Der vollständige Name der Policy (einschließlich Präfix und Suffix, max. 512 Zeichen) wird vor dem Fortfahren in der Vorschau angezeigt.
• Doppelte Richtliniennamen werden automatisch erkannt, indem vorhandene veröffentlichte Richtlinien in Intune überprüft werden.

Schritt 2: Verwalten der BIOS-Sicherheit (Zertifikat-Upload)

• Laden Sie insgesamt bis zu 3 Zertifikate hoch:
  • 1 Bereitstellungszertifikat (erforderlich): wird verwendet, um die sichere Konnektivität für Bereitstellungsvorgänge zu authentifizieren.
  • Bis zu 2 Befehlszertifikate: Wird zum Signieren von Payloads für BIOS-Konfigurationsänderungen verwendet.
• Wählen Sie für jedes Zertifikat Folgendes aus: 
  • Typ: Bereitstellung oder Befehl
  • Richtlinienaktion: Hinzufügen (Bereitstellung eines neuen Schlüssels)
• Zertifikate werden clientseitig validiert (siehe Zertifikatanforderungen und Upload).
• Die Schaltfläche Next wird aktiviert, wenn:
  • Ein Bereitstellungszertifikat wird hochgeladen
  • 1 Befehlszertifikat wird hochgeladen

Schritt 3: Überprüfen und veröffentlichen

• Überprüfen Sie den Namen, die Beschreibung und den Typ der Policy.
• Klicken Sie auf Veröffentlichen, um die Policy in Microsoft Intune zu veröffentlichen (siehe Veröffentlichen von Policies in Microsoft Intune).

Zurück zum Anfang

Workflow für BIOS-Einstellungsrichtlinien

Der Assistent für BIOS-Einstellungsrichtlinien umfasst 4 oder 5 Schritte (je nachdem, ob vorhandene BIOS-Richtlinien in Intune vorhanden sind):

Schritt 1: Kopieren und bearbeiten oder von Grund auf neu beginnen (bedingt – wird nur angezeigt, wenn vorhandene Richtlinien vorhanden sind)

• Start a blank policy file – Beginnen Sie mit einer leeren Konfiguration.
• Kopieren und dann bearbeiten – BIOS-Attributwerte aus einer vorhandenen veröffentlichten Policy kopieren und ändern. Ein Modal zeigt eine durchsuchbare, sortierbare, paginierte Liste der vorhandenen BIOS-Policies an.

Schritt 2: Benennen der Policy

• Identisch mit der Authentifizierungsrichtlinie, jedoch mit dem Präfix BIOS_.

Schritt 3: BIOS-Attribute und -Werte auswählen

• Eine Tabelle zeigt alle verfügbaren BIOS-Attribute aus der Dell Attributregistrierung an.
• Suchen Sie nach Attributen nach Namen, filtern Sie nach Kategorie und schalten Sie um, um nur ausgewählte Attribute anzuzeigen.
• Wählen Sie ein Attribut aus, indem Sie auf das entsprechende Kontrollkästchen klicken, und konfigurieren Sie dann seinen Wert:
  • Enum-Attribute (z. B. SecureBoot, WakeOnLan): Wählen Sie aus einer Drop-down-Liste zulässiger Werte aus.
  • Ganzzahlige Attribute (z. B. AutoOnHr, CustomChargeStart): Geben Sie eine Zahl innerhalb des Min-Max-Bereichs ein.
  • Zeichenfolgenattribute (z. B. AssetTag) – Geben Sie Text mit bis zu 80 Zeichen ein.
  • Nutzerdefinierte Funktionen (z. B. AutoOn-Planung, Konfiguration des Akkuladezustands, Farbe der Tastaturhintergrundbeleuchtung) – Klicken Sie auf "Anzeigen/Ändern", um ein dediziertes Konfigurationsmodal zu öffnen.
• Ein Codevorschaufenster zeigt eine Live-Vorschau der ausgewählten Konfiguration im CCTK-Format an:

[cctk]

SecureBoot=Enabled

WakeOnLan=LanOnly

AutoOn=SelectDays

AutoOnMon=Enabled

AutoOnTue=Enabled

• Die Schaltfläche Weiter ist deaktiviert, wenn keine Attribute ausgewählt sind oder ein ausgewähltes Attribut einen ungültigen Wert hat.

Schritt 4: Verwalten der BIOS-Sicherheit

• Laden Sie dasselbe Befehlszertifikat hoch, das für die Authentifizierungs-Policy verwendet wurde.
• Es ist ein Befehlszertifikat erforderlich, um fortzufahren.

Schritt 5: Überprüfen und veröffentlichen

• Überprüfung und Veröffentlichung in Microsoft Intune.

Zurück zum Anfang

Workflow für Aufhebungsrichtlinie

Der Assistent Deprovisioning Policy umfasst 3 Schritte:

Schritt 1: Benennen der Policy

• Wie bei anderen Policies mit dem Präfix DPRV_.

Schritt 2: Verwalten der BIOS-Sicherheit

• Laden Sie dasselbe Bereitstellungszertifikat hoch, das für die Authentifizierungsrichtlinie verwendet wurde.
• Ein Bereitstellungszertifikat ist erforderlich.
• Hinweis: Abgelaufene Zertifikate sind für die Aufhebung der Bereitstellung zulässig, da der Zweck darin besteht, die Bereitstellung von Geräten zu entfernen.

Schritt 3: Überprüfen und veröffentlichen

• Überprüfen und veröffentlichen. Die Policy zur Aufhebung der Bereitstellung verwendet einen Clear DACI-Vorgang, um alle bereitgestellten Schlüssel von den Zielgeräten zu entfernen.

Zurück zum Anfang

Zertifikatanforderungen und Upload

DCSBC Cloud erfordert X.509-Zertifikate im PEM-Format für die Signierung von BIOS-Payloads. Der private Schlüssel muss in Azure Managed HSM oder Azure Premium Key Vault gespeichert sein. Nur das öffentliche Zertifikat wird in das DCSBC-Portal hochgeladen.

Regeln für die Zertifikatvalidierung:

Die Validierung erfolgt clientseitig. Nachdem ein Zertifikat hochgeladen wurde, zeigt das Portal Folgendes an:

• Validierungsstatus-Badge (erfolgreich/fehlgeschlagen)
• Ausgestellt am Datum
• Datum gültig bis (rot angezeigt, wenn abgelaufen)
• Ausstellerdetails: Common Name (CN), Organisationseinheit (OU), Organisation (O), Standort (L)

Fehlermeldungen:

• Bitte laden Sie eine gültige Zip-Datei hoch – Datei hat nicht das PEM-Format oder falsche Erweiterung.
• "Dateiname enthält ungültige Zeichen." -- Der Dateiname enthält Leerzeichen oder Sonderzeichen.
• "Maximale Dateigröße beträgt 8 KB" – Datei überschreitet die 8-KB-Begrenzung.
• "Diese Datei ist ungültig, beschädigt oder leer. Wählen Sie eine andere Datei mit einem gültigen x509-Zertifikat aus und versuchen Sie es erneut." Zertifikat konnte nicht analysiert werden oder schlägt fehl X.509 v3 / RSA / 3072-Bit-Validierung.
• "Dieses Zertifikat kann nicht verwendet werden." Das Zertifikat ist abgelaufen und die Richtlinienaktion lautet "Hinzufügen".

Zurück zum Anfang

Veröffentlichen von Policies in Microsoft Intune

Klicken Sie nach Abschluss des Policy-Assistenten auf die Schaltfläche Veröffentlichen im Schritt Überprüfen und veröffentlichen. Das Portal führt eine automatisierte 11-stufige Publishing-Pipeline aus:

Ein Fortschrittsbalken und ein detaillierter Phasentracker zeigen den Veröffentlichungsstatus in Echtzeit an. Nach erfolgreichem Abschluss:

• Die Meldung "Die {policyName}-Richtlinie wurde in Intune veröffentlicht und ist in wenigen Minuten verfügbar" wird angezeigt.
• View in Intune: Öffnet das Microsoft Intune-Verwaltungsportal in einer neuen Registerkarte.
• Zurück zu Richtlinien: Kehrt zum Dashboard BIOS-Richtlinien zurück.

Fehlerbehandlung: Wenn eine Phase fehlschlägt, wird eine Fehlermeldung mit der Schaltfläche Retry angezeigt (bis zu 3 Wiederholungen). Zu den häufigen Fehlern zählen Intune-API-Timeouts, Speicheruploadfehler und Verzögerungen bei Dateicommits.

Zurück zum Anfang

Sicherheitskontrollen

DCSBC Cloud implementiert Defense-in-Depth-Sicherheit auf allen Ebenen der Infrastruktur. Da die Lösung im Azure-Abonnement des Kunden ausgeführt wird, sind alle Sicherheitskontrollen überprüfbar und unterliegen der Kontrolle des Kunden.

Netzwerksicherheit

• Private Endpunkte stellen sicher, dass der Datenverkehr zwischen Azure-Diensten (Datenbank, Schlüsseltresor, HSM, Speicher, App-Dienste) nie das öffentliche Internet durchläuft.
• Der Zugriff auf öffentliche Netzwerke ist standardmäßig für alle Datenebenendienste deaktiviert. Nur das API-Gateway und die CDN-Endpunkte sind öffentlich zugänglich.
• Netzwerksicherheitsgruppen (NSGs) steuern den ein- und ausgehenden Datenverkehr für jedes Subnetz mit granularen Regeln.
• Isolierung virtueller Netzwerke: Alle Ressourcen werden in einem einzigen VNet mit getrennten Subnetzen für jede Serviceebene bereitgestellt.

Anwendungssicherheit

• Web Application Firewall (WAF) mit nach Branchenstandard gemanagten OWASP-Regelsätzen im Präventionsmodus, die Schutz vor gängigen Web-Exploits (SQL-Injection, XSS usw.) bieten.
• Die Firewall auf CDN-Ebene bietet eine zusätzliche WAF-Ebene am Edge.
• API-Ratenbegrenzung: Die IP-basierte Ratenbegrenzung pro Vorgang schützt Back-end-Services vor Missbrauch und Denial-of-Service-Angriffen.
• Azure AD JWT-Tokenvalidierung: Alle API-Aufrufe werden für Azure AD-Authentifizierungstoken überprüft, um sicherzustellen, dass nur autorisierte Benutzer auf Back-End-Services zugreifen können.
• CORS-Einschränkungen – Cross-Origin-Anfragen sind auf autorisierte Ursprünge beschränkt.

Verschlüsselung:

• TLS 1.2-Minimum wird für alle Services durchgesetzt, wobei nur starke Cipher Suites zulässig sind.
• Azure Managed HSM: Kryptografische Signaturvorgänge verwenden FIPS 140-2 Level 3-validierte Hardwaresicherheitsmodule, um sicherzustellen, dass Schlüssel niemals in der Software offengelegt werden.
• Data at Rest wird mithilfe der Azure-Plattformverschlüsselung für alle Storage-Services verschlüsselt.

Identität und Zugriff:

• Verwaltete Identitäten (null gespeicherte Anmeldeinformationen): Von Azure verwaltete Identitäten werden für die gesamte Dienst-zu-Dienst-Authentifizierung verwendet. In der Anwendungskonfiguration werden keine Kennwörter, Verbindungszeichenfolgen oder Geheimschlüssel gespeichert.
• RBAC mit den geringsten Berechtigungen: Jeder verwalteten Identität werden nur die minimal erforderlichen Rollen zugewiesen, nach dem Prinzip der geringsten Berechtigungen.
• Azure Bastion: Sicherer Administratorzugriff auf Management-VMs ohne Offenlegung öffentlicher IP-Adressen.

Monitoring und Warndienst

• Automatisierte Warnmeldungen für kritische Sicherheits- und Betriebsereignisse, einschließlich Verstößen gegen die Ratenbegrenzung, Back-end-Fehlern, unbefugten Zugriffsversuchen, WAF-Blockierungsmustern, API-Latenzanomalien und HSM-Signaturfehlern.
• Umfassende Diagnoseprotokollierung für alle Infrastrukturkomponenten – API-Gateway, Anwendungsgateway, Webanwendungen, Datenbank, Schlüsseltresor und HSM – mit Protokollen, die in einem zentralen Log Analytics-Arbeitsbereich gesammelt werden.
• Dashboards für betriebliche Transparenz in Echtzeit und Trendanalysen

Governance:

• Policy-Prüfungen vor der Bereitstellung (OPA-basiert) erzwingen Sicherheitsbaselines vor der Bereitstellung der Infrastruktur, einschließlich Zugriffsbeschränkungen für öffentliche Netzwerke, TLS-Mindestversionen, Anforderungen an den Löschschutz und öffentliche IP-Kontrollen.
• Ressourcensperren verhindern das versehentliche Löschen kritischer Datenspeicher (Schlüsseltresore, Datenbanken, Speicherkonten).

Zurück zum Anfang

FAQs

F: Ich verwende bereits DCSBC mit Dell Command | On-Premise-Konfiguration Kann ich zu DCSBC Cloud migrieren?

Ja. Beide Lösungen verwenden dasselbe zugrunde liegende Protokoll auf BIOS-Ebene (DACI mit PKI-Authentifizierung). Mit der On-Premises-Lösung bereitgestellte Geräte können von DCSBC Cloud verwaltet werden und umgekehrt, solange dieselben Zertifikate/Schlüssel verwendet werden. Sie müssen Ihre vorhandenen Zertifikate in das DCSBC Cloud-Portal hochladen und sicherstellen, dass die entsprechenden privaten Schlüssel in Azure Managed HSM oder Key Vault verfügbar sind.

F: Wo wird DCSBC Cloud ausgeführt? Wird es von Dell gehostet?

Nein. DCSBC Cloud wird in Ihrem eigenen Microsoft Azure-Abonnement bereitgestellt. Die gesamte Infrastruktur – Compute, Storage, Datenbank, HSM, Netzwerke, – wird in Ihrem Azure-Mandanten ausgeführt. Dell hostet Ihre Daten oder Infrastruktur nicht und hat keinen Zugriff darauf. Die gesamte Lösung wird automatisch mit Terraform bereitgestellt.

F: Hat Dell Zugriff auf meine BIOS-Richtlinien, Schlüssel oder Konfigurationsdaten?

Nein. Da DCSBC Cloud vollständig innerhalb Ihres Azure-Abonnements ausgeführt wird, bleiben alle Daten in Ihrem Besitz und unter Ihrer Kontrolle. Dell stellt die Software und Terraform-Vorlagen zur Verfügung, greift jedoch nicht auf Ihre Daten zu, speichert oder verarbeitet sie jedoch nicht.

F: Kann ich auswählen, in welcher Azure-Region die Bereitstellung erfolgen soll?

Ja. Die Azure-Region ist ein Parameter in der Terraform-Konfiguration. Sie können in jeder unterstützten Azure-Region bereitstellen, um Ihre Anforderungen an Datenresidenz und Compliance zu erfüllen. Alle Ressourcen werden innerhalb der einzelnen ausgewählten Region bereitgestellt.

F: Muss ich Dell Command | Auf dem DCSBC-Cloudserver konfigurieren?

Nein. Es gibt keinen On-Premise-Server. Die Infrastruktur wird in Ihrem Azure-Abonnement über Terraform bereitgestellt, und die Anwendung wird als von Azure verwaltete Dienste (App Service, Funktions-App, statische Web-App) ausgeführt.

F: Muss ich Dell Software auf den Endgeräten installieren?

Nein. Die über Intune bereitgestellten .intinewin-Pakete sind eigenständig und enthalten alle erforderlichen Komponenten. Es ist keine Installation eines Endpunkt-Agent erforderlich.

F: Welche Bereitstellungskonsolen werden unterstützt?

DCSBC Cloud unterstützt derzeit Microsoft Intune als Bereitstellungskonsole. Der lokale DCSBC mit DCC unterstützt zusätzlich SCCM und Workspace ONE.

F: Kann ich meinen eigenen HSM-Anbieter anstelle von Azure Managed HSM verwenden?

DCSBC Cloud ist für die Zusammenarbeit mit Azure Managed HSM oder Azure Key Vault konzipiert. Wenn Sie einen anderen HSM-Anbieter benötigen, sollten Sie den lokalen DCSBC mit DCC verwenden, der anbieterunabhängiges HSM über das konfigurierbare HSMSigning.bat Skript unterstützt.

F: Welche RSA-Schlüsselgrößen werden unterstützt?

DCSBC Cloud benötigt genau 3072-Bit-RSA-Schlüssel . Schlüssel anderer Größen (2048-Bit, 4096-Bit usw.) werden während der Zertifikatsvalidierung abgelehnt.

F: Kann ich dasselbe Zertifikat sowohl für die On-Premises- als auch für die Cloud-DCSBC-Lösung verwenden?

Ja, solange auf den privaten Schlüssel in beiden Umgebungen zugegriffen werden kann – gespeichert in Ihrem lokalen HSM-/Zertifikatspeicher für die lokale Lösung und in Azure Managed HSM oder Key Vault für die Cloud-Lösung.

F: Was passiert, wenn mein Zertifikat abläuft?

Abgelaufene Zertifikate können nicht für "Add"-Vorgänge (Bereitstellung) verwendet werden. Abgelaufene Zertifikate werden jedoch für Deprovisioning-Vorgänge akzeptiert, da die Absicht darin besteht, die Bereitstellung von Geräten zu entfernen.

F: Welche BIOS-Einstellungen kann ich konfigurieren?

DCSBC Cloud umfasst eine umfassende BIOS-Attributregistrierung, die Kategorien wie Sicherheit, Energie- und Performancemanagement, Systemkonfiguration, Video und erweiterte Konfigurationen abdeckt. Beispiele hierfür sind SecureBoot, WakeOnLan, Boot Order, AutoOn-Planung, Konfiguration der Akkuladung, Farbe der Tastaturhintergrundbeleuchtung und vieles mehr.

F: Welche Terraform-Version ist für die Bereitstellung von DCSBC Cloud erforderlich?

Terraform >= 1.3.0 ist erforderlich, mit dem AzureRM-Anbieter ~> 4.37.0.

F: Kann ich die Terraform-Bereitstellung anpassen (z. B. SKU-Größen, Skalierung, Speicherredundanz)?

Ja. Die Terraform-Konfiguration wird über Variablen vollständig parametrisiert. Sie können die App Service-Plan-SKU, die Datenbankebene, den Speicherreplikationstyp (LRS/GRS/ZRS), Application Gateway-Einstellungen für die automatische Skalierung und vieles mehr basierend auf Ihren Skalierungs- und Verfügbarkeitsanforderungen anpassen.