GH GambleHub

ოპერაციების აუდიტის ჟურნალები

(განყოფილება: ოპერაციები და კონტროლი)

1) დანიშვნა და პრინციპები

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

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

2) დაფარვის სფეროები

მომხმარებლის მოქმედებები: შესვლა/SSO/MFA, როლების/ლიმიტების შეცვლა, ოპერაციები PII- სთან.
პრივილეგირებული ოპერაციები: JIT/PAM სესიები, break-glass, admin-consol.
ფინანსები: ფასების სიები/გადასახადები/FX პუბლიკაციები, გადასახადები/გადახდები, სააღრიცხვო, გაუქმება/გადახდა.
კონფიგურაცია/გამოშვებები: ficheflages, სქემების მიგრაცია, გადახრა/გამოტოვება, გასაღებები/სერთიფიკატები.
ინტეგრაცია: ვებჰუკი, ხელმოწერები, ქვითრები, პირადობის გასაღებები.
მონაცემები: PII კითხვა/ექსპორტი, არტეფაქტების შექმნა/მოცილება, პოლიტიკოსის ცვლილებები.

3) არქიტექტურა და უცვლელი

Ingest კარიბჭე ავთენტიფიკაციით, კვოტებით და სქემური დამოკიდებულებით.
WORM საცავი (immutable buckets/append-only): ვერსია, Retention Lock, Legal Hold.
Cryptoquitance: კრიტიკული მოვლენებისთვის, იქმნება 'receipt _ hash "და DSSE ხელმოწერა.
მერკლის ჯაჭვები: პერიოდულად შენდება სექციები, ქვეყნდება ფესვის ჰაში.
ჩქაროსნული გზა: არტეფაქტების გადაადგილების კვალი (ვინ მოიპოვა წვდომა, როდის, რა საფუძველზე).
Time Sync: NTP/PTP, ეტიკეტები 'event _ time' და 'ingest _ time', კორექტირება 'skew'.

4) ღონისძიების სქემა (რეფერენდუმი)


audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human    service    partner, roles[], mfa?, device_posture?
},
action: CREATE    READ    UPDATE    DELETE    EXECUTE    PUBLISH    APPROVE    ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass    fail, justification?, ticket_ref?,
result: success    deny    error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none    aggregated    tokenized    sensitive,
retention_class, labels[]
}

გარდა ამისა: ფინანსებისთვის - 'fx _ version/tax _ rule _ version/pricelist _ version'; ვებჰუკებისთვის - 'webhook _ id', 'idempotence _ key'.

5) მონაცემთა და ზონის მოდელი

ცხელი (ოპერატიული): 7-30 დღე, სწრაფი მოთხოვნები/დაშბორდები.
Warm (OLAP): 6-24 თვე, ანალიტიკა/ძებნა.
ცივი (არქივი/WORM): 7-10 წლამდე (მარეგულირებლის მიხედვით).
აღდგენის კლასები: 'ოპერატიული', 'financial', 'უსაფრთხოება ",' legal _ hold '.
პოლიტიკის ვერსია: ყველა მოვლენა აღინიშნება 'policy _ version "; პოლიტიკის ცვლილება ცალკე აუდიტის მოვლენაა.

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

RBAC/ABAC/ReBAC: ხილვადობა როლში/ტენანტი/რეგიონი/საქმე (საქმე).
PII- ის შენიღბვა: იდენტიფიკატორების ტოქსიკაცია, პირველადი დასკვნა - მხოლოდ დამტკიცებული ჯობის საშუალებით.
პირდაპირი მოცილების აკრძალვა: მხოლოდ 'tombstone' + Legal Hold; ცალკეული ჟურნალის ექსპლოატირებული „დასუფთავება“.
თავად აუდიტის აუდიტი: ვინ დაათვალიერა/ატვირთა ლოგოები - ასევე არის ლოგიკური.

7) ხარისხი, თანმიმდევრულობა, დუბლი

Data contracts: მკაცრი სქემა და შესასვლელი ლამბდა.
Idempotency & dedup: '(event _ id, product) "; «seen-cache» + KV.
დროის კორექტირება: წყლის ნიშნები გვიანდელი მოვლენებისთვის.
სისრულის კონტროლი: წყაროების მრიცხველების შედარება და ingest მეტრიკა.

