Zero trust 30-კაციანი კომპანიისთვის: VPN, reverse proxy და პატჩი, რომელიც პროდაქშენამდე მივიდა

Zero trust ბანკის თემად ჟღერს, რომელსაც უსაფრთხოების განყოფილება აქვს. ამ კვირაში მასზე Forrester-მა, Red Hat-მა და Docker-მა დაწერეს, და თითოეულთან სტრიქონებს შორის ერთი და იგივე კითხვაა: რა გააკეთოს აქედან კომპანიამ, სადაც უსაფრთხოების განყოფილება არ არის, არის კი ერთი ადამიანი, რომელიც სერვერზე აგებს პასუხს. რამდენიმე კომპანიაში ასეთი ადამიანი მე ვარ, და ქვემოთ ის არის, რაც ამისგან ჩამომიყალიბდა.

რა გამოვიდა

Forrester-მა 23 ოქტომბერს ხელახლა აიღო თემა „Zero Trust ლუდის ბიუჯეტზე“ და ტექსტს „მინიმალურად სიცოცხლისუნარიანი zero trust“ უწოდა. შესავლიდან ადრესატი გასაგებია: ის, ვინც საეტალონო არქიტექტურები და BeyondCorp წაიკითხა, სიმწიფის ერთ-ერთ მოდელში საკუთარი თავის პოვნა სცადა და ვერ გაიგო, საიდან დაიწყოს. Forrester-ის რეცეპტს არ გადმოვცემ, ჩემსას ვიტყვი.

Red Hat-მა 22 ოქტომბერს გამოაქვეყნა OpenShift-ში zero trust-ზე სტატიების ციკლის მეოთხე ნაწილი. იქიდან ფორმულირება ზუსტია: zero trust-ის აღწერა ერთი ფრაზით ადვილია, „არასოდეს ენდო, ყოველთვის შეამოწმე“, განმეორებადად ქცევა კი რთული. ფრაზა არ ამბობს, რა დაინერგოს ორშაბათს დილით და როგორ აჩვენო შემმოწმებელს, რომ კონტროლი მუშაობს. OpenShift 30-კაციანი კომპანიისთვის სხვა მასშტაბია, მაგრამ ორშაბათის კითხვა სწორია.

სამი დღით ადრე, 19 ოქტომბერს, Red Hat-მა პატჩებზე დაწერა, და ეს, ჩემი აზრით, კვირის მთავარი ტექსტია. პატჩი რამდენიმე დღეში მზად იყო, პროდაქშენამდე კი თვეობით მიდიოდა. კლიენტებთან საუბრებში პასუხი თითქმის არასოდეს არის „არ ვიცოდით“, თითქმის ყოველთვის არის „ვიცოდით, მაგრამ პროდაქშენამდე მიტანას ექსპლუატაციის ფანჯარაზე მეტი დრო დასჭირდა“. ამ დაყოვნებას ისინი რისკის ერთ-ერთ ყველაზე დაუფასებელ მეტრიკას უწოდებენ: AI ექსპლოიტამდე დროს საათებამდე კუმშავს, ბევრი ორგანიზაცია კი ჯერ კიდევ 40-დან 90 დღემდე ხარჯავს ხელახალ აწყობასა და შემოწმებაზე.

Docker-მა 21 ოქტომბერს Secure Software Factory-ზე მოგვიყვა. ეს საეტალონო არქიტექტურაა გუნდებისთვის, სადაც AI-აგენტები კოდს ცვლიან, ტესტებს უშვებენ და შედეგს ადამიანს გადასცემენ. ის Agent Baseline-დან გაიზარდა, რომელიც Docker-მა, Snyk-მა და Keycard-მა ივლისში გამოაქვეყნეს. მათი თქმით, გუნდები სიჩქარეს იღებენ და მასთან ერთად აგენტებს, რომლებიც ბაზებს შლიან და შეთანხმების გარეშე პროდაქშენში push-ს აკეთებენ. მთავარი აზრი: რაც მეტი ავტონომია აქვს აგენტს, მით ნაკლებად შეიძლება მას დაეყრდნო, და კონტროლი იმ გარემოში უნდა ცხოვრობდეს, სადაც ის გაშვებულია. ეს zero trust-ის იგივე აზრია, ოღონდ თანამშრომლის ნაცვლად პროგრამაზე.

Manufacturing Today-მ 22 ოქტომბერს წარმოებებისთვის კიბერუსაფრთხოების რვა პრაქტიკა ჩამოთვალა: მიერთებული ჩარხები და ნივთების სამრეწველო ინტერნეტი მწარმოებლურობას იძლევა და ამავე დროს ახალ მოწყვლადობებს. ანონსში თავად სია არ არის, ქვემოთ ჩემია.

წარმოება, სადაც კონტრაქტორი ყველაფერს ხედავს

ავიღოთ საწარმოო კომპანია. საამქროში ქსელია, მასში ჩარხები, 1C-ის სერვერი, ნახაზების ქსელური საქაღალდეები და კონტრაქტორის ლეპტოპი, რომელიც ლაზერის გასამართად ჩამოვიდა. ის Wi-Fi-ს მიუერთდა, და ახლა მისთვის ხელმისაწვდომია ყველაფერი, რაც შიგნითაა: საქაღალდეები SMB-ით, ბაზა, პრინტერები. ქსელი პრინციპით „შიგნით ყველა თავისიანია“ არის მოწყობილი.

