ინფორმაციული უსაფრთხოება და კონფიდენციალურობა

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

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

მიმწოდებლის ინფორმაციული უსაფრთხოების მართვის სისტემას (ISMS) წარმართავს IT დეპარტამენტი და იგი შესაბამისობაშია ISO/IEC 27001:2022-თან. წინამდებარე თავი ეხება უსაფრთხოების ტექნიკურ კონტროლებს, რომლებიც ავსებს მე-7 თავში (მონაცემთა დაცვა და კონფიდენციალურობა) აღწერილ კონფიდენციალურობის სპეციფიკურ ზომებს და მე-4 თავში (მომსახურების მხარდაჭერა და ოპერაციები) აღწერილ ოპერაციული მხარდაჭერის უსაფრთხოების ზომებს.

DANAOS Web Enterprise უსაფრთხოების მექანიზმებს აერთიანებს აპლიკაციური სტეკის ყველა დონეზე — წარდგენის დონიდან (ვებ-ბრაუზერი) აპლიკაციის დონის (აპლიკაციის სერვერი) გავლით მონაცემთა დონემდე (მონაცემთა ბაზის სერვერი) — რაც უზრუნველყოფს კონფიდენციალურობის, მთლიანობისა და ხელმისაწვდომობის (C.I.A. ტრიადა) ბოლომდე დაცვას თითოეული კლიენტის გამოყოფილ კერძო სუვერენულ გარემოში.

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

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

• (a) პლატფორმის აპლიკაციურ უსაფრთხოებას: აუთენტიფიკაცია, ავტორიზაცია, სესიის მართვა, შეყვანილი მონაცემების ვალიდაცია და უსაფრთხო კოდირების პრაქტიკები, რომლებიც ჩაშენებულია DANAOS Web Framework-ში.
• (b) ინფრასტრუქტურის უსაფრთხოებას: ქსელის სეგმენტაცია, ფაერვოლის კონფიგურაცია, შეჭრის აღმოჩენა, DDoS-ისგან დაცვა და ვებ-აპლიკაციების ფაერვოლის (WAF) კონტროლები, რომლებიც გამოიყენება თითოეული კლიენტის Azure-ზე განთავსებულ სუვერენულ გარემოზე.
• (c) მონაცემთა ბაზის უსაფრთხოებას: წვდომის კონტროლი, დაშიფვრა (შენახვისა და გადაცემის დროს), აუდიტის ჟურნალები, პრივილეგიების მართვა და კავშირების მონიტორინგი SQL Server-ის მონაცემთა ბაზის ინსტანსებისთვის.
• (d) ოპერაციულ უსაფრთხოებას: მოწყვლადობების მართვა, შეჭრის ტესტირება, პატჩების მართვა, ცვლილებების აღრიცხვა და უსაფრთხოების ინციდენტებზე რეაგირება (ინციდენტები, რომლებიც არ ეხება პერსონალურ მონაცემებს; პერსონალურ მონაცემთა უსაფრთხოების დარღვევები რეგულირდება §7.15-ით).
• (e) წყარო კოდის უსაფრთხოებას: ინტელექტუალური საკუთრების დაცვა, უსაფრთხო დეველოპმენტის სასიცოცხლო ციკლი, Git-ზე დაფუძნებული ვერსიების კონტროლი და კოდის განხილვის პრაქტიკები, რომლებიც არეგულირებს მიმწოდებლის საკუთრობაში არსებულ კოდს.
• (f) კონფიდენციალურობის ვალდებულებებს: ურთიერთო კონფიდენციალურობის ვალდებულებები, ინფორმაციის კლასიფიკაცია, გამოქვეყნების შეზღუდვები და შეწყვეტის შემდგომ ძალაში დარჩენილი დებულებები.

8.3 უსაფრთხოების სტანდარტები და ჩარჩოები

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

ISO/IEC 27001:2022 NIST CSF 2.0 OWASP Top 10 (2021) CIS Azure Foundations Benchmark NIST SP 800-63B Azure Well-Architected Framework

8.4 აპლიკაციის უსაფრთხოება

DANAOS ProjectVIEW ERP პლატფორმა სისტემის კონფიდენციალურობისა და მთლიანობის უზრუნველსაყოფად აპლიკაციის დონეზე აერთიანებს უსაფრთხოების შემდეგ მექანიზმებს. ეს კონტროლები გამოიყენება კლიენტის ყველა ინსტანსზე და კონფიგურირდება კლიენტის სისტემური ადმინისტრატორების მიერ STY (მომხმარებლებისა და როლების მართვა) მოდულის მეშვეობით.

