საიდუმლოების მენეჯმენტი

საიდუმლოების მენეჯმენტი

1) რატომ და კონკრეტულად რას ვთვლით „საიდუმლოდ“

საიდუმლო არის ნებისმიერი მასალა, რომლის გამჟღავნება იწვევს სისტემის ან მონაცემების კომპრომისს: პაროლები, API ნიშნები, OAuth/JWT პირადი გასაღებები, SSH გასაღებები, სერთიფიკატები, დაშიფვრის გასაღებები (KEK/DEK), ვებჰუკების ხელმოწერის გასაღებები, DSN ბაზები/ქეში, გასაღებები და მომწოდებები (გადახდები), ფოსტის პროვაიდერები/SMS), cookie მარილი/pepper, ბოტების/ჩატების ნიშნები, ლიცენზიები.
საიდუმლოებები ცხოვრობენ კოდში, კონფისკაციაში, გარემოში, კონტეინერის სურათებში, CI/CD, Terraform/Ansible, dolls/damps - საიდუმლოების მართვის ამოცანა: აღრიცხვა, შენახვა, მიწოდება, გამოყენება, როტაცია, მიმოხილვა, აუდიტი და განკარგვა.

2) არქიტექტურის პრინციპები

ცენტრალიზაცია. ერთი სანდო ფენა (Vault/Cloud Secret Manager/KMS) შენახვის, გაცემისა და აუდიტის მიზნით.
ყველაზე მცირე პრივილეგიები (PoLP). წვდომა მხოლოდ საჭირო სერვისებზე/როლებზე, მინიმალური ვადით.
მოკლე ცხოვრება. სასურველია დინამიური/დროებითი საიდუმლოებები TTL/Lease- ით.
Crypto-agility. ალგორითმების/კლავიშების სიგრძის შეცვლის შესაძლებლობა სისუსტის გარეშე.
საიდუმლოებების გამიჯვნა კოდიდან/სურათებიდან. არც პაროლები საცავებში და არც Docker სურათებში.
დაკვირვება და აუდიტი. საიდუმლოებების გაცემის/კითხვის თითოეული ოპერაცია ხდება და ალერტულია.
ავტომატური როტაცია. როტაცია არის პროცესი მილში და არა ხელით აქცია.

3) კომპონენტების ტიპიური გადაწყვეტილებები და როლები

KMS/HSM. ფესვის ნდობა, დაშიფვრის/გასაღების შეფუთვის ოპერაციები (envelope).
Secret Manager/Vault. საიდუმლოების ვერსიების საცავი, ACL, აუდიტი, დინამიური საიდუმლოებები (DB, cloud-IAM, PKI), როტაციის შაბლონები.
PKI/CA. MTLS/SSH/JWT ხელმოწერების მოკლე სერთიფიკატების გაცემა.
აგენტი/sidecar. საიდუმლოებების გადაცემა ranthim- ში (tmpfs ფაილები, in-memory k/v, hot-reload).
CSI დრაივერები/ოპერატორები. ინტეგრაცია Kubernetes- თან (Secret Store CSI Driver, cert მენეჯერი).
დაშიფვრის ფენა Git- ში. SOPS/age, git-crypt (ინფრასტრუქტურული კოდისთვის).

4) კლასიფიკაცია და პოლიტიკა

• TTL/lease და როტაციის სიხშირე;
• გაცემის მეთოდი (დინამიკა სტატიკური), ფორმატი, გადამზიდავი;
• წვდომის პოლიტიკა (ვინ/სად/როდის/რატომ), მოთხოვნები mTLS და ურთიერთდახმარების შესახებ;
• აუდიტი (რომ ჩვენ ვიცავთ რამდენს ვიცავთ, ვინ იძიებს);
• break-glass პროცედურები და მიმოხილვა.

5) საიდუმლოების სიცოცხლის ციკლი

