პროდ გარემოს გაძლიერება

1) მიზანი და ჩარჩო

პროდუქტების გარემოს გაძლიერება არის პრაქტიკის სისტემური ერთობლიობა, რაც ამცირებს ინციდენტების ალბათობას და მათგან ზიანს. ფოკუსი: API პერიმეტრი, მომხმარებელთა მონაცემები/გადახდები, CI/CD, კონტეინერის პლატფორმა, წვდომა, ცვლილებების კონტროლი, დაკვირვება და შესაბამისობა მარეგულირებელი მოთხოვნების შესაბამისად.

ძირითადი პრინციპები:

Security by Design & Default: მინიმალური საჭირო პრივილეგიები, უსაფრთხო ნაგულისხმევი.
Zero Trust: არ ენდოთ არც ქსელს, არც იდენტურობას გადამოწმების გარეშე.
Defence-in-Depth: მრავალ დონის დაცვა (ქსელი - სერვისი - პროგრამა - მონაცემები).
არტეფაქტების Immutable: „build once, run many“.
E2E კვალი და აუდიტი: ვინ, როდის, რა შეცვალა - და რატომ.

2) მუქარისა და კრიტიკული აქტივების მოდელი

აქტივები: ანგარიშები და გადახდის ნიშნები, PII/პასპორტის მონაცემები, RNG/თამაშის ბალანსები, დაშიფვრის გასაღებები, ინტეგრაციის საიდუმლოებები, დეპლოკაციის რაციონები, კონტეინერების გამოსახულებები.

ვექტორები: დამოკიდებულების დაუცველობა, ტოქსინების გაჟონვა, ღრუბლის/K8s, SSRF/RCE არასწორად კონფიგურაცია API- ში, supply chain (კომპრომისული CI/CD/საცავი), ინსაიდერის წვდომა, DDoS oS oS oS S oS BoS oS oS oT T TRROOROOOVOOOOOaTaTa

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

3) ქსელის არქიტექტურა და იზოლაცია

სეგმენტი: ინდივიდუალური VPC/VNet stage/stage/dev. Scream- ის შიგნით არის edge ქვესახეები (LB/WAF), API, BD, ანალიტიკოსები, admin სერვისები.
პოლიტიკა „აშკარად ნებადართულია“: deny-all ქვესადგურებს შორის, ჩვენ ვხსნით მხოლოდ საჭირო პორტებს/მიმართულებებს.
mTLS სერვისებს შორის, სერთიფიკატების როტაცია ავტომატიზირებულია.

მაგალითი K8s NetworkPolicy (deny-all + allow-list):

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: default-deny namespace: prod spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: allow-api-to-db namespace: prod spec:
podSelector:
matchLabels: {app: db}
ingress:
- from:
- podSelector: {matchLabels: {app: api}}
ports: [{protocol: TCP, port: 5432}]

4) იდენტურობა და წვდომა (PAM/JIT)

SSO + MFA ყველა ხელმისაწვდომი ადამიანისთვის.
RBAC&ABAC: როლები ღრუბლის, კლასტერის, სახელების და განაცხადის დონეზე.
PAM: jump/bastion, JIT წვდომა (შეზღუდული დრო), სესიის ჩანაწერი.
Break-glass: დალუქული აპარატურა, ჟურნალის გაცემა.
რეგულარული სკანები „ვისაც წვდომა აქვს“, შურისძიება 30 დღეში ერთხელ ხდება.

5) საიდუმლოებები და გასაღებები

საიდუმლოების საცავი (Vault/KMS/Secrets Manager), გამორიცხავს საიდუმლოებებს Git- დან.
KMS/HSM სამაგისტრო გასაღებისთვის; KEK/DEK, ავტომატური როტაცია.
TTL პოლიტიკოსები: მოკლევადიანი ნიშნები (OIDC/JWT), დროებითი აღრიცხვა CI- სთვის.
დაშიფვრა: მარტო (AES-256/GCM), ფრენის დროს (TLS 1. 2 +/mTLS), PII/ბარათის მონაცემების სვეტები - ცალკე გასაღები.

6) Supply chain и CI/CD hardening

Runner- ის იზოლაცია self-hosted კერძო ქსელში.
არტეფაქტების ხელმოწერა (Sigstore/cosign), ხელმოწერის გადამოწმება.
SBOM (CycloneDX/SPDX), SCA/VA თითოეულ კომიტაზე და გამოსვლამდე.
პოლიტიკოსები „არა tag latest“, მხოლოდ იმუნური ჭდეები.
4 - თვალის პრინციპი: სავალდებულო კოდექსი და chapproval.
Infrastructure as Code: Terraform/Helm с policy-as-code (OPA/Conftest).

