GH GambleHub

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

1) მიზნები და პასუხისმგებლობის სფერო

წარმოება არა მხოლოდ „ყველაზე სტაბილური გარემოა“, არამედ ყველაზე თავდასხმა. ჩვენი ამოცანა:
  • შეტევის არეალის შემცირება და Blast Radius;
  • დაიცავით არხები, ანგარიშები, საიდუმლოებები და მიწოდების ნივთები;
  • MTTR მიზნების უფრო სწრაფად გამოვლენა და რეაგირება;
  • დაადასტურა შესაბამისობა სტანდარტებთან (GDPR/PCI DSS/ადგილობრივი წესები);
  • შეინარჩუნეთ ყველა კრიტიკული მოქმედება.

საკვანძო პრინციპები: Zero Trust, Least Privilege, Segmentation, Everything-as-Code, Security-by-Default.

2) ქსელის პერიმეტრი და სეგმენტი

სეგმენტები: Edge (WAF, bot მენეჯმენტი, DDoS), DMZ (gateway), App (მიკროსერვისები), Data (BD/ქეში), Backofice/Ops (CI/CD, observabilility).
პოლიტიკოსები L4/L7: deny-by-default, აშკარა ალოუ სერვისებზე/ნეიმსპასებზე/პორტებზე.
mTLS კლასტერის შიგნით; TLS 1. 2 + პერიმეტრზე, HSTS, უსაფრთხო შიფრები.
შეყვანის ფილტრი: WAF (OWASP Top-10), inti bot, rate limits, geo/ASN ბლოკები, CAPTCHA რისკის გზაზე.
DDoS დაცვა: always-on + auto-mitigation, ინდივიდუალური პროფილები API/სტატიკური შინაარსისთვის.
Egress კონტროლი: მხოლოდ საჭირო გარე მასპინძლები პროვაიდერებისთვის (PSP/KYC/თამაშები).

3) იდენტურობა, წვდომა და პრივილეგიები (IAM/PAM)

SSO (OIDC/SAML) + MFA ადამიანებისთვის; OIDC ნიშნები/Workload Identity მომსახურებისთვის.
RBAC/ABAC: როლები მინიმალური აუცილებელი რეზოლუციებით; „break glass“ წვდომა აუდიტზე და TTL.
PAM: პრივილეგირებული სესიების დაწერა მოთხოვნით, სრული ჩანაწერი და ჟურნალისტიკა.
CIEM (ღრუბლები): გადაჭარბებული უფლებებისა და მკვდარი როლების ძიება, მანქანის რემედიაცია.
პროდუქტებზე წვდომა: მხოლოდ დამტკიცებული jump/მარიონეტული საშუალებით, PII შენიღბვით.

4) საიდუმლოებები და კრიპტოგრაფია

KMS/HSM: კლავიშების შენახვა, ენერგიის დაშიფვრა, შეტყობინებების როტაცია.
საიდუმლო მენეჯერი: მოკლევადიანი კრედიტები, გამორიცხეთ საიდუმლოებები Git/logs- დან.
ხელმოწერები: არტეფაქტები (cosign), webhooks (HMAC), მომსახურების ნიშნები.
PAN/PII ველები: ტოქსიკაცია/დაშიფვრა at-rest; შენიღბვა ლოგებში და ზემოთ.
როტაციის პოლიტიკოსები: გასაღებები/სერთიფიკატები/პაროლები - რეგულარული და იძულებითი.

5) კონტეინერები და კუბერნეტები (CWPP/KSPM)

ძირითადი სურათები: მინიმალური, დაუცველობის სკანირება CI- ზე; rootless სადაც შესაძლებელია.
ადმისიის პოლიტიკა (OPA/Gatekeeper/Kyverno): კრძალავს ': latest', 'privileged', hostPath; ჩვენ ვითხოვთ სურათების ხელმოწერას.
ქსელის პოლიტიკა: ოფისის კავშირი მხოლოდ საჭიროების შემთხვევაში.
PodSecurity: შეზღუდული capabilities, read-only FS, seccomp, AppARmor.
საიდუმლოებები: საიდუმლო მაღაზიიდან CSI (KMS); არცერთი plain საიდუმლო მანიფესტებში.
Runtime დაცვა: ქცევითი წესები (eBPF), ალერტები ანომალიებში.

