Aplikacja Dell Command | Bezpieczna konfiguracja systemu BIOS — oferta SaaS za pośrednictwem platformy Microsoft Azure Marketplace

Dotyczy produktów:

• Aplikacja Dell Command | Bezpieczna konfiguracja systemu BIOS
• Komercyjne urządzenia klienckie Dell (notebooki, komputery stacjonarne, stacje robocze)

Spis treści:

• Wprowadzenie
• Model wdrażania — hostowany przez klienta na platformie Azure
• Chmura DCSBC a DCSBC lokalnie (DCC)
• Infrastruktura w formie kodu (Terraform)
• Wymagania wstępne
• Pierwsze kroki -- Uzyskiwanie dostępu do portalu chmury DCSBC
• Tworzenie zasad systemu BIOS
  • Przepływ pracy zasad uwierzytelniania
  • Obieg pracy z zasadami ustawień systemu BIOS
  • Przepływ pracy zasad anulowania aprowizacji
• Wymagania dotyczące certyfikatu i przesyłanie
• Publikowanie zasad w usłudze Microsoft Intune
• Mechanizmy kontroli bezpieczeństwa
• Najczęściej zadawane pytania

Wprowadzenie

Interfejsy zarządzania opierają się na otwartych interfejsach lub poleceniach uwierzytelnianych hasłem. Uwierzytelnianie hasłem jest podatne na ataki typu brute-force lub słownikowe, dlatego jest mniej bezpieczne w porównaniu z uwierzytelnianiem opartym na kluczach. Potrzebny jest lepiej uwierzytelniony interfejs zarządzania, który zapewnia integralność i poufność danych i poleceń. Aplikacja Dell Command | Secure BIOS Configuration (DCSBC) to metoda odejścia od uwierzytelniania poleceń DACI za pomocą haseł systemu BIOS. DCSBC zapewnia zaufaną komunikację, tworząc interfejs, który wykorzystuje mechanizmy uwierzytelniania PKI (Public Key Infrastructure) i szyfrowane kanały do przekazywania komunikatów między platformą a klientem. Takie podejście zapewnia zarówno integralność, jak i poufność w celu ochrony danych klienta.
Usługa DCSBC Cloud rozszerza tę funkcję na model SaaS hostowany w chmurze wdrożony we własnej subskrypcji platformy Azure klienta. Zamiast instalować i utrzymywać serwer DCSBC lokalnie dzięki aplikacji Dell Command | Configure (DCC) — administratorzy IT uzyskują dostęp do portalu internetowego hostowanego we własnym środowisku platformy Azure. Cała infrastruktura jest aprowizowana automatycznie za pośrednictwem narzędzia Terraform (infrastruktura jako kod). Zasady są tworzone za pomocą portalu internetowego z przewodnikiem krok po kroku i publikowane bezpośrednio w usłudze Microsoft Intune — bez konfiguracji serwera lokalnego, bez generowania samodzielnego pliku wykonywalnego (SCE) i bez konieczności instalacji agenta punktu końcowego.

Kluczowe zalety chmury DCSBC:

