PII жылыстағанда сұрау мәтінінсіз аудит журналдары жете ме?

Сұрау мәтіні жоқ аудит журналдары көбіне әрекеттер тізбегін анықтауға жетеді: шақыруды кім жіберді, қай кілтті қолданды, қандай саясат іске қосылды, сұрау қайда бағытталды және қолжетімділікті тексеру немен аяқталды. Бірақ олар нақты ЖСН-ды, телефон нөмірін немесе диагнозды қалпына келтіре алмайды. Егер тергеу «Қандай дербес дерек сыртқа шықты?» деген сұраққа жауап беруі керек болса, метадеректің өзі жеткіліксіз.

Бұл сұрау денесін үнемі жазып отыру керек деген сөз емес. Ондай журнал алғашқы жылыстаудың қасына екіншісін жасап береді: журналға көбірек адам қол жеткізеді, сақтау мерзімі ұзарады, ал көшірмелер іздеу индексіне, SIEM жүйесіне және резервтік архивтерге тарайды. Мен үш міндетті алдын ала бөлемін: оқиғаларды байланыстыру, бақылаудың іске қосылғанын растау және қажет болса, бүкіл сұрауды ашық мәтінмен сақтамай, нақты құпияны оқиғамен салыстыру.

Метадерек оқиғаны дәлелдейді, мазмұнын емес

Мәтін болмаса, тек жеке өрістерге жазылған деректі сенімді дәлелдеуге болады. 200 POST /chat/completions секілді жазба пайдасыз деуге келеді: ол шақыруды адаммен байланыстырмайды, нақты бағытты көрсетпейді және бүркемелеу туралы ештеңе айтпайды. Жақсы жазба сұрау денесіне қарамай алты сұраққа жауап береді: әрекетті кім жасады, қандай өкілеттікпен жасады, қай саясат іске қосылды, сұрау қайда кетті, қашан болды және операцияны қай бақылау өткізіп не тоқтатып қалды.

Командалар бұл жерде бақылауды, трассалауды және аудитті жиі араластырады. Метрикалар қателердің немесе кідірістің өскенін көрсетеді. Трассалау бірнеше сервистегі жұмысты байланыстырады. Аудит субъектінің әрекеті мен бақылау шешімін ішкі тексеруге жарайтын түрде бекітеді. Бір trace_id үш қабатқа да пайдалы, бірақ техникалық спанды өздігінен дәлелге айналдырмайды.

Шекарасы анық. Метадерек мына жайтты растауға мүмкіндік береді: «42-пайдаланушы k_7f3a таңбасы бар кілтпен сұрау жіберді, pii-kz-v4 саясаты бір ЖСН тапты, оны токенмен ауыстырды, содан кейін шлюз шақыруды жергілікті пулға бағыттап, жауап алды». Бірақ оның қай ЖСН болғанын анықтау мүмкін емес. Бұл айырманы оқиғаға ден қою жоспарына алдын ала жазыңыз, әйтпесе тергеу кезінде журналдан ол бере алмайтын жауап талап етіледі.

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

Пайдаланушы мен кілт сәйкестігін бөлек сақтаңыз

Ең аз жазбада тұрақты actor_id және API кілтінің таңбасы болуы керек. Пайдаланушы идентификаторы әрекетті жасаған адамды немесе сервисті көрсетеді, ал кілт таңбасы қандай өкілеттік қолданылғанын білдіреді. Біреуін ғана сақтасаңыз, тергеу ортақ техникалық аккаунтқа немесе жұмыс базасынан өшіріліп кеткен кілтке тіреледі.

Құпияның өзін, тіпті оны табуға көмектесетін бөлігін де жазбаңыз. Кілтті шығарған кезде қайтымсыз таңба есептеңіз, мысалы, толық кілттен бөлек сервер құпиясымен HMAC жасап, нәтижесін иесі туралы жазбаның қасында сақтаңыз. Энтропиясы төмен не белгілі префиксі бар токендер үшін жай жылдам хеш әлсіз, ал HMAC құпия кілтсіз болжамдарды тексеруге жол бермейді. Аудит ағынына кілт жазбасының қысқа идентификаторын және тұрақты ұзындықтағы толық таңбаны жіберіңіз.

