როგორ დავმეგობრდეთ GOST R 57580-თან და კონტეინერის ვირტუალიზაციასთან. ცენტრალური ბანკის პასუხი (და ჩვენი აზრები ამ საკითხთან დაკავშირებით)

ცოტა ხნის წინ ჩვენ ჩავატარეთ GOST R 57580 მოთხოვნებთან შესაბამისობის კიდევ ერთი შეფასება (შემდგომში უბრალოდ GOST). კლიენტი არის კომპანია, რომელიც ავითარებს ელექტრონულ გადახდის სისტემას. სისტემა სერიოზულია: 3 მილიონზე მეტი მომხმარებელი, ყოველდღიურად 200 ათასზე მეტი ტრანზაქცია. იქ ძალიან სერიოზულად ეკიდებიან ინფორმაციის უსაფრთხოებას.

შეფასების პროცესში კლიენტმა შემთხვევით გამოაცხადა, რომ განვითარების განყოფილება, გარდა ვირტუალური მანქანებისა, გეგმავს კონტეინერების გამოყენებას. მაგრამ ამასთან, დასძინა კლიენტმა, არის ერთი პრობლემა: GOST-ში არ არის სიტყვა იგივე დოკერის შესახებ. Რა უნდა გავაკეთო? როგორ შევაფასოთ კონტეინერების უსაფრთხოება?

მართალია, GOST წერს მხოლოდ ტექნიკის ვირტუალიზაციაზე - იმაზე, თუ როგორ დავიცვათ ვირტუალური მანქანები, ჰიპერვიზორი და სერვერი. განმარტება ცენტრალურ ბანკს ვთხოვეთ. პასუხმა გვაოცა.

GOST და ვირტუალიზაცია

დასაწყისისთვის, შეგახსენებთ, რომ GOST R 57580 არის ახალი სტანდარტი, რომელიც განსაზღვრავს „მოთხოვნებს ფინანსური ორგანიზაციების ინფორმაციული უსაფრთხოების უზრუნველსაყოფად“ (FI). ამ FI-ებში შედის გადახდის სისტემების ოპერატორები და მონაწილეები, საკრედიტო და არასაკრედიტო ორგანიზაციები, ოპერატიული და საკლირინგო ცენტრები.

1 წლის 2021 იანვრიდან FI-ები ვალდებულნი არიან ჩაატარონ ახალი GOST-ის მოთხოვნებთან შესაბამისობის შეფასება. ჩვენ, ITGLOBAL.COM, ვართ აუდიტორული კომპანია, რომელიც ატარებს ასეთ შეფასებებს.

GOST-ს აქვს ქვეგანყოფილება, რომელიც ეძღვნება ვირტუალიზებული გარემოს დაცვას - No 7.8. ტერმინი "ვირტუალიზაცია" არ არის მითითებული, არ არის დაყოფა აპარატურულ და კონტეინერულ ვირტუალიზაციად. ნებისმიერი IT სპეციალისტი იტყვის, რომ ტექნიკური თვალსაზრისით ეს არასწორია: ვირტუალური მანქანა (VM) და კონტეინერი სხვადასხვა გარემოა, განსხვავებული იზოლაციის პრინციპებით. ჰოსტის დაუცველობის თვალსაზრისით, რომელზედაც განლაგებულია VM და Docker კონტეინერები, ეს ასევე დიდი განსხვავებაა.

გამოდის, რომ VM-ების და კონტეინერების ინფორმაციული უსაფრთხოების შეფასებაც განსხვავებული უნდა იყოს.

ჩვენი კითხვები ცენტრალურ ბანკს

ისინი გავაგზავნეთ ცენტრალური ბანკის საინფორმაციო უსაფრთხოების დეპარტამენტში (შეკითხვებს წარმოგიდგენთ შემოკლებული ფორმით).

1. როგორ გავითვალისწინოთ Docker-ის ტიპის ვირტუალური კონტეინერები GOST შესაბამისობის შეფასებისას? სწორია თუ არა ტექნოლოგიის შეფასება GOST-ის 7.8 ქვეპუნქტის შესაბამისად?
2. როგორ შევაფასოთ ვირტუალური კონტეინერის მართვის ინსტრუმენტები? შესაძლებელია თუ არა მათი გაიგივება სერვერის ვირტუალიზაციის კომპონენტებთან და მათი შეფასება GOST-ის იმავე ქვეპუნქტის მიხედვით?
3. მჭირდება თუ არა ცალ-ცალკე შევაფასო Docker კონტეინერებში ინფორმაციის უსაფრთხოება? თუ ასეა, რა გარანტიები უნდა იქნას გათვალისწინებული შეფასების პროცესში?
4. თუ კონტეინერიზაცია გაიგივებულია ვირტუალურ ინფრასტრუქტურასთან და შეფასებულია 7.8 ქვეპუნქტის მიხედვით, როგორ სრულდება GOST მოთხოვნები ინფორმაციული უსაფრთხოების სპეციალური ინსტრუმენტების დანერგვისთვის?