• Klient jest właścicielem swoich danych —Cała infrastruktura działa w ramach subskrypcji platformy Azure klienta. Zasady systemu BIOS, klucze kryptograficzne, dane konfiguracyjne i dzienniki inspekcji pozostają pod pełną własnością i kontrolą klienta. Firma Dell nie ma dostępu do danych klientów.
• Suwerenność danych i zgodność z przepisami — Klienci wybierają region świadczenia usługi Azure do wdrożenia, zapewniając spełnienie wymagań dotyczących miejsca przechowywania danych. Wszystkie dane pozostają w wybranym regionie.
• Infrastruktura jako kod — Całe rozwiązanie jest aprowizowane za pośrednictwem narzędzia Terraform, co zapewnia powtarzalne, możliwe do skontrolowania wdrożenia infrastruktury z kontrolą wersji.
• Brak infrastruktury lokalnej — Brak konieczności instalowania i konserwacji serwera DCSBC dzięki aplikacji Dell Command | Konfigurować.
• Zarządzanie zasadami przez przeglądarkę — Za pomocą intuicyjnego kreatora krok po kroku można tworzyć zasady systemu BIOS i zarządzać nimi z dowolnej przeglądarki.
• Natywna integracja z usługą Intune — Zasady są publikowane bezpośrednio w usłudze Microsoft Intune jako aplikacje biznesowe Win32 za pomocą jednego kliknięcia.
• Wdrożenie bez agentów — Agent nie jest wymagany na punktach końcowych. Wdrożony pakiet jest samowystarczalny.
• Podpisywanie zarządzanego modułu HSM platformy Azure — Wszystkie ładunki systemu BIOS są kryptograficznie podpisane przy użyciu zarządzanego modułu HSM platformy Azure (RS384), dzięki czemu tylko autoryzowane zmiany docierają do urządzeń.
• Architektura "zero trust" — Zaufanie istnieje tylko między systemem BIOS a usługą DCSBC Cloud. Nie jest wymagane zaufanie do klienta/punktu końcowego.
• Wbudowana ochrona przed atakami typu replay — każda sesja systemu BIOS wykorzystuje unikatowe błędy kryptograficzne i efemeryczną wymianę kluczy, dzięki czemu przechwycone wcześniej ładunki nie mogą być ponownie wykorzystane ani odtworzone na urządzeniach.
• Ładunki danych kryptograficznie powiązane z urządzeniem — ładunki konfiguracji systemu BIOS są kryptograficznie powiązane z każdym urządzeniem podczas ustanawiania sesji, co uniemożliwia zastosowanie ładunków przeznaczonych dla jednego urządzenia do drugiego.

Powrót do góry

Model wdrażania — hostowany przez klienta na platformie Azure

W przeciwieństwie do tradycyjnych ofert SaaS, w których dostawca hostuje infrastrukturę, DCSBC Cloud jest wdrażany w ramach własnej subskrypcji Microsoft Azure klienta. Ta architektura zapewnia kilka krytycznych korzyści:

• Własność i kontrola danych: Wszystkie zasoby platformy Azure — obliczenia, magazyn, baza danych, moduł HSM, sieć — są aprowizowane w ramach dzierżawy i subskrypcji platformy Azure klienta. Konfiguracje zasad systemu BIOS, kryptograficzne klucze podpisywania, dane sesji i dzienniki inspekcji są przechowywane we własnej usłudze Azure SQL Database, usłudze Azure Key Vault / zarządzanym module HSM i koncie usługi Azure Storage. Firma Dell Technologies nie ma dostępu do danych, kluczy ani infrastruktury klienta. Klient zachowuje pełną kontrolę administracyjną.
• Suwerenność danych i zgodność z przepisami: Klient wybiera region świadczenia usługi Azure do wdrożenia (np. Wschodnie stany USA 2, Europa Zachodnia, Australia Wschodnia). Wszystkie zasoby są aprowizowane w tym jednym regionie.
  Magazyn domyślnie używa magazynu lokalnie nadmiarowego (LRS), dzięki czemu dane nie opuszczają wybranego regionu. W zależności od wymagań klienta można ją skonfigurować jako magazyn geograficznie nadmiarowy (GRS) lub magazyn strefowo nadmiarowy (ZRS). Model hostowany przez klienta obsługuje zgodność z przepisami dotyczącymi miejsca przechowywania danych (RODO, przepisami dotyczącymi suwerenności danych, mandatami branżowymi), ponieważ klient kontroluje, gdzie znajdują się dane.
• Izolacja najemcy: Każdy klient otrzymuje w pełni izolowane wdrożenie: własną grupę zasobów, sieć wirtualną, podsieci, bazy danych, magazyny kluczy i wszystkie inne zasoby. Izolacja sieci jest wymuszana za pośrednictwem prywatnych punktów końcowych, sieciowych grup zabezpieczeń i Azure Firewall.
• Przejrzystość kosztów: Wszystkie koszty zasobów platformy Azure są wyświetlane we własnych rozliczeniach klienta za korzystanie z platformy Azure, zapewniając pełny wgląd w wydatki na infrastrukturę. Klient może wykorzystać istniejące zobowiązania platformy Azure (MACC — Microsoft Azure Consumption Commitment) i wystąpienia zarezerwowane.

