პირადი endpoints და შიდა ქსელები

1) რატომ არის პირადი ქსელი

• PaaS/DB/საცავის იზოლაცია საჯარო IP- დან;
• შესაბამისობის გამარტივება (PCI DSS/GDPR);
• პროგნოზირებადი შეფერხებები და მარშრუტიზაცია.

2) ძირითადი მოდელი: VPC/VNet და კერა

მისამართის სივრცე: ერთი CIDR გეგმა, კვეთა გარეშე (მაგალითად, '10. 0. 0. 0/12 'დაჭრილი გარემოთი და კერა).
სეგმენტი: ქვესადგურები 'ingress', 'app', 'data', 'ops', 'shared' ცალკეული მარშრუტებით/ACL/SG.
სატრანზიტო კერა: ცენტრალური VPC/VNet საკეტებით (VPN/DirectConnect/ExpressRoute/Interconnect), VPC peering/Transit Gateway და ქსელის ფაილები.
ორმაგი შეტევა: IPv6 დაგეგმვა წინასწარ (დაზოგავს NAT, აუმჯობესებს მისამართების მასშტაბს).

3) პირადი endpoints: პრინციპები

• ტრეფიკი გადის პროვაიდერის ქსელში (არა ინტერნეტით).
• Endpoint policy ზღუდავს სად შეგიძლიათ წასვლა (პრეფიქსი/ARN/რესურსები).
• DNS განისაზღვრება პირადი IP (იხ. § 6).

ტიპიური მიზნები: ობიექტის ნაკადები (S3/GCS/Blob), საიდუმლო/KMS, რიგები, ღონისძიების ავტობუსები, კონტროლირებადი DD, ანალიტიკური სერვისები, არტეფაქტური რეესტრები.

4) შიგნით შესვლა და დაბალანსება

Internal Load Balancer (ILB) L4/7 - ისთვის, ჩვენ მხოლოდ კერძო ქვესათაურებისგან ვხედავთ.

• 'Service' ტიპის 'LoadBalancer "ინტერტონალური ვიდეოჩანაწერებით.
• შესასვლელი Internal Ingress (Nginx/Contour/Gateway API) კერძო მისამართზე.
• API Gateway (პირადი): კერძო ინტეგრაცია ზურგჩანთებზე; გარეთ - მხოლოდ edge მეშვეობით, საჭიროების შემთხვევაში.

მაგალითი: K8s Ingress, როგორც შიდა

yaml apiVersion: networking. k8s. io/v1 kind: Ingress metadata:
name: api-internal annotations:
kubernetes. io/ingress. class: "nginx"
alb. ingress. kubernetes. io/scheme: internal # or provider equivalent spec:
rules:
- host: api. internal. corp http:
paths:
- path: /v1/
pathType: Prefix backend:
service:
name: api port: { number: 8080 }

5) Egress კონტური: „ნაგულისხმევი - დენი“

• NAT Gateway (apdates/საცავებისთვის) + egress allowlist FQDN/IP;
• TLS შემოწმება/მარიონეტული, თუ პოლიტიკოსები საჭიროებენ კონტროლს;
• პირადი endpoints PaaS/რეგისტრაციისთვის NAT- ის ნაცვლად.
• SG/NACL: პერ სერვისის აშკარა ნებართვები, „აღმოსავლეთ-დასავლეთისკენ“ - მინიმალური.
• K8s Egress პოლიტიკა (CNI/OPA Gatekeeper/Calico NetworkPolicy) - გარე IP აკრძალვა, მტევანი/endpoints ნებართვები.

6) DNS: split-horizon и private zones

გამოყავით შიდა ზონები ('. internal. corp ') და საჯარო.
Private DNzones პროვაიდერის სერვისებისთვის: ასახავს საზოგადოებრივ სახელებს (მაგალითად, 'bucket. s3. region. amazonaws. com ') პირადი A/AAAA ჩანაწერებისთვის.
Forwarders/Conditional DNS между on-prem ↔ cloud.
სახელების ფორმატი: დააკომპლექტეთ გარემო/რეგიონი ('app. eu1. internal. corp '), თავიდან აიცილეთ PII.

api. internal. corp. A  10. 20. 30. 40 s3. bucket. corp. A  10. 100. 0. 25 # via private endpoint

