分散プラットフォームのセキュリティ確保 — アイデンティティ、シークレット、鍵の管理

Ankur Singla

これは、F5がSaaSサービスを構築・運用するために必要だったさまざまな取り組みを紹介するブログシリーズの第3回です。

1. 分散型Kubernetes PaaS向けコントロールプレーン
2. 分散アプリケーション向けグローバルサービスメッシュ
3. 分散インフラ、アプリ、データのためのプラットフォームセキュリティ
4. 分散クラスターのアプリケーションおよびネットワークセキュリティ
5. グローバルに分散したプラットフォーム全体のオブザーバビリティ
6. グローバルに分散したプラットフォームの運用とSRE
7. 分散マイクロサービス向けGolangサービスフレームワーク

最初のブログでは、分散クラウド向けの新しいプラットフォームを構築するに至ったニーズについて、その背景をご紹介しました。このプラットフォームを使用して、お客さまはスマートマニュファクチャリング、公共安全のための映像フォレンジック、アルゴリズム取引、通信事業者向け5Gネットワークなど、複雑で多様なアプリケーションを構築しています。

これらのアプリケーションの多くはミッションクリティカルであるため、お客さまは、多層型セキュリティの提供に加え、分散クラスターのセキュリティを維持するために継続的な改善を行えることを期待しています。本ブログでは、複数のクラスターにわたってインフラストラクチャ、アプリケーション、データを保護する際の課題を取り上げます。

要約

1. ユーザーや従業員がアプリケーションに安全にアクセスできるようにする方法は、比較的よく理解されています（銀行口座や社内メールにアクセスする際、日常的に行っていることです）。一方、アプリ間またはアプリからデータへのアクセスでは、検証プロセスに人が関与しないため、同じように対応するのは容易ではありません。
2. 異種混在環境（エッジ、複数のクラウド、ネットワークPoP）でアプリとデータを保護するには、多層的な課題への対応が必要でした。それは、アイデンティティ、認証と認可、シークレット、鍵管理です
3. これら4つの課題に対しては、多数のポイントソリューション（各クラウドプロバイダーが提供する複数のサービス、Hashicorp Vault、SPIFFE/Spireなど）を利用できます。しかし、複数のクラウドプロバイダーにまたがって機能し、各サービスをシームレスに統合して容易に利用できる統合ソリューションは存在しません。
4. 開発チームとDevOpsチームには、これらの要素を統合するための専門知識が不足していたため、プラットフォームチームが、これらの機能を使いやすい統合ソリューションとして提供することが不可欠となりました。セキュリティ環境の変化や新たなテクノロジーの登場により、必要な専門知識や、あらゆる変化に対応するための余力がない両チームにとって、対応はさらに困難になっています。
5. 多層型のプラットフォームセキュリティを提供する一環として、3つの重大な課題をまったく新しい方法で解決するソフトウェアコンポーネントを新たに構築しました。具体的には、「亀がどこまでも続く」ような無限後退の問題が生じない汎用IDの安全なブートストラップ、中央保管庫の侵害（宝の山の問題）を懸念することなく保存および配布できるシークレット、保存データのセキュリティ確保を容易にする分散型鍵管理です。

セキュリティ上の課題の背景

前述のとおり、アプリケーションへのユーザーアクセス（たとえば、銀行口座やメールへのアクセス）を保護するという課題は、広く認識されています。しかし、アプリ間またはアプリからデータへのアクセスでは、検証プロセスに人が関与しないため、同様の保護を実現するのはそれほど容易ではありません。

アプリケーションが別のリソースにセキュアにアクセスするには、たとえばオブジェクトストアに保存されたデータへのアクセスや、別のアプリケーションへのAPI呼び出しなどを行う場合、以下の処理が必要です。

1. アイデンティティ — リクエスト元は、必要なリソースにアクセスする際の認証および認可に使用できる、検証可能なアイデンティティを安全に取得する必要があります。また、ピアのアイデンティティの検証に使用できる、必要なトラストアンカーが安全にプロビジョニングされている必要があります。
   