Powrót do góry

Chmura DCSBC a DCSBC lokalnie (DCC)

Uwaga:
Oba rozwiązania korzystają z tego samego protokołu bazowego systemu BIOS, w tym poleceń opartych na sesjach z wymianą kluczy Diffiego-Hellmana, ochrony powtórzeń opartej na nonce i uwierzytelniania PKI. Zasady utworzone za pomocą obu rozwiązań są zgodne z tymi samymi implementacjami systemu BIOS w klientach komercyjnych firmy Dell.

Powrót do góry

Infrastruktura w formie kodu (Terraform)

Cała infrastruktura chmury DCSBC jest udostępniana przy użyciu narzędzia Terraform (HashiCorp), co zapewnia powtarzalne, możliwe do skontrolowania wdrożenia z kontrolą wersji. Konfiguracja narzędzia Terraform jest modułowa i sparametryzowana, dzięki czemu każde wdrożenie klienta można dostosować do regionu świadczenia usługi Azure, konwencji nazewnictwa i wymagań dotyczących skalowania.
Omówienie konfiguracji programu Terraform:

• Wersja programu Terraform: >= 1.3.0
• Dostawca AzureRM: ~> 4.37.0
• Zarządzanie państwem: Stan zdalny przechowywany na koncie usługi Azure Storage (uwierzytelnianie usługi Azure AD)
• Przydzielone zasoby platformy Azure: Następujące zasoby są automatycznie aprowizowane w ramach subskrypcji platformy Azure klienta:

Powrót do góry

Wymagania wstępne

Przed użyciem rozwiązania DCSBC Cloud należy upewnić się, że spełnione są następujące warunki wstępne:

• Subskrypcja platformy Microsoft Azure — aktywna subskrypcja platformy Azure z najemcą identyfikatora usługi Azure Entra (Azure AD).
• Microsoft Intune — aktywne środowisko Microsoft Intune skonfigurowane do zarządzania urządzeniami.
• Komercyjne urządzenia klienckie Dell — urządzenia docelowe muszą być komercyjnymi notebookami, komputerami stacjonarnymi lub stacjami roboczymi firmy Dell z systemem BIOS obsługującym DCSBC, zarejestrowanymi w Microsoft Intune.
• Zarządzany moduł HSM platformy Azure lub usługa Azure Key Vault — wystąpienie zarządzanego modułu HSM lub Key Vault platformy Azure aprowizowane przy użyciu kluczy RSA-HSM, które odpowiadają certyfikatom używanym do uwierzytelniania systemu BIOS. Klucz prywatny musi znajdować się w module HSM; tylko certyfikat publiczny (.pem) jest przesyłany do portalu DCSBC Cloud.
• Certyfikaty X.509 - certyfikaty RSA spełniające następujące wymagania:
  • Długość klucza: 3072-bitowy RSA (dokładnie)
  • Format: PEM (rozszerzenie pliku .pem)
  • Wersja: X.509 v3
  • Rozmiar pliku: maksymalnie 8 KB
  • Algorytm: RSA (OID 1.2.840.113549.1.1.1)
• Obsługiwana przeglądarka - nowoczesna przeglądarka internetowa (Microsoft Edge, Google Chrome, Mozilla Firefox).

Powrót do góry

Pierwsze kroki -- Uzyskiwanie dostępu do portalu chmury DCSBC

• Subskrybuj — kup aplikację Dell Command | Chmura bezpiecznej konfiguracji systemu BIOS za pośrednictwem platformy Microsoft Azure Marketplace.
• Zaloguj się — przejdź do adresu URL portalu chmury DCSBC podanego w ramach subskrypcji. Zaloguj się przy użyciu poświadczeń identyfikatora Microsoft Entra (Azure AD). Portal używa biblioteki Microsoft Authentication Library (MSAL) do logowania jednokrotnego.
• Strona początkowa — po uwierzytelnieniu nastąpi przekierowanie do pulpitu nawigacyjnego zasad systemu BIOS. W tym miejscu możesz:
  • Wyświetlanie istniejących zasad systemu BIOS opublikowanych w dzierżawie usługi IntuneView existing BIOS policies published to your Intune tenant
  • Tworzenie nowych zasad przy użyciu portalu internetowego krok po kroku

