LLM-қызметіндегі қолжетімділікті шектеу: RBAC, ABAC және аудит

Мәселе неде: LLM рұқсаттарды «араластыра» алады

LLM сұрақтарға жақсы жауап береді, өйткені ол жауапты барлық берілген контексттен жинайды: жүйелік нұсқаулардан, чат тарихынан, табылған құжаттардан және интеграциялардан келген деректерден. Егер контекстке артық нәрсе түссе, модель көбіне оны құпия деп танымайды. Ол жай пайдалы болу үшін ақпаратты қолданады және бұл әдетте бірден қателік ретінде көрінбейді.

Типтік жағдай — компанияның жалпы корпоративтік чат-боты. Қаржы бөлімінен қызметкер төлемдер туралы сұрайды, HR — үміткерлер жайлы, заң бөлімі — келісімшарттар туралы, IT — инциденттер туралы. Барлығы бір интерфейсті және бір білім базасын пайдаланғанда, бір бөлімнің сұрауы басқа бөлімнің құжаттарын кездейсоқ тартып әкелуі мүмкін. Бұл әсіресе жобалар, клиенттер немесе файлдар атаулары ұқсас болса қауіпті.

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

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

Қауіп моделін қарапайым тілмен: нені қорғау керек және кімнен

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

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

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

Кім шабуыл жасайды? Көбінесе бұл сыртқы хакер емес, қызыққұмар қызметкер, инсайдер немесе интеграция/настройка қателігі, яғни DMS, пошта немесе CRM құқықтары дұрыс өңделмеген кезде болады.

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

RBAC тәжірибеде: рөлдер, қолжетімділік матрицасы және шектеулер

RBAC-та рөл — жүйедегі «сіз кімсіз» сұрағына қарапайым жауап. Бизнестің түсінуі оңай: әр адамға жүздеген жеке рұқсат орнатудың орнына түсінікті рөл тағайындап, сервис мінез-құлқын болжамды етуге болады.

Практикада рөлдер компания ішіндегі сөйлесудегі түрде құрылады. Мысалы, колл-орталығының операторына өтініштің карточкасы мен статустары көрінеді, дәрігерге — пациенттің тарихы мен тағайындаулары, бухгалтерге — шоттар мен актілер, сатып алушыға — өтініштер мен келісімшарттар, әкімшіге — пайдаланушылар мен баптаулар.

Қолжетімділік матрицасы әдетте «рөл — ресурс — іс-әрекет» схемасына сай құрылады. Ресурстар: клиент профилі, медициналық карта, келісімшарт, есеп, білім базасы, хат алысы. Әрекеттер: оқу, құру, өңдеу, өшіру, экспорттау, бекіту. LLM-қызметінде бұл интерфейске ғана емес, модель контекстке қандай құжаттарды алуына және жауапта қандай деректерді көрсетуге рұқсат етілгеніне де байлануы маңызды.

RBAC-тi тірi жүйеде жұмыс істету үшін алдын ала жиі ұмытылатын шектеулерді қосыңыз: экспорт пен көшіруге тыйым салу кейбір рөлдерге; журналдарға, промпттарға және чат тарихына жеке қолжетімділік құқықтары; қарау мен бекіту рөлдерін бөлек ету; әдепкі бойынша минималды құқықтар.

RBAC шекаралары тез көрінеді. Бірдей «дәрігер» рөлі барлық пациенттерді көруі тиіс емес, ал «сатып алушы» барлық жобаларды көруі тиіс емес. Рөл «кім?» сұрағын жауаптайды, бірақ «қандай контексте?» — филиал, жоба, деңгей немесе құпиялылық сияқты сұрақтарды онша ашпайды. Сол себепті RBAC әдетте негіз болып, нақты шектеулер атрибуттық ережелермен (ABAC) толықтырылады.

ABAC тәжірибеде: атрибуттар бойынша ережелер және нақты мысалдар

ABAC (Attribute-Based Access Control) рөлдер жеткіліксіз болған жерлерді жабады. LLM-қызметінде бұл өте қажет: бір адам «инженер» болуы мүмкін, бірақ әртүрлі жобаларда, филиалдарда және әртүрлі допуск деңгейлерінде жұмыс істеуі ықтимал.

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

