Құпия менеджменті

Құпия менеджменті

1) Неге және нені «құпия» деп санаймыз

Құпия - ашылуы жүйенің немесе деректердің бұзылуына әкелетін кез келген материал: парольдер, API-токендер, OAuth/JWT private keys, SSH-кілттер, сертификаттар, шифрлау кілттері (KEK/DEK), вебхуктардың қолтаңба кілттері, DSN базалары/кэштері, жеткізушілердің кілттері (төлемдер, пошта/SMS провайдерлері), cookie-тұздар/pepper, боттар/чаттар токендері, лицензиялар.
Құпиялар кодта, конфигада, ортада, контейнерлік бейнелерде, CI/CD, Terraform/Ansible, логтарда/дамбаларда өмір сүреді - құпия менеджментінің міндеті: есепке алу → сақтау → жеткізу → пайдалану → ротация → пікір → аудит → кәдеге жарату.

2) Сәулет қағидаттары

Орталықтандыру. Сақтау, беру және аудит үшін бір сенімді қабат (Vault/Cloud Secret Manager/KMS).
Ең аз артықшылықтар (PoLP). Тек қажетті сервистерге/рөлдерге қол жеткізу, ең аз мерзімге.
Қысқа өмір. TTL/lease бар динамикалық/уақытша құпиялар артықшылықты.
Crypto-agility. Алгоритмдерді/кілттердің ұзындығын тоқтаусыз ауыстыру мүмкіндігі.
Құпияларды кодтан/бейнелерден бөлу. Репозиторийлерде немесе Docker бейнелерінде құпия сөз жоқ.
Бақылау және аудит. Құпияларды берудiң/оқудың әрбiр операциясы логикаланады және құпияландырылады.
Автоматты түрде ротациялау. Ротация - қол акциясы емес, pipeline процесі.

3) Үлгілік шешімдер және компоненттердің рөлдері

KMS/HSM. Түбірлік сенім, шифрлау/кілттерді орау операциялары (envelope).
Secret Manager/Vault. Құпия нұсқаларын сақтау, ACL, аудит, динамикалық құпиялар (DB, cloud-IAM, PKI), ротация үлгілері.
PKI/CA. mTLS/SSH/JWT-қол қою сертификаттарын беру.
Агент/sidecar. Құпияларды рантаймға жеткізу (tmpfs, in-memory k/v, hot-reload файлдары).
CSI драйверлері/операторлары. Kubernetes (Secret Store CSI Driver, cert-manager) бағдарламасымен біріктіру.
Git ішіндегі шифрлау қабаты. SOPS/age, git-crypt (инфрақұрылымдық код үшін).

4) Жіктеу және саясат

• TTL/lease және айналу жиілігі;
• беру тәсілі (статистиканың динамикасы vs), форматы, жеткізгіші;
• кіру саясаты (кім/қайда/қашан/неге), mTLS және өзара сәйкестендіру талаптары;
• аудит (не істейміз, қанша сақтаймыз, кім тексереді);
• break-glass рәсімдері және кері қайтарып алу.

5) Құпияның өмірлік циклі

1. Құру: метадеректері бар (owner, tags, scope) Secret Manager API арқылы.
2. Сақтау: шифрланған түрде (envelope: DEK KMS/HSM-ден KEK оралған).
3. Жеткізу: Авторизацияланған субъектінің сұрауы бойынша (OIDC/JWT, SPIFFE/SVID, mTLS).
4. Пайдалану: тек жадында/tmpfs; логингке/дампқа тыйым салу.
5. Ротация: TTL немесе оқиға бойынша (компрометация); параллель нұсқаларын қолдау (N-1).
6. Кері шақыру/бұғаттау: lease, дизабл аккаунт/кілттің мақсатты жүйеде тез арада аяқталуы.
7. Кәдеге жарату: нұсқаларды/материалдарды жою, аудиттің нақты тізбегі.

6) Динамикалық құпиялар (әдепкі бойынша ұсынылады)

• TTL 15-60 мин. бар ДБ (Postgres/MySQL) есептік деректері.
• Сервистің рөлі бойынша уақытша бұлт кілттері (AWS/GCP/Azure).
• SSH-сертификаттары (мерзімі 5-30 мин), X.509-сертификаттары (сағат/күн).
• Сұрауларға, session-tickets брокерлеріне қол қою үшін уақытша JWT.
• Артықшылықтары: ең аз blast radius, оңайлатылған пікір (әлемде ештеңе «қалмайды»).

7) Құпияларды рантаймға жеткізу