Иесімен байланысты тергеу басталғанда ғана есептеуге болмайды. Пайдаланушы жұмыстан кетуі, сервистік аккаунттың атауы өзгеруі, ал кілт қайта шығарылуы мүмкін. Сондықтан оқиғада шақыру сәтіндегі actor_id, actor_type, tenant_id және key_id сақталуға тиіс. Аты мен электрондық поштасын қайталамаған жөн: олар өзгереді әрі өздері де дербес дерекке жатады. Сәйкестіктер тарихын қолжетімділікті басқарудың қорғалған тізілімінде ұстаңыз.

Бастамашы мен өкілді ажыратқан пайдалы. Фондық агент жасаған шақыруда сервис actor_id ретінде, ал тапсырманы бастаған пайдаланушы on_behalf_of өрісінде тұра алады. Екінші өріс болмаса, он мың автоматты сұрау бір ғана белгісіз процестің әрекеті болып көрінеді. Өкілдік жоқ кезде өрісті кездейсоқ жоғалтпай, нақты null мәнін жазыңыз.

Кілт бұзылған жағдайды тергеу үшін auth_context қосыңыз: аутентификация тәсілі, сессия идентификаторы, тексеру нәтижесі және себеп коды. IP мекенжайын тұлғаның орнына қолданбаңыз. NAT, мобильді желілер мен проксилер IP-ді әлсіз белгіге айналдырады, дегенмен қалыпқа келтірілген дереккөз өрісі қосымша сигнал ретінде пайдалы.

Саясат нұсқасы «бүркемелеу қосулы» жалауынан маңызды

masking=true жалауы ештеңеге жуық дәлел бермейді. Тергеушіге саясат идентификаторы, оның өзгермейтін нұсқасы, орындау режимі және нәтиже керек. Бір атаудағы саясат кеше ЖСН іздеп, бүгін тек телефондарды іздеуі мүмкін; режим мәтінді өзгертпей, тек бақылауға қойылған болуы ықтимал.

Кемінде policy_id, policy_version, policy_digest, enforcement_mode және policy_decision өрістерін жазыңыз. Идентификатор ережені табады, нұсқа конфигурацияның нақты қалпын көрсетеді, ал digest бұрынғы нұсқа нөмірімен жасырын өзгертілген файлды анықтайды. Режим monitor, redact, block және bypass мәндерін ажыратуы керек. Шешімді allow, deny, allow_after_redaction және error секілді шектеулі мәндермен берген дұрыс.

Детектор нәтижесін бөлек сақтаңыз: оның нұсқасы, табылған нысан түрлері, әр түрдің саны және орындалған әрекет. Бастапқы мәтінсіз мысал былай көрінеді:

{"policy_id":"pii-kz","policy_version":4,"policy_digest":"sha256:8c...","enforcement_mode":"redact","detector_version":"ner-12","findings":{"iin":1,"phone":0},"action":"tokenize","decision":"allow_after_redaction"}

Мұндай нысан қай бақылау қолданылғанын көрсетеді, бірақ ЖСН мәнін ашпайды. Ол баптаудағы маңызды қатені де байқатады: findings.iin=1 және enforcement_mode=monitor қатар тұрса, жүйе деректі көріп, оны бүркемелемей әдейі өткізіп жіберген.

Кейде бекітілген ерекшелік бойынша саясат айналып өтіледі. Мұны жалпы allow ішіне жасырмаңыз. exception_id, ерекшелік иесін және жарамдылық мерзімін қосыңыз, ал толық негіздемені келісу жүйесінде сақтауға болады. Журналға ішкі идентификатор жеткілікті. Төтенше айналып өту үшін жеке себеп кодын және күшейтілген қолжетімділік бақылауы қолданылғанын жазыңыз.

