Аудит және өзгермейтін журналдар

Аудит және өзгермейтін журналдар

1) Бұл не үшін қажет

Аудиттің мақсаты - қауіпсіздікті, тергеуді, қаржылық есептілікті және талаптарға сәйкестікті қолдау үшін «кім, не, қайда, қашан және неліктен» дәлелденетін тұтастықпен белгілеу.
Өзгермейтін журнал - оқиғалар тек қосу арқылы жазылатын (append-only), ал кейінгі өзгерту/жою не мүмкін емес, не криптографиялық құралдармен және сақтау саясатымен байқалатын формат және сақтау орны.

2) Қатерлер моделі және бақылау мақсаттары

• Инсайдердің оқиғаларды қасақана түзету/жою.
• Уақытты/көзді ауыстыру (replay/backdating).
• Торапта логингті «үнсіз» өшіру.
• Авария/көші-қон кезінде журналдың бір бөлігін жоғалту.
• PII артық жинау және жекешелендiрумен жөнсiздiк.

1. Тұтастығы: түрлендіруден/жоюдан қорғаумен дәлелденетін.

2. Толықтығы: негізгі ағындарды жабу (control plane, data plane, қолжетімділік, ақша).

3. Уақыт дәлдігі: ойнатылатын, үндестірілген уақыт.

4. Қол жетімділік: SLO шегінде оқу және іздеу.

5. Құпиялылық: минимум PII, токенизация/шифрлау, пайдалану заңдылығы.

3) Оқиғалардың таксономиясы мен басымдықтары

• Control Plane: аутентификация/авторизация, конфигурация өзгерістері, кілттер операциялары (KMS), құпияларды басқару, саясатты өзгерту.
• Data Plane: объектілерге/жазбаларға/чектаутқа/төлемдерге қол жеткізу; оқу/жасау/жою.
• Әкімшілік және DevOps: SSH/консоль, CI/CD, инфрақұрылымды өзгерту/IaC, құқықтарды күшейту.
• Өнімдік: транзакциялар, биллинг, клиенттердің операциялары.
• Жүйелік/желілік: ядро/агенттер/прокси/теңгерімдер, брокерлер, ДҚ.
• Қауіпсіздік: IDS/IPS/EDR, WAF, анти-DDoS, антифрод, DLP.

Әрбір сынып үшін критикалылықты, схеманы, міндетті өрістерді, сақтау мерзімін, өзгермеушілікке қойылатын талаптарды белгілейміз.

4) Міндетті өрістер және пішім

Корреляция идентификаторлары: 'trace _ id', 'span _ id', 'request _ id', 'actor _ id' (пайдаланушы/қызмет), 'tenant _ id', 'resource _ id'.
A&A контексті: аутентификация тәсілі, әрекет ету сәтіндегі рөлдер/саясат.
Уақыты: RFC3339/UTC, миллисекунд/наносекунд; үндестіру көзі.
Іс-әрекет және нәтиже: операция түрі, мақсаты, мәртебесі, қозғалған объектілердің саны.
Тұтастығы: жергілікті HMAC жазба, реттік нөмірі (sequence), hash-prev.
Сұлба: Тұрақты үлгісі бар JSON (мысалы, оқиғалардың ортақ сөздіктерімен үйлесімді).

Құпия сөздерге, кілттерге, толық PAN белгілеріне, құпия сөздерге, жеке кілттерге тыйым салынады. PII - тек қажеттілігіне қарай, бүркемелеумен/токенизациялаумен.

5) Уақыт және синхрондау

Уақыт көзі: кем дегенде екі тәуелсіз көз (NTP/PTP) + ығысу мониторингі.
Уақыттың сыни қолтаңбалары: уақытты сенімді белгілеу (TSA) қызметтерін немесе оқиғалар бумасы үшін ішкі time-sealing қызметін пайдаланыңыз.
Ережелер: жергілікті уақыт белдеулері жоқ, тек UTC; логикалау және ығысу/уақыт сапасы.

6) Логтар ағынының архитектурасы

Агенттер → Буфер → Көлік → Лэндинг → Хэш-тізбегі/қолы → Суық/Мұрағат → Іздеу индексі.

