ინციდენტებზე რეაგირების გეგმა

ძალაში შესვლა: 2026 წლის 2 ივნისი

ეს ინციდენტებზე რეაგირების გეგმა („გეგმა“) განსაზღვრავს, თუ როგორ აღმოაჩენს, რეაგირებს, აღდგენს და სწავლობს STANDOUT Inc. („ჩვენ“) უსაფრთხოების ინციდენტებიდან, სერვისის შეფერხებებიდან და მონაცემთა დარღვევებიდან, რომლებიც გავლენას ახდენს VATES-ის სერვისზე („სერვისი“). გეგმა ეყრდნობა NIST SP 800-61 Rev.2-სა და ISO/IEC 27035-ს, და აგებულია იმ საპროექტო პრინციპზე, რომ ავტომატური მონიტორინგის ხელსაწყოები აღმოჩენის წინა ხაზად მსახურობს.

1. მიზანი და მოქმედების სფერო

ამ გეგმის მიზნებია:

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

ეს გეგმა ვრცელდება სერვისის საწარმოო გარემოზე (EC2, Cloudflare და დაკავშირებული SaaS მომწოდებლები), სერვისიდან ზედა დონის AI მომწოდებლებამდე საკომუნიკაციო გზაზე და მომხმარებლის მონაცემების შემცველ ყველა საცავზე.

2. ინციდენტის განმარტება და სიმძიმის კლასიფიკაცია

2.1 ინციდენტის განმარტება

ამ გეგმის მიზნებისთვის, ინციდენტი არის ნებისმიერი მოვლენა, რომელიც ემთხვევა ქვემოთ ჩამოთვლილთაგან ერთ ან მეტს:

• სავარაუდო არასანქცირებული წვდომა, credentials-ის კომპრომეტირება ან სისტემაში შეჭრა.
• მომხმარებლის მონაცემების, პერსონალური მონაცემების ჩათვლით, არასანქცირებული გამჟღავნება, შეცვლა ან დაკარგვა.
• გათიშვა ან მნიშვნელოვანი წარმადობის ვარდნა, რომელიც სერვისის ძირითად ფუნქციონალზე ახდენს გავლენას.
• უსაფრთხოების საფრთხეები, malware-ით ინფიცირების, ransomware-ის ან მიწოდების ჯაჭვის შეტევების ჩათვლით.
• ოპერაციული შეცდომა, არასწორი კონფიგურაცია ან პროგრამული დეფექტი, რომელიც დიდი მასშტაბის გავლენას იწვევს.

2.2 სიმძიმის კლასიფიკაცია

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

• P1 (Critical): სერვისის სრული გათიშვა, ან დადასტურებული მონაცემთა დარღვევა, რომელიც პერსონალურ მონაცემებს ეხება. საჭიროებს დაუყოვნებლივ რეაგირებას.
• P2 (High): ძირითადი ფუნქციონალის მნიშვნელოვანი დაზიანება, კონკრეტული მომხმარებლებისთვის მიუწვდომლობა, ან ავთენტიფიკაციის ანომალიები. საწყისი რეაგირება საჭიროა ერთი საათის განმავლობაში.
• P3 (Medium): ნაწილობრივი ფუნქციური დაზიანება ან წარმადობის ვარდნა ხელმისაწვდომი შემოვლითი გზებით. რეაგირება სამუშაო საათებში მისაღებია.
• P4 (Low): შეზღუდული მომხმარებლის გავლენის მქონე მოვლენები, ლოგების მთლიანობის მცირე გადახრა, ან მონიტორინგის ხელსაწყოების შემცირებული რეზერვირება. განიხილება შემდეგ დაგეგმილ მიმოხილვის ციკლში.

3. რეაგირების სტრუქტურა

3.1 პასუხისმგებელი მხარე

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

3.2 ავტომატური აღმოჩენის ხელსაწყოები

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

