მთავარი დასკვნა
ერთიანი პანელი არ ამტკიცებს, რომ ერთი კონტროლი ყველა პლატფორმაზე მუშაობს. განსაზღვრეთ საერთო მოთხოვნა, გამოსცადეთ თითო პროვაიდერის განხორციელება და ხარვეზებს პასუხისმგებლები დაუნიშნეთ.
შექმენით საერთო ინვენტარი და კონტროლის მიზნები
AWS ანგარიშების, Azure გამოწერებისა და Google Cloud პროექტების ერთიანი ინვენტარი მფლობელობით კავშირებთან ერთად შეინარჩუნეთ. განსაზღვრეთ საერთო ველები დატვირთვის, მონაცემთა კლასის, ინტერნეტში ღია ინტერფეისების, კრიტიკული დამოკიდებულებებისა და აღდგენის მფლობელისთვის. შემდეგ პროვაიდერებს შორის საერთო შედეგები დასახეთ, მაგალითად პრივილეგირებული წვდომის დაცვა, ჟურნალების შენახვა და ასლების გამოცდა. შიდა პოლიტიკა შეიძლება ერთიანი იყოს, მაგრამ სერვისის პარამეტრებს თითო ღრუბელში განსხვავებული განხორციელება დასჭირდება.
| საერთო მიზანი | პროვაიდერზე მორგებული შემოწმება | ეფექტიანობის მტკიცებულება |
|---|---|---|
| პრივილეგირებული წვდომა | როლის, ნდობისა და MFA‑ს კონფიგურაცია | გამოცდილი დაშვებული და აკრძალული მოქმედება |
| დაცული საცავი | საჯარო წვდომის, პოლიტიკისა და გასაღების პარამეტრები | წვდომის ტესტი და კონფიგურაცია |
| გამოსაყენებელი ჟურნალები | მოვლენათა შერჩევა, ექსპორტი და შენახვა | მოძიებადი მოვლენა თავდაპირველი კონტექსტით |
| აღდგენა | სერვისის დამოკიდებულებები, ასლები და აღდგენის გზა | სავარჯიშოს შედეგი |
შეათანხმეთ ვინაობა და დატვირთვების ავტორიზაციის მონაცემები
ღრუბლოვან როლებზე წვდომა ცენტრალური ვინაობით მიანიჭეთ და თითო პროვაიდერის როლების, ჯგუფებისა და ნდობის პოლიტიკების შესაბამისობა აღრიცხეთ. ადამიანთა ანგარიშები, დატვირთვათა ვინაობები, CI/CD დავალებები და ანგარიშებს შორის როლის მიღება ცალკე განიხილეთ. უპირატესობა დროებით ავტორიზაციის მონაცემებს მიანიჭეთ; თუ სტატიკური გასაღები საჭიროა, განსაზღვრეთ მფლობელი, შენახვის ადგილი, მიზანი და გაუქმების თარიღი. ნუ ჩათვლით, რომ ერთ სამუშაო ვინაობას ყველა პროვაიდერთან ერთი ნებართვები აქვს.
გააერთიანეთ ხილვადობა და მონაცემთა კონტროლი
პროვაიდერის ჟურნალები საერთო ანალიზში გაგზავნეთ, მათი წყაროსა და პროვაიდერის სპეციფიკური ველების შენარჩუნებით, რათა გამოძიებამ კონტექსტი არ დაკარგოს. კონფიგურაციის წესები ყველა ანგარიშში, გამოწერასა და პროექტში გამოსცადეთ; გამონაკლისებს მფლობელი და ვადა მიანიჭეთ. თითო მონაცემთა გზისა და სერვისისთვის განიხილეთ დაშიფვრა, გასაღებების მართვა, ასლები და რეგიონული შეზღუდვები. ნუ ჩათვლით, რომ ერთი პროვაიდერის უსაფრთხოების ხელსაწყო სხვა ღრუბელში მუშაობს ან ყველა რესურსს ავტომატურად მოიცავს.
გამოსცადეთ პროვაიდერებს შორის რეაგირება და აღდგენა
ინციდენტის გეგმაში შეინარჩუნეთ პლატფორმის სპეციფიკური ნაბიჯები კომპრომეტირებული ანგარიშის წვდომის ფარგლებში შესაზღუდად, როლთა ნებართვების შესამცირებლად, ჟურნალების ექსპორტისთვის, ქსელური წვდომის შესაზღუდად და პროვაიდერის მხარდაჭერასთან დასაკავშირებლად. ერთ ღრუბელში სიგნალმა სხვა გარემოებზე გავრცელებული შეტევა შეიძლება ვერ გამოავლინოს, ამიტომ ინციდენტის ხელმძღვანელსა და პლატფორმის სპეციალისტებს შორის კოორდინაციაში ივარჯიშეთ. აღდგენის ტესტები ანგარიშისა და სერვისის მიხედვით გამოყავით და მონაცემთა გადაცემა და აპლიკაციის დამოკიდებულებები გადაამოწმეთ. პოლიტიკისა თუ ავტომატიზაციის ცვლილებისას ტესტები განაახლეთ. შეინარჩუნეთ მტკიცებულებების შეგროვება და აღდგენის წვდომა.
დაიცავით API‑ები და ღრუბლებს შორის მონაცემთა ნაკადები
ღრუბლებს შორის აპლიკაციური კავშირებისთვის შეამოწმეთ, რომელი ვინაობა ასრულებს მოთხოვნას და რა მონაცემის წაკითხვა ან შეცვლა შეუძლია. API ავთენტიფიკაცია, ავტორიზაციის შემოწმება, საიდუმლოს როტაცია, სიხშირის შეზღუდვა და აუდიტის აღრიცხვა აპლიკაციის რისკს მოარგეთ. დაადასტურეთ სენსიტიური მონაცემების შენახვისა და რეპლიკაციის ადგილი; რესურსის ღრუბლებს შორის გადატანა იურიდიულ ან სახელშეკრულებო შესაბამისობას თავისთავად არ ადგენს.