Детектор қатесі таза нәтиже емес. Бүркемелеу сервисі жауап бермесе, оқиға policy_decision=error және нақты failure_code алуы керек. Бұдан кейін сұрауды жабық күйде тоқтатуды шлюз конфигурациясы шешеді. Сезімтал деректер бар жүйеде мен сұрауды өткізбеймін, себебі нәтижесі белгісіз тексеруден өткізу ақауды жылыстау арнасына айналдырады.

Нақты бағытты ескі конфигурациядан қалпына келтірмеңіз

Сұралған модель мен нақты бағыт жиі сәйкес келмейді. Роутер қолжетімсіздікке, лимитке, өңірге, бағаға немесе дерек резиденттігі ережесіне байланысты басқа провайдерді таңдай алады. Сондықтан аудит кейін ескі конфигурацияны қайта құруды талап етпей, бағыттау шешімін оқиғаның өзінде бекітуі керек.

Ең аз жиынға requested_model, resolved_model, route_id, provider_id, endpoint_class, processing_region және residency_policy кіреді. Сұрау бірнеше рет жіберілсе, бір финалдық жол жеткіліксіз. Ортақ request_id, ретімен берілген attempt_no және жеке нәтижесі бар әр талпынысқа еншілес оқиға жасаңыз. Сонда сыртқы провайдерге алғашқы сәтсіз жіберілім жергілікті модельдегі сәтті қайталаудың тасасында қалмайды.

Егер құпия болуы мүмкін болса, провайдердің параметрлері бар толық мекенжайын жазбаңыз. Қалыпқа келтірілген provider_id және соңғы нүкте класы әдетте жеткілікті контекст береді. Жеке өрістетуге кластер идентификаторы мен аймақ пайдалы, ал торап атауы аудитке сирек көмектеседі және кардиналдықты қатты өсіреді.

Дерек резиденттігі ережесін қолданылған шешім ретінде, мысалы kz_only:v3 деп, нәтижесін matched немесе violated түрінде бекітіңіз. Қосымша толтырған өңір өрісіне қарағанда шекаралық шлюз жазған дерек сенімдірек: қосымша қателесуі немесе қайта бағыттауды білмеуі мүмкін. Әр маңызды өрістің бір ғана анық дереккөзі болуға тиіс.

AI Router мұндай сызбада провайдерге немесе жергілікті модельге бағытты PII бүркемелеуімен және аудит оқиғасымен байланыстыратын бірыңғай нүкте бола алады. Бірақ шлюз нашар журнал шартын түземейді: команда өрістерді, нұсқаларды және оларға қолжетімділік ережелерін алдын ала анықтауы керек.

Уақытқа шекаралар, сағаттар және оқиға реті керек

Сұрау тексеруден, кезектен, бағыттаудан және бірнеше талпыныстан өтсе, бір уақыт белгісі жеткіліксіз. received_at, policy_checked_at, dispatched_at және completed_at мәндерін UTC бойынша платформа шынымен қолдайтын дәлдікпен сақтаңыз. Ұзақтықты процесс ішіндегі монотонды сағатпен өлшеңіз, өйткені жүйелік уақыт түзетілгенде екі күнтізбелік белгі арасындағы айырма теріс болып шығуы мүмкін.

Әр жазбада бірегей event_id, тұрақты request_id және таратылған trace_id болуы керек. W3C Trace Context сервистер арасында traceparent тасымалдауды анықтайды, бірақ бұл идентификатор аутентификациядан өтті немесе жалғыз аудит кілті болуға жарайды деп уәде бермейді. Кіріс trace-контекстін трассалауға қабылдаңыз, ал өз request_id мәніңізді сенімді шекарада шығарып, клиентке оны ауыстыруға рұқсат бермеңіз.

Бір сұрау оқиғаларының ретін жергілікті sequence_no арқылы бекітуге болады. Бұл топтап жеткізу кезінде қоймадағы жолдар реті өзгерсе көмектеседі. Әртүрлі сервистер арасында микросекундқа дейінгі абсолютті ретті бар етіп көрсетпеңіз. Сағаттарды синхрондаудың белгілі ауытқуын сақтап, себептік идентификаторларға сүйеніңіз: негізгі спан, талпыныс нөмірі және алдыңғы оқиғаға сілтеме.

