Akreditācijas datu aizsardzība: reāla ietekme uz veiktspēju un kā to pārvaldīt

Kad Windows datoros, īpaši vecākā aparatūrā, tiek aktivizēta Credential Guard, daudzi administratori ir pārsteigti: Sistēma kļūst drošāka, jā, bet... veiktspējas kritums Diezgan nopietni. Dažos gadījumos pārnēsājamas Un vecākos galddatoros dators pāriet no nevainojamas darbības uz lēnu, vienkārši iespējojot šo papildu virtualizācijas aizsardzības slāni.

Šāda uzvedība nav atsevišķs gadījums vai kaut kas raksturīgs tikai konkrētam iekārtu zīmolam; Tas ir tieši saistīts ar to, kā darbojas uz virtualizāciju balstīta drošība (VBS), kā tā balstās uz Hyper-V un CPU paplašinājumiem, piemēram, Intel VT-x/VT-d un tādās tehnoloģijās kā MBEC, kā arī ar to, ka noteiktas lietojumprogrammas (īpaši mantotas no Windows XP vai līdzīgiem laikiem) nebija paredzētas līdzāspastāvēšanai ar šo pastiprināto drošības modeli.

Kas ir Credential Guard un kāpēc tas var palēnināt datora darbību?

Saistītais raksts:

Ražošanai gatavas virtuālās mašīnas? Stabilitāte, veiktspēja un kad tās izvēlēties

Credential Guard ir Windows drošības līdzeklis, kas izolē un aizsargā pieteikšanās akreditācijas datus. (NTLM jaucējkodas, Kerberos piešķiršanas biļetes, akreditācijas dati, kas glabājas akreditācijas datu pārvaldniekā, utt.) vidē, ko aizsargā hipervizors. Šie noslēpumi netiek atstāti operētājsistēmas parastajā atmiņas telpā, bet gan izolētā apakšsistēmā, kurai var piekļūt tikai sistēmas programmatūra ar atbilstošām privilēģijām.

Galvenais mērķis ir mazināt akreditācijas datu zādzību uzbrukumus. piemēram, “pārsūtot jaukšanas kodu” un “pārsūtot biļetes”, kas ir ļoti izplatītas mērķtiecīgos uzbrukumos un progresīvos pastāvīgajos apdraudējumos (APT). Pat ja uzbrucējs iegūst administratora privilēģijas operētājsistēmā, piekļuve VBS aizsargātajiem noslēpumiem tiek bloķēta, ievērojami sarežģījot sānu pārvietošanos tīklā.

Lai nodrošinātu šo izolāciju, Credential Guard izmanto virtualizācijas drošību (VBS).Tas izmanto Windows hipervizoru (Hyper-V), lai izveidotu atmiņas vidi, kas ir atdalīta no pārējās sistēmas. Galvenie procesi, piemēram, lokālā drošības iestāde (LSA), darbojas aizsargātā variantā (izolēta LSA, LSAIso.exe), kas vairs nekoplieto to pašu atmiņas vietu, kas ir pieejama nevienam procesam ar paaugstinātām privilēģijām.

Kur izpaužas ietekme uz sniegumu? Sistēmās ar moderniem procesoriem (īpaši Intel 7. paaudzes un vēlākiem ar MBEC/GMET vai AMD ekvivalentiem) izmaksas parasti ir mērenas. Tomēr vecākos procesoros, kuriem trūkst šo instrukciju, Windows ir jāizmanto noteiktu izpildes kontroles mehānismu programmatūras emulācija, un tieši tur... Ir novērota veiktspējas samazināšanās par 30–40 % dažos reālos gadījumos, īpaši ar vecākas paaudzes profesionālajiem klēpjdatoriem.

Tādās iekārtās kā Dell Latitude 7280 un citos korporatīvajos modeļos ar centrālajiem procesoriem, kas ir vecāki par Intel 7. paaudziVairāki administratori ir ziņojuši, ka ar "tīru" Windows 10 instalāciju dators darbojas nevainojami, taču, izvietojot korporatīvo attēlu ar VBS, Credential Guard un daudzos gadījumos ar hipervizora aizsargātu koda integritāti (HVCI/Memory Integrity), viss kļūst lēnāks: zābaks, lietojumprogrammu atvēršana, vispārējie atbildes laiki, Uc

