უსაფრთხოების ფენები ინფრასტრუქტურაში
(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)
მოკლე რეზიუმე
უსაფრთხოება არის ფენების სისტემა: თითოეული ფენა იკავებს და აღმოაჩენს შეტევებს, თუ წინა ვერ მოხერხდა. IGaming- ისთვის ეს განსაკუთრებით კრიტიკულია: გადახდის ნაკადები, PII, პარტნიორობა და პიკის დატვირთვა. ქვემოთ მოცემულია თავდაცვის ჩარჩო, რომელიც აკავშირებს ქსელს, იდენტურობას, პროგრამებს, მონაცემებსა და ოპერაციულ პროცესებს ერთ კონტროლირებად პროგრამაში.
1) მუქარის მოდელი და ძირითადი პრინციპები
Threat Modeling: STRIDE/kill chain საკვანძო ნაკადებისთვის (ლოგინი, ანაბარი, განაკვეთი, დასკვნა, ბეკოფისი).
Zero Trust: „არ ენდოთ ნაგულისხმევი“, მინიმალური უფლებები, შემოწმება თითოეულ ჰოპზე.
Least Privilege & Segregation of Duties: როლები ატომურია, მგრძნობიარე ოპერაციები იყოფა.
Secure by Default: დახურული პორტები, დენის ყველა პოლიტიკა, უსაფრთხო ნაგულისხმევი.
Auditability: ყველა წვდომა/ცვლილება - ცენტრალიზებულ აუდიტში.
2) ქსელი და პერიმეტრი
მიზანი: გვერდითი მოძრაობის თავიდან აცილება და რისკის იზოლირება.
სეგმენტი/ზონები: Edge (CDN/WAF) - API - მონაცემთა სერვისები (DB/KMS) - admin/becophis.
VPC/VNet იზოლაცია + ქვესახეები საჯარო/კერძო მომსახურებისთვის; NAT/egress კონტროლი (მათ შორის egress-allowlist PSP/თამაშების პროვაიდერების ჩათვლით).
mTLS ყველგან (mesh/Ingress), TLS 1. 2 +/HSTS/მკაფიო კრიპტოვალუტა.
WAF/bot მენეჯმენტი/DDoS პერიმეტრზე; credential stuffing.
DNS უსაფრთხოება: split-horizon, DNSSEC, უარყოფითი წინააღმდეგობა, ქეში-პინინგი კრიტიკულ დომენებზე.
yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: { name: api-deny-all, namespace: prod }
spec:
podSelector: { matchLabels: { app: api } }
policyTypes: [Ingress, Egress]
ingress: [] # deny-all egress:
- to:
- namespaceSelector: { matchLabels: { name: prod } }
podSelector: { matchLabels: { app: payments } }
ports: [{ protocol: TCP, port: 8080 }]
3) პირადობა და წვდომა (IAM/PAM)
მიზანი: თითოეული წვდომა გამართლებულია, შემოიფარგლება და გამჭვირვალედ შემოწმდება.
SSO + MFA ხალხისა და მანქანებისთვის; აპარატების გასაღებები პრივილეგირებული ანგარიშებისთვის.
RBAC/ABAC ღრუბლის/K8s/bacofis; SCIM - ავტომატური ჩართვა/გამორთვა.
JIT წვდომა (დროებითი), გაუმჯობესებული აუდიტით break glass.
Service Accounts მოკლე ტოქსებით (OIDC/JWT), კლიენტის საიდუმლოებების აუდიტი.
Bastion/ბრძანებების მარცვლეული: Prod-BD/კვანძებზე წვდომა - მხოლოდ bastion და სესიების საშუალებით.
4) საიდუმლოებები და გასაღებები
მიზანი: გაჟონვის გამორიცხვა და საკვანძო სასიცოცხლო ციკლის უზრუნველყოფა.
KMS/HSM (სამაგისტრო გასაღები), რეგულარული როტაცია; გასაღებების გამიჯვნა ზონებში/მიზნებზე.
საიდუმლო საცავი (Vault/Cloud KMS Secrets) დინამიური creds და Lease.
- At rest (DB/bankets/snaphots) envelope encryption.
- In transit (TLS/mTLS).
- გადახდის მონაცემების ტოკენიზაცია; PAN-safe ნაკადები და 3-დიუმიანი უსაფრთხოება (PCI DSS).
hcl path "kv/prod/payments/" {
capabilities = ["read","list"]
}
path "database/creds/readonly" {
capabilities = ["read"]
}
5) კონტეინერების უსაფრთხოება და კუბერნეტები
მიზანი: შეტევის ზედაპირის შემცირება rantime დონეზე.
სურათები: მინიმალური ძირითადი, შემდგენლების/შელის გარეშე; ხელმოწერები (კოდი) და SBOM.
ადმისიის კონტროლი (OPA/Gatekeeper/Kyverno): აკრძალვა ': latest', 'privileged', 'hostPath', 'root'.
Runtime-политики: Seccomp/AppArmor, `readOnlyRootFilesystem`, `drop ALL` capabilities + allow-list.
საიდუმლოებები, როგორც volume/env, საიდუმლოების მენეჯერისგან; სურათის გარეშე.
PodSecurity (или Pod Security Admission): enforce restricted.
რეგისტრატორები: პირადი, დაუცველობის შემოწმებით (SAST/DAST/CSA).
yaml apiVersion: constraints. gatekeeper. sh/v1beta1 kind: K8sAllowedRepos metadata: { name: only-internal-registry }
spec:
repos: ["registry. internal. local/"]
6) Supply-chain и CI/CD
მიზანი: ენდობა არტეფაქტებს კომიტიდან წარმოებამდე.
Branch-policies: კოდი-revies, დაცული ფილიალები, სავალდებულო შემოწმებები.
არტეფაქტებისა და პროვენციების ხელმოწერა (SLSA/COSIGN), უცვლელი ჭდეები (იმუნური გამოსახულებები).
SBOM (CycloneDX/SPDX), Dependabot/Renovate და pinning დამოკიდებულებები.
CI იზოლაცია: ეფემერული რანერები, საიდუმლოებები მხოლოდ დაცულ ჯობებში, no-plaintext.
CD კარიბჭეები: quality/SAST/ლიცენზია/მოვაჭრე პოლიტიკა; დაწინაურდა მხოლოდ GitOps- ის საშუალებით.
7) პროგრამის უსაფრთხოება (API/ვებ/მობილური)
მიზანი: ლოგიკური და ტექნიკური შეტევების თავიდან აცილება.
AuthN/AuthZ: OAuth2/OIDC/JWT; მოკლე TTL, კლავიშების როტაცია, აუდიტი/შემოწმება.
Input Security: სავალდებულო/ნორმალიზაცია, ინექციებისგან დაცვა, პარამეტრების შაბლონები.
CSP/HSTS/XFO/XSS დაცვა, მკაცრი CORS, დატვირთული MIME/ზომის შეზღუდვა.
Rate limit/= tas, idempotence-keys გადახდა/გადახდისთვის.
ფიჩეფლაგები: სწრაფი კილ-სვიტჩი საშიში ფუნქციებისთვის.
nginx add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:;" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
8) მონაცემები, PII და შესაბამისობა (მათ შორის PCI)
მიზანი: მინიმალური საფასური, მინიმალური დაშვება, მაქსიმალური გამჭვირვალობა.
Data-zones/классы: `public/internal/confidential/pii/pci`. ჭდეები შენახვის ობიექტებში და ლოგოებში.
PII- ის მინიმიზაცია: ფსევდონიზაცია 'player _ id', გადახდის დეტალების ტოქსიკაცია.
შენახვის პოლიტიკა: ცხელი/ცივი, WORM აუდიტისთვის; ავტომატური მოცილება TTL- ზე.
წვდომა: მხოლოდ შეთანხმებული როლებისა და ატრიბუტების საშუალებით (რეგიონი/მიზანი).
PCI სეგმენტი: იზოლირებული სეგმენტი, წვდომის ჟურნალები, რეგულარული სკანერები/ASV.
9) Edge ფენა: CDN/WAF/DDoS/bot დაცვა
მიზანი: „ნაგვის“ გადატანა პლატფორმის ბირთვზე.
CDN: გეო-ბლოკები, ქეშის სტრატეგიები, დაცვა layer-7.
WAF: ძირითადი ხელმოწერები + კასტომიური წესები API- სთვის (JSON სქემები, არასტანდარტული მეთოდების აკრძალვა).
ბოტები: ქცევითი ანალიტიკა, მოწყობილობა fingerprint, rate-limit/ქუდი ანომალიებში.
TLS/ALPN: გამორთეთ ძველი შიფრები, ჩართეთ OCSP stapling.
10) მონიტორინგი, ტელემეტრია და SecOps
მიზანი: შეტევების ნახვა და რეაგირება ინციდენტამდე.
დაკვირვება: მეტრიკა/ლოგები/ტრეისი 'trace _ id' და audit ველები.
SIEM/SOAR: მოვლენების კორელაცია (ავთენტიფიკაცია, IAM ცვლილებები, WAF მოქმედება, საიდუმლოებების დაშვება).
გამოვლენის წესები: აურზაური 401/403, როლის ესკალაცია, მასობრივი გადახდები, გეოს ანომალიები.
სკანირება: SAST/DAST/IAST, CSPM/KSPM, რეგულარული პენის ტესტები და ბარიერი.
ანტი-ფროიდი: გარიგების/ქცევის გაყალბება, velocity ფილტრები, სანქციების სიები.
11) საიმედოობა, რეზერვი და ბიზნეს კონკურენცია
მიზანი: გაუმართაობა მონაცემთა დაკარგვის გარეშე და SLA.
რეპლიკაცია და PITR BD- სთვის, ხშირი სლაიდები ტესტების აღდგენით.
DR გეგმა: RTO/RPO, რეგულირების სკრიპტები, გადართვის ტესტები.
საიდუმლოებები DR- ში: დამოუკიდებელი გასაღებები/KMS რეპლიკა, გადაუდებელი როტაციის პროცესი.
ოფიციალური ჰაიდები: თამაშის დღის აღდგენისა და წვრთნების შემოწმება.
12) ოპერაციული პროცესები და კულტურა
მიზანი: უსაფრთხოება „ნაგულისხმევი“ იყოს.
უსაფრთხოების PR: სავალდებულო უსაფრთხოების მიმოხილვა მგრძნობიარე ცვლილებებისთვის.
გამოშვების პოლიტიკოსები: ღამის/მწვერვალის ფანჯრები დახურულია; წინასწარი ფრენის ჩეკის ფურცლები.
Secure Runbooks: უსაფრთხო პარამეტრების ინსტრუქციები, მოქმედების აუდიტი.
ტრენინგი: ფიშინგ სიმულაციები, ინციდენტებზე ტრენინგი, „ცოცხალი“ tabletop სესიები.
13) საკონტროლო სიები (მოკლედ)
ქსელი და პერიმეტრი
- ყველა ინგრედიენტი WAF/CDN; DDoS ჩართულია
- mTLS სერვისებს შორის; deny all ქსელის პოლიტიკა
- Egress-allowlist გარე პროვაიდერების მიმართ
თვითმყოფადობა
- SSO+MFA; JIT და break glass აუდიტით
- RBAC/ABAC, თანამდებობიდან გათავისუფლების SCIM დეაქტივაცია
- სამსახურის ჩანაწერები მოკლე ნიშნით
K8s/კონტეინერები
- სურათების ხელმოწერები + SBOM; აკრძალვა 'latest'
- Seccomp/AppArmor, read-only FS, drop caps
- Gatekeeper/Kyverno პოლიტიკოსები და დენის სიები
საიდუმლოებები/გასაღებები
- Vault/KMS, როტაცია, გასაღებების გამიჯვნა
- დაშიფვრა at rest/in transit
- გადახდები
CI/CD и supply-chain
- ეფემერული ჭრილობები; საიდუმლოებები მხოლოდ დაცულ ჯობებში
- SAST/DAST/ლიცენზია; არტეფაქტების ხელმოწერები
- GitOps აქცია, ხარისხის კარიბჭეები
მონაცემები/PII/PCI
- მონაცემთა კლასიფიკაცია და შენახვის ჭდეები
- retention/WORM პოლიტიკოსები; როლებზე წვდომა
- PCI სეგმენტის იზოლაცია, ASV სკანერები
SecOps
- SIEM/SOAR წესები, ესკალაციის ალერტები
- Anti frode და velocity ფილტრები
- DR გეგმა, RTO/RPO ტესტები
14) „მკაცრი“ პოლიტიკოსის მაგალითები
Kyverno: პრივილეგირებული კონტეინერების აკრძალვა
yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata: { name: disallow-privileged }
spec:
rules:
- name: no-priv match: { resources: { kinds: ["Pod"] } }
validate:
message: "Privileged containers are not allowed"
pattern:
spec:
containers:
- securityContext:
privileged: "false"
OPA (Rego): აკრძალვა 'hostNetwork'
rego package kubernetes. admission
violation[msg] {
input. request. kind. kind == "Pod"
input. request. object. spec. hostNetwork == true msg:= "hostNetwork is not allowed"
}
15) ანტი შაბლონები
„ჩვენ ვიცავთ პერიმეტრს“ შიდა mTLS/სეგმენტაციის გარეშე - გვერდითი მოძრაობა.
საიდუმლოებები Env-ცვლადი CI- ში, გადმოტვირთვის ლოგოებში.
სურათები „: latest“, ხელმოწერების ნაკლებობა და SBOM.
Allow-all პოლიტიკა კლასტერში; საერთო ნეიმსპასი ყველაფრისთვის.
დაშიფვრა „ქაღალდზე“ გასაღებების და აღდგენის ტესტების რეალური როტაციის გარეშე.
დაეყრდნოს WAF- ს ლოგიკის კორექტირების ნაცვლად და მონაცემების შესაბამისობა.
არ არსებობს DR/ფირფიტის სცენარების წვრთნები - გეგმა „მტვერი“.
16) როგორ დავიწყოთ (გეგმა 90 დღის განმავლობაში)
1. კვირა 1-2: ასეტების/მონაცემების ინვენტარიზაცია, კლასიფიკაცია, ნაკადის რუკა.
2. კვირა 3-4: ჩართეთ mTLS/deny all ქსელის პოლიტიკა, WAF/DDoS/bot ფილტრები.
3. კვირა 5-6: Vault/KMS, გასაღების როტაცია, გადახდის ტოქსიკაცია.
4. კვირა 7-8: Gatekeeper/Kyverno, Seccomp/AppArmor, აკრძალვები 'privileged '/' hostPath'.
5. კვირა 9-10: სურათების ხელმოწერები, SBOM, კარიბჭეები CI/CD, GitOps პოპულარიზაცია.
6. კვირა 11-12: SIEM/SOAR წესები, ესკალაციის ალერტები, ანტი-ფროიდი.
7. კვირა 13: DR სწავლება, რუნაბუკების განახლება და შესაბამისობის სტატუსი (PII/PCI).
შედეგები
უსაფრთხოების ფენები არის გადაწყვეტილებების არქიტექტურა და არა „შეცდომების“ ერთობლიობა. დააკავშირეთ ქსელის სეგმენტი და Zero Trust, მკაცრი IAM, უსაფრთხო კონტეინერები/K8s, კონტროლირებადი საიდუმლოებები და კრიპტო, დაცული დანართები, edge თავდაცვა და SecOps დაკვირვება. შემდეგ, შეტევებისა და ჩავარდნების დროსაც კი, პლატფორმა შეინარჩუნებს მონაცემთა მთლიანობას, PII/PCI კონფიდენციალურობას და საკვანძო ნაკადების ხელმისაწვდომობას - დეპოზიტებს, განაკვეთებსა და დასკვნებს - ნებისმიერ პიკის საათებში.