Қабылдау уақытын сұрау денесін талдамай тұрып алыңыз, әйтпесе парсер ақауы шақыруды басталу нүктесінсіз қалдырады. Клиент таймауты мен ішкі қатені қоса алғанда, әр нәтиженің аяқталуын жазыңыз. Процесс соңғы жазбаға дейін тоқтаса, жеткізуді жеке бақылау аяқталмаған сұрауды белгілеуі керек. Сонда completed_at болмауы түсініксіз қуыс емес, бақыланатын күй болады.

Сақтау мерзімі де дәлел моделіне кіреді. Оқиғалар жеті күн сақталса, сегізінші күнгі тергеу тізбекті қалпына келтірмейді. Мерзімді анықтау уақыты мен ішкі міндеттерге қарай таңдаңыз, саясатқа бекітіңіз, ал жоюды журналды басқарудың жеке оқиғасымен растаңыз. Тізбектің ең қысқа сақталатын бөлігі жойылғаннан кейін тергеу мүмкіндігін уәде етпеңіз.

Қолжетімділік нәтижесі шешімді түсіндіруі керек

HTTP мәртебесі клиентке берілген жауапты сипаттайды, бірақ бақылаудың шешімін түсіндірмейді. 403 шлюзден, провайдерден немесе қосымшадан келуі мүмкін; 200 ішінде тапсырмадан бас тартқан модель жауабы болуы ықтимал. Қолжетімділік аудитіне бөлек access_decision, decision_source, reason_code және evaluated_permissions өрістері керек.

Себеп кодтары тұрақты және машина оқи алатын болуы қажет: KEY_REVOKED, TENANT_MISMATCH, MODEL_NOT_ALLOWED, RESIDENCY_BLOCK, RATE_LIMIT немесе POLICY_SERVICE_ERROR. Адамға арналған хабарды қосуға болады, бірақ тергеу сұрауларын соған құрмаңыз: келесі шығарылымда мәтін өзгеруі мүмкін. Хабарға бастапқы сұраудың бөлігін не токен мәнін қоспаңыз.

Тексерілген рұқсаттарды llm.invoke, model.external.use және pii.redaction.required секілді ықшам күй көшірмесімен, рөлдер жиынының нұсқасымен бірге сақтаған дұрыс. Бір айдан кейін әкімші рөлді өзгерткенде, жай allow мәні жеткіліксіз. Күй көшірмесі бүкіл IAM саясатын қайталамауы мүмкін, бірақ қолжетімділікті қай ереже бергенін қалпына келтіруге мүмкіндік беруі керек.

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

Бас тарту оқиғасын клиентке жауап қайтармай тұрып, сол ақаулы құрамдасқа тәуелсіз арнамен жазыңыз. Әйтпесе шамадан тыс жүктелген саясат сервисі тексеруді дұрыс орындай алмай, өз қатесі туралы жазбаны да жоғалтады. Маңызды шешімдер үшін жеткізуді растауы және жоғалған оқиғалар есептегіші бар жергілікті кезек қолайлы.

Мазмұн таңбасы нақты қауіп моделінде ғана көмектеседі

Журналда қалыпқа келтірілген мәннің қорғалған таңбасы болса, команда сұрау денесін сақтамай-ақ белгілі PII мәнін оқиғамен салыстыра алады. Мысалы, детектор ЖСН-ды шығарып, оны бірыңғай қалыпқа келтіреді де, бөлек кілт доменінде HMAC есептейді. Тергеу кезінде рұқсаты бар процесс белгілі ЖСН үшін осы әрекетті қайталап, сәйкестікті іздейді.

