Actualizări secure boot certificate: instrucțiuni pentru profesioniști IT și organizații

Expirare certificat de bootare securizată

Configurația autorităților de certificare (CA- uri), denumită și certificate, furnizată de Microsoft ca parte a infrastructurii Secure Boot, a rămas aceeași începând cu Windows 8 și Windows Server 2012. Aceste certificate sunt stocate în variabilele bază de date de semnături (DB) și cheie Exchange Key (KEK) din firmware. Microsoft a furnizat aceleași trei certificate în ecosistemul producătorului de echipamente original (OEM) pe care să le includă în firmware-ul dispozitivului. Aceste certificate acceptă bootul securizat în Windows și sunt utilizate, de asemenea, de sisteme de operare terțe (so). Următoarele certificate sunt furnizate de Microsoft:

• Microsoft Corporation KEK CA 2011

• Microsoft Windows Production PCA 2011

• Microsoft Corporation UEFI CA 2011

Ce se schimbă?

Certificatele microsoft Secure Boot curente (Microsoft Corporation KEK CA 2011, Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011) vor expira începând din iunie 2026 și vor expira până în octombrie 2026. 

Sunt lansate certificate 2023 noi pentru a menține securitatea și continuitatea bootului securizat. Dispozitivele trebuie să actualizeze la certificatele 2023 înainte ca certificatele 2011 să expire, altfel, nu vor fi în conformitate cu securitatea și vor fi supuse riscurilor.  

Dispozitivele Windows fabricate din 2012 pot avea versiuni de certificate care expiră, care trebuie actualizate. 

Terminologie

Certificate

Verificarea stării Secure Boot în flota dvs.: Bootarea sigură este activată? 

Majoritatea dispozitivelor fabricate începând cu 2012 au suport pentru Bootare sigură și sunt livrate cu Secure Boot activat. Pentru a verifica dacă un dispozitiv are Secure Boot activat, alegeți una dintre următoarele variante: 

• Metodă GUI: Accesați Start setări > >Securitate & confidențialitate> Securitate Windows > Securitate dispozitive. Sub Securitate dispozitiv, secțiunea Bootare sigură ar trebui să indice faptul că este activată bootarea sigură.

• Metodă linie de comandă: Într-o linie de comandă cu drepturi sporite în PowerShell, tastați Confirmare-SecureBootUEFI, apoi apăsați enter. Comanda ar trebui să returneze True, indicând faptul că este activată bootarea sigură.

În implementările la scară largă pentru o flotă de dispozitive, software-ul de gestionare utilizat de profesioniștii IT va trebui să furnizeze o verificare pentru activarea bootării securizate. 

De exemplu, metoda de a verifica starea bootării sigure pe dispozitivele gestionate de Microsoft Intune este să creați și să implementați un script de conformitate particularizat Intune. Setările de conformitate Intune sunt descrise în Utilizarea setărilor de conformitate particularizate pentru dispozitivele Linux și Windows cu Microsoft Intune.  

Cum sunt implementate actualizările

Există mai multe modalități de a direcționa dispozitivele pentru actualizările certificatului secure Boot. Detaliile de implementare, inclusiv setările și evenimentele, vor fi discutate mai târziu în acest document. Atunci când direcționați un dispozitiv pentru actualizări, se face o setare pe dispozitiv pentru a indica faptul că dispozitivul ar trebui să înceapă procesul de aplicare a noilor certificate. O activitate planificată rulează pe dispozitiv la fiecare 12 ore și detectează că dispozitivul a fost direcționat pentru actualizări. O schiță a ceea ce face activitatea este după cum urmează:

1. Windows UEFI CA 2023 se aplică la baza de date.

2. Dacă dispozitivul are Microsoft Corporation UEFI CA 2011 în DB, atunci activitatea aplică Microsoft Option ROM UEFI CA 2023 și Microsoft UEFI CA 2023 la DB.

3. Activitatea adaugă apoi Microsoft Corporation KEK 2K CA 2023.

4. În sfârșit, activitatea programată actualizează managerul de boot Windows la cel semnat de Windows UEFI CA 2023. Windows va detecta că este necesară o repornire înainte de a putea aplica managerul de boot. Actualizarea managerului de boot va fi amânată până când repornirea are loc în mod natural (de exemplu, atunci când se aplică actualizări lunare), apoi Windows va încerca din nou să aplice actualizarea managerului de boot.

