🥇 ღრუბლოვანი უსაფრთხოების მონიტორინგი

მონაცემთა და აპლიკაციების ღრუბელში გადატანა ახალ გამოწვევას წარმოადგენს კორპორატიული SOC-ებისთვის, რომლებიც ყოველთვის არ არიან მზად სხვა ადამიანების ინფრასტრუქტურის მონიტორინგისთვის. Netoskope-ის მიხედვით, საშუალო საწარმო (როგორც ჩანს, აშშ-ში) იყენებს 1246 სხვადასხვა ღრუბლოვან სერვისს, რაც 22%-ით მეტია, ვიდრე ერთი წლის წინ. 1246 ღრუბლოვანი სერვისი!!! აქედან 175 HR სერვისებს ეხება, 170 მარკეტინგის, 110 კომუნიკაციების და 76 ფინანსებსა და CRM-ს. Cisco იყენებს "მხოლოდ" 700 გარე ღრუბლოვან სერვისს. ასე რომ, მე ცოტა დაბნეული ვარ ამ ციფრებით. ნებისმიერ შემთხვევაში, პრობლემა მათში არ არის, არამედ იმაში, რომ ღრუბელი იწყებს საკმაოდ აქტიურად გამოყენებას მზარდი კომპანიების მიერ, რომლებსაც სურთ ჰქონდეთ იგივე შესაძლებლობები ღრუბლოვანი ინფრასტრუქტურის მონიტორინგისთვის, როგორც საკუთარ ქსელში. და ეს ტენდენცია მზარდია - შესაბამისად ამერიკის ანგარიშთა პალატის ცნობით 2023 წლისთვის შეერთებულ შტატებში 1200 მონაცემთა ცენტრი დაიხურება (6250 უკვე დაიხურა). მაგრამ ღრუბელზე გადასვლა არ არის მხოლოდ „მოდით გადავიტანოთ ჩვენი სერვერები გარე პროვაიდერზე“. ახალი IT არქიტექტურა, ახალი პროგრამული უზრუნველყოფა, ახალი პროცესები, ახალი შეზღუდვები... ამ ყველაფერს მნიშვნელოვანი ცვლილებები მოაქვს არამარტო IT, არამედ ინფორმაციული უსაფრთხოების მუშაობაში. და თუ პროვაიდერებმა ისწავლეს როგორმე გაუმკლავდნენ თავად ღრუბლის უსაფრთხოების უზრუნველყოფას (საბედნიეროდ, უამრავი რეკომენდაცია არსებობს), მაშინ ღრუბლოვანი ინფორმაციის უსაფრთხოების მონიტორინგით, განსაკუთრებით SaaS პლატფორმებზე, არის მნიშვნელოვანი სირთულეები, რაზეც ვისაუბრებთ.

ვთქვათ, თქვენმა კომპანიამ თავისი ინფრასტრუქტურის ნაწილი ღრუბელში გადაიტანა... გაჩერდით. არა ამ გზით. თუ ინფრასტრუქტურა გადატანილია და მხოლოდ ახლა ფიქრობთ, როგორ დააკვირდებით, მაშინ უკვე წააგე. თუ ეს არ არის Amazon, Google ან Microsoft (და შემდეგ დაჯავშნით), თქვენ ალბათ არ გექნებათ თქვენი მონაცემებისა და აპლიკაციების მონიტორინგის დიდი შესაძლებლობა. კარგია, თუ მოგეცემათ შესაძლებლობა იმუშაოთ ჟურნალებთან. ზოგჯერ უსაფრთხოების ღონისძიებების მონაცემები ხელმისაწვდომი იქნება, მაგრამ თქვენ არ გექნებათ წვდომა მასზე. მაგალითად, Office 365. თუ თქვენ გაქვთ ყველაზე იაფი E1 ლიცენზია, მაშინ უსაფრთხოების ღონისძიებები საერთოდ არ არის თქვენთვის ხელმისაწვდომი. თუ თქვენ გაქვთ E3 ლიცენზია, თქვენი მონაცემები ინახება მხოლოდ 90 დღის განმავლობაში და მხოლოდ იმ შემთხვევაში, თუ თქვენ გაქვთ E5 ლიცენზია, ჟურნალების ხანგრძლივობა ხელმისაწვდომია ერთი წლის განმავლობაში (თუმცა, ამას ასევე აქვს საკუთარი ნიუანსი, რომელიც დაკავშირებულია ცალკე საჭიროებასთან. მოითხოვეთ მრავალი ფუნქცია ჟურნალებთან მუშაობისთვის Microsoft-ის მხარდაჭერისგან). სხვათა შორის, E3 ლიცენზია ბევრად სუსტია მონიტორინგის ფუნქციების თვალსაზრისით, ვიდრე კორპორატიული Exchange. იმავე დონის მისაღწევად, გჭირდებათ E5 ლიცენზია ან დამატებითი Advanced Compliance ლიცენზია, რაც შეიძლება მოითხოვოს დამატებით თანხას, რომელიც არ იყო გათვალისწინებული თქვენს ფინანსურ მოდელში ღრუბლოვან ინფრასტრუქტურაში გადასასვლელად. და ეს არის მხოლოდ ერთი მაგალითი იმისა, რომ არ შეფასდეს ღრუბლოვანი ინფორმაციის უსაფრთხოების მონიტორინგთან დაკავშირებული საკითხები. ამ სტატიაში, სრულყოფილად მოჩვენების გარეშე, მინდა გავამახვილო ყურადღება რამდენიმე ნიუანსზე, რომელიც უნდა იქნას გათვალისწინებული უსაფრთხოების თვალსაზრისით ღრუბლოვანი პროვაიდერის არჩევისას. და სტატიის ბოლოს მოცემულია საკონტროლო სია, რომლის შევსებაც ღირს, სანამ განიხილება, რომ ღრუბლოვანი ინფორმაციის უსაფრთხოების მონიტორინგის საკითხი მოგვარებულია.

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

უსაფრთხოების ჟურნალები არ არსებობს. ეს საკმაოდ გავრცელებული სიტუაციაა, განსაკუთრებით ღრუბლოვანი გადაწყვეტილებების ბაზარზე ახალბედა მოთამაშეებს შორის. მაგრამ თქვენ არ უნდა თქვათ მათზე დაუყოვნებლივ. მცირე მოთამაშეები, განსაკუთრებით საშინაო მოთამაშეები, უფრო მგრძნობიარენი არიან მომხმარებელთა მოთხოვნების მიმართ და შეუძლიათ სწრაფად განახორციელონ ზოგიერთი საჭირო ფუნქცია მათი პროდუქტებისთვის დამტკიცებული საგზაო რუქის შეცვლით. დიახ, ეს არ იქნება GuardDuty-ის ანალოგი ამაზონიდან ან Bitrix-ის "პროაქტიული დაცვის" მოდული, მაგრამ მაინც რაღაც.
ინფორმაციის უსაფრთხოებამ არ იცის სად ინახება ჟურნალები ან არ არის მათზე წვდომა. აქ აუცილებელია მოლაპარაკება ღრუბლოვანი სერვისის პროვაიდერთან - შესაძლოა, ის მიაწვდის ასეთ ინფორმაციას, თუ კლიენტს მისთვის მნიშვნელოვანად მიიჩნევს. მაგრამ ზოგადად, არც თუ ისე კარგია, როდესაც ჟურნალებზე წვდომა უზრუნველყოფილია "სპეციალური გადაწყვეტილებით".
ასევე ხდება, რომ ღრუბლოვან პროვაიდერს აქვს ჟურნალები, მაგრამ ისინი უზრუნველყოფენ შეზღუდულ მონიტორინგს და მოვლენის ჩაწერას, რაც საკმარისი არ არის ყველა ინციდენტის გამოსავლენად. მაგალითად, თქვენ შეგიძლიათ მიიღოთ მხოლოდ ვებსაიტზე ცვლილებების ჟურნალი ან მომხმარებლის ავტორიზაციის მცდელობების ჟურნალები, მაგრამ არა სხვა მოვლენები, როგორიცაა ქსელის ტრაფიკი, რომელიც დაგიმალავთ მოვლენების მთელ ფენას, რომლებიც ახასიათებს თქვენი ღრუბლოვანი ინფრასტრუქტურის გატეხვის მცდელობებს.
არის ჟურნალები, მაგრამ მათზე წვდომა ძნელია ავტომატიზირება, რაც აიძულებს მათ მონიტორინგს არა მუდმივად, არამედ გრაფიკით. და თუ თქვენ არ შეგიძლიათ ავტომატურად ჩამოტვირთოთ ჟურნალები, მაშინ ჟურნალების ჩამოტვირთვამ, მაგალითად, Excel ფორმატში (როგორც შიდა ღრუბლოვანი გადაწყვეტილებების პროვაიდერების შემთხვევაში), შეიძლება გამოიწვიოს კორპორატიული ინფორმაციის უსაფრთხოების სამსახურის მხრიდან მათთან დაკავშირება.
არ არის ჟურნალის მონიტორინგი. ეს არის ალბათ ყველაზე გაურკვეველი მიზეზი ღრუბლოვან გარემოში ინფორმაციული უსაფრთხოების ინციდენტების შემთხვევისთვის. როგორც ჩანს, არის ჟურნალები და შესაძლებელია მათზე წვდომის ავტომატიზაცია, მაგრამ ამას არავინ აკეთებს. რატომ?

ღრუბლოვანი უსაფრთხოების საერთო კონცეფცია