OPA რეგლის მაგალითი (აკრძალვა საჯარო S3/Storage):

rego package iac. guardrails

deny[msg] {
input. resource. type == "storage_bucket"
input. resource. acl == "public-read"
msg:= sprintf("Public bucket forbidden: %s", [input. resource. name])
}

7) კონტეინერები და კუბერნეტები

გამოსახულების მინიმალური ბაზა (distroless), rootless, read-only FS, drop CAPs.
Admission კონტროლი: აკრძალვა პრივილეგირებული, hostPath, hostNetwork.
Pod Security Standards: baseline/restricted для prod ns.
ImagePolicyWebhook: მხოლოდ ხელმოწერილი სურათების გამოტოვება.
Runtime პოლიტიკა (Falco/eBPF): ალერტები არანორმალური სისკალებისთვის.
É ta/LimitRange: კვანძების დაცვა „ხმაურიანი მეზობლებისგან“.

8) API პერიმეტრი: WAF, Rate Limits, Bot/DDoS

API Gateway: ავთენტიფიკაცია (OAuth2/JWT/HMAC), ნორმალიზაცია, mTLS, სქემის ვალიდაცია.
WAF: ძირითადი წესები + კასტა ბიზნეს მეტრებისთვის.
Rate limits: გლობალური/IP/კლიენტის გასაღები; „ნიშნები“ და burst.

მაგალითი NGINX-rate-limit:

nginx limit_req_zone $binary_remote_addr zone=api:20m rate=10r/s;

server {
location /api/ {
limit_req zone=api burst=30 nodelay;
proxy_pass http://api_backend;
}
}

Bot მენეჯმენტი: ქცევითი სიგნალები, მოწყობილობა fingerprint, გამოწვევა.
DDoS: CDN/edge scrubbing, autoscaling, „dark-launch“ ცხელი იხვები.

9) კონფიგურაციის პოლიტიკა და უსაფრთხო ნაგულისხმევი

Feature flags/kill-switches სარისკო ფუნქციების სწრაფი გათიშვისთვის.
Config-as-Code სქემების შესაბამისობით, ცისფერი/მწვანე კონფიგურაციისთვის.
Time-to-Revoke, როგორც KPI, კონფიგურაციების/გასაღებების ამოღებისას.

10) მონაცემები და კონფიდენციალურობა

კლასიფიკაცია: PII/ფინანსები/ოპერაციული შეცდომები/ტელემეტრია.
მინიმიზაცია: შეინახეთ მხოლოდ საჭირო, ანონიმიზაცია/ფსევდონიზაცია.
Backups: ცალკეული ანგარიში/პროექტი, დაშიფვრა, რეგულარული DR რეპეტიციები.
დასკვნის წესები: same-method, velocity-limites, risk-scoring, 4-თვალები.
Legal Hold/retenshne: შენახვის გრაფიკები, კონტროლირებადი განკარგვა.

11) დაკვირვება, ალერტები და რეაგირება

ტრიადა: ლოგოები (საიდუმლოებას არ შეიცავს), მეტრიკა (SLO/SLA), ტრეისი (W3C).
უსაფრთხოების სიგნალები: შეყვანის წარმატება/წარუმატებლობა, პრივილეგიების ესკალაცია, საიდუმლოებების შეცვლა, ტრაფიკის გადახრა.
SIEM + SOAR: კორელაცია და ნახევრად ავტომატური ფლეიბუკები.
ინციდენტების ფლეიბუკი: DDoS, საიდუმლოების გაჟონვა, runner 'a კომპრომისზე, rollback გამოშვებაზე, გადახდების გაყინვაზე.
MTTD/MTTR, როგორც ოპერატიული ძირითადი მეტრიკა.

12) ცვლილებები და გამოშვება

Change Advisory Board (მსუბუქი) მაღალი დონის ცვლილებებისთვის.
Pre playgates: ტესტები, უსაფრთხოება, პერფი, BD მიგრაცია.
Canary/Blue-Green/Shadow eploes, ავტომატური rollback SLO.
პირდაპირი რედაქტირების აკრძალვა გაყიდვაში: ცვლილებები მხოლოდ დალუქვის გზით.

13) დაუცველობა და პატჩი

Patch policy: კრიტიკული - ASAP; მაღალი - N დღის განმავლობაში.
განმეორებითი სკანირება ფაქსის შემდეგ; CVE წონა ექსპოზიციის მიხედვით.
Chaos-Security: პერიოდული ვარჯიშები „table-top“ და „წითელი გუნდის“ თავდასხმები გამოყოფილი ფანჯრებში.