Fiecare dintre pașii de mai sus trebuie finalizat cu succes înainte ca activitatea planificată să se mute la pasul următor. În timpul acestui proces, jurnalele de evenimente și alte stări vor fi disponibile pentru a ajuta la monitorizarea implementării. Mai multe detalii despre monitorizare și jurnalele de evenimente sunt furnizate mai jos.  

Actualizarea certificatelor secure boot permite o actualizare viitoare a Managerului de boot 2023, care este mai sigură. Actualizările specifice ale Managerului de boot vor fi în edițiile viitoare.

Pașii de implementare 

• Pregătire: inventar și dispozitive de testare.

• Considerații legate de firmware

• Monitorizare: Verificați lucrările de monitorizare și referința flotei dvs.

• Implementare: dispozitive țintă pentru actualizări, începând cu subseturi mici și extinzând pe baza testelor reușite.

• Remediere: investigați și rezolvați orice probleme utilizând asistența pentru jurnale și furnizori.

Pregătire 

Hardware și firmware de inventar. Construiți un eșantion reprezentativ de dispozitive bazate pe producătorul sistemului, modelul de sistem, versiunea/data BIOS, versiunea produsului BaseBoard etc. și testați actualizările pe aceste eșantioane înainte de o implementare extinsă.  Acești parametri sunt disponibili de obicei în informațiile de sistem (MSINFO32). 

Exemple de comenzi PowerShell pentru colectarea informațiilor sunt:

Considerații legate de firmware

Implementarea noilor certificate Secure Boot pentru flota de dispozitive necesită ca firmware-ul dispozitivului să joace un rol în finalizarea actualizării. Deși Microsoft se așteaptă ca majoritatea firmware-ului dispozitivului să funcționeze așa cum vă așteptați, este necesară o testare atentă înainte de a implementa noile certificate.

Examinați inventarul de hardware și construiți un eșantion mic, reprezentativ de dispozitive, pe baza următoarelor criterii unice, cum ar fi: 

• Producător

• Număr model

• Versiune firmware

• Versiunea OEM a tablei de bază etc.

Înainte de a implementa pe scară largă pe dispozitivele din flota dvs., vă recomandăm să testați actualizările certificatelor pe dispozitive eșantion reprezentative (așa cum sunt definite de factori precum producătorul, modelul, versiunea de firmware) pentru a vă asigura că actualizările sunt procesate cu succes. Îndrumările recomandate privind numărul de dispozitive eșantion de testat pentru fiecare categorie unică sunt de 4 sau mai multe.

Acest lucru va contribui la consolidarea încrederii în procesul de implementare și va ajuta la evitarea impactului neprevăzut asupra flotei mai largi. 

În unele cazuri, poate fi necesară o actualizare de firmware pentru a actualiza cu succes certificatele Secure Boot. În aceste cazuri, vă recomandăm să consultați producătorul OEM al dispozitivului pentru a vedea dacă este disponibil firmware actualizat.

Windows în medii virtualizate

Pentru Windows care rulează într-un mediu virtual, există două metode de adăugare a noilor certificate la variabilele de firmware Secure Boot:  

• Creatorul mediului virtual (AWS, Azure, Hyper-V, VMware etc.) poate oferi o actualizare pentru mediu și poate include noile certificate în firmware-ul virtualizat. Acest lucru ar funcționa pentru noile dispozitive virtualizate.

• Pentru Windows care rulează pe termen lung într-o mașină virtuală, actualizările pot fi aplicate prin Windows la fel ca orice alte dispozitive, dacă firmware-ul virtualizat acceptă actualizări secure Boot.

Monitorizare și implementare 

Vă recomandăm să începeți monitorizarea dispozitivului înainte de implementare, pentru a vă asigura că monitorizarea funcționează corect și că aveți un bun simț pentru starea flotei în avans. Opțiunile de monitorizare sunt discutate mai jos. 

Microsoft oferă mai multe metode pentru implementarea și monitorizarea actualizărilor certificatelor de bootare securizată.

Asistență pentru implementarea automată 

Microsoft oferă două asistență pentru implementare. Aceste asistenți se pot dovedi utile pentru a ajuta la implementarea noilor certificate pentru flota dvs. Ambele asistări necesită date de diagnosticare.