ღრუბელზე გადასვლა ყოველთვის არის ბალანსის ძიება ინფრასტრუქტურაზე კონტროლის შენარჩუნების სურვილსა და მის შენარჩუნებაში სპეციალიზებული ღრუბლოვანი პროვაიდერის უფრო პროფესიონალურ ხელში გადაცემას შორის. ღრუბლოვანი უსაფრთხოების სფეროში ეს ბალანსი ასევე უნდა ვეძებოთ. უფრო მეტიც, გამოყენებული ღრუბლოვანი სერვისის მიწოდების მოდელის მიხედვით (IaaS, PaaS, SaaS), ეს ბალანსი ყოველთვის განსხვავებული იქნება. ნებისმიერ შემთხვევაში, უნდა გვახსოვდეს, რომ დღეს ყველა ღრუბლოვანი პროვაიდერი მიჰყვება ეგრეთ წოდებულ საზიარო პასუხისმგებლობას და საინფორმაციო უსაფრთხოების საერთო მოდელს. ღრუბელი პასუხისმგებელია ზოგიერთ საკითხზე, ზოგზე კი კლიენტი პასუხისმგებელია, ათავსებს თავის მონაცემებს, აპლიკაციებს, ვირტუალურ მანქანებს და სხვა რესურსებს ღრუბელში. უგუნური იქნება იმის მოლოდინი, რომ ღრუბელზე გადასვლით, ჩვენ მთელ პასუხისმგებლობას გადავიტანთ პროვაიდერზე. მაგრამ ასევე არაგონივრულია, რომ თავად ააშენო მთელი უსაფრთხოება ღრუბელზე გადასვლისას. საჭიროა ბალანსი, რომელიც მრავალ ფაქტორზე იქნება დამოკიდებული: - რისკის მართვის სტრატეგიაზე, საფრთხის მოდელზე, ღრუბლის პროვაიდერისთვის ხელმისაწვდომ უსაფრთხოების მექანიზმებზე, კანონმდებლობაზე და ა.შ.

მაგალითად, ღრუბელში განთავსებული მონაცემების კლასიფიკაცია ყოველთვის მომხმარებლის პასუხისმგებლობაა. ღრუბლოვან პროვაიდერს ან გარე სერვისის პროვაიდერს შეუძლია დაეხმაროს მას მხოლოდ ინსტრუმენტებით, რომლებიც დაეხმარება ღრუბელში მონაცემების მონიშვნას, დარღვევების იდენტიფიცირებას, კანონის დამრღვევი მონაცემების წაშლას ან ამა თუ იმ მეთოდის გამოყენებით. მეორეს მხრივ, ფიზიკური უსაფრთხოება ყოველთვის არის ღრუბლოვანი პროვაიდერის პასუხისმგებლობა, რომელსაც მას არ შეუძლია გაუზიაროს კლიენტებს. მაგრამ ყველაფერი, რაც მონაცემებსა და ფიზიკურ ინფრასტრუქტურას შორის არის, სწორედ ამ სტატიის განხილვის საგანია. მაგალითად, ღრუბლის ხელმისაწვდომობა არის პროვაიდერის პასუხისმგებლობა, ხოლო firewall-ის წესების დაყენება ან დაშიფვრის ჩართვა კლიენტის პასუხისმგებლობაა. ამ სტატიაში ჩვენ შევეცდებით გადავხედოთ, თუ რა ინფორმაციული უსაფრთხოების მონიტორინგის მექანიზმებს უზრუნველყოფენ დღეს რუსეთში სხვადასხვა პოპულარული ღრუბლოვანი პროვაიდერი, რა არის მათი გამოყენების მახასიათებლები და როდის ღირს გარე გადაფარვის გადაწყვეტილებების ძიება (მაგალითად, Cisco E- mail Security), რომელიც აფართოებს თქვენი ღრუბლის შესაძლებლობებს კიბერუსაფრთხოების თვალსაზრისით. ზოგიერთ შემთხვევაში, განსაკუთრებით თუ მიჰყვებით მრავალ ღრუბლოვან სტრატეგიას, თქვენ არ გექნებათ არჩევანი, გარდა იმისა, რომ გამოიყენოთ გარე ინფორმაციის უსაფრთხოების მონიტორინგის გადაწყვეტილებები ერთდროულად რამდენიმე ღრუბლოვან გარემოში (მაგალითად, Cisco CloudLock ან Cisco Stealthwatch Cloud). კარგად, ზოგიერთ შემთხვევაში მიხვდებით, რომ ღრუბლოვანი პროვაიდერი თქვენ მიერ არჩეული (ან დაწესებული) საერთოდ არ გთავაზობთ ინფორმაციის უსაფრთხოების მონიტორინგის შესაძლებლობებს. ეს უსიამოვნოა, მაგრამ არც თუ ისე ცოტა, რადგან ის საშუალებას გაძლევთ ადეკვატურად შეაფასოთ ამ ღრუბელთან მუშაობასთან დაკავშირებული რისკის დონე.

ღრუბლოვანი უსაფრთხოების მონიტორინგის სასიცოცხლო ციკლი

თქვენ მიერ გამოყენებული ღრუბლების უსაფრთხოების მონიტორინგისთვის, თქვენ გაქვთ მხოლოდ სამი ვარიანტი:

დაეყრდნოთ თქვენი ღრუბლოვანი პროვაიდერის მიერ მოწოდებულ ინსტრუმენტებს,
გამოიყენეთ მესამე მხარის გადაწყვეტილებები, რომლებიც მონიტორინგს გაუწევენ თქვენს მიერ გამოყენებულ IaaS, PaaS ან SaaS პლატფორმებს,
შექმენით თქვენი საკუთარი ღრუბლოვანი მონიტორინგის ინფრასტრუქტურა (მხოლოდ IaaS/PaaS პლატფორმებისთვის).

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

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

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

ჩამონტაჟებული ღრუბლოვანი სერვისები

მე უკვე დავწერე ზემოთ, რომ დღეს ბევრი ღრუბლოვანი სერვისი არ იძლევა ინფორმაციის უსაფრთხოების მონიტორინგის შესაძლებლობებს. ზოგადად, ინფორმაციული უსაფრთხოების თემას დიდ ყურადღებას არ აქცევენ. მაგალითად, ერთ-ერთი პოპულარული რუსული სერვისი სამთავრობო უწყებებისთვის ინტერნეტით გაგზავნისთვის (კონკრეტულად არ ვახსენებ მის სახელს). მთელი განყოფილება ამ სერვისის უსაფრთხოების შესახებ ტრიალებს სერტიფიცირებული CIPF-ის გამოყენებას. ელექტრონული დოკუმენტების მართვის სხვა შიდა ღრუბლოვანი სერვისის ინფორმაციის უსაფრთხოების განყოფილება არ განსხვავდება. საუბარია საჯარო გასაღების სერთიფიკატებზე, სერტიფიცირებულ კრიპტოგრაფიაზე, ვებ სისუსტეების აღმოფხვრაზე, DDoS თავდასხმებისგან დაცვაზე, ფაირვოლების, სარეზერვო ასლების და ინფორმაციული უსაფრთხოების რეგულარულ აუდიტზეც კი. მაგრამ არ არის სიტყვა მონიტორინგზე და არც ინფორმაციის უსაფრთხოების მოვლენებზე წვდომის შესაძლებლობის შესახებ, რომლებიც შეიძლება იყოს დაინტერესებული ამ სერვისის მომწოდებლის კლიენტებისთვის.

ზოგადად, სხვათა შორის, ღრუბლოვანი პროვაიდერი აღწერს ინფორმაციული უსაფრთხოების საკითხებს თავის ვებსაიტზე და მის დოკუმენტაციაში, შეგიძლიათ გაიგოთ, რამდენად სერიოზულად ეკიდება ამ საკითხს. მაგალითად, თუ წაიკითხავთ ინსტრუქციებს „ჩემი ოფისის“ პროდუქტებისთვის, უსაფრთხოების შესახებ საერთოდ არ არის სიტყვა, არამედ ცალკეული პროდუქტის „ჩემი ოფისის“ დოკუმენტაციაში. KS3“, შექმნილია არასანქცირებული წვდომისგან დასაცავად, არსებობს FSTEC-ის მე-17 რიგის პუნქტების ჩვეულებრივი ჩამონათვალი, რომელსაც „My Office.KS3“ ახორციელებს, მაგრამ არ არის აღწერილი, თუ როგორ ახორციელებს მას და, რაც მთავარია, როგორ. ამ მექანიზმების ინტეგრირება კორპორატიული ინფორმაციის უსაფრთხოებასთან. შესაძლოა, ასეთი დოკუმენტაცია არსებობს, მაგრამ მე ვერ ვიპოვე საჯარო დომენში, "ჩემი ოფისის" ვებსაიტზე. თუმცა იქნებ უბრალოდ არ მაქვს წვდომა ამ საიდუმლო ინფორმაციაზე?..

ბიტრიქსისთვის სიტუაცია ბევრად უკეთესია. დოკუმენტაცია აღწერს მოვლენების ჟურნალის ფორმატებს და, საინტერესოა, შეჭრის ჟურნალს, რომელიც შეიცავს ღრუბლოვანი პლატფორმის პოტენციურ საფრთხეებთან დაკავშირებულ მოვლენებს. იქიდან შეგიძლიათ ამოიღოთ IP, მომხმარებლის ან სტუმრის სახელი, ღონისძიების წყარო, დრო, მომხმარებლის აგენტი, ღონისძიების ტიპი და ა.შ. მართალია, თქვენ შეგიძლიათ იმუშაოთ ამ მოვლენებთან ან თავად ღრუბლის მართვის პანელიდან, ან ატვირთოთ მონაცემები MS Excel ფორმატში. ახლა რთულია Bitrix-ის ჟურნალებთან მუშაობის ავტომატიზაცია და მოგიწევთ ზოგიერთი სამუშაოს ხელით შესრულება (მოხსენების ატვირთვა და SIEM-ში ჩატვირთვა). მაგრამ თუ გავიხსენებთ, რომ შედარებით ცოტა ხნის წინ ასეთი შესაძლებლობა არ არსებობდა, მაშინ ეს დიდი პროგრესია. ამავდროულად, მინდა აღვნიშნო, რომ ბევრი უცხოური ღრუბლოვანი პროვაიდერი გვთავაზობს მსგავს ფუნქციონირებას „დამწყებთათვის“ - ან შეხედეთ ჟურნალებს თქვენი თვალით მართვის პანელის მეშვეობით, ან ატვირთეთ მონაცემები საკუთარ თავს (თუმცა, უმეტესობა ატვირთავს მონაცემებს . csv ფორმატი და არა Excel).