OPA წესის მაგალითი (დაუწერელი სურათების აკრძალვა):
rego package k8sadmission deny[msg] {
input. request. kind. kind == "Pod"
some c image:= input. request. object. spec. containers[c].image not startswith(image, "registry. company. com/signed/")
msg:= sprintf("Image must be signed and come from trusted registry: %v", [image])
}

6) მიწოდების ჯაჭვი: ენდობი, მაგრამ შეამოწმე

SBOM თითოეული ბილეთისთვის; გამოშვებასთან შენახვა და დაკავშირება.
სურათების/მანიფესტების ხელმოწერები, შემოწმება admission კონტროლერში.
SLSA სერტიფიკაცია: არტეფაქტების დადასტურებული წარმოშობა.
Policy-as-Code: Conftest/OPA Terraform/Helm/K8s დურგლის წინ.
აკრძალვა „Last-minute patching“ გაყიდვაზე: ყველა ცვლილება - მხოლოდ pline- ის საშუალებით.

7) დაუცველობისა და პატჩების მართვა

SCA/SAST/DAST в CI; დაბლოკვის ბარიერები critical/high.
ყოველკვირეული განახლების ბრძოლები (სურათები, OS პაკეტები, ბიბლიოთეკები) + გადაუდებელი დაუგეგმავი.
შესრულებული კორექტირება - ticets/გამოშვებები CVE/SBOM ბმულით.
EASM: თავდასხმის ზედაპირის გარე მიმოხილვა (ჩანართები, ღია პორტები, სერთიფიკატები).
რეგულარული კალმის ტესტები: წელიწადში ერთხელ მაინც + მიზნობრივი კრიტიკული ნაკადებით (გადახდები/CCC).

8) აუდიტის ნიმუშების ლოგოები, მეტრიკა, კვალდაკვალ და შენახვა

სტანდარტიზებული ლოგოები (JSON) 'trace _ id', 'request _ id', user/tenant/geo (ფსევდონიმი), PII/PAN- ის გარეშე.
მეტრიკა: p50/p95/p99, error-rate, saturation, DLQ, retrai, Business KPI (Time-to-Wallet).
ტრეისი (OTel): end-to-end კრიტიკული მარშრუტებისთვის (ანაბარი/KUS/დასკვნა).
SIEM: მოვლენების კორელაცია (ავთენტიფიკაცია, როლების შეცვლა, ადმინისტრაციული მოქმედება, WAF/ბოტების წესები).
SOAR: მანქანის რეაქციები (ქვესადგურის იზოლაცია, ნიშნის მიმოხილვა, IP/ASN ბლოკი, გამოშვების აკრძალვა).
Retenschn: ოპერაციული ნათურები - 30-90 დღე ცხელი შენახვა, აუდიტის არტეფაქტები - უფრო გრძელი, პოლიტიკოსების აზრით.

ლოგის მინიმალური ფორმატი (მაგალითი):
json
{
"ts":"2025-11-05T15:00:00Z",
"sev":"WARN",
"svc":"payments-api",
"route":"POST /v1/payments",
"trace_id":"2f9f...e1",
"user":"anon",
"tenant":"eu-casino-12",
"geo":"EU",
"event":"circuit_breaker_open",
"provider":"psp-1"
}

9) ანტიბოტი, თაღლითობა და დამცავი სცენარები

Bot მენეჯმენტი: ხელმოწერები/ქცევა, მოწყობილობები-fingerprint, დინამიური ჩელენჯი.
Rate limits/quotas: per-user/tenant/IP; ადაპტირებულია ანომალიებისთვის.
RASP სენსორები კრიტიკულ ენდოინტებზე (webhooks ხელმოწერის გვერდის ავლით, საათის დრიფტი, ხელახალი მიწოდება).
Fraud სიგნალები: კორელაცია არხებზე (ლოგინები, გადახდები, KYC), მანქანის ესკალაცია.

10) სარეზერვო, DR და BCP

