Prywatne punkty końcowe i intranety

1) Dlaczego sieć prywatna

• odizolowanie PaaS/DB/magazynów od publicznego IP;
• Łatwiejsza zgodność (PCI DSS/RODO)
• przewidywalne opóźnienia i routing.

2) Model podstawowy: VPC/VNet i piasty

Przestrzeń adresowa: jeden plan CIDR, bez skrzyżowań (na przykład, '10. 0. 0. 0/12 "jest pocięte na środowisko i piasty).
Segmentacja: podsieci "ingress", "app", "data", "ops'," shared "z poszczególnymi trasami/ACL/SG.
Centrum tranzytowe: centralny VPC/VNet z bramami (VPN/DirectConnect/ViaRoute/Interconnect), międzyVPC peering/Transit Gateway i zapory sieciowe.
Podwójny stosy: planowanie IPv6 z wyprzedzeniem (zapisuje NAT, poprawia skalę adresu).

3) Prywatne punkty końcowe: zasady

• Ruch odbywa się wewnątrz sieci dostawców (nie przez Internet).
• Limity zasad punktu końcowego, gdzie można przejść (prefiksy/ARN/zasoby).
• DNS jest na nowo zdefiniowany jako prywatny IP (patrz: § 6).

Typowe cele: sklepy obiektowe (S3/GCS/Blob), tajne/KMS, kolejki, busy imprez, zarządzane bazy danych, usługi analityczne, rejestry artefaktów.

4) Wejście i wyważenie wewnątrz

Balancer obciążenia wewnętrznego (ILB) dla L4/7, widzimy tylko z prywatnych podsieci.

• „Usługa” typu „LoadBalancer” z adnotacjami wewnętrznymi.
• Zaloguj się przez Internal Ingress (Nginx/Contour/Gateway API) pod prywatnym adresem.
• API Gateway (private): prywatna integracja z backendami; na zewnątrz - tylko przez krawędź, jeśli jest to wymagane.

Przykład: K8s Ingress jako wewnętrzne

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) Kontur Egress: „domyślny - zaprzeczenie”

• NAT Gateway (dla aktualizacji/repozytoriów) + egress permlist via FQDN/IP;
• inspekcja/pełnomocnik TLS, jeżeli polityka wymaga kontroli;
• Prywatne punkty końcowe do PaaS/rejestrów zamiast NAT.
• SG/NACL: wyraźne uprawnienia na usługę, „wschód-zachód” - minimum.
• K8s Polityka Egress (CNI/OPA Gatekeeper/Calico, Polityka) - zewnętrzne luki IP, uprawnienia klastra/punktu końcowego.

6) DNS: podział-horyzont dla stref prywatnych

Oddzielne strefy wewnętrzne ('.internal. corp ") i publicznie.
Prywatne strefy DNS dla usług dostawców: nadrzędne nazwy publiczne (na przykład "wiadro. s3. region. amazonawe. com ") do prywatnych rejestrów A/AAAA.
Spedytorzy/Warunkowe DNS меда, on-prem z chmury.
Format nazwy: enkapsulacja środowiska/regionu ('api. eu1. wewnętrzne. corp "), unikać PII.

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

7) Wzory połączeń międzysystemowych

Peering (VPC i VPC): prosty i szybki; tranzyt nie zawsze jest obsługiwany → Użyj Transit Gateway/Virtual WAN/Cloud Router dla hub-and-speak.
On-prem ⇄ cloud: IPsec VPN do uruchomienia, a następnie dzierżawy linii (DC/ER/IC) z BGP i kopii zapasowych (dwóch dostawców, różne punkty wejścia).
Segmentacja VRF/Route-domain: izolacja obwodu prod/stage/dev i karty.

8) Zero zaufania i uwierzytelnianie wewnętrzne

mTLS-domyślny (siatka serwisowa: Istio/Linkerd/Consul), tożsamość maszyny: SPIFFE/SPIRE.
Zasady L7: autoryzacja przez JWT/roszczenia/zakresy, ograniczenie tras/metod na poziomie proxy.
Tajemnice: HashiCorp Vault/KMS + Operator tajemnic zewnętrznych; krótkotrwałe poświadczenie (STS).
Bastion/Uprzywilejowany dostęp: dostęp do privatki tylko poprzez sesję brokera/JIT (MFA, nagrywanie poleceń).

Przykład: Filtr wysłannika 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) Dane i PaaS wewnątrz prywatnej

Bazy danych/klastry: tylko adresy prywatne; panel administracyjny poprzez bastion/JIT.
Repozytoria: dostęp z VPC za pośrednictwem prywatnego punktu końcowego; polityka punktu końcowego pozwala tylko na żądane wiadra/kontenery.
Kolejki/autobusy: prywatne interfejsy; producenci/konsumenci - w tym samym VPC/peering.
Rejestry artefaktów: prywatny dostęp od operatorów CI/CD w prywatnych podsieciach.