Saistība starp Credential Guard, VBS, HVCI un citiem komponentiem

Credential Guard nedarbojas vakuumā; tā ir daļa no drošības funkciju ekosistēmas, kas balstīta uz Hyper-V.Šajā pašā grupā mēs atrodam Device Guard (jeb App Control uzņēmumiem tās attīstības posmā), atmiņas integritāti (HVCI) un citas funkcijas, piemēram, Windows Sandbox, WSL2 vai pat pašu virtuālās mašīnas platformu.

VBS darbojas kā kopēja bāze, kas ļauj izveidot izolētu vidi.Šajā vidē darbojas kritiski svarīgi komponenti, piemēram, kodola režīma koda integritāte, izolētā LSA un citi pakalpojumi, kas gūst labumu no šīs atdalīšanas. Vispirms tiek startēts Windows hipervizors, pēc tam operētājsistēma darbojas "virs tā", un šai aizsargātajai videi tiek rezervētas noteiktas atmiņas zonas.

HVCI (hipervizora nodrošināta koda integritāte), kas pazīstama arī kā atmiņas integritāte, ir vēl viena svarīga mīklas sastāvdaļa.Tā ir atbildīga par to, lai pārbaudītu, vai kods, kas darbojas kodola režīmā, atbilst stingrām prasībām: tiek ielādēti tikai pareizi parakstīti draiveri, tiek kavētas atmiņas izmantošanas metodes un tiek novērota tipiska uzvedība. malware un nulles dienas uzbrukumi, kas vērsti pret kodolu.

Daudzos korporatīvos scenārijos, kad ir iespējota Credential Guard funkcija, parasti tiek aktivizēta arī HVCI.To var izdarīt tieši vai kā daļu no drošības politikas, kas nodrošina VBScript ar uzlabotu koda integritāti. Šī kombinācija maksimāli palielina drošību, bet arī palielina slodzi: papildu pārbaudes, ievades/izvades ierobežojumus, palielinātu hipervizora izmantošanu un lielāku slodzi uz centrālo procesoru un atmiņu.

Microsoft ir pastiprinājis savu drošības nostāju ar jaunākajām versijām Windows 11Sākot ar Windows 11 22H2 un Windows Server 2025, VBS un Credential Guard pēc noklusējuma ir iespējoti atbilstošās ierīcēs. Šī aktivizācija parasti tiek veikta "bez UEFI bloķēšanas", lai administratori varētu attālināti atspējot Credential Guard, ja nepieciešams, taču patiesībā daudzi jauni datori tiek piegādāti ar šīm aizsardzības funkcijām, kas ir iespējotas jau no pirmās dienas.

Credential Guard aparatūras, programmaparatūras un licencēšanas prasības

Lai Credential Guard un pārējās VBS funkcijas darbotos pareizi un ar pēc iespējas mazāku ietekmi, aparatūrai un programmaparatūrai ir jāatbilst noteiktām minimālajām prasībām.Jo modernāks un atbilstošāks šīm prasībām ir aprīkojums, jo labāks būs drošības un veiktspējas līdzsvars.

Credential Guard pamatprasības aparatūrai ietver:

• 64 bitu centrālais procesors, ar aparatūras virtualizācijas paplašinājumiem (Intel VT-x vai AMD-V) un atbalstu paplašinātām lapu tabulām.
• IOMMU (Intel VT-d vai AMD-Vi) lai uzlabotu ierīču izolāciju un mazinātu uz DMA balstītus uzbrukumus.
• TPM 1.2 vai vēlams TPM 2.0 lai nodrošinātu akreditācijas datu un sāknēšanas ķēdes aparatūras piesaisti.

