კონფიგურაციისა და საიდუმლოების მართვა

კონფიგურაციის და საიდუმლოების მენეჯმენტი

1) რატომ არის ეს აუცილებელი?

• პროგნოზირებადი (სქემები, შესაბამისობა, ვერსიები).
• უსაფრთხო (დაშიფვრა, მინიმალური უფლებები, როტაცია).
• მართვადი (GitOps, აუდიტი, გამოტოვება).
• დინამიური, სადაც ის გამართლებულია (feature flags, ლიმიტების პარამეტრიზაცია).

2) არტეფაქტების კლასიფიკაცია

საზოგადოებრივი კონფისკაციები: ფიჩები, ბარიერები, ტაიმაუტები, ფანტაზიის ყვავილები (საიდუმლოების გარეშე).
მგრძნობიარე კონფისკაციები: პარამეტრები, რომლებიც ცვლის კრიტიკულ გზების ქცევას (მაგალითად, გადახდის შეზღუდვები).
საიდუმლოებები: პაროლები/გასაღებები/ნიშნები/სერთიფიკატები/დაშიფვრის მასალები.
ნდობის არტეფაქტები: ფესვი/შუალედური სერთიფიკატები, PKI პოლიტიკოსები, KMS გასაღებები.

ცალკეული შენახვისა და უფლებების პრინციპი: საზოგადოებრივი და მგრძნობიარე საიდუმლოებები.

3) კონფიგურაციის იერარქია

1. Global defaults (org-wide).

2. Environment (`prod/stage/dev`).

3. Region (`eu-central-1`, `us-east-1`).

4. Tenant/Brand (მულტფილმის ტენანტებისთვის).

5. მომსახურება (კონკრეტული მიკრო სერვისი).

6. Override (runtime) - დროებითი კონცენტრატორები.

შერწყმის წესები: „ქვემოთ გაიმარჯვებს“, კონფლიქტი მხოლოდ MR/approval- ის საშუალებით ხდება.

მაგალითი (YAML)

yaml defaults:
http:
timeout_ms: 800 retry: 2 prod:
http:
timeout_ms: 1200 service: payments-api overrides:
eu-central-1:
http:
timeout_ms: 1500

4) სქემები და შესაბამისობა

თითოეული კონფისკაცია - ხელშეკრულება სქემასთან (JSON Schema/OPA/CI შემსრულებლები).

ტიპები, დიაპაზონი, სავალდებულო ველები, ნაგულისხმევი მნიშვნელობები.
„Guard წესები“ (თქვენ არ შეგიძლიათ დააყენოთ 'retry> 5', 'p95 _ target <50ms').
ავტომატური შემოწმება CI- ში და გამოყენებისას (admission-webhook/KRM).

ფრაგმენტი JSON Schema

json
{
"type":"object",
"properties":{
"http":{"type":"object","properties":{"timeout_ms":{"type":"integer","minimum":100,"maximum":10000},"retry":{"type":"integer","minimum":0,"maximum":5}},"required":["timeout_ms"]},
"feature_flags":{"type":"object","additionalProperties":{"type":"boolean"}}
},
"required":["http"]
}

5) კონფისკაციის მიწოდების მოდელები

Static (გამოსახულების დაბომბვა): საიმედოდ, მაგრამ მოითხოვს გადატვირთვას.
Push/Watch: აგენტები/sidecar იღებენ განახლებებს (stream/poll) და სიგნალებს განაცხადს.
Pull on startup: ჩვენ ვიღებთ sneapshot დაწყების დროს (გამარტივება hot-path).
Edge cache/proxy გეო-განაწილებული დატვირთვისთვის.

მთავარია: ატომურობა და სნაიპერების ვერსიები, თავსებადობის კონტროლი და სწრაფი დაბრუნება.

6) ინსტრუმენტები და როლები

ჩამორთმევის საცავი: Git (ჭეშმარიტების წყარო) + GitOps (Argo/Flux), Parameter Store/Config Service.
საიდუმლოების საცავი: Vault, AWS Secrets Manager/SSM, GCP Secrets, Azure KV.
დაშიფვრა: KMS/HSM, SOPS (age/GPG/KMS), Sealed Secrets, Transit დაშიფვრა (Vault).
ადგილზე მიტანა: CSI Secrets Store, Vault Agent Injector/Sidecar, init კონტეინერები.
დროშები/დინამიკა: ფიგურის დროშის პლატფორმა (ფრაგმენტი სასწრაფო დახმარების გამშვები).

7) დაშიფვრა: მოდელები და პრაქტიკა

rest: KMS გასაღებები პროექტი/გარემო, განახლებადი დაშიფვრა.
Transit: TLS/mTLS ურთიერთგაგებით.
At use: გაშიფვრა რაც შეიძლება მოგვიანებით, სასურველია - პროცესის მეხსიერებაში/sidecar (დისკზე ჩაწერის გარეშე).
საკვანძო იერარქია: Root (HSM) - KMS CMK - მონაცემები (DEK).
როტაცია: კალენდარი (90/180 დღე) + ღონისძიება (თანამშრომლის კომპრომისი/წასვლა).