No-logs ვარიანტის განხილვის გარეშე, ღრუბლოვანი პროვაიდერები ჩვეულებრივ გთავაზობენ უსაფრთხოების მოვლენების მონიტორინგის სამ ვარიანტს - დაფები, მონაცემთა ატვირთვა და API წვდომა. პირველი, როგორც ჩანს, ბევრ პრობლემას მოგიგვარებთ, მაგრამ ეს მთლად ასე არ არის - თუ რამდენიმე ჟურნალი გაქვთ, თქვენ უნდა გადართოთ მათ გამოსახულ ეკრანებს შორის, დაკარგოთ საერთო სურათი. გარდა ამისა, ღრუბლოვანი პროვაიდერი ნაკლებად სავარაუდოა, რომ მოგაწოდოთ უსაფრთხოების მოვლენების კორელაცია და ზოგადად მათი გაანალიზება უსაფრთხოების თვალსაზრისით (ჩვეულებრივ, თქვენ გაქვთ საქმე ნედლეულ მონაცემებთან, რომლებიც თავად უნდა გესმოდეთ). არის გამონაკლისები და მათზე შემდგომში ვისაუბრებთ. და ბოლოს, ღირს კითხვა, თუ რა მოვლენებს აფიქსირებს თქვენი ღრუბლოვანი პროვაიდერი, რა ფორმატში და როგორ შეესაბამება ისინი თქვენს ინფორმაციული უსაფრთხოების მონიტორინგის პროცესს? მაგალითად, მომხმარებლებისა და სტუმრების იდენტიფიკაცია და ავთენტიფიკაცია. იგივე Bitrix საშუალებას გაძლევთ, ამ მოვლენებზე დაყრდნობით, ჩაწეროთ ღონისძიების თარიღი და დრო, მომხმარებლის ან სტუმრის სახელი (თუ გაქვთ „ვებ ანალიტიკა“ მოდული), წვდომის ობიექტი და ვებსაიტისთვის დამახასიათებელი სხვა ელემენტები. . მაგრამ კორპორატიული ინფორმაციის უსაფრთხოების სამსახურებს შეიძლება დასჭირდეთ ინფორმაცია იმის შესახებ, შედიოდა თუ არა მომხმარებელმა ღრუბელში სანდო მოწყობილობიდან (მაგალითად, კორპორატიულ ქსელში ამ ამოცანას ახორციელებს Cisco ISE). რაც შეეხება ისეთ მარტივ ამოცანას, როგორიცაა geo-IP ფუნქცია, რომელიც დაგეხმარებათ დაადგინოთ, მოიპარეს თუ არა ღრუბლოვანი სერვისის მომხმარებლის ანგარიში? და მაშინაც კი, თუ ღრუბლოვანი პროვაიდერი მოგაწოდებთ მას, ეს საკმარისი არ არის. იგივე Cisco CloudLock არ აანალიზებს მხოლოდ გეოლოკაციას, არამედ იყენებს მანქანურ სწავლებას ამისთვის და აანალიზებს ისტორიულ მონაცემებს თითოეული მომხმარებლისთვის და აკონტროლებს სხვადასხვა ანომალიებს იდენტიფიკაციისა და ავთენტიფიკაციის მცდელობებში. მხოლოდ MS Azure-ს აქვს მსგავსი ფუნქციონირება (თუ თქვენ გაქვთ შესაბამისი გამოწერა).

არსებობს კიდევ ერთი სირთულე - რადგან ღრუბლოვანი პროვაიდერებისთვის ინფორმაციის უსაფრთხოების მონიტორინგი ახალი თემაა, რომელთანაც ისინი ახლა იწყებენ გამკლავებას, ისინი მუდმივად ცვლიან რაღაცას თავიანთ გადაწყვეტილებებში. დღეს მათ აქვთ API-ს ერთი ვერსია, ხვალ მეორე, ზეგ მესამე. თქვენ ასევე უნდა მოემზადოთ ამისთვის. იგივე ეხება ფუნქციონალურობას, რომელიც შეიძლება შეიცვალოს, რაც მხედველობაში უნდა იქნას მიღებული თქვენი ინფორმაციული უსაფრთხოების მონიტორინგის სისტემაში. მაგალითად, ამაზონს თავდაპირველად ჰქონდა ღრუბლოვანი მოვლენების მონიტორინგის ცალკეული სერვისები - AWS CloudTrail და AWS CloudWatch. შემდეგ გამოჩნდა ინფორმაციული უსაფრთხოების მოვლენების მონიტორინგის ცალკეული სერვისი - AWS GuardDuty. გარკვეული პერიოდის შემდეგ, ამაზონმა წამოიწყო მართვის ახალი სისტემა, Amazon Security Hub, რომელიც მოიცავს GuardDuty, Amazon Inspector, Amazon Macie და რამდენიმე სხვაგან მიღებული მონაცემების ანალიზს. კიდევ ერთი მაგალითია Azure log ინტეგრაციის ინსტრუმენტი SIEM-თან - AzLog. მას აქტიურად იყენებდნენ SIEM-ის მრავალი გამყიდველი, სანამ 2018 წელს მაიკროსოფტმა გამოაცხადა მისი განვითარებისა და მხარდაჭერის შეწყვეტის შესახებ, რამაც ბევრი კლიენტი, ვინც ამ ხელსაწყოს იყენებდა, პრობლემას დაუპირისპირდა (მოგვიანებით ვისაუბრებთ იმაზე, თუ როგორ მოგვარდა).

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

მაგალითი: ინფორმაციის უსაფრთხოების მონიტორინგი IaaS-ში AWS-ზე დაფუძნებული

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

პირველი, რაც უნდა ითქვას, არის ის, რომ ამაზონი არ არის შეუვალი ციხე. მის კლიენტებს რეგულარულად ემართებათ სხვადასხვა ინციდენტები. მაგალითად, Deep Root Analytics-დან მოიპარეს 198 მილიონი ამომრჩევლის სახელები, მისამართები, დაბადების თარიღები და ტელეფონის ნომრები. ისრაელის კომპანია Nice Systems-მა Verizon-ის აბონენტების 14 მილიონი ჩანაწერი მოიპარა. თუმცა, AWS-ის ჩაშენებული შესაძლებლობები საშუალებას გაძლევთ აღმოაჩინოთ ინციდენტების ფართო სპექტრი. Მაგალითად:

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

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

ინციდენტების იდენტიფიცირებისთვის შეგიძლიათ გამოიყენოთ Amazon-ის მიერ შემუშავებული სხვადასხვა მონიტორინგის სერვისების ფართო სპექტრი (თუმცა ისინი ხშირად ავსებენ გარე ხელსაწყოებს, როგორიცაა osquery). ასე რომ, AWS-ში ხდება მომხმარებლის ყველა მოქმედების მონიტორინგი, მიუხედავად იმისა, თუ როგორ ხორციელდება ისინი - მართვის კონსოლის, ბრძანების ხაზის, SDK ან სხვა AWS სერვისების მეშვეობით. თითოეული AWS ანგარიშის აქტივობის ყველა ჩანაწერი (მომხმარებლის სახელის, მოქმედების, სერვისის, აქტივობის პარამეტრების და შედეგის ჩათვლით) და API გამოყენების შესახებ ხელმისაწვდომია AWS CloudTrail-ის მეშვეობით. თქვენ შეგიძლიათ ნახოთ ეს მოვლენები (როგორიცაა AWS IAM კონსოლის შესვლა) CloudTrail-ის კონსოლიდან, გაანალიზოთ ისინი Amazon Athena-ს გამოყენებით, ან „აუთსორსინგი“ მათ გარე გადაწყვეტილებებზე, როგორიცაა Splunk, AlienVault და ა.შ. თავად AWS CloudTrail ჟურნალები მოთავსებულია თქვენს AWS S3 თაიგულში.

ორი სხვა AWS სერვისი უზრუნველყოფს სხვა მნიშვნელოვან მონიტორინგის შესაძლებლობებს. პირველი, Amazon CloudWatch არის AWS რესურსებისა და აპლიკაციების მონიტორინგის სერვისი, რომელიც, სხვა საკითხებთან ერთად, საშუალებას გაძლევთ ამოიცნოთ სხვადასხვა ანომალიები თქვენს ღრუბელში. ყველა ჩაშენებული AWS სერვისი, როგორიცაა Amazon Elastic Compute Cloud (სერვერები), Amazon Relational Database Service (მონაცემთა ბაზები), Amazon Elastic MapReduce (მონაცემების ანალიზი) და 30 სხვა Amazon სერვისი, იყენებს Amazon CloudWatch-ს მათი ჟურნალების შესანახად. დეველოპერებს შეუძლიათ გამოიყენონ ღია API Amazon CloudWatch-ისგან, რათა დაამატონ ჟურნალის მონიტორინგის ფუნქციონირება მორგებულ აპლიკაციებსა და სერვისებზე, რაც მათ საშუალებას აძლევს გააფართოონ მოვლენის ანალიზის ფარგლები უსაფრთხოების კონტექსტში.

მეორეც, VPC Flow Logs სერვისი საშუალებას გაძლევთ გაანალიზოთ თქვენი AWS სერვერების მიერ გაგზავნილი ან მიღებული ქსელის ტრაფიკი (გარედან ან შიგნით), ასევე მიკროსერვისებს შორის. როდესაც თქვენი AWS VPC ნებისმიერი რესურსი ურთიერთქმედებს ქსელთან, VPC Flow Logs აღრიცხავს დეტალებს ქსელის ტრაფიკის შესახებ, მათ შორის წყაროს და დანიშნულების ქსელის ინტერფეისის, ასევე IP მისამართებს, პორტებს, პროტოკოლს, ბაიტების რაოდენობას და პაკეტების რაოდენობას. დაინახა. ლოკალური ქსელის უსაფრთხოების მქონე ადამიანები ამას აღიარებენ, როგორც ძაფების ანალოგს NetFlow, რომელიც შეიძლება შეიქმნას გადამრთველებით, მარშრუტიზატორებით და საწარმოს კლასის ფაირვოლებით. ეს ჟურნალები მნიშვნელოვანია ინფორმაციის უსაფრთხოების მონიტორინგის მიზნებისთვის, რადგან მომხმარებლებისა და აპლიკაციების მოქმედებებისგან განსხვავებით, ისინი ასევე საშუალებას გაძლევთ არ გამოტოვოთ ქსელის ურთიერთქმედება AWS ვირტუალურ კერძო ღრუბლოვან გარემოში.

