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