現代のクラウド環境では、従來の境界防禦モデルがもはや十分ではなくなった。2009年にジョン・カインドバグが提唱したゼロトラスト（Zero Trust）アプローチは、常に信頼せず常に検証するという原則に基づき、機密情報の保護を強化するための枠組みとして注目されている。本記事では、Shopifyが數千のサービス間で実施したMTLS（Mutual TLS）自動化の実踐を紹介し、その技術的詳細と課題を解説する。
MTLSは、クライアントとサーバー雙方が証明書を交換し、お互いの身分を検証する通信プロトコルである。ゼロトラストでは、ネットワークの境界を信頼せず、すべての通信が認証と暗號化を必要とする。このアプローチは、クラウドやハイブリッド環境でのセキュリティ強化に不可欠である。
Shopifyでは、X.509証書を用いた機械の身分証明を実現し、Spiffy ID（URI形式のtrust-domain/path）を採用している。このIDは、GoogleのSpire（CNCFプロジェクト）を基盤にし、Google Certificate Authority Service（CAS）で証書を生成する。Spiffy IDは、KafkaなどのサービスでACL（Access Control List）を構築する際の解析に特化したフォーマットを提供する。
Shopifyでは、三層構造のPKI（Public Key Infrastructure）を採用している。Root CAは受控され、Intermediate CAが葉証書を発行し、サービス間で使用される。証書のローテーションは、Root CAを3年前に、Subordinate CAを3か月前に実施し、自動化された警報と検証プロセスで平滑に移行する。
サービスメッシュは、自動証書ローテーションやMTLS通信を提供するが、CPUやメモリの負荷が高く、Shopifyの百萬規模のPodでは適用が困難である。一方、Google ALBやIngress Engine XはMTLSをサポートするが、カスタム解析やベンダー鎖定の問題が生じる。
Shopifyでは、Google Cloud Run Schedule Jobsを用いて証書の自動更新を実現し、Google Secret Managerで証書を管理している。また、Argo CD Sync Wavesを活用し、証書の更新タイミングを制御し、サービスの起動前にTLSデータを確保する。
Spiffy IDはSAN URIから解析され、Kubernetes Secretに注入される。ACLは、特定のエンドポイントへのアクセスを制限し、サービス間の信頼関係を確立する。たとえば、サービスAが/internal/Zエンドポイントにアクセスできない場合、アクセス拒否が発生する。
StatsDを用いて指標を収集し、Prometheusに格納し、Grafanaで可視化する。Jobの狀態（cube job status failed）を監視し、Prometheusのルールに基づくアラームを生成する。また、GCP Logs ExplorerとTempoを統合し、アプリケーションのトレースを追跡する。
數千のサービス間でのMTLS実裝では、認証プロトコルの選択が重要である。Ingress Engine Xでは、SAN URIのカスタム解析が必要であり、LuaスクリプトやGPTを活用してロジックを構築する。
証書のローテーションや秘密の管理は、システムの安定性に直結する。Shopifyでは、動的なスケジュール戦略を採用し、各サービスに獨自のCron表現を生成し、同時にリクエストが発生するのを防ぐ。
ゼロトラストの実現には、MTLSの自動化と機械の信頼性ある身分証明が不可欠である。Shopifyの実踐では、Spiffy ID、PKI構造、Argo CDの同期制御、そして監視インフラの統合が成功の鍵となった。今後は、より高度な自動化とセキュリティのバランスを追求する必要がある。