14) შესაბამისობა და აუდიტი

საკონტროლო ჩარჩოები: PCI DSS (გადახდები), SOC 2, ISO 27001.
არტეფაქტები: მაკონტროლებელი მატრიცა, ცვლილებების ჟურნალები, სკანირების მოხსენებები, DR ტესტების შედეგები, წვდომის მიმოხილვა.
უწყვეტი მზადყოფნა: „evidence as code“ - ნიმუშები იკრიბება ავტომატურად payplines და სისტემებისგან.

15) ეკონომიკა და საიმედოობა

Guardrails ღირებულებით: კვოტები, ბიუჯეტები, ალერტები, გამოუყენებელი რესურსების ავტომატური გამორთვა.
შესაძლებლობები: SLO ორიენტირებული დაგეგმვა, დატვირთვის ტესტები, „ქაოსის დღეები“.
აღდგენის პრიორიტეტები: RTO/RPO მომსახურებისთვის, დამოკიდებულების რუკა.

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

Git- ის საიდუმლოებები, ყველასთვის ზოგადი „admin“, „პირდაპირი SSH prod“, სახელმძღვანელო ფიქსაცია კონტეინერებში, „latest“ ჭდეები, ერთი საერთო მტევანი ყველაფრისთვის, საზოგადოებრივი ბაკეტები, CI-runner გარე ინტერნეტ ქსელში, logs PII, kill - switch „ცხელი“ fices.

17) სწრაფი დაწყების ჩეკის სია (90 დღე)

0-30 დღე

ჩართეთ MFA/SSO, წვდომის შურისძიება; deny all ქსელის პოლიტიკა; Secrets Manager/KMS; აკრძალვა privileged K8s; ჩართეთ WAF/Rate-limit; შესასვლელი/ესკალაციის ძირითადი ალერტები.

31-60 დღე

სურათების ხელმოწერა + ImagePolicy; SBOM + SCA в CI; canary/rollback; SIEM კორელაციები; Playbuks IR; JIT/PAM; სარეზერვო DR ტესტით.

61-90 დღე

OPA-guardrails IaC- ისთვის; eBPF/Falco; ბოტის მენეჯმენტი; periodic access-review; ქაოსის უსაფრთხოების ვარჯიში; ჩამორთმევის აუდიტი და cost-guardrails.

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

წვდომა: MFA- სთან ანგარიშების%, ნიშნების საშუალო ასაკი, გაწვევის დრო.
Pipline: ხელმოწერილი სურათების %/SBOM, SAST/DAST საფარი.
პლატფორმა: pod- ის წილი read-only FS, PSS-restricted, NetworkPolicy საფარი.
პერიმეტრი:% API საბაზო-ლიმიტის/WAF წესებით, საშუალო პასუხი DDoS- ზე.
IR: MTTD/MTTR, სიხშირე „table-top“, წარმატებული DR რეპეტიციების პროცენტი.
შესაბამისობა: კონტროლის წილი ავტომატური მტკიცებულებებით.

19) განაცხადი: პოლიტიკის შაბლონები

AWS SCP (საჯარო ტანკების აკრძალვა)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyPublicS3",
"Effect": "Deny",
"Action": ["s3:PutBucketAcl","s3:PutBucketPolicy"],
"Resource": "",
"Condition": {"StringEquals": {"s3:x-amz-acl": "public-read"}}
}]
}

Kubernetes PodSecurity (namespace-label)

yaml apiVersion: v1 kind: Namespace metadata:
name: prod labels:
pod-security. kubernetes. io/enforce: restricted pod-security. kubernetes. io/audit: restricted

OPA კონტეინერებისთვის (კერძო აკრძალვა)

rego package k8s. admission deny[msg] {
input. request. object. spec. containers[_].securityContext. privileged == true msg:= "Privileged containers are not allowed in prod"
}

20) დასკვნა

პროდ გარემოს გაძლიერება უწყვეტი პროცესია. პრიორიტეტულია მაქსიმალური რისკის შემცირების ზომები: წვდომა და საიდუმლოებები, ქსელის იზოლაცია, არტეფაქტების ხელმოწერა და პაილინის კონტროლი, API პერიმეტრის დაცვა, დაკვირვება და ცვლილებების დისციპლინა. დანარჩენი გაიზარდეთ iterative, დააფიქსირეთ სიმწიფის მეტრიკა და კონტროლის ეკონომიკა.

პროდ გარემოს გაძლიერება