Puncte finale private și intranete

1) De ce o rețea privată

• izolarea PaaS/DB/depozitelor de PI publice;
• Respectarea mai ușoară (PCI DSS/GDPR)
• întârzieri previzibile și rutare.

2) Model de bază: VPC/VNet și hub-uri

Spaţiu adresă: un singur plan CIDR, fără intersecţii (de exemplu, '10. 0. 0. 0/12 'este tăiat în medii și hub-uri).
Segmentare: subrețele „ingress',” app „,” data „,” ops', „partajate” cu rute individuale/ACL/SG.
Nod de tranzit: VPC/VNet central cu gateway-uri (VPN/DirectConnect/ExpressRoute/Interconnect), inter-VPC peering/Transit Gateway și firewall-uri de rețea.
Dual-stack: programarea IPv6 în avans (salvează NAT, îmbunătățește scala de adrese).

3) Puncte finale private: principii

• Traficul merge în interiorul rețelei de furnizori (nu prin Internet).
• Limitele politicii Endpoint unde puteți merge (prefixe/ARN/resurse).
• DNS este redefinit la IP privat (a se vedea § 6).

Obiective tipice: magazine de obiecte (S3/GCS/Blob), secret/KMS, cozi, autobuze de evenimente, baze de date gestionate, servicii analitice, registre artefact.

4) Intrarea și echilibrarea în interior

Intern Load Balancer (ILB) pentru L4/7, vedem numai de la subrețele private.

• "Service 'de tip" LoadBalancer "cu adnotări interne.
• Conectați-vă prin Internal Ingress (Nginx/Contour/Gateway API) la o adresă privată.
• API Gateway (privat): integrare privată cu backend; în afara - numai prin margine, dacă este necesar.

Exemplu: K8s Ingress ca interior

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) Contur de ieșire: „implicit - nega”

• NAT Gateway (pentru actualizări/depozite) + lista de permisiuni de ieșire prin FQDN/IP;
• inspecție TLS/proxy în cazul în care politicile necesită control;
• Puncte finale private pentru PaaS/registre în loc de NAT.
• SG/NACL: permisiuni explicite per serviciu, „est-vest” - minim.
• Politicile K8s de ieșire (CNI/OPA Gatekeeper/Calico NetworkPolicy) - restricții IP externe, permisiuni cluster/endpoint.

6) DNS: split-orizont и zone private

Zone interioare separate ('.internal. corp ") și public.
Zone private DNS pentru serviciile furnizorilor: suprascrie numele publice (de exemplu, "găleată. s3. regiune. amazonaws. com ') înregistrărilor private A/AAAA.
Forwarders/DNS condiționat между on-prem ↔ nor.
Format nume: incapsulare mediu/regiune ('api. eu1. intern. corp "), evita PII.

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

7) Modele de interconectare

Peering (VPC↔VPC/VNet↔VNet): simplu și rapid; tranzitul nu este întotdeauna acceptat → utilizarea Transit Gateway/Virtual WAN/Cloud Router pentru hub-and-speaked.
On-prem ⇄ cloud: VPN IPsec pentru pornire, apoi linie închiriată (DC/ER/IC) cu BGP și backup (doi furnizori, puncte de intrare diferite).
VRF/Segmentarea domeniului de traseu: izolarea perimetrului prod/stage/dev și a cardului.

8) Zero încredere și autentificare internă

mTLS-default (service mesh: Istio/Linkerd/Consul), identitatea mașinii: SPIFFE/SPIRE.
Politicile L7: autorizarea de către JWT/revendicări/scopuri, restricționarea rutelor/metodelor la nivelul proxy.
Secrete: HashiCorp Vault/КMS + Operator de secrete externe; acreditare de scurtă durată (STS).
Bastion/Acces privilegiat: acces la privatka numai printr-o sesiune de broker/JIT (MFA, înregistrare comandă).

Exemplu: Filtru Envoy mTLS + JWT-authz (fragment)

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) Date și PaaS în interiorul privat

Baze de date/clustere: numai adrese private; panou admin prin bastion/JIT.
Depozite: acces de la VPC prin punct final privat; politica endpoint permite numai gălețile/containerele dorite.
Cozi/autobuze: interfețe private; producători/consumatori - în același VPC/peering.
Registre artefact: acces privat de la alergători CI/CD pe subrețele private.