Көбіне кездесетін атрибуттар:

• Пайдаланушы: филиал, бөлім, допуск деңгейі, жобалық қатыстылық.
• Ресурс: құжат түрі, иесі, құпиялылық белгісі, жоба.
• Контекст: уақыт, орналасқан жер (корпоративтік желіде ме), келісім-шарт статусы.

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

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

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

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

RBAC пен ABAC-ты қалай біріктіруге болады (күрделендірмей)

LLM-қызметінде қолжетімділікті шектегенде RBAC пен ABAC-тен бірін таңдау керек емес — оларды міндеттерге бөлу жақсы тәжірибе. RBAC — кім екеніңізге қатысты базалық шекараны анықтайды. ABAC нақты сұрауда қандай жобаға, филиалға, құпиялылық деңгейіне немесе құжат түріне рұқсат бар екенін айқындайды.

Жай схема: «рөл алдымен, атрибуттар кейін»

Бастапқыда 5–10 рөлден бастаңыз және оларға негізгі құқықтарды қатты бекітіңіз. Мысалы: «Қызметкер», «Жоба менеджері», «Заңгер», «Қаржы», «Әкімші». Кейін атрибуттарды тек қажет жерлерде қосыңыз және оларды біркелкі етіңіз.

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

Қарапайым мысал: бірнеше алаңы бар компанияда «Қолдау қызметі» рөлі инциденттер туралы сұрақ қояды. RBAC инциденттер базасына қолжетімділікті рұқсат етеді, ал ABAC филиалға жататын жазбаларды шектеп, жеке деректер өрістерін жасыртады, егер қосымша допуск болмаса.

Қалай «ережелер жан-жануарлар бағасын» тудырмас үшін

Гибридтің басты қаупі — шексіз ерекшеліктер жиыны. Басқаруды сақтау үшін ережелерді «көлденең» ұстаңыз: шарттарды азайтып, стандартты атрибуттарды көбейтңіз. Егер ереже AND/OR тізбегіне айналып кетсе, сіз симптомды емдейсіз, себепті емес (мысалы, қате рөл немесе деректерді нашар классификациялау).

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

Осылайша RBAC-пен болжаулы база және ABAC-пен дәлдік ала аласыз, артық жүктемесіз және үнемі қолмен жасалатын ерекшеліктерсіз.

Құқықтар бойынша контекстті сүзу: дәл не ұсталуы керек

LLM-қызметінде контекст — жауап үшін отын. Егер оның ішіне қолданушының қолы жетпейтін құжаттың фрагменті түссе, ақпарат ағып кетті деп санауға болады, тіпті модель оны толық көрсетпесе де. Сондықтан қолжетімділікті бірнеше нүктеде тексеру керек, бір рет қана емес.

Құқықтарды кемінде үш сатыда қолдану дұрыс. Іздеуден бұрын: пайдаланушының қолы жоқ индекс пен сақтау орындары бойынша сұрау жіберуге болмайды. Іздеуден кейін: нәтижелер ACL, рөлдер мен атрибуттар бойынша сүзілмей, фрагменттер промптқа алынбауы тиіс. Жауаптың алдында: жауап жобасында және цитаталарда тыйым салынған үзінділер жоқ екеніне финалдық тексеру (мысалы, кэштен немесе жалпы сниппеттерден алынғанда).

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

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

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

Осылай контекст пайдалы болып қалады, бірақ ағып кетуге арнаулы арнаға айналмайды.

Бастапқы көздерді қауіпсіз көрсету: сілтемелер, цитаталар және аудит

"Дереккөздерді көрсет" деген сұраныс қауіпсіз естілсе де, бұл жиі ағып кетудің нүктесі болады. Модель құжат мәтінін ашпаған болса да, файлдың бар болуы, атауы, иесі немесе келісімшарт нөмірі сезімтал болуы мүмкін. Сондықтан ережелер жауапқа ғана емес, кез келген «дәлелдерге» де қолданылуы тиіс.