Powrót do góry

Tworzenie zasad systemu BIOS

Na stronie BIOS Policies kliknij opcję Create a new policy. Zostaną wyświetlone trzy typy zasad:

Wybierz typ zasad, aby uruchomić kreatora z przewodnikiem. Te zasady są wdrażane bezpośrednio z Intune do punktów końcowych bez konieczności instalacji jakichkolwiek agentów punktów końcowych.

Uwaga:

W dowolnym przypadku na komputerze klienckim można aprowizować tylko jeden klucz aprowizacji.

Uwaga:

Na komputerze klienckim w dowolnym wystąpieniu można aprowizować do siedmiu kluczy poleceń.

Przepływ pracy zasad uwierzytelniania

Kreator zasad uwierzytelniania składa się z 3 kroków:

Krok 1 – Nazwij swoją polisę

• Wprowadź nazwę zasady (wymagane, maks. 488 znaków). AUTH_ prefiksu i sufiks sygnatury czasowej _DD.MM.YY_HH:mm_UTC są dodawane automatycznie.
• Wprowadź opcjonalny opis (maks. 1000 znaków).
• Przed kontynuowaniem wyświetlany jest podgląd pełnej nazwy zasady (w tym prefiksu i sufiksu, maks. 512 znaków).
• Zduplikowane nazwy zasad są wykrywane automatycznie przez sprawdzenie istniejących opublikowanych zasad w Intune.

Krok 2 – zarządzanie zabezpieczeniami BIOS (przesyłanie certyfikatu)

• Prześlij łącznie do 3 certyfikatów :
  • 1 certyfikat aprowizacji (wymagany) — używany do uwierzytelniania bezpiecznej łączności dla operacji aprowizacji.
  • Do 2 certyfikatów poleceń — używanych do podpisywania ładunków danych w przypadku zmian konfiguracji systemu BIOS.
• Dla każdego certyfikatu wybierz: 
  • Rodzaj: Przydzielanie lub polecenie
  • Działanie w ramach polityki: Dodawanie (aprowizacja nowego klucza)
• Certyfikaty są weryfikowane po stronie klienta (patrz Wymagania dotyczące certyfikatów i przesyłanie).
• Przycisk Dalej staje się aktywny, gdy:
  • Przesłano certyfikat aprowizacji
  • Przesłano 1 certyfikat polecenia

Krok 3 -- Przejrzyj i opublikuj

• Zapoznaj się z nazwą, opisem i typem zasady.
• Kliknij przycisk Publikuj, aby opublikować zasady w Microsoft Intune (zobacz Publikowanie zasad w Microsoft Intune).

Powrót do góry

Obieg pracy z zasadami ustawień systemu BIOS

Kreator zasad ustawień systemu BIOS składa się z 4 lub 5 kroków (w zależności od tego, czy istnieją zasady systemu BIOS w Intune):

Krok 1 -- Kopiuj i edytuj lub Zacznij od zera (warunkowo -- wyświetlane, jeśli istnieją istniejące zasady)

• Uruchom pusty plik zasad – zacznij od pustej konfiguracji.
• Kopiuj, a następnie edytuj — kopiuje wartości atrybutów systemu BIOS z istniejących opublikowanych zasad i modyfikuje je. W oknie modalnym wyświetlana jest przeszukiwalna, sortowana i podzielona na strony lista istniejących zasad systemu BIOS.

Krok 2 - Nazwij swoją polisę

• Taki sam jak zasady uwierzytelniania, ale z prefiksem BIOS_.

Krok 3 – wybierz atrybuty i wartości systemu BIOS