Торапта жинау: дискіде буфері бар жеңіл агенттер (daemonset/sidecar) (back-pressure).
Көлік: қорғалған арна (TLS/mTLS), кепілдендірілген жеткізу (at-least-once), idempotent-ingest.
Лэндинг-аймақ: «шикі» түрдегі объектілік қойма (күні/тенанты/типі бойынша партиялар).
Индекс: online-сұрауларға арналған іздеу/талдау қозғалтқышы (ыстық қабат).
Мұрағат (WORM): ретенция саясаты және заңды hold.
Anchor/Seal: хэш-тізбектердің бумаларын мерзімді «дәнекерлеу» (төменде қараңыз).

7) Криптографиялық өзгермеушілік

7. 1 Хеш тізбегі (append-only)

Әрбір жазбада: 'hash _ curr = H (record)', '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 секунд/МБ блок қалыптастырамыз: Меркл түбірі барлық 'hash _ curr'.
Блокқа аудит кілтімен қол қоямыз (тұрақты түрде KMS/HSM-де сақталады).
TSA уақыт белгісін қосып, «блоктар каталогын» (Transparency Log) жариялаймыз.
Опциондық: сыртқы дәлелденетін кеңістікке мерзімді түрде түбір хэш зәкірі (мысалы, тәуелсіз журнал немесе көпшілік алдында өзгермейтін сақтау орны).

7. 3 Аудит кілттерін басқару

Қол қою кілттері - KMS/HSM-де, кесте бойынша ротация, көп факторлы қолжетімділік, экспорт үшін dual-control.
Кілтті қайтару → сенімнің жаңа тармағы; ескі қолтаңбалар тексеріледі.

8) Сақтау саясаты және WORM

WORM/immutability: P0/P1 сыныптарына арналған Retention және Legal Hold саясаты бар өзгермейтін контейнерлерді/бакеттерді қосамыз.
Нұсқалау: қосылған; жою - кешіктірілген процедуралар бойынша ғана (жедел purge тыйым салу).
Ретенция: ыстық (7-30 күн), жылы (3-6 ай), суық/мұрағат (реттегішке/келісімшартқа байланысты 1-7 жыл және одан да көп).
Көп жалдау қабілеті: жалдаушыға жеке аттардың/есепке алудың/шифрлау кілттерінің кеңістігі; журналдарға кіру бойынша есептілік.

9) Жекешелендіру және барынша азайту

Қажеттілік принципі бойынша алым: артық емес.
Сезімтал өрістерді токенизациялау/псевдонимизациялау, идентификаторлар үшін тұзы бар хэш.
Ортақ объектілік қоймада сақтау кезінде продьюсер (AEAD) жағындағы өрістерді шифрлау.
Алып тастау құқығы (қолданылатын жерде): контейнердің өзгермейтіндігін бұзбай, өрістердің/партиялардың кілттерін крипто-өшіру арқылы іске асырылады (жобалау кезінде жоспарланады).

10) Аудиттің өзінің қолжетімділігі, рөлі және аудиті

producers ≠ readers ≠ admins.
WORM бағдарламасынан тек оқу; ретенция саясатының өзгеруі - жекеленген рөлдер мен мақұлданған рәсімдер арқылы.
Барлық оқу/экспорт операциялары қайталама журналға (мета-аудит) жазылады.
Тергеу/комплаенс үшін экспорт - хэш-блоктар каталогы және сенім тізбегі бар шифрланған түрде.

11) Бақылау және SLO

Өлшемдер: инжест жылдамдығы, индекске дейінгі лаг, жоғалған/қайталанған%, синхронизацияланбаған уақыт үлесі, қол қою/зәкірлеу қателіктері, буферлерді толтыру.
SLO: ≥99. Оқиғалардың 9% ыстық индекске дейін X сек ≤ жеткізілді; тізбектегі 0 түсіндірілмейтін «тесіктер»; Блоктардың 100% уақытпен қол қойылған және таңбаланған.
Алерта: инжест үзілісі> N минут, invalid-hash өсуі, тізбектің ажырасуы, қолтаңбаның/таймстамптың сәтсіздігі, уақыттың табалдырықтан жылжуы.

12) Тестілеу және верификация