• Secret Store CSI Driver → сыртқы менеджерден pod-ға құпияларды файлдар (tmpfs) ретінде монтаждау.
• Kubernetes Secret жалғыз дереккөз ретінде (base64 ≠ шифрлау); қажет болса - etcd үшін KMS провайдерін қосыңыз.
• Sidecar-агент (Vault Agent/Secrets Store) авто-реневалы lease және hot-reload.
• VM/Bare-metal: Vault/Secret Manager жүйелік агенті + mTLS, жадындағы кэш, ең аз TCB.
• Serverless: бұлтты қоршаған ортаның/файлдардың айнымалы ретінде ашық құпия алмастырумен біріктіру, бірақ ұзақ өмір сүретін envvars - файлдар/жады қалайды.

Мысал (Kubernetes + CSI, тұжырымдамалық)

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8) CI/CD және IaC интеграциялары

CI: воркерлер OIDC (Workload Identity) бойынша қысқа мерзімді токендерді алады. Логтарға түсетін «бүркемеленген» құпияларға тыйым салу; «жылыстау сканері» қадамы (trufflehog/gitleaks).
CD: Деплой құпияларды орналастыру сәтінде алады, оларды артефактілерге жазбайды.
IaC: Terraform айнымалыларды Secret Manager бағдарламасында сақтайды; күйі (state) шифрланады және қатынау бойынша шектеледі.
SOPS/age: репо үшін - шифрланған манифесттерді, кілттерді - KMS басқаруында сақтау.

Мысал (SOPS-фрагмент)

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9) Қол жеткізу саясаты және жұмыс жүктемелерін сәйкестендіру

Workload identity: SPIFFE/SPIRE, Kubernetes SA→OIDC→IAM-роль, mTLS.
Уақытша токендер: қысқа TTL, тар scope.
Secret Manager-дағы ABAC/RBAC: «Y ортасында X құпиясын кім оқи алады» «кім жасауы/ротациялауы мүмкін».
Көп жалдау қабілеті: жалға алушыға жеке namespaces/key-rings; жекелеген саясат пен есептілік.

10) Ротация, нұсқалар және үйлесімділік

Құпия идентификаторы мен оның нұсқаларын бөлісіңіз ('secret/app/db #v17').
Тоқтаусыз ротациялау үшін екі белсенді нұсқаны (N және N-1) қолдаңыз.
Оқиға кезіндегі ротация: жұмыстан шығару, компромат жасау, провайдерді ауыстыру, алгоритмдердің көші-қоны.
Автоматтандырыңыз: Vault/Secret Manager + webhook-триггерлерде қайта іске қосу/реневалада cron/бэкенд айналымы.

Шағын рецепт «екі кілтті» вебхук ротациясы

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11) Рантаймнан тыс сақтау: резервтік көшірмелер мен артефактілер

Артефактілерге (суреттер, логтардың мұрағаттары, дампалар) ешқашан түсуге болмайды.
Secret Manager бэкаптары - шифрлау, сол контурдан тыс сақтау кілттері (separation of duties).
Белгілер мен DLP-сканерлер: S3/Blob/GCS, Git, CI артефактілерінде құпияларды табу.

12) Бақылау, аудит және SLO

Метрика: беру/құпия/сервис саны, өткен lease үлесі, орташа TTL, ротация уақыты, конвергенция уақыты (жаңа нұсқаны «қабылдауға» дейін секунд/минут).
Аудит-логи: кім/не/қашан/қайдан/неліктен; жеке сақтау, сондай-ақ шифрланған.
SLO: 99% беру <200 мс; 0 жылыстау; 100% құпиялардың owner/TTL/тегтері бар; 100% сындарлы құпиялар - динамикалық немесе ротация ≤ 30 күн.
Алерты: құпия аяқталады <7 күн (статиктер үшін), сақтау орнына аутентификация істен шығуы, құпияны оқу жоқ> N күн (өлі), күтпеген гео/ASN көздері.

13) Жиі қателер және оларды болдырмау

Git/бейнелердегі құпиялар. SOPS/age және сканерлерді пайдаланыңыз; саясатымен «жалаңаш» жолдарға тыйым салу.
Envvars ұзақ мерзімді тасымалдаушы ретінде. tmpfs/in-memory файлдарына артықшылық беріңіз; форкаларда/дамбаларда қоршауды тазалаңыз.
dev/stage/prod үшін бірдей құпиялар. Орталарға бөліңіз.
Ұзақ өмір сүретін статикалық парольдер. Динамикалық/қысқа өміршеңге көшіңіз.
Барлығына арналған бірыңғай мастер-кілт. Жалға алушылар/жобалар/сервистер бойынша бөліңіз.
hot-reload жоқ. Бағдарлама айналым кезінде осалдықты қайта қарауды талап етеді.

14) Интеграция үлгілері (схемалық)

Vault динамикалық қатынас Postgres

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

JWT-сұрау қолтаңбасы (қысқа мерзім)

Жеке кілт Secret Manager бағдарламасында сақталады; сервис қысқа уақытты signing-token сұратады және жергілікті агент payload қол қояды (кілт бағдарламаға жол ретінде берілмейді).