• W tabeli przedstawiono wszystkie dostępne atrybuty systemu BIOS z rejestru atrybutów firmy Dell.
• Wyszukaj atrybuty według nazwy, filtruj według kategorii i przełącz, aby wyświetlić tylko wybrane atrybuty.
• Wybierz atrybut, klikając jego pole wyboru, a następnie skonfiguruj jego wartość:
  • Atrybuty wyliczenia (np. SecureBoot, WakeOnLan) — wybierz z listy rozwijanej dozwolonych wartości.
  • Atrybuty całkowite (np. AutoOnHr, CustomChargeStart) — wprowadź liczbę w zakresie od min. do maksimum.
  • Atrybuty łańcuchowe (np. AssetTag) -- Wprowadź tekst o długości do 80 znaków.
  • Funkcje niestandardowe (np. harmonogram AutoOn, konfiguracja ładowania baterii, kolor podświetlenia klawiatury) — kliknij "Wyświetl/Zmień", aby otworzyć dedykowane okno konfiguracji.
• Panel Podgląd kodu wyświetla podgląd na żywo wybranej konfiguracji w formacie CCTK:

[cctk]

SecureBoot=Enabled

WakeOnLan=LanOnly

AutoOn=SelectDays

AutoOnMon=Enabled

AutoOnTue=Enabled

• Przycisk Dalej jest nieaktywny, jeśli nie wybrano żadnych atrybutów lub którykolwiek z wybranych atrybutów ma nieprawidłową wartość.

Krok 4 – zarządzanie zabezpieczeniami BIOS

• Prześlij ten sam certyfikat polecenia , który był używany dla zasad uwierzytelniania.
• Aby kontynuować, wymagany jest jeden certyfikat polecenia.

Krok 5 -- Przejrzyj i opublikuj

• Przejrzyj i opublikuj w usłudze Microsoft Intune.

Powrót do góry

Przepływ pracy zasad anulowania aprowizacji

Kreator zasad anulowania aprowizacji składa się z 3 kroków:

Krok 1 – Nazwij swoją polisę

• Tak samo jak inne zasady, z prefiksem DPRV_.

Krok 2 – zarządzanie zabezpieczeniami BIOS

• Przekaż ten sam certyfikat aprowizacji , który był używany dla zasad uwierzytelniania.
• Wymagany jest jeden certyfikat inicjowania.
• Uwaga: Wygasłe certyfikaty są dozwolone w przypadku operacji anulowania aprowizacji, ponieważ celem jest usunięcie aprowizacji z urządzeń.

Krok 3 -- Przejrzyj i opublikuj

• Przejrzyj i opublikuj. Zasady anulowania aprowizacji używają operacji czyszczenia DACI w celu usunięcia wszystkich aprowizowanych kluczy z urządzeń docelowych.

Powrót do góry

Wymagania dotyczące certyfikatu i przesyłanie

Chmura DCSBC wymaga certyfikatów X.509 w formacie PEM do podpisywania ładunków BIOS. Klucz prywatny musi być przechowywany w usłudze Azure Managed HSM lub Azure Premium Key Vault; tylko certyfikat publiczny jest przekazywany do portalu DCSBC.

Reguły weryfikacji certyfikatu:

Walidacja jest wykonywana po stronie klienta. Po przesłaniu certyfikatu w portalu są wyświetlane następujące informacje:

• Plakietka stanu weryfikacji (Powodzenie/Niepowodzenie)
• Data wydania
• Termin ważności (jeśli wygasł, zaznaczony kolorem czerwonym)
• Dane wystawcy: Nazwa pospolita (CN), Jednostka organizacyjna (OU), Organizacja (O), Lokalizacja (L)

Komunikat o błędzie:

• "Prześlij prawidłowy plik .PEM". -- Plik nie jest w formacie PEM lub ma nieprawidłowe rozszerzenie.
• "Nazwa pliku zawiera nieprawidłowe znaki". -- Nazwa pliku zawiera spacje lub znaki specjalne.
• "Maksymalny rozmiar pliku to 8 KB" – plik przekracza limit 8 KB.
• "Ten plik jest nieprawidłowy, uszkodzony lub pusty. Wybierz inny plik z prawidłowym certyfikatem x509 i spróbuj ponownie." --Nie można przeanalizować certyfikatu lub kończy się niepowodzeniem Walidacja X.509 v3 / RSA / 3072-bitowa.
• "Tego certyfikatu nie można użyć". -- Certyfikat wygasł, a działaniem zasad jest "Dodaj".