2. 認証 — 特定のリソースにアクセスする際、リクエスト元とリソース所有者は、互いのアイデンティティを安全に検証する必要があります。提示されたアイデンティティに基づいて、相手が主張するアイデンティティを検証するプロセスを認証と呼びます。
   
3. 認可 — リクエスト元の認証後、そのリクエスト元にリソースへのアクセスが許可されているかどうかを確認するプロセスを「認可」と呼びます。

認証プロセスの一環として、リクエスト元のアプリケーションは、PKI証明書、シークレット（パスワードなど）、またはキーを使用して自身のIDを提示できます。IDの提示にシークレットまたはキーを使用する場合は、次の2つの問題に対処する必要があります。

• シークレットやキーをコード内に直接保存しないでください。攻撃経路として容易に悪用される可能性があり、キーが漏えいすると重大な問題につながるおそれがあります。
• シークレットを外部のVaultに保存する場合、そのシークレットを取得するためにどのID（通常は別のシークレット）を使用し、そのIDをどのように保護すればよいでしょうか。

これらのセキュリティ操作（アプリ間の連携に必要な操作）を、信頼性と再現性のある方法で実行することは容易ではありません。その理由は数多くあります。

1. アプリケーションは容易に複製し、複数のインスタンスとして起動できます（マイクロサービスなど）。フォレンジック、監査、オブザーバビリティのために必要となる可能性がある一意のIDを、各複製にどのように割り当てればよいでしょうか。
2. アプリケーションのアイデンティティは、実行環境によって異なります。たとえば、開発環境と本番環境でアプリケーション自体は同じでも、環境ごとに異なるアイデンティティが必要です。
3. アプリケーションが生成されるインフラストラクチャによって、気付かないうちにアイデンティティやシークレット、キーが盗まれないと信頼できる仕組みを、どのように構築すればよいでしょうか？
4. 中央ボールトを攻撃から保護し、そこに保存されているすべてのシークレットとキーを安全に保つにはどうすればよいでしょうか？

そのため、動的な環境全体でインフラストラクチャ、アプリケーション、データを保護することは、非常に困難な課題です。クラウドプロバイダーはこの課題に対応し、これらの問題に対処するための多くのツールを提供していますが、以下の理由から、その統合と保守は容易ではありません。

• 複雑さ — 各クラウドプロバイダーでは、複数のサービスを設定・管理する必要があります。たとえばAWSでは、メタデータサービス、IAMロール、サービスアカウント、RBAC、KMS、Secrets Managerなどです。これらのサービスは、セマンティクス、API、監視のいずれもクラウドプロバイダーごとに大きく異なります。
  
• 相互運用性 — クラウドプロバイダーのサービスを構成して運用可能な状態にしても、いずれのサービスも相互運用性には対応していません。たとえば、GCPで稼働するVMは、GCPサービスアカウントを使用して割り当てられたIDをAWSリソースが認識できないため、AWS内のリソースにアクセスできません。
  
• 異種混在環境 — 環境がパブリッククラウドとプライベートクラウド、複数のパブリッククラウド、さらにはエッジにまで分散している場合、パスワードやキーなどのシークレットを一元的に保存するか、分散して保存するか、またどこに保存するかが課題となります。
  
• 環境固有 — 認証情報のローテーションや失効に対応するソリューションはクラウドプロバイダーごとに大きく異なりますが、エッジクラスターにはそのような仕組みがありません。

多くの企業は単一のクラウドプロバイダーを利用しているため、そのプロバイダーが提供する基本的なセキュリティ機能の管理と強化にリソースを投入すれば十分かもしれません。しかし、F5は異種混在環境（ハイブリッドクラウドおよびエッジ）で運用しているため、これらの問題を解決する新たなソリューションを構築する必要がありました。

分散プラットフォームを保護するソリューション

図1に示すような分散インフラストラクチャ全体に配置される可能性のあるアプリケーション、インフラストラクチャ、データのセキュリティ確保が、私たちのチームに課せられた任務でした。

図1：分散プラットフォームのセキュリティ確保 — アイデンティティ、シークレット、鍵の管理

