ბიზნესის უწყვეტობა და ავარიული აღდგენა

9.1 მიმოხილვა და მიზანი

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

მიმწოდებლის ბიზნესის უწყვეტობის მართვის სისტემა (BCMS) შესაბამისობაშია ISO 22301:2019-თან (უსაფრთხოება და მდგრადობა — ბიზნესის უწყვეტობის მართვის სისტემები) და ეყრდნობა NIST SP 800-34 Rev. 1-ს (Contingency Planning Guide for Federal Information Systems) და Microsoft Cloud Enterprise Business Continuity Management (EBCM) პროგრამას. წინამდებარე თავი ავსებს მე-3 თავში (მომსახურების დონის შეთანხმება (SLA)) განსაზღვრულ ხელმისაწვდომობის ვალდებულებებს, მე-8 თავში (ინფორმაციული უსაფრთხოება და კონფიდენციალურობა) აღწერილ ინფრასტრუქტურის უსაფრთხოების კონტროლებს და მე-7 თავის (მონაცემთა დაცვა და კონფიდენციალურობა) მონაცემთა დაცვის დებულებებს.

თითოეული კლიენტის გამოყოფილი კერძო სუვერენული გარემო უზრუნველყოფილია უწყვეტობის მრავალფენოვანი (defence-in-depth) კონტროლებით, რომლებიც მოიცავს გამოთვლითი რესურსების, მონაცემთა ბაზის, საცავისა და ქსელის დონეებს — რაც უზრუნველყოფს, რომ არც ერთმა წერტილის მწყობრიდან გამოსვლამ არ გამოიწვიოს მონაცემთა დაკარგვა ან მომსახურების ხანგრძლივი შეწყვეტა შეთანხმებული აღდგენის წერტილის მიზნის (RPO) და აღდგენის დროის მიზნის (RTO) ფარგლებს გარეთ.

9.2 მოქმედების სფერო

წინამდებარე თავი მოიცავს:

• (a) აღდგენის მიზნებს: პლატფორმის ყველა დონისთვის სახელშეკრულებოდ სავალდებულო RPO და RTO ვალდებულებები.
• (b) რეზერვირების მართვას: რეზერვირების გრაფიკები, შენახვის ვადები, მთლიანობის გადამოწმება და აღდგენის პროცედურები ვირტუალური მანქანებისთვის, მონაცემთა ბაზებისთვის და აპლიკაციის არტეფაქტებისთვის.
• (c) მონაცემთა ზედმეტობასა და რეპლიკაციას: Azure Storage-ის რეპლიკაციის ვარიანტები (LRS, ZRS, GRS), მონაცემთა ბაზის წაკითხვის რეპლიკები და გეორეზერვირებული გადართვის არქიტექტურა.
• (d) ავარიულ აღდგენას: გადართვის პროცედურები, მეორადი რეგიონის აქტივაცია, კომუნიკაციის პროტოკოლები და მომსახურების აღდგენის პროცესები.
• (e) ბიზნესის უწყვეტობის დაგეგმვას: ბიზნესზე ზეგავლენის ანალიზი (BIA), უწყვეტობის გეგმის შენარჩუნება, DR სავარჯიშოების გრაფიკები და ინციდენტის შემდგომი განხილვის პროცედურები.
• (f) მონაცემებზე საკუთრობასა და გადატანადობას: კლიენტის უფლებები მონაცემებზე საკუთრობის შესახებ, მონაცემთა ექსპორტის მექანიზმები, ჩანაწერების მართვის ვალდებულებები და e-discovery-ს მხარდაჭერა.
• (g) როლებსა და პასუხისმგებლობებს: RACI-ს განაწილება მიმწოდებლისა და კლიენტის ორგანიზაციებს შორის BCDR-ის ყველა საქმიანობისთვის. წინამდებარე თავი არ მოიცავს აპლიკაციის დონის უსაფრთხოების კონტროლებს (იხ.მე-8 თავი), პერსონალური მონაცემების დამუშავებას (იხ. მე-7 თავი) ან ოპერაციული მხარდაჭერის პროცესებს (იხ. მე-4 თავი).

9.3 სტანდარტებთან და ჩარჩოებთან შესაბამისობა

მიმწოდებლის BCDR პროგრამა შესაბამისობაშია შემდეგ საერთაშორისოდ აღიარებულ სტანდარტებთან და ჩარჩოებთან:

9.4 აღდგენის მიზნები

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

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

Azure SQL Database-ის ბიზნესის უწყვეტობის მიმოხილვა

9.5 რეზერვირების მართვა

მიმწოდებელი ინარჩუნებს რეზერვირების ყოვლისმომცველ რეჟიმს, რომელიც მოიცავს თითოეული კლიენტის გამოყოფილი კერძო სუვერენული გარემოს ყველა კომპონენტს. რეზერვირების ოპერაციები სრულდება Azure Backup-ისა და SQL Server-ის ჩაშენებული რეზერვირების შესაძლებლობების გამოყენებით.

9.5.1 რეზერვირების გრაფიკი და შენახვა

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

Azure Backup-ის მიმოხილვა SQL Server-ის რეზერვირება Azure-ში

9.5.2 რეზერვო ასლების მთლიანობის გადამოწმება

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

