GH GambleHub

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

1) დანიშნულება და გამოყენების სფერო

მიზანი: მომხმარებელთა/სერვისების მოქმედების დადასტურების უზრუნველყოფა, გამოძიების გამჭვირვალობა, რეგულატორებისა და შიდა სტანდარტების შესაბამისობა (GDPR/AML, PSP/KYC პროვაიდერების კონტრაქტები, ISO/PCI გამოყენებისას).
გაშუქება: ყველა სარეკლამო სისტემა, პლატფორმის მომსახურება (ანგარიში, გადახდა, ანტიფროდი, KUS/სანქციები, RG), admin პანელები, API კარიბჭეები, DWH/BI, ინფრასტრუქტურა (K8s/ღრუბელი), ინტეგრაცია მოვაჭრეებთან.


2) რა უნდა გააკეთოთ (მოვლენების კლასები)

1. იდენტიფიკაცია და წვდომა: ლოგინი/ლოგუტი, MFA, პაროლების/გასაღებების შეცვლა, SSO, „break-glass“ წვდომა.
2. ადმინისტრაციული მოქმედებები: როლების/უფლებების ცვლილებები, კონფიგურაცია, ანტიფროდული/სანქციების წესები, ფიგურის დროშები.
3. ოპერაციები PII/findan- ით: კითხვა/ექსპორტი/მოცილება, გადმოტვირთვა, KYC- ზე წვდომა, VIP პროფილების ნახვა.
4. გარიგებები და ფული: ქეშები/ანაბრები, გაუქმება, გადახდა, ჩარჟბეკების შესახებ გადაწყვეტილებები.
5. შესაბამისობა/AML/KYC: სკრინინგის შედეგები (სანქციები/PEP/Adverse Media), გადაწყვეტილებები (TP/FP), EDD/STR/SAR.
6. ინციდენტები და უსაფრთხოება: ესკალაცია, WAF/IDS წესების ცვლილებები, მომსახურების იზოლაცია, საიდუმლოების როტაცია.
7. ინტეგრაცია/გამყიდველები: API გამოწვევები, შეცდომები, ტაიმაუტები, ექსპორტები, მონაცემთა მოცილების/დაბრუნების დადასტურება.

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

3) ღონისძიების სავალდებულო სფეროები (მინიმალური)

`event_id` (UUID), `ts_utc`, `ts_local`, `source_service`, `trace_id`/`span_id`

'actor _ type' (user/service/vendor), 'actor _ id' (მუდმივი იდენტიფიკატორი), 'actor _ org' (თუ B2B)

`subject_type` (account/tx/document/dataset), `subject_id`