• Opțiune pentru actualizări cumulative cu bucketuri de încredere: Microsoft poate include automat grupuri de dispozitive de mare încredere în actualizările lunare, pe baza datelor de diagnosticare partajate până în prezent, pentru a beneficia de sistemele și organizațiile care nu pot partaja date de diagnosticare. Acest pas nu necesită activarea datelor de diagnosticare.

  • Pentru organizațiile și sistemele care pot partaja date de diagnosticare, oferă Microsoft vizibilitatea și încrederea că dispozitivele pot implementa cu succes certificatele. Sunt disponibile mai multe informații despre activarea datelor de diagnosticare în: Configurarea datelor de diagnosticare Windows în organizația dvs. Creăm "bucketuri" pentru fiecare dispozitiv unic (așa cum sunt definite de atributele care includ producătorul, versiunea plăcii de bază, producătorul firmware-ului, versiunea firmware și puncte de date suplimentare). Pentru fiecare recipient, monitorizăm dovezile succesului pe mai multe dispozitive. După ce am văzut suficiente actualizări de succes și nicio eroare, vom lua în considerare bucketul "nivel înalt de încredere" și vom include datele respective în actualizările cumulative lunare. Atunci când sunt aplicate actualizări lunare la un dispozitiv într-un bucket de mare încredere, Windows va aplica automat certificatele variabilelor de boot secure UEFI în firmware.

  • Bucketurile de mare încredere includ dispozitivele care procesează corect actualizările. Desigur, nu toate dispozitivele vor furniza date de diagnosticare, iar acest lucru poate limita încrederea Microsoft în capacitatea unui dispozitiv de a procesa corect actualizările.

  • Această asistență este activată în mod implicit pentru dispozitivele de mare încredere și poate fi dezactivată cu o setare specifică dispozitivului. Mai multe informații vor fi partajate în edițiile windows viitoare.

• Lansare controlată a caracteristicilor (CFR):  Optați pentru dispozitive pentru implementarea gestionată de Microsoft dacă sunt activate datele de diagnosticare.

  • Lansarea controlată a caracteristicilor (CFR) poate fi utilizată cu dispozitive client din flotele de organizații. Acest lucru necesită ca dispozitivele să trimită date de diagnosticare necesare la Microsoft și să fi indicat că dispozitivul optează să permită CFR pe dispozitiv. Detalii despre cum să vă înscrieți sunt descrise mai jos.

  • Microsoft va gestiona procesul de actualizare pentru aceste certificate noi pe dispozitivele Windows unde sunt disponibile date de diagnosticare și dispozitivele participă la lansarea controlată a caracteristicilor (CFR). Deși CFR poate ajuta la implementarea noilor certificate, organizațiile nu se vor putea baza pe CFR pentru a-și remedia flotele- va fi necesar să urmați pașii subliniați în acest document în secțiunea despre Metodele de implementare neacoperite de asistența automată.

  • Limitări: Există câteva motive pentru care CFR poate să nu funcționeze în mediul dvs. De exemplu:

    • Nu sunt disponibile date de diagnosticare sau datele de diagnosticare nu se pot utiliza ca parte a implementării CFR.

    • Dispozitivele nu se află în versiunile de client acceptate de Windows 11 și Windows 10 cu actualizări de securitate extinse (ESU).

Metodele de implementare neacoperite de asistența automată

Alegeți metoda care se potrivește mediului dvs. Evitați amestecarea metodelor pe același dispozitiv: 

• Chei de registry: controlați implementarea și monitorizați rezultatele.
  Există mai multe chei de registry disponibile pentru controlul comportamentului implementării certificatelor și pentru monitorizarea rezultatelor. În plus, există două chei pentru a renunța la ajutoarele de implementare descrise mai sus. Pentru mai multe informații despre cheile de registry, consultați Cheia de registry Actualizări pentru Bootare sigură - dispozitive Windows cu actualizări gestionate de IT.

• Politică de grup Objects (GPO): Gestionați setările; monitorizați prin jurnale de registry și evenimente.
  Microsoft va oferi asistență pentru gestionarea actualizărilor secure Boot utilizând Politică de grup într-o actualizare viitoare. Rețineți că, deoarece Politică de grup este pentru setări, monitorizarea stării dispozitivului va trebui efectuată utilizând metode alternative, inclusiv monitorizarea cheilor de registry și a intrărilor din jurnalul de evenimente.