• (a) საკონტროლო ჯამის ავტომატური ვალიდაცია: რეზერვირების ყოველი ოპერაცია ქმნის კრიპტოგრაფიულ საკონტროლო ჯამს (SHA-256). საკონტროლო ჯამი ავტომატურად მოწმდება დასრულებისას და აღირიცხება რეზერვირების აუდიტის კვლში.
• (b) აღდგენის ყოველთვიური ტესტი: კალენდარულ თვეში სულ მცირე ერთხელ მიმწოდებელი ახორციელებს შემთხვევით შერჩეული მონაცემთა ბაზის რეზერვო ასლის სატესტო აღდგენას იზოლირებულ გარემოში და ამოწმებს მონაცემთა სისრულეს, რეფერენციულ მთლიანობასა და აპლიკაციური დონის ფუნქციონალს.
• (c) სრული სტეკის აღდგენის კვარტლური სავარჯიშო: კალენდარულ კვარტალში სულ მცირე ერთხელ მიმწოდებელი ახორციელებს პლატფორმის სრულ აღდგენას (VM + მონაცემთა ბაზა + აპლიკაცია + კონფიგურაცია) იზოლირებულ გარემოში ავარიული აღდგენის სრული სცენარის სიმულაციით. შედეგები დოკუმენტირდება DR სავარჯიშოს ანგარიშში.
• (d) რეზერვირების მონიტორინგი და გაფრთხილება: Azure Monitor-ის გაფრთხილებები კონფიგურირებულია ისე, რომ რეზერვირების ნებისმიერი წარუმატებლობის, დროის ამოწურვის ან მთლიანობის შემოწმების წარუმატებლობის შემთხვევაში 15 წუთში აცნობონ მიმწოდებლის Cloud Operations გუნდს. წარუმატებელი რეზერვირება 1 საათში ავტომატურ განმეორებით მცდელობას იწვევს.

9.6 მონაცემთა ზედმეტობა და რეპლიკაცია

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

ნაგულისხმევად, თითოეული კლიენტის Azure Storage ანგარიში იქმნება გეორეზერვირებული საცავით (GRS), რომელიც კლიენტის მონაცემების ექვს ასლს ინახავს — სამს ძირითად Azure რეგიონში და სამს გეოგრაფიულად წყვილის მეორად რეგიონში. ძირითადი რეგიონის მწყობრიდან გამოსვლის შემთხვევაში Azure Storage ავტომატურად გადადის მეორად რეგიონზე, რაც მონაცემთა მდგრადობას უზრუნველყოფს ხელის ჩარევის გარეშე.

Azure Storage-ის ზედმეტობა

9.6.1 მონაცემთა ბაზის რეპლიკაცია

თითოეული კლიენტის გარემოში SQL Server 2022-ის მონაცემთა ბაზები მხარს უჭერს რეპლიკაციის შემდეგ კონფიგურაციებს:

• (a) სტანდარტული კონფიგურაცია: ყოველდღიური სრული რეზერვირება 7-დღიანი შენახვით, GRS-ში. ტრანზაქციების ჟურნალები რეზერვდება კონფიგურირებული გრაფიკის შესაბამისად (ნაგულისხმევი: ყოველსაათში; გაუმჯობესებული DR: ყოველ 15 წუთში).
• (b) გაუმჯობესებული DR კონფიგურაცია (არჩევითი): იქმნება SQL Server-ის მეორადი ინსტანსი კლიენტის ყველა მონაცემთა ბაზის მხოლოდ წაკითხვის რეპლიკებით. მაღალი სიხშირის ჟურნალების გადაცემა (log shipping, არაუმეტეს 15-წუთიანი ინტერვალით) უზრუნველყოფს მონაცემთა სინქრონიზაციას რეალურ დროსთან მიახლოებულ რეჟიმში. ძირითადი სერვერის მწყობრიდან გამოსვლის შემთხვევაში მეორადი სერვერი ავტომატურად იღებს ძირითადის როლს და უზრუნველყოფს უწყვეტობას მონაცემთა მინიმალური დაკარგვით (RPO ≤ 15 წუთი) და სწრაფი აღდგენით (RTO ≤ 1 საათი).
• (c) მონაცემთა ადგილმდებარეობის მოთხოვნების დაცვა: მონაცემთა რეპლიკაცია შეზღუდულია კლიენტის მიერ შერჩეული გეოგრაფიული რეგიონით, გარდა იმ შემთხვევისა, როდესაც კლიენტი წერილობით პირდაპირ უფლებამოსილებს რეგიონებს შორის რეპლიკაციას. მონაცემების გადაცემა შერჩეული გეოგრაფიული არეალის ფარგლებს გარეთ კლიენტის თანხმობის გარეშე არ ხდება, GDPR-ის 44-ე მუხლისა და UAE PDPL-ის 22-ე მუხლის საერთაშორისო გადაცემის მოთხოვნების შესაბამისად (იხ. თავი 7, §7.14).

9.7 ავარიული აღდგენის პროცედურები

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

9.7.1 ინციდენტების კლასიფიკაცია და ესკალაცია

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

9.7.2 გადართვის (failover) პროცედურები

DR-1 ან DR-2 მოვლენის გამოცხადებისას თანმიმდევრულად სრულდება გადართვის შემდეგი პროცედურები:

9.7.3 მეორად რეგიონზე გადართვა

თუ ძირითადი Azure რეგიონი Microsoft-ის ან მიმწოდებლის CTO-ს მიერ აღდგენისთვის შეუძლებლად ცხადდება, მიმწოდებელი ახორციელებს სრულ გადართვას მეორად რეგიონზე — გეოგრაფიულად წყვილის Azure რეგიონზე. ეს პროცედურა მოიცავს:

• (a) GRS გადართვის ინიცირება: Azure Storage ავტომატურად გადადის მეორად რეგიონზე. RA-GRS ანგარიშები უზრუნველყოფს რეპლიკირებულ მონაცემებზე წაკითხვის დაუყოვნებლივ წვდომას.
• (b) VM-ების ხელახალი შექმნა: მეორად რეგიონში ახალი ვირტუალური მანქანები იქმნება უახლოესი Azure Backup საცავიდან (ჩართულია რეგიონებს შორის აღდგენა).
• (c) მონაცემთა ბაზის აღდგენა: SQL Server-ის მონაცემთა ბაზები აღდგება გეორეზერვირებული რეზერვო ასლებიდან ან, გაუმჯობესებული DR-ის შემთხვევაში, წყვილის რეგიონში მდებარე მეორადი წაკითხვის რეპლიკის სერვერიდან.
• (d) DNS-ის ხელახალი კონფიგურაცია: Azure Traffic Manager ან DNS ჩანაწერები ისე იცვლება, რომ კლიენტის მთელი ტრაფიკი მიმართოს მეორადი რეგიონის წერტილებზე.
• (e) ვალიდაცია და გამოცხადება: მეორადი რეგიონიდან მომსახურების აღდგენის გამოცხადებამდე სრულდება აპლიკაციის გადამოწმების სრული ტესტების კრებული. მეორად რეგიონზე სრული გადართვის სამიზნე RTO შეადგენს 24 საათს ძირითადი რეგიონის შესახებ გამოცხადების მომენტიდან. გადართვის პროცედურის დროს კლიენტი ინფორმირდება მინიმუმ ყოველ 2 საათში შეთანხმებული საკომუნიკაციო არხის მეშვეობით.

Azure-ის რეგიონებს შორის ავარიული აღდგენა

9.8 ბიზნესის უწყვეტობის დაგეგმვა

9.8.1 ბიზნესზე ზეგავლენის ანალიზი (BIA)

მიმწოდებელი ინახავს ProjectVIEW ERP პლატფორმის ბიზნესზე ზეგავლენის ანალიზს, რომელიც ავლენს კრიტიკულ ბიზნეს-პროცესებს, ასახავს მათ დამოკიდებულებას პლატფორმის კომპონენტებზე და აფასებს მომსახურების შეფერხების ზეგავლენას. BIA გადაიხედება და ახლდება:

• (a) სულ მცირე წელიწადში ერთხელ, BCMS-ის მენეჯმენტის გადახედვის ციკლის ფარგლებში.
• (b) პლატფორმის არქიტექტურის, Azure რეგიონის კონფიგურაციის ან კლიენტის განთავსების ტოპოლოგიის ნებისმიერი არსებითი ცვლილების შემდეგ.
• (c) ნებისმიერი DR-1 ან DR-2 ინციდენტის შემდეგ, რომელიც არსებულ BIA-ში ხარვეზებს ავლენს.

BIA ეყრდნობა აღდგენის მიზნების (RPO/RTO) კალიბრაციას, რეზერვირების სიხშირის შესახებ გადაწყვეტილებებს და თითოეული კლიენტის გარემოსთვის რეპლიკაციის არქიტექტურის დიზაინს.

9.8.2 ბიზნესის უწყვეტობის გეგმა (BCP)

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

• (a) კრიზისული მართვის გუნდის (CMT) შემადგენლობას: CTO (ინციდენტის მეთაური), Cloud Operations-ის ხელმძღვანელი, DBA-ის ხელმძღვანელი, კლიენტის ანგარიშის მენეჯერი და კომუნიკაციების ხელმძღვანელი.
• (b) კომუნიკაციის გეგმას: კლიენტის შეტყობინების წინასწარ განსაზღვრულ შაბლონებს (პირველადი გაფრთხილება, პროგრესის განახლება, გადაჭრის შეტყობინება, PIR-ის გავრცელება), შიდა ესკალაციის მატრიცებსა და მომწოდებლების საკონტაქტო რეესტრებს (Microsoft Azure Support, დომენის რეგისტრატორები, SSL პროვაიდერები).
• (c) რესურსების ინვენტარს: თითოეული კლიენტის გარემოს ყველა Azure რესურსის (VM-ები, SQL ინსტანსები, საცავის ანგარიშები, ქსელური კომპონენტები, Key Vault-ის საიდუმლოებები) დოკუმენტირებულ ინვენტარს, რომელიც ინახება CMDB-ში და მოწმდება კვარტლურად.
• (d) ალტერნატიული ლოკაციის პროცედურებს: მეორადი Azure რეგიონის აქტივაციის ეტაპობრივ პროცედურებს, მათ შორის წინასწარ მომზადებულ ინფრასტრუქტურულ შაბლონებს (Azure Resource Manager / Bicep) და განთავსების ავტომატიზებულ სკრიპტებს.
• (e) მომწოდებლების უწყვეტობას: მესამე მხარეზე კრიტიკული დამოკიდებულებების (Microsoft Azure-ის SLA ვალდებულებები, დომენის რეგისტრატორები, სერტიფიცირების ცენტრები) შეფასებას და თითოეულისთვის გადაუდებელი სიტუაციების ზომებს.

