ტექნიკური და ორგანიზაციული ზომები (TOMs)

1. კონფიდენციალურობა (GDPR-ის 32(1)(b) მუხლი და საქართველოს კანონი „პერსონალურ მონაცემთა დაცვის შესახებ“)

1.1 ფიზიკური წვდომის კონტროლი

რივო იყენებს სერვერლეს (serverless) ჰოსტინგსა და მართულ ღრუბლოვან გარემოებს. ინფრასტრუქტურა განთავსებულია უსაფრთხო და სერტიფიცირებულ მონაცემთა ცენტრებში:

• აპლიკაციის ჰოსტინგი: Cloudflare Pages (გლობალური CDN ქსელი).
• მონაცემთა ბაზა და ფაილების საცავი: Supabase (AWS ინფრასტრუქტურა ევროკავშირის ტერიტორიაზე).

მონაცემთა ცენტრების ფიზიკურ უსაფრთხოებას (ბიომეტრიული კონტროლი, 24/7 ვიდეომონიტორინგი, ფიზიკური ბარიერები) უზრუნველყოფენ AWS და Cloudflare საერთაშორისო სტანდარტების (ISO 27001, SOC 2 Type II) შესაბამისად.

1.2 ლოგიკური წვდომის კონტროლი (სისტემური წვდომა)

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

1.3 მონაცემთა წვდომის კონტროლი (მონაცემთა ბაზის დონე)

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

1.4 მონაცემთა გადაცემის კონტროლი

• შიფრაციის სავალდებულოობა: HTTPS პროტოკოლის გამოყენება სავალდებულოა ყველა საჯარო მისამართისთვის.
• API და ვებჰუკის დაცვა: გარე მოთხოვნები (Cross-Origin POST) დაბლოკილია. გადახდების სისტემიდან მიღებული თითოეული ვებჰუკი მოწმდება კრიპტოგრაფიული ხელმოწერით.

2. მონაცემთა მთლიანობა (GDPR-ის 32(1)(b) მუხლი)

2.1 გადახდების და ტრანზაქციების მთლიანობა

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

2.2 უსაფრთხოების გამყარება და მანიპულაციების პრევენცია

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

3. ხელმისაწვდომობა და მდგრადობა (GDPR-ის 32(1)(b) მუხლი)

3.1 ინფრასტრუქტურის მდგრადობა

• გლობალური ქსელი: ვებ-აპლიკაცია განთავსებულია გლობალურ ქსელში (CDN), რაც უზრუნველყოფს დაცვას DDoS შეტევებისგან, ტრაფიკის მკვეთრი ზრდისა და ლოკალური შეფერხებებისგან.
• მონაცემთა ბაზის ხელმისაწვდომობა: მონაცემთა ბაზა მართულია პროვაიდერის მიერ, რაც უზრუნველყოფს მაღალი ხელმისაწვდომობის გარანტიას (SLA) და მუდმივ მონიტორინგს.

3.2 სარეზერვო ასლები და აღდგენის დრო

• სარეზერვო ასლების გრაფიკი: ყოველდღიური სარეზერვო ასლები იქმნება ავტომატურად მონაცემთა ბაზის პროვაიდერის მიერ.
• Point-in-Time Recovery (PITR): ჩართულია საწარმოო გარემოსთვის, რაც საშუალებას იძლევა მონაცემები აღდგეს ნებისმიერ მიკროწამში მოცემული დროის ინტერვალის ფარგლებში.
• აღდგენის გეგმა: ოპერაციები ხორციელდება შესაბამისი ინსტრუქციის მიხედვით. აღდგენის სიმულაციები სრულდება მხოლოდ სატესტო იზოლირებულ გარემოებში.

4. კანდიდატთა პერსონალური მონაცემების დაცვა და თანხმობა

4.1 ფაილების საცავი და წვდომის აუდიტი

• დაცული ფაილების საცავი: კანდიდატების CV ფაილები ინახება მონაცემთა საცავის დახურულ განყოფილებაში (Private Bucket). ფაილზე წვდომა იხსნება მხოლოდ დამსაქმებლის მიერ კრედიტების გადახდის შემდეგ.
• წვდომის ჟურნალი (Audit Log): სისტემაში ფიქსირდება თითოეული კანდიდატის რეზიუმეს გახსნის ფაქტი (რომელმა ორგანიზაციამ გახსნა, როდის და რომელი ტრანზაქციის ფარგლებში).

4.2 პერსონალური მონაცემების შენახვის ვადა და წაშლა

• კასკადური წაშლა (Deletion Cascades): მონაცემთა ბაზის მთლიანობის წესები უზრუნველყოფს მონაცემთა ნარჩენების სრულ განადგურებას. მომხმარებლის ან პროფილის წაშლისას კასკადურად იშლება კანდიდატის ყველა მონაცემი, ატვირთული ფაილი და ვაკანსიაზე გაგზავნილი განაცხადები.
• ავტომატური წაშლა (Data Purge): არააქტიური კანდიდატების ანგარიშები და ფაილები ავტომატურად იშლება მონაცემთა ბაზიდან სპეციალური პერიოდული სკრიპტების მეშვეობით, კანდიდატის ბოლო აქტივობის თარიღის საფუძველზე.
• თანხმობის აღრიცხვა: რეზიუმეს გაგზავნისას მომხმარებლისგან გროვდება მკაფიო წესებზე თანხმობის აღნიშვნა.
• ფაილების უსაფრთხოების ლიმიტები:
  • ატვირთული CV ფაილის მაქსიმალური ზომა შეზღუდულია 5 მეგაბაიტით (5MB).
  • დასაშვებია მხოლოდ PDF და DOCX ფორმატები, რაც გამორიცხავს სერვერზე მავნე კოდის (executable) ატვირთვის შესაძლებლობას.

5. ორგანიზაციული და დეველოპმენტის უსაფრთხოება

5.1 მომხმარებელთა/დეველოპერთა სამუშაო სადგურების უსაფრთხოება

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

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

5.2 სატესტო გარემოს ვერიფიკაციის ბარიერი (Staging Gate)

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

5.3 კოდის ხარისხი

• კოდის შემოწმება (Static Analysis): კოდის ტიპების ვალიდაცია სრულდება ავტომატური ბრძანებების მეშვეობით ლოკალურად და CI გარემოში.
• კოდის რევიუ (Pull Requests): პროდაქშენში კოდის გაშვება ხდება მხოლოდ განხილვის, დამტკიცებისა და უსაფრთხოების შემოწმების გავლის შემდეგ.