Red/Blue тестілері: әртүрлі сатылардағы жазбаларды өңдеу/жою әрекеті; детекторлауды тексеру.
Chaos: тораптағы агентті өшіру, желіні үзу, буферді толтыру, «уақытты ауыстыру».
Крипто-тексерулер: тізбектерді тұрақты валидациялау, Меркл тамырлары мен мөртабандарды салыстыру.
Форензия: end-to-end журналдарынан тергеу сценарийлерін шығару.

13) Пайдалану және рәсімдер

Runbook «бүтіндігін тексеру» (on-demand және кесте бойынша).
Legal hold және партияларды уақытша «мұздату» рәсімі.
Сенім тізбегін сақтай отырып, 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 plane P0: ыстық 30 күн → жылы 6 ай → 7 жыл мұрағат (WORM).
• DevOps: ыстық 14 күн → жылы 3 ай → мұрағат 1 жыл.
• Секурити-сигналдар: ыстық 90 күн (тергеу үшін), содан кейін 1-3 жыл.

15) Жиі қателер

«Логи - бұл схемасыз мәтін». Схемасыз детерминирленген тұтастық пен іздеу жоқ; канонды JSON және тіркелген өрістер міндетті.
Корреляция жоқ. 'trace _ id' болмауы тексерулерді бұзады.
Жергілікті уақыт. Тек UTC және жылжуды бақылау.
Өзгертілетін томдарға жазу. WORM-сіз кез келген өзгермеушілік - фикция.
Оқу логин жоқ. Сезімтал деректерді оқу жазбадан кем емес жазу үшін маңызды.
Жылғалардағы құпиялар. Жөнелтілгенге дейін санитайзерлерді, паттерндердің «қызыл тізімдерін» қосыңыз.
Барлығына бір кілт. Қол қою және шифрлау кілттері - жеке, рөлі мен ротациясы бар.

16) Сәйкестік және реттеу

Сақтау/өзгермеу мерзімдеріне қойылатын талаптар доменге (қаржы, төлем, телеком және т.б.) байланысты.
Дәлелденуі: WORM/ретенция хаттамаларының, тізбектерді валидациялау есептерінің, журналдарға қол жеткізу журналдарының, legal hold және экспорт рәсімдерінің болуы.

17) Чек парақтары

Азық-түлік алдында

• Оқиғалардың таксономиясы және схемасы бекітілді (міндетті өрістер).
• Реттелген агенттер, буферлер, қауіпсіз көлік, back-pressure.
• Енгізілген: хештер тізбегі, блоктық қолтаңба, уақыт мөртабаны, transparency-лог.
• WORM/ретенция қоймасы қосылған; қайта жазу/жою мүмкін еместігіне арналған тест.
• Сезімтал өрістерді бүркемелеу/токенизациялау.
• Уақытты синхрондау және ығысу мониторингі.
• Ротация жоспары және аудит кілттерін KMS/HSM-де сақтау.

Пайдалану

• Тізбектер мен блоктардың апта сайынғы валидациясы (+ есеп).
• Тізбекті үзу/қолтаңба қателері/уақыт ығысуы.
• Ауыстыру/жою үшін мерзімді Red-team тестілері.
• Ретенциалдар мен шығындардың тұрақты шолуы.

18) FAQ

С: ДБ деңгейінде жай ғана «қосу» жеткілікті ме?
О жоқ. Криптографиялық кепілдіктер (хештер тізбегі, блоктардың қолтаңбалары, уақыт мөртабандары) және WORM саясаты қажет.

С: Деректерді жою құқығымен не істеу керек?
О: Тасығыштың өзгермейтіндігі мен журналдардың дәлелденетіндігін сақтай отырып, өрістер/партиялар үшін крипто-өшіруді (кілттерді жоюды) жобалаңыз.

С: Блоктарға қол қою үшін жеке кілт қажет пе?
О: Иә. Блоктардың қолтаңба кілттерін сақтау шифрлау кілттерінен бөліңіз; KMS/HSM-де, ротациямен және аудитпен сақтаңыз.

С: Көпшілік кеңістікке «зәкірлеуге» бола ма?
О: Опциондық. Бұл тексеруді күшейтеді және контур ішіндегі «тарихты қайта жазуды» ажыратады.

• «At Rest шифрлау»
• «In Transit шифрлау»
• «Құпия менеджменті»
• «Кілттерді басқару және ротация»
• «Сұрау салуларға қол қою және тексеру»