その結果、プラットフォームチームは、エッジ、あらゆるクラウド、当社のネットワークPoP全体でプラットフォームセキュリティを実現するため、以下の4つの要素を統合した新しいソフトウェアサービスを構築することにしました。

1. アイデンティティ管理 — 暗号技術によって保護され、偽造不可能なPKIベースのアイデンティティを、アプリケーションだけでなく、異種混在環境（複数のクラウド、F5のグローバルPoP、地理的に分散したエッジロケーション）に分散し、複数の環境（開発者用マシン、単体テスト、本番環境など）として稼働するインフラストラクチャにも提供する仕組みについて説明します。
   
2. 認証と認可 — F5のインフラストラクチャは、PKIベースのアイデンティティを利用するマイクロサービスで構築されており、使用する通信プロトコルにかかわらず、すべての通信を相互認証します。また、認可を認証から分離することで、共通の認可エンジンをさまざまな認可判断に使用し、ポリシー構造を統一できるようにしています。
   
3. シークレット管理システム — F5のソフトウェアやお客さまのワークロードでは、TLS証明書、パスワード、トークンなど、さまざまな種類のシークレットが必要です。最も単純な方法は、すべてのシークレットを一元管理する保管庫を採用することですが、この方法には、侵害が発生するとすべてのシークレットが漏えいするという欠点があります。ここでは、簡便性を一部犠牲にすることで、より高いレベルのセキュリティを実現するためにF5が実装した別のアプローチについて説明します。
   
4. Key Management System (KMS) — 分散システムにとってデータセキュリティは極めて重要であり、チームは複数のクラウドプロバイダー間でシームレスに動作するKMSを実現する必要がありました。KMSは、保存データの対称暗号化と復号、CSRFトークンのHMAC、バイナリへのデジタル署名に使用する鍵を管理し、バージョン管理とローテーションを行う必要があります。ここでは、このKMSを使用するセキュリティ上重要な処理と、シークレット管理システムを使用するレイテンシー重視の処理の両方に対応する機能を、どのように提供しているかを説明します。

インフラとアプリの偽造不可能なアイデンティティ

アイデンティティは根本的な課題です。アイデンティティの問題を解決すれば、多くのセキュリティ上の課題により容易に対処できるようになります。ただし、そのためには、アイデンティティとは何かを定義し、信頼できる方法で付与する仕組みを明確にする必要があります。暗号技術の専門家は、何事にも独自の解釈を加えたがるものです。アイデンティティの定義も例外ではありません。

人や物が何者または何であると認識もしくは見なされるかを構成する、偽造不可能かつ暗号学的に検証可能な特性の一意かつ完全な集合であり、信頼できる機関が委任されていないセキュアなプロトコルを介して暗号学的に認証したもの。

要するに、必要なのは、偽造不可能で暗号学的に検証可能なアイデンティティを安全に提供することです。このようなアイデンティティの発行が困難な理由は2つあります。1） アイデンティティのブートストラップ 、2） 信頼の基点

アイデンティティに関連してよく議論されるアプローチとして、SPIFFEとHashicorp Vaultがあります。SPIFFEは、F5のシステムでアイデンティティドキュメント（X.509証明書）として使用できる命名方式です。ただし、この形式は、バイナリデータを含む一部のアイデンティティ属性には適していません。また、Vaultはアイデンティティドキュメントの発行に使用できますが、アイデンティティのブートストラップと信頼の基点に関する課題は解決できません。