Runājot par programmaparatūru, ir svarīgi, lai būtu UEFI 2.3.1 vai jaunāka versija ar iespējotu drošo sāknēšanu.Papildus drošiem programmaparatūras atjaunināšanas mehānismiem, sāknēšanas konfigurācijas aizsardzībai un drošai atmiņas pārrakstīšanas pieprasījuma (MOR) ieviešanai, lai nodrošinātu, ka parametrus, kas ietekmē VBS, nevar viegli manipulēt.

Attiecībā uz licencēšanu Credential Guard nav pieejams visos Windows izdevumos.Tas tiek atbalstīts uz:

• Windows Enterprise.
• Windows Izglītība.

Licences, kas dod lietotājam tiesības izmantot Credential Guard, ietver Windows Enterprise E3 un E5, kā arī izglītības versijas A3 un A5. Tā nav pieejama operētājsistēmās Windows Pro, Pro Education/SE vai Home, ja vien tā netiek jaunināta uz Enterprise, izmantojot lielapjoma licencēšanas līgumu.

Ražotāji, piemēram, Dell, ir publicējuši ļoti detalizētas saderības matricas. Latitude, OptiPlex, Precision, XPS un Rugged modeļiem, norādot minimālās versijas BIOS, vadītājiem un mikroshēmojumu komplektus, kas nodrošina sistēmas “gatavību” Device Guard un Credential Guard. Šajos sarakstos ir precizēts, kuras audio, grafikas, Wi-Fi, Bluetooth versijas glabāšana un citi autovadītāji Tie ir apstiprināti darbam ar HCCI, neizraisot negaidītas avārijas vai veiktspējas kritumus.

Praktiska ietekme uz sniegumu: reāli gadījumi un tipiski scenāriji

Papildus teorijai daudzas organizācijas satrauc tas, kas notiek praksē, kad tiek aktivizēta Credential Guard.datori, kuru palaišana aizņem ilgāku laiku, korporatīvās lietojumprogrammas, kas tiek atvērtas ar aizkavēšanos, veci rīki, kas, šķiet, "avarē", un lietotāji, kas zvana atbalsta dienestam, jo ​​"jaunais dators ir sliktāks par veco".

Darbstacijās, kurās darbojas operētājsistēma Windows 10 Enterprise (piemēram, versija 1607 LTSC vai 1803), ir dokumentēti scenāriji, kuros pēc attēlu izvietošanas ar iespējotu Credential Guard un HVCI kopējā veiktspēja ievērojami samazinās.Atspējojot šīs funkcijas, tiek atjaunota normāla sistēmas darbība. Šis efekts ir izteiktāks sistēmās ar vecākiem centrālajiem procesoriem, tām, kurām trūkst MBEC, un vidēs, kurās darbojas mantotas lietojumprogrammas, kas ir ļoti intensīvas sistēmas izsaukumos vai izmanto slikti optimizētus draiverus. Lai kvantitatīvi noteiktu šo ietekmi uz atmiņu, var izmantot tādus rīkus kā [šeit ievietojiet rīka piemēru]. RAM veiktspējas mērīšana.

Vēl viena izplatīta pazīme ir palielināta centrālā procesora izmantošana un latentums procesos, kas saistīti ar LSAIso.exevai ar lietojumprogrammām, kas mēģina mijiedarboties ar izolēto akreditācijas datu apakšsistēmu. Daži rīki, kas mēģina lasīt Kerberos TGT, manipulēt ar NTLM jaucējkodiem vai netieši deleģēt akreditācijas datus, var saskarties ar lielāku pretestību, tikt bloķēti vai izraisīt kavēšanos atkārtotu mēģinājumu dēļ.

Tiek ietekmēta ne tikai operētājsistēmas veiktspēja, bet arī citas darba slodzes, kas ir atkarīgas no virtualizācijas, var tikt pasliktinātas.Kad ir aktīvi VBS un Credential Guard, Hyper-V pārņem ekskluzīvu CPU virtualizācijas paplašinājumu kontroli. Tas neļauj 2. tipa hipervizoriem, piemēram, VMware Workstation, VMware Player vai Oracle VirtualBox, tieši piekļūt Intel VT-x/AMD-V, kā rezultātā rodas tipiskas kļūdas, piemēram, "VT-x nav pieejams" vai tieši Device/Credential Guard nesaderības ziņojumi.