7) ოფშორული კავშირების ნიმუშები

Peering (VPC, VPC/VNet): მარტივი და სწრაფი; ტრანზიტი ყოველთვის არ არის მხარდაჭერილი - გამოიყენეთ Transit Gateway/ვირტუალური WAN/Cloud Router ვარსკვლავისთვის (hub-and-spoke).
On-prem-cloud: IPsec VPN დაწყებისთვის, შემდეგ გამოყოფილი ხაზი (DC/ER/IC) BGP და რეზერვით (ორი პროვაიდერი, სხვადასხვა შესასვლელი წერტილები).
VRF/Route-domain სეგმენტი: იზოლაცია/stage/dev და კარტის პერიმეტრი.

8) Zero Trust და შიდა ავთენტიფიკაცია

mTLS ნაგულისხმევი (სერვისი: Istio/Linkerd/Consul), მანქანების თვითმყოფადობა: SPIFFE/SPIRE.
L7 პოლიტიკოსები: საავტორო უფლებები JWT/claims/scopes, მარშრუტების/მეთოდების შეზღუდვა მარიონეტულ დონეზე.
Secrets: HashiCorp Vault/КMS + External Secrets Operator; მოკლე credenchels (STS).
Bastion/კერძო წვდომა: კერძო პირზე წვდომა მხოლოდ ბროკერის/JIT სესიის საშუალებით (MFA, ბრძანებების ჩანაწერი).

მაგალითი: Envoy ფილტრი mTLS + JWT-authz (ფრაგმენტი)

yaml transport_socket:
name: tls typed_config: {... spiffe://svc. api... }
http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
oidc: { issuer: https://idp. corp, audiences: ["api"], remote_jwks: {...} }
rules: [{ match: { prefix: "/v1" }, requires: { provider_name: oidc } }]

9) მონაცემები და PaaS კონფიგურაციის შიგნით

ბაზები/მტევანი: მხოლოდ პირადი მისამართები; Admink bastion/JIT.
შენახვა: VPC- დან წვდომა კერძო endpoint- ზე; endpoint პოლიტიკა საშუალებას აძლევს მხოლოდ საჭირო ტანკები/კონტეინერები.
რიგები/საბურავები: პირადი ინტერფეისები; მწარმოებლები/კონსუტერები - იმავე VPC/peering.
არტეფაქტების რეესტრები: პირადი წვდომა CI/CD runners- დან კერძო ქვესათაურებში.

10) კერძო ქსელებში დაკვირვება

OpenTelemetry Collector - როგორც ტელემეტრიული კარიბჭე: შინაგანი ექსპორტიორები self-hosted (Prometheus/Tempo/Loki/ClickHouse) ან კერძო ობიექტების მართვადი ბუკენდებში.
Flow logs/NSG/NACL ლოგები და რეაქციის ანალიზები სავალდებულოა.
SLO სექციები: 'site/region/vpc/subnet ", ალერტები egress გაჟონვისთვის და მოულოდნელი" ინტერნეტ მიმართულება ".

11) ტესტირება და გადამოწმება

პოლიტიკა არის კოდი (OPA/Gatekeeper) ქსელის წესებისთვის/Ingress/Service.
კანარის მარშრუტები: სატესტო დომენები კერძო DNS- ში, სინთეზური შემოწმებები სხვადასხვა ქვესახეობიდან/AZ/რეგიონებიდან.
Chaos ქსელი: შეფერხებები/ზარალი VPC/VTC-AZ (netem/Toxiproxy), ტაიმაუტების შემოწმება და retry პოლიტიკოსი.

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

12. 1 Terraform: ნიშნები და მარშრუტები (იდეა)

hcl resource "aws_route_table" "app" {
vpc_id = aws_vpc. core. id tags = { Name = "rt-app", env = var. env, zone = "private" }
}
Route on PrivateLink endpoint (interface endpoint is created separately)
resource "aws_vpc_endpoint_route_table_association" "s3" {
route_table_id = aws_route_table. app. id vpc_endpoint_id = aws_vpc_endpoint. s3. id
}

12. 2 K8s NetworkPolicy: აკრძალვა ყველაფერი, გარდა საჭირო

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

12. 3 Nginx Ingress (internal scheme) + HSTS