• Cloudflare Health Check: ამოწმებს production origin-ს მრავალი გეოგრაფიული წერტილიდან 60-წამიანი ინტერვალით.
• HetrixTools: აკვირდება production endpoint-ებს მრავალი გლობალური წერტილიდან Cloudflare-ისგან დამოუკიდებელი გზით.
• Sentry: იჭერს აპლიკაციის გამონაკლისებს რეალურ დროში და აცნობებს პასუხისმგებელ მხარეს.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): ბლოკავს ცნობილ შეტევის შაბლონებს Block რეჟიმში.
• Cloudflare DDoS Protection: უწყვეტად და ავტომატურად ანეიტრალებს DDoS შეტევებს ქსელის ფენაზე, SSL/TLS ფენაზე და HTTP ფენაზე.
• Anomaly Detection Batch (systemd timer): ასკანირებს audit log-ებს ყოველ ხუთ წუთში და აღმოაჩენს სამ კატეგორიას: მოთხოვნების მაღალი სიხშირე, ავტორიზაციის უარყოფის მაღალი მაჩვენებელი და brute-force მცდელობები.
• Rate Limiting: tenant-ის დონეზე მოთხოვნების rate limiting გამოყენების endpoint-ებზე და IP-ზე დაფუძნებული rate limiting ავთენტიფიკაციის endpoint-ებზე, ჭარბი ტრაფიკის ავტომატური უარყოფით.
• Configurable Security Alerts: მომხმარებლებს შეუძლიათ აირჩიონ, რომელი ოპერაციული მოვლენა (დაბალი ბალანსი, ახალი მდებარეობიდან შესვლა, დაბლოკილი წვდომა, განმეორებითი შესვლის წარუმატებლობები) იწვევს ელფოსტის შეტყობინებებს, თითო მოვლენაზე მგრძნობელობის ზღვრებით.
• Audit Log Infrastructure: ჩაიწერს ყველა API გამოძახებას hash-chain-ით დაცულ, გაყალბების მტკიცებად audit log-ში (SHA-256, თითო tenant-ის თანმიმდევრობა) და აერთიანებს ჩანაწერებს დამოუკიდებელი გადამოწმებისთვის.
• Status Dashboard (9 health pill): ვიზუალიზებს audit-ს, ანომალიას, GeoIP-ს, backup-ს, deletion batch-ს, კატალოგის დაფარვას, შეჯერების გადახრას, killswitch-სა და სერვისის ჯანმრთელობას ერთ ეკრანზე.
• Automated Backup: შიფრავს SQLite snapshot-ებს GPG AES-256-ით და ინახავს 30 ყოველდღიურ თაობას.

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

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

4. რეაგირების პროცესი

4.1 აღმოჩენა

როდესაც 3.2 ნაწილში აღწერილი ავტომატური ხელსაწყოებიდან ერთი ან მეტი აღმოაჩენს ანომალიას, პასუხისმგებელი მხარე დაუყოვნებლივ ეცნობება Sentry-ის, ელფოსტისა და dashboard-ის alert-ების მეშვეობით. მომხმარებლის შეტყობინებები მიიღება [email protected]ზე და ანალოგიური ნაკადით ფიქსირდება ticket-ად.

4.2 ტრიაჟი

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

• გავლენის მასშტაბი (ყველა მომხმარებელი / კონკრეტული მომხმარებელი / ცალკეული instance).
• დაზარალდა თუ არა პერსონალური მონაცემები, ავთენტიფიკაციის credentials ან ბილინგის ინფორმაცია.
• გარე ფაქტორების ჩართულობა (ზედა დონის AI მომწოდებლის გათიშვები, Cloudflare-ის გათიშვები, AWS-ის გათიშვები).
• კავშირი ცნობილ შეტევის შაბლონებთან (WAF ლოგები, ანომალიის აღმოჩენის შედეგები, GeoIP alert-ები).

4.3 შეკავება

