管理負荷の限界をどう突破した？ LinkedInが「SPIRE」で築くゼロトラスト：短命プロセスの認証という壁

サービス間の安全な通信を保証する認証システムの運用には多様な課題が発生する。自社システムの限界に直面したLinkedInは、オープンソースの「SPIRE」を導入した。独自の制約をどう乗り越えたのか。

[TechTargetジャパン]

　ビジネス特化型SNS（ソーシャルネットワーキングサービス）を運営するLinkedInは、自社データセンター内で稼働する膨大なマイクロサービス間で、暗号化通信やアイデンティティーの証明に用いられるデジタル証明書の標準規格「X.509証明書」を用いた認証を実施している。

　LinkedInは近年、独自の社内PKI（Public Key Infrastructure）システムの限界に直面していた。PKIは、公開鍵暗号技術を用いてデジタル証明書を発行、管理する仕組みを指す。従来のシステムは拡張性が低く、標準的なアイデンティティーフォーマットに適合しない。証明書の自動ローテーションや追跡といったライフサイクル機能もなく、運用担当者の作業負荷が高まっていた。

　この状況を打開する手段としてLinkedInが選定したのが、クラウドネイティブなシステム向けのオープンソースアイデンティティー管理システム「SPIFFE」およびその実装である「SPIRE」だ。同社はSPIREを社内インフラに組み込むことで、数十万のノード（ネットワーク上のサーバ機器など）とワークロード（実行されるアプリケーションやプロセス）の認証を自動化し、運用の効率化を実現した。

　既存システムからSPIREへの移行は決して平坦な道のりではなかった。本稿は、LinkedInがいかにして強固な信頼チェーンを構築し、エージェントソフトウェアを配置できないシステム構成での証明書発行を可能にしたのかに迫る。

ハードウェアを起点とした信頼の構築

併せて読みたいお薦め記事

クラウドネイティブシステムのセキュリティ運用

• Kubernetesの構成は“穴だらけ”？　致命的な設定ミスを防ぐ「KSPM」の実力
• 大量アラートにもう悩まされない　「発生元」を断つコンテナセキュリティ運用術

　本稿で紹介する内容は、セキュリティカンファレンス「Open Source SecurityCon」におけるジュンユアン・ツェン氏とウェイ・ジャン氏のセッション「From Adoption to Innovation: LinkedIn's SPIRE Journey」に基づく。

　LinkedInがSPIREを選定した理由は、同社の要件に適合する特有の優位性にあった。クラウドネイティブなシステムだけではなく、ベアメタル（物理サーバ）のシステム構成でも最小限の依存関係で動作可能な点や、分散キャッシュ設計による高い拡張性が評価されている。豊富なプラグインによる拡張性を備えていることも決定打となった。

　SPIREをオンプレミスインフラと連携させる上で、最大の障壁となったのが「SPIREサーバとエージェントソフトウェアの信頼性をいかに確保するか」という問題だった。

　LinkedInは、ハードウェアの「信頼の起点」を確立するために、標準規格TPM（Trusted Platform Module）準拠のセキュリティ用ハードウェアチップを用い、機器の正当性を検証するプロセス「ノードアテステーション」を導入した。データセンターでのプロビジョニング（配備）時に、スイッチ、ポート、キャビネットなど物理的な設置場所の情報を資産データベースに記録し、ハードウェア固有の変更不可能な暗号鍵であるEK（Endorsement Key）を登録する仕組みを構築した。

　システム起動時には、TPMチップから取得したEKと資産データベースの情報を照合する。これによって、攻撃者が偽のTPMチップを用意したとしても、物理的な設置場所のデータが一致しなければノードとして登録できない強固な検証プロセスを実現した。

短命なプロセスを処理する「エージェントレス」アーキテクチャ

　システムの整備が進む一方で、SPIRE標準のアーキテクチャでは対処が難しい領域も浮き彫りになった。通常、SPIREは各ノードにエージェントソフトウェアを配置して証明書の要求や更新を実施する。しかし、数分から数時間で消滅する短命のプロセスでは、エージェントソフトウェアを登録する動的な処理自体がシステム全体のオーバーヘッド（処理に伴う余分な負荷や時間）になった。パブリッククラウドや管理権限を持たないインフラ、「macOS」など「Linux」以外のOSでは、エージェントソフトウェアの展開と運用が困難だという課題もあった。

　この課題を解決するため、LinkedInは「エージェントレスアーキテクチャ」を独自に開発した。各ノードにエージェントソフトウェアを配置するのではなく、クライアントとSPIREサーバの間に仲介役となるgRPC（高速にシステム間でデータをやりとりする通信方式）サービスを配置する手法だ。

　例えば自動化ツール「GitHub Actions」の処理に対しては、認証情報を安全にやりとりするための共通規格「OIDC」トークンを利用して認証する。仲介サービスがOIDCトークンの正当性を確認し、要求された属性情報と一致した場合のみ、SPIREサーバにローカルでAPIを呼び出して証明書を発行し、クライアントに渡す仕組みだ。これによって、エージェントソフトウェアの展開が不可能なシステム構成であっても、安全に証明書を発行、管理することが可能になった。

　セッションでは、ツェン氏とジャン氏がインフラストラクチャ刷新における運用面の学びを共有した。

　ジャン氏は「証明書を発行することは始まりに過ぎない」と述べる。「全てを疑う」ことを前提としたセキュリティアプローチである「ゼロトラストセキュリティ」に基づく認証システムの変更は、社内のさまざまな認証ライブラリや権限管理ポリシーのアップデートを伴う。そのため、関連する他部門との早期の擦り合わせや、監視・可視化機能の入念な設計がプロジェクト成功の鍵となる。

本稿は、Cloud Native Computing Foundation（CNCF）が2025年11月25日に公開した動画「From Adoption to Innovation: LinkedIn’s SPIRE Journey - Junyuan Zeng & Wei Zhang, LinkedIn」を基に作成しました。