yaml metadata:
annotations:
alb. ingress. kubernetes. io/scheme: internal nginx. ingress. kubernetes. io/hsts: "true"

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

ზოგადი „მენეჯმენტის ინტერნეტი“ პირადი ქვესათაურებიდან; egress კონტროლის არარსებობა.
Split-brain DNS და შემთხვევითი სახელმძღვანელო '/etc/hosts '.
კვეთა CIDR და „NAT მატრიოშკა“.
საზოგადოებრივი endpoint's BD/საცავი „მოხერხებულობისთვის“.
ნაკადების/აუდიტის წესების ნაკლებობა; „ღია“ SG '0. 0. 0. 0/0`.
გრძელი სტატიკური კოდის გასაღებები/CI.

14) ღირებულება და შესრულება

Private endpoints ხშირად იაფია, ვიდრე მუდმივი NAT egress და უსაფრთხო.
დაგეგმეთ NAT მტევანი/az-local გამტარუნარიანობისთვის, რათა არ შექმნათ bottleneck.
ქეში/edge და SWR ამცირებენ ჯვარედინი რეგიონალური ტრაფიკს.
პროტოკოლების არჩევანი: HTTP/2/gRPC შიგნით ნაკლებია ნაერთები და TLS overhaed.

15) iGaming/ფინანსების სპეციფიკა

PCI DSS: ბარათების წრე (CDE) ცალკეულ ქსელში/VRF, არა ინტერნეტი; ნაკადის წვდომა/PSP ლოგოები მხოლოდ კერძო endpoints- ით; უცვლელი აუდიტი (WORM/Object Lock).
KMS/Vault: გასაღებები სეგმენტირებულია პერის რეგიონში/ბრენდზე; ხელმოწერის ოპერაციები (HSM) ხელმისაწვდომია მხოლოდ CDE- დან mTLS- ზე.
PSP/KYC: თუ არსებობს პირადი კავშირი/ბაზრები - გამოიყენეთ; წინააღმდეგ შემთხვევაში - egress სანდო მარიონეტული საშუალებით HMAC/mTLS და აშკარა allowlist.
მრავალ ტენდენცია: ჭდეები და პოლიტიკოსები 'tenant '/' brand'; ინდივიდუალური პირადი DNS სახელები და SG ფენები.

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

• CIDR გეგმა კვეთა გარეშე; ორმაგი შეტევა მზად არის (IPv6).
• Hub-and-Spoke, Transit, peering; on-prem-cloud - BGP, სარეზერვო საბრძოლო წყვილი.
• ყველა PaaS/საცავი/BD - კერძო endpoints + endpoint policies- ის საშუალებით.
• Internal LB/Ingress; საჯარო პერიმეტრი - მხოლოდ edge/WAF.
• Split-horizon DNS, პირადი ზონები და conditional-forwarding მორგებულია.
• ნაგულისხმევი „დენი“; NAT/მარიონეტული შეზღუდულია და ჟღერს.
• Mesh mTLS + SPIFFE; JWT-authz L7- ზე; Vault/ESO, მოკლე საიდუმლოებები.
• ქსელის პოლიტიკა/SG/NACL - „მინიმალური საჭირო“, flow-logs და reachability ანალიზი.
• OTel Collector შიგნით; ალერტები გაჟონვისთვის, SLO 'site/region/vpc'.
• PCI/აუდიტი: WORM ჟურნალები, KMS/HSM, CDE იზოლაცია, runbook წვდომა.

17) TL; DR

ააშენეთ ქსელი hub-and-spoke სქემის მიხედვით, მკაფიო CIDR გეგმით, გამოიყენეთ პირადი endpoints თითოეული PaaS/შენახვის/BD- ისთვის, ხოლო გარედან ტრაფიკი მხოლოდ კონტროლირებადი egress წერტილების საშუალებით. შიგნით - Internal LB/Ingress, mTLS + SPIFFE, split-horizon DNS, მკაცრი ქსელის პოლიტიკა/SG და ტელემეტრია OTel- ის საშუალებით. IGaming/ფინანსებისთვის დაამატეთ PCI სეგმენტი, KMS/Vault და უცვლელი აუდიტი; PSP/KYC ამოიღეთ პირადი არხებით ან მკაცრად კონტროლირებადი მარიონეტებით.