私人endpoints和內部網絡

1）為什麼要建立私人網絡

• 將PaaS/DB/存儲與公共 IP隔離；
• 法規遵從性簡化（PCI DSS/GDPR）；
• 可預見的延遲和路由。

2）基本模型： VPC/VNet和樞紐

地址空間：單個CIDR計劃，沒有交叉點（例如'10。0.0.0/12'切入周圍和中心）。
細分：具有單獨路由/ACL/SG的「ingress」，「app」，「data」，「ops」，「shared」子網。
公交樞紐：帶網關的中央VPC/VNet （VPN/DirectConnect/ExpressRoute/Interconnect）、VPC同步/公交網關和網絡門戶。
雙堆棧：提前IPv6規劃（節省NAT,提高地址規模）。

3）私人endpoints： 原則

• 流量在提供商網絡內（不通過Internet）。
• Endpoint策略限制了可以行走的位置（前綴/ARN/資源）。
• DNS被覆蓋為私有IP（請參閱§6）。

類型目標：對象堆棧（S3/GCS/Blob），秘密/KMS，隊列，DB驅動的事件總線，分析服務，寄存器工件。

4）進入和平衡內部

僅從私人子網中看到用於L4/7的內部負載平衡器（ILB）。

Kubernetes:

帶有內部註釋的「服務」類型「LoadBalancer」。
通過私人地址上的Internal Ingress（Nginx/Contour/Gateway API）登錄。
Gateway API（私人）：私人後端集成；向外-如果需要的話,只能通過邊緣。

示例： Ingress作為內部K8s

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路徑： 「默認為deny」

• NAT Gateway（用於更新/存儲庫）+通過FQDN/IP的egress allowlist；
• TLS檢查/代理，如果政策需要控制；
• Private endpoints到PaaS/寄存器而不是 NAT。
• SG/NACL：明確的per服務權限，「東西向」是最低權限。
• Egress K8s政策（CNI/OPA Gatekeeper/Calico NetworkPolicy）-禁止外部IP，群集/擴展權限。

6) DNS: split-horizon и private zones

分隔內部區域（'.internal.公司）和公開。
提供商服務的私人DNS區域：覆蓋公共名稱（例如,'bucket。s3.region.amazonaws.com'）用於私有A/AAAA記錄。

Forwarders/Conditional DNS между on-prem ↔ cloud.

名稱格式：封裝環境/區域（'api.eu1.internal.公司,避免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↔VNet）：簡單快捷；不總是支持公交→使用公交Gateway/Virtual WAN/Cloud Router for star （hub-and-spoke）。
On-prem ⇄ Cloud：IPsec VPN用於啟動，然後是帶有BGP和備份（兩個提供商，不同的入口點）的專用線（DC/ER/IC）。
VRF/路線域分割： prod/stage/dev隔離和卡外圍。

8）Zero Trust和內部身份驗證

mTLS默認值（服務主題：Istio/Linkerd/Consul）,機器標識：SPIFFE/SPIRE。
L7策略：通過JWT/claims/scopes授權,在代理級別限制路由/方法。
Secrets: HashiCorp Vault/КMS + External Secrets Operator;短壽命的credenschels（STS）。
基地/特權訪問：僅通過經紀人/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內部私有

基地/集群：僅限私人地址；通過bastion/JIT進行管理。
存儲：從VPC通過私人終端訪問；endpoint策略只允許您想要的垃圾箱/容器。
隊列/總線：私人接口；同一VPC/peering中的生產者/消費者。
文物寄存器：從CI/CD運行者在私人子網中的私有訪問。

10）私人網絡的可觀察性

OpenTelemetry Collector-作為遙測網關：內部出口商在自我托管的（Prometheus/Tempo/Loki/ClickHouse）或通過私人終端管理後端。
Flow logs/NSG/NACL logs和reachability analyzer-是強制性的。
SLO切片：「site/region/vpc/subnet」，超出了egress泄漏和出乎意料的「互聯網方向」。

11）測試和驗證

用於網絡規則/輸入/服務的策略作為代碼（OPA/Gatekeeper）。
Canary路由：私有DNS中的測試域,來自不同子網/AZ/地區的合成檢查。
混沌網絡：VPC/AZ inter-AZ（netem/Toxiproxy）中的延遲/損失，定時檢查和返回策略。

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）反模式

來自私人子網的通用「管理互聯網」；缺乏控制。
拆分DNS和隨機手動「/etc/hosts」。
相交的CIDR和「NAT矩陣」。
為了方便起見，公開為DB/金庫提供 endpoint。

沒有線程/規則審核日誌；「開放」SG'0。0.0.0/0`.

代碼/CI中的長壽命靜態訪問密鑰。

14）成本和性能

私人結帳通常比永久性NAT egress便宜，更安全。
規劃NAT 群集/az-local的帶寬,以免創建bottleneck。
緩存/邊緣和SWR可減少跨區域流量。
協議選擇：HTTP/2/gRPC內部→較少的連接和TLS overhead。

15） iGaming/財務細節

PCI DSS：一個單獨的網絡/VRF中的卡路徑（CDE），沒有互聯網；僅通過私人端口/PSP登錄器訪問；不可更改的審計（WORM/對象鎖）。
KMS/Vault：按區域/品牌細分；簽名操作（HSM）僅可通過mTLS從CDE獲得。
PSP/KYC：如果有私人連接/標記-使用；否則-通過具有HMAC/mTLS 和顯式allowlist的受信任代理來進行表述。
多影子：「tenant」/「brand」標簽和政策；單獨的私有DNS名稱和SG層。

16）準備就緒支票清單

• CIDR無交叉計劃；雙堆棧就緒（IPv6）。

[] Hub-and-Spoke, Transit, peering;on-prem ⇄ cloud-BGP，備用鏈接對。

• 所有PaaS/存儲/DB-通過私人endpoints+endpoint政策。

[] Internal LB/Ingress;公共外圍-僅在邊緣/WAF上。

• 已配置Split-horizo​​n DNS，private zones和condition-forwarding。
• Egress默認為「deny」；NAT/代理受到限制和日誌記錄。

[] Mesh mTLS + SPIFFE;L7上的JWT-authz；Vault/ESO，簡短的秘密。

• NetworkPolicy/SG/NACL-「最低要求」、流記錄和可重復性分析。
• 內部的OTel收藏家；通過「站點/區域/vpc」對egress泄漏進行SLO。
• PCI/審計：WORM日誌，KMS/HSM，CDE隔離，訪問運行簿。

17) TL;DR

以清晰的CIDR計劃構建集線器與分頻器模式網絡,在每個PaaS/存儲/DB上使用專用端點,並且僅通過托管的egress點向外通信。內部-內部LB/Ingress，mTLS+SPIFFE，split-horizo​​n DNS，嚴格的NetworkPolicy/SG和通過OTel的遙測。對於iGaming/financial，請添加PCI細分，KMS/Vault和不可更改的審計；PSP/KYC通過私人渠道或嚴格控制的代理輸出。