აუდიტის ჟურნალები და წვდომის კვალი
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) შენახვის დრო და დონე (გადაკეთება)
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
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).
- ექსპორტები ხელმოწერით/ჰეშით: 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- სთან. ეს აჩქარებს გამოძიებას, ამცირებს რისკებს და შესაბამისობას ამტკიცებს.