აუდიტი და უცვლელი ჟურნალები

აუდიტი და უცვლელი ჟურნალები

1) რატომ არის ეს აუცილებელი?

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

2) მუქარის მოდელი და კონტროლის მიზანი

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

1. მთლიანობა: დადასტურებული დაცვა მოდიფიკაციებისა/წაშლისგან.

2. სისრულე: საკონტროლო ნაკადის დახურვა (საკონტროლო თვითმფრინავი, მონაცემთა თვითმფრინავი, წვდომა, ფული).

3. დროის სიზუსტე: რეპროდუცირებული, სინქრონიზებული დრო.

4. წვდომა: კითხვა და ძებნა SLO- ში.

5. კონფიდენციალურობა: მინიმალური PII, ტოკენიზაცია/დაშიფვრა, გამოყენების კანონიერება.

3) ტაქსონომია და მოვლენების პრიორიტეტები

• Control Plane: ავთენტიფიკაცია/ავტორიზაცია, კონფიგურაციის შეცვლა, კლავიშებით ოპერაციები (KMS), საიდუმლოების მართვა, პოლიტიკოსის შეცვლა.
• Data Plane: ობიექტების/ჩანაწერების/შემოწმების/გადახდების წვდომა; კითხვა/შექმნა/მოცილება.
• ადმინი და DevOps: SSH/კონსოლი, CI/CD, ინფრასტრუქტურის ცვლილებები/IaC, უფლებების ესკალაცია.
• სასურსათო: გარიგებები, ბილინგი, მომხმარებელთა ოპერაციები.
• სისტემური/ქსელი: ბირთვი/აგენტები/მარიონეტები/ბალანსები, ბროკერები, BD.
• უსაფრთხოება: IDS/IPS/EDR, WAF, ანტი-DDoS, ანტიფროდი, DLP.

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

4) სავალდებულო ველები და ფორმატი

კორელაციის იდენტიფიკატორები: 'trace _ id', 'spank _ id', 'request _ id', 'actor _ id' (მომხმარებელი/სერვისი), 'tenant _ id', 'resource _ id'.
A&A კონტექსტი: ავთენტიფიკაციის მეთოდი, როლი/პოლიტიკა მოქმედების დროს.
დრო: RFC339/UTC, მილიწამები/ნანოეკუნები; სინქრონიზაციის წყარო.
მოქმედება და შედეგი: ოპერაციის ტიპი, მიზანი, სტატუსი, დაზარალებული ობიექტების რაოდენობა.
მთლიანობა: ადგილობრივი HMAC ჩანაწერები, სერიული ნომერი (sequence), hash-prev.
სქემა: JSON სტაბილური მოდელით (მაგალითად, მოვლენების საერთო ლექსიკონებთან თავსებადი).

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

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

დროის წყარო: მინიმუმ ორი დამოუკიდებელი წყარო (NTP/PTP) + გადაადგილების მონიტორინგი.
კრიტიკული დროის ხელმოწერები: გამოიყენეთ დროის სანდო ნიშნის სერვისები (TSA) ან შიდა დროის შეკვეთის სერვისი მოვლენების პაკეტებისთვის.
წესები: არ არსებობს ადგილობრივი დროის ზონები, მხოლოდ UTC; დროის გადაადგილება და ხარისხი.

6) ლოგების ნაკადის არქიტექტურა

აგენტები - ბუფერი - ტრანსპორტი - ლენდინგი - ჰეშის ჯაჭვი/ხელმოწერა - ცივი/არქივი. საძიებო ინდექსი.

კვანძის შეგროვება: მსუბუქი აგენტები (daemonset/sidecar) ბუფერით დისკზე (უკუკავშირი).
ტრანსპორტი: დაცული არხი (TLS/mTLS), გარანტირებული მიწოდება (at-least-once), idempotent ingest.
Landing ზონა: ობიექტის საცავი „ნედლეულის“ ფორმით (წვეულებები თარიღით/ტენანტით/ტიპით).
ინდექსი: საძიებო ძრავა/ანალიტიკა ონლაინ მოთხოვნებისთვის (ცხელი ფენა).
არქივი (WORM): უცვლელი ბაქტერიები/ფირები რეტენციისა და იურიდიული ჰოლდინგის პოლიტიკოსებთან.
Anchor/Seal: პერიოდული „შეფუთვა“ hash ჯაჭვების პაკეტები (იხ. ქვემოთ).

7) კრიპტოგრაფიული უცვლელი

