ゼロトラストアーキテクチャ
概要
Zero Trust （ZT）は、ネットワーク境界がもはや信頼できるゾーンとは見なされないセキュリティモデルです。各リクエスト（ユーザー→アプリ、サービス→サービス、デバイス→ネットワーク）は、コンテキスト信号（アイデンティティ、デバイス状態、場所、リスク、行動）を考慮して、明示的に認証、承認、暗号化されます。目標は、ブラスト半径を最小限に抑え、横方向の移動のリスクを低減し、コンプライアンスを簡素化することです。
ゼロトラストの基礎
1.明示的な信頼はありません-信頼は/VPN/ASNネットワークから継承されません。
2.アクセスは必要最小限です。「今必要なものだけを提供する」ポリシー。
3.継続的検証：セッションとトークンは、リスクとコンテキストのために定期的に再評価されます。
4.妥協の前提：セグメンテーション、観察可能性、急速な封じ込めおよび主要な回転。
5.どこでも暗号化：TLS 1。2+/1.3とmTLSデータプラン内、保護されたDNS、 KMS/HSMの秘密。
ターゲットのランドスケープと制御ドメイン
アイデンティティ：ヒト（IdP： SSO、 MFA、 パスキー/FIDO2）、マシン（SPIFFE/SVID、 x509/mTLS）。
デバイス：ポリシーの遵守（MDM/EDR、ディスク暗号化、パッチ、脱獄/ルート-禁止）。
ネットワーク：L3/L7マイクロセグメンテーション、ZTNA/SDPゲートウェイ、サービスメッシュ（Envoy/Istio/Linkerd）。
アプリケーション/API： mTLS、 OIDC/JWT、リクエストシグネチャ（HMAC）、レート制限、DLP/マスキング。
データ：分類（公開/機密/制限）、フィールドレベルでのトークン化/暗号化。
可視性：集中認証/承認ログ、行動分析、SLO/SLA。
参照アーキテクチャ（平面で分解）
コントロールプレーン：IdP/CIAM、 PDP/PEP （OPA/Envoy）、ポリシーカタログ、PKI/CA、デバイス資格。
Data Plane：プロキシアクセス（ZTNA）、 mTLSおよびL7ポリシーのサイドカープロキシ（Envoy）、 GW サービスゲートウェイ/API。
管理平面：サービスカタログ、CMDB、 CI/CD、秘密管理（Vault/KMS）、集中監査。
1.識別（SSO+フィッシング耐性MFA）→2）デバイス評価（MDM姿勢）→3） ZTNAプロキシがmTLSをアプリケーションに確立する→4） PDP（ポリシー）属性に基づいて決定（ABAC/RBAC）→5）継続的なリスク再評価（時間、地理、異常）。
アイデンティティと承認
IdP/SSO： OIDC/SAML、デフォルトMFA、できればFIDO2（パスキー）。
RBAC/ABAC：役割+コンテキスト属性（デバイスのステータス、部門、リスクプロファイル）。
ジャストインタイム（JIT）アクセス：自動失効を伴う一時的な権限；壊れ目ガラス-厳しく調整される。
機械のためのmTLS：短命の証明書が付いているSPIFFE/SVIDまたは内部PKI；自動ロータリーリリース。
デバイスとコンテキスト
姿勢：OS/EDRバージョン、含まれているディスク暗号化、ファイアウォール；非準拠→最小アクセスまたはブロック。
証明：デバイスID+署名付き証明（MDM/エンドポイント）。
ネットワーク制限：サードパーティトンネルのブロック、強制的な企業DNS、 DNS/WebRTC漏洩に対する保護。
ネットワークとマイクロセグメンテーション
「フラット」VLANの破棄：代わりに、セグメント/VRFとL7のポリシー。
サービスメッシュ：サイドカープロキシは、mTLS、ポリシー認可（OPA/EnvoyFilter）、テレメトリーを提供します。
ZTNA/SDP：ネットワークへのアクセスではなく、特定のアプリケーションへのアクセス。kliyent↔broker↔app、 PDPのポリシー。
リモートアクセス：「厚い」VPNをアプリプロキシに置き換えます。フォールバックトンネルはルート/ポートに制限されています。
ポリシーとソリューションエンジン
PDP/PEP：政策決定ポイント（OPA/Styra、 CedarPep。）+ポリシー執行ポイント（Envoy/Istio/Gateway）。
ポリシーモデル：宣言規則（Rego/Cedar）、静的属性およびコンテキスト属性、リスク評価。
rego package access. http
default allow = false
allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}トレースソリューション：監査のログ'input'/'result'/'explain'。
デフォルトの暗号化と信頼
TLS 1。2+/1.3どこでも、厳密な暗号スイート、HSTS、 OCSPのステープル。
mTLS内部：相互証明書によるservis↔servisのみ。短期キー（時間/日）。
秘密：KMS/HSM、動的秘密（Vault）、短いTTL、アプリケーションの最小特権。
観察可能性、SLOおよび応答
メトリック（最小セット）：- 認証と承認の成功（％）、p95 PDPの決定時間、p95 TLSハンドシェイク。
- ポリシーでブロックされたリクエストの割合（異常/false）。
- ZTNAブローカーとメッシュコントローラの可用性。
- 迎合的な装置および傾向の割合。
- "ZTNA ≥ 99の可用性。95％/月；p95 authZの決定≤ 50ミリ"
- "mTLSのリクエストの割合≥ 99。9%».
- "0以下。1％の誤ったアクセス障害/日"
警報：否定のバースト、p95ハンドシェイクの劣化、無効なチェーン、準拠デバイスの割合の低下、地理的異常/ASN。
周囲からゼロトラストへの移行： ロードマップ
1.在庫：アプリケーション、データフロー、消費者、感度（PII/カード/ペイアウト）。
2.アイデンティティおよびMFA：すべてのためのSSOおよびフィッシング抵抗力があるMFA。
3.デバイスのコンテキスト：MDM/EDR、基本的なコンプライアンスポリシー、非準拠ブロック。
4.プライオリティパスのマイクロセグメンテーション：支払い、バックオフィス、管理者；mTLSと入力します。
5.ユーザーアクセス用のZTNA：プロキシを介してアプリケーションを公開し、「wide VPN」を削除します。
6.ABACポリシー：一元化されたPDP、宣言規則、監査。
7.サービスメッシュ拡張：S2S mTLS、 L7ポリシー、テレメトリー。
8.自動化とSLO： アラート、ポリシーテスト（政治CI）、ゲームの日"IdPが利用できない場合はどうなりますか？».
iGaming/Fintechの特異性
厳格なドメインセグメンテーション：支払い/PII/不正防止/コンテンツ-個別の境界とポリシー；ZTNA経由でのみアクセスできます。
PSP/banksとの相互作用：ASN/rangeによるallow-list、 mTLSからPSPエンドポイント、Time-to-Wallet監視、authZ障害。
コンテンツプロバイダとパートナー：一時的なJIT APIアクセス、短いTTLトークン、統合監査。
コンプライアンス：PCI DSS/GDPR-データの最小化、DLP/仮名化、機密テーブルへのアクセスのロギング。
サプライチェーンセキュリティとCI/CD
アーティファクト署名（SLSA/Provenance）：コンテナ署名（cosign）、 K8sの入場ポリシー。
SBOMと脆弱性：SBOM生成（CycloneDX）、パイプラインのポリシーゲート。
CIの秘密：OIDC Federation to Cloud KMS；静的なキーの禁止。
回転：頻繁な、自動；インシデントの強制的な取り消し。
よくあるバグやアンチパターン
「ZTNA=new VPN」：アプリケーションの代わりにネットワークを公開することは、Zero Trustではありません。
デバイスチェックはありません：MFAですが、感染した/根付いたデバイスはアクセスできます。
単一のスーパーユーザー：JITと個別の役割の欠如。
サービスコードのポリシー：中央監査/更新は不可能です。
mTLS partial： mTLSのないサービスの一部→「漏えい」ループ。
ゼロUX：冗長MFA要求、SSOなし。result-コマンドに対する抵抗。
技術選びのミニガイド
ユーザーアクセス：ZTNA/SDPブローカー+IdP （OIDC、 FIDO2 MFA）。
サービスセキュリティ：service-mesh （Istio/Linkerd）+OPA/Envoy authZ。
PKI：短いTTLを持つSPIFFE/SVIDまたはVault PKI。
政治家：OPA/レゴまたは杉；store in Git、 check in CI （policy-tests）。
ログとテレメトリー：OpenTelemetry→集中解析、異常検出。
サンプル構成（フラグメント）
特使（サービス間の相互TLS）
yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: trueOPA/Rego： 「金融」からのレポートへのアクセス、準拠デバイスからのアクセス、勤務時間中
rego package policy. reports
default allow = false
allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}ゼロトラスト実装チェックリスト
1.すべてのユーザーと管理者に対してSSOとFIDO2 MFAを有効にします。
2.非準拠ロックでデバイスの姿勢（MDM/EDR）を入力します。
3.ZTNA（アプリごと）へのユーザーアクセスを転送し、狭いS2SチャネルでのみVPNを残します。
4.内部-デフォルトではmTLS+短命の証明書。
5.ポリシー（PDP/OPA）を一元化し、Gitに保存し、CIでテストします。
6.セグメントに敏感なドメイン（支払い/PII/バックオフィス）と東西を制限します。
7.テレメトリー、SLO、アラートをauth/authZ、 mTLS共有、姿勢信号に設定します。
8.「ゲーム日」（IdPの失敗、キーリーク、ブローカーのドロップ）を行い、SOP/ロールバックを修正します。
FAQ（よくある質問）
Zero TrustはVPNを完全に置き換えていますか？
ユーザーアクセス-はい、ZTNAに有利です。S2Sトランクの場合、VPN/IPsecは残りますが、mTLS overと厳格なポリシーがあります。
ZTはUXを悪化させる可能性がありますか？
無思慮であれば。SSO+FIDO2、 アダプティブMFA、およびアプリアクセスごとに、UXは通常改善されます。
サービスメッシュの導入は必要ですか？
必ずしもそうではありません。しかし、大規模なマイクロサービス環境では、メッシュはmTLS/ポリシー/テレメトリを根本的に簡素化します。
合計
Zero Trustは製品ではなく、アーキテクチャの規律です。新しい境界としてのアイデンティティ、デバイスのコンテキスト、アプリケーションアクセス（ZTNA）、マイクロセグメンテーション、mTLS、集中ポリシー、測定可能な信頼性。ロードマップとチェックリストに従うことで、攻撃面を縮小し、監査をスピードアップし、「デフォルトの信頼」なしで持続可能なセキュリティを得ることができます。