1. アイデンティティのブートストラップ — 現実の世界では、人が生まれると出生証明書によってその人のアイデンティティが確立されます。これにより、その人のアイデンティティが論理的にブートストラップされ、この証明書を基に、パスポートや運転免許証など、さらに多くの身分証明書を取得または申請できるようになります。同様に、コンピューティングの世界でも、アプリケーション（またはマイクロサービス）を起動するたびに、アイデンティティをブートストラップする必要があります。実行中のコードが他のサービスとやり取りできるようにするため、アイデンティティの確立は最初に行う必要がある手順の1つです。また、同じアプリケーションコードが複数回、異なる環境（開発者のノートPC、単体テスト、本番環境など）で起動される場合があるため、起動ごとに個別のブートストラップアイデンティティを確立する必要があります。
2. 信頼の基点 — ブートストラップIDの発行は一見単純なプロセスに思えますが、問題は誰がこのIDをプロビジョニングするかです。たとえば現実の世界では、病院が、特定の人物から所定の日時に子どもが生まれたという事実を証明することから、IDのプロビジョニングが始まります。その際、病院が適切な確認を行って出生記録を発行しており、その記録は偽造できないことが前提となります。そのため、出生記録文書は信頼できる情報源（または信頼の基点）として使用できます。同様に、人または自動化されたコードによってアプリケーションが起動される場合、起動されたアプリケーションのIDを検証可能な形で証明できる信頼の基点が必要です。この証明を使用して、そのアプリケーションの後続のID文書を生成できます。

たとえば、AWSでVMを起動すると、ブートストラップIDが付与され、AWSのメタデータサービスが信頼の基点として機能します。AWS独自の暗号鍵で署名されたIDドキュメントは、次のような形式です。

起動されたアプリケーションインスタンスの一意のIDをinstanceIdで示すことはできますが、他のアプリケーションがこの特定のインスタンスとの通信に使用する既知の名前（myserver.acmecorp.com）に関連付ける必要があります。そのため、このAWSブートストラップIDドキュメントだけでは不十分です。ただし、アプリケーション間の通信に使用できる別のIDを発行するために利用できます。

前述のとおり、クラウドプロバイダーやエッジロケーションをまたいでアプリケーションが通信し、情報を共有できるようにするアイデンティティを提供することが不可欠でした（図2）。そのため、これらすべての環境で機能する、アイデンティティのブートストラップと信頼の基点の両方に対応したシステムを構築する必要がありました。

図2：クラウドプロバイダー、ネットワークPoP、エッジ間の通信

マイクロサービスとVMの両方を含むアプリケーションの管理とオーケストレーションにKubernetesを使用しているため、起動する各Podに一意のIDをブートストラップする処理を、KubernetesのPod作成プロセスに組み込む必要がありました。図3は、K8sのWebhookメカニズムを使用してPod作成プロセスに処理を組み込む方法を示しています。Voucherと呼ばれるこのWebhookは、クラスター内で作成されるすべてのPodに、Wingmanというセキュリティサイドカーを挿入し、信頼の基点として使用できる、暗号署名された必要な情報も提供します。また、このWebhookは有効期間の短い署名付きトークンを提供します。Wingmanはこのトークンを使用して、VolterraのSaaSバックエンドにあるIdentity AuthorityにX.509証明書を要求します。

Identity Authorityは、いずれかのK8sクラスターが侵害された場合の「影響範囲」を最小限に抑えられるよう、アイデンティティ発行ルールを適用します。共通のルートCAやK8sクラスターのフェデレーションに依存する他の多くのソリューションでは影響範囲を限定できないため、この点が設計上の意思決定における重要な要素となりました。

図3：各Kubernetesクラスターの信頼の基点

K8s内の特定のPodでは、Podの作成後に属性が変更される場合があります。たとえば、作成後にPodを新しいサービスに関連付けることができます。そのため、新しいサービスに合わせてID証明書を更新する必要がありました。Wingmanは、K8s APIサーバーを追跡するVoucherを継続的に監視し、このような更新を検出します。

このメカニズムにより、F5のワークロードかお客さまのワークロードかを問わず、プラットフォーム全体で稼働するすべてのアプリケーションインスタンスに、一意かつ汎用的なグローバルIDが付与されます。この一意のIDとサイドカー（Wingman）は、分散システム全体のあらゆる通信、アクセス、キー／シークレットを保護するために使用されます。

認証と認可

Podごとに一意のアイデンティティを持たせることは、相互に通信するサービス間で相互認証を実装しやすくするための優れた第一歩です。基盤となるインフラストラクチャは、gRPC、REST、IPSec、BGPなど、さまざまなプロトコルで動作する多数のサービスで構成されています。チームは当初から、プロトコルを問わず、通信するすべての当事者間で相互認証と通信のセキュリティ（暗号化チャネル）を実現することを目標としてきました。そのため、特定のプロトコル群（HTTP/TCPとIPベースなど）に限定されるソリューション（Istioなど）にアイデンティティを結び付けることはできませんでした。