Powrót do góry

Publikowanie zasad w usłudze Microsoft Intune

Po zakończeniu pracy kreatora zasad kliknij przycisk Publikuj w kroku Review and Publish. Portal wykonuje zautomatyzowany 11-etapowy potok publikowania:

Pasek postępu i szczegółowy tracker etapu pokazują status publikowania w czasie rzeczywistym. Po pomyślnym zakończeniu:

• Zostanie wyświetlony komunikat "Zasady {policyName} zostały opublikowane w usłudze Intune i będą dostępne w ciągu kilku minut".
• Wyświetl w Intune — otwiera portal administracyjny Microsoft Intune w nowej karcie.
• Powrót do zasad — powrót do pulpitu zasad systemu BIOS.

Obsługa błędów: Jeśli którykolwiek etap zakończy się niepowodzeniem, zostanie wyświetlony komunikat o błędzie z przyciskiem Ponów próbę (do 3 ponownych prób). Typowe błędy obejmują przekroczenie limitu czasu interfejsu API usługi Intune, niepowodzenia przekazywania magazynu i opóźnienia zatwierdzania plików.

Powrót do góry

Mechanizmy kontroli bezpieczeństwa

DCSBC Cloud wdraża ochronę w głąb ochrony we wszystkich warstwach infrastruktury. Ponieważ rozwiązanie działa w ramach subskrypcji platformy Azure klienta, wszystkie mechanizmy kontroli zabezpieczeń są poddawane inspekcji i podlegają ładowi klienta.

Bezpieczeństwo sieci

• Prywatne punkty końcowe zapewniają, że ruch między usługami platformy Azure (bazą danych, magazynem kluczy, modułem HSM, magazynem, usługami aplikacji) nigdy nie przechodzi przez publiczny Internet.
• Dostęp do sieci publicznej jest domyślnie wyłączony dla wszystkich usług płaszczyzny danych. Tylko brama interfejsu API i punkty końcowe usługi CDN są publicznie dostępne.
• Sieciowe grupy zabezpieczeń kontrolują ruch przychodzący i wychodzący dla każdej podsieci ze szczegółowymi regułami.
• Izolacja Virtual Network — wszystkie zasoby są wdrażane w ramach jednej sieci wirtualnej z oddzielnymi podsieciami dla każdej warstwy usługi.

Bezpieczeństwo aplikacji:

• Web Application Firewall (WAF) ze standardowymi w branży zestawami reguł zarządzanych OWASP w trybie zapobiegania, zapewniając ochronę przed typowymi programami wykorzystującymi luki w zabezpieczeniach sieci Web (wstrzyknięcie kodu SQL, XSS itp.).
• Zapora na poziomie usługi CDN zapewnia dodatkową warstwę zapory aplikacji internetowej na brzegu sieci.
• Ograniczanie szybkości interfejsu API — na operację, ograniczanie szybkości na podstawie adresu IP chroni usługi zaplecza przed nadużyciami i atakami typu "odmowa usługi".
• Walidacja tokenu JWT usługi Azure AD — wszystkie wywołania interfejsu API są weryfikowane pod kątem tokenów uwierzytelniania usługi Azure AD, dzięki czemu tylko autoryzowani użytkownicy mogą uzyskiwać dostęp do usług zaplecza.
• Ograniczenia CORS — żądania między źródłami są ograniczone tylko do autoryzowanych źródeł.

Szyfrowanie

• Minimalny protokół TLS 1.2 jest wymuszany we wszystkich usługach z dozwolonymi tylko silnymi zestawami szyfrowania.
• Zarządzany moduł HSM platformy Azure — operacje podpisywania kryptograficznego używają zweryfikowanych sprzętowych modułów zabezpieczeń FIPS 140-2 poziomu 3, zapewniając, że klucze nigdy nie są ujawniane w oprogramowaniu.
• Dane magazynowane są szyfrowane przy użyciu szyfrowania platformy Azure we wszystkich usługach magazynu.

