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 नियम जुना राहू देतो।