მოკლედ, ეს სამი AWS სერვისი - AWS CloudTrail, Amazon CloudWatch და VPC Flow Logs - ერთად იძლევა საკმაოდ ძლიერ ინფორმაციას თქვენი ანგარიშის გამოყენების, მომხმარებლის ქცევის, ინფრასტრუქტურის მენეჯმენტის, აპლიკაციისა და სერვისის აქტივობისა და ქსელის აქტივობის შესახებ. მაგალითად, ისინი შეიძლება გამოყენებულ იქნას შემდეგი ანომალიების გამოსავლენად:

ცდილობს საიტის სკანირებას, უკანა კარების ძიებას, მოწყვლადობის მოძიებას „404 შეცდომების“ მეშვეობით.
ინექციის შეტევები (მაგალითად, SQL ინექცია) "500 შეცდომის" ადიდებული გზით.
შეტევის ცნობილი ინსტრუმენტებია sqlmap, nikto, w3af, nmap და ა.შ. მომხმარებლის აგენტის ველის ანალიზის მეშვეობით.

Amazon Web Services-მა ასევე შეიმუშავა სხვა სერვისები კიბერუსაფრთხოების მიზნებისთვის, რომლებიც საშუალებას გაძლევთ გადაჭრათ მრავალი სხვა პრობლემა. მაგალითად, AWS-ს აქვს ჩაშენებული სერვისი პოლიტიკისა და კონფიგურაციის აუდიტის შესამოწმებლად - AWS Config. ეს სერვისი უზრუნველყოფს თქვენი AWS რესურსების და მათი კონფიგურაციის უწყვეტ აუდიტს. ავიღოთ მარტივი მაგალითი: ვთქვათ, გსურთ დარწმუნდეთ, რომ მომხმარებლის პაროლები გამორთულია თქვენს ყველა სერვერზე და რომ წვდომა შესაძლებელია მხოლოდ სერტიფიკატების საფუძველზე. AWS Config აადვილებს ამის შემოწმებას თქვენი ყველა სერვერისთვის. არსებობს სხვა წესები, რომლებიც შეიძლება გამოყენებულ იქნას თქვენს ღრუბლოვან სერვერებზე: „ვერცერთ სერვერს არ შეუძლია გამოიყენოს პორტი 22“, „მხოლოდ ადმინისტრატორებს შეუძლიათ შეცვალონ firewall-ის წესები“ ან „მხოლოდ მომხმარებელს Ivashko-ს შეუძლია შექმნას ახალი მომხმარებლის ანგარიშები და მას შეუძლია გააკეთოს ეს მხოლოდ სამშაბათს. " 2016 წლის ზაფხულში AWS Config სერვისი გაფართოვდა შემუშავებული პოლიტიკის დარღვევების გამოვლენის ავტომატიზაციისთვის. AWS კონფიგურაციის წესები არსებითად არის უწყვეტი კონფიგურაციის მოთხოვნები თქვენს მიერ გამოყენებული ამაზონის სერვისებისთვის, რომლებიც წარმოქმნიან მოვლენებს შესაბამისი წესების დარღვევის შემთხვევაში. მაგალითად, იმის ნაცვლად, რომ პერიოდულად გაუშვათ AWS Config მოთხოვნები, რათა დაადასტუროთ, რომ ვირტუალურ სერვერზე ყველა დისკი დაშიფრულია, AWS Config წესები შეიძლება გამოყენებულ იქნას სერვერის დისკების მუდმივი შესამოწმებლად, რათა დარწმუნდეთ, რომ ეს პირობა დაკმაყოფილებულია. და რაც მთავარია, ამ პუბლიკაციის კონტექსტში, ნებისმიერი დარღვევა წარმოშობს მოვლენებს, რომლებიც შეიძლება გაანალიზდეს თქვენი ინფორმაციული უსაფრთხოების სამსახურის მიერ.

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

შეჭრის გამოვლენა - AWS GuardDuty
ინფორმაციის გაჟონვის კონტროლი - AWS Macie
EDR (თუმცა ის ცოტა უცნაურად საუბრობს ღრუბელში ბოლო წერტილებზე) - AWS Cloudwatch + ღია კოდის osquery ან GRR გადაწყვეტილებები
ქსელის ანალიზი - AWS Cloudwatch + AWS VPC Flow
DNS ანალიზი - AWS Cloudwatch + AWS Route53
AD - AWS დირექტორია სერვისი
ანგარიშის მენეჯმენტი - AWS IAM
SSO - AWS SSO
უსაფრთხოების ანალიზი - AWS ინსპექტორი
კონფიგურაციის მართვა - AWS Config
WAF - AWS WAF.

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

ნებისმიერ შემთხვევაში, ყველაფერი იწყება მონაცემთა წყაროებით, რომლებიც მოგაწვდით ინფორმაციის უსაფრთხოების მოვლენებს. ეს წყაროები მოიცავს, მაგრამ არ შემოიფარგლება მხოლოდ:

CloudTrail - API გამოყენება და მომხმარებლის მოქმედებები
სანდო მრჩეველი - უსაფრთხოების შემოწმება საუკეთესო პრაქტიკის წინააღმდეგ
კონფიგურაცია - ინვენტარიზაცია და კონფიგურაცია ანგარიშებისა და სერვისების პარამეტრები
VPC Flow Logs - კავშირები ვირტუალურ ინტერფეისებთან
IAM - იდენტიფიკაციისა და ავთენტიფიკაციის სერვისი
ELB Access Logs - Load Balancer
ინსპექტორი - განაცხადის ხარვეზები
S3 - ფაილის შენახვა
CloudWatch - აპლიკაციის აქტივობა
SNS არის შეტყობინების სერვისი.

ამაზონი, მიუხედავად იმისა, რომ გვთავაზობს ღონისძიების წყაროების და ინსტრუმენტების ასეთ სპექტრს მათი თაობისთვის, ძალზე შეზღუდულია შეგროვებული მონაცემების ინფორმაციული უსაფრთხოების კონტექსტში ანალიზის უნარით. თქვენ მოგიწევთ დამოუკიდებლად შეისწავლოთ ხელმისაწვდომი ჟურნალები, მოძებნოთ მათში კომპრომისის შესაბამისი ინდიკატორები. AWS Security Hub, რომელიც ამაზონმა ახლახან გამოუშვა, მიზნად ისახავს ამ პრობლემის გადაჭრას AWS-ისთვის ღრუბლოვანი SIEM გადაქცევით. მაგრამ ჯერჯერობით ის მხოლოდ მოგზაურობის დასაწყისშია და შეზღუდულია როგორც წყაროების რაოდენობით, რომლებთანაც მუშაობს, ასევე სხვა შეზღუდვებით, რომლებიც დადგენილია თავად Amazon-ის არქიტექტურითა და ხელმოწერებით.

მაგალითი: ინფორმაციის უსაფრთხოების მონიტორინგი IaaS-ში Azure-ზე დაფუძნებული

არ მინდა გრძელ დებატებში ჩავვარდე იმის შესახებ, თუ რომელია ღრუბლის სამი პროვაიდერი (Amazon, Microsoft თუ Google) უკეთესი (განსაკუთრებით, რომ თითოეულ მათგანს ჯერ კიდევ აქვს საკუთარი სპეციფიკა და შესაფერისია საკუთარი პრობლემების გადასაჭრელად); მოდით, ყურადღება გავამახვილოთ ინფორმაციული უსაფრთხოების მონიტორინგის შესაძლებლობებზე, რომლებსაც ეს მოთამაშეები გვაწვდიან. უნდა ვაღიაროთ, რომ Amazon AWS იყო ერთ-ერთი პირველი ამ სეგმენტში და, შესაბამისად, ყველაზე შორს წავიდა ინფორმაციული უსაფრთხოების ფუნქციების თვალსაზრისით (თუმცა ბევრი აღიარებს, რომ მათი გამოყენება რთულია). მაგრამ ეს არ ნიშნავს იმას, რომ ჩვენ უგულებელყოფთ იმ შესაძლებლობებს, რომლებსაც Microsoft და Google გვაწვდიან.

მაიკროსოფტის პროდუქტები ყოველთვის გამოირჩეოდა „გახსნით“ და Azure-შიც ანალოგიური სიტუაციაა. მაგალითად, თუ AWS და GCP ყოველთვის გამომდინარეობენ კონცეფციიდან "რაც დაუშვებელია აკრძალულია", მაშინ Azure-ს აქვს სრულიად საპირისპირო მიდგომა. მაგალითად, ღრუბელში ვირტუალური ქსელის და მასში ვირტუალური მანქანის შექმნისას, ყველა პორტი და პროტოკოლი ღიაა და ნებადართულია ნაგულისხმევად. ამიტომ, თქვენ მოგიწევთ ცოტა მეტი ძალისხმევის დახარჯვა Microsoft-ის ღრუბელში წვდომის კონტროლის სისტემის საწყის დაყენებაზე. და ეს ასევე უფრო მკაცრ მოთხოვნებს აწესებს თქვენზე Azure ღრუბელში აქტივობის მონიტორინგის თვალსაზრისით.