当社のプラットフォームでは、お客さまが任意のワークロードを実行できるため、これらのワークロードではさまざまなプロトコルが使用される可能性があります。そのため、特定のプロトコル群に限定されたアイデンティティを提供することで、プラットフォームがワークロードの機能を制限すべきではありません。代わりに、認証を（Wingmanを介して）アイデンティティから分離することで、さまざまなサービスメッシュテクノロジーとの連携を可能にしています。当社のサービスメッシュのサイドカー／データプレーン（以前のブログで紹介）は、このアイデンティティを使用して、お客さまのワークロードにmTLSを提供します。

当社独自のインフラストラクチャサービスの多くはVolterra Golang Service Framework（今後のブログで解説予定）を使用して開発されていたため、Wingmanから取得したアイデンティティを利用するロジックをフレームワークに直接組み込むことにしました。これにより、開発者はmTLS用のサービスメッシュサイドカーに依存することなく、サービス間通信を標準で保護できるようになりました。

相互認証されたセキュアなチャネルを確立した後の次の論理的なステップは、認可です。認可とは、リクエストの受信側（サーバー）が、識別された呼び出し元（クライアント）からのリクエストを許可するかどうかを判断するプロセスです。リクエストを許可しない理由には、クォータ制限や権限など、さまざまなものがあります。こうした理由やそのしきい値は動的に変化するため、認可ルール（ポリシー）をハードコードする方法は、当社のプラットフォームには適していませんでした。

Open Policy Agentのエンジンを出発点として採用し、Wingmanサイドカー内に認可用のラッパーを構築しました。このラッパーコードは、関連するポリシーを動的に取得し、迅速に評価できるよう、すぐに利用可能な状態に保ちます。認証と同様に、認可エンジンをアイデンティティ（および認証）から分離したことで、認証直後だけでなく、ビジネスロジックの深い階層を含むリクエスト処理の複数の段階で認可ポリシーを適用できるようになりました。

Wingmanは、お客さまのワークロードを含むすべてのワークロードに組み込まれているため、当社のプラットフォームでは認可エンジンを組み込み機能として提供しています。Open Policy Agent（OPA）はRegoという強力な言語を基盤としていますが、その複雑さを開発者やお客さまから隠蔽したいと考えました。当社のプラットフォーム上のすべてのポリシーは、より理解しやすく直感的なポリシー構造でも定義できます。そのため、ユーザー（DevOps担当者）はRegoを習得する必要がなく、ミスを回避できます。認証設定と同様に、Golang Service Frameworkが認可時にWingmanを自動的に呼び出すようにしてWingmanの認可エンジンと連携させることで、認可の複雑さを開発者から隠蔽しました。

認証にはWingmanが発行する一意のIDを、認可にはWingman内のプログラム可能なポリシーエンジンを使用することで、mTLSを用いて通信を保護し、堅牢かつプログラム可能なポリシーに基づいてすべてのアクセスを制御できます。

一元管理型Vaultを使用しないシークレット管理

エンジニアは日々、誤ってキーやパスワードをコードに保存してしまい、それらが何らかの経路で公開コードリポジトリやアーティファクトリポジトリに流出することがあります。シークレットの管理は難しく、使いやすいツールキットと明確に定義されたプロセスがなければ、開発者は最も手軽な方法を選びがちです。そのため、創業当初から、当社のプラットフォームセキュリティ（ネットワークセキュリティやアプリケーションセキュリティとは異なります）チームは、開発者が「シークレットはどこに保存すればよいのか。ソースコードか、アーティファクトか、それとも……？」と悩まずに済むようにすることを使命としてきました。

プラットフォームの構築を開始した当時、シークレット管理に利用できた一般的な2つのアプローチを評価しましたが、どちらにもいくつかの欠点がありました。