Tożsamość i dostęp:

• Tożsamości zarządzane (zero przechowywanych poświadczeń) — tożsamości zarządzane platformy Azure są używane do uwierzytelniania między usługami. W konfiguracji aplikacji nie są przechowywane żadne hasła, parametry połączenia ani wpisy tajne.
• RBAC z najmniejszymi uprawnieniami — każda tożsamość zarządzana ma przypisane tylko minimalne wymagane role, zgodnie z zasadą najniższych uprawnień.
• Azure Bastion — bezpieczny dostęp administracyjny do maszyn wirtualnych zarządzania bez uwidaczniania publicznych adresów IP.

Monitorowanie i ostrzeganie

• Automatyczne alerty dotyczące krytycznych zdarzeń związanych z zabezpieczeniami i operacjami, w tym naruszeń ograniczania szybkości, błędów zaplecza, nieautoryzowanych prób dostępu, wzorców blokowania zapory aplikacji internetowej, anomalii opóźnień interfejsu API i niepowodzeń podpisywania modułu HSM.
• Kompleksowe rejestrowanie diagnostyczne we wszystkich składnikach infrastruktury — bramie interfejsu API, bramie aplikacji, aplikacjach internetowych, bazie danych, magazynie kluczy i module HSM — z dziennikami zbieranymi w scentralizowanym obszarze roboczym usługi Log Analytics.
• Pulpity nawigacyjne zapewniające widoczność operacyjną i analizę trendów w czasie rzeczywistym.

Governance:

• Kontrole zasad przed wdrożeniem (oparte na OPA) wymuszają punkty odniesienia zabezpieczeń przed aprowizacją infrastruktury, w tym ograniczenia dostępu do sieci publicznej, minimalne wersje protokołu TLS, wymagania dotyczące ochrony przeczyszczania i kontrole publicznych adresów IP.
• Blokady zasobów zapobiegają przypadkowemu usunięciu krytycznych magazynów danych (magazynów kluczy, baz danych, kont magazynu).

Powrót do góry

Najczęściej zadawane pytania

P: Korzystam już z DCSBC z aplikacją Dell Command | Konfiguracja lokalna. Czy mogę przeprowadzić migrację do chmury DCSBC?

Tak. Oba rozwiązania korzystają z tego samego bazowego protokołu na poziomie systemu BIOS (DACI z uwierzytelnianiem PKI). Urządzeniami aprowizowanymi za pomocą rozwiązania lokalnego można zarządzać przez DCSBC Cloud i odwrotnie, o ile używane są te same certyfikaty/klucze. Należy przekazać istniejące certyfikaty do portalu DCSBC Cloud i upewnić się, że odpowiednie klucze prywatne są dostępne w usłudze Azure Managed HSM lub Key Vault.

P: Gdzie działa DCSBC Cloud? Czy jest obsługiwany przez firmę Dell?

Nie. Chmura DCSBC jest wdrażana w ramach własnej subskrypcji Microsoft Azure. Cała infrastruktura — obliczeniowa, magazynowa, baza danych, moduł HSM, sieć — działa w dzierżawie platformy Azure. Firma Dell nie hostuje ani nie ma dostępu do danych lub infrastruktury użytkownika. Całe rozwiązanie jest aprowizowane automatycznie przy użyciu narzędzia Terraform.

P: Czy firma Dell ma dostęp do zasad, kluczy lub danych konfiguracyjnych systemu BIOS?

Nie. Ponieważ usługa DCSBC Cloud działa w całości w ramach subskrypcji platformy Azure, wszystkie dane pozostają pod Twoją własnością i kontrolą. Firma Dell dostarcza oprogramowanie i szablony Terraform, ale nie uzyskuje dostępu, nie przechowuje ani nie przetwarza danych użytkownika.

Pyt.: Czy mogę wybrać region świadczenia usługi Azure do wdrożenia?

Tak. Region świadczenia usługi Azure jest parametrem w konfiguracji programu Terraform. Możesz wdrożyć w dowolnym obsługiwanym regionie świadczenia usługi Azure, aby spełnić wymagania dotyczące miejsca przechowywania danych i zgodności. Wszystkie zasoby są aprowizowane w jednym wybranym regionie.