AWS-ს აქვს თავისებურება, რომელიც დაკავშირებულია იმ ფაქტთან, რომ როდესაც თქვენ აკვირდებით თქვენს ვირტუალურ რესურსებს, თუ ისინი განლაგებულია სხვადასხვა რეგიონში, მაშინ გიჭირთ ყველა მოვლენის გაერთიანება და მათი ერთიანი ანალიზი, რომლის აღმოსაფხვრელად საჭიროა მიმართოთ სხვადასხვა ხრიკებს, მაგ. შექმენით თქვენი საკუთარი კოდი AWS Lambda-სთვის, რომელიც გადაიტანს მოვლენებს რეგიონებს შორის. Azure-ს არ აქვს ეს პრობლემა - მისი Activity Log მექანიზმი აკონტროლებს ყველა აქტივობას მთელ ორგანიზაციაში შეზღუდვების გარეშე. იგივე ეხება AWS Security Hub-ს, რომელიც ახლახან შეიქმნა ამაზონის მიერ, რათა გააერთიანოს უსაფრთხოების მრავალი ფუნქცია ერთი უსაფრთხოების ცენტრში, მაგრამ მხოლოდ მის რეგიონში, რაც, თუმცა, რუსეთისთვის არ არის აქტუალური. Azure-ს აქვს საკუთარი უსაფრთხოების ცენტრი, რომელიც არ არის შეზღუდული რეგიონალური შეზღუდვებით, რაც უზრუნველყოფს ღრუბლოვანი პლატფორმის უსაფრთხოების ყველა მახასიათებელს. უფრო მეტიც, სხვადასხვა ადგილობრივი გუნდისთვის მას შეუძლია უზრუნველყოს დამცავი შესაძლებლობების საკუთარი ნაკრები, მათ შორის უსაფრთხოების ღონისძიებები, რომლებსაც მართავს. AWS Security Hub ჯერ კიდევ გზაშია Azure უსაფრთხოების ცენტრის მსგავსი გახდეს. მაგრამ ღირს მალამოში ბუზის დამატება - შეგიძლიათ Azure-დან ბევრი გამოწუროთ, რაც ადრე იყო აღწერილი AWS-ში, მაგრამ ეს ყველაზე მოსახერხებელია მხოლოდ Azure AD-ისთვის, Azure Monitor-ისთვის და Azure Security Center-ისთვის. ყველა სხვა Azure უსაფრთხოების მექანიზმი, უსაფრთხოების მოვლენების ანალიზის ჩათვლით, ჯერ არ არის მართული ყველაზე მოსახერხებელი გზით. პრობლემა ნაწილობრივ მოგვარებულია API-ით, რომელიც გაჟღენთილია Microsoft Azure-ის ყველა სერვისში, მაგრამ ამას დასჭირდება თქვენგან დამატებითი ძალისხმევა თქვენი ღრუბლის თქვენს SOC-თან ინტეგრირებისთვის და კვალიფიციური სპეციალისტების თანდასწრებით (ფაქტობრივად, როგორც ნებისმიერი სხვა SIEM, რომელიც მუშაობს ღრუბელთან. APIs). ზოგიერთი SIEM, რომელიც მოგვიანებით იქნება განხილული, უკვე მხარს უჭერს Azure-ს და შეუძლია მისი მონიტორინგის ამოცანის ავტომატიზაცია, მაგრამ მას ასევე აქვს საკუთარი სირთულეები - ყველა მათგანს არ შეუძლია შეაგროვოს ყველა ჟურნალი, რაც Azure-ს აქვს.

Azure-ში მოვლენების შეგროვება და მონიტორინგი ხორციელდება Azure Monitor სერვისის გამოყენებით, რომელიც წარმოადგენს Microsoft-ის ღრუბელში მონაცემების შეგროვების, შენახვისა და ანალიზის მთავარ ინსტრუმენტს და მის რესურსებს - Git საცავებს, კონტეინერებს, ვირტუალურ მანქანებს, აპლიკაციებს და ა.შ. Azure Monitor-ის მიერ შეგროვებული ყველა მონაცემი იყოფა ორ კატეგორიად - მეტრიკა, რომელიც გროვდება რეალურ დროში და აღწერს Azure ღრუბლის მუშაობის ძირითად ინდიკატორებს და ჟურნალებს, რომლებიც შეიცავს ჩანაწერებში ორგანიზებულ მონაცემებს, რომლებიც ახასიათებს Azure რესურსების და სერვისების აქტივობის გარკვეულ ასპექტებს. გარდა ამისა, მონაცემთა შემგროვებელი API-ს გამოყენებით, Azure Monitor სერვისს შეუძლია შეაგროვოს მონაცემები ნებისმიერი REST წყაროდან, რათა შექმნას საკუთარი მონიტორინგის სცენარები.

აქ არის რამდენიმე უსაფრთხოების ღონისძიების წყარო, რომლებსაც Azure გთავაზობთ და რომლებზეც შეგიძლიათ წვდომა Azure Portal-ის, CLI-ის, PowerShell-ის ან REST API-ის მეშვეობით (და ზოგიერთი მხოლოდ Azure Monitor/Insight API-ის მეშვეობით):

აქტივობის ჟურნალები - ეს ჟურნალი პასუხობს კლასიკურ კითხვებს „ვინ“, „რა“ და „როდის“ ღრუბლოვან რესურსებზე ჩაწერის ნებისმიერ ოპერაციასთან დაკავშირებით (PUT, POST, DELETE). წაკითხვის წვდომასთან დაკავშირებული მოვლენები (GET) არ შედის ამ ჟურნალში, ისევე როგორც სხვა მრავალი.
დიაგნოსტიკური ჟურნალები - შეიცავს მონაცემებს თქვენს გამოწერაში შეტანილი კონკრეტული რესურსით ოპერაციების შესახებ.
Azure AD ანგარიშგება - შეიცავს როგორც მომხმარებლის აქტივობას, ასევე სისტემის აქტივობას, რომელიც დაკავშირებულია ჯგუფთან და მომხმარებლის მენეჯმენტთან.
Windows Event Log და Linux Syslog - შეიცავს მოვლენებს ღრუბელში განთავსებული ვირტუალური მანქანებიდან.
მეტრიკა - შეიცავს ტელემეტრიას თქვენი ღრუბლოვანი სერვისებისა და რესურსების მუშაობისა და ჯანმრთელობის მდგომარეობის შესახებ. ყოველ წუთს იზომება და ინახება. 30 დღის განმავლობაში.
ქსელის უსაფრთხოების ჯგუფის ნაკადის ჟურნალები - შეიცავს მონაცემებს ქსელის უსაფრთხოების მოვლენების შესახებ, რომლებიც შეგროვებულია Network Watcher სერვისის და რესურსების მონიტორინგის გამოყენებით ქსელის დონეზე.
შენახვის ჟურნალები - შეიცავს მოვლენებს, რომლებიც დაკავშირებულია შენახვის ობიექტებთან წვდომასთან.

მონიტორინგისთვის შეგიძლიათ გამოიყენოთ გარე SIEM ან ჩაშენებული Azure მონიტორი და მისი გაფართოებები. ინფორმაციის უსაფრთხოების ღონისძიებების მართვის სისტემებზე მოგვიანებით ვისაუბრებთ, მაგრამ ახლა ვნახოთ, რას გვთავაზობს თავად Azure უსაფრთხოების კონტექსტში მონაცემთა ანალიზისთვის. Azure მონიტორში ყველა უსაფრთხოებასთან დაკავშირებული ყველაფრის მთავარი ეკრანი არის Log Analytics უსაფრთხოებისა და აუდიტის დაფა (უფასო ვერსია მხარს უჭერს მოვლენის შეზღუდულ შენახვას მხოლოდ ერთი კვირის განმავლობაში). ეს დაფა დაყოფილია 5 ძირითად ზონად, რომლებიც ვიზუალურად ასახავს შემაჯამებელ სტატისტიკას იმის შესახებ, თუ რა ხდება ღრუბლოვან გარემოში, რომელსაც იყენებთ:

უსაფრთხოების დომენები - ძირითადი რაოდენობრივი ინდიკატორები, რომლებიც დაკავშირებულია ინფორმაციულ უსაფრთხოებასთან - ინციდენტების რაოდენობა, კომპრომეტირებული კვანძების რაოდენობა, გაუხსნელი კვანძები, ქსელის უსაფრთხოების მოვლენები და ა.შ.
Notable Issues - აჩვენებს ინფორმაციული უსაფრთხოების აქტიური საკითხების რაოდენობასა და მნიშვნელობას
Detections - აჩვენებს თქვენს წინააღმდეგ გამოყენებულ თავდასხმების ნიმუშებს
Threat Intelligence - აჩვენებს გეოგრაფიულ ინფორმაციას გარე კვანძებზე, რომლებიც თავს დაესხნენ თქვენ
უსაფრთხოების საერთო მოთხოვნები - ტიპიური მოთხოვნები, რომლებიც დაგეხმარებათ უკეთ აკონტროლოთ თქვენი ინფორმაციული უსაფრთხოება.

Azure მონიტორის გაფართოებები მოიცავს Azure Key Vault (კრიპტოგრაფიული გასაღებების დაცვა ღრუბელში), Malware Assessment (ვირტუალურ მანქანებზე მავნე კოდისგან დაცვის ანალიზი), Azure Application Gateway Analytics (სხვა საკითხებთან ერთად ღრუბლოვანი firewall ჟურნალების ანალიზი) და ა.შ. . ეს ხელსაწყოები, გამდიდრებული ღონისძიებების დამუშავების გარკვეული წესებით, საშუალებას გაძლევთ ვიზუალურად წარმოიდგინოთ ღრუბლოვანი სერვისების საქმიანობის სხვადასხვა ასპექტები, უსაფრთხოების ჩათვლით, და განსაზღვროთ გარკვეული გადახრები ოპერაციიდან. მაგრამ, როგორც ხშირად ხდება, ნებისმიერი დამატებითი ფუნქციონირება მოითხოვს შესაბამის ფასიან გამოწერას, რომელიც მოითხოვს თქვენგან შესაბამის ფინანსურ ინვესტიციებს, რაც წინასწარ უნდა დაგეგმოთ.

Azure-ს აქვს ჩაშენებული საფრთხის მონიტორინგის შესაძლებლობები, რომლებიც ინტეგრირებულია Azure AD-ში, Azure Monitor-სა და Azure Security Center-ში. მათ შორის, მაგალითად, ვირტუალური მანქანების ურთიერთქმედების გამოვლენა ცნობილ მავნე IP-ებთან (მაიკროსოფტის Threat Intelligence სერვისებთან ინტეგრაციის გამო), ღრუბლოვან ინფრასტრუქტურაში მავნე პროგრამის გამოვლენა ღრუბელში განთავსებული ვირტუალური მანქანებისგან განგაშის მიღებით, პაროლი. შეტევების გამოცნობა” ვირტუალურ მანქანებზე, დაუცველობა მომხმარებლის იდენტიფიკაციის სისტემის კონფიგურაციაში, სისტემაში შესვლა ანონიმიზატორებიდან ან ინფიცირებული კვანძებიდან, ანგარიშის გაჟონვა, სისტემაში შესვლა უჩვეულო ადგილებიდან და ა.შ. Azure დღეს არის ერთ-ერთი იმ რამდენიმე ღრუბლოვანი პროვაიდერიდან, რომელიც გთავაზობთ ჩაშენებულ Threat Intelligence-ის შესაძლებლობებს შეგროვებული ინფორმაციის უსაფრთხოების ღონისძიებების გასამდიდრებლად.

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

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