დასკვნა: „ქსელის შიგნით ყოფნა“ წვდომის უფლება აღარ არის. უფლებას კონკრეტულ ადამიანს ან პროგრამას კონკრეტულ სერვისზე იძლევა ის, ვინც ამ სერვისზე აგებს პასუხს.

როგორ მაქვს ეს მოწყობილი

აშშ-ში ჰიდროპონიკურ ფერმაზე, რომელთანაც 2023 წლიდან ვმუშაობ, 25 კონტროლერია 2 ობიექტზე, და ობიექტების ქსელებს პრივატული IP-მისამართები აქვს, საჯარო მისამართის გარეშე. იმისთვის, რომ Google Cloud-ში Debian-ზე მდგომ სერვერს კონტროლერები დაენახა, reverse proxy-ები, NAT, firewall და VPN გავმართე. ერთად ეს ერთი ქსელია, სადაც სერვერს ყველა კონტროლერზე აქვს წვდომა, გარედან კი მათამდე ვერ მიაღწევ. მისამართებსა და ქსელურ პროდუქტებს არ ვამხელ, ეს კლიენტის კერძო ინფრასტრუქტურაა.

აშშ-ის PDR-კომპანიაში, სადაც ახლა 30-ზე მეტი ადამიანია, უსაფრთხოების საკითხები ჩემთან მოდის. სისტემას დაცვისა და სარეზერვო ასლების რამდენიმე კონტური აქვს. სერვერს, VPN-ს, ქსელურ აპარატურასა და ტელეფონიას თავად ვემსახურები, მსოფლიოში მსხვილი გატეხვებისას კი ვამოწმებ, გვეხება თუ არა. 2022 წლიდან, როცა საკუთარი სერვერი გაჩნდა, აღდგენასთან დაკავშირებული სერიოზული ჩავარდნა არ ყოფილა.

საწარმოო კომპანიაში, რომლისთვისაც Excel-სპეციფიკაციებით დეტალების გაანგარიშება გავაკეთე, პროგრამის ვებ-ვერსია მხოლოდ კომპანიის ქსელის შიგნითაა ღია და ACL-ით არის შეზღუდული, ქსელურ საქაღალდეებს SMB-ით კი პროგრამა VPN-ით მიმართავს. გაანგარიშების ლოგიკა სერვერზე ცხოვრობს, და მასზე წვდომის გარეშე კლიენტის ნაწილი არაფერს ითვლის: დამკვეთს უნდოდა, რომ პროგრამის წაღება შეუძლებელი ყოფილიყო.

ეს არის zero trust ჩემს ზომაზე: პლატფორმისა და განყოფილების გარეშე, VPN-ზე, reverse proxy-ებსა და უფლებებზე, რომლებიც კონკრეტული სერვისისთვის გაიცემა.

რას გავაკეთებდი 30-კაციან კომპანიაში

შევადგენდი სიას ყველაფრისა, რაც ინტერნეტში ღიაა: საიტი, API, ტელეფონია, დისტანციური წვდომა, კამერები, პრინტერები. ყველაფერს, რაც კლიენტებისთვის არ არის, VPN-ის ან reverse proxy-ის უკან გადავიტანდი.

ყოველი სერვისისთვის ჩავწერდი, ვინ მიმართავს მას და რატომ, და წვდომას სწორედ ამ ადამიანებსა და პროგრამებს მივცემდი. კონტრაქტორი ერთ სერვისზე წვდომას სამუშაოს ვადით იღებს.

გავზომავდი ერთ რიცხვს, როგორც Red Hat გვთავაზობს: რამდენი დღე გადის პატჩის გამოსვლიდან პროდაქშენში მის მუშაობამდე. თუ ეს კვირებია, გავარკვევდი, სად იჭედება: შეთანხმებაზე, აწყობაზე თუ იმაზე, რომ გამკეთებელი არავინაა.

სარეზერვო ასლიდან აღდგენის რეპეტიციას ჩავატარებდი.

AI-ასისტენტებს, თუ ისინი დეველოპმენტში გყავთ, იმავე უფლებებს მივცემდი, რასაც კონტრაქტორს: შეზღუდულ გარემოს და არანაირ წვდომას პროდაქშენზე.

სერვერზე, როგორც საერთო ცენტრზე, რომელიც მდგომარეობას ინახავს და უფლებებს ამოწმებს: სტატია სერვერი: მონაცემები, წვდომა და პროცესის შესრულება. ინფრასტრუქტურა, რომლის გამოშვება და აღდგენა შეიძლება: DevOps და ინფრასტრუქტურა. ამ ტექსტის ქსელები აღწერილია ქეისებში ჰიდროპონიკური ფერმის სერვერი და ქსელი და ტექნიკური პარტნიორობა PDR-კომპანიასთან. იმავე თემაზე: PHP2Shell და საკუთარი სერვერების შემოწმება, ბიზნეს-ლოგიკის მოწყვლადობა და რატომ ჰყოფნის მცირე ბიზნესს Docker Compose; ადრე ვწერდი დახურულ კონტურსა და ინტერნეტის გარეშე მუშაობაზე. თუ თქვენთან წვდომების სია ჩაწერილი არ არის, მომიყევით, როგორ არის ყველაფერი ახლა მოწყობილი, და შემოგთავაზებთ, საიდან დავიწყოთ. ამოცანის განხილვა.