Vecākajās VMware Workstation un VirtualBox versijās vienīgais risinājums bija atspējot Hyper-V un, attiecīgi, atspējot VBS un Credential Guard.Tas nozīmē drošības priekšrocību upurēšanu apmaiņā pret iespēju darbināt trešo pušu virtuālās mašīnas ar labu veiktspēju. Pavisam nesen gan VMware, gan Oracle ir iekļāvuši atbalstu Windows Hypervisor Platform (WHP), ļaujot savām virtuālajām mašīnām darboties, izmantojot Hyper-V API, lai gan ar noteiktiem ierobežojumiem (nav ligzdotas virtualizācijas, trūkst dažu veiktspējas skaitītāju, ir zināms veiktspējas zudums utt.).

Daudzos gadījumos lietotāji pat nebija tieši instalējuši Hyper-V.Tomēr, kad VBS, Device Guard vai Credential Guard tika iespējoti, izmantojot Windows 10 atjauninājumus (piemēram, no versijas 1607), hipervizors tika iespējots fonā, izraisot nesaderību ar VMware Workstation vai VirtualBox.

Šo konfliktu klasiskie risinājumi bija vairāki:

• Atinstalēt Hyper-V lomu un saistītās funkcijas no grafiskās lietotāja saskarnes (Vadības panelis > Ieslēgt vai izslēgt Windows funkcijas) vai no PowerShell/DISM.
• Atspējot hipervizora startēšanu, bcdedit /set hypervisorlaunchtype offpilnībā neatinstalējot Hyper-V.
• Izveidojiet divkāršās sāknēšanas ierakstus (ar un bez Hyper-V), lai katrā atkārtotas palaišanas reizē izvēlētos, vai sistēma tiks startēta ar aktīvu VBS/Hyper-V vai "vietējā" režīmā, lai darbotos ar citiem hipervizoriem.

ar el tiempoMicrosoft izlaida Windows Hypervisor Platform (WHP), kas ļauj VMware Workstation (sākot ar 15.5.6 versiju un vēlāk) un VirtualBox (sākot ar 6.x sēriju un vēlāk) darboties, izmantojot Hyper-V API.Šajā "VBS resursdatora režīmā" virtuālās mašīnas monitors zaudē tiešu piekļuvi VT-x/AMD-V un darbojas lietotāja līmenī, deleģējot centrālā procesora virtualizācijas darbības Hyper-V. Tas ir kompromiss: VBS/Device Guard/Credential Guard paliek aktīvi, taču trešo pušu virtuālajās mašīnās ir neliels veiktspējas zudums, un tiek pieņemti daži ierobežojumi (nav ligzdotas virtualizācijas VMware virtuālajās mašīnās, nav noteiktu veiktspējas skaitītāju utt.).

Tomēr scenārijos, kuros prioritāte ir VMware vai VirtualBox virtuālo mašīnu maksimāla veiktspējaDaudzi administratori joprojām izvēlas īslaicīgi atspējot Hyper-V, VBS un Credential Guard izstrādes datoros, laboratorijās vai uzlabotās pārvaldības darbstacijās.

Lietojumprogrammu un pakalpojumu saderība, iespējojot Credential Guard

Aktivizējot Credential Guard, mainās ne tikai veiktspēja, bet arī sistēmas autentifikācijas modelis.Dažas funkcijas un protokoli ir pilnībā bloķēti, citi tiek uzskatīti par neieteicamiem, bet citi turpina darboties normāli, bet iziet cauri izolētas vides filtram.

Starp funkcijām, kas kļūst nepieejamas, ja ir iespējota akreditācijas aizsardzība, ir šādas::

• šifrēšanas izmantošana DES Kerberosam.
• Kerberos deleģēšana bez ierobežojumi.
• Tieša ekstrakcija TGT no Kerberos.
• Autentifikācija NTLMv1.