P: Czy trzeba zainstalować aplikację Dell Command | Skonfigurować na serwerze DCSBC Cloud?

Nie. Brak serwera lokalnego. Infrastruktura jest aprowizowana w ramach subskrypcji platformy Azure za pośrednictwem narzędzia Terraform, a aplikacja jest uruchamiana jako usługi zarządzane przez platformę Azure (App Service, aplikacja funkcji, statyczna aplikacja internetowa).

P: Czy muszę instalować oprogramowanie firmy Dell na urządzeniach końcowych?

Nie. Pakiety .intunewin wdrożone za pośrednictwem usługi Intune są samodzielne i zawierają wszystkie niezbędne składniki. Nie jest wymagana instalacja agenta punktu końcowego.

Pyt.: Jakie konsole wdrażania są obsługiwane?

DCSBC Cloud obsługuje obecnie Microsoft Intune jako konsolę wdrażania. Lokalne rozwiązanie DCSBC z DCC obsługuje dodatkowo rozwiązania SCCM i WorkspaceONE.

Pyt.: Czy mogę użyć własnego dostawcy modułu HSM zamiast zarządzanego modułu HSM platformy Azure?

Usługa DCSBC Cloud jest przeznaczona do współpracy z zarządzanym modułem HSM platformy Azure lub usługą Azure Key Vault. Jeśli potrzebujesz innego dostawcy modułu HSM, rozważ użycie lokalnego kontrolera DCSBC z usługą DCC, który obsługuje moduł HSM niezależny od dostawcy za pośrednictwem konfigurowalnego skryptu HSMSigning.bat.

Pyt.: Jakie rozmiary kluczy RSA są obsługiwane?

DCSBC Cloud wymaga dokładnie 3072-bitowych kluczy RSA . Klucze o innych rozmiarach (2048-bitowy, 4096-bitowy itd.) zostaną odrzucone podczas weryfikacji certyfikatu.

Pyt.: Czy mogę używać tego samego certyfikatu zarówno dla lokalnych, jak i chmurowych rozwiązań DCSBC?

Tak, o ile klucz prywatny jest dostępny w obu środowiskach — przechowywany w lokalnym magazynie HSM/certyfikatów dla rozwiązania lokalnego oraz w zarządzanym module HSM platformy Azure lub Key Vault dla rozwiązania w chmurze.

P: Co się stanie, jeśli mój certyfikat wygaśnie?

Wygasłych certyfikatów nie można używać do operacji "dodawania" (aprowizacji). Jednak wygasłe certyfikaty są akceptowane w przypadku operacji anulowania aprowizacji, ponieważ celem jest usunięcie aprowizacji z urządzeń.

P: Jakie ustawienia BIOS mogę skonfigurować?

Chmura DCSBC zawiera obszerny rejestr atrybutów systemu BIOS obejmujący takie kategorie, jak Zabezpieczenia, Zarządzanie zasilaniem i wydajnością, Konfiguracja systemu, Wideo i Konfiguracje zaawansowane. Niektóre przykłady to SecureBoot, WakeOnLAN, Boot Order, AutoOn scheduling, Battery Charge Configuration, Keyboard Backlight Color i wiele innych.

Pyt.: Jaka wersja programu Terraform jest wymagana do wdrożenia usługi DCSBC Cloud?

Narzędzie Terraform >= 1.3.0 jest wymagane, z dostawcą AzureRM ~> 4.37.0.

Pyt.: Czy mogę dostosować wdrożenie programu Terraform (np. rozmiary jednostek SKU, skalowanie, nadmiarowość magazynu)?

Tak. Konfiguracja narzędzia Terraform jest w pełni sparametryzowana za pomocą zmiennych. Na podstawie wymagań dotyczących skalowania i dostępności można dostosować jednostkę SKU planu App Service, warstwę bazy danych, typ replikacji magazynu (LRS/GRS/ZRS), ustawienia automatycznego skalowania Application Gateway i nie tylko.