• WinCS (Sistem de configurare Windows) CLI: Utilizați instrumente în linia de comandă pentru clienții asociați la domeniu.
  Ca alternativă, administratorii de domeniu pot utiliza sistemul de configurare Windows (WinCS) inclus în actualizările sistemului de operare Windows pentru a implementa actualizările bootării securizate pe toți clienții și serverele Windows asociate la domeniu. Aceasta constă dintr-o serie de utilitare de linie de comandă (atât un executabil tradițional, cât și un modul PowerShell) pentru a interoga și a aplica local configurațiile Secure Boot pe o mașină. Pentru mai multe informații, consultați API-urile Sistemului de configurare Windows (WinCS) pentru bootare sigură.

• Microsoft Intune/Configuration Manager: Implementați scripturi PowerShell. Un Furnizor de servicii de configurare (CSP) va fi furnizat într-o actualizare viitoare pentru a permite implementarea utilizând Intune.

Monitorizarea jurnalelor de evenimente

Două evenimente noi sunt furnizate pentru a ajuta la implementarea actualizărilor certificatului de bootare securizată. Aceste evenimente sunt descrise în detaliu în evenimentele de actualizare a variabilei Secure Boot DB și DBX: 

• ID eveniment: 1801
  Acest eveniment este un eveniment de eroare care indică faptul că certificatele actualizate nu au fost aplicate la dispozitiv. Acest eveniment oferă câteva detalii specifice dispozitivului, inclusiv atributele dispozitivului, care vă vor ajuta să corelați dispozitivele care trebuie în continuare actualizate.

• ID eveniment: 1808
  Acest eveniment este un eveniment informativ care indică faptul că dispozitivul are noile certificate Secure Boot necesare aplicate la firmware-ul dispozitivului.

Strategii de implementare 

Pentru a minimiza riscul, implementați actualizări secure Boot în etape, nu simultan. Începeți cu un subset mic de dispozitive, validați rezultatele, apoi extindeți la grupuri suplimentare. Vă sugerăm să începeți cu subseturi de dispozitive și, pe măsură ce câștigați încredere în aceste implementări, adăugați subseturi suplimentare de dispozitive. Mai mulți factori pot fi utilizați pentru a determina ce intră într-un subset, inclusiv rezultatele testelor pe dispozitivele eșantion și structura organizației etc. 

Decizia cu privire la dispozitivele pe care le implementați depinde de dvs. Câteva strategii posibile sunt listate aici. 

• Flota mare de dispozitive: începeți prin a vă baza pe asistența descrisă mai sus pentru cele mai comune dispozitive pe care le gestionați. În paralel, concentrați-vă pe dispozitivele mai puțin comune gestionate de organizația dvs. Testați dispozitive mici eșantion și, dacă testarea reușește, implementați pe restul dispozitivelor de același tip. Dacă testarea produce probleme, investigați cauza problemei și determinați pașii de remediere. De asemenea, se recomandă să luați în considerare clasele de dispozitive care au o valoare mai mare în flota dvs. și să începeți testarea și implementarea, pentru a vă asigura că dispozitivele respective au o protecție actualizată la început.

• Flota mica, o mare varietate: Dacă flota pe care o gestionați conține o mare varietate de mașini în care testarea dispozitivelor individuale ar fi prohibitivă, luați în considerare să vă bazați pe cele două asistări descrise mai sus, mai ales pentru dispozitivele care ar putea fi dispozitive comune pe piață. Inițial, concentrați-vă pe dispozitivele care sunt esențiale pentru funcționarea de zi cu zi, testați și apoi implementați. Continuați mutarea în jos a listei de dispozitive cu înaltă prioritate, testarea și implementarea în timp ce monitorizarea flotei pentru a confirma că asistența sunt de ajutor cu restul dispozitivelor.

Note 

• Fiți atent la dispozitivele mai vechi, în special la dispozitivele care nu mai sunt acceptate de producător. Deși firmware-ul ar trebui să efectueze corect operațiunile de actualizare, este posibil ca unele să nu funcționeze. În cazurile în care firmware-ul nu funcționează corect și dispozitivul nu mai este în asistență, luați în considerare înlocuirea dispozitivului pentru a asigura protecția Secure Boot în întreaga flotă.