Бұл бүкіл сұрауға арналған әмбебап хеш емес. Бос орын, өрістер реті немесе қызметтік нұсқау өзгерсе, дербес дерек сол күйі қалса да, дене хеші өзгереді. ЖСН-нан алынған жай SHA-256 қауіпті: мүмкін мәндер кеңістігі шектеулі, сондықтан журналға қол жеткізген адам үміткерлерді тере алады. Құпия журнал жүйесінен тыс сақталса және салыстыру операциясына қолжетімділік те аудиттен өтсе, HMAC бұл тәуекелді азайтады.

Табылған мәнге арналған ең аз сызба мынадай:

{"entity_type":"iin","fingerprint":"hmac-sha256:v2:ab...","normalization":"iin-digits-v1","key_version":2,"match_scope":"tenant"}

key_version кілтті ауыстыруға қажет, ал match_scope бір адамды барлық клиент ұйым бойынша байқамай іздеуге жол бермейді. Таңбалардың өзі сезімтал болып қалады, себебі олар оқиғалар арасында тұрақты байланыс жасайды. Қолжетімділікті шектеп, жеке сақтау мерзімін белгілеңіз және оларды әзірлеушілердің күнделікті панельдеріне жібермеңіз.

Тергеушіге мән айналасындағы контекст керек болса, таңба көмектеспейді. Онда дәлелге арналған бөлек сақтау контуры қажет: қатаң триггермен таңдап жазу, бөлек кілтпен шифрлау, қолжетімділікті екі тараптың келісуі және қысқа сақтау мерзімі. Мұндай контурды «керек болып қалар» деп үнемі қосып қоюға болмайды. Ол тергеу саясаты рұқсат еткен материалды ғана жинауы керек.

Барлық сұрау денесін шифрлап, мәселе шешілді деп санауға да кеңес бермеймін. Шифрланған архив дербес деректер архиві болып қала береді, оған кілттерді басқару, көшірмелерді жою және әр оқылымды есепке алу қажет. Ол команда аудит өрістерін келісе алмағандықтан емес, құқықтық және операциялық жағдай мазмұнды қалпына келтіруді талап еткенде орынды.

Оқиғаның ең аз шарты тексерілуі керек

Жақсы ең аз жиынды бір нұсқаланатын нысанға сыйғызуға болады. Бұл жердегі «ең аз» дегеніміз, бір өрісті алып тастау тергеудің кемінде бір қорытындысын өзгертеді деген сөз. Ол контексті жоқ қысқа жолды білдірмейді.

{"schema_version":3,"event_id":"evt_01...","request_id":"req_01...","trace_id":"4bf92f...","sequence_no":4,"received_at":"2026-07-27T10:15:12.184Z","completed_at":"2026-07-27T10:15:12.941Z","actor":{"tenant_id":"t_17","actor_id":"u_42","actor_type":"human","on_behalf_of":null},"credential":{"key_id":"key_9","fingerprint":"hmac-sha256:7f3a..."},"auth":{"method":"api_key","decision":"allow","reason_code":"ROLE_MATCH","role_set_version":8},"pii":{"policy_id":"pii-kz","policy_version":4,"policy_digest":"sha256:8c...","mode":"redact","detector_version":"ner-12","findings":{"iin":1},"decision":"allow_after_redaction"},"route":{"requested_model":"model-a","resolved_model":"model-b","route_id":"kz-local","provider_id":"local-pool","processing_region":"kz","residency_policy":"kz_only:v3"},"result":{"status_class":"2xx","error_code":null,"input_tokens":812,"output_tokens":144}}

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

Теріс шарттарды да тексерген пайдалы. Журналда Authorization, бастапқы prompt, модельдің толық жауабы, электрондық пошта немесе шығарылған PII мәні болмауы керек. Журнал ағынын құпияларды іздейтін сканерден индекстеуге дейін өткізіңіз. Ол белгі берсе, карантин жазбаның қосалқы жүйелерге таралуын тоқтатуы қажет.

