ოპერაციები და კონფიგურაციის აუდიტი

კონფიგურაციის აუდიტი

1) მიზანი და მნიშვნელობა

კონფიგურაციის აუდიტი უზრუნველყოფს ცვლილებების დადასტურებულ ანგარიშვალდებულებას და განმეორებას: ვინ, როდის და რა შეცვალა; რა არის გამართლებული; როგორც შემოწმებულია; როგორ გამოტოვოთ. ეს ამცირებს ინციდენტების რისკს, საიდუმლოების გაჟონვას, შესაბამისობას და გაყიდვაში „ფარული“ ცვლილებებს.

• ჭეშმარიტების ერთი წყარო (SoT) კონფისკაციისთვის.
• ცვლილებების სრული კვალი (end-to-end).
• პროგნოზირებადი გამოშვებები და სწრაფი დაბრუნება.
• მარეგულირებელი მოთხოვნების დაცვა და უსაფრთხოების პოლიტიკოსები.

2) დაფარვის არეალი

ინფრასტრუქტურა: Terraform/Helm/Ansible/K8s მანიფესტები, ქსელის ACL/WAF/CDN.
გამოყენებითი კონფიგურაციები: ფაილები 'yaml/json/properties', fica დროშები, limites/კვოტები.
საიდუმლოებები და გასაღებები: vault/kms, სერთიფიკატები, ნიშნები, პაროლები.
მონაცემთა პაკეტები: სქემები, ტრანსფორმაციები, ETL/ნაკადის გრაფიკი.
ინტეგრაცია: PSP/KYC/პროვაიდერები, ვებჰუკები, retry/timeout პოლიტიკა.
დაკვირვება: ალერტის წესები, დაშბორდები, SLO/SLA.

3) პრინციპები

Config as Data: დეკლარირებული, ვერსირებული, ტესტირებული არტეფაქტები.
Immutabelity და idempotence: კოდიდან გარემოს რეპროდუქცია.
სქემები და კონტრაქტები: მკაცრი შესაბამისობა (JSON-Schema/Protobuf), უკუკავშირი/თავსებადობა.
სახელმძღვანელო ცვლილებების შემცირება: ცვლილებები მხოლოდ MR/PR- ის საშუალებით.
მოვალეობების გამიჯვნა (SoD) და 4-eyes: ავტორი! = deploer; სავალდებულო შურისძიება.
ატრიბუტი და ხელმოწერები: კომუნების/გამოცემების ხელმოწერები, არტეფაქტების ატესტაცია.

4) აუდიტის არქიტექტურა

1. SCM (Git), როგორც SoT: ყველა კონფისკაცია საცავებში, დაცული არის 'main' ფილიალი.

• Config Registry (ჩამორთმევის, საკუთრების კატალოგი, SLA, გარემო),
• Schema Registry (კონფისკაციის/გამომძიებლების სქემების ვერსიები),
• Policy Engine (OPA/Conftest) - ინსპექტირების ნაკრები.
• 3. CI/CD კარიბჭეები: ფორმატი/სქემა, სტატიკური შემოწმება - პოლიტიკური შემოწმება - საიდუმლო სკანირება - dry-run და ცვლილების გეგმა.
• 4. Delivery: GitOps (მაგალითად, ArgoCD/Flux) ერთად drift დეტექტორი და აპლიკაციების აუდიტის ლოგოები.
• 5. Evidence Store: აუდიტის ნიმუშების შენახვა (გეგმა, ლოგოები, ხელმოწერები, ბილეთები, SBOM).
• 6. სამოქმედო ჟურნალი: მოვლენების მუდმივი ჟურნალი 'CREATE/APPROVE/APLBACK/ACCE'.

5) აუდიტის მონაცემთა მოდელი (მინიმალური)

Сущности: `ConfigItem(id, env, service, owner, schema_version, sensitivity)`

События: `change_id, actor, action, ts, diff_hash, reason, approvals[]`

Артефакты: `plan_url, test_report_url, policy_report, signature, release_tag`

ობლიგაციები: RFC/ticet - PR deple (sha) - გამოშვება-ჩაწერა და SLO- ს მონიტორინგი.

6) ცვლილების პროცესი (დასრულება)

1. RFC/ticket - მიზანი, რისკი, backout.
2. PR/MR - ლინტინგი, სქემატური შემოწმება, პოლიცია, საიდუმლო სკანირება.
3. გეგმა/გადახედვა/გადახედვა dry-run/plan- ით, რესურსების შემცირება, ღირებულების/იმპორტის შეფასება.
4. Approve (4-eyes/SoD, CAB ეტიკეტი მაღალი რისკით).
5. Deploy (ფანჯრის/კალენდრის მიხედვით) იყენებს GitOps; შედის drift-alerting.
6. Smoke/SLO გარდერობების გადამოწმება, შედეგის დადასტურება.
7. მტკიცებულებების არქივირება; კონფიგურაციის ლექსიკონის განახლება.

7) პოლიტიკა და წესები (მაგალითები)