ცენტრალური ბანკის პასუხი

ქვემოთ მოცემულია ძირითადი ამონარიდები.

”GOST R 57580.1-2017 ადგენს განხორციელების მოთხოვნებს ტექნიკური ზომების გამოყენების გზით GOST R 7.8-57580.1-ის ZI ქვეპუნქტის 2017 ქვეპუნქტთან დაკავშირებით, რომელიც, დეპარტამენტის აზრით, შეიძლება გავრცელდეს კონტეინერის ვირტუალიზაციის გამოყენების შემთხვევებზე. ტექნოლოგიების გათვალისწინებით, შემდეგი:

• ზომების განხორციელება ZSV.1 - ZSV.11 იდენტიფიკაციის, ავტორიზაციის, ავტორიზაციის (წვდომის კონტროლის) ორგანიზებისთვის ვირტუალურ მანქანებზე და ვირტუალიზაციის სერვერის კომპონენტებზე ლოგიკური წვდომის განხორციელებისას შეიძლება განსხვავდებოდეს კონტეინერის ვირტუალიზაციის ტექნოლოგიის გამოყენების შემთხვევებისგან. ამის გათვალისწინებით, მთელი რიგი ღონისძიებების განსახორციელებლად (მაგალითად, ZVS.6 და ZVS.7), მიგვაჩნია, რომ შესაძლებელია რეკომენდაცია გავუწიოთ ფინანსურ ინსტიტუტებს, შეიმუშაონ კომპენსატორული ღონისძიებები, რომლებიც იგივე მიზნებს მისდევს;
• ღონისძიებების განხორციელება ZSV.13 - ZSV.22 ვირტუალური მანქანების ინფორმაციული ურთიერთქმედების ორგანიზებისა და კონტროლისთვის ითვალისწინებს ფინანსური ორგანიზაციის კომპიუტერული ქსელის სეგმენტაციას, რათა განასხვავოს ინფორმატიზაციის ობიექტები, რომლებიც ახორციელებენ ვირტუალიზაციის ტექნოლოგიას და მიეკუთვნებიან უსაფრთხოების სხვადასხვა სქემებს. ამის გათვალისწინებით, მიგვაჩნია, რომ მიზანშეწონილია უზრუნველყოს შესაბამისი სეგმენტაცია კონტეინერის ვირტუალიზაციის ტექნოლოგიის გამოყენებისას (როგორც შესრულებად ვირტუალურ კონტეინერებთან, ასევე ვირტუალიზაციის სისტემებთან მიმართებაში, რომლებიც გამოიყენება ოპერაციული სისტემის დონეზე);
• ზომების განხორციელება ZSV.26, ZSV.29 - ZSV.31 ვირტუალური მანქანების გამოსახულების დაცვის ორგანიზების მიზნით, უნდა განხორციელდეს ანალოგიით, ასევე ვირტუალური კონტეინერების ძირითადი და მიმდინარე სურათების დაცვის მიზნით;
• ზომების განხორციელება ZVS.32 - ZVS.43 ვირტუალურ მანქანებთან და სერვერის ვირტუალიზაციის კომპონენტებთან წვდომასთან დაკავშირებული ინფორმაციული უსაფრთხოების მოვლენების ჩასაწერად უნდა განხორციელდეს ანალოგიით, ასევე ვირტუალიზაციის გარემოს ელემენტებთან მიმართებაში, რომლებიც ახორციელებენ კონტეინერის ვირტუალიზაციის ტექნოლოგიას.

რას ნიშნავს ეს

ორი ძირითადი დასკვნა ცენტრალური ბანკის საინფორმაციო უსაფრთხოების დეპარტამენტის პასუხიდან:

• კონტეინერების დაცვის ზომები არაფრით განსხვავდება ვირტუალური მანქანების დაცვის ზომებისგან;
• აქედან გამომდინარეობს, რომ ინფორმაციული უსაფრთხოების კონტექსტში, ცენტრალური ბანკი აიგივებს ვირტუალიზაციის ორ ტიპს - Docker კონტეინერებსა და VM-ებს.

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

რა შუაშია ცენტრალური ბანკის პოზიცია?

თუ თქვენ იყენებთ ცენტრალური ბანკის რეკომენდაციებს შეფასების (და თვითშეფასების) დროს, თქვენ უნდა გადაჭრათ მთელი რიგი ტექნიკური და ლოგიკური სირთულეები.