10) Observabilitate în rețelele private

OpenTelemetry Collector - ca un gateway de telemetrie: exportatorii interni la auto-găzduit (Prometheus/Tempo/Loki/ClickHouse) sau pentru a gestiona backends prin puncte finale private.
Sunt necesare jurnale de flux/NSG/NACL și analizor de accesibilitate.
SLO-felii: 'site/regiune/vpc/subnet', alerte de ieșire și o neașteptată „direcție de Internet”.

11) Testarea și verificarea

Politica ca cod (OPA/Gatekeeper) pentru regulile de rețea/Ingress/Service.
Rute canare: domenii de testare în DNS privat, controale sintetice din diferite subrețele/AZ/regiuni.
Rețeaua de haos: întârzieri/pierderi în ceea ce privește controalele inter-VPC/inter-AZ (netem/Toxiproxy), controalele temporale și politicile de reincercare.

12) Exemple de configurare

12. 1 Terraform: etichete și rute (idee)

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: negați totul, cu excepția a ceea ce aveți nevoie

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 (schema internă) + HSTS

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

13) Antipattern

„gestionare-Internet” comună de la subrețele private; lipsa controlului ieşirii.
Split-brain DNS și manual aleatoriu '/etc/hosts'.
Intersectarea CIDRs și „NAT cuiburi păpuși”.
Puncte finale publice pentru baze de date/depozite „de dragul comodității”.
Nu există jurnale de flux/audituri de regulă; „deschis” SG '0. 0. 0. 0/0`.
Chei de acces statice cu durată lungă de viață în cod/CI.

14) Costul și performanța

Punctele finale private sunt adesea mai ieftine decât ieșirea permanentă NAT și mai sigure.
Programați clustere NAT/az-local pentru lățimea de bandă pentru a evita crearea blocajului.
Cache/edge și SWR reduc traficul transregional.
Alegerea protocoalelor: HTTP/2/gRPC în interiorul → există mai puține conexiuni și TLS deasupra capului.

15) Specificul iGaming/Finanțe

PCI DSS: circuit de card (CDE) într-o rețea separată/VRF, fără internet; accesul la jurnalele magazinului/PSP numai prin puncte finale private; audituri imuabile (WORM/Object Lock).
KMS/Vault: chei segmentate pe regiune/brand; operațiuni de semnare (HSM) sunt disponibile numai de la CDE peste mTLS.
PSP/KYC: dacă există conectivitate/piețe private - utilizare; în caz contrar, ieșirea printr-un proxy de încredere cu HMAC/mTLS și lista de permisiune explicită.
Multi-chirie: etichete și politici de „chiriaș ”/„ brand”; nume DNS private separate și straturi SG.

16) Lista de verificare Prod Readiness

• Planul CIDR fără intersecții; dual-stack gata (IPv6).
• Hub-and-Spoked, Tranzit, peering; on-prem ⇄ cloud - BGP, perechi de link-uri de rezervă.
• Toate PaaS/storages/DB - prin intermediul punctelor finale private + politicile endpoint.
• Interior LB/Ingress; perimetrul public - numai pe marginea/WAF.
• Split-horizon DNS, zonele private și redirecționarea condiționată sunt configurate.
• Ieșirea este „nega” în mod implicit; NAT/proxy-urile sunt restricționate și înregistrate.
• Mesh mTLS + SPIFFE; JWT-authz pe L7; Seif/ESO, scurte secrete.
• NetworkPolicy/SG/NACL - „minim necesar”, jurnale de curgere și analiza accesibilității.
• OTel Collector în interior; alerte de ieșire, SLO prin "site/regiune/vpc'.
• PCI/audit: jurnale WORM, KMS/HSM, izolarea CDE, acces runbook.

17) TL; DR

Construiți o rețea hub-and-speaked cu un plan CIDR clar, utilizați puncte finale private pentru fiecare PaaS/stocare/bază de date și traficul către exterior numai prin punctele de ieșire gestionate. Interior - intern LB/Ingress, mTLS + SPIFFE, split-horizon DNS, strict NetworkPolicy/SG și telemetrie prin OTel. Pentru iGaming/Finance, adăugați segmentarea PCI, KMS/Vault și auditarea imuabilă; Ieșire PSP/KYC prin canale private sau un proxy bine controlat.