9.8.3 DR სავარჯიშოების პროგრამა

მიმწოდებელი რეგულარულად ატარებს DR სავარჯიშოებს BCDR გეგმის ეფექტურობის დასადასტურებლად და ოპერაციული მზადყოფნის უზრუნველსაყოფად:

სავარჯიშოების ყველა შედეგი დოკუმენტირდება, ინახება მინიმუმ სამი (3) წლის განმავლობაში და კლიენტს წერილობითი მოთხოვნის შემთხვევაში წარედგინება. თუ სავარჯიშო ავლენს შეთანხმებული RPO/RTO მიზნებიდან გადახრას, მიმწოდებელი ოცდაათი (30) კალენდარული დღის განმავლობაში ახორციელებს გამოსწორებით ქმედებებს და იმეორებს შესაბამის სავარჯიშოს გამოსწორების დასადასტურებლად.

9.9 კლიენტის მონაცემებზე საკუთრობა და გადატანადობა

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

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

9.9.1 მონაცემთა ექსპორტი და გადატანადობა

მიმწოდებელი კლიენტის მონაცემებს ექსპორტისთვის ხელმისაწვდომს ხდის შემდეგნაირად:

• (a) ექსპორტი მოთხოვნისამებრ: კლიენტს შეუძლია გამოწერის ვადის ნებისმიერ დროს მოითხოვოს კლიენტის მონაცემების სრული ან ნაწილობრივი ექსპორტი. მიმწოდებელი ექსპორტს წარადგენს სათანადო წერილობითი მოთხოვნის მიღებიდან ორი (2) სამუშაო დღის განმავლობაში, მანქანისთვის წაკითხვად, ინდუსტრიულად სტანდარტულ ფორმატში (SQL რეზერვო ფაილი, CSV, JSON ან XML, შეთანხმების შესაბამისად).
• (b) ექსპორტი შეწყვეტისას: ჩარჩოს ვადის გასვლის ან შეწყვეტისას მიმწოდებელი კლიენტის წერილობითი მოთხოვნიდან ორი (2) სამუშაო დღის განმავლობაში კლიენტის ყველა მონაცემს ექსპორტისთვის ხელმისაწვდომს ხდის თავი 7, §7.13-ის (მონაცემთა დაბრუნება შეწყვეტისას) მონაცემთა დაბრუნების დებულებების შესაბამისად. ექსპორტის საერთო პერიოდი ღია რჩება შეწყვეტის ძალაში შესვლის თარიღიდან მინიმუმ სამოცი (60) კალენდარული დღის განმავლობაში.
• (c) აუდიტისა და შესაბამისობის ექსპორტი: კლიენტს შეუძლია შესაბამისობის მიზნებისთვის მოითხოვოს აუდიტის ჟურნალები, წვდომის ჟურნალები და ცვლილებების აღრიცხვის ჩანაწერები. ასეთი ექსპორტი წარდგენილი იქნება წერილობითი მოთხოვნიდან ორი (2) სამუშაო დღის განმავლობაში.

9.9.2 ჩანაწერების მართვა

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

• (a) შენახვის კონფიგურირებადი პოლიტიკა: პლატფორმა აპლიკაციის დონეზე მხარს უჭერს მონაცემთა შენახვის კონფიგურირებად წესებს, რაც კლიენტს საშუალებას აძლევს, განსაზღვროს შენახვის ვადები ჩანაწერების სხვადასხვა კატეგორიისთვის.
• (b) აუდიტის კვლის შენახვა: Azure Storage-ის შენახვის პოლიტიკა და SQL Server-ის ცვლილებების აღრიცხვა უზრუნველყოფს უცვლელ აუდიტის კვალს მონაცემთა ყველა ცვლილებისთვის. აუდიტის ჩანაწერები ინახება კომერციულ ხელშეკრულებაში შეთანხმებული მინიმალური ვადის განმავლობაში (ნაგულისხმევი: შვიდი წელი).
• (c) ექსპორტი გარე არქივირებისთვის: კლიენტს შეუძლია გამოწერის ვადის ნებისმიერ დროს გარე არქივირებისთვის ექსპორტი გაუკეთოს მონაცემებსა და აუდიტის ანგარიშებს. მიმწოდებელი წერილობითი მოთხოვნის საფუძველზე ხელს უწყობს სტანდარტულ ფორმატებში მასობრივ ექსპორტს.

9.9.3 ელექტრონული მტკიცებულებების გამოვლენა (e-Discovery)

პლატფორმის გამოყენებისას e-discovery-ს მოთხოვნების დაცვაზე პასუხისმგებელია კლიენტი. მიმწოდებელი მხარს უჭერს კლიენტის e-discovery ვალდებულებებს შემდეგი გზით:

• (a) მონაცემთა შენახვის ბლოკირება (preservation hold): კლიენტის წერილობითი მოთხოვნის საფუძველზე, რომელიც ეყრდნობა სასამართლო დავის გამო შენახვის (litigation hold) ან მარეგულირებელი გამოძიების მოთხოვნას, მიმწოდებელი აწესებს შენახვის ბლოკირებას კლიენტის მითითებულ მონაცემებზე და აჩერებს ავტომატურ წაშლასა და შენახვის პოლიტიკის აღსრულებას შესაბამისი მონაცემთა კრებულებისთვის.
• (b) მონაცემთა ექსპორტი e-discovery-სთვის: მიმწოდებელი შენახვის ბლოკირების მოთხოვნიდან ორი (2) სამუშაო დღის განმავლობაში ახდენს მითითებული მონაცემთა კრებულების ექსპორტს და მიწოდებას e-discovery განხილვისთვის ვარგის ფორმატში (მეტამონაცემებისა და აუდიტის კვლის ჩათვლით).
• (c) სამფლობელოს ჯაჭვის (chain-of-custody) დოკუმენტაცია: მიმწოდებელი e-discovery-ს ყველა ექსპორტისთვის წარადგენს სამფლობელოს ჯაჭვის დოკუმენტაციას, რომელიც ადასტურებს ექსპორტირებული მონაცემების სისრულესა და მთლიანობას.

9.10 Azure პლატფორმის მდგრადობა

მიმწოდებელი თითოეული კლიენტის გამოყოფილ კერძო სუვერენულ გარემოში იყენებს Azure-ის შემდეგ ჩაშენებულ მდგრადობის შესაძლებლობებს:

• (a) ხელმისაწვდომობის ზონები (Availability Zones): იქ, სადაც ეს ხელმისაწვდომია კლიენტის მიერ არჩეულ Azure-ის რეგიონში, კრიტიკული რესურსები (ვირტუალური მანქანები, მართვადი დისკები, დატვირთვის ბალანსერები) რამდენიმე ხელმისაწვდომობის ზონაშია განთავსებული, რათა დაცული იყოს ერთი ზონის მწყობრიდან გამოსვლისგან.
• (b) Azure Resource Health: აკონტროლებს ვირტუალური მანქანების მდგომარეობას და ამოწმებს, მუშაობს თუ არა რესურსები მოსალოდნელი რეჟიმით, ავლენს Azure პლატფორმის ცნობილ პრობლემებს, რომლებიც არსებულ რესურსებზე ახდენს გავლენას. გაფრთხილებები Azure Monitor-ის მეშვეობით ეგზავნება ღრუბლოვანი ოპერაციების გუნდს.
• (c) Azure Backup Vault: რეზერვირების ცენტრალიზებული მართვა რეგიონთაშორისი აღდგენის შესაძლებლობით, „რბილი წაშლისგან“ (soft-delete) დაცვით (14 დღე) და რეზერვული ასლების წაშლის კრიტიკული ოპერაციებისთვის მრავალმომხმარებლიანი ავტორიზაციით.
• (d) Azure Resource Locks: ყველა საწარმოო რესურსზე გამოიყენება CanNotDelete და ReadOnly ბლოკირებები, რათა თავიდან იქნეს აცილებული კრიტიკული ინფრასტრუქტურის კომპონენტების შემთხვევითი ან ბოროტზრახული წაშლა ან შეცვლა.
• (e) Azure DDoS Protection: კლიენტის ყველა ვირტუალურ ქსელზე ჩართულია Standard დონის DDoS დაცვა, რომელიც უზრუნველყოფს შეტევების ავტომატურ შერბილებას რეალურ დროში ტელემეტრიითა და შეტევის შემდგომი ანგარიშგებით.
• (f) Azure Key Vault: დაშიფვრის გასაღებები, საიდუმლოებები და სერტიფიკატები ინახება Azure Key Vault-ში ჩართული „რბილი წაშლით“ (soft-delete) და საბოლოო წაშლისგან დაცვით (purge protection), რაც უზრუნველყოფს კრიპტოგრაფიული მასალის აღდგენადობას შემთხვევითი წაშლის შემთხვევაშიც კი.

Azure Availability Zones Overview Azure Resource Health Overview Azure Backup Architecture

9.11 კლიენტის პასუხისმგებლობები

კლიენტი აღიარებს და ეთანხმება შემდეგ პასუხისმგებლობებს BCDR პროგრამის მხარდასაჭერად:

• (a) საკონტაქტო პირების დანიშვნა: კლიენტი ნიშნავს და ინარჩუნებს მინიმუმ ორ (2) უფლებამოსილ საკონტაქტო პირს ავარიულ აღდგენასთან დაკავშირებული კომუნიკაციისთვის, მათ შორის სამუშაო საათების შემდეგ საგანგებო საკონტაქტო მონაცემებით. საკონტაქტო მონაცემები განახლდება პერსონალის ნებისმიერი ცვლილებიდან ხუთი (5) სამუშაო დღის განმავლობაში.
• (b) ავარიული აღდგენის სწავლებებში მონაწილეობა: კლიენტი გონივრულ ძალისხმევას იჩენს, რათა მონაწილეობა მიიღოს მეორად რეგიონზე გადართვის ყოველწლიურ სწავლებებსა და კვარტალურ სამაგიდო სწავლებებში (Tabletop Exercises) და წარმოადგინოს უკუკავშირი კომუნიკაციის ეფექტიანობისა და ბიზნესზე გავლენის შეფასების სიზუსტის შესახებ.
• (c) შენახვის პოლიტიკის განსაზღვრა: კლიენტი ჩართვის (onboarding) ეტაპზე წერილობით განსაზღვრავს მონაცემთა შენახვის მოთხოვნებს და საჭიროებისამებრ ანახლებს მათ. მიმწოდებელი შესაბამისად აკონფიგურირებს პლატფორმის შენახვის პოლიტიკებს.
• (d) მონაცემთა ექსპორტის ვალიდაცია: მონაცემთა ნებისმიერი ექსპორტის ოპერაციის (მოთხოვნისამებრ ან შეწყვეტისას) შემდეგ კლიენტი შეთანხმებულ ვალიდაციის ვადაში ამოწმებს ექსპორტირებული მონაცემების სისრულესა და მთლიანობას. თუ ვალიდაციის ვადაში მონაცემთა სისრულესთან დაკავშირებით პრეტენზია არ იქნება წარდგენილი, ეს ჩაითვლება ექსპორტის მიღებად.
• (e) საბოლოო მომხმარებლების უწყვეტობის დაგეგმვა: კლიენტი პასუხისმგებელია საკუთარი შიდა ბიზნესის უწყვეტობის დაგეგმვაზე, მათ შორის საბოლოო მომხმარებლებთან კომუნიკაციაზე, ხელით შესრულებად სარეზერვო პროცესებზე და შიდა სისტემების დამოკიდებულებებზე, რომლებიც პლატფორმის ფარგლებს მიღმაა.

9.12 უწყვეტი გაუმჯობესება

მიმწოდებლის BCDR პროგრამა ექვემდებარება უწყვეტი გაუმჯობესების ციკლს, რომელიც შესაბამისობაშია ISO 22301:2019-ით განსაზღვრულ Plan-Do-Check-Act (PDCA) მეთოდოლოგიასთან:

• (a) დაგეგმვა (Plan): BIA-ს ყოველწლიური გადახედვა, აღდგენის მიზნების კალიბრაცია და BCDR გეგმის განახლება პლატფორმის, Azure-ის შესაძლებლობებისა და კლიენტის მოთხოვნების ცვლილებების საფუძველზე.
• (b) შესრულება (Do): რეზერვირების გრაფიკების, რეპლიკაციის კონფიგურაციებისა და ავარიული აღდგენის სწავლებების პროგრამის შესრულება წინამდებარე თავის შესაბამისად.
• (c) შემოწმება (Check): რეზერვირების წარმატების მაჩვენებლების, ავარიული აღდგენის სწავლებების შედეგების (გაზომილი RPO/RTO სამიზნე მნიშვნელობებთან შედარებით), ინციდენტის შემდგომი განხილვებისა და კლიენტის უკუკავშირის მონიტორინგი.
• (d) მოქმედება (Act): შემოწმების ფაზაში გამოვლენილი მაკორექტირებელი ქმედებების, არქიტექტურული გაუმჯობესებებისა და პროცედურების დახვეწილების დანერგვა. ყველა გაუმჯობესება აღირიცხება BCDR გაუმჯობესებების რეესტრში და მოხსენდება მომსახურების კვარტალურ განხილვაზე (იხ. თავი 4, §4.12).

9.13 პროგრამული უზრუნველყოფის უვადო გარანტია

მიმწოდებელი იძლევა გარანტიას, რომ პლატფორმა გამოწერის ვადისა და მისი ნებისმიერი განახლების მთელი პერიოდის განმავლობაში („ საგარანტიო პერიოდი “):

• (a) შესაბამისობა: არსებითად იმუშავებს წინამდებარე ჩარჩოსა და შესაბამის კომერციულ ხელშეკრულებაში აღწერილი სპეციფიკაციების, ფუნქციონალისა და მომსახურების დონეების შესაბამისად;
• (b) დეფექტების აღმოფხვრა: თავისუფალი იქნება არსებითი დეფექტებისგან, რომლებიც კლიენტს ხელს უშლის პლატფორმის გამოყენებაში მისი ბიზნესმიზნებისთვის. ნებისმიერ დადასტურებულ დეფექტს მიმწოდებელი აღმოფხვრის კლიენტისთვის დამატებითი ღირებულების გარეშე, მე-3 თავში განსაზღვრული SLA-ს რეაგირებისა და გადაწყვეტის სამიზნე ვადებში;
• (c) ვერსიის აქტუალურობა: დაფუძნებული იქნება ამჟამად მხარდაჭერილ და შენარჩუნებულ ტექნოლოგიურ სტეკზე. მიმწოდებელი საკუთარი ინიციატივით ახლებს ყველა საბაზისო COTS კომპონენტს (მონაცემთა ბაზის ძრავა, აპლიკაციის ფრეიმვორკი, ოპერაციული სისტემა, შუალედური პროგრამული უზრუნველყოფა) მწარმოებლის მიერ მხარდაჭერილ ვერსიებამდე 4.7 ქვეთავში განსაზღვრული რელიზების ციკლის ფარგლებში;
• (d) უსაფრთხოების მხარდაჭერა: საგარანტიო პერიოდის მანძილზე მიიღებს უსაფრთხოების უწყვეტ განახლებებს (patching), მათ შორის კრიტიკული და მაღალი დონის მოწყვლადობების აღმოფხვრას მე-8 თავში განსაზღვრულ ვადებში;
• (e) გაუარსების დაუშვებლობა: ინარჩუნებს წარმადობის მახასიათებლებს, რომლებიც შეესაბამება ან აჭარბებს წინამდებარე ჩარჩოთი განსაზღვრულ SLO-სა და აღდგენის მიზნების (RPO/RTO) მნიშვნელობებს. მიმწოდებელი კლიენტის თანხმობის გარეშე არ შეიტანს ცვლილებებს, რომლებიც არსებითად აუარსებს პლატფორმის წარმადობას. ეს გარანტია არის უვადო გარანტია, რომლის მოქმედება ემთხვევა კლიენტის აქტიურ გამოწერას. იგი არ იწურება, არ იზღუდება ფარგლებში და არ საჭიროებს ცალკე განახლებას. გარანტია ძალაში რჩება მე-10 თავის შესაბამისად ვერსიებზე გადასვლისას და თანაბრად ვრცელდება მომდევნო ვერსიაზე მისი საერთო ხელმისაწვდომობის (General Availability) თარიღიდან.