7. 1 ჰაშის ჯაჭვები (append-only)

თითოეული ჩანაწერი შეიცავს: 'hash _ curr = H (ჩანაწერები)', 'hash _ prev' წინა ჩანაწერიდან, 'seq'. ნებისმიერი რედაქტირება არღვევს ჯაჭვს.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 პაკეტების ხელმოწერა და დროის ბეჭედი

ყოველ N წამში/MB ჩვენ ვქმნით ბლოკს: მერკლის ფესვი ყველა 'hash _ curr'.
ჩვენ ვაწარმოებთ ბლოკს აუდიტის გასაღებით (სტაბილურად შენახული KMS/HSM- ში).
დაამატეთ TSA დროის ნიშანი და გამოაქვეყნეთ „ბლოკის კატალოგი“.
სურვილისამებრ: პერიოდულად ვიღებთ ფესვებს გარე დადასტურებულ სივრცეში (მაგალითად, დამოუკიდებელი ჟურნალი ან საზოგადოებრივი უცვლელი საცავი).

7. 3 აუდიტის ღილაკების კონტროლი

ხელმოწერის გასაღებები - KMS/HSM- ში, გრაფიკის როტაცია, მულტიფაქტორული წვდომა, ექსპორტის ორმაგი კონტროლი.
გასაღების მიმოხილვა - ნდობის ახალი ფილიალი; ძველი ხელმოწერები შემოწმებულია.

8) შენახვის პოლიტიკა და WORM

WORM/immutability: P0/P1 კლასებისთვის ჩართეთ უცვლელი კონტეინერები/ტანკები Retention და Legal Hold პოლიტიკით.
ვერსია: ჩართვა; მოცილება - მხოლოდ პროცედურების შეფერხებით (მყისიერი აკრძალვა).
რეპეტიცია: ცხელი (7-30 დღე), თბილი (3-6 თვე), ცივი/არქივი (1-7 წელი ან მეტი - რეგულატორის/ხელშეკრულების მიხედვით).
მრავალფუნქციურობა: ინდივიდუალური სახელების/ჩანაწერების/დაშიფვრის გასაღებები მოიჯარეზე; ჟურნალების წვდომის ანგარიში.

9) კონფიდენციალურობა და მინიმიზაცია

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

10) თავად აუდიტის წვდომა, როლები და აუდიტი

გამიჯვნა: producers-readers-admins.
მხოლოდ WORM- ის კითხვა; რეცენზიის პოლიტიკის ცვლილება - ცალკეული როლებისა და დამტკიცების გზით.
კითხვის/ექსპორტის ყველა ოპერაცია ჟღერს მეორად ჟურნალში (მეტა-აუდიტი).
ექსპორტი გამოძიებისთვის/შესაბამისობისთვის - დაშიფრული ფორმით, მძიმე ბლოკების კატალოგით და ნდობის ჯაჭვით.

11) დაკვირვება და SLO

მეტრიკა: ინჟესტის სიჩქარე, ინდექსამდე კალმები, დაკარგული/განმეორებითი%, არაპროგნოზირებადი დროის წილი, ხელმოწერის/წამყვანების შეცდომები, ბუფერების შევსება.
SLO: ≥99. მოვლენების 9% X წამში გადაეცა ცხელ ინდექსს; თანმიმდევრობით 0 აუხსნელი „ხვრელი“; ბლოკების 100% გაფორმებულია და დროულად იწერება.
ალერტები: ინჟესტის პაუზა> N წუთი, invalid-hash ზრდა, ჯაჭვის შეუსაბამობა, ხელმოწერის/timstamp- ის წარუმატებლობა, ბარიერის დროის გადაადგილება.

12) ტესტირება და გადამოწმება

Red/Blue ტესტები: სხვადასხვა ეტაპზე ჩაწერის რედაქტირების/ამოღების მცდელობა; გამოვლენის შემოწმება.
ქაოსი: აგენტის გათიშვა კვანძზე, ქსელის რღვევა, ბუფერული გადატვირთვა, „დროის შეცვლა“.
კრიპტო შემოწმება: ჯაჭვების რეგულარული შემოწმება, მერკლის ფესვების შერწყმა და კლიშეები.
Forenzic: საგამოძიებო სცენარების რეპროდუქცია ჟურნალებიდან end-to-end.

13) ოპერაცია და პროცედურები