თუ გჭირდებათ არა მხოლოდ ჟურნალებთან მუშაობის უნარი, არამედ ყოვლისმომცველი უსაფრთხოების ცენტრი თქვენი Azure ღრუბლოვანი პლატფორმისთვის, ინფორმაციის უსაფრთხოების პოლიტიკის მენეჯმენტის ჩათვლით, მაშინ შეგიძლიათ ისაუბროთ Azure უსაფრთხოების ცენტრთან მუშაობის აუცილებლობაზე, რომლის უმეტესი სასარგებლო ფუნქციაა. ხელმისაწვდომია გარკვეული თანხისთვის, მაგალითად, საფრთხის გამოვლენა, მონიტორინგი Azure-ის გარეთ, შესაბამისობის შეფასება და ა.შ. (უფასო ვერსიაში თქვენ გაქვთ წვდომა მხოლოდ უსაფრთხოების შეფასებაზე და რეკომენდაციებზე გამოვლენილი პრობლემების აღმოსაფხვრელად). ის აერთიანებს უსაფრთხოების ყველა საკითხს ერთ ადგილას. სინამდვილეში, ჩვენ შეგვიძლია ვისაუბროთ ინფორმაციული უსაფრთხოების უფრო მაღალ დონეზე, ვიდრე Azure Monitor გთავაზობთ, რადგან ამ შემთხვევაში თქვენი ღრუბლოვანი ქარხანაში შეგროვებული მონაცემები გამდიდრებულია მრავალი წყაროს გამოყენებით, როგორიცაა Azure, Office 365, Microsoft CRM ონლაინ, Microsoft Dynamics AX. , outlook .com, MSN.com, Microsoft Digital Crimes Unit (DCU) და Microsoft Security Response Center (MSRC), რომლებზედაც დაყენებულია სხვადასხვა დახვეწილი მანქანათმცოდნეობის და ქცევითი ანალიტიკის ალგორითმები, რაც საბოლოოდ უნდა გააუმჯობესოს საფრთხეების გამოვლენისა და რეაგირების ეფექტურობა. .

Azure-ს ასევე აქვს საკუთარი SIEM - ის 2019 წლის დასაწყისში გამოჩნდა. ეს არის Azure Sentinel, რომელიც ეყრდნობა Azure Monitor-ის მონაცემებს და ასევე შეუძლია ინტეგრირება. გარე უსაფრთხოების გადაწყვეტილებები (მაგალითად, NGFW ან WAF), რომელთა სია მუდმივად იზრდება. გარდა ამისა, Microsoft Graph Security API-ის ინტეგრაციის საშუალებით, თქვენ გაქვთ შესაძლებლობა დააკავშიროთ თქვენი საფრთხის დაზვერვის არხები Sentinel-თან, რაც ამდიდრებს თქვენს Azure ღრუბელში ინციდენტების ანალიზის შესაძლებლობებს. შეიძლება ითქვას, რომ Azure Sentinel არის პირველი „მშობლიური“ SIEM, რომელიც გამოჩნდა ღრუბლოვანი პროვაიდერებისგან (იგივე Splunk ან ELK, რომელიც შეიძლება ღრუბელში განთავსდეს, მაგალითად, AWS, ჯერ კიდევ არ არის შემუშავებული ღრუბლოვანი სერვისის ტრადიციული პროვაიდერების მიერ). Azure Sentinel და უსაფრთხოების ცენტრს შეიძლება ეწოდოს SOC Azure ღრუბლისთვის და შეიძლება შემოიფარგლოს მათზე (გარკვეული დათქმებით), თუ აღარ გქონდეთ ინფრასტრუქტურა და გადაიტანდით თქვენს ყველა გამოთვლილ რესურსს ღრუბელში და ეს იქნებოდა Microsoft Cloud Azure.