გამონაკლისები: გარანტია არ ვრცელდება დეფექტებზე, რომლებიც გამოწვეულია (i) კლიენტის მიერ პლატფორმაში შეტანილი ცვლილებებით მიმწოდებლის ცვლილებების მართვის პროცესის გარეშე; (ii) პლატფორმის მისი დოკუმენტაციისაგან შეუსაბამო გამოყენებით; (iii) მესამე მხარის პროგრამული ან ტექნიკური უზრუნველყოფით, რომელიც მიმწოდებლის მიერ არ არის მოწოდებული ან დამტკიცებული; ან (iv) ფორს-მაჟორული მოვლენებით.

9.14 წყარო კოდის ესქროუ

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

9.14.1 ესქროუ დეპოზიტი

• (a) ესქროუ აგენტი: მიმწოდებელი ნიშნავს საიმედო, დამოუკიდებელ მესამე მხარე ესქროუ აგენტს („ესქროუ აგენტი“) პლატფორმის წყარო კოდის შესანახად. ესქროუ აგენტის ვინაობა კლიენტს მოთხოვნისამებრ ეცნობება.
• (b) დეპოზიტის შემადგენლობა: ესქროუ დეპოზიტი მოიცავს: (i) პლატფორმის სრულ წყარო კოდს; (ii) აწყობის სკრიპტებსა და კომპილაციის ინსტრუქციებს; (iii) მონაცემთა ბაზის სქემებსა და მიგრაციის სკრიპტებს; (iv) მესამე მხარის დამოკიდებულებების სიებსა და სალიცენზიო დოკუმენტაციას; (v) სისტემური არქიტექტურის დოკუმენტაციას; და (vi) განთავსების პროცედურებს, რომლებიც საკმარისია კომპეტენტური პროგრამული უზრუნველყოფის სპეციალისტისთვის პლატფორმის კომპილაციის, განთავსებისა და ექსპლუატაციისთვის.
• (c) განახლების სიხშირე: ესქროუ დეპოზიტი განახლდება ყოველი ძირითადი ვერსიის რელიზიდან (Upgrade) ოცდაათი (30) დღის განმავლობაში და ინკრემენტული რელიზებისთვის (Updates) საკალენდარო კვარტალში მინიმუმ ერთხელ.
• (d) ვერიფიკაცია: ესქროუ აგენტი ყოველწლიურად ამოწმებს დეპოზიტს, რათა დაადასტუროს მისი სისრულე და აწყობის შესაძლებლობა. ვერიფიკაციის შეჯამებითი სერტიფიკატი კლიენტს მოთხოვნისამებრ ეწვდება.

9.14.2 გაცემის პირობები

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

• (a) გადახდიუუნარობა: მიმწოდებელის მიმართ ნებისმიერ იურისდიქციაში იწყება ლიკვიდაციის, ადმინისტრირების, მმართველის დანიშვნის ან ნებისმიერი ანალოგიური გადახდიუუნარობის პროცედურა;
• (b) საქმიანობის შეწყვეტა: მიმწოდებელი წყვეტს სამეწარმეო საქმიანობას ან მისი საქმიანობის არსებით ნაწილს;
• (c) არსებითი დარღვევა: მიმწოდებელი არსებითად არღვევს წინამდებარე ჩარჩოს და დარღვევა კლიენტის წერილობითი შეტყობინებიდან სამოცი (60) დღის განმავლობაში არ აღიმოფხვრება;
• (d) მხარდაჭერის შეწყვეტა: მიმწოდებელი სამუდამოდ წყვეტს პლატფორმის მხარდაჭერას კომერციულად გონივრული მომდევნო პროდუქტის ან გადასვლის გზის უზრუნველყოფის გარეშე.

9.14.3 კლიენტის უფლებები გაცემის შემდეგ

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

9.14.4 ხარჯები

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

9.15 როლები და პასუხისმგებლობები (RACI მატრიცა)

შემდეგი RACI მატრიცა BCDR-ის ძირითადი საქმიანობებისთვის პასუხისმგებლობებს ანაწილებს მიმწოდებლისა და კლიენტის როლებს შორის:

ლეგენდა: R = შემსრულებელი (ახორციელებს საქმიანობას) · A = ანგარიშვალდებული (საბოლოო გადაწყვეტილების უფლებამოსილება) · C = კონსულტაცია (გადაწყვეტილებამდე წარმოადგენს მოსაზრებას) · I = ინფორმირებული (გადაწყვეტილების შემდეგ ეცნობება).

9.16 პროცესების რეესტრი

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

9.17 პროცესების ნაკადის სქემა

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

① BIA და რისკების შეფასება → ② BCP-სა და DR გეგმის შემუშავება → ③ რეზერვირებისა და რეპლიკაციის

კონფიგურაცია

↓

④ მონიტორინგი და გამოვლენა → ⑤ ინციდენტის კლასიფიკაცია და ესკალაცია → ⑥ გადართვისა და აღდგენის

შესრულება

↓

⑦ მომსახურების აღდგენა და ვერიფიკაცია → ⑧ ინციდენტის შემდგომი განხილვა და PIR → ⑨ უწყვეტი

გაუმჯობესება და სწავლებების პროგრამა

ეტაპი ① BIA და რისკების შეფასება: ბიზნესზე გავლენის ყოველწლიური ანალიზი ავლენს კრიტიკულ პროცესებს, ასახავს პლატფორმის დამოკიდებულებებს და რაოდენობრივად აფასებს შეფერხების გავლენას. აღდგენის პრიორიტეტების რანჟირება და RPO/RTO სამიზნე მნიშვნელობები კალიბრდება BIA-ს შედეგების საფუძველზე (P-9.01).

ეტაპი ② BCP-სა და DR გეგმის შემუშავება: ბიზნესის უწყვეტობის გეგმა და DR პროცედურები შეიქმნება ან განახლდება BIA-ს დასკვნების საფუძველზე და მოიცავს CMT-ს შემადგენლობას, კომუნიკაციის შაბლონებს, რესურსების ინვენტარს და მეორე რეგიონის აქტივაციის პროცედურებს (P-9.02).

ეტაპი ③ რეზერვირებისა და რეპლიკაციის კონფიგურაცია: რეზერვირების გრაფიკები, შენახვის პოლიტიკები და რეპლიკაციის არქიტექტურა (LRS/ZRS/GRS/RA-GRS) კონფიგურირდება კლიენტის თითოეული გარემოსთვის. გაფართოებული DR წაკითხვის რეპლიკები იქმნება არჩევის შემთხვევაში (P-9.03).

ეტაპი ④ მონიტორინგი და გამოვლენა: Azure Monitor, SIEM და Resource Health უწყვეტად აკონტროლებს პლატფორმის ყველა კომპონენტს. რეზერვირების დასრულება და მთლიანობა ავტომატურად მოწმდება, წარუმატებლობისას კი გაფრთხილება იგზავნება (P-9.04, P-9.05, P-9.06).

ეტაპი ⑤ ინციდენტის კლასიფიკაცია და ესკალაცია: გამოვლენილი ინციდენტები კლასიფიცირდება (DR-1-დან DR-4-მდე) და ესკალირდება სიმძიმის ტაქსონომიის შესაბამისად. კლიენტის ინფორმირების ვადები ამოქმედდება სიმძიმის დონის მიხედვით (P-9.07, P-9.08).

ეტაპი ⑥ გადართვისა და აღდგენის შესრულება: მონაცემთა ბაზის გადართვა, ვირტუალური მანქანების აღდგენა და აპლიკაციის ვერიფიკაცია თანმიმდევრულად სრულდება გადართვის პროცედურების ცხრილის შესაბამისად. მეორად რეგიონზე გადართვა აქტიურდება DR-1 მოვლენებისას, როდესაც ძირითადი რეგიონი აღუდგენელია (P-9.09–P-9.11, P-9.14).

ეტაპი ⑦ მომსახურების აღდგენა და ვერიფიკაცია: მომსახურება აღდგენილად ცხადდება აღდგენის ყველა ფაზის დასრულების შემდეგ. SLA-ს ათვლა განახლდება და 72 საათის განმავლობაში გაძლიერებული მონიტორინგი ხორციელდება. მოწმდება DNS/ქსელის გადართვა (P-9.12).

ეტაპი ⑧ ინციდენტის შემდგომი განხილვა და PIR: ძირეული მიზეზის ანალიზი ტარდება 5 სამუშაო დღის განმავლობაში. ინციდენტის შემდგომი ანგარიში კლიენტს წარედგინება მაკორექტირებელი ქმედებებით, BCDR გეგმის განახლებებითა და მიღებული გაკვეთილებით (P-9.13).

ეტაპი ⑨ უწყვეტი გაუმჯობესება და სწავლებების პროგრამა: DR სწავლებები (სამაგიდო, კომპონენტური, სრული სტეკის, რეგიონული) ტარდება განრიგის პროგრამის შესაბამისად. RPO/RTO სამიზნე მნიშვნელობებიდან გადახრები იწვევს მაკორექტირებელ ქმედებებს, რომლებიც აღირიცხება გაუმჯობესებების რეესტრში. PDCA ციკლი ბრუნდება ① ეტაპზე (P-9.15, P-9.18).