Ең қауіпті жағдай — қолданушыға құқығы жоқ тақырып бойынша сұрау салғанда жүйенің «құжатқа сілтеме» беруі. Негізі, бұл құпия деректерді қайда іздеуге болатынын көрсететін кеңес. Цитаталар да қауіпті: қысқа үзінді жеке деректерді, бағаларды, тендер шарттарын немесе ішкі белгілерді аша алады.

Қауіпсіз әдіс — «сілтеме» дегенді URL емес, бақылаудағы карточка деп санау. Онда минималды метадеректер көрсету қажет: ішкі идентификатор, нейтралды тақырып (артық детальсіз), бөлім иесі, нұсқа немесе дата, қолжетімділік деңгейінің белгісі. Негізгі ереже: дереккөзді тек қолданушы сол құжатты бастапқы жүйеде ашуға құқығы бар болса ғана көрсету. Егер құқық жоқ болса, «дереккөз қолжетімсіз» деп қайтарған жөн және атауды да ашпау керек.

Цитаталар үшін сол принцип қолданылады: тек рұқсат етілген құжаттардан ғана және тек тексеруге жеткілікті көлемде цитата беру. Көбінесе бір-екі жол жеткілікті, және маскалау арқылы: нөмірлерді, ФИО-ды, шоттарды жасыру.

Аудит шынайы болуы үшін дәлелдерді сервис жағында тіркеу керек, жауап мәтінінде емес. Логта пайдалы жазылар:

• кім сұрады (пайдаланушы, рөлі, негізгі атрибуттары);
• кандидат болған көздер және қайсысы құқықтан өтті;
• саясат шешімі (рұқсат/тыйым) және себебі;
• құжат нұсқалары мен уақыт белгілері;
• фрагменттердің хештері, толық мәтін емес (жеке өмір шекарасын сақтау үшін).

Осылай жауап неліктен осындай болғанын дәлелдеп беруге болады, ал журналдарды жаңа утечка қоймасыға айналдырмау үшін мәтіннің орнына хештер пайдаланылады.

Іске асыру бойынша қадамдық жоспар: рөлдерден тексерулер мен логтарға дейін

LLM-қызметінде қолжетімділікті шектеуді бір жердегі баптау емес, деректер жобасы ретінде енгізген жақсы. Бастыдан анықтаңыз: деректердің иесі кім, оларды кім тұтынады және аудитормен қалай дәлелдейсіз, модель артық нәрсе көрсетпеді деп.

Бастапқыда көздерді инвентаризациялаңыз: білім базалары, файлдар, тикеттер, CRM, ішкі регламенттер. Әр көзге data owner тағайындаңыз — қолжетімділікті бекітетін адам. Бұл RBAC/ABAC схемасын таңдаудан да маңыздырақ.

Келесі қадам — рөлдер мен атрибуттарды сипаттау. Рөлдер түсінікті каркас береді (мысалы, «HR», «қаржы», «сатып алулар», «қолдау»), ал атрибуттар дәлдік қосады (бөлім, допуск деңгейі, ел, жоба, құжат түрі). Бұларды ИБ мен бизнеспен алдын ала келісіңіз, әйтпесе ережелер «сұрау арқылы айналып өтуге» жиналады.

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

RAG пайплайнінің практикалық минимумі:

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

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

Жиі болатын қателер мен тұзақтар, олар утечкаға әкеледі

LLM-дегі ең қауіпті утечкалар көбіне архитектура мен баптаудағы кішкентай қателіктерден шығады, әсіресе «кіру кезінде қолданушы тексерілді — соның өзі жеткілікті» қағидасы қолданылғанда.

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

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

Үшінші тұзақ — «прозрачность үшін» бастапқы көздерді көрсету, қайта тексеріссіз. Қолданушы құжатты ашуға құқығы болмауы мүмкін, бірақ ол атауын, идентификаторын, жолының бөлігін немесе цитатасын ала алады — бұл сезімтал ақпаратты қайта құрастыруға жеткілікті болуы мүмкін.

Логтар да бөлек қауіп тудырады. Көбіне логта промпттар, табылған фрагменттер, жауаптар, токендер, аттар мен нөмірлер жазылады. Егер логтар жеке деректер мен құпияларды маскаламай жазса, сіз жаңа утечка қоймасын жасайсыз.

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

