Шифрлау кілттерін тоқтаусыз қалай ротациялауға болады

Шифрлау кілттерін тоқтаусыз ротациялау KMS-тегі Rotate батырмасынан басталмайды. Ол жағымсыз бір шындықты мойындаудан басталады: LLM сервисіндегі деректер бір ғана дерекқорда тұрмайды. Промпттар мен жауаптар жұмыс кестелеріне, техникалық журналдарға, трассировкаларға, кезектерге, векторлық индекстерге, тіркемелерге, экспорттарға және резервтік көшірмелерге түседі. Егер мұның бәрін бір кілт қорғаса, сіз қарапайым схема құрған жоқсыз. Әртүрлі сақтау мерзімдерін, қолжетімділік құқықтарын және деректердің сыртқа шығу салдарын бір апат доменіне байлап қойдыңыз.

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

Ротация мен қайта шифрлау әртүрлі міндеттерді шешеді

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

Басқарылатын KMS жүйелері көбіне бірінші процесті қолданба үшін сезілмейтіндей орындайды. AWS KMS құжаттамасы KMS кілтінің материалын ауыстыру data keys мәндерін өзгертпейтінін және олар қорғайтын деректерді қайта шифрламайтынын нақты ескертеді. Google Cloud KMS те осыны басқа түрде айтады: жаңа нұсқа белсенді болады, бірақ ескі деректер автоматты түрде қайта шифрланбайды.

Бұл LLM инфрақұрылымы үшін маңызды. Егер жазбаларды envelope encryption арқылы қорғасаңыз, объект әдетте пайдалы жүктеменің шифртексті мен шифрланған DEK-тен тұрады. KEK ротациясы жаңа DEK-терді жаңа нұсқамен қорғай алады, бірақ ескі DEK пен ескі шифртекст жоғалмайды. Нақты DEK бұзылса, KEK-тің күнтізбелік ротациясы мәселені шешпейді.

Жүйе мына үш сұраққа еш болжамсыз жауап беруі керек:

• Бұл объектіні қай кілт және оның қай нұсқасы қорғады?
• Сервис ауысу алдында жасалған объектіні оқи ала ма?
• Көшірмелерді қоса есептегенде, қанша объект әлі де ескі нұсқаға тәуелді?

Үшінші сұраққа жауап беру үшін бірнеше командадан қолмен іздеу керек болса, ескі нұсқаны қауіпсіз жоюға болмайды. Сіз нені істен шығаратыныңызды білмейсіз.

Барлық қоймаға бір кілт қолдану инцидент ауқымын кеңейтеді

Журналдарға, жұмыс деректеріне, бэкаптарға және құпияларға арналған кілттер әртүрлі криптографиялық домендер болуы керек. Бұл аудитордың қалауы емес және KMS-ке көбірек объект қосуға тырысу да емес. Бұл деректер кластарының өмірлік циклі әртүрлі.

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

Практикалық ең аз нұсқа мынадай:

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

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

Инвентаризация кестелерді емес, көшірмелерді санауы керек

Жаңа кілт жасамас бұрын шифртекстер картасын құрыңыз. Ол үшін дерекқор кестелерінің тізімі жеткіліксіз: бір жазба индекске, аналитикалық экспортқа, dead-letter queue-ге және түнгі көшірмеге кетуі мүмкін. Ротация дәл осындай қосалқы бағыттарда бұзылады.

Деректердің әр класы үшін тізілімде мына өрістерді бекітіңіз:

• сервис иесі және деректер иесі;
• физикалық сақтау орны және барлық репликация жолдары;
• шифрлау форматы, алгоритм және нұсқа идентификаторы;
• batch тапсырмаларын, CLI мен қалпына келтіру процедурасын қоса есептегендегі оқырмандар;
• объект немесе оның көшірмесі қолжетімді болып қалатын ең ұзақ мерзім.

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

Ротацияға дейін сақталмауы тиіс деректерді де тексеріңіз. Толық промпттың error log ішінде пайда болуы көбіне әзірлеуші провайдер қатесін бір рет көргісі келгендіктен болады. Содан кейін ол архивте жылдар бойы жатады. Журналдауға дейін PII-ді бүркемелеу қайта шифрланатын деректер көлемін азайтып, сыртқа шығудың салдарын жеңілдетеді, бірақ шифрлауды алмастырмайды.