RTO/RPO მიზნების განსაზღვრა და ტესტირება ხდება (მაგალითად, RTO - 1 საათი, RPO - 5 წუთი გადახდის მონაცემთა ბაზებისთვის).
Bacaps: დაშიფრული, პერიოდულად ოფლაინ საცავში; რეგულარული restore ტესტები.
გეო დუბლირება: აქტივი/აქტივი აქტივი რეგიონებისთვის; DNS-failover TTL კონტროლით.
კრიტიკული დამოკიდებულების კატალოგი (PSP/KYC/თამაშების აგრეგატორები) და გადართვის გეგმები.

11) ინციდენტები და რეაგირება

Runbooks: პროვაიდერის დაცემის, ლატენტობის ზრდისთვის, ნიშნის კომპრომისზე, DDoS.
On-call: 24/7, როტაცია და ბლასტის პეიჯი; ერთობლივი „ომის ოთახი“ პრაქტიკა.
კომუნიკაციები: მომხმარებელთა/პარტნიორებისა და რეგულატორების შეტყობინებების შაბლონები.
Post-mortem (blameless): მოქმედებები განმეორების თავიდან ასაცილებლად, პოლიტიკოსის/პლეიბუკების განახლება.

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

GDPR: მონაცემთა შემცირება, თანხმობის რეესტრი, მოცილების/გადაზიდვის უფლება; DPIA ახალი პროვაიდერებისთვის.
PCI DSS: ტოკენიზაცია/იზოლირებული PAN ზონები, ქსელის სეგმენტები, მკაცრი წვდომის ჟურნალები.
ადგილობრივი მოთხოვნები (ბაზრის იურისდიქცია): მონაცემთა შენახვა რეგიონში, ანგარიშგებები, განახლებების ფანჯრები.
მონაცემთა ხაზები: სად და როგორ მიედინება PII/PAN; სქემები და DPIA DevPortal- ში.

13) აუდიტი: ტიპები, არტეფაქტები და ციკლი

აუდიტის ტიპები:
  • შიდა (კვარტალურად): კორესპონდენცია პოლიტიკოსებთან, ცვლილებების კონტროლი, წვდომა, საიდუმლოებები, ლოგოები, პლაკატები.
  • გარე (ყოველწლიურად/მოთხოვნების შესაბამისად): PCI/GDPR/ადგილობრივი რეგულატორები, კალმის ტესტები, პროვაიდერების SOC მოხსენებები.
საკვანძო ნიმუშები (წინასწარ მომზადება):
  • უსაფრთხოების პოლიტიკოსები, IAM როლების მატრიცა, გამონაკლისების სია გასვლის თარიღით.
  • ინფრასტრუქტურის ცვლილების ლოგოები (IaC), CI/CD (SBOM, ხელმოწერები, ტესტები).
  • პროვაიდერების რეესტრი (PSP/KYC/თამაშები), DPIA/მოვაჭრე რისკის შეფასებები, ხელშეკრულებები და SLA.
  • სარეკლამო ჟურნალები, საიდუმლოების როტაციების შედეგები, SIEM/SOAR მოხსენებები.
  • DR/BCP გეგმები და უახლესი restore ტესტების ოქმები.
აუდიტის მიდგომა:
  • „Evidence-first“: თითოეული პრაქტიკა არის დადასტურებული არტეფაქტი.
  • „No humans in vision“: მაქსიმუმი plines და დამტკიცებული განაცხადების საშუალებით; ყველა სესია ჟურნალისთვის.
  • „მოგზაურობა“: დააკავშირეთ ცვლილებები ინციდენტებთან/მეტრიკებთან.

14) Guardrails-as-Code: მაგალითები

Conftest for Terraform (საზოგადოებრივი DD აკრძალვა):
rego package terraform. deny deny[msg] {
input. resource. type == "aws_db_instance"
input. resource. publicly_accessible == true msg:= "RDS must not be public"
}