1. Kubernetes Secrets — Kubernetesを使用しており、Kubernetesにはシークレット管理機能が備わっていますが、いくつかの理由から、特に有用とはいえません。シークレットは保存時に暗号化されず、ポリシー構造も包括的ではなく、マルチクラスター環境にも対応していません。
   
2. 一元管理型Vault（例：HashicorpまたはCyberark Vault） — 別のアプローチとして、シークレットを一元的に保存し、認可された要求元に提供するVaultを使用する方法も考えられます。シークレットは、Vaultの暗号化ストレージに使用される単一の暗号鍵によって保護されます。ただし、このアプローチでは、シークレット管理システムが平文のシークレットにアクセスできるため（暗号化された形式で保存されている場合でも）、システムが侵害されると、すべてのシークレットが漏えいする可能性があります。

当社のサービスはSaaSであるため、システムが侵害されてもお客さまのシークレットが漏えいしないよう、より堅牢な保護方法を考案する必要がありました。

その結果、図4に示すように、セキュリティサイドカーであるWingmanと連携して動作する、Volterra Blindfold（商標）と呼ぶ新しい技術を実装することにしました。この手法では、シークレットの所有者がシークレットをロック（暗号化）し、意図しないいかなる相手（復号サーバーを含む）にも平文で開示されないようにできます。シークレットは中央の復号サーバーに保存されることすらなく、この設計により、いくつかの点でサーバー設計が大幅に簡素化されます。

図4：シークレット管理のためのBlindfoldとWingman

完全にオフラインの環境でシークレット（S）を暗号化できるblindfoldツールを提供しています。暗号化したシークレットは配布可能です。たとえば、ワークロードとともに保存し、レジストリにアップロードできます。これが完了したら、次の手順を実行する必要があります。

これにより、集中管理型のコントロールプレーンが平文のシークレット（S）にアクセスすることはなく、シークレットを利用できるのも、アクセス中のPodのランタイムメモリ内に限られます。さらに、アクセスポリシーを適用して、シークレットにアクセスできる主体を定義できます。ポリシーは、アプリケーション名、場所、コンプライアンスレベルなどのID属性に基づいて定義できます。これにより、ワークロードから任意の複雑なサブセットを切り分け、きめ細かなアクセス制御を実現できます。ポリシーは、暗号化、ブラインディング、復号、アンブラインディングの各プロセスに暗号学的に組み込まれているため、ポリシーの意図を覆すことは計算上困難です。

独自のBlindfold技術で各シークレットをロックし、ポリシーと偽造不可能なアイデンティティに基づいてWingmanで各シークレットをアンシールすることで、既存のソリューションが抱える問題を克服し、中央に集約された貴重なシークレットの侵害を懸念することなく、分散環境でシークレット管理を実現できます。

分散システム向け鍵管理

シークレット管理と鍵管理は、同じ問題を指す2つの異なる呼び方のように聞こえるかもしれません。しかし、誰に尋ねるか、またソリューションをどのように実装するかによって、両者にはわずかな違いがあります。この違いは、実際には重要です。

シークレットとは、秘密として扱われ、権限のない第三者が利用できないようにする必要があるあらゆる情報を指します。暗号鍵は、ある意味ではシークレットの一種です。一方、鍵管理とは一般に、機密性の高い暗号鍵マテリアルを安全に保管し、その使用を制御するシステムを指します。鍵管理システムが権限のある第三者に鍵の生バイトを渡す場合もあるため、シークレット管理システムと混同されることがあります。しかし、ほとんどの場合、鍵管理システムは鍵マテリアルの生バイトを実際に渡すのではなく、権限のある要求元に代わって処理を実行し、その処理結果のみを返します。また、多くの鍵管理システムでは、鍵マテリアルをハードウェアストレージ（HSMなど）に格納することで、鍵が平文のままソフトウェアに公開されないようにしています。

分散環境では、単一のクラウドプロバイダーを利用する場合でも、暗号鍵の管理、同期、ローテーションは非常に困難です。現在のソリューションはエラーが発生しやすく、非効率で、安全性に欠ける場合さえあります。たとえば、現在3つのAWSリージョンを利用し、すべてのリージョンで同じ暗号鍵を使用するには、鍵を手動で同期し、ローテーションする必要があります。複数のクラウドプロバイダー（パブリック、プライベート、またはその両方）にまたがる環境では、この問題はさらに深刻になります。こうした作業をすべて完了しても、アプリケーション所有者はKMSの機能を利用するために複雑なコードを記述しなければなりません。