Lietojumprogrammas, kas paļaujas uz šiem mehānismiem, var tieši sabojātiesNeveiksmīgas autentifikācijas pret pakalpojumiem, kļūdas mantotajās Kerberos deleģēšanās procedūrās, uzņēmumu Wi-Fi sistēmas, kas izmanto novecojušas autentifikācijas metodes utt. Pirms Credential Guard ieviešanas organizācijā plašā mērogā ir svarīgi iepriekš pārbaudīt visas kritiskās lietojumprogrammas.

Citas funkcijas, kas joprojām ir iespējamas, bet palielina uzbrukuma virsmu, ja tās tiek ļaunprātīgi izmantotas, pat ja ir aktīvs akreditācijas datu aizsardzības līdzeklis, ir::

• Autentifikācija netiešs.
• Deleģēšana akreditācijas dati.
• MS-CHAPv2.
• CredSSP.

Bieži sastopamie pakalpojumi, piemēram, SMB failu koplietošana, attālā darbvirsma vai lietojumprogrammas, kas izmanto "moderno" Kerberos, turpina darboties normāli.ar nosacījumu, ka tās nemēģina tieši iegūt vai manipulēt ar VBS vides aizsargātajiem noslēpumiem. Tomēr, ja noteiktas lietojumprogrammas mēģina agresīvi saistīties ar LSAIso.exe procesu vai izmanto neatbalstītas metodes, var rasties papildu veiktspējas problēmas vai pat avārijas.

Vidēs ar IIS, uzlabotu Wi-Fi autentifikāciju vai mantotiem tīmekļa autentifikācijas risinājumiemProblēmas ir novērotas, ja konfigurācijas atbalsta vecās shēmas (piemēram, NTLMv1, DES Kerberos vai “atvērtās” deleģēšanas), piespiežot pārveidot daļu infrastruktūras vai izveidot izņēmumus, ja nav iespējams nekavējoties atjaunināt visas komponentes.

Mijiedarbība ar citiem hipervizoriem: Hyper-V, VMware, VirtualBox un VBS

Lai Credential Guard darbotos, Windows hipervizoram (Hyper-V) ir jābūt ielādētam sāknēšanas laikā un tam ir jāpārņem centrālā procesora virtualizācijas paplašinājumu kontrole.Tam ir tiešas sekas: neviens cits 2. tipa hipervizors nevar tieši izmantot Intel VT-x vai AMD-V, kamēr Hyper-V ir aktīvs.

Vēsturiski tas izraisīja tādas kļūdas kā:

• "VMware Workstation Hyper-V un Hyper-V nav saderīgi. Noņemiet lomu Hyper-V…”
• “VMware darbstacija un Ierīces/akreditācijas datu aizsardzība Tie nav saderīgi. VMware Workstation var palaist pēc Device/Credential Guard atspējošanas.
• BSOD programmā VirtualBox (SYSTEM_SERVICE_EXCEPTION), ziņojumi “VT-x nav pieejams (VER_VMX_NO_VMX)” vai ārkārtīgi lēnas virtuālās mašīnas, kas izmanto paravirtualizācijas/emulācijas režīmu.

Daudzos gadījumos lietotāji pat nebija tieši instalējuši Hyper-V.Tomēr, kad VBS, Device Guard vai Credential Guard tika aktivizēti, izmantojot Windows 10 atjauninājumus (piemēram, no versijas 1607), hipervizors tika iespējots fonā, izraisot nesaderību ar VMware Workstation vai VirtualBox.

Šo konfliktu klasiskie risinājumi bija vairāki:

• Atinstalēt Hyper-V lomu un saistītās funkcijas no grafiskās lietotāja saskarnes (Vadības panelis > Ieslēgt vai izslēgt Windows funkcijas) vai no PowerShell/DISM.
• Atspējot hipervizora startēšanu, bcdedit /set hypervisorlaunchtype offpilnībā neatinstalējot Hyper-V.
• Izveidojiet divkāršās sāknēšanas ierakstus (ar un bez Hyper-V), lai katrā atkārtotas palaišanas reizē izvēlētos, vai sistēma tiks startēta ar aktīvu VBS/Hyper-V vai "vietējā" režīmā, lai darbotos ar citiem hipervizoriem.

