本稿で紹介する内容は、セキュリティカンファレンス「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」を基に作成しました。