8) დაშბორდი და მოთხოვნები

ოპერატიული: პრივილეგირებული ქმედებები, SoD დარღვევები, JIT უფლებების ამაღლება, PII- ზე წვდომა.
ფინანსური: პუბლიკაციები FX/Tax/PriceList, შეუსაბამობები @ te - checkout, ძირითადი ხელმოწერები.
ინტეგრაცია: ვებჰუკების ქვითრები, ლაგი, რელეები, დუბლები.
გამოშვებები/კონფისკაციები: ვინ/როდის/რა ჩართვა/გამოტოვება, ინციდენტებთან კავშირი.
საძიებო სცენარები: 'trace _ id', 'subject. id`, `target. id ', დრო/რეგიონი/ტენანტი,' policy _ version '.
ექსპორტი: პაკეტის გადმოტვირთვის მოთხოვნით ქვითრით (ხელმოწერილი მანიფესტი).

9) API და ვებჰუკი

'POST/audit/ingest' - მოვლენების მიღება (ავთენტიფიკაცია, ლიმიტები, სქემა).
'GET/audit/search' - ფილტრები, პაგინაცია, შედეგის ზღვარი.
'GET/audit/trace/{ trace _ id' "- მოვლენების ერთობლიობა ჯაჭვში.
'POST/audit/receipt/verify' - ქვითრის შემოწმება/DSSE.
Вебхуки: `SoDViolation`, `PrivilegedSession`, `PIIAccess`, `PolicyChanged`, `FinancialArtifactPublished`.

10) SLO/აუდიტის ხარისხის მეტრიკა

Ingest Availability: ≥ 99. 95%.
Freshness (ოპერატიული): lag-30 p95-ით.
Completeness: ≥ 99. წყაროების 5% -მა მონაცემები ფანჯარაში გაგზავნა.
Correctness: საკონტროლო თანხების შეუსაბამობა 0. 1%.
Tamper-evidence: პერიოდების 100% დამოწმებულია მერკლის ფესვებით/ხელმოწერებით.
PII Hygiene: მოვლენების 100% მგრძნობიარე კლასით - ნიღაბი/ნიშნით.

11) Playbooks და ინციდენტები

ჩანაწერების ჩანაცვლების ეჭვი: მერკლის ფესვების დაუყოვნებელი შემოწმება, DSSE ქვითრების შერიგება, დაშვების იზოლაცია, იურიდიული ჰოლდი.
PII გაჟონვა: დაზარალებული მოვლენების/ექსპორტის ძებნა, წვდომის აუდიტი, DPO შეტყობინებები/მარეგულირებელი ვადები.
SoD- ის დარღვევა: ოპერაციის ბლოკი, როლის დროებითი ამოღება, გამოძიება და პოლიტიკის კორექტირება.
Ingest- ის უარყოფა: ბუფერიზაცია, დეგრადაციის რეჟიმი, გამოჯანმრთელება, დუბლიკატების კონტროლი.

12) იურიდიული გამძლეობა და შესაბამისობა

ანგარიშსწორება იურისდიქციებში: ფინანსები/გადასახადები - 5-10 წელი; უსაფრთხოება - პოლიტიკის შესახებ; პერსონალური მონაცემები - მინიმალური საჭირო ვადა.
Legal Hold: საქმეში მოცილების გაყინვა/რეგულატორის მოთხოვნა.
საანგარიშო ნიმუშები: პერიოდების ინდექსი, ფესვთა ჰეშები, ხელმომწერების სია, წყაროების ინვენტარი.
შეუსაბამობა: კრიპტოვალუტები, დამოუკიდებელი timestamping (შიდა TSA).

13) iGaming/fintech სპეციფიკა

გადახდა/გადახდა: ავტოკატასტროფების სრული კვალი, კლირინგი, წარუმატებლობა, chargeback; შედარება საბანკო ქვითრებთან.
RTP/limites: პროფილების პუბლიკაციები, RTP- ის მიერ დაფიქსირებული ცვლილებები და გადაწყვეტილებები ლიმიტებზე - ხელმოწერებითა და ვერსიით.
Affiliates: ვებჰუკების მიღება, დედაპლატის კონვერტაცია, წინააღმდეგობა/ესკიზი - მხოლოდ ხელმოწერილი არტეფაქტების მიხედვით.
ფასების სიები/გადასახადები/FX: არტეფაქტის ვერსია თითოეულ შეკვეთაში; გამოტოვება - ქვითრებით.