• თითოეული შესრულებადი კონტეინერი მოითხოვს მასზე ინფორმაციის დაცვის პროგრამული უზრუნველყოფის (IP) დაყენებას: ანტივირუსი, მთლიანობის მონიტორინგი, ჟურნალებთან მუშაობა, DLP სისტემები (Data Leak Prevention) და ა.შ. ამ ყველაფრის დაყენება VM-ზე უპრობლემოდ შეიძლება, მაგრამ კონტეინერის შემთხვევაში ინფორმაციული უსაფრთხოების დაყენება აბსურდული ნაბიჯია. კონტეინერი შეიცავს "სხეულის ნაკრების" მინიმალურ რაოდენობას, რომელიც საჭიროა სერვისის ფუნქციონირებისთვის. მასში SZI-ის დაყენება ეწინააღმდეგება მის მნიშვნელობას.
• კონტეინერის გამოსახულება დაცული უნდა იყოს იმავე პრინციპით; როგორ განხორციელდეს ეს ასევე გაურკვეველია.
• GOST მოითხოვს სერვერის ვირტუალიზაციის კომპონენტებზე წვდომის შეზღუდვას, ანუ ჰიპერვიზორზე. რა ითვლება სერვერის კომპონენტად Docker-ის შემთხვევაში? ეს არ ნიშნავს იმას, რომ თითოეული კონტეინერი ცალკე ჰოსტზე უნდა იყოს გაშვებული?
• თუ ჩვეულებრივი ვირტუალიზაციისთვის შესაძლებელია VM-ების შემოსაზღვრა უსაფრთხოების კონტურებით და ქსელის სეგმენტებით, მაშინ Docker კონტეინერების შემთხვევაში იგივე ჰოსტში, ეს ასე არ არის.

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

ყოველ შემთხვევაში, დავამატებთ, რომ 1 წლის 2021 იანვრიდან მინიმალური ქულა არ უნდა იყოს 0,7-ზე დაბალი.

სხვათა შორის, ჩვენ რეგულარულად ვაქვეყნებთ პასუხებსა და კომენტარებს მარეგულირებლებისგან, რომლებიც დაკავშირებულია GOST 57580-ის მოთხოვნებთან და ცენტრალური ბანკის რეგულაციებთან. ტელეარხი.

რა უნდა გავაკეთოთ

ჩვენი აზრით, ფინანსურ ორგანიზაციებს პრობლემის გადაჭრის მხოლოდ ორი გზა აქვთ.

1. მოერიდეთ კონტეინერების დანერგვას

გამოსავალი მათთვის, ვინც მზად არის გამოიყენოს მხოლოდ ტექნიკის ვირტუალიზაცია და ამავე დროს ეშინია დაბალი რეიტინგების GOST-ის მიხედვით და ცენტრალური ბანკის ჯარიმების.

პლუს: უფრო ადვილია GOST-ის 7.8 ქვეპუნქტის მოთხოვნების დაცვა.

მინუსი: ჩვენ მოგვიწევს უარი თქვან განვითარების ახალ ინსტრუმენტებზე, რომლებიც დაფუძნებულია კონტეინერის ვირტუალიზაციაზე, კერძოდ, Docker-სა და Kubernetes-ზე.

2. უარი თქვას GOST-ის 7.8 ქვეპუნქტის მოთხოვნების შესრულებაზე

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

• მასპინძელი OS-ის უსაფრთხოება, სათანადოდ კონფიგურირებული ჟურნალი, კონტეინერებს შორის მონაცემთა გაცვლის აკრძალვა და ა.შ.
• Docker Trust ფუნქციის გამოყენებით სურათების მთლიანობის შესამოწმებლად და ჩაშენებული დაუცველობის სკანერის გამოყენებით;
• ჩვენ არ უნდა დავივიწყოთ დისტანციური წვდომის უსაფრთხოება და მთლიანობაში ქსელის მოდელი: შეტევები, როგორიცაა ARP-სპოოფინგი და MAC-flooding, არ გაუქმებულა.

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

მინუსი: დიდია ალბათობა იმისა, რომ მარეგულირებელი დაისჯება GOST-ის მოთხოვნების შეუსრულებლობისთვის.

დასკვნა

ჩვენმა კლიენტმა გადაწყვიტა არ დაეტოვებინა კონტეინერები. ამავდროულად, მას საგრძნობლად უნდა გადაეხედა სამუშაოს მოცულობა და დოკერზე გადასვლის დრო (ისინი გაგრძელდა ექვსი თვის განმავლობაში). კლიენტს ძალიან კარგად ესმის რისკები. მას ასევე ესმის, რომ GOST R 57580-თან შესაბამისობის შემდეგი შეფასებისას, ბევრი რამ იქნება დამოკიდებული აუდიტორზე.

რას გააკეთებდით ამ სიტუაციაში?

წყარო: www.habr.com