Жақсы ереже: егер деректі бастапқы жүйеде қолданушыға көрсетіп болмайтын болса, оны LLM арқылы да көрсетуге болмайды — жауапта, бастапқы көздерде де, логтарда да.

Өнімге шығар алдында қысқа чек-лист

Релиз алдында LLM-қызметіндегі қолжетімділіктің промптқа сенім емес, тексерілетін ережелер мен журналдарға сүйенетінін растаңыз.

Деректер гигиенасын тексеріңіз. Әр құжатта және тіпті әр фрагментте (чанк) иесі болуы және түсінікті қолжетімділік меткасы болуы тиіс: мысалы, «тек HR», «қаржы», «барлық қызметкерлер», «құпия». Егер меткалар жоқ немесе олар қолмен бақылаусыз тағайындалса, жүйе тез қате бере бастайды.

Содан кейін құқық бақылауы екі нүктеде екеніне көз жеткізіңіз, бір жерде емес:

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

Қосымша тексеріңіз: бастапқы көздер мен цитаталар тек тиісті құқықтары барларға көрсетіледі және артық детальдарсыз (мысалы, жабық папкалардың атауларысыз). Аудит журналы оқылатын болуы керек: кім, қашан, қандай сұрау, қандай нәтиже, қандай көздер қолданылды. Және процестің иесі болуы шарт — рөлдер, атрибуттар мен ережелердің өзгерістеріне жауап беретін адам.

Арнайы «қоздырғыш» тесттерді де жасаңыз. Утечкаға әдетте әкелетін сұрақтар тізімін құрастырыңыз: «жалақыны көрсет», «поставщикпен келісімшартты бер», «директордың хатында не болды», «құжатты қайталап бер, дереккөзді көрсетпей». Жақсы тест — бір сұрақты құқықтары бар және жоқ қолданушыдан сұрау: жауаптар әртүрлі болуға тиіс, ал тыйым салынған факттер тіпті ирония арқылы да ашылмауы тиіс.

Егер бір пункт өтпесе, релизді тоқтырып, түзеткен дұрыс.

Мысал сценарий: бір LLM, әр бөлімге түрлі жауап

Үлкен ұйымда бір көмекші сатып алуларда да, қаржыларда да қолданылады. Бір сұрақ: «Астана-2026 жобасына осы айда төлеуге болатын келісімшарттарды көрсетіп, неге екенін жазып бер».

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

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

LLM әртүрлі жауап береді — модельдің «көңіл-күйіне» байланысты емес, контекст құқықтарға сәйкес таңдалғандықтан: бір сұрақ үшін промптқа әр түрлі құжаттар мен өрістер жиналады.

Тексеру үшін көрсеткіш көздері де қауіпсіз беріледі. «Міне файлға сілтеме» деп берілмей, қолданушыға ID, нұсқа, дата, иесі, статус сияқты нақты көрсеткіштер және 1–2 сөйлемдік үзінді беріледі (сезімтал өрістерсіз); бөлім немесе бетке метка және аудит үшін контрольдық хеш беріледі.

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

Келесі қадамдар: пилот, масштабтау және инфрақұрылым

Кішкентай пилоттан бастаңыз: бір процесс, бір команда, нақты мақсат (мысалы, регламенттер бойынша жауаптар немесе өтініштерді қолдау) және тек шын қажет құжаттар жиыны. Осылайша қолжетімділікті бақылауды тәуекелсіз тексересіз.

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

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

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

Іске асыру ішкі ИБ және ИТ командасымен орналастырылуы мүмкін немесе жүйелік интегратор жалдануы мүмкін — ол архитектураны құрып, қолжетімділікті баптап, сервер базасын таңдауға көмектеседі. Қазақстанда мұндай жобаны көбінесе локалды инфрақұрылым мен GSE.kz деңгейіндегі өндіруші/интегратордың қолдауымен жүргізеді, әсіресе жабдық жеткізу, сервистік қолдау және айқын жабдық тізбегі маңызды болғанда.