მაგრამ ვინაიდან Azure-ის ჩაშენებული შესაძლებლობები (თუნდაც თქვენ გაქვთ Sentinel-ის გამოწერა) ხშირად არ არის საკმარისი ინფორმაციის უსაფრთხოების მონიტორინგისა და ამ პროცესის უსაფრთხოების სხვა წყაროებთან (როგორც ღრუბელი, ასევე შიდა) ინტეგრირებისთვის, არსებობს საჭიროა შეგროვებული მონაცემების ექსპორტი გარე სისტემებში, რომლებშიც შეიძლება მოიცავდეს SIEM. ეს კეთდება როგორც API-ის გამოყენებით, ასევე სპეციალური გაფართოებების გამოყენებით, რომლებიც ამჟამად ოფიციალურად ხელმისაწვდომია მხოლოდ შემდეგი SIEM-ებისთვის - Splunk (Azure Monitor Add-On for Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight და ELK. ბოლო დრომდე, უფრო მეტი ასეთი SIEM იყო, მაგრამ 1 წლის 2019 ივნისიდან Microsoft-მა შეწყვიტა Azure Log Integration Tool-ის (AzLog) მხარდაჭერა, რომელიც Azure-ის არსებობის გარიჟრაჟზე და ჟურნალებთან მუშაობის ნორმალური სტანდარტიზაციის არარსებობის შემთხვევაში (Azure მონიტორი ჯერ კიდევ არ არსებობდა) გაადვილა გარე SIEM-ის ინტეგრირება Microsoft-ის ღრუბელთან. ახლა სიტუაცია შეიცვალა და Microsoft რეკომენდაციას უწევს Azure Event Hub პლატფორმას, როგორც ინტეგრაციის მთავარ ინსტრუმენტს სხვა SIEM-ებისთვის. ბევრმა უკვე დანერგა ასეთი ინტეგრაცია, მაგრამ ფრთხილად იყავით - მათ შეიძლება არ დაიკავონ Azure-ის ყველა ჟურნალი, მაგრამ მხოლოდ ზოგიერთი (ნახეთ თქვენი SIEM-ის დოკუმენტაციაში).

Azure-ში მოკლე ექსკურსიის დასასრულს, მსურს ზოგადი რეკომენდაცია მოგცეთ ამ ღრუბლოვან სერვისთან დაკავშირებით - სანამ რაიმეს იტყვით Azure-ში ინფორმაციის უსაფრთხოების მონიტორინგის ფუნქციების შესახებ, თქვენ უნდა დააკონფიგურიროთ ისინი ძალიან ფრთხილად და შეამოწმოთ, რომ ისინი მუშაობენ ისე, როგორც ეს დოკუმენტაციაშია დაწერილი. როგორც კონსულტანტებმა გითხრეს Microsoft-ს (და მათ შეიძლება ჰქონდეთ განსხვავებული შეხედულებები Azure ფუნქციების ფუნქციონირებაზე). თუ გაქვთ ფინანსური რესურსი, შეგიძლიათ Azure-სგან ბევრი სასარგებლო ინფორმაცია გამოაქვეყნოთ ინფორმაციული უსაფრთხოების მონიტორინგის თვალსაზრისით. თუ თქვენი რესურსები შეზღუდულია, მაშინ, როგორც AWS-ის შემთხვევაში, თქვენ მოგიწევთ დაეყრდნოთ მხოლოდ საკუთარ ძალას და იმ ნედლეულ მონაცემებს, რომლებსაც გაწვდით Azure Monitor. და დაიმახსოვრეთ, რომ ბევრი მონიტორინგის ფუნქცია ფული ღირს და უმჯობესია წინასწარ გაეცნოთ საფასო პოლიტიკას. მაგალითად, უფასოდ შეგიძლიათ შეინახოთ 31 დღის მონაცემები მაქსიმუმ 5 გბაიტამდე თითო კლიენტზე - ამ მნიშვნელობების გადაჭარბება მოგიწევთ დამატებითი თანხის დახარჯვას (დაახლოებით $2+ თითოეული დამატებითი გბაიტის შესანახად კლიენტისგან და $0,1-ისთვის. ყოველ დამატებით თვეში 1 GB-ის შენახვა). აპლიკაციის ტელემეტრიასთან და მეტრიკასთან მუშაობამ შეიძლება ასევე მოითხოვოს დამატებითი სახსრები, ასევე მუშაობა გაფრთხილებებთან და შეტყობინებებთან (გარკვეული ლიმიტი ხელმისაწვდომია უფასოდ, რაც შეიძლება არ იყოს საკმარისი თქვენი საჭიროებისთვის).

მაგალითი: ინფორმაციის უსაფრთხოების მონიტორინგი IaaS-ში Google Cloud Platform-ზე დაფუძნებული

Google Cloud Platform ახალგაზრდას ჰგავს AWS-სა და Azure-თან შედარებით, მაგრამ ეს ნაწილობრივ კარგია. AWS-ისგან განსხვავებით, რომელმაც თანდათან გაზარდა თავისი შესაძლებლობები, მათ შორის უსაფრთხოების, ცენტრალიზაციასთან დაკავშირებული პრობლემები; GCP, ისევე როგორც Azure, ბევრად უკეთ იმართება ცენტრალიზებულად, რაც ამცირებს შეცდომებს და დანერგვის დროს საწარმოში. უსაფრთხოების თვალსაზრისით, GCP, უცნაურად საკმარისია, AWS-სა და Azure-ს შორის. მას ასევე აქვს ერთი ღონისძიების რეგისტრაცია მთელი ორგანიზაციისთვის, მაგრამ ის არასრულია. ზოგიერთი ფუნქცია ჯერ კიდევ ბეტა რეჟიმშია, მაგრამ თანდათან ეს დეფიციტი უნდა აღმოიფხვრას და GCP გახდება უფრო მომწიფებული პლატფორმა ინფორმაციული უსაფრთხოების მონიტორინგის თვალსაზრისით.

GCP-ში მოვლენების აღრიცხვის მთავარი ინსტრუმენტი არის Stackdriver Logging (მსგავსი Azure Monitor), რომელიც საშუალებას გაძლევთ შეაგროვოთ მოვლენები მთელ ღრუბლოვან ინფრასტრუქტურაში (ასევე AWS-დან). GCP-ში უსაფრთხოების თვალსაზრისით, თითოეულ ორგანიზაციას, პროექტს ან საქაღალდეს აქვს ოთხი ჟურნალი:

ადმინისტრატორის აქტივობა - შეიცავს ადმინისტრაციულ წვდომასთან დაკავშირებულ ყველა მოვლენას, მაგალითად, ვირტუალური მანქანის შექმნას, წვდომის უფლებების შეცვლას და ა.შ. ეს ჟურნალი ყოველთვის იწერება, თქვენი სურვილის მიუხედავად და ინახავს მის მონაცემებს 400 დღის განმავლობაში.
მონაცემთა წვდომა - შეიცავს ყველა მოვლენას, რომელიც დაკავშირებულია ღრუბლოვანი მომხმარებლების მონაცემებთან მუშაობასთან (შექმნა, მოდიფიკაცია, კითხვა და ა.შ.). ნაგულისხმევად, ეს ჟურნალი არ არის დაწერილი, რადგან მისი მოცულობა ძალიან სწრაფად იზრდება. ამ მიზეზით, მისი შენახვის ვადა მხოლოდ 30 დღეა. გარდა ამისა, ამ ჟურნალში ყველაფერი არ წერია. მაგალითად, რესურსებთან დაკავშირებული ღონისძიებები, რომლებიც საჯაროდ ხელმისაწვდომია ყველა მომხმარებლისთვის ან ხელმისაწვდომია GCP-ში შესვლის გარეშე, მასში არ იწერება.
სისტემის მოვლენა - შეიცავს სისტემის მოვლენებს, რომლებიც არ არის დაკავშირებული მომხმარებლებთან, ან ადმინისტრატორის მოქმედებებს, რომელიც ცვლის ღრუბლის რესურსების კონფიგურაციას. ის ყოველთვის იწერება და ინახება 400 დღის განმავლობაში.
Access Transparency არის ჟურნალის უნიკალური მაგალითი, რომელიც აღწერს Google-ის თანამშრომლების ყველა მოქმედებას (მაგრამ ჯერ არა ყველა GCP სერვისისთვის), რომლებიც წვდებიან თქვენს ინფრასტრუქტურას, როგორც მათი სამუშაო მოვალეობების ნაწილი. ეს ჟურნალი ინახება 400 დღის განმავლობაში და არ არის ხელმისაწვდომი ყველა GCP კლიენტისთვის, მაგრამ მხოლოდ იმ შემთხვევაში, თუ დაკმაყოფილებულია მთელი რიგი პირობები (ან ოქროს ან პლატინის დონის მხარდაჭერა, ან გარკვეული ტიპის 4 როლის არსებობა კორპორატიული მხარდაჭერის ნაწილად). მსგავსი ფუნქცია ასევე ხელმისაწვდომია, მაგალითად, Office 365 - Lockbox.

ჟურნალის მაგალითი: წვდომა გამჭვირვალობაზე

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

ამ ჟურნალებზე წვდომა შესაძლებელია რამდენიმე გზით (ისევე, როგორც ადრე განვიხილეთ Azure და AWS) - Log Viewer ინტერფეისის მეშვეობით, API-ს მეშვეობით, Google Cloud SDK-ის მეშვეობით ან თქვენი პროექტის აქტივობის გვერდის მეშვეობით, რომლისთვისაც თქვენ დაინტერესებულია მოვლენებით. ანალოგიურად, მათი ექსპორტი შესაძლებელია გარე გადაწყვეტილებებში დამატებითი ანალიზისთვის. ეს უკანასკნელი კეთდება ჟურნალების ექსპორტით BigQuery ან Cloud Pub/Sub საცავში.

Stackdriver Logging-ის გარდა, GCP პლატფორმა ასევე გთავაზობთ Stackdriver Monitoring ფუნქციონირებას, რომელიც საშუალებას გაძლევთ აკონტროლოთ ღრუბლოვანი სერვისებისა და აპლიკაციების ძირითადი მეტრიკები (შესრულება, MTBF, საერთო ჯანმრთელობა და ა.შ.). დამუშავებულმა და ვიზუალიზებულმა მონაცემებმა შეიძლება გააადვილოს პრობლემების პოვნა თქვენს ღრუბლოვან ინფრასტრუქტურაში, მათ შორის უსაფრთხოების კონტექსტში. მაგრამ უნდა აღინიშნოს, რომ ეს ფუნქციონალობა არ იქნება ძალიან მდიდარი ინფორმაციული უსაფრთხოების კონტექსტში, რადგან დღეს GCP-ს არ აქვს იგივე AWS GuardDuty-ის ანალოგი და არ შეუძლია ცუდის იდენტიფიცირება ყველა რეგისტრირებულ მოვლენას შორის (Google-მა შეიმუშავა Event Threat Detection, მაგრამ ის ჯერ კიდევ დამუშავების პროცესშია ბეტაში და ჯერ ნაადრევია მის სარგებლობაზე საუბარი). Stackdriver Monitoring შეიძლება გამოვიყენოთ, როგორც სისტემა ანომალიების გამოსავლენად, რომელიც შემდგომ გამოიკვლიოს მათი წარმოშობის მიზეზების დასადგენად. მაგრამ ბაზარზე GCP ინფორმაციული უსაფრთხოების სფეროში კვალიფიციური პერსონალის ნაკლებობის გათვალისწინებით, ეს ამოცანა ამჟამად რთულად გამოიყურება.

ასევე ღირს ინფორმაციული უსაფრთხოების ზოგიერთი მოდულის ჩამონათვალის მიცემა, რომლებიც შეიძლება გამოყენებულ იქნას თქვენს GCP ღრუბელში და რომლებიც მსგავსია რასაც AWS გთავაზობთ:

Cloud Security Command Center არის AWS Security Hub-ისა და Azure Security Center-ის ანალოგი.
Cloud DLP - ღრუბელში განთავსებული მონაცემების ავტომატური აღმოჩენა და რედაქტირება (მაგ. შენიღბვა) 90-ზე მეტი წინასწარ განსაზღვრული კლასიფიკაციის პოლიტიკის გამოყენებით.
ღრუბლოვანი სკანერი არის ცნობილი დაუცველობის სკანერი (XSS, Flash Injection, გაუხსნელი ბიბლიოთეკები და ა.შ.) App Engine-ში, Compute Engine-სა და Google Kubernetes-ში.
Cloud IAM - აკონტროლეთ წვდომა GCP-ის ყველა რესურსზე.
Cloud Identity - მართეთ GCP მომხმარებლის, მოწყობილობის და აპლიკაციის ანგარიშები ერთი კონსოლიდან.
Cloud HSM - კრიპტოგრაფიული გასაღებების დაცვა.
Cloud Key Management Service - კრიპტოგრაფიული გასაღებების მართვა GCP-ში.
VPC სერვისის კონტროლი - შექმენით უსაფრთხო პერიმეტრი თქვენი GCP რესურსების გარშემო, რათა დაიცვათ ისინი გაჟონვისგან.
Titan უსაფრთხოების გასაღები - დაცვა ფიშინგისგან.

ბევრი ამ მოდული ქმნის უსაფრთხოების მოვლენებს, რომლებიც შეიძლება გაიგზავნოს BigQuery საცავში ანალიზისთვის ან ექსპორტისთვის სხვა სისტემებში, მათ შორის SIEM-ში. როგორც ზემოთ აღინიშნა, GCP არის აქტიურად განვითარებადი პლატფორმა და Google ახლა ავითარებს უამრავ ახალ საინფორმაციო უსაფრთხოების მოდულს თავისი პლატფორმისთვის. მათ შორისაა Event Threat Detection (ახლა ხელმისაწვდომია ბეტა რეჟიმში), რომელიც სკანირებს Stackdriver-ის ჟურნალებს არაავტორიზებული აქტივობის კვალის მოსაძებნად (ანალოგია GuardDuty-ზე AWS-ში) ან Policy Intelligence (ხელმისაწვდომია ალფაში), რომელიც საშუალებას მოგცემთ განავითაროთ ინტელექტუალური პოლიტიკა. GCP რესურსებზე წვდომა.

მე გავაკეთე მოკლე მიმოხილვა ჩაშენებული მონიტორინგის შესაძლებლობების პოპულარულ ღრუბლოვან პლატფორმებზე. მაგრამ გყავთ თუ არა სპეციალისტები, რომლებსაც შეუძლიათ იმუშაონ IaaS პროვაიდერის ჟურნალებთან (ყველა არ არის მზად იყიდოს AWS-ის, Azure-ის ან Google-ის მოწინავე შესაძლებლობები)? გარდა ამისა, ბევრი იცნობს ანდაზას „ენდე, მაგრამ გადაამოწმე“, რომელიც უსაფრთხოების სფეროში უფრო ჭეშმარიტია, ვიდრე ოდესმე. რამდენად ენდობით ღრუბლოვანი პროვაიდერის ჩაშენებულ შესაძლებლობებს, რომლებიც გიგზავნით ინფორმაციის უსაფრთხოების მოვლენებს? რამდენად აკეთებენ ისინი საერთოდ ყურადღებას ინფორმაციის უსაფრთხოებაზე?

ზოგჯერ ღირს გადაფარვის ღრუბლოვანი ინფრასტრუქტურის მონიტორინგის გადაწყვეტილებების ნახვა, რომლებსაც შეუძლიათ შეავსონ ჩაშენებული ღრუბლოვანი უსაფრთხოება, ზოგჯერ კი ასეთი გადაწყვეტილებები ერთადერთი ვარიანტია თქვენი მონაცემებისა და ღრუბელში განთავსებული აპლიკაციების უსაფრთხოების შესახებ ინფორმაციის მისაღებად. გარდა ამისა, ისინი უბრალოდ უფრო მოსახერხებელია, რადგან ისინი იღებენ ყველა დავალებას სხვადასხვა ღრუბლოვანი სერვისების მიერ წარმოქმნილი საჭირო ჟურნალების ანალიზის სხვადასხვა ღრუბლოვანი პროვაიდერისგან. ასეთი გადაფარვის გადაწყვეტის მაგალითია Cisco Stealthwatch Cloud, რომელიც ორიენტირებულია ერთ დავალებაზე - ინფორმაციული უსაფრთხოების ანომალიების მონიტორინგი ღრუბლოვან გარემოში, მათ შორის არა მხოლოდ Amazon AWS, Microsoft Azure და Google Cloud Platform, არამედ კერძო ღრუბლებიც.

მაგალითი: ინფორმაციის უსაფრთხოების მონიტორინგი Stealthwatch Cloud-ის გამოყენებით

AWS უზრუნველყოფს მოქნილ გამოთვლით პლატფორმას, მაგრამ ეს მოქნილობა უადვილებს კომპანიებს დაუშვან შეცდომები, რომლებიც უსაფრთხოების საკითხებს იწვევს. და საინფორმაციო უსაფრთხოების საერთო მოდელი მხოლოდ ამას უწყობს ხელს. ღრუბელში გაშვებული პროგრამული უზრუნველყოფა უცნობი დაუცველობით (ცნობილებთან ბრძოლა შესაძლებელია, მაგალითად, AWS Inspector ან GCP Cloud Scanner), სუსტი პაროლები, არასწორი კონფიგურაციები, ინსაიდერები და ა.შ. და ეს ყველაფერი აისახება ღრუბლოვანი რესურსების ქცევაზე, რომლის მონიტორინგიც შესაძლებელია Cisco Stealthwatch Cloud-ის მიერ, რომელიც წარმოადგენს ინფორმაციული უსაფრთხოების მონიტორინგისა და თავდასხმის აღმოჩენის სისტემას. საჯარო და კერძო ღრუბლები.

Cisco Stealthwatch Cloud-ის ერთ-ერთი მთავარი მახასიათებელია ერთეულების მოდელირების შესაძლებლობა. მასთან ერთად, თქვენ შეგიძლიათ შექმნათ პროგრამული მოდელი (ანუ თითქმის რეალურ დროში სიმულაცია) თქვენი ღრუბლის თითოეული რესურსისთვის (არ აქვს მნიშვნელობა ეს არის AWS, Azure, GCP თუ სხვა). ეს შეიძლება შეიცავდეს სერვერებს და მომხმარებლებს, ასევე რესურსების ტიპებს, რომლებიც სპეციფიკურია თქვენი ღრუბლოვანი გარემოსთვის, როგორიცაა უსაფრთხოების ჯგუფები და ავტომატური მასშტაბის ჯგუფები. ეს მოდელები იყენებენ ღრუბლოვანი სერვისების მიერ მოწოდებულ მონაცემთა სტრუქტურირებულ ნაკადებს, როგორც შეყვანას. მაგალითად, AWS-სთვის ეს იქნება VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda და AWS IAM. ერთეულის მოდელირება ავტომატურად აღმოაჩენს თქვენი ნებისმიერი რესურსის როლს და ქცევას (შეგიძლიათ ისაუბროთ ღრუბლის მთელი აქტივობის პროფილირებაზე). ამ როლებში შედის Android ან Apple მობილური მოწყობილობა, Citrix PVS სერვერი, RDP სერვერი, ფოსტის კარიბჭე, VoIP კლიენტი, ტერმინალის სერვერი, დომენის კონტროლერი და ა.შ. შემდეგ ის მუდმივად აკონტროლებს მათ ქცევას, რათა დადგინდეს, როდის ხდება სარისკო ან უსაფრთხოებისთვის საშიში ქცევა. თქვენ შეგიძლიათ ამოიცნოთ პაროლის გამოცნობა, DDoS შეტევები, მონაცემთა გაჟონვა, უკანონო დისტანციური წვდომა, მავნე კოდის აქტივობა, დაუცველობის სკანირება და სხვა საფრთხეები. მაგალითად, ასე გამოიყურება თქვენი ორგანიზაციისთვის ატიპიური ქვეყნიდან (სამხრეთ კორეა) კუბერნეტის კლასტერში დისტანციური წვდომის მცდელობის გამოვლენა SSH-ის საშუალებით:

და ასე გამოიყურება პოსტგრესის მონაცემთა ბაზიდან ინფორმაციის სავარაუდო გაჟონვა ქვეყანაში, რომელთანაც აქამდე არ გვქონია ურთიერთქმედება:

და ბოლოს, ასე გამოიყურება ძალიან ბევრი წარუმატებელი SSH მცდელობა ჩინეთიდან და ინდონეზიიდან გარე დისტანციური მოწყობილობიდან:

ან, დავუშვათ, რომ სერვერის მაგალითი VPC-ში, პოლიტიკის მიხედვით, არასოდეს იქნება შესვლის დისტანციური დანიშნულება. მოდით ვივარაუდოთ, რომ ამ კომპიუტერმა განიცადა დისტანციური შესვლა ფაირვოლ-ის წესების პოლიტიკაში არასწორი ცვლილების გამო. Entity Modeling ფუნქცია აღმოაჩენს და მოახსენებს ამ აქტივობას („არაჩვეულებრივი დისტანციური წვდომა“) თითქმის რეალურ დროში და მიუთითებს კონკრეტულ AWS CloudTrail-ზე, Azure Monitor-ზე ან GCP Stackdriver Logging API-ზე (მომხმარებლის სახელის, თარიღისა და დროის ჩათვლით, სხვა დეტალებთან ერთად). რამაც გამოიწვია ITU-ს წესის ცვლილება. და შემდეგ ეს ინფორმაცია შეიძლება გაიგზავნოს SIEM-ში ანალიზისთვის.

მსგავსი შესაძლებლობები დანერგილია ნებისმიერი ღრუბლოვანი გარემოსთვის, რომელსაც მხარს უჭერს Cisco Stealthwatch Cloud:

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

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

აღმოჩენილი ინფორმაციის უსაფრთხოების ღონისძიება შეიძლება გაიგზავნოს შესაბამისი ბილეთის სახით Slack-ში, Cisco Spark-ში, PagerDuty ინციდენტების მართვის სისტემაში და ასევე გაიგზავნოს სხვადასხვა SIEM-ში, მათ შორის Splunk ან ELK. შეჯამებისთვის, შეგვიძლია ვთქვათ, რომ თუ თქვენი კომპანია იყენებს მრავალ ღრუბლოვან სტრატეგიას და არ შემოიფარგლება მხოლოდ ღრუბლოვანი პროვაიდერებით, ზემოთ აღწერილი ინფორმაციული უსაფრთხოების მონიტორინგის შესაძლებლობებით, მაშინ Cisco Stealthwatch Cloud-ის გამოყენება კარგი ვარიანტია მონიტორინგის ერთიანი ნაკრების მისაღებად. შესაძლებლობები წამყვანი ღრუბლოვანი მოთამაშეებისთვის - Amazon, Microsoft და Google. ყველაზე საინტერესო ის არის, რომ თუ შევადარებთ Stealthwatch Cloud-ის ფასებს AWS, Azure ან GCP ინფორმაციული უსაფრთხოების მონიტორინგის მოწინავე ლიცენზიებთან, შეიძლება აღმოჩნდეს, რომ Cisco-ს გადაწყვეტა უფრო იაფიც კი იქნება, ვიდრე Amazon-ის, Microsoft-ის ჩაშენებული შესაძლებლობები. და Google გადაწყვეტილებები. პარადოქსულია, მაგრამ ასეა. და რაც უფრო მეტ ღრუბელს და მათ შესაძლებლობებს იყენებთ, მით უფრო აშკარა იქნება კონსოლიდირებული გადაწყვეტის უპირატესობა.

გარდა ამისა, Stealthwatch Cloud-ს შეუძლია დააკვირდეს თქვენს ორგანიზაციაში განლაგებულ კერძო ღრუბლებს, მაგალითად, Kubernetes-ის კონტეინერებზე დაყრდნობით ან Netflow ნაკადების ან ქსელური ტრაფიკის მონიტორინგით, რომელიც მიღებულია ქსელურ აღჭურვილობაში (თუნდაც შიდა წარმოების), AD მონაცემების ან DNS სერვერების და ა.შ. ყველა ეს მონაცემი გამდიდრდება Threat Intelligence-ის ინფორმაციით, რომელიც შეაგროვა Cisco Talos-მა, კიბერუსაფრთხოების საფრთხეების მკვლევართა მსოფლიოში უმსხვილესი არასამთავრობო ჯგუფი.

ეს საშუალებას გაძლევთ განახორციელოთ მონიტორინგის ერთიანი სისტემა, როგორც საჯარო, ასევე ჰიბრიდული ღრუბლებისთვის, რომელიც თქვენს კომპანიას შეუძლია გამოიყენოს. შემდეგ შეგროვებული ინფორმაცია შეიძლება გაანალიზდეს Stealthwatch Cloud-ის ჩაშენებული შესაძლებლობების გამოყენებით ან გაიგზავნოს თქვენს SIEM-ში (Splunk, ELK, SumoLogic და რამდენიმე სხვა მხარდაჭერილია ნაგულისხმევად).

ამით ჩვენ დავასრულებთ სტატიის პირველ ნაწილს, რომელშიც მიმოვიხილე ჩაშენებული და გარე ინსტრუმენტები IaaS/PaaS პლატფორმების ინფორმაციული უსაფრთხოების მონიტორინგისთვის, რაც საშუალებას გვაძლევს სწრაფად აღმოვაჩინოთ და ვუპასუხოთ ღრუბლოვან გარემოში მომხდარ ინციდენტებს. ჩვენმა საწარმომ აირჩია. მეორე ნაწილში ჩვენ გავაგრძელებთ თემას და გადავხედავთ SaaS პლატფორმების მონიტორინგის ვარიანტებს Salesforce-ისა და Dropbox-ის მაგალითის გამოყენებით, ასევე შევეცდებით შევაჯამოთ და გავაერთიანოთ ყველაფერი სხვადასხვა ღრუბლოვანი პროვაიდერებისთვის ინფორმაციის უსაფრთხოების მონიტორინგის ერთიანი სისტემის შექმნით.

წყარო: www.habr.com

ღრუბლოვანი უსაფრთხოების მონიტორინგი