8.4.1 აუთენტიფიკაციის კონტროლები

8.4.2 ავტორიზაცია და წვდომის კონტროლი

პლატფორმის მომხმარებლებისა და როლების მართვის მოდული (STY) ახორციელებს დეტალურ, როლზე დაფუძნებულ წვდომის კონტროლს (RBAC) რამდენიმე დონეზე:

• (a) მოდულის დონე: მომხმარებლებს როლის მიხედვით ეძლევათ ან ეზღუდებათ წვდომა მთლიან მოდულებზე (მაგ., PV_07 HRMS – სახელფასო აღრიცხვა, PV_08 ბუღალტრული აღრიცხვა).
• (b) ფუნქციის დონე: მოდულის ფარგლებში ცალკეულ ფუნქციებზე (მაგ., შესყიდვის შეკვეთის შექმნა, ინვოისის დამტკიცება, ხელფასის ნახვა) უფლებები დამოუკიდებლად ინიჭება.
• (c) ველის დონე: ჩანაწერში მგრძნობიარე ველები (მაგ., ხელფასის ოდენობა, საბანკო ანგარიში, პირადი ნომერი) შესაძლოა დაიმალოს ან მხოლოდ წაკითხვისთვის იყოს ხელმისაწვდომი კონკრეტული როლებისთვის.
• (d) ჩანაწერის დონე: სტრიქონის დონის უსაფრთხოება ზღუდავს ხილვადობას ორგანიზაციული იერარქიის მიხედვით (მაგ., პროექტის მენეჯერები ხედავენ მხოლოდ მათთვის განკუთვნილ პროექტებს; რეგიონული მენეჯერები — საკუთარ რეგიონს).
• (e) მოვალეობების გამიჯვნა: შეუთავსებელი როლების აღმოჩენა ხელს უშლის ერთ მომხმარებელს იქონიოს როლები, რომლებიც მოვალეობების გამიჯვნის კონფლიქტს ქმნის (მაგ., მოთხოვნის შემქმნელი და დამმტკიცებელი). STY მოდული ადმინისტრატორებს აცნობს აღმოჩენილი კონფლიქტების შესახებ და ამოქმედებს პოლიტიკაზე დაფუძნებულ შეზღუდვებს.
• (f) უნიკალური მომხმარებლის ID: თითოეულ მომხმარებლის ანგარიშს ენიჭება უნიკალური იდენტიფიკატორი. საერთო/ზოგადი ანგარიშები აკრძალულია. ყველა ქმედება აუდიტის კვლის მეშვეობით უკავშირდება კონკრეტულ მომხმარებელს.
• (g) შეზღუდული დისტანციური წვდომა: სისტემური ადმინისტრატორები თითოეული მომხმარებლისთვის აკონტროლებენ დისტანციურ წვდომას ადმინისტრატორის კონსოლიდან; წვდომის მიცემა ან გაუქმება შესაძლებელია ნებისმიერ დროს.

8.4.3 სესიის უსაფრთხოება

• (a) სესიის ტოკენები: აუთენტიფიკაციისას გენერირდება კრიპტოგრაფიულად შემთხვევითი სესიის ტოკენები. ტოკენები დაკავშირებულია მომხმარებლის IP მისამართთან და user-agent სტრიქონთან სესიის მიტაცების (session hijacking) თავიდან აცილების მიზნით.
• (b) სესიის გაუქმება: სესიები უქმდება: პაროლის შეცვლისას, ანგარიშის შეჩერებისას, ცხადი გასვლისას ან უმოქმედობის დროის ლიმიტის ამოწურვისას.
• (c) პარალელური სესიების კონტროლი: კონფიგურირებადი ლიმიტები ერთ მომხმარებლის ანგარიშზე პარალელურად აქტიურ სესიებზე. ნაგულისხმევი: ერთი აქტიური სესია თითო მომხმარებელზე (პოლიტიკა „ბოლო შესვლა იგებს“).

8.4.4 შეყვანილი მონაცემების ვალიდაცია და გამოსატანი მონაცემების კოდირება