8) საიდუმლოების მართვა: ნიმუშები

8. 1 GitOps + SOPS (სტატიკური სნაიპშოტი)

Git შეიცავს მხოლოდ შიფრაციას.
გაშიფვრა CI/CD- ში ან კლასტერზე (KMS/age).
პროგრამა კონტროლერის (Flux/Argo) საშუალებით Kubernetes Secret.

yaml apiVersion: v1 kind: Secret metadata: { name: psp-keys, namespace: payments }
type: Opaque data:
apiKey: ENC[AES256_GCM,data:...,sops]

8. 2 Vault Agent Injector (დინამიური გამოცემა)

მომსახურების ანგარიში (JWT/SA) ავთენტურია Vault- ში.
Sidecar აყენებს კრედიტებს tmpfs- ში და განაახლებს TTL- ს.
დინამიური კრედიტების მხარდაჭერა (DB, cloud - იზოლაცია და მოკლე დროში).

yaml annotations:
vault. hashicorp. com/agent-inject: "true"
vault. hashicorp. com/role: "payments-api"
vault. hashicorp. com/agent-inject-secret-db: "database/creds/payments"

8. 3 CSI Secrets Store

საიდუმლო, როგორც volume, როტაცია გამჭვირვალეა.
PKI- სთვის - სერთიფიკატების/გასაღებების ავტომატური განახლება.

9) კუბერნეტები: პრაქტიკული ასპექტები

ConfigMap მხოლოდ საჯარო/მგრძნობიარე მონაცემებია.
საიდუმლო - მგრძნობიარე (base64 წლიდან - არ არის დაშიფვრა; ჩართეთ Encryption at Rest etcd).
Checksum ვიდეოები: Restart Deployment კონფიგურაციის შეცვლისას.
Admission კონტროლი: საიდუმლოებების დამონტაჟების აკრძალვა არ არის „თეთრი სიიდან“, მანიფესტებში პაროლების აკრძალვა.
ქსელის პოლიტიკა: შეზღუდეთ საიდუმლოების მიმწოდებლებზე წვდომა (Vault/CSI).

Checksum მაგალითი (Helm)

yaml annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}

10) წვდომის პოლიტიკა (RBAC/ABAC)

Least privilege: მომსახურება ხედავს მხოლოდ მის საიდუმლოებებს; წვდომა namespace/label/prefix.
Split duties: Split duties: Secret- ნებისმიერი კითხვის აუდიტი.
დროებითი კრედიტები: დინამიური ლოგინები (DB, cloud) TTL- ით და ავტომატური როტაციით.
სეგმენტი: Stage/stage სხვადასხვა პროექტებში/ანგარიშებში/KMS გასაღებები.

11) აუდიტი, ჟურნალები, დაკვირვება

საიდუმლოების კითხვის/გამოცემის ლოგოები: ვინ/როდის/რა/საიდან; კორელაცია გამოშვებებთან და ინციდენტებთან.
მეტრიკა: ზარების სიხშირე, საიდუმლოებების ამოწურვა, ვადაგასული სერთიფიკატები, დინამიური კრედიტების წილი.
უსაფრთხოების მოვლენები: კვოტების გადაჭარბება, IP/დროის ანომალიები, მრავალი წარუმატებელი ავთენტიფიკაცია.

12) საიდუმლოებებისა და სერთიფიკატების როტაცია

სტანდარტიზებული ვადები: API გასაღებები - 90 დღე, DB პაროლები - 30 დღე, TLS სერჟები - 60-90 დღე.
როტაციის წრე: გამომუშავება - ტესტი - ორმაგი გამოქვეყნება (გრეისი), ძველი გადართვა და მიმოხილვა - გადამოწმება.
უმოქმედობა: ჩამორთმევის/საიდუმლოებების ორმაგი ჩაწერა, მომხმარებელთა თავსებადობა (accept new + old).
PKI: საკუთარი CA ან გარე ინტეგრაცია; MTLS მასალების ავტომატური განახლება CSI/Vault- ის საშუალებით.

13) დინამიური კონფიგურაცია და feature flags

„ცხელი“ პარამეტრები (ლიმიტები, ტაიმაუტები) აიღეთ კონფისკაციის სამსახურიდან/დროშის პლატფორმიდან.
ადგილობრივი ქეში და სტიკინგი (ჰაშის ვარიანტის გაანგარიშება), მოკლე TTL.
SLO მცველები მგრძნობიარე პარამეტრების შეცვლისთვის (ავტომატური გამოტოვება და კილ-სვიტჩი).

14) ინტეგრაცია CI/CD და GitOps

Pre commit/CI: სქემების ლინზები, SOPS შემოწმება, „შიშველი“ საიდუმლოებების აკრძალვა (სკანერები: gitleaks/trufflehog).
Policy Gate: OPA/Conftest - კონფიგურაციის აკრძალვა სქემის გარეშე/მფლობელის განცხადებების გარეშე/გარემოსდაცვითი ეტიკეტების გარეშე.
პროგრესული მიწოდება: კონფიგურაცია, როგორც არტეფაქტები, პარამეტრების შეცვლა.
გამოცემების მენიუ: ვინ/რა კონფისკაცია/საიდუმლო შეიცვალა; სწრაფი კორელაცია p95/5xx- სთან.

