Firewall პოლიტიკოსები და ACL

1) მიზნები და პრინციპები

• Least privilege: დაუშვას მხოლოდ საჭირო (აშკარა ალოუ, implicit deny).
• Segmentation: გარემოსდაცვითი იზოლაცია (stage/stage/dev), კრიტიკული კონტურები (PCI/KMS/DB).
• Egress კონტროლი: გამავალი ტრაფიკი შემოიფარგლება მხოლოდ FQDN/IP და პირადი endpoint 'ami სიებით.
• Identity aware (L7): გადაწყვეტილებები მიიღება ავთენტიფიცირებული არსით (SPIFFE/OIDC), და არა მხოლოდ IP- ით.
• Infrastructure as Code: წესები, როგორც კოდი, მიმოხილვა/CI/CD, ცვლილებების აუდიტი.

2) ტაქსონომია: სად და რა ფილტრაცია

2. 1 ფენა და მდგომარეობა

L3/L4 სახელმწიფო: კლასიკური ACL (CIDR, პროტოკოლი, პორტი).
L3/L4 stateful: უსაფრთხოების groups/NSG, აკონტროლებს ნაერთებს.
L7-aware: proxy/WAF/mesh RBAC (მეთოდები, გზები, JWT კლაიმები, SNI).
Inline vs out-of-band: Inline farerval ახდენს ტრაფიკს; out-of-band - ანალიზი/ალერტი.

2. 2 კონტურები

Perimeter: edge/WAF/Anti-DDoS.
Core: transit hub / меж-VPC/VNet.
Workload: SG/NSG на VM/ENI/POD.
App-level: Envoy/Istio/NGINX policy, service-to-service mTLS.

3) ღრუბლის მოდელები

AWS

Security Group (SG): stateful на ENI/instance/LB.
ქსელის ACL (NACL): ქვესახეობა, წესების რიგი, ორმხრივი ჩანაწერები.
AWS ქსელის Firewall/GWLB: L7 შემოწმება/IDS.
რეკომენდაცია: „SG არის მთავარი კონტროლი, NACL არის დიდი მარცვლეულის ღობე/დენის სია“.

Azure

NSG (stateful), ASG (tage ჯგუფები), Azure FW L7/IDS, პირადი Endpoints.
რეკომენდაცია: NSG Sabnet + NIC, სერვისების ჭდეები ASG- ის საშუალებით.

GCP

VPC Firewall Rules (stateful), Hierarchical FW (ორგანიზაციული/პაპა), Cloud Armor (L7), კერძო სამსახურის კავშირი.
რეკომენდაცია: org-level guardrails + დიზაინის ალოუ.

4) წესების დიზაინი: ნიმუშები

4. 1 ძირითადი ნაკრები

Deny all egress, ჩვენ ვუშვებთ FQDN/IP საშუალებით: პაკეტის საცავები, არტეფაქტური რეესტრი, მესამე მხარის API (პირადი/ფიქსირებული გასასვლელების საშუალებით).
East-West მინიმუმი: მომსახურება კომუნიკაციას უწევს მხოლოდ საჭირო დამოკიდებულებებს.
ადმინის დაშვება: bastion/JIT საშუალებით MFA- სთან ერთად, სესიების ჩანაწერი.

4. 2 ტეგი და ჯგუფები

გამოიყენეთ labels/tags ნაცვლად IP: 'env', 'service', 'tier', 'tenant', 'pci = true'.
პოლიტიკის განახლება ჭდის შეცვლისას - IP ბადეების ხელით რედაქტირების გარეშე.

4. 3 ცხოვრების ციკლი

Propose - Evaluate (staging) - Enforce (sh), dry-run/ჰიტების ლოგოებით.
შეფერხება: TTL/owner თითოეული წესისთვის, გამოუყენებელი მანქანის შემოწმება.

5) Kubernetes და mesh

5. 1 NetworkPolicy (L3/L4)

მინიმუმი არის „აკრძალვა ყველაფერი, გარდა საჭირო“.

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: core }
spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
kind: NetworkPolicy metadata: { name: api-egress }
spec:
podSelector: { matchLabels: { app: api } }
egress:
- to:
- namespaceSelector: { matchLabels: { ns: db } }
ports: [{ protocol: TCP, port: 5432 }]
- to:
- ipBlock: { cidr: 10. 100. 0. 0/16 } # Private endpoints ports: [{ protocol: TCP, port: 443 }]

5. 2 L7 RBAC в mesh (Istio/Envoy)