• (a) სერვერის მხარეს ვალიდაცია: მომხმარებლის მიერ შეყვანილი ყველა მონაცემი სერვერის მხარეს მოწმდება თეთრ სიაზე (whitelist) დაფუძნებული ვალიდაციით. კლიენტის მხარეს ვალიდაცია განიხილება მხოლოდ გამოყენების სიმარტივის გაუმჯობესებად და არასოდეს — უსაფრთხოების კონტროლად.
• (b) პარამეტრიზებული მოთხოვნები: მონაცემთა ბაზასთან ყველა ურთიერთქმედება იყენებს პარამეტრიზებულ მოთხოვნებს (prepared statements) SQL ინექციის თავიდან აცილების მიზნით. მომხმარებლის შეყვანილი მონაცემებიდან დინამიური SQL-ის აგება აკრძალულია მიმწოდებლის უსაფრთხო კოდირების სტანდარტით.
• (c) გამოსატანი მონაცემების კოდირება: ბრაუზერში გამოსახული ყველა მონაცემი კონტექსტურად კოდირდება (საჭიროებისამებრ HTML, JavaScript, URL, CSS კოდირება) ჯვარედინი სკრიპტინგის (XSS) თავიდან აცილების მიზნით.
• (d) შიგთავსის უსაფრთხოების პოლიტიკა (CSP): HTTP პასუხის სათაურები შეიცავს მკაცრ Content Security Policy-ს XSS-ისა და მონაცემთა ინექციის შეტევების შესამცირებლად.

8.5 ინფრასტრუქტურის უსაფრთხოება

თითოეული კლიენტის ProjectVIEW ERP ინსტანსი განთავსებულია გამოყოფილ კერძო სუვერენულ გარემოში Microsoft Azure-ზე. ქვემოთ აღწერილი ინფრასტრუქტურის უსაფრთხოების კონტროლები გამოიყენება თითოეულ ტენანტზე ცალ-ცალკე და შესაბამისობაშია CIS Azure Foundations Benchmark-თან და Azure Well-Architected Security Pillar-თან.

8.5.1 ქსელური უსაფრთხოება

• (a) ქსელური უსაფრთხოების ჯგუფები (NSG): თითოეული ვირტუალური მანქანა დაცულია NSG-ებით, რომლებიც უზრუნველყოფენ მდგომარეობის გამათვალისწინებელ (stateful) ფაერვოლის ფუნქციონალს ცხადი ნებართვის/აკრძალვის წესებით. ნაგულისხმევი პოლიტიკა: ყველა შემომავალი ტრაფიკის აკრძალვა; დაშვებულია მხოლოდ აუცილებელი სერვისული პორტები.
• (b) ვებ-აპლიკაციების ფაერვოლი (WAF): Azure WAF განთავსებულია აპლიკაციის დონის წინ OWASP Top 10 საფრთხეებისგან დასაცავად, მათ შორის SQL ინექციის, XSS-ის, CSRF-ისა და request-smuggling შეტევებისგან.
• (c) DDoS-ისგან დაცვა: Azure DDoS Protection Standard ჩართულია კლიენტის ყველა გარემოსთვის და უზრუნველყოფს მოცულობითი, პროტოკოლის დონისა და აპლიკაციის დონის შეტევების შემცირებას ავტომატური აღმოჩენითა და რეალურ დროში აღმოფხვრით.
• (d) ქსელის სეგმენტაცია: მონაცემთა დონე, აპლიკაციის დონე და მართვის დონე განთავსებულია ცალკეულ ქვექსელებში, ხოლო დონეებს შორის ტრაფიკი კონტროლდება NSG წესებით. მონაცემთა ბაზის ქვექსელი ინტერნეტიდან პირდაპირ ხელმისაწვდომი არ არის.
• (e) VPN და კერძო კავშირი: თუ კლიენტს სჭირდება site-to-site კავშირი (მაგ., შიდა (on-premises) Active Directory-სთან ინტეგრაცია), იქმნება Azure VPN Gateway ან ExpressRoute IPSec/IKEv2 დაშიფვრით.
• (f) DNS-ის უსაფრთხოება: DNS-ზე დაფუძნებული მონაცემთა გატანის თავიდან აცილების მიზნით გამოიყენება Azure Private DNS ზონები. საჯარო DNS ჩანაწერები დაცულია DNSSEC-ით, სადაც ამას რეგისტრატორი უჭერს მხარს.

8.5.2 გამოთვლითი რესურსების უსაფრთხოება

