Операциялар аудитінің журналдары

(Бөлім: Операциялар және Басқару)

1) Мақсаты және қағидаттары

Аудит журналы - жазбалардың өзгермейтіндігі мен түпнұсқалығын дәлелдеу мүмкіндігімен кім, не, қайда, қашан және неліктен жасағаны туралы ақиқаттың бастапқы көзі.

• Толымдылық: адамдардың, сервистердің және сыртқы әріптестердің іс-әрекеттері жабылған.
• Өзгермейтіндігі: жазбаларды көрінетін ізсіз қайта жазуға/жоюға болмайды.
• Атрибуция: әрекет субъектімен, рөлмен, контекстпен, артефакттармен байланысты.
• Ойнатылу: оқиғаны есеп/дауда ойнатуға болады.
• PII барынша азайту: тек қажетті, бетпермен және токендермен.

2) Жабу аумағы

Пайдаланушы әрекеттері: кіру/SSO/MFA, рөлдерді/лимиттерді өзгерту, PII операциялары.
Артықшылықты операциялар: JIT/PAM-сессиялар, break-glass, әкімші-консоль.
Қаржы: прайс-парақтар/салықтар/FX жарияланымдар, төлемдер/төлемдер, эскроу, есептен шығару/қайтарулар.
Конфигурациялар/релиздер: фичефлагтар, схемалардың көші-қоны, деплой/кері қайту, кілттер/сертификаттар.
Интеграциялар: вебхактар, қолтаңбалар, түбіртектер, idempotency-кілттер.
Деректер: PII оқу/экспорттау, артефактілерді жасау/жою, саясаттағы өзгерістер.

3) Сәулет және өзгермейтін

Ingest-шлюз аутентификациямен, квоталармен және схемалық валидациямен.
WORM-сақтау орны (immutable buckets/append-only): нұсқа, Retention Lock, Legal Hold.
Криптоквитанциялар: сыни оқиғалар үшін 'receipt _ hash' және DSSE-қолтаңба қалыптастырылады.
Merkle тізбектері: мерзімді түрде кесінділер (checkpoint) жасалады, түбірлік хэш жарияланады.
Chain of custody: артефактілерді жылжыту трассасы (кімге, қашан, қандай негізде қол жеткізілді).
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', 'idempotency _ key'.

5) Деректер моделі және аймақтар

Hot (жедел): 7-30 күн, жылдам сұраулар/дашбордтар.
Warm (OLAP): 6-24 ай, талдау/іздеу.
Cold (мұрағат/WORM): 7-10 жасқа дейін (реттеуіш бойынша).
Ретенция кластары: 'operational', 'financial', 'security', 'legal _ hold'.
Саясаттың нұсқасы: барлық оқиғалар 'policy _ version' деп белгіленген; саясатты өзгерту - жеке аудит оқиғасы.

6) Қолжетімділік және құпиялылық

RBAC/ABAC/ReBAC: рөлі/тенанты/аймағы/іс (case) бойынша көріну.
PII бүркемелеу: сәйкестендіргіштерді токенизациялау, бастауышты шығару - тек қана мақұлданған джобтар арқылы.
Тікелей жоюға тыйым салу: тек 'tombstone' + Legal Hold; жеке журналмен жоспарланатын «толық тазарту».
Аудиттің өзінің аудиті: журналды кім көрді/түсірді - ол да логин жасайды.

7) Сапа, консистенттілік, дубль

Data contracts: кіре берістегі қатаң схема және лямбда-валидация.
Idempotency & дедуп: '(event_id, producer)'; «seen-cache» + KV.
Уақытты түзету: кеш оқиғалар үшін су таңбалары (watermarks).
Толықтығын бақылау: көздер есептеуіштерін және ingest-метриктерді салыстыру.

8) Дашбордтар және сұрау салулар

Жедел: артықшылықты әрекеттер, SoD-бұзушылықтар, JIT-құқықтарды көтеру, PII-ге қол жеткізу.
Қаржылық: FX/Tax/PriceList жарияланымдары, алшақтықтар quote 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 (оперативка): лаг ≤ 30 с p95.
Completeness: ≥ 99. Деректердің 5% терезеге деректер жіберді.
Correctness: бақылау сомаларының алшақтығы ≤ 0. 1%.
Tamper-evidence: 100% мерзім Merkle-тамырымен/қолтаңбаларымен расталған.
PII Hygiene: 100% сезімтал сыныпты оқиғалар - маска/токенмен.

11) Плейбуктер мен инциденттер

