プライベートエンドポイントとイントラネット

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ピアリング/トランジットゲートウェイ間、およびネットワークファイアウォール。
デュアルスタック：事前にIPv6をスケジューリングします（NATを保存し、アドレスのスケールを向上させます）。

3）プライベートエンドポイント： 原則

• トラフィックはプロバイダネットワーク内に入ります（インターネット経由ではありません）。
• 行えるエンドポイントポリシーの制限（接頭辞/ARN/リソース）。
• DNSはプライベートIPに再定義されます（第6章を参照）。

典型的なターゲット：オブジェクトストア（S3/GCS/Blob）、 シークレット/KMS、キュー、イベントバス、マネージドデータベース、分析サービス、アーティファクトレジスタ。

4）中の記入項目そしてバランスをとること

L4/7の内部ロードバランサー（ILB）は、プライベートサブネットからのみ表示されます。

• 内部注釈付きのタイプ'LoadBalancer'の'Service'。
• プライベートアドレスでInternal Ingress （Nginx/Contour/Gateway API）経由でログインします。
• 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）出力輪郭： 「default-deny」

• NATゲートウェイ（更新/リポジトリ用）+FQDN/IP経由のegress allowlist；
• ポリシーが制御を必要とする場合のTLS検査/プロキシ。
• NATではなくPaaS/レジスタへのプライベートエンドポイント。
• SG/NACL：サービスごとの明示的なアクセス許可「、東西」-最小。
• K8s Egress Policies （CNI/OPA Gatekeeper/Calico NetworkPolicy）-外部IPバーリング、クラスタ/エンドポイント権限。

6） DNS： スプリットホライズンprivate zones

独立した内部ゾーン（'。internal。corp'）とpublic。
プロバイダサービスのプライベートDNSゾーン：公衆名（例えば、'bucket。s3。地域。amazonaws。com'）プライベートA/AAAAレコードへ。
Forwarders/Conditional DNS между on-prem ↔ cloud。
Name format： environment/region （'api。eu1。内部的に。corp'）、PIIを避ける。

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

7）相互接続パターン

ピアリング（VPC↔VPC/VNet↔VNet）：シンプルで高速。トランジットは常にサポートされているわけではありません→ハブアンドスポーク用にTransit Gateway/Virtual WAN/Cloud Routerを使用してください。
オンプレミス⇄クラウド：IPsec VPNを起動し、BGPとバックアップ（2つのプロバイダ、異なるエントリーポイント）でライン（DC/ER/IC）をリースします。
VRF/Route-domain segmentation： prod/stage/devとカード境界の分離。

8）ゼロ信頼および内部認証

mTLS-default（サービスメッシュ：Istio/Linkerd/Consul）、マシンID： SPIFFE/SPIRE。
L7ポリシー：JWT/クレーム/スコープによる承認、プロキシレベルでのルート/メソッドの制限。
Secrets： HashiCorp Vault/KMS+外部シークレットオペレーター；短命の資格情報（STS）。
バスティオン/特権アクセス：ブローカー/JITセッション（MFA、コマンド記録）を通じてのみprivatkaにアクセスできます。

例： 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 policyは、目的のbucket/containersのみを許可します。
キュー/バス：プライベートインターフェイス；生産者/消費者-同じVPC/ピアリングで。
アーティファクトレジスタ：プライベートサブネット上のCI/CDランナーからのプライベートアクセス。

10）プライベートネットワークにおける観測可能性

OpenTelemetry Collector-テレメトリーゲートウェイとして：自己ホスト（Prometheus/Tempo/Loki/ClickHouse）またはプライベートエンドポイント経由で管理されるバックエンドへの内部エクスポート。
フローログ/NSG/NACLログと到達性アナライザが必要です。
SLOスライス：'site/region/vpc/subnet'、 egressと予期しない「Internet direction」へのアラート。

11）テストおよび検証

ネットワークルール/入力/サービスのコードとしてのポリシー（OPA/ゲートキーパー）。
カナリアルート：プライベートDNSのテストドメイン、さまざまなサブネット/AZ/リージョンからの合成チェック。
カオスネットワーク：VPC 間/AZ間（netem/Toxiproxy）の遅延/損失、タイムアウトチェックおよび再試行ポリシー。

12）構成例

12.1テラフォーム：ラベルとルート（アイデア）

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（内部スキーム）+HSTS

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

13） Antipatterns

プライベートサブネットからの一般的な「管理-インターネット」。排出制御の欠如。
Split-brain DNSとランダムマニュアル'/etc/hosts'。
CIDRと「NATネスティングドール」の交差。
データベース/ストレージのパブリックエンドポイント「利便性のために」。

フローログ/ルール監査はありません。「open」 SG '0。0.0.0/0`.

コード/CI内の長寿命の静的アクセスキー。

14）コストとパフォーマンス

プライベートエンドポイントは、多くの場合、永続的なNAT出力よりも安価で安全です。
帯域幅のためにNAT クラスタ/az-localをスケジュールし、ボトルネックを作成しないようにします。
キャッシュ/エッジとSWRは、クロスリージョントラフィックを削減します。
プロトコルの選択：→内部のHTTP/2/gRPCでは、接続数とTLSオーバーヘッドが少なくなります。

15） iGaming/Financeの詳細

PCI DSS： 別のネットワーク/VRFのインターネット無しのカード回路（CDE）；プライベートエンドポイントでのみストア/PSPログにアクセスできます。不変監査（WORM/オブジェクトロック）

KMS/Vault：地域/ブランドごとに分割されたキー。署名操作（HSM）は、CDE over mTLSからのみ使用できます。
PSP/KYC：プライベート接続/マーケットがある場合-使用；それ以外の場合は、HMAC/mTLSと明示的なallowlistで信頼されたプロキシをエグレスします。
マルチテナンシー：'テナント'/'ブランド'によるタグとポリシー。プライベートDNS名とSGレイヤーを分離します。

16） Prod Readinessチェックリスト

• 交差なしのCIDR計画；デュアルスタック対応（IPv6）。
• ハブ・アンド・スポーク、トランジット、ピアリング；オンプレミス⇄クラウド-BGP、バックアップリンクペア。
• すべてのPaaS/storages/DB-プライベートエンドポイント+エンドポイントポリシーを介して。
• 内部LB/Ingress；public perimeter-エッジ/WAFのみ。
• 分割地平線DNS、プライベートゾーン、および条件付き転送が設定されています。
• Egressはデフォルトでは「拒否」です。NAT/プロキシは制限され、記録されます。
• メッシュmTLS+SPIFFE；L7のJWT-authz；ヴォールト/ESO、短い秘密。
• NetworkPolicy/SG/NACL-「最小必要」、フローログおよび到達可能性分析。
• 内部のOTelコレクター；'site/region/vpc'でSLOを出力します。
• PCI/監査： WORMログ、KMS/HSM、 CDE分離、アクセスランブック。

17） TL；DR（ドクター）

明確なCIDR計画でハブとスポークネットワークを構築し、各PaaS/ストレージ/データベースにプライベートエンドポイントを使用し、管理されたエグレスポイントを介してのみ外部にトラフィックを送信します。内部-内部LB/Ingress、 mTLS+SPIFFE、分割地平線DNS、厳密なNetworkPolicy/SG、 OTelによるテレメトリ。iGaming/Financeでは、PCIセグメンテーション、KMS/Vault、および不変監査を追加します。プライベートチャンネルまたは厳密に制御されたプロキシを介してPSP/KYC出力。