Laika gaitā Microsoft izlaida Windows Hypervisor Platform (WHP), kas ļauj VMware Workstation (sākot ar 15.5.6 versiju un vēlāk) un VirtualBox (sākot ar 6.x sēriju un vēlāk) darboties, izmantojot Hyper-V API.Šajā "VBS resursdatora režīmā" virtuālās mašīnas monitors zaudē tiešu piekļuvi VT-x/AMD-V un darbojas lietotāja līmenī, deleģējot centrālā procesora virtualizācijas darbības Hyper-V. Tas ir kompromiss: VBS/Device Guard/Credential Guard paliek aktīvi, taču trešo pušu virtuālajās mašīnās ir neliels veiktspējas zudums, un tiek pieņemti daži ierobežojumi (nav ligzdotas virtualizācijas VMware virtuālajās mašīnās, nav noteiktu veiktspējas skaitītāju utt.).

Tomēr scenārijos, kuros prioritāte ir VMware vai VirtualBox virtuālo mašīnu maksimāla veiktspējaDaudzi administratori joprojām izvēlas īslaicīgi atspējot Hyper-V, VBS un Credential Guard izstrādes datoros, laboratorijās vai uzlabotās pārvaldības darbstacijās.

Kā iespējot un atspējot VBS, HVCI un Credential Guard ar detalizētu kontroli

Credential Guard un citus VBS komponentus var pārvaldīt vairākos veidos.: grupu politikas, reģistra modifikācijas, skripti PowerShelloficiāli validācijas rīki (piemēram, scenārijs Microsoft DG_Readiness.ps1) un pat konfigurācijas, izmantojot lietotņu vadību uzņēmumiem.

Lai iespējotu uz virtualizāciju balstītu drošību un nebloķējošu UEFI atmiņas integritāti katrā reģistrā, var izmantot sekojošo komandas stila (izpildīts ar administratora privilēģijām):

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 0 /f

Ja vēlaties iespējot tikai VBS, bez atmiņas integritātes, varat konfigurēt tikai atslēgu EnableVirtualizationBasedSecurity.RequirePlatformSecurityFeatures kontrolē, vai ir nepieciešama tikai drošā sāknēšana (vērtība 1) vai arī DMA aizsardzība (vērtība 3). Gan VBS, gan HVCI parametrs Locked nosaka, vai stāvoklis ir bloķēts, izmantojot UEFI (novēršot vienkāršas turpmākas izmaiņas), vai arī atstāts atvērts, lai to varētu mainīt programmatūra.

Pati Windows 10/11 saskarne piedāvā grafisku veidu, kā iespējot atmiņas integritāti. (HVCI) sadaļā Windows drošība > Ierīces drošība, taču lielās korporatīvajās vidēs biežāk tiek izmantotas grupu politikas, MDM profili vai automatizācijas skripti.

Lai pārbaudītu VBS, Credential Guard un atmiņas integritātes faktisko statusu, var izmantot vairākus rīkus.:

• Komanda msinfo32.exe"Sistēmas kopsavilkumā" ir parādīts, vai ir aktīva uz drošību balstīta virtualizācija, vai ir iespējota Device Guard funkcija un kādi pakalpojumi darbojas.
• WMI klase Win32_DeviceGuard, kam var piekļūt ar PowerShell, izmantojot:
  Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Šīs klases lauki ļauj uzzināt, kuri aparatūras drošības rekvizīti ir pieejami (AvailableSecurityProperties)., kādas prasības tiek pieprasītas (RequiredSecurityProperties), vai VBS ir iespējots un darbojas (VirtualizationBasedSecurityStatus), vai akreditācijas datu aizsardzība un/vai atmiņas integritāte ir konfigurēta un aktīva (SecurityServicesConfigured, SecurityServicesRunning), un atbilstības koda integritātes politikām režīms (CodeIntegrityPolicyEnforcementStatus).

Ja kaut kas noiet greizi, piemēram, nesaderīgs draiveris izraisa zilus ekrānus vai sistēma kļūst nestabila Pēc atmiņas integritātes iespējošanas izmaiņas var atsaukt no Windows atkopšanas vides (Windows RE), atspējojot atbilstošās reģistra atslēgas un pārskatot grupas politikas pirms normālas restartēšanas.