1. შექმნა: API Secret Manager- ის მეშვეობით მეტამონაცემებით (owner, tags, scope).
2. შენახვა: დაშიფრული ფორმით (დაშიფრული: DEK გადაიქცევა KMS/HSM).
3. ადგილზე მიტანა: უფლებამოსილი საგნის მოთხოვნით (OIDC/JWT, SPIFFE/SVID, mTLS).
4. გამოყენება: ექსკლუზიურად მეხსიერებაში/tmpfs- ში; ლოგარიზაციის/დამპების აკრძალვა.
5. როტაცია: TTL- ის ან ღონისძიების მიხედვით (კომპრომისი); პარალელური ვერსიების მხარდაჭერა (N-1).
6. მიმოხილვა/დაბლოკვა: lease- ის დაუყოვნებლივი გასწორება, ანგარიშის/გასაღების დისპლეი სამიზნე სისტემაში.
7. განკარგვა: ვერსიების/მასალის განადგურება, აუდიტის მკაფიო ჯაჭვი.

6) დინამიური საიდუმლოებები (რეკომენდებულია ნაგულისხმევი)

• BD ანგარიშების მონაცემები (Postgres/MySQL) TTL- ით 15-60 წთ.
• ღრუბლების დროებითი გასაღებები (AWS/GCP/Azure) სამსახურის როლის შესაბამისად.
• SSH სერთიფიკატები (5-30 წუთი), X.509 სერთიფიკატები (საათი/დღე).
• დროებითი JWT, რომ ხელი მოაწეროს მოთხოვნებს, ბროკერებს.
• დადებითი: მინიმალური blast radius, გამარტივებული მიმოხილვა (მსოფლიოში არაფერი „დარჩება“).

7) საიდუმლოების გაგზავნა ranthim- ში

• Secret Store CSI Driver არის საიდუმლოებების დამონტაჟება გარე მენეჯერისგან pod- ში, როგორც ფაილები (tmpfs).
• Kubernetes Secret- ის, როგორც ერთადერთი წყაროს თავიდან აცილება (base64 - დაშიფვრა); საჭიროების შემთხვევაში - ჩართეთ KMS პროვაიდერი etcd- სთვის.
• Sidecar აგენტი (Vault Agent/Secrets Store) მანქანის გასაშლელი ხაზით და ცხელი რელიეფით.
• VM/Bare-metal: სისტემის აგენტი + mTLS Vault/Secret Manager, მეხსიერების ქეში, მინიმალური TCB.
• Serverless: ღრუბლის ინტეგრაცია საიდუმლოებების გამჭვირვალე ჩანაცვლებით, როგორც გარემოს/ფაილების ცვლადი, მაგრამ გრძელვადიანი envars- ის თავიდან აცილება - სასურველია ფაილები/მეხსიერება.

მაგალითი (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 ინახავს ცვლადებს საიდუმლო მენეჯერში; სახელმწიფო დაშიფრული და შეზღუდულია წვდომით.
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, ვიწრო სკოპი.
ABAC/RBAC Secret Manager- ში: „ვისაც შეუძლია წაიკითხოს X საიდუმლო Y გარემოში“ განცალკევებულია „ვის შეუძლია შექმნას/როტაცია“.
მრავალფუნქციურობა: ინდივიდუალური namespaces/key-rings მოიჯარეზე; ცალკეული პოლიტიკოსები და მოხსენებები.

10) როტაცია, ვერსიები და თავსებადობა

გაზიარეთ საიდუმლოების იდენტიფიკატორი და მისი ვერსია ('secret/app/db # v17').
შეინარჩუნეთ ორი აქტიური ვერსია (N და N-1) უწყვეტი როტაციისთვის.
ღონისძიების როტაცია: თანამდებობიდან გათავისუფლების, კომპრომისების, პროვაიდერის შეცვლის, ალგორითმების მიგრაციის დროს.
ავტომატიზაცია: cron/backend როტაცია Vault/Secret Manager + პროგრამის გადატვირთვის webhook-trighers/reneval.

მინი რეცეპტი „ორმხრივი“ ვებჰუკის როტაცია

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) შენახვა ranthim- ის გარეთ: სარეზერვო ასლები და ნივთები

არასოდეს მოხვდეთ არტეფაქტებში (სურათები, ლოგოების არქივები, dumps).
Secret Manager Bacapes - დაშიფვრა, შენახვის გასაღებები იმავე მიკროსქემის გარეთ.
ეტიკეტები და DLP სკანერები: საიდუმლოებების აღმოჩენა S3/Blob/GCS, Git, CI არტეფაქტები.

12) დაკვირვება, აუდიტი და SLO