სიმძიმის მიხედვით, გამოიყენება შემდეგი შეკავების ზომებიდან ერთი ან მეტი:

• დაზარალებული instance-ების შეჩერება state machine-ის მეშვეობით დაუყოვნებლივი იზოლაციისთვის.
• წყაროს IP მისამართების deny list-ში დამატება (თითო მომხმარებელზე ან გლობალურად).
• session-ების მასობრივი გაუქმება JWT jti-ით.
• killswitch-ის გააქტიურება (ტრაფიკის სრული შეჩერება, უკანასკნელი საშუალება).
• Cloudflare „Under Attack Mode“-ის გააქტიურება L7 შეტევების წინააღმდეგ.

4.4 აღდგენა

შეკავების შემდეგ, აღმოიფხვრება ფესვეული მიზეზები და სრულდება შემდეგი:

• backup-იდან აღდგენა საჭიროებისამებრ (პროცედურები დოკუმენტირებულია docs/RESTORE.md-ში).
• დაზარალებული credentials-ის როტაცია (API keys, JWT secrets, backup-ის დაშიფვრის გასაღებები და სხვ.).
• patch-ების, კონფიგურაციის შესწორებებისა და კოდის გასწორებების გამოყენება საწარმოო გარემოში.
• გადამოწმება staging და production გარემოებში.
• გაგრძელებული დაკვირვება მინიმუმ 24 საათის განმავლობაში მონიტორინგის ხელსაწყოების მეშვეობით.

4.5 პოსტ-ინციდენტი

აღდგენის დადასტურების შემდეგ, პასუხისმგებელი მხარე:

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

5. მომხმარებლისა და მარეგულირებლის შეტყობინება

5.1 პერსონალურ მონაცემთა დარღვევის შეტყობინება

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

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

5.2 სერვისის შეფერხების შეტყობინება

P1 ან P2-ად კლასიფიცირებული სერვისის შეფერხებებისთვის, დაზარალებულ მომხმარებლებს ვაცნობებთ გაუმართლებელი დაყოვნების გარეშე, მოსალოდნელი აღდგენის ვადისა და ნებისმიერი შუალედური შემამსუბუქებელი ზომის ჩათვლით. შეტყობინების არხებია [email protected] და სერვისის ადმინისტრაციული კონსოლი.

5.3 შეტყობინების მეთოდი

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

6. Post-Mortem და სწავლის ციკლი

P1 ან P2 ინციდენტის შემდეგ, პასუხისმგებელი მხარე ასრულებს Post-Mortem-ს და დოკუმენტირებს შემდეგ პუნქტებს. დოკუმენტი ინახება შიდად და მომხმარებლებსა და აუდიტორებს ეცნობება მოთხოვნისას.

• მოვლენების ქრონოლოგია აღმოჩენიდან აღდგენამდე.
• ფესვეული მიზეზის ანალიზი (ტექნიკური და ოპერაციული ფაქტორები).
• გავლენის რაოდენობრივად განსაზღვრული მასშტაბი.
• სარეაგირო პროცესის შეფასება.
• პრევენციული ზომები და სამიზნე ვადები.

Post-Mortem-ები ტარდება როგორც Blameless Post-Mortem-ები, ფოკუსირებული სტრუქტურულ გაუმჯობესებაზე და არა ინდივიდუალურ პასუხისმგებლობაზე.

7. გეგმის შენახვა და გადახედვა

7.1 პერიოდული გადახედვა

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

7.2 რედაქციების ისტორია

ამ გეგმის რედაქციების ისტორია ინახება შიდად და მომხმარებლებსა და აუდიტორებს ეცნობება მოთხოვნისას.

8. კონტაქტი

ინციდენტის შესატყობინებლად ან ამ გეგმის შესახებ შეკითხვების დასასმელად:

STANDOUT Inc.
ელფოსტა: [email protected]

ბოლო განახლება: 2026 წლის 2 ივნისი