mTLS + საავტორო უფლებები JWT/claims/scopes/paths.

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: api-rbac }
spec:
selector: { matchLabels: { app: api } }
rules:
- from:
- source:
principals: ["spiffe://svc. payments"]
to:
- operation: { methods: ["POST"], paths: ["/v1/payouts"] }
when:
- key: request. headers[x-tenant]
values: ["eu-1","eu-2"]

6) Egress კონტროლი და პირადი პერიმეტრები

უპირატესობა მიანიჭეთ PrivateLink/კერძო სერვისის კავშირს PaaS/რეესტრებში/საცავებში.
დანარჩენი egress NAT/მარიონეტული allowlist FQDN- ით და ფიქსირებული IP (მესამე მხარის allowlist- ისთვის).
დაბლოკეთ პოდიუმების/VM ინტერნეტით პირდაპირ გასასვლელი; გამონაკლისი მხოლოდ egress კარიბჭის საშუალებით.

7) DNS და SNI ცნობიერი წესები

Split-horizon: შიდა ზონები არ იშლება გარეთ.
FW/Proxy FQDN/SNI მხარდაჭერით HTTPS (SNI allow).
დააფიქსირეთ pinning კონკრეტული მომწოდებლების დომენებისთვის; დააკვირდით მათ IP- ს ცვლილებებს.

8) ლოგი, აუდიტი, დაკვირვება

ჩართეთ flow logs (VPC/VNet/NSG/NACL), გაგზავნეთ SIEM.
დაუკავშირდით პროგრამებს 'trace _ id' ლოგოებში.
მეტრიკა: hit/miss წესები, top-talkers, drop-rates, ტრაფიკის ასიმეტრია, „egress გაჟონვა“.
მოხსენებები: „გამოუყენებელი წესები“, „ფართო ნებართვები“.

9) მენეჯმენტი, როგორც კოდი (IaC) და შემოწმება

Terraform/CloudFormation + მოდულარული პოლიტიკოსები შაბლონების მიხედვით.
პოლიტიკა as Code (OPA/Gatekeeper/Conftest): აკრძალვა '0. 0. 0. 0/0 ', მოთხოვნა' description/owner/ttl ', შერევის აკრძალვა/dev.
CI: ლინტი, სტატანალიზი, მიღწევის სიმულატორები (reachability analyzer), სანახავი გეგმა, სავალდებულო პერის მიმოხილვა.

10) მიღწევის და ქაოსის ტესტირება

სინთეტიკური ტესტები სხვადასხვა ქვესახეობიდან/AZ/რეგიონებიდან: TCP/443, სპეციფიკური BD/ბროკერების პორტები.
DR ტრეკების შესამოწმებლად: retries/circuit/fallback უნდა მუშაობდეს დამოკიდებულების გამორთვა.
MTU/MSS: დარწმუნდით, რომ არ არის ფრაგმენტაცია პერიმეტრებზე (განსაკუთრებით IPsec/NAT-T).

11) პროდუქტიულობა და საიმედოობა

მოერიდეთ ცენტრალიზებულ ვიწრო ადგილს: ჰორიზონტალურად მასშტაბური inline-FW (GWLB/scale sets).
ECMP/AS-path/BGP ჰაბებს შორის განაწილებისთვის.
TLS შემოწმების პროფილები: ჩართეთ წერტილოვანი (ძვირი), შეინახეთ გასაღების ანაბეჭდები ცალკე, დააკვირდით შესაბამისობას.

12) ჩამორთმევის მაგალითები (შემცირებული რეფერენდუმები)

12. 1 AWS SG: API → Postgres + S3 PrivateLink

hcl resource "aws_security_group" "api" {
name    = "sg-api"
description = "Ingress from ALB, egress to DB and PrivateLink"
vpc_id   = var. vpc_id

ingress { from_port=8080 to_port=8080 protocol="tcp" security_groups=[aws_security_group. alb. id] }
egress { from_port=5432 to_port=5432 protocol="tcp" security_groups=[aws_security_group. db. id] }
egress { from_port=443 to_port=443 protocol="tcp" prefix_list_ids=[aws_vpc_endpoint. s3. prefix_list_id] }
tags = { owner="team-api", env=var. env, ttl="2026-01-01" }
}

12. 2 Azure NSG: deny-by-default + allow bastion

bash az network nsg rule create -g rg -n allow-bastion --nsg-name nsg-app \
--priority 100 --direction Inbound --access Allow --protocol Tcp \
--source-address-prefixes 10. 0. 0. 10 --source-port-ranges "" \
--destination-port-ranges 22 --destination-address-prefixes 10. 1. 0. 0/16