`action` (e. g., `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `WITHDRAWAL_APPROVE`)

`result` (success/deny/error) и `reason`/`error_code`

'ip', 'device _ fingerprint', 'geo' (ქვეყანა/რეგიონი), 'auth _ context' (MFA/SSO)

'fields _ accessed '/' scope' (PII/findane- სთან მუშაობის დროს) - შენიღბვით

'purpose '/' ticket _ id' (საფუძველი: DSAR, ინციდენტი, რეგულატორის მოთხოვნა, ოპერაციული ამოცანა)


4) უცვლელობა და მტკიცება

WORM საცავი „ოქროს“ ასლისთვის.
კრიპტოვალუტის/ჰეშის ჯაჭვი: მოვლენების პაკეტების პერიოდული ხელმოწერა ან/და ჰაშის ჯაჭვის მშენებლობა, ცვლილებების იდენტიფიცირების მიზნით.
სქემების/წესების შეცვლის ჟურნალი: სქემების ვერსია და ლოჯისტიკის პოლიტიკა; ნებისმიერი რედაქტირება გადის CAB.
ორმაგი წრიული შენახვა: ოპერაციული ინდექსი (ძებნა) + არქივი/immutability.


5) დროის სინქრონიზაცია და კვალდაკვალ

ერთი NTP/Chrony ყველა გარემოში; ლოგებში - 'ts _ utc', როგორც ჭეშმარიტების წყარო.
თითოეულ ლოგოში - 'trace _ id '/' spank _ id' მოთხოვნის კვეთაზე (კორელაცია სერვისებს, გამყიდველებსა და ფრონტს შორის).


6) კონფიდენციალურობა და საიდუმლოებები

აკრძალულია: პაროლები, ნიშნები, სრული PAN/CSC, სრული დოკუმენტების ნომრები, „ნედლეული“ ბიომეტრია.
ნაგულისხმევი შენიღბვა: ელექტრონული ფოსტის/ტელეფონის/IBAN/PAN- ის ნიშნები/ნაწილობრივი რუქა.
ფსევდონიმიზაცია: 'user _ id' - სტაბილური ნიშანი ანალიტიკაში; ნამდვილი პირადობის მოწმობის მითითება მხოლოდ დაცულ წრეში არის.
DSAR თავსებადობა: საგნის საშუალებით ლოგოების შერჩევითი მოპოვების შესაძლებლობა უცხო PII- ის გამჟღავნების გარეშე.


7) შენახვის დრო და დონე (გადაკეთება)

კლასიHotWarmColdWORM/Legal Hold
წვდომა PII/Admin მოქმედებებზე30 დნ6-12 თვე24-36 თვე5 წლამდე/მოთხოვნით
გარიგებები/ფინანსები90 დნ12 თვე36 თვე5-10 წელი (AML/ხელშეკრულებები)
KUS/სანქციები/RER გადაწყვეტილებები30 დნ12 თვე36 თვე5-10 წელი
ინციდენტები/უსაფრთხოება30 დნ6-12 თვე24 თვეგამოძიების დასრულებამდე
💡 კონკრეტული თარიღები დამტკიცებულია Legal/Compliance, იურისდიქციების, ლიცენზიებისა და ხელშეკრულებების გათვალისწინებით (PSP/KYC/ღრუბელი).

8) წვდომა და კონტროლი (RBAC/ABAC)

აუდიტორული ლოგოების წაკითხვის როლები გამოყოფილია ადმინისტრატორის როლებისგან.
MFA და Just-in-Time (break-glass) წვდომა ავტომატური სიჩქარით/მიზეზების გაუმჯობესებით.
„მინიმუმის“ პოლიტიკა: PII/findance მინდვრებზე წვდომა მხოლოდ საჭიროების შემთხვევაში და 'purpose' - ის ფიქსაციით.
ექსპორტი/გადმოტვირთვა: ადრესატებისა და ფორმატების თეთრი სიები; სავალდებულო ხელმოწერა/ჰაში, გადმოტვირთვის ჟურნალი.


9) ინტეგრაცია SIEM/SOAR/ETL

აუდიტის მოვლენების ნაკადი შედის SIEM- ში კორელაციისთვის (ე. გ., მასიური 'READ _ PII' + შესასვლელი ახალი მოწყობილობიდან).
SOAR playbuks: ავტომობილების თიკეტები პოლიტიკოსის დარღვევის დროს (არა 'purpose ", არანორმალური მოცულობა, ფანჯრის გარეთ შესვლა).
ETL/DWH: ფანჯრები 'audit _ access', 'pii _ exports', 'admin _ changes' ხარისხის კონტროლითა და სქემების ვერსიით.


10) მონაცემთა ხარისხი და მოვალეობები

სქემები, როგორც კოდი (JSON/Protobuf/Avro): სავალდებულო ველები, ტიპები, ლექსიკონები; CI შემსრულებლები.
შერჩევა და quarantine ხაზი სქემის შეცდომებით მოვლენებისთვის; ქორწინების მეტრიკა.
დედუპლიკაცია/იდემპოტენტურობა '(event _ id, trace _ id, ts) "; ხელახალი გაგზავნის კონტროლი.


11) RACI

ამოცანაCompliance/LegalDPOSecuritySRE/DataProduct/Eng
პოლიტიკა და ჭრაA/RCCCI
შენიღბვა/PII კონტროლიCA/RRRC
Immutability/ხელმოწერებიICA/RRC
წვდომა/ექსპორტიCCA/RRI
სქემები/მოვალეობებიICCA/RR
ინციდენტები და გამოძიებაCARRC
გამყიდველები/კონტრაქტებიA/RCCCI

12) SOP: მონაცემების წვდომის გამოძიება

1. ტრიგერი: ალერტი SIEM (არანორმალური 'READ _ PII '/ექსპორტი), საჩივარი, სიგნალი გამყიდველისგან.
2. არტეფაქტების შეგროვება: მოვლენების გადმოტვირთვა 'actor _ id '/' subject _ id '/' trace _ id', ჟურნალი 'purpose ", თანმხლები ლოგოები (WAF/IdP).
3. კანონიერების შემოწმება: ბაზის არსებობა (DSAR/ინციდენტი/ოფიციალური ამოცანა), კოორდინაცია, წვდომის ფანჯრები.
4. ზემოქმედების შეფასება: PII მოცულობა/კატეგორია, იურისდიქცია, სუბიექტების რისკი.
5. გამოსავალი: ხიდის ინციდენტი (მაღალი/კრიტიკული), შინაარსი (წვდომის მიმოხილვა, გასაღების როტაცია).
6. ანგარიში და CAPA: დარღვეული პოლიტიკის მიზეზები, ზომები (შენიღბვა, ტრენინგი, RBAC- ის ცვლილებები), ვადები.


13) SOP: მონაცემთა ექსპორტი (რეგულატორი/პარტნიორი/DSAR)

1. მოთხოვნა - ფუძისა და პიროვნების გადამოწმება (DSAR- სთვის) - მოთხოვნის ფორმირება DWH- ში.
2. ანესთეზია/ნაგულისხმევი შემცირება; PII ჩართვა მხოლოდ იურიდიულ საფუძველზე.
3. გადმოტვირთვის თაობა (CSV/JSON/Parquet) - ხელმოწერა/Hash - ჩაწერა გადმოტვირთვის ჟურნალში (CSV/com/com/ბაზა).
4. პროგრამა დამტკიცებული არხის საშუალებით (sFTP/Secure link); ასლის შენახვის ვადაა პოლიტიკა.
5. პოსტის კონტროლი: მიღების დადასტურება, დროებითი ფაილების წაშლა.


14) მეტრიკი და KRIs/KPIs

Coverage: კრიტიკული სისტემების წილი, რომლებიც audit მოვლენებს უგზავნიან, 95% -ს შეადგენს.
DQ შეცდომები: მოვალეობის შემსრულებლის მიერ უარყოფილი მოვლენები 0. ნაკადის 5%.
MTTD ნაკადის დაკარგვა: 15 წუთი (ალერტი დუმილით).
არანორმალური წვდომა 'purpose' გარეშე: = 0 (KRI).

გამოძიებაზე პასუხის დრო: საშუალო - 4 საათი, P95 - 24:
  • ექსპორტები ხელმოწერით/ჰეშით: 100%.
  • Retenshny- ის დაცვა: მოცილება/არქივები 99% -ით.

15) მოთხოვნები გამყიდველებსა და ქვე-პროცესორებზე

DPA/SLA: აუდიტის ლოგოების აღწერა (სქემები, ვადები, გეოგრაფია, ექსპორტის ფორმატი), WORM/immutability, SLA ინციდენტის შეტყობინებები.
გამყიდველის დაშვება: დასახელებული მომსახურების ანგარიშები, მათი მოქმედების ჟურნალები, შერჩევითი აუდიტის შესაძლებლობა.
ოფბორდი: გასაღებების მიმოხილვა, ჟურნალების ექსპორტი/მოცილება, დახურვის აქტი, ბეკების განადგურების დადასტურება.


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

როლების გამიჯვნა: admin წყარო - admin საცავი - აუდიტორი.
აგენტების/კოლექციონერების ხელმოწერა, mTLS კომპონენტებს შორის.
Anti-tamper აკონტროლებდა: ჰეშას შედარება, რეგულარული მთლიანობის შემოწმება, განსხვავებების ალერტები.
WORM ასლების გეო-რეპლიკაცია და რეგულარული აღდგენის ტესტები.


17) ტიპიური შეცდომები და ანტი-ნიმუშები

მგრძნობიარე მნიშვნელობების ლოგიკა (PAN/საიდუმლოებები) არის redaction-middleware- ის დაუყოვნებლივი ჩართვა.
'purpose '/' ticket _ id' არარსებობა PII- ზე წვდომისას.
ადგილობრივი გადმოტვირთვის „სამუშაო მაგიდაზე“ და ელექტრონული ფოსტის გაგზავნა.
ერთიანი სქემის არარსებობა და შესაბამისობა არის „მუნჯი“ ველები, კორელაციის შეუძლებლობა.
ერთი სუპერ ანგარიში პირის ან მომსახურების მითითების გარეშე.


18) ჩეკის ფურცლები

18. 1 პოლიტიკის გაშვება/შურისძიება

დამტკიცებულია სქემები და ლექსიკონები; სავალდებულო ველები შედის

  • ჩართულია შენიღბვა და საიდუმლოების აკრძალვა
  • NTP, 'trace _ id' ყველგან
  • Hot/Warm/Cold/WORM ფენები
  • RBAC/ABAC და break glass მორთულია
  • SIEM/SOAR ინტეგრირებულია, ალერტების ტესტირება ხდება

18. 2 ყოველთვიური აუდიტი

  • ექსპორტის ნიმუში: ხელმოწერები/ჟურნალები სწორია
  • ჭრილობის/წაშლის შემოწმება/Legal Hold
  • DQ მეტრიკა ნორმალურად, quarantine ანალიზი
  • Wendor- ის ლოგოები ხელმისაწვდომია/სავსეა

19) გზის განხორციელების რუკა

კვირები 1-2: სისტემების ინვენტარიზაცია, სქემების და სავალდებულო ველების კოორდინაცია, დროისა და კვანძების კონფიგურაცია.
კვირები 3-4: ნიღბების ჩართვა, WORM ფენა, ინტეგრაცია SIEM/SOAR- სთან, ექსპორტის ჟურნალების გაშვება.
თვე 2: წამყვანების/ალერტების ავტომატიზაცია, გამოძიების ფლეიბუკები, გუნდების ტრენინგი.
თვე 3 +: რეგულარული აუდიტი, სტრესული მთლიანობის ტესტები, ღირებულების ოპტიმიზაცია, მოვაჭრეების/კონტრაქტების აუდიტი.


TL; DR

ძლიერი აუდიტის ჟურნალები = სრული და სტრუქტურირებული მოვლენები + immutability (WORM) და ხელმოწერები + PII + მყარი წვდომა და გადმოტვირთვის ჟურნალი + ინტეგრაცია SIEM/SOAR- სთან. ეს აჩქარებს გამოძიებას, ამცირებს რისკებს და შესაბამისობას ამტკიცებს.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.