Инвентаризацияның пайдалы нәтижесі презентацияға арналған диаграмма емес, тексеруге болатын жол болуы керек: conversation_events -> PostgreSQL primary + CDC topic + nightly backup -> app-data-kek v4 -> API, summarizer, restore-job -> retention 30 days / 180 days backup. Бұл жолдан қосарланған оқудан қай жүйелер өтуі керегін және v4 нұсқасына қашанға дейін тиіспеу қажет екенін көруге болады.

Шифртекст форматы нұсқаны сақтауы керек

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

Қолданбалық шифрлау үшін метадеректер мынадай болуы мүмкін:

{
  "cipher": "AES-256-GCM",
  "key_domain": "app-data",
  "key_version": "2026-07",
  "wrapped_dek": "base64url(...) ",
  "nonce": "base64url(...)",
  "aad": {
    "tenant_id": "t_4821",
    "record_type": "conversation_event",
    "record_id": "ev_01J..."
  },
  "ciphertext": "base64url(...)"
}

key_version кілт нұсқасын таңдайды, wrapped_dek DEK-ті ашуға мүмкіндік береді, ал AAD шифртексті контекстпен байланыстырады. Егер шабуылдаушы бір tenant-тің шифртекстін екіншісінің жазбасына көшірсе, шифрды ашу аутентификация қатесімен аяқталуы керек. Қайта шифрлаусыз өзгертілуі тиіс өрістерді, мысалы тапсырма күйін немесе соңғы жаңарту уақытын, AAD құрамына қоспаңыз.

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

Шағын мәндер үшін KMS арқылы тікелей шифрлау қолдануға болады. Журналдарға, файлдарға, модельдің үлкен жауаптарына және бэкаптарға әдетте envelope encryption тиімдірек: сервис кездейсоқ DEK жасап, деректерді сонымен шифрлайды да, DEK-ті оралған түрде сақтайды. Бұл KMS-ке жасалатын қымбат сұраулар санын азайтып, объектілерді кезең-кезеңімен миграциялауға мүмкіндік береді. Бірақ DEK-ті журналға жазуға, жарамдылық мерзімінсіз кэштеуге немесе кезекке кәдімгі JSON өрісі ретінде жіберуге болмайды.

Қосарланған оқу миграция кезінде сервисті сақтайды

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

Реттілік мынадай:

1. Жаңа нұсқаны немесе жаңа кілтті жасаңыз, бірақ жазуды әлі ауыстырмаңыз.
2. key_version арқылы ескі және жаңа нұсқаларды оқитын, олардың көрсеткіштерін бөлек санайтын кодты орналастырыңыз.
3. Жаңа жазушыларды тез кері қайтаруға болатын конфигурация арқылы жаңа нұсқаға ауыстырыңыз.
4. Ескі объектілерді оқып, тұтастығын тексеріп, жаңа криптографиялық қабыққа жазатын воркерді іске қосыңыз.
5. Қамту расталғаннан кейін ескі нұсқамен жаңа операцияларға тыйым салып, бақылау мерзімі ішінде тек шифрды ашуды қалдырыңыз.

Екінші қадамның мәні try old key атты қосалқы тармақта емес. Мұндай код формат қателерін жасырып, сервисті кілттерді кезекпен тексеруге мәжбүр етеді. Оқу детерминирленген болуы керек: v4 объектісі v4 арқылы, v5 объектісі v5 арқылы ашылады. Нұсқа белгісіз болса, API басқарылатын қате қайтарып, дабыл көтереді және сәттілікке үміттеніп KMS-ке бес рет сұрау жібермейді.

Төменде әдейі «шифрды ашу сәтсіз болса, алдыңғы кілтті байқап көр» деген логикасыз берілген ықшам псевдокод:

def decrypt_record(envelope):
    policy = key_registry.get(
        domain=envelope["key_domain"],
        version=envelope["key_version"]
    )
    if policy is None or policy.read_status != "enabled":
        raise UnsupportedCiphertextVersion(envelope["key_version"])

    dek = unwrap(policy.kek_ref, envelope["wrapped_dek"], envelope["aad"])
    return aes_gcm_decrypt(dek, envelope["nonce"], envelope["ciphertext"], envelope["aad"])


def encrypt_record(plaintext, context):
    policy = key_registry.current_writer(domain="app-data")
    return envelope_encrypt(policy.kek_ref, plaintext, context)

Код доменді, нұсқаны және операция нәтижесін журналдауы керек, бірақ пайдалы жүктемені, DEK-ті, nonce мәнін немесе оралған кілтті журналға жазбаңыз. decrypt_success_total{domain,version} метрикасы ескі нұсқаның шынайы оқылуын аяқталған batch-ке сенуден гөрі дәлірек көрсетеді.