15) მაგალითები

15. 1 OPA პოლიტიკა: ღია SG აკრძალვა კონფისკაციაში

rego package policy. config

deny[msg] {
input. kind == "SecurityGroupRule"
input. cidr == "0. 0. 0. 0/0"
input. port = = 5432 msg: = "Postgres open internet banned"
}

15. 2 „Snapshot“ კონფისკაციის მაგალითი (ვერსირებული)

yaml version: 1. 12. 0 owner: payments-team appliesTo: [ "payments-api@prod" ]
http:
timeout_ms: 1200 retry: 2 withdraw:
limits:
per_txn_eur: 5000 per_day_eur: 20000 flags:
new_withdrawal_flow: false

15. 3 Vault - BD დინამიური კრედიტები

hcl path "database/creds/payments" {
capabilities = ["read"]
}
role issues user/password with TTL = 1h and auto-rollover

16) ანტი შაბლონები

საიდუმლოებები Git- ში ღია ფორმით/Helm/Ansible ცვლადი დაშიფვრის გარეშე.
ერთი „მეგა-საიდუმლო“ ყველა სერვისის/გარემოსთვის.
გრძელი ნიშნები TTL/როტაციის გარეშე; „უკვდავი“ სერთიფიკატები.
დინამიური კონფიგურაცია სქემების/ვალიდაციის გარეშე და ცვლილებების აუდიტის გარეშე.
Encryption at Rest- ის არარსებობა etcd/KMS და ქსელი mTLS- ის გარეშე.
კონფიგურაციის სახელმძღვანელო კორექტირება გაყიდვაში (GitOps- ის გვერდის ავლით).
დეველოპერების წვდომა კეთილ საიდუმლოებებზე „მხოლოდ შემთხვევაში“.

17) განხორციელების სიის სია (0-60 დღე)

0-15 დღე

ჩართეთ სქემები/ჩამორთმევა; დაიწყეთ რეპო „კონფიგურაციები“ და GitOps Stream.
ამაღლება KMS და დაშიფვრა: SOPS/Sealed Secrets/Encryption at Rest etcd.
აკრძალეთ plaintext საიდუმლოებები CI (სკანერები), შემოიღეთ owners/approvals.

16-30 დღე

გაზიარეთ საცავი: საზოგადოებრივი კონფიგურაცია მგრძნობიარე საიდუმლოებებით.
შემოიღეთ Vault/Secrets მენეჯერი, შეარჩიეთ მიწოდების მარშრუტი (Agent/CSI/SOPS).
TLS/DB/PSP კრედიტების კონფიგურაცია; დაშბორდები „სიცოცხლის ხანგრძლივობა/ამოწურვა“.

31-60 დღე

დინამიური კონფიგურაცია და დროშები SLO გეიტინგით და მანქანის გამოტოვებით.
პოლიტიკოსები OPA/Conftest; zero-trust (namespace/label-scoped წვდომა).
თამაშის დღე: საიდუმლოების გაჟონვის სიმულაცია და ფორსმაჟორული როტაცია.

18) სიმწიფის მეტრიკა

დაშიფვრის საიდუმლოებების% და Git = 100% პირდაპირი წვდომის გარეშე.
ჩამორთმევის დაფარვა სქემებით/მოვალეობებით - 95%.
კრიტიკული საიდუმლოებების ბრუნვის საშუალო დრო (მიზანი: საათი, არა დღეები).
დინამიური კრედიტების წილი (DB/cloud) 80% -ს შეადგენს.
0 ინციდენტი „plain secrets „/ვადაგადაცილებული სერთიფიკატების გამო.
MTTR კონფიგურაციის შეცდომით გამოტოვებით <5 წუთი.

19) გუნდური როლები და პროცესები

Config Owner: დომენის/სქემების მფლობელი/პოლიტიკოსი.
უსაფრთხოება: პოლიტიკოსები, საკვანძო იერარქია, წვდომის აუდიტი.
Platform/SRE: GitOps, მიწოდება/ინჟექცია, ტელემეტრია.
App Teams: კონფიგურაციის/საიდუმლოების მოხმარება, თავსებადობის ტესტები.

20) დასკვნა

კონფიგურაციებისა და საიდუმლოებების საიმედო წრე არის + GitOps + დაშიფვრა + როტაცია + პოლიტიკა. გაზიარეთ საჯარო და საიდუმლო, დაშიფრეთ ყველაფერი, გამოიყენეთ ატომური და ვერსიულად კონფიგურაცია, მინიმუმამდე დაიყვანეთ კრედიტების უფლებები და სიცოცხლის ხანგრძლივობა, ავტომატურად მოახდინეთ როტაცია და აუდიტი. შემდეგ ცვლილებები სწრაფი და უსაფრთხო გახდება, ხოლო გაჟონვისა და ვარდნის რისკი მინიმალურია.