მეტრიკა: ემისიების რაოდენობა/საიდუმლო/სერვისი, ვადაგადაცილებული წილის წილი, საშუალო TTL, როტაციის დრო, კონვერგენციის დრო (ახალი ვერსიის „მიღებამდე“ წამი/წუთი).
აუდიტის ლოგოები: ვინ/რა/როდის/საიდან/რატომ; შენახვა ცალკე, ასევე დაშიფრული.
SLO: გამოშვებების 99% <200 ms; 0 გაჟონვა ლოგებში; საიდუმლოების 100% -ს აქვს owner/TTL/ჭდეები; კრიტიკული საიდუმლოებების 100% - დინამიური ან როტაცია 30 დღის განმავლობაში.
ალერტა: საიდუმლოება იწურება <7 დღის განმავლობაში (სტატიკოსებისთვის), ავთენტიფიკაციაზე უარის თქმის შეწყვეტა, საიდუმლო კითხვა არ არის> N დღე (მკვდარი), მოულოდნელი გეო/ASN წყაროები.

13) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

საიდუმლოებები გიტ/სურათებში. გამოიყენეთ SOPS/age და სკანერები; პოლიტიკა აიკრძალოს „შიშველი“ ხაზები.
Envars, როგორც გრძელვადიანი გადამზიდავი. უპირატესობა მიანიჭეთ tmpfs/in-memory ფაილებს; გაასუფთავეთ გარემო ჩანგლების/დამპების დროს.
იგივე საიდუმლოებები dev/stage/with. გაყოფა გარემოში.
გრძელი სტატიკური პაროლები. გადადით დინამიურ/ხანმოკლე ცხოვრებაზე.
ერთი სამაგისტრო გასაღები „ყველაფრისთვის“. გაზიარეთ მოიჯარეები/პროექტები/სერვისები.
Hot-reload არ არის. პროგრამა მოითხოვს restart - დაუცველ ფანჯრებს როტაციის დროს.

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 მოთხოვნის ხელმოწერა (მოკლე ვადა)

პირადი გასაღები ინახება საიდუმლო მენეჯერში; მომსახურება ითხოვს მოკლევადიანი signing-token და ადგილობრივი აგენტი ხელს აწერს payload- ს (გასაღები არ გადადის განაცხადში, როგორც სტრიქონი).

SSH სერთიფიკატები admins

SSH-cert- ის გაცემა 10 წუთის განმავლობაში SSO- სთვის (OIDC), მუდმივი გასაღებების განაწილების გარეშე.

15) უსაფრთხოება კიდეების გასწვრივ

Logs/traces/მეტრიკა: ექთნები, ფილტრები ცნობილი გასაღებების/ნიმუშებისთვის; „საიდუმლო“ ველები - შენიღბვა APM- ში.
Damps/Crash-Records: მოჭრილი ნაგულისხმევი; თუ საჭიროა, დაშიფვრა და გაწმენდა.
კლიენტის პროგრამები/მობილური: ოფლაინ საიდუმლოებების მინიმუმამდე შემცირება, პლატფორმის საცავის გამოყენება (Keychain/Keystore), მოწყობილობის სავალდებულო, TLS-pinning გადაუდებელი განლაგებით.

16) შესაბამისობა

PCI DSS: PAN/საიდუმლოებების შენახვის აკრძალვა დაშიფვრის გარეშე; წვდომისა და როტაციის მკაცრი კონტროლი.
ISO 27001/SOC 2: მოთხოვნები აქტივების მართვის, ჟურნალისტიკის, წვდომის კონტროლის, კონფიგურაციის ცვლილების შესახებ.
GDPR/ადგილობრივი რეგულატორები: მინიმიზაცია, საჭიროების შემთხვევაში წვდომა, აუდიტი.

17) პროცესები და runbook

ექსპლუატაცია

1. საიდუმლოებების ინვენტარიზაცია (საცავი, CI, სურათები, რუნტიმი, ზურგჩანთები).
2. კლასიფიკაცია და ჭდეები (owner, environment, tenant, rotation-policy).
3. საცავის არჩევანი (Vault/Cloud SM) + ინტეგრაცია KMS/HSM- სთან.
4. კონფიგურაცია სამუშაო პირადობის შესახებ (OIDC/SPIRE).
5. დინამიური საიდუმლოებების ჩართვა BD/ღრუბლებისთვის/PKI.
6. ავტო როტაცია და ცხელი რელიეფი; ალერტები ექსპირაციისთვის.
7. გაჟონვის სკანერების კონფიგურაცია და მონაცემთა კატალოგი/DS.