当社のプラットフォームでは、Wingmanサイドカーが複雑な処理をすべて担い、暗号化、復号、HMAC、HMAC検証、デジタル署名、署名検証、鍵の取得（許可されている場合）などの鍵管理リクエストを行うためのシンプルなインターフェースをアプリケーションに提供します。これにより、鍵管理の複雑さがアプリケーションから隠蔽され、当社のインフラストラクチャサービスとお客さまのワークロードのどちらでも、鍵管理が容易になります。

次の図（図5）は、VolterraのKMSが複数の環境にわたってどのように機能し、ワークロードによる鍵管理と暗号処理をWingmanサイドカーにオフロードできるよう支援するかを示しています。構成によっては、Wingmanはアプリケーションに意識させることなく、鍵をキャッシュし、そのキャッシュを更新できます。これを可能にするのが、前述した汎用的で偽造不可能なアイデンティティです。各Podには、その場所にかかわらずグローバルに一意のアイデンティティが付与されるため、Volterra KMSシステムは、暗号鍵や、暗号化、復号、HMAC、HMAC検証、デジタル署名、署名検証などの特定の処理に対して、アクセス・ポリシーを極めて正確に適用できます。

図5：SaaSバックエンドのWingmanとKMSサーバー

すべてのキーはVolterraのSaaSバックエンドで管理されるため、異種環境で実行されるワークロードがキーの同期、ローテーション、失効などに対応する必要はありません。保存データのセキュリティに必要なのは、シンプルなWingman APIだけです。

F5のプラットフォームセキュリティソリューションがもたらすメリット

多層型のプラットフォームセキュリティを活用することで、3つの重大な課題に対し、まったく新しい方法で包括的なソリューションを提供できるようになりました。F5のシステムは、「無限後退」の問題が生じない汎用IDを安全にブートストラップし、宝の山問題を懸念することなく保存・配布できるシークレットを管理するとともに、分散環境における保存データのセキュリティ確保を容易にする鍵管理を提供できます。これにより、社内チームとお客さまに次のようなメリットがもたらされました。

1. セキュリティとコンプライアンス — 偽造不可能なユニバーサルID、Blindfold、およびプラットフォームに完全に統合され自動管理されるセキュリティサイドカー（Wingman）により、すべての通信を保護し、すべてのアクセスを認可するとともに、分散システム全体の鍵とシークレットを管理します。こうした進歩により、より堅牢なセキュリティソリューションを提供できるようになり、F5とお客さまがコンプライアンス要件に対応しやすくなりました。
   
2. 生産性の向上 — DevOpsプロセスとサービスフレームワークに統合されたセキュリティソリューションを使用することで、開発者やDevOpsチームは、アプリケーションとデータのセキュリティに関する重要な要素を気にすることなく、成果物に集中できます。
   
3. 継続的な進化 — 変化し続けるセキュリティ環境と新しいテクノロジーに対応して、Blindfold、Wingman、Golang Service Frameworkも継続的に進化します。その結果、アプリケーションロジックを変更することなく、プラットフォームによって新機能が自動的に展開されます。

次回へ続く……

このブログシリーズでは、パブリッククラウド上の多数のアプリケーションクラスター、プライベートネットワークのPoP、エッジサイトで構成される、グローバルに分散したSaaSサービスの構築と運用に必要だったさまざまな取り組みをご紹介します。次回のテーマは「アプリケーションとネットワークのセキュリティ」です……

この機能をオープンソースプロジェクトとしてより広いコミュニティに提供するため、ご協力いただけるボランティアの開発者およびソリューションアーキテクトを若干名募集しています。楽しみながらプロジェクトに参加してみたい方は、asingla@volterra.ioまで直接ご連絡ください。

著者について

Ankur Singla

Ankur Singlaのその他のブログ記事