10) Obserwowalność w sieciach prywatnych

OpenTelemetry Collector - jako brama telemetryczna: wewnętrzni eksporterzy do samozatrudnionych (Prometheus/Tempo/Loki/ClickHouse) lub do zarządzania backends za pośrednictwem prywatnych punktów końcowych.
Dzienniki przepływu/dzienniki NSG/NACL i analizator osiągalności są wymagane.
SLO-plasterki: 'site/region/vpc/subnet', wpisy do egress i nieoczekiwany „Internet direction”.

11) Badanie i weryfikacja

Polityka jako kod (OPA/Gatekeeper) dla zasad sieci/Ingress/Service.
Trasy kanaryjskie: domeny testowe w prywatnym systemie DNS, kontrole syntetyczne z różnych podsieci/AZ/regionów.
Sieć chaosu: opóźnienia/straty w ramach inter-VPC/inter-AZ (netem/Toxiproxy), kontrole czasowe i polityka retry.

12) Przykłady konfiguracji

12. 1 Terraform: etykiety i trasy (pomysł)

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 Polityka: zaprzeczać wszystkiemu poza tym, czego potrzebujesz

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 (system wewnętrzny) + HSTS

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

13) Antypattery

wspólne „zarządzanie internetem” z prywatnych podsieci; brak kontroli nad wyjściem.
Split-brain DNS i random manual '/etc/hosts'.
Przecinanie CIDR i „NAT gniazdowanie lalek”.
Publiczne punkty końcowe dla baz danych/magazynów „dla wygody”.
Brak dzienników przepływu/audytów reguł; „otwórz” SG '0. 0. 0. 0/0`.
Długotrwałe klucze dostępu statycznego w kodzie/CI.

14) Koszt i wydajność

Prywatne punkty końcowe są często tańsze niż stałe NAT i bezpieczniejsze.
Harmonogram klastrów NAT/az-local dla szerokości pasma, aby uniknąć tworzenia wąskich gardeł.
Pamięć podręczna/krawędź i SWR zmniejszają ruch międzyregionalny.
Wybór protokołów: HTTP/2/gRPC wewnątrz → istnieje mniej połączeń i TLS napowietrznych.

15) Szczegóły dotyczące iGaming/Finance

PCI DSS: układ kart (CDE) w oddzielnej sieci/VRF, brak internetu; dostęp do dzienników sklepu/PSP wyłącznie za pomocą prywatnych punktów końcowych; audyty niezmienne (WORM/Object Lock).
KMS/Vault: klucze podzielone na regiony/marki; operacje podpisywania (HSM) są dostępne tylko od CDE przez mTLS.
PSP/KYC: jeżeli istnieje prywatna łączność/rynki - zastosowanie; w przeciwnym razie wyjmij zaufany serwer proxy z HMAC/mTLS i wyraźną listą dopuszczalną.
Wielopoziomowe: znaczniki i polityki „najemcy ”/„ marki”; oddzielne prywatne nazwy DNS i warstwy SG.

16) Lista kontrolna gotowości Prod

• Plan CIDR bez skrzyżowań; podwójny stos gotowy (IPv6).
• Hub-and-Speak, Transit, peering; on-prem ⇄ cloud - BGP, kopie zapasowe par linków.
• Wszystkie PaaS/storages/DB - za pośrednictwem prywatnych punktów końcowych + polityki punktów końcowych.
• Wewnętrzny LB/Ingress; obwód publiczny - tylko na krawędzi/WAF.
• Split-horizon DNS, strefy prywatne i spedycja warunkowa są skonfigurowane.
• Egress jest domyślnie „zaprzeczać”; NAT/proxy są ograniczone i rejestrowane.
• Mesh mTLS + SPIFFE; JWT-authz na L7; Skarbiec/ESO, krótkie sekrety.
• Polityka/SG/NACL - „minimum niezbędne”, dzienniki przepływu i analiza osiągalności.
• OTel Collector wewnątrz; wpisy do egress, SLO przez 'site/region/vpc'.
• PCI/audyt: dzienniki WORM, KMS/HSM, izolacja CDE, uruchomienie dostępu.

17) TL; DR

Zbuduj sieć hub-and-speak z jasnym planem CIDR, użyj prywatnych punktów końcowych do każdej bazy danych PaaS/storage/i ruchu na zewnątrz tylko poprzez zarządzane punkty wyjścia. Wewnątrz - wewnętrzny LB/Ingress, mTLS + SPIFFE, split-horizon DNS, ścisła polityka/SG i telemetria za pośrednictwem OTel. W przypadku iGaming/Finance dodaj segmentację PCI, KMS/Vault i niezmienny audyt; Wyjście PSP/KYC za pomocą kanałów prywatnych lub ściśle kontrolowanego serwera proxy.