გადაუდებელი სცენარები

გაჟონვის ეჭვი: წვდომის გაჩერების სია, დაუყოვნებლივი როტაცია, სერთიფიკატების/გასაღებების გაუქმება, ტოქსინების ხელახლა გამოქვეყნება, გაზრდილი აუდიტის ჩართვა, RCA.
Secret Manager მიუწვდომელია: მცირე TTL- ის მეხსიერების ადგილობრივი ქეში, ფუნქციების დეგრადაცია, ახალი ნაერთების შეზღუდვა, სახელმძღვანელო break-glass ნაბიჯები.
ფესვის გასაღების კომპრომისი: კეი-ჰერარქიის რეგენერაცია, ყველა DEK- ის რეპროდუქცია, რისკის ფანჯრის მიღმა ყველა ემისიის შემოწმება.

18) ჩეკის ფურცლები

გაყიდვამდე

• საიდუმლოებები ამოღებულია კოდიდან/სურათებიდან; ჩართულია გაჟონვის სკანერები.

კრიტიკული საიდუმლოებისთვის გამოიყენება დინამიური მექანიზმები.

• მიტანა sidecar/CSI/tmpfs ერთად hot-reload, გამძლე envars- ის გარეშე.
• IAM/ABAC პოლიტიკოსები არიან განწყობილი, workload identity.
• ავტომობილების როტაცია და ორმაგი ვერსიები (N, N-1) თავსებადობისთვის.
• მეტრიკი/ალერტა/აუდიტი შედის; დეგრადაციის ტესტები გაიარა.

ოპერაცია

• ყოველთვიური ანგარიში: მფლობელები, TTL, ვადაგადაცილებული საიდუმლოებები, გამოუყენებელი.
• გაჟონვის მარშრუტების პერიოდული როტაციები და პენტესტები (ლოგოები, ნაგავსაყრელები, არტეფაქტები).
• Crypto-agility გეგმა და SA/ფესვების გადაუდებელი ჩანაცვლება.

19) FAQ

გ: საკმარისია საიდუმლო მენეჯერი KMS- ის გარეშე?
ო: საბაზო დონისთვის - დიახ, მაგრამ უმჯობესია გამოიყენოთ განახლებადი დაშიფვრა: KEK KMS/HSM- ში, საიდუმლოებები გადაიქცევა. ეს ამარტივებს მიმოხილვას და შესაბამისობას.

გ: რა უნდა აირჩიოთ - სტატიკა თუ დინამიკა?
ო: ნაგულისხმევი - დინამიკა. დატოვეთ სტატიკა მხოლოდ იქ, სადაც არ არსებობს მხარდაჭერილი პროვაიდერები და დაწვით TTL დღემდე/საათამდე + ავტომატური როტაცია.

გ: რამდენად უსაფრთხოა საიდუმლოებების მიკრო სერვისში გადატანა?
О: Workload identity → mTLS к Secret Manager → sidecar/CSI → файлы в tmpfs + hot-reload. ლოგოების გარეშე, envars- ის გარეშე „სამუდამოდ“.

გ: შეგიძლიათ საიდუმლოებების შენახვა Kubernetes Secret- ში?
O: მხოლოდ მაშინ, როდესაც etcd დაშიფვრა ხდება KMS პროვაიდერთან და მკაცრ პოლიტიკოსებთან. ურჩევნიათ გარე საცავი და CSI.

გ: როგორ „წაშალოთ“ მოიჯარის დაშვება?
ო: საიდუმლო მენეჯერში მისი პოლიტიკის ამოღება/დაბლოკვა, ყველა ფოთლის ინვალიდობა, გასაღების როტაცია/რეგენერაცია; KMS- ის გამოყენებისას - გამორთეთ შესაბამისი KEK unwrap.

• „დაშიფვრა At Rest“
• „დაშიფვრა In Transit“
• „კლავიშების მართვა და როტაცია“
• „S2S ავთენტიფიკაცია“
• „მოთხოვნის ხელმოწერა და გადამოწმება“