Сызба нұсқасы міндетті. Өрістерді үйлесімді түрде қосыңыз, ал мағынасы өзгерсе, жаңа нұсқа шығарыңыз. OpenTelemetry trace-контекст пен техникалық атрибуттарды жақсы тасымалдайды, бірақ оның семантикалық келісімдері сіздің сәйкестік, саясат шешімі және сақтау мерзімі туралы шартыңызды алмастырмайды. Бұл өрістер қауіп моделіңізге тиесілі, сондықтан оларды қауіпсіздік иесі нақты бекітуі керек.

Журнал тұтастығы мен оған қолжетімділік дәлелге кіреді

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

Өзгерістен қорғау immutable белгісімен шектелмейді. Реттелген топтама ішінде хештер тізбегін қолдануға болады: әр оқиға алдыңғы хешті сақтайды, ал бөлек сервис топтаманың түбіріне қол қояды. Қол қойылған түбірді мезгіл-мезгіл басқа әкімшілік доменге сақтаңыз. Сонда жолды өшіру немесе өзгерту тексерілетін үзіліс қалдырады, бірақ бұл сызба қосымша бастапқыда шын өрістерді жібергенін дәлелдемейді.

Жазбаның салмағын оның дереккөзі анықтайды. Сенімсіз клиент жіберген actor_id анықталған тұлға деп саналмайды. Шлюз оны тексерілген аутентификация контекстінен алуы керек. Бүркемелеу нәтижесін саясат сервисі, ал нақты провайдерді сыртқы байланысты ашқан құрамдас жазады. Әр маңызды өрісті кім жасайтынын және оған қай шекарадан бастап сенуге болатынын сызбада сипаттаңыз.

Журналды оқу да жылыстау қаупін тудырады. Метадерек іздеу, HMAC-таңбаларды салыстыру және қорғалған денелерге қол жеткізу рөлдерін бөліңіз. Қарапайым оператор request_id және шешім кодтарымен іздей алады, бірақ басқа клиент ұйымдардағы адамдардың тұрақты таңбаларын көрмеуі керек. Үлкен ауқымды экспортқа бөлек рұқсат және қолжетімділік себебі қажет.

Әр іздеу мен экспортты екінші аудит контурына жазыңыз: сұрауды кім орындады, қай іс бойынша, қандай өрістерді сұрады, қанша жол алды және файл қайда кетті. Іздеу нәтижелерінің өзін бұл метажурналға көшірмеңіз. Әйтпесе бірінші қоймаға қойылған қолжетімділік бақылауын әлсіз қорғалған сұраулар тарихы арқылы айналып өтуге болады.

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

Резервтік көшірме қолжетімділік шектеулері мен жою мерзімін сақтауы керек. Негізгі индекс бір айдан кейін дұрыс тазартылып, ал шектеусіз архив инфрақұрылым аккаунтында жылдар бойы қалған сызбаларды көрдім. Тергеу мүмкіндігі көп жақсармады, есесіне ықтимал жылыстауда ашылатын дерек көлемі өсті. Жоюды сынақ көшірмесін қалпына келтіріп, мерзімі өткен event_id іздеу арқылы тексеріңіз.

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

Сағаттарға, жинағыш конфигурациясына және қол қою кілтіне қолжетімділікті де бөліңіз. Қосымша операторы саясатты өзгертіп, экспортты тоқтатып және оқиғалар топтамасына қайта қол қоя алмауы керек. Міндеттерді толық бөлу мүмкін болмаса, бұл операцияларға тәуелсіз растау талап етіп, қауіпсіздік иесіне дереу хабар жіберіңіз. Басқару журналында ескі және жаңа мәнді, авторды, растаушыны және өзгеріс нөмірін сақтаңыз.

Тұтастық тексеруін кесте бойынша және тергеуге әр экспорт жасалғанда іске қосыңыз. Ол тізбекті қайта есептеп, топтама қолдарын тексеріп, реттіліктегі бос орындарды тауып, нақты сақтау мерзімін жарияланған мерзіммен салыстыруы керек. Қатесіз есеп әлі де толықтықты дәлелдемейді, сондықтан қасына әр дереккөз бойынша күтілген және қабылданған оқиға санын көрсетіңіз. Мұндай бақылау «журналдар бар» деген уәдені тексерілетін күйге айналдырады.

