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 წესს მოძველებულს ტოვებს.