Runbook „მთლიანობის შემოწმება“ (on-demand და გრაფიკით).
ლეგალური ჰოლდინგის პროცედურა და პარტიების დროებითი „გაყინვა“.
Discovery და ექსპორტის პროცედურა ნდობის ჯაჭვის შენარჩუნებით.
აუდიტის გასაღებების როტაციის გეგმა და კომპრომისზე რეაგირება (ნდობის ახალი ფილიალი, ბლოკის კალმის ხელმოწერა, შეტყობინებები).

14) მინი რეცეპტები

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Control/Data P0: ცხელი 30 დღე - თბილი 6 თვე - 7 წლის არქივი (WORM).
• DevOps: ცხელი 14 დღე - თბილი 3 თვე - არქივი 1 წელი.
• Security სიგნალები: ცხელი 90 დღე (გამოძიებისთვის), შემდეგ 1-3 წელი.

15) ხშირი შეცდომები

„ლოგიკა არის ტექსტი სქემის გარეშე“. სქემის გარეშე, არ არსებობს დეტერმინისტული მთლიანობა და ძებნა; სავალდებულოა კანონიკური JSON და ფიქსირებული ველები.
არ არსებობს კორელაცია. Trace _ id- ის არარსებობა არღვევს გამოძიებას.
ადგილობრივი დრო. მხოლოდ UTC და გადაადგილების კონტროლი.
ცვალებადი ტომის ჩაწერა. WORM- ის გარეშე, ნებისმიერი უცვლელი - მხატვრული ლიტერატურა.
წაკითხული არ არის. მგრძნობიარე მონაცემების კითხვა მნიშვნელოვანია ჩაწეროთ არანაკლებ ჩანაწერი.
საიდუმლოებები ლოგებში. ჩართეთ ექთნები გაგზავნამდე, შაბლონების „წითელი სიები“.
ერთი გასაღები ყველაფრისთვის. ხელმოწერისა და დაშიფვრის გასაღებები ცალკე, როლით და როტაციით.

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

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

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

გაყიდვამდე

• დამტკიცდა მოვლენების ტაქსონომია და სქემა (სავალდებულო ველები).
• აგენტები, ბუფერები, დაცული ტრანსპორტი, უკან დაბრუნება.
• ჩართულია: ჰაშის ჯაჭვები, ბლოკის ხელმოწერა, დროის ბეჭედი, გამჭვირვალობა-ლოგი.
• WORM/Retention საცავი; ტესტი გადაწერის/მოცილების შეუძლებლობის შესახებ.
• მგრძნობიარე ველების შენიღბვა/ტოქსიკაცია.

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

• აუდიტის გასაღებების როტაციისა და შენახვის გეგმა KMS/HSM- ში.

ოპერაცია

• ჯაჭვებისა და ბლოკების ყოველკვირეული შესაბამისობა (+ ანგარიში).
• ალერტას ჯაჭვის რღვევა/ხელმოწერის შეცდომა/დროის გადაადგილება.
• პერიოდული წითელი გუნდის ტესტები ჩანაცვლების/მოცილების შესახებ.
• რეცენზიებისა და ხარჯების რეგულარული მიმოხილვა.

18) FAQ

გ: საკმარისია მხოლოდ „მხოლოდ დამატება“ BD დონეზე?
ო: არა. ჩვენ გვჭირდება კრიპტოგრაფიული გარანტიები (ჰაშის ჯაჭვები, ბლოკების ხელმოწერები, დროის ბეჭდები) და WORM პოლიტიკა.

გ: როგორ მოვიშოროთ მონაცემები?
O: შეიმუშავეთ კრიპტო-წაშლა (გასაღებების მოცილება) ველების/წვეულებებისთვის, შეინარჩუნეთ გადამზიდავი უცვლელი და ჟურნალების დადასტურება.

გ: საჭიროა ცალკეული გასაღები ბლოკის ხელმოწერისთვის?
ო: დიახ. ბლოკის ხელმოწერის გასაღებები განცალკევებულია შენახვის დაშიფვრის ღილაკებისგან; შეინახეთ KMS/HSM- ში, როტაციით და აუდიტით.

გ: შესაძლებელია თუ არა საზოგადოებრივ სივრცეში „წამყვანობა“?
ო: სურვილისამებრ. ეს აძლიერებს შემოწმებას და შეწყვეტს კონტურის შიგნით „ისტორიის გადაწერას“.

• „დაშიფვრა At Rest“
• „დაშიფვრა In Transit“
• საიდუმლო მენეჯმენტი
• „კლავიშების მართვა და როტაცია“
• „მოთხოვნის ხელმოწერა და გადამოწმება“