• Noile dispozitive fabricate în ultimii 1-2 ani pot avea deja instalate certificatele actualizate, dar este posibil să nu aibă managerul de boot semnat Windows UEFI CA 2023 aplicat la sistem. Aplicarea acestui manager de boot este un ultim pas critic în implementarea pentru fiecare dispozitiv.

• După ce un dispozitiv a fost selectat pentru actualizări, poate dura un timp înainte ca actualizările să se finalizeze. Estimați 48 de ore și una sau mai multe reporniri pentru certificatele de aplicat.

Probleme și recomandări comune

Acest ghid descrie în detaliu modul în care funcționează procesul de actualizare a certificatului de bootare securizată și prezintă câțiva pași de depanare pentru a depana dacă apar probleme în timpul implementării pe dispozitive. Actualizări la această secțiune vor fi adăugate după cum este necesar.

Suport pentru implementarea certificatului de bootare securizat 

În sprijinul actualizărilor certificatului de bootare securizată, Windows menține o activitate programată care rulează o dată la fiecare 12 ore. Activitatea caută biți în cheia de registry AvailableUpdates care necesită procesare. Biții de interes utilizați pentru implementarea certificatelor se află în tabelul următor. Coloana Ordine indică ordinea în care sunt procesați biții.

Fiecare bit este procesat de evenimentul planificat în ordinea dată în tabelul de mai sus.

Progresia prin biți ar trebui să arate astfel: 

1. Start: 0x5944

2. 0x0040 → 0x5904 (S-a aplicat cu succes Windows UEFI CA 2023)

3. 0x0800 → 0x5104 (S-a aplicat Microsoft UEFI CA 2023, dacă este necesar)

4. 0x1000 → 0x4104 (S-a aplicat Opțiunea Microsoft ROM UEFI CA 2023, dacă este necesar)

5. 0x0004 → 0x4100 (Aplicat Microsoft Corporation KEK 2K CA 2023)

6. 0x0100 → 0x4000 (s-a aplicat managerul de boot semnat Windows UEFI CA 2023)

Note

• După finalizarea cu succes a operațiunii asociate cu un pic, acel bit este eliminat din cheia AvailableUpdates .

• Dacă una dintre aceste operațiuni nu reușește, se înregistrează un eveniment și operațiunea este reîncercată data viitoare când rulează activitatea planificată.

• Dacă bit 0x4000 este setat, acesta nu va fi șters. După ce au fost procesați toți ceilalți biți, cheia de registry AvailableUpdates va fi setată la 0x4000.

Problema 1: Eroare de actualizare KEK: Dispozitivul actualizează certificatele la Secure Boot DB, dar nu progresează dincolo de implementarea noului certificat cheie Exchange pentru Secure Boot KEK. 

Notă În prezent, când apare această problemă, un ID de eveniment: 1796 va fi înregistrat în jurnal (consultați Evenimentele de actualizare a variabilei Secure Boot DB și DBX). Un eveniment nou va fi furnizat în ediția ulterioară pentru a indica această problemă specifică. 

Cheia de registry AvailableUpdates de pe un dispozitiv este setată la 0x4104 și nu șterge 0x0004 biți, chiar și după ce au trecut mai multe reporniri și timp considerabil. 

Problema ar putea fi că nu există un KEK semnat de PK OEM pentru dispozitiv. OEM controlează PK pentru dispozitiv și este responsabil pentru semnarea noului certificat Microsoft KEK și returnarea acestuia la Microsoft, astfel încât să poată fi inclus în actualizările cumulative lunare. 

Dacă întâmpinați această eroare, consultați producătorul OEM pentru a confirma că a urmat pașii subliniați în Instrucțiuni de creare și gestionare a cheilor de boot securizate Windows.  

Problema 2: Erori de firmware: Atunci când aplicați actualizările certificatului, certificatele sunt transmise firmware-ului pentru a se aplica variabilelor Secure Boot DB sau KEK. În unele cazuri, firmware-ul va returna o eroare. 

Atunci când apare această problemă, Bootarea sigură va înregistra un ID de eveniment: 1795. Pentru informații despre acest eveniment, consultați Evenimente de actualizare a variabilei Secure Boot DB și DBX. 

Vă recomandăm să consultați producătorul OEM pentru a vedea dacă este disponibilă o actualizare de firmware pentru dispozitiv pentru a rezolva această problemă.