SoD: PR ავტორი არ გაანადგურებს პროდუქტს.
დროის შეზღუდვა: აკრძალულია freeze- ს გარეთ ჩაძირვა.
სკოპი: მგრძნობიარე კლავიშების შეცვლას მოითხოვს 2 აფროვერი უსაფრთხოების/კომპლექსისგან.
საიდუმლოებები: აკრძალულია რეპო შენახვა; მხოლოდ ბმულები vault ბილიკზე + წვდომის როლი.
ქსელები: ingress s '0. 0. 0. 0/0 'აკრძალულია დროებითი გამონაკლისის გარეშე და TTL.
ალერტა: აკრძალულია P1- ის კრიტიკის შემცირება CAB- ის გარეშე.

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

შენახვა Vault/KMS, მოკლე TTL, ავტომატური როტაცია.
საიდუმლო სკანირება CI- ში (გასაღების ნიმუშები, მაღალი ენთუზიაზმი).
საიდუმლოებების იზოლაცია გარემოში/როლებზე; მინიმალური აუცილებელი პრივილეგიები.
დაშიფვრა „მავთულზე“ და „მარტო“; საიდუმლო წვდომის დახურული აუდიტის ლოგოები.

9) ინსტრუმენტები (ცვალებადია)

Lint/Schema: `yamllint`, `jsonschema`, `ajv`, `cue`.
Policy: OPA/Conftest, Checkov/tfsec/kube-policies.
GitOps: ArgoCD/Flux (drift detection, audit, RBAC).
საიდუმლოებები: HashiCorp Vault, cloud KMS, cert მენეჯერები.
სკანერები: trufflehog, gitleaks (საიდუმლოებები); OPA/Regula (წესები).
ანგარიში: ჟურნალების export DWH/BI- ში, ინციდენტთან და შედარების სისტემასთან ერთად.

10) წესებისა და არტეფაქტების მაგალითები

JSON-Schema ლიმიტების კონფიგურაციისთვის

json
{
"$schema": "http://json-schema. org/draft-07/schema#",
"title": "limits",
"type": "object",
"required": ["service", "region", "rate_limit_qps"],
"properties": {
"service": {"type":"string", "pattern":"^[a-z0-9-]+$"},
"region": {"type":"string", "enum":["eu","us","latam","apac"]},
"rate_limit_qps": {"type":"integer","minimum":1,"maximum":5000},
"timeouts_ms": {"type":"integer","minimum":50,"maximum":10000}
},
"additionalProperties": false
}

Conftest/OPA (რეგო) - აკრძალვა '0. 0. 0. 0/0` в ingress

rego package policy. network

deny[msg] {
input. kind == "IngressRule"
input. cidr == "0. 0. 0. 0/0"
msg:= "Ingress 0. 0. 0. 0/0 is not allowed. Specify specific CIDRs or throw an exception with TTL"
}

Conftest/OPA - SoD (prod არ გაანადგურებს ავტორი)

rego package policy. sod

deny[msg] {
input. env == "prod"
input. pr. author == input. pr. merger msg: = "SoD: PR author cannot hold in prod."
}

SQL (DWH) - ვინ შეამცირა ალერტების კრიტიკა თვეში

sql
SELECT actor, COUNT() AS cnt
FROM audit_events
WHERE action = 'ALERT_SEVERITY_CHANGED'
AND old_value = 'P1' AND new_value IN ('P2','P3')
AND ts >= date_trunc('month', now())
GROUP BY 1
ORDER BY cnt DESC;

Git შეტყობინებების მაგალითი (სავალდებულო ველები)

feat(config/payments): raise PSP_B timeout to 800ms in EU

RFC: OPS-3421
Risk: Medium (PSP_B only, EU region)
Backout: revert PR + restore timeout=500ms
Tests: schema ok, conftest ok, e2e ok

11) მონიტორინგი და ალერტინგი

Drift დეტაჟი: კონფისკაცია მტევანში - Git - P1/P2 სიგნალი + მანქანის რემედიაცია (ჩანაწერი).
High-risk change: ქსელების/საიდუმლოებების შეცვლა/პოლიტიკოსი - შეტყობინება # უსაფრთხოების-ოპებში.
Missing evidence: deple გარეშე გეგმა/ხელმოწერა/მოხსენებები - ბლოკი ან ალერტი.
Expired assets: სერთიფიკატები/გასაღებები - პრო-აქტიური ალერტები.

12) მეტრიკი და KPI

Audit Coverage% - ჩამორთმევის წილი სქემების/პოლიტიკოსების/სკანერების ქვეშ.
Drift MTTR - დრიფტის აღმოფხვრის საშუალო დრო.
Policy Compliance% - პოლიტიკოსის გადასასვლელი PR- ზე.
Secrets Leak MTTR - გაჟონვიდან გაჟონვამდე/როტაციამდე.
Backout Rate არის კონფიგურაციის ცვლილების გამოტოვების წილი.
Mean Change Size არის საშუალო ხაზი/რესურსები (ნაკლები - უკეთესი).

13) ანგარიშები და შესაბამისობა