• (a) ოპერაციული სისტემის გამაგრება: ყველა ვირტუალურ მანქანაზე გაშვებულია Microsoft Windows Server 2022, გამაგრებული CIS Windows Server 2022 Benchmark-ის შესაბამისად. ზედმეტი სერვისები, პორტები და ფუნქციები გათიშულია.
• (b) პატჩების მართვა: უსაფრთხოების პატჩები ინერგება: (i) კრიტიკული/მაღალი სიმძიმის CVE-ებისთვის სამოცდათორმეტი (72) საათის განმავლობაში; (ii) საშუალო სიმძიმის CVE-ებისთვის ოცდაათი (30) კალენდარული დღის განმავლობაში; (iii) დაბალი სიმძიმის CVE-ებისთვის მომდევნო ტექნიკური მომსახურების ფანჯარაში. პატჩები საწარმოო გარემოში დანერგვამდე იტესტება სატესტო (Staging) გარემოში.
• (c) მავნე პროგრამებისგან დაცვა: ყველა ვირტუალურ მანქანაზე ჩართულია ღრუბლოვანი საბოლოო წერტილების დაცვა (Microsoft Defender for Cloud) რეალურ დროში სკანირებით, ქცევის ანალიზითა და ავტომატური აღმოფხვრით.
• (d) ჰოსტზე დაფუძნებული შეჭრის აღმოჩენა: Azure Security Centre ყველა VM-ზე აკვირდება ფაილების მთლიანობას, საეჭვო პროცესების გაშვებას და ანომალიურ სისტემურ გამოძახებებს.

8.5.3 იდენტობისა და საიდუმლოებების (secrets) მართვა

• (a) Azure Key Vault: ყველა კრიპტოგრაფიული გასაღები, სერტიფიკატი, კავშირის სტრიქონი და სერვისული სარწმუნო მონაცემები ინახება Azure Key Vault-ში, წვდომით, რომელსაც აკონტროლებს Azure RBAC და Key Vault-ის წვდომის პოლიტიკები.
• (b) მართული იდენტობები: სადაც ეს შესაძლებელია, სერვისებს შორის აუთენტიფიკაციისთვის გამოიყენება Azure Managed Identities, რაც გამორიცხავს აპლიკაციის კონფიგურაციაში სარწმუნო მონაცემების შენახვის საჭიროებას.
• (c) საიდუმლოებების როტაცია: სერვისული ანგარიშების ყველა სარწმუნო მონაცემსა და API გასაღებს ერგება როტაციის ავტომატური პოლიტიკა. როტაციის მაქსიმალური პერიოდი: ოთხმოცდაათი (90) კალენდარული დღე.

8.6 მონაცემთა ბაზის უსაფრთხოება

პლატფორმის მონაცემთა დონე მუშაობს Microsoft SQL Server 2022-ზე (Standard ან Enterprise Edition), რომელიც განთავსებულია Microsoft Windows Server 2022-ზე. გამოიყენება მონაცემთა ბაზისთვის სპეციფიკური უსაფრთხოების შემდეგი კონტროლები, CIS SQL Server 2022 Benchmark-თან შესაბამისად:

8.6.1 წვდომა და აუთენტიფიკაცია

• (a) მონაცემთა ბაზის აუთენტიფიკაცია: SQL Server ძირითად აუთენტიფიკაციის მეთოდად იყენებს Windows Authentication რეჟიმს (Active Directory-სთან ინტეგრირებულს). შერეული (mixed-mode) აუთენტიფიკაცია გათიშულია, გარდა იმ შემთხვევისა, როდესაც ის პირდაპირ აუცილებელია და დამტკიცებულია კლიენტის მიერ.
• (b) აპლიკაციის პაროლები: მონაცემთა ბაზის აპლიკაციური დონის სარწმუნო მონაცემები იყენებს ძლიერ პაროლებს, რომლებიც შეესაბამება პაროლის შედგენილობის პოლიტიკას და იცვლება საიდუმლოებების როტაციის გრაფიკის შესაბამისად (§8.5.3).
• (c) ნაგულისხმევი ანგარიშები: სისტემის ყველა ნაგულისხმევ ანგარიშს (მაგ., „sa“) DBA შესაბამისად იცავს: ნაგულისხმევი პაროლები იცვლება უშუალოდ გამოყოფისავე; ზედმეტი ნაგულისხმევი ანგარიშები გათიშულია ან წაშლილი.
• (d) კავშირების კონტროლი: მონაცემთა ბაზის ინსტანსებთან კავშირები კონტროლდება და იმონიტორინგება. კავშირის დამყარება შეუძლიათ მხოლოდ ავტორიზებულ აპლიკაციური დონის სერვისებს და განსაზღვრულ DBA პერსონალს. კავშირის სტრიქონები ინახება Azure Key Vault-ში (§8.5.3).
• (e) კავშირის შესაძლებლობა: ქსელური დონის კონტროლები მონაცემთა ბაზასთან კავშირს ზღუდავს მხოლოდ აპლიკაციური დონის ქვექსელითა და მართვის ავტორიზებული წერტილებით. მონაცემთა ბაზასთან პირდაპირი კავშირი ინტერნეტიდან აკრძალულია.