14) RACI

რეგიონიRACI
არქიტექტურა და WORMPlatform/DataCTOSecurity, LegalAudit
სქემები და პოლიტიკაComplianceCCOData, SecurityProduct
Ingest и ObservabilityData Eng/SREHead of DataPlatformAll
წვდომა და კონფიდენციალურობაSecurity/PrivacyCISO/DPOLegalAudit
იურიდიული მოთხოვნები/ექსპორტებიComplianceCCOLegal, SecurityManagement

15) რისკები და ანტი-ნიმუშები

რედაქტირებული ლოგოები კვალის გარეშე - იურიდიული არარსებობა.
დროის სინქრონიზაციის არარსებობა არის შეუქცევადი დრო.
Shadow ექსპორტები ქვითრების გარეშე, გაჟონვა/დავა.
საიდუმლოებები ლოგოებში და კომპრომისზე.
არანაირი კავშირი არ არსებობს SLO/ინციდენტებთან - „მონაცემთა სასაფლაოზე“ სარგებლის გარეშე.

16) განხორციელების შემოწმების სია

  • განსაზღვრეთ საფარის სფეროები და პოლიტიკა _ ვერსია.
  • განლაგება ingest ავთენტიფიკაციით, სქემებით და კვოტებით.
  • ჩართეთ WORM, Merkle ნაჭრები, DSSE ხელმოწერები, TSA.
  • კონფიგურაცია კლასებსა და იურიდიულ ჰოლდში.
  • შეიყვანეთ RBAC/ABAC/ReBAC და ჟურნალების წვდომის აუდიტი.
  • დაშბორდის აშენება: პრივილეგიები, PII, ფინანსები, გამოშვებები/კონფისკაცია.
  • ჩართეთ playbuks: tamper, PII გაჟონვა, ingest უარი, SoD დარღვევა.
  • შეამოწმეთ აბრეშუმი და დედაპლატი ტესტის ნაკრებში.
  • ჩამოაყალიბეთ ექსპორტი ქვითრებით და მოთხოვნის რეესტრით.
  • კვარტალურად გაიარეთ ხარისხის მეტრიკის აუდიტი (freshness/completeness/tamper).

17) FAQ

შესაძლებელია თუ არა ყველაფრის შენახვა ჩვეულებრივ მონაცემთა ბაზაში?
ოპერაციისთვის - დიახ, მაგრამ კრიტიკული ჟურნალები უნდა იყოს დუბლირებული WORM/append-only- ში ხელმოწერებით და მერკლის სექციებით.

აუცილებელია მონაცემების თითოეული კითხვის დაფიქსირება?
PII/ფინანსების კითხვა - აუცილებელია; დანარჩენი - პოლიტიკასა და ღირებულებაში.

როგორ დავამტკიცოთ უცვლელობა?
ფესვის ჰეში, DSSE ხელმოწერები, დამოუკიდებელი TSA და რეპროდუქციული შემოწმების პროცედურები.

რა უნდა გავაკეთოთ „მოცილების უფლებით“ (GDPR)?
ამოიღეთ პირველადი დამუშავების სისტემები; აუდიტის ჟურნალებში - შეინახეთ ნიშნები/ჰეშები აღდგენილი PII- ის გარეშე და უხელმძღვანელეთ ლეგალურ ჰოლდს საჭიროების შემთხვევაში.

რეზიუმე: აუდიტის ჟურნალები არ არის „logs in S3“, არამედ კრიპტოგრაფიულად დადასტურებული მოქმედების ისტორია მკაფიო პოლიტიკით, უცვლელი შენახვით, კონტროლირებადი დაშვებით და დავის/მარეგულირებელი შემოწმების მზადყოფნით. ააშენეთ ინვესტიცია კონტრაქტებით, მოაწერეთ კრიტიკულ მოვლენებს, მხარი დაუჭირეთ მერკლის ნაჭრებსა და დაშბორდებს - და თქვენ გექნებათ სანდო საფუძველი ნდობის, უსაფრთხოებისა და შესაბამისობისთვის.

Contact

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

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

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

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

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

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