აუდიტის კვალი: შენახვა 1-3 წელი (მოთხოვნების შესაბამისად), უცვლელი შენახვა.
რეგულატორი: ISO 27001/27701, SOX მსგავსი SoD, GDPR (PII), ინდუსტრიის მოთხოვნები (iGaming: GGR/NGR, limites, ბონუსის წესები).
ყოველთვიური მოხსენებები: ტოპ ცვლილებები, პოლიტიკოსების დარღვევები, სერთიფიკატების ამოწურვა, როტაციების სტატუსი.

14) პლეიბუკი

A. აღმოაჩინეს დრიფტი გაყიდვაში

1. დაბლოკეთ მანქანა დისტანციური მომსახურებისთვის.
2. მიმდინარე მდგომარეობის სარტყლის ამოღება.
3. შეადარეთ Git, დაიწყეთ 'reconcile' ან გამოტოვება.
4. შექმენით P2 ინციდენტი, მიუთითეთ დრიფტის წყარო (სახელმძღვანელო kubectl/კონსოლი).
5. ჩართეთ დაცვა: პირდაპირი ცვლილებების აკრძალვა (PSP/ABAC), აცნობეთ მფლობელებს.

B. ამოიწურა PSP სერთიფიკატი

1. გადართეთ სარეზერვო მარშრუტზე/PSP, შეამცირეთ Timauts/retrais.
2. გაუშვით ახალი სერთიფიკატი PKI პროცესის საშუალებით, განაახლეთ კონფიგურაცია Git- ის საშუალებით.
3. სმოკის ტესტი, ტრაფიკის დაბრუნება, ინციდენტის დახურვა, პოსტ-მორტის ჩატარება.

C. საიდუმლო მოხვდა PR- ში

1. გაიტანეთ გასაღები/ნიშანი, გამოიყენეთ როტაცია.
2. გადაწერეთ ისტორია/ამოიღეთ ქეში არტეფაქტი, შეადგინეთ RCA.
3. დაამატეთ წესი საიდუმლო სკანერში, ასწავლეთ გუნდი.

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

ხელნაკეთი კორექტირება „გაყიდვაში“ კვალის გარეშე და უკან დაბრუნების გარეშე.
კონფისკაცია სქემების გარეშე და შეუსაბამობის გარეშე.
საიდუმლოებები Git/CI ცვლადის გარეშე KMS/Vault.
მონორეპო „გლობალური სუპერ სამართლის“ ეკვივალენტით.
„ყრუ“ GitOps drift ალერტებისა და გამოყენების ჟურნალების გარეშე.
უზარმაზარი PR „ყველაფერი და დაუყოვნებლივ“ არის უცნაური ატრიბუტი და მაღალი რისკი.

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

მერჯამდე

• სქემა და ლინტერი დასრულდა
• პოლიტიკოსები OPA/Conftest „მწვანე“
• საიდუმლო-სკანი - „სუფთა“
• გეგმა/თან ერთვის, რისკი შეფასებულია, backout მზად არის
• დაცული 2 აფროუ () და SoD

deploy- მდე

• გამოშვების ფანჯარა და კალენდარი
• დრიფტის მონიტორინგი აქტიურია
• SLO გარდერობები მორგებულია, მცირე ტესტები მზად არის

ყოველთვიურად

• კლავიშების/სერთიფიკატების როტაცია გრაფიკით
• მესაკუთრეთა ინვენტარიზაცია და უფლებები
• ORA/გამონაკლისი (TTL)
• პლეიბუკის ინციდენტის ტესტი (fire-drill)

17) დიზაინის რჩევები

შეწყვიტეთ ცვლილებები მცირე დიფებში; ერთი PR არის ერთი მიზანი.
სავალდებულო PR/კომუნალური შაბლონები RFC/რისკით/გამოტოვებით.
დინამიური კონფიგურაციისთვის გამოიყენეთ „ჩამორთმევის ცენტრები“ აუდიტით და rollback.
პარამეტრების სქემები; აკრძალეთ breaking მიგრაციის გარეშე.
ვიზუალიზაცია მოახდინეთ „ჩამორთმევის რუქაზე“: რა, სად, ვის აკონტროლებს.

18) ინტეგრაცია ცვლილებებისა და ინციდენტების მენეჯმენტთან

PR - RFC - გამოშვების კალენდარი, ინციდენტები/პოსტ-mortems.
მეტრიკის (SLO/ბიზნესი) ავტომატური დაჭერა კონფიგურაციის გამოშვებისთვის.
ამოცანების შექმნა ძველი დროშების/გამონაკლისის (TTL) მოცილებისთვის.

19) შედეგი

კონფიგურაციის აუდიტი არ არის „ქაღალდის ანგარიში“, არამედ საოპერაციო საიმედოობის მექანიზმი: კონფიგურაცია - მონაცემები, ცვლილებები - კონტროლირებადი და შემოწმებული, საიდუმლოებები - საკეტის ქვეშ, და მთელი ამბავი - გამჭვირვალე და შემოწმებულია. ეს არის სტაბილური, კომპოზიციური და პროგნოზირებადი პლატფორმა.