8.6.2 პრივილეგიების მართვა

• (a) მინიმალური უფლებები და როლები: მონაცემთა ბაზის მომხმარებლის ანგარიშებს ენიჭება მათი ფუნქციისთვის აუცილებელი მინიმალური უფლებები და როლები. უმცირესი პრივილეგიის პრინციპი სავალდებულოა და პერიოდულად გადაიხედება.
• (b) სისტემური პრივილეგიები: ყველა „სისტემური“ პრივილეგია მომხმარებლის ანგარიშებიდან იხსნება, გარდა იმ შემთხვევისა, როდესაც ისინი პირდაპირ აუცილებელი და დამტკიცებულია. პრივილეგირებული ოპერაციები მოითხოვს ცალკე, გამოყოფილ DBA ანგარიშს MFA-ით.
• (c) მოვალეობების გამიჯვნა: მონაცემთა ბაზის ადმინისტრირების პრივილეგიები გამიჯნულია აპლიკაციის დეველოპმენტის პრივილეგიებისგან. დეველოპერებს არ აქვთ წვდომა საწარმოო მონაცემთა ბაზაზე.
• (d) პრივილეგიების გადახედვა: მონაცემთა ბაზის პრივილეგიების მინიჭების კვარტლური გადახედვა; გამოუყენებელი ან ზედმეტი პრივილეგიები უქმდება. გადახედვის შედეგები დოკუმენტირდება და ხელმისაწვდომია აუდიტისთვის (§7.11).

8.6.3 დაშიფვრა

• (a) მონაცემთა გამჭვირვალე დაშიფვრა (TDE): TDE ჩართულია ყველა საწარმოო და სატესტო მონაცემთა ბაზის ინსტანსზე და შიფრავს მონაცემთა ფაილებს, ჟურნალის ფაილებს და tempdb-ს AES-256 დაშიფვრით. TDE სერტიფიკატების რეზერვო ასლები ინახება Azure Key Vault-ში.
• (b) რეზერვო ასლების დაშიფვრა: მონაცემთა ბაზის ყველა რეზერვო ასლი (სრული, დიფერენციალური და ტრანზაქციების ჟურნალის) დაშიფრულია AES-256-ით კლიენტისთვის სპეციფიკური დაშიფვრის გასაღებებით, რომლებიც იმართება Azure Key Vault-ის მეშვეობით.
• (c) სვეტის დონის დაშიფვრა: თუ ამას მოითხოვს კლიენტის მონაცემთა კლასიფიკაციის პოლიტიკა, უაღრესად მგრძნობიარე ველებისთვის (მაგ., პირადი ნომრები, საბანკო ანგარიშის ნომრები) ხელმისაწვდომია სვეტის დონის დაშიფვრა (Always Encrypted).

8.6.4 აუდიტი და ჟურნალების წარმოება

• (a) აუდიტის ჟურნალები: SQL Server Audit აღრიცხავს: (i) ყველა DDL ოპერაციას (სქემის ცვლილებებს); (ii) პრივილეგირებული მომხმარებლების აქტივობას; (iii) აუთენტიფიკაციის წარუმატებელ მცდელობებს; (iv) მონაცემთა ექსპორტისა და მასობრივი კოპირების ოპერაციებს; (v) უფლებების ცვლილებებს. აუდიტის ჟურნალები იწერება საცავში, რომელიც უზრუნველყოფს შეცვლის აღმოჩენას (tamper-evident).
• (b) ჟურნალების შენახვა: მონაცემთა ბაზის აუდიტის ჟურნალები ინახება მინიმუმ თერთმეტი (12) თვის განმავლობაში ონლაინ და ოცდაოთხი (24) თვის განმავლობაში საარქივო საცავში. შენახვა შეესაბამება GDPR-ის, UAE PDPL-ისა და მოქმედი დარგობრივი სტანდარტების მარეგულირებელ მოთხოვნებს.
• (c) ცვლილებების აღრიცხვა: შესაბამისობისა და აუდიტის მიზნებისთვის მონაცემთა ცვლილებების სრული აღრიცხვის უზრუნველსაყოფად ჩართულია SQL Server Change Tracking და Change Data Capture (CDC).
• (d) DBA-ს დისტანციური წვდომა: მონაცემთა ბაზის დისტანციური ადმინისტრირება შეზღუდულია სახელით განსაზღვრული პირებით, დაშიფრული არხებით და მრავალფაქტორიანი აუთენტიფიკაციით. DBA-ს ყველა სესია რეგისტრირდება ბრძანებების დონის სრული აუდიტის კვლით (§7.8.3).