Credential Guard un HVCI izmantošana Hyper-V virtuālajās mašīnās

Akreditācijas datu aizsardzība un atmiņas integritāte nav ierobežota tikai ar fiziskām iekārtām; tās var izmantot arī 2. paaudzes Hyper-V virtuālajās mašīnās.ar nosacījumu, ka resursdators atbilst prasībām (vismaz Windows 10/Windows Server 2016 atmiņas integritātes ziņā).

Šajā scenārijā VBS aizsargā noslēpumus un kodolu pašā viesa virtuālajā mašīnā.sistēmas nostiprināšana pret ļaunprogrammatūru vai uzbrukumiem konkrētajai iekārtai. Tomēr resursdatoram vienmēr ir pietiekamas privilēģijas, lai atspējotu aizsardzību virtuālajā mašīnā (piemēram, izmantojot Set-VMSecurity -VirtualizationBasedSecurityOptOut $true), tāpēc tā nav aizsardzība pret ļaunprātīgiem resursdatora administratoriem, bet gan pret uzbrukumiem "no iekšienes" virtuālajās mašīnas.

Izmantojot atmiņas integritāti virtuālajās mašīnās, ir jāņem vērā daži ierobežojumi.:

• Virtuālie šķiedru kanāla adapteri ar AllowFullSCSICommandSet un dažos konkrētos disku caurlaišanas scenārijos var būt nepieciešams atspējot uz virtualizāciju balstītu drošību attiecīgajā virtuālajā mašīnā.
• Ir iespējams apvienot atmiņas integritāti ar ligzdota virtualizācijaTomēr konfigurācija jāveic uzmanīgi, lai izvairītos no resursu konfliktiem un straujas veiktspējas krituma.

No veiktspējas viedokļa VBS un Credential Guard iespējošana virtuālajās mašīnās pievieno vēl vienu virtualizācijas slāni.Tāpēc ieteicams viesu datoriem piešķirt pietiekamus centrālā procesora un operatīvās atmiņas resursus un izvairīties no šo aizsardzības pasākumu iespējošanas virtuālajās mašīnās, kurām jau ir nepietiekama jauda vai kurās darbojas programmatūra, kas ir ļoti jutīga pret latentumu.

Operacionālā līmenī daudzas organizācijas izvēlas iespējot Credential Guard un HVCI virtuālajās mašīnās, kas darbojas kā domēna kontrolleri, autentifikācijas serveri vai kritiski administratīvie datori.kur akreditācijas datu un kodola aizsardzības stiprināšanas vērtība vairāk nekā kompensē papildu resursu izmaksas.

Akreditācijas datu aizsardzība, VBS un atmiņas integritāte nodrošina ļoti spēcīgu aizsardzības slāni pret akreditācijas datu zādzību uzbrukumiem un kodola ļaunprātīgu izmantošanu.Tomēr tām ir nepieciešama atbilstoša aparatūra un programmaparatūra, skaidrs saderīgu lietojumprogrammu saraksts, rūpīga Hyper-V un citu hipervizoru pārvaldība, kā arī pārdomāti lēmumi par to, kur iespējot vai atspējot šīs funkcijas, lai izvairītos no perfekti spējīgas aparatūras pārvēršanas par neapmierinoši lēnām iekārtām. Pareizo darbstaciju, serveru un virtuālo mašīnu izvēle šo tehnoloģiju iespējošanai ļauj atrast pareizo līdzsvaru starp stabilu drošību un pieņemamu veiktspēju ikdienas lietošanai.

Isaac

Kaislīgs rakstnieks par baitu pasauli un tehnoloģiju kopumā. Man patīk dalīties savās zināšanās rakstot, un tieši to es darīšu šajā emuārā, parādot visu interesantāko informāciju par sīkrīkiem, programmatūru, aparatūru, tehnoloģiju tendencēm un daudz ko citu. Mans mērķis ir palīdzēt jums vienkāršā un izklaidējošā veidā orientēties digitālajā pasaulē.