SSH әкімшілер сертификаттары

SSO (OIDC) бойынша тұрақты кілттерді таратпай 10 минутқа SSH-cert беру.

15) Жиектері бойынша қауіпсіздік

Логи/трейстер/метриктер: санитайзерлер, белгілі кілттерге/паттерндерге арналған сүзгілер; «құпия» өрістер - APM жасыру.
Дамп/краш-репорттар: әдепкі бойынша кесу; қажет болса - шифрлау және тазалау.
Клиенттік қосымшалар/мобильді: оффлайн-құпияларды барынша азайту, платформалық сақтау орындарын (Keychain/Keystore) пайдалану, құрылғыға байланыстыру, авариялық домалатқышы бар TLS-pinning.

16) Комплаенс

PCI DSS: шифрланбаған PAN/құпияларды сақтауға тыйым салу; қол жеткізу мен ротациялауды қатаң бақылау.
ISO 27001/SOC 2: активтерді басқаруға, журналға жазуға, кіруді бақылауға, конфигурацияларды өзгертуге қойылатын талаптар.
GDPR/жергілікті реттегіштер: барынша азайту, қажеттілігіне қарай қол жеткізу, аудит.

17) Процестер және runbook

Пайдалануға беру

1. Құпияларды түгендеу (репозиторийлер, CI, бейнелер, runtime, бэкаптар).
2. Жіктелуі және тегтері (owner, environment, tenant, rotation-policy).
3. Сақтау орнын таңдау (Vault/Cloud SM) + KMS/HSM біріктіру.
4. Workload identity (OIDC/SPIRE) бойынша беруді теңшеу.
5. ДБ/бұлттар/PKI үшін динамикалық құпияларды қосу.
6. Авто-ротация және hot-reload; экспирациядағы алерта.
7. Жылыстау және Data Catalog/DC сканерлерін теңшеу.

Авариялық сценарийлер

Ағуға күдік: қолжетімділікті тоқтату парағы, дереу ротация, сертификаттарды/кілттерді қайтарып алу, токендерді қайта шығару, жоғары аудитті қосу, RCA.
Secret Manager қол жетімді емес: шағын TTL жадындағы жергілікті кэш, функциялардың тозуы, жаңа қосылымдардың шектелуі, қол break-glass қадамдары.
Түбір кілтінің компрометациясы: key-hierarchy регенерациясы, барлық DEK rewrap, тәуекел терезесі үшін барлық берілімдерді тексеру.

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

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

• Құпиялар кодтан/бейнелерден жойылған; ағу сканерлері қосылды.
• Сындарлы құпиялар үшін динамикалық механизмдер қосылған.
• Ыстық релоадпен sidecar/CSI/tmpfs арқылы жеткізу, ұзақ мерзімді envvars жоқ.
• IAM/ABAC саясаты, workload identity байланыстырылған.
• Үйлесімділік үшін авто-ротация және қосарлы нұсқалар (N, N-1).
• Метриктер/алерттар/аудит енгізілген; деградация тестілері өтті.

Пайдалану

• Ай сайынғы есеп: иелері, TTL, мерзімі өткен құпиялар, пайдаланылмайтын.
• Мерзімді ротациялар және жылыстау жолдарының пентестері (саңылаулар, дамптар, артефактілер).
• crypto-agility жоспары және СА/тамырларды апаттық ауыстыру.

19) FAQ

Q: KMS-сіз Secret Manager жеткілікті ме?
О: Базалық деңгей үшін - иә, бірақ envelope-шифрлауды пайдаланған дұрыс: KMS/HSM-де KEK, құпиялар - ораған. Бұл кері қайтару мен комплаенсті жеңілдетеді.

В: Не таңдау керек - статика немесе динамика?
О: Әдепкі - динамика. Статикті тек қолдау көрсетілетін провайдерлер жоқ жерде қалдырыңыз және TTL + автоматты айналымға дейін жағыңыз.

С: Құпияларды микросервиске қалай қауіпсіз тастау керек?
О: Workload identity → mTLS к Secret Manager → sidecar/CSI → файлы в tmpfs + hot-reload. Логсыз, envvars «мәңгі».

Q: Kubernetes Secret құпияларды сақтауға бола ма?
О: KMS-провайдері мен қатаң саясаты бар etcd шифрлау қосылған кезде ғана. Сыртқы сақтау орны мен CSI-ны таңдаңыз.

С: Жалға алушының қолжетімділігін қалай «крипто-өшіру» керек?
A: Secret Manager-да оның саясатын қайтарып алу/бұғаттау, барлық leases-ті мүгедектендіру, кілттерді ротациялау/қалпына келтіру; KMS пайдаланғанда - тиісті KEK unwrap өшіру.

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