Шикі аудит оқиғаларын барлық талдау жүйесіне тікелей жібермеңіз. Алдымен операциялық панельдерге арналған өрістерді тергеу өрістерінен бөліп, содан кейін әр жүйеге жеке көрініс беріңіз. Мәртебе саны мен кідірісті біріктіруге болады, ал кілт таңбаларын, субъект идентификаторларын және ерекшелік мәліметтерін қорғалған индексте қалдырыңыз. Тұрақты идентификаторлары бар көшірме азайған сайын, оларды кім оқи алғанын дәлелдеу оңайырақ.

Тергеуді жылыстауға дейін жаттықтырыңыз

Қауіпсіздік қызметі сыртқы провайдердің жауабынан табылған ЖСН мен жиырма минуттық уақыт аралығын алды делік. Тергеуші алдымен белгілі мәннің рұқсат етілген HMAC-таңбасын есептеп, сәйкестікті тек қажетті клиент ұйымында іздейді. Таңбалар болмаса, ол оқиғаларды iin табылым түрі, уақыт, сыртқы бағыттар және allow не allow_after_redaction шешімдері бойынша сүзеді.

Содан кейін нәтижелерді request_id бойынша топтап, талпыныстарды sequence_no ретімен ашады да, төрт байланысты тексереді: сол сәттегі кілт иесі, саясат нұсқасы, нақты провайдер және қолжетімділік шешімінің дереккөзі. Қоймаға арналған сұрау былай көрінуі мүмкін:

SELECT request_id, actor_id, key_id, policy_version,
       provider_id, processing_region, decision, reason_code
FROM audit_events
WHERE tenant_id = :tenant
  AND received_at >= :from_utc
  AND received_at < :to_utc
  AND pii_types @> ARRAY['iin']
ORDER BY request_id, sequence_no;

Нәтиже ықтимал оқиғаларды азайтады, бірақ таңба немесе қорғалған дене болмаса, нақты ЖСН қайсысында болғанын анықтамайды. Есепте расталған жайтты, ықтимал қорытындыны және белгісізді бөлу қажет. Мысалы, үш шақыру ЖСН тапқаны және біреуі monitor режимінде сыртқы провайдерге кеткені расталуы мүмкін. Жылыстау сол шақыруға қатысты болуы ықтимал. Нақты мазмұн белгісіз қалады.

Осындай жаттығуда әдетте жайсыз қуыс анықталады: рұқсат оқиғасы бар, бірақ қайта жіберу кезінде бағыт жазбасы жоғалған; саясат нұсқасы үстінен жазылып кеткен конфигурацияға сілтейді; бір сервистің сағаты қалады; немесе өшірілген кілт енді иесімен байланыспайды. Мұны нақты оқиғадан кейін түсіндіргеннен гөрі, оқу деректерінен тапқан арзан.

Жаттығу таныстырылыммен емес, дәлел матрицасымен аяқталуы керек. Әр сұрақ үшін өрісті, негізгі жүйені, сақтау мерзімін, қолжетімді рөлді және күтілетін олқылықты көрсетіңіз. Егер «Нақты қандай мән кетті?» сұрағы дәлелденбейді деп белгіленсе, басшылық тәуекелді саналы түрде қабылдайды немесе таңбалар контурын бекітеді. Бұл шекараны жылыстаудан кейін ғана білу ең нашар нәтиже.

Сұрау денесін нақты міндет мазмұнды қалпына келтіруді талап еткен және команда көшірменің бүкіл өмірлік циклін қорғай алған жерде ғана сақтаңыз. Көп тергеуге егжей-тегжейлі метадерек, саясаттың өзгермейтін нұсқалары және бақыланатын HMAC-таңбалар қолайлы. Мұндай журнал артық дерек білмейді, бірақ пайдаланушы, кілт, тексеру, бағыт, уақыт және шешім туралы сұрақтарға болжамсыз жауап береді.