12. 3 GCP hierarchical firewall: org-guardrail

yaml direction: INGRESS priority: 1000 action: deny enableLogging: true match:
layer4Configs: [{ ipProtocol: "all" }]
srcIpRanges: ["0. 0. 0. 0/0"]
targetResources: ["organizations/123456"]

12. 4 Envoy RBAC (L7 allow)

yaml
- name: envoy. filters. http. rbac typed_config:
rules:
action: ALLOW policies:
payments-post:
permissions: [{ url_path: { path: "/v1/payouts", ignore_case: true } }]
principals: [{ authenticated: { principal_name: { exact: "spiffe://svc. payments" } } }]

13) ანტიპატერები

`0. 0. 0. 0/0 'ingress/egress „დროებით“ სამუდამოდ რჩება.
„ფიფქები“ (სახელმძღვანელო რედაქტირება კონსოლში) კოდისა და აუდიტის გარეშე.
ზოგადი SG/NSG stage/stage/dev; კრიტიკული და არაკრიტიკული ქვესახეების ნაზავი.
egress კონტროლისა და პირადი endpoint- ის არარსებობა - გასაღების/საიდუმლოებების გაჟონვა გარეთ.
DNS/SNI- ის უგულებელყოფა: IP მიმწოდებლის უფლება მისცეს - ხვალ იგი შეიცვალა და გაიხსნა მთელი დიაპაზონი.
flow logs და runbook's flow შეუძლებელია.

14) iGaming/ფინანსების სპეციფიკა (PCI/მარეგულირებელი)

PCI CDE ცალკე VRF/სეგმენტში, ინტერნეტი არ არის; PSP/ლოგებზე წვდომა - პირადი კავშირის/მარიონეტული საშუალებით mTLS და HMAC.
მონაცემთა აღდგენა: PII/გადახდის მოვლენები - ქვეყნის შიგნით/რეგიონში; ინტერრეგიონალურად - მხოლოდ დანაყოფები/ანონიმი.
KMS/Vault/HSM: ინდივიდუალური ქვესათაურები/SG, მხოლოდ mTLS კლიენტები მოკლე სერთიფიკატებით.
WORM აუდიტი: FW/flow ლოგოები უცვლელი საცავში (Obect Lock), მარეგულირებელი მინიმუმის ჭრა.
პარტნიორები (PSP/KYC): FQDN allowlist, სტატიკური egress IP, SLA პროვაიდერების მონიტორინგი.

15) მზადყოფნის სიის სია

• სეგმენტის ერთიანი მოდელი (hub-and-spoke, VRF), CIDR კვეთა გარეშე.
• Deny-by-default на egress; პირადი endpoints PaaS/შენახვის ობიექტებისთვის.
• SG/NSG stateful for workload, NACL/route filters - ქვესახეობებზე/ჰაბებზე.
• K8s: NetworkPolicy «deny-all», mesh mTLS + L7 RBAC.
• tegi/ჯგუფები IP- ის ნაცვლად; owner/TTL/description თითოეული წესისთვის.
• IaC + Policy-as-Code; CI მიღწევის სიმულაციით; სავალდებულო მიმოხილვა.
• Flow logs შედის; dashboards top-talkers, drop-rates; ალერტები „გაჟონვისთვის“.
• Bastion/JIT Admin წვდომისთვის; MFA; სესიების ჟურნალები.
• Runbook "და: როგორ დაამატოთ/ამოიღეთ წესი, თუ როგორ უნდა იმუშაოთ ინციდენტში; „მკვდარი“ წესების რეგულარული გადასინჯვა.
• PCI/ფინანსებისთვის: CDE იზოლაცია, WORM აუდიტი, FQDN-allow PSP/KYC, სტატიკური egress IP.

16) TL; DR

ააშენეთ თავდაცვა ფენების მიხედვით: SG/NSG stateful worcloads, NACL/route filters ქვესახეობებზე, L7 RBAC mesh/promotions, WAF/edge პერიმეტრბოლაზე. სტანდარტულად - deny-by-default, egress მხოლოდ კონტროლირებადი წერტილების ან პირადი endpoints- ის საშუალებით. აღწერეთ წესები, როგორც კოდი, შეამოწმეთ ისინი პოლიტიკოსების და მიღწევის სიმულატორების მიერ, შეაგროვეთ flow-logs. IGaming/ფინანსებისთვის დაამატეთ PCI სეგმენტი, WORM აუდიტი და მკაცრი FQDN-allow PSP/KYC.