Visual Studio-ն դանդաղում է միայն VPN-ում. ստուգեք CRL-ը և OCSP-ը

Visual Studio-ն տանը սկսվում է սովորական, ապա նույն նոութբուքը միանում է կորպորատիվ թունելին, և յուրաքանչյուր մեկնարկ կես րոպե կանգնում է մեկնարկային էկրանին։ Հեռացրեք քաղաքականությունը, և ուշացումը կանհետանա նրա հետ; հեռացրեք թունելը, և նույնը կպատահի։ Երկու դիտարկումներն էլ ճիշտ են, դրա համար էլ երկու բաղադրիչները մշտապես մեղադրում են միմյանց։ Վճռորոշ հարցն այն է՝ արդյոք վկայագրի չեղարկման հարցումը սպասում է մի ուղու, որը տրամադրում է միայն թունելը, թե ընդհանրապես այդպիսին չի գտնում։

Չափեք բեռնումը, ոչ թե մեկնարկը

Մեկ WDAC քաղաքականություն, որը տեղակայված է որպես ստորագրված SiPolicy.p7b ֆայլ, որոշում է, թե որ պատկերները կարող են աշխատել մեքենայում։ Կոդի ամբողջականությունը ստուգում է պատկերի ստորագրությունների շղթան կատարումից առաջ, և այդ ստուգումը կարող է ներառել չեղարկման հարց։ Պատասխանը կախված է CRL բաշխման կետից կամ OCSP պատասխանողից, որը վկայագիրը նշում է իր ներսում։

Դրանք սովորական ցանցային հարցումներ են, ուստի դրանց արժեքը կախված է նրանից, թե որտեղ է գտնվում պատասխանողը։ Երբ այն հասանելի է միայն թունելով, կամ նրա անունը լուծվում է միայն թունելի հետևում գտնվող DNS սերվերի միջոցով, ստուգումը սպասում է, որ թունելը պատրաստ լինի։ Visual Studio-ն մեկնարկելիս բեռնում է մեծ թվով ստորագրված հավաքածուներ և ընդլայնումներ, և յուրաքանչյուր պատկերի փոքր ուշացումը դառնում է տեսանելի կանգ։ Ոչինչ աղավաղված չէ, և քաղաքականությունը վարվում է ճիշտ այնպես, ինչպես կարգավորված է, դրա համար էլ քաղաքականության հեռացումը թվում է, թե լուծում է խնդիրը։

Յուրաքանչյուր ստորագրված պատկեր կարող է ցանցային կանչ առաջացնել

Սկսեք սկավառակի վրա արդեն եղած ստորագրված բինար ֆայլից և խնդրեք հարթակին ստուգել այն նույն բեռնման վարքով, որն օգտագործում է մեկնարկը։ Գործարկեք հրամանը մեկ անգամ թունելի վրա և մեկ անգամ դրսում, ապա համեմատեք բեռնման տողերը, այլ ոչ թե վերջնական դատավճիռը։

certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80

Արդյունքը թվարկում է շղթան, CRL-ի և OCSP-ի հասցեները և այն, թե արդյոք յուրաքանչյուր բեռնում հաջողվել է։ Պատասխանողը, որը թունելի վրա ժամանակը սպառում է և դրսում պատասխանում, այն ապացույցն է, որ ձեզ պետք է, և այն շատ ավելի ծանր է կշռում, քան դանդաղության տպավորությունը։ Եթե բեռնումը դանդաղ հաջողվում է, գրանցեք հասցեն, որպեսզի հաջորդ քայլը կարողանա ուղղակիորեն փորձարկել այդ հոսթը։

Լուծեք պատասխանողի հոսթի անունը և փորձարկեք հասանելիությունը հավելվածից դուրս, որովհետև չլուծվող անունը երբեք չի ուղղվի ոչ մի կլիենտի կարգավորումով։ CodeIntegrity-ի գործառնական մատյանը տալիս է ապացույցի մյուս կեսը՝ կապելով ստուգման իրադարձությունը դանդաղ մեկնարկի ժամանակադրոշմի հետ։

Կրճատեք ուշացումը՝ չհեռացնելով վերահսկողությունը

Քաղաքականության անջատումը կամ աուդիտի ռեժիմի անցումը վերացնում է ուշացումը և հեռացնում կազմակերպության տեղակայած վերահսկողությունը, ուստի դա համարեք սխալ վերանորոգում։ Ավելի նեղ տարբերակներն են՝ երթուղու փոփոխություն, որպեսզի պատասխանողը հասանելի լինի թունելով, բացառություն բաժանված թունելում պատասխանողի հոսթերի համար, DNS-ի ուղղում, երբ անունը լուծվում է անհասանելի հասցեի, կամ աջակցվող քեշավորող պրոքսի չեղարկման տվյալների համար։ Յուրաքանչյուրն ունի տարբեր սեփականատեր՝ PKI թիմը պատասխանատու է պատասխանողի հասանելիության, ցանցային թիմը՝ թունելի բաժանման, իսկ վերջնակետերի թիմը՝ քաղաքականության։

Չեղարկման յուրաքանչյուր հոսթ թունելից բացառելը ինքնաբերաբար անվտանգ չէ, քանի որ ներքին պատասխանողը կարող է դիտավորյալ ներքին լինել։ Հաստատեք բացառությունը PKI-ն կառավարող թիմի հետ նախքան այնպիսի կանոն գրելը, որը հանգիստ ուղարկում է վկայագրերի ստուգումները հանրային ինտերնետ։ Առանց այդ հաստատման արված փոփոխությունը այն տեսակն է, որը հետ է վերցվում քաղաքականության հաջորդ թարմացման ժամանակ։

Փոփոխությունից հետո ստուգեք սառը մեկնարկը

Չափեք սառը մեկնարկը երկու վիճակում էլ և պահեք թվերը, որովհետև տաք մեկնարկը համարյա ոչինչ չի ապացուցում, երբ հավաքածուներն արդեն քեշում են։ Կրկնեք մեկնարկը նոր նստաշրջանից, որպեսզի ընդլայնումների բեռնման ուղին նորից աշխատի։

Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -MaxEvents 40 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-10) }
Get-ChildItem C:\Windows\System32\CodeIntegrity\CiPolicies\Active
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Վերանորոգված կոնֆիգուրացիան դեռ կապվում է պատասխանողի հետ կամ օգտագործում է ձեր PKI թիմի հաստատած քեշի ուղին, և մատյանը ցույց է տալիս, որ ստուգումն ավարտվում է, այլ ոչ թե ժամանակը սպառվում։ Հաստատեք, որ վերջերս ստորագրված հավելվածը դեռ մեկնարկում է, որովհետև ամեն ինչ թույլատրող քաղաքականությունը հաջող վերանորոգում չէ։ Ստուգեք նաև ակտիվ քաղաքականության պանակը և կիրարկման վիճակը, որպեսզի հայտնի լինի, որ վրիպազերծվող քաղաքականությունը հենց աշխատողն է։ Պահեք վկայագրերի շղթան, պատասխանողի հասցեն և մեկնարկի ժամանակադրոշմերը նույն տոմսում, որովհետև թարմացումը սովորաբար տեղափոխում է պատասխանողին և բացառության կամ DNS կանոնը թողնում է հնացած։