Жазбаларды ауыстыру күдігі: дереу Merkle-тамырларын тексеру, DSSE-түбіртектерін салыстыру, қолжетімділікті оқшаулау, Legal Hold.
PII жылыстауы: қозғалған оқиғаларды/экспортты іздеу, қол жеткізу аудиті, DPO/реттеушіге мерзімі бойынша хабарлау.
SoD бұзылуы: операция блогы, рөлді уақытша алып тастау, саясатты тексеру және түзету.
Бас тарту: буферлеу, тозу режимі, қалпына келтірілгеннен кейін реплика, телнұсқаларды бақылау.

12) Заңдық төзімділік және комплаенс

Юрисдикциялар бойынша retention: қаржы/салықтар - 5-10 жыл; қауіпсіздік - саясат бойынша; дербес деректер - ең аз қажетті мерзім.
Legal Hold: іс/реттегіштің сұрауы бойынша жоюды тоқтату.
Есептік артефактілер: кезеңдер индексі, түбірлік хэштер, қол қоюшылар тізімі, көздерді түгендеу.
Ажыратылмаушылық: криптоқойма, тәуелсіз timestamping (ішкі TSA).

13) iGaming/финтех ерекшелігі

Төлемдер/төлемдер: авторизацияларды, клирингті, бас тартуларды, chargeback толық трассалау; банк түбіртектерімен салыстыру.
RTP/лимиттер: профильдерді жариялау, өзгерістер, бақыланатын RTP және лимиттер бойынша шешімдер - қолдарымен және нұсқасымен.
Аффилиаттар: вебхуктарды қабылдау, конверсиялар дедупы, қарсылықтар/эскроу - қол қойылған артефактілер бойынша ғана.
Прайс-парақтар/салықтар/FX: әрбір тапсырыстағы артефактінің нұсқасы; қайтару - түбіртектермен.

14) RACI

15) Тәуекелдер және қарсы паттерндер

Ізсіз өңделетін логтар → заңдық қолдау көрсетпеу.
Уақыттың үндестірілмеуі → сәйкес келмейтін таймлайндар.
Shadow-экспорт түбіртектерсіз → ағып кету/даулар.
Логтардағы құпиялар → компромат.
SLO/инциденттермен байланыс жоқ → «деректер зираты» пайдасыз.

16) Енгізу чек-парағы

• Жабу және policy_version аумақтарын анықтау.
• Аутентификациямен, схемалармен және квоталармен ingest өрістету.
• WORM, Merkle бөліктерін, DSSE қолтаңбаларын, TSA қосыңыз.
• Ретенцияны сыныптар және Legal Hold бойынша теңшеу.
• RBAC/ABAC/ReBAC және журналдарға кіру аудитін енгізіңіз.
• Дашбордтар құру: артықшылықтар, PII, қаржы, релиздер/конфиги.
• Плейбуктерді қосу: tamper, PII-ағып кету, ingest-бас тарту, SoD-бұзылу.
• Тест жиынтығында репликаны және дедупты сынап көру.
• Квитанциялармен және сұрау тізілімімен экспорттауды реттеу.
• Тоқсан сайын сапа метрикасының аудитінен өту (freshness/completeness/tamper).

17) FAQ

Бәрін де кәдімгі ДБ-да сақтауға бола ма?
Оперативтілік үшін - иә, бірақ сындарлы журналдар WORM/append-only-де қолтаңбалармен және Merkle-тіліктерімен қайталануы тиіс.

Деректерді әрбір оқуды логикалау қажет пе?
PII/қаржыны оқу - міндетті түрде; қалғаны - саясат пен құн бойынша.

Өзгермейтіндігін қалай дәлелдеуге болады?
Түбірлік хэштер, DSSE қолтаңбалары, тәуелсіз TSA және қайталанатын тексеру процедуралары.

«Жою құқығымен» (GDPR) не істеу керек?
Өңдеу жүйелеріндегі бастапқы мәнді жойыңыз; аудит-журналдарда - токендерді/хэштерді қалпына келтірілмейтін PII-сыз сақтаңыз және қажет болған жағдайда Legal Hold-ды жүргізіңіз.

Түйіндеме: Аудит журналдары - бұл «S3-дегі логтар» емес, нақты саясатпен, өзгермейтін сақтаумен, басқарылатын қолжетімділікпен және дауға/реттеушілік тексеруге дайындықпен іс-қимылдардың криптографиялық дәлелденетін тарихы. Келісімшарттар бойынша ingest құрыңыз, сындарлы оқиғаларға қол қойыңыз, Merkle-бөліктер мен дашбордтарды қолдаңыз - сенімнің, қауіпсіздіктің және комплаенстің сенімді іргетасына ие боласыз.