AdmissionPolicy (K8s): ჩვენ მოითხოვს უსაფრთხოების ეტიკეტებს და რესურსის შეზღუდვებს

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: enforce-security-labels-and-limits spec:
rules:
- name: require-labels match: {resources: {kinds: ["Deployment","StatefulSet"]}}
validate:
message: "security labels required"
pattern:
metadata:
labels:
security. tier: "?"
data. classification: "?"
- name: require-limits match: {resources: {kinds: ["Deployment","StatefulSet"]}}
validate:
message: "resources limits/requests required"
pattern:
spec:
template:
spec:
containers:
- resources:
limits:
cpu: "?"
memory: "?"
requests:
cpu: "?"
memory: "?"

15) ყოველდღიური ჰიგიენის პროდუქტების ჩამონათვალი

  • WAF/bot პოლიტიკოსები აქტიურია, ხელმოწერები განახლებულია; Anti-DDoS always-on რეჟიმში.
  • Admission კონტროლერები კლასტერში enforce, არა audit.
  • ყველა პროტო სურათი გაფორმებულია; SBOM ხელმისაწვდომია და უკავშირდება გამოშვებას.
  • დაუცველი კრიტიკული/მაღალი - არ არსებობს ან აღრიცხულია თარიღის გამონაკლისი.
  • საიდუმლოებების/სერთიფიკატების როტაცია - გრაფიკით, შეფერხებები არ არის.
  • SIEM კორელაციას უწევს IAM/გამოშვებების შესვლის/ცვლილების მოვლენებს; SOAR ფლეიბუქების ტესტირება ხდება.
  • Bacaps- მა გაიარა, რესტავრაციის ტესტი გრაფიკით; DR გეგმა რეალურია.
  • პროდუქტებზე წვდომა - მხოლოდ SSO + MFA/PAM- ის საშუალებით; ყველა სესია იწერება.
  • „No PII logs“ - გამოსახულია სკანერების მიერ; შენიღბვა ჩართულია.
  • Release gates და დაკვირვება განახლებულია „as-code“.

16) სიმწიფის მოდელი (მოკლედ)

1. ძირითადი - სახელმძღვანელო ცვლილებები, ერთი პერიმეტრი, ნაწილობრივი მონიტორინგი.
2. მოწინავე - სეგმენტი, IAM/RBAC, ხელმოწერილი არტეფაქტები, WAF/DDoS, SIEM, რეგულარული პატჩი.
3. ექსპერტი - Zero Trust, guardrails-as-code, SLSA სერტიფიკაცია, runtime დაცვა, SOAR ავტომატიზაცია, „no humans in code“, უწყვეტი აუდიტი.

17) საგზაო რუკა

M0-M1 (MVP): ქსელის სეგმენტი, WAF/DDoS, SSO + MFA, KMS, ძირითადი Admission-policy, სტანდარტიზებული ლოგოები/მეტრიკა/ტრეისი, SIEM.
M2-M3: სურათების ხელმოწერები და admission, SBOM, Conftest/OPA IaC, PAM, როტაციის გეგმა, რეგულარული პატჩი, პირველი DR ტესტები.
M4-M6: SOAR playbuks, eBPF/runtime დეტალი, EASM, შესაბამისობის პაკეტი (PCI/GDPR), აუდიტის ნიმუშების სრული ნაკრები, რეგიონების მიხედვით ring-DR.
M6 +: Zero-Trust ქსელი (mTLS ყველგან), CIEM, ავტომატური აუდიტის ანგარიშები, მუდმივი „purple-team“ ტესტირება.

მოკლე დასკვნა

ძლიერი პროდი არ არის რკინის წესების ერთობლიობა, არამედ სისტემა: სეგმენტი, მკაცრი იდენტურობა და საიდუმლოებები, დაცული მიწოდება, კონტროლირებადი კონტეინერები, დაკვირვება და ავტომატური რეაქცია. ამას დაამატეთ შემოწმება (აუდიტის არტეფაქტები, SBOM/ხელმოწერები, ჟურნალები), ხოლო პროდ-გარემო ხდება პროგნოზირებადი, კონტროლირებადი და მზად გარე შემოწმებისთვის - კომპრომისების გარეშე გამოშვების სიჩქარეზე და ბიზნეს SLO.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

Telegram
@Gamble_GC
ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.