Миграциялық воркер идемпотентті болуы керек

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

conversation_event жазбасын алайық. Воркер оны row_version=18 және key_version=2026-01 күйінде оқиды, шифрын ашады, сол AAD арқылы 2026-07 нұсқасымен шифрлайды және жазбаны тек row_version=18 сәйкес келгенде жаңартады. Пайдаланушы сұрауы жазбаны бұдан бұрын өзгерткен болса, шартты жаңарту орындалмайды. Воркер өзекті нұсқаны қайта оқып, жұмысты қайталайды. Оның ескі суретпен жаңа күйді қайта жазуға құқығы жоқ.

Жазбас бұрын мына төрт шартты тексеріңіз:

• объект әлі де ескі нұсқаны қолданып тұр;
• AAD қазіргі иесі мен объект түріне сәйкес келеді;
• шифрды ашу аутентификация тексерісінен өтті;
• шартты жаңарту объект оқу мен жазу арасында өзгермегенін растады.

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

Жақсы воркер checkpoint-ті «соңғы id» ретінде емес, орнықты өту ережесі ретінде сақтайды. Идентификаторлар реттелмесе, жазбалар бэкаптан қалпына келтірілсе немесе кейбір объектілер кешіккен кезектен ескі нұсқамен жасалса, соңғы id тәсілі бұзылады. «X доменінің key_version=old нұсқасындағы, бастапқы кілті бойынша реттелген барлық объектілері» түріндегі сұрауды қолданыңыз және санауыш нөлге түскенше оны қайталаңыз. Содан кейін кезектердің ең ұзақ кідіріске жететін мерзімі өткен соң тағы бір рет өтіңіз.

Резервтік көшірмелерді миграцияланған деп санауға болмайды

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

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

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

Басқарылатын сервистер клиенттік кілт ротациясынан кейін әртүрлі жұмыс істейді. Google Cloud KMS құжаттамасы үш нұсқаны сипаттайды: сервис DEK-ті автоматты түрде қайта орауы, жаңа нұсқаны тек болашақ деректерге қолдануы немесе бастапқы нұсқаны жалғастыра пайдалануы мүмкін. Бір қойманың мінез-құлқын екіншісіне ұқсастықпен көшірмеңіз. Нақты сервисті тексеріп, нәтижесін өз қалпына келтіру тестіңізбен растаңыз.

Құпияларға деректер миграциясы емес, бөлек процедура қажет

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

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

Нашар жоспар былай естіледі: «Master key-ді бұрамыз, демек токендер қауіпсіз». Жоқ. Токен беріліп қойған болса, ол кері қайтарылғанға, мерзімі біткенге немесе провайдер жағында ауыстырылғанға дейін жұмыс істей береді. Маңызды интеграциялар үшін провайдер екі белсенді есептік деректі, нұсқа идентификаторларын және ескінің қолданылуын бақылауды қолдай ма, тексеріңіз.

AI Router модельдерге қолжетімділікті бірыңғай үйлесімді API endpoint артында ұстауға көмектеседі, бірақ шлюздің өзіне арналған қолжетімділік кілті де өзіндік өмірлік циклі бар құпия болып қала береді. Оны пайдаланушы деректерін қайта шифрлау пакетіне бөлек қатар жұмыс істеу және кері қайтару жоспарынсыз қоспаңыз.

Ескі кілтті жою үшін дәлел қажет

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

Шифрды ашуды өшірмес бұрын төрт дәлелді қолданамын:

1. Инвентаризация барлық белгілі қоймалардың миграцияланғанын немесе архивтік оқу режимінде әдейі қалдырылғанын көрсетеді.
2. Метадеректер сканері жұмыс қоймаларында ескі нұсқасы бар объектілерді таппайды.
3. Ескі нұсқаны оқу метрикалары таңдалған кезең бойы, жоспарланған тапсырмаларды қоса есептегенде, нөл болып қалады.
4. Команда құжатталған процедура бойынша ескі және жаңа бэкаптан сәтті қалпына келтірді.

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

NIST SP 800-57 кілттерді басқаруды алгоритм таңдау емес, бүкіл криптографиялық жүйені жобалаудың бір бөлігі ретінде қарастырады. Бұл дәл тұжырым: AES-GCM v3 нұсқасына қандай деректер әлі тәуелді екенін және оларды кім оқи алатынын айта алмайтын команданы құтқармайды.

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