8.7 მოწყვლადობების მართვა

მიმწოდებელი ახორციელებს მოწყვლადობების მართვის უწყვეტ პროგრამას NIST CSF-ის ფუნქციებთან Identify (ID.RA) და Protect (PR.IP) შესაბამისად:

8.7.1 შეფასებების გრაფიკი

8.7.2 აღმოფხვრის ვადები

„ნულოვანი დღის“ (zero-day) მოწყვლადობები: პლატფორმის ტექნოლოგიურ სტეკზე მოქმედი აქტიურად ექსპლოატირებული zero-day მოწყვლადობების შემთხვევაში მიმწოდებელი ოცდაოთხი (24) საათის განმავლობაში იღებს საგანგებო შემცირების ზომებს (მაგ., WAF-ის წესები, ქსელის იზოლაცია, ვირტუალური პატჩინგი), ხოლო მუდმივი პატჩი ინერგება კრიტიკული სიმძიმის აღმოფხვრის SLA-ს შესაბამისად.

8.8 უსაფრთხოების მონიტორინგი და ინციდენტებზე რეაგირება

8.8.1 მონიტორინგი

მიმწოდებელი უზრუნველყოფს უსაფრთხოების 24/7 მონიტორინგს შემდეგი კომპონენტების მეშვეობით:

• (a) SIEM: ღრუბლოვანი უსაფრთხოების ინფორმაციისა და მოვლენების მართვის სისტემა (Microsoft Sentinel) აგრეგირებს ჟურნალებს ინფრასტრუქტურის, აპლიკაციისა და მონაცემთა ბაზის ყველა დონიდან. კორელაციის წესები და მანქანური სწავლების დეტექციები ავლენს ანომალიურ შაბლონებს.
• (b) AIOps: AI-ზე დაფუძნებული ოპერაციული ინსტრუმენტები უზრუნველყოფს ანომალიების პროგნოზულ აღმოჩენას წარმადობის მეტრიკებზე, აუთენტიფიკაციის შაბლონებზე და მონაცემებზე წვდომის მოცულობებზე, რაც უსაფრთხოებასთან დაკავშირებული გადახრების ადრეულ იდენტიფიცირებას უზრუნველყოფს, სანამ ისინი ინციდენტებად გადაიზრდება.
• (c) საფრთხეების დაზვერვა (threat intelligence): SIEM აერთიანებს საფრთხეების შესახებ რეალური დროის ინფორმაციულ ნაკადებს (Microsoft Threat Intelligence, დარგსათვის სპეციფიკური IOC-ები) ცნობილი შეტევების ხელმოწერებისა და კომპრომეტაციის ინდიკატორების აღმოსაჩენად.
• (d) მომხმარებლებისა და სუბიექტების ქცევის ანალიტიკა (UEBA): მომხმარებლებისა და სერვისული ანგარიშებისთვის დგინდება ქცევის საბაზისო პროფილები. გადახრები (მაგ., შესვლის ანომალიური ადგილმდებარეობა, მონაცემებზე წვდომის უჩვეულო შაბლონები, პრივილეგიების ესკალაციის მცდელობები) იწვევს ავტომატურ გაფრთხილებებს.

8.8.2 უსაფრთხოების ინციდენტებზე რეაგირება

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

8.8.3 კლიენტის შეტყობინება

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

• (iii) კლიენტის გარემოსთან დაკავშირებით სამართალდაცვათა ორგანოების ჩართულობას გულისხმობს. შეტყობინება ხორციელდება ინციდენტის სიმძიმისა და დარღვევის შესახებ შეტყობინების იმ SLA-ებთან შესაბამის ვადებში, რომლებიც განსაზღვრულია §7.15.1-ში.

8.9 უსაფრთხო დეველოპმენტის სასიცოცხლო ციკლი (SDLC)

მიმწოდებელი იყენებს უსაფრთხო SDLC-ს, რომელიც შესაბამისობაშია OWASP-ის Software Assurance Maturity Model-თან (SAMM) და Microsoft-ის Security Development Lifecycle-თან (SDL):

• (a) საფრთხეების მოდელირება: ახალი ფუნქციები და მნიშვნელოვანი ცვლილებები დიზაინის ეტაპზე გადის საფრთხეების მოდელირებას. საფრთხეების იდენტიფიცირებისთვის გამოიყენება STRIDE მეთოდოლოგია; რისკის პრიორიტიზაციისთვის — DREAD.
• (b) უსაფრთხო კოდირების სტანდარტები: დეველოპერები იცავენ მიმწოდებლის უსაფრთხო კოდირების სტანდარტს (OWASP Secure Coding Practices-ზე დაფუძნებულს), რომელიც მოიცავს შეყვანილი მონაცემების ვალიდაციას, გამოსატანი მონაცემების კოდირებას, აუთენტიფიკაციას, სესიის მართვას, შეცდომების დამუშავებასა და კრიპტოგრაფიას.
• (c) აპლიკაციის უსაფრთხოების სტატიკური ტესტირება (SAST): ავტომატური SAST სრულდება კოდის ყოველ კომიტზე. მაღალი/კრიტიკული სიმძიმის მიგნები ბლოკავს აწყობას მათ გადაჭრამდე.
• (d) აპლიკაციის უსაფრთხოების დინამიური ტესტირება (DAST): DAST სრულდება სატესტო (Staging) გარემოში საწარმოო გარემოში ყოველი დანერგვის წინ. სკანირება მიზნად ისახავს OWASP Top 10-სა და ASVS-ის მე-2 დონის კონტროლებს.
• (e) პროგრამული შედგენლობის ანალიზი (SCA): ყოველ აწყობაზე მესამე მხარის ყველა დამოკიდებულება სკანდება ცნობილი მოწყვლადობების (CVE) და ლიცენზიებთან შესაბამისობის თვალსაზრისით. კომპონენტები, რომლებსაც აქვთ გაუსწორებელი კრიტიკული/მაღალი სიმძიმის CVE, იბლოკება.
• (f) კოდის განხილვა: საწარმოო კოდის ყველა ცვლილება Master ტოტში შერწყმამდე მოითხოვს კოლეგის მიერ განხილვასა და დამტკიცებას. უსაფრთხოებისთვის მგრძნობიარე ცვლილებები (აუთენტიფიკაცია, კრიპტოგრაფია, წვდომის კონტროლის ლოგიკა) მოითხოვს განხილვას დანიშნული უსაფრთხოების ჩემპიონის (security champion) მიერ.
• (g) ვერსიების კონტროლი: Git-ზე დაფუძნებული ვერსიების კონტროლი Master/Client/Working ტოტების მოდელით (§4.7). ყველა კომიტი ხელმოწერილია და კონკრეტულ დეველოპერამდე ითვლებადია. Master ტოტში იძულებითი გადაცემა (force-push) აკრძალულია.

8.10 წყარო კოდის დაცვა

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

• (a) წვდომის შეზღუდვა: წყარო კოდის რეპოზიტორიები ხელმისაწვდომია მხოლოდ მიმწოდებლის ავტორიზებული დეველოპმენტის პერსონალისთვის. კლიენტის პერსონალს წყარო კოდზე წვდომა არ აქვს, გარდა იმ შემთხვევისა, როდესაც გაფორმებულია წყარო კოდის ესქროუ (escrow) ცალკე შეთანხმება.
• (b) წყარო კოდის ესქროუ: კლიენტის მოთხოვნის შემთხვევაში მიმწოდებელი აფორმებს წყარო კოდის ესქროუ შეთანხმებას საიმედო მესამე მხარე ესქროუ აგენტთან. გამოშვების პირობები, ჩვეულებრივ, მოიცავს: მიმწოდებლის გადახდიუუნარობას, წინამდებარე ჩარჩოს არსებით დარღვევას ან პლატფორმის შეწყვეტას შესაბამისი მემკვიდრე პროდუქტის გარეშე.
• (c) თხელი კლიენტის (thin-client) არქიტექტურა: პლატფორმა მუშაობს როგორც thin-client ვებ-აპლიკაცია. კლიენტის მოწყობილობებზე არ ვრცელდება საკუთრობაში არსებული წყარო კოდი, კომპილირებული ბინარული ფაილები ან აპლიკაციის ლოგიკა. აპლიკაციის ყველა დამუშავება ხორციელდება სერვერის მხარეს, კლიენტის სუვერენულ გარემოში.
• (d) ობფუსკაცია: ბრაუზერისთვის მიწოდებული კლიენტის მხარის JavaScript და CSS მინიფიცირებული და ობფუსკირებულია. Source map-ები საწარმოო გარემოში ხელმისაწვდომი არ არის.
• (e) ღია კოდის ვალდებულების არარსებობა: მიმწოდებელი უზრუნველყოფს, რომ ღია კოდის კომპონენტების გამოყენება არ ქმნის საკუთრობაში არსებული წყარო კოდის გამოქვეყნების ვალდებულებას (მაგ., copyleft ლიცენზიის „გავრცელების“ გზით). ღია კოდის ყველა კომპონენტი გამოყენებამდე მოწმდება ლიცენზიური თავსებადობის თვალსაზრისით.

8.11 კონფიდენციალურობის ვალდებულებები

8.11.1 ინფორმაციის კლასიფიკაცია

მხარეებს შორის გაცვლილი ყველა ინფორმაცია კლასიფიცირდება შემდეგი სქემის შესაბამისად:

8.11.2 ურთიერთო კონფიდენციალურობის ვალდებულებები

თითოეული მხარე მეორე მხარის წინაშე იღებს ვალდებულებას:

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

8.11.3 გამონაკლისები

კონფიდენციალურობის ვალდებულებები არ ვრცელდება ინფორმაციაზე, რომელიც:

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

8.11.4 ვალდებულებების ძალაში დარჩენა

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

8.12 წვდომის გაუქმება

8.12.1 სისტემებზე წვდომის გაუქმება

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

• (a) იძულებითი შეწყვეტა ან უსაფრთხოების საფრთხე: სისტემური სარწმუნო მონაცემების, VPN წვდომის, Key Vault-ის უფლებებისა და ფიზიკურ ობიექტებზე წვდომის დაუყოვნებლივ გაუქმება (1 საათის განმავლობაში).
• (b) გადაგეგმილი წასვლა: წვდომა უქმდება ბოლო სამუშაო დღეს. მიმწოდებლის საკუთრობაში არსებული ყველა მოწყობილობა ბრუნდება და სუფთავდება.
• (c) როლის ცვლილება: წვდომა ერთი (1) სამუშაო დღის განმავლობაში ერგება ახალი როლის პრივილეგიების მოთხოვნებს. წინა როლის ზედმეტი პრივილეგიები იხსნება.

8.12.2 აპლიკაციაზე წვდომის გაუქმება

კლიენტის საბოლოო მომხმარებლის როლის ცვლილებისას ან კლიენტის ორგანიზაციიდან წასვლისას:

• (a) კლიენტის პასუხისმგებლობა: STY მოდულში მომხმარებლის ანგარიშების გათიშვაზე ან ცვლილებაზე პასუხისმგებელია კლიენტის სისტემური ადმინისტრატორი (ან Champion).
• (b) მიმწოდებლის მხარდაჭერა: თუ კლიენტს სჭირდება მიმწოდებლის დახმარება (მაგ., მასობრივი გათიშვა, საგანგებო ბლოკირება), იქმნება P2 სერვისული მოთხოვნა (§4.3), რომელიც მუშავდება შესაბამისი SLA-ს ფარგლებში.
• (c) უმოქმედო ანგარიშების აღმოჩენა: პლატფორმა ნიშნავს ანგარიშებს, რომლებშიც ოთხმოცდაათ (90) კალენდარულ დღეზე მეტი ხნის განმავლობაში შესვლა არ ყოფილა. მონიშნული ანგარიშების შესახებ ეცნობება კლიენტის ადმინისტრატორს განხილვისა და შესაძლო გათიშვისთვის.

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

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

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

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

① ISMS-ის რისკების შეფასება → ② უსაფრთხოების არქიტექტურა და კონტროლები → ③ უსაფრთხო დეველოპმენტი და დანერგვა

▼

④ მოწყვლადობების მართვა → ⑤ უწყვეტი მონიტორინგი (SIEM / AIOps) → ⑥ წვდომის კონტროლი და გადახედვები

▼

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

უწყვეტი ციკლი: ეტაპი ⑨ (აუდიტი და სერტიფიცირება) უბრუნდება ეტაპ ①-ს (რისკების შეფასება) ISMS-ის უწყვეტი გაუმჯობესების ციკლის (Plan–Do–Check–Act) მეშვეობით. ეტაპები ④–⑦ უწყვეტად მოქმედებს კვირეული ავტომატური სკანირებითა და რეალურ დროში SIEM მონიტორინგით. ყოველწლიური შეჭრის ტესტები და სერტიფიცირების აუდიტები უზრუნველყოფს დამოუკიდებელ გარანტიას.