ブログ

分散プラットフォームのセキュリティ保護 - ID、シークレット、キー管理

アンカー・シングラ サムネイル
アンクル・シングラ
2019年12月11日公開

これは、 SaaSサービスの構築と運用に必要だったさまざまな側面を取り上げているブログ シリーズの 3 番目のブログです。 

  1. 分散Kubernetes PaaSのコントロールプレーン
  2. 分散アプリケーション向けのグローバル サービス メッシュ
  3. 分散インフラストラクチャ、アプリ、データのプラットフォーム セキュリティ 
  4. 分散クラスタのアプリケーションとネットワークのセキュリティ
  5. グローバルに分散されたプラットフォーム全体の可観測性
  6. グローバルに分散されたプラットフォームの運用と SRE 
  7. 分散マイクロサービス向けの Golang サービス フレームワーク

私の最初のブログでは、分散クラウド用の新しいプラットフォームを構築することになったニーズについての背景を説明しました。 このプラットフォームを使用して、お客様はスマート製造、公共安全のためのビデオフォレンジック、アルゴリズム取引、通信事業者の 5G ネットワークなど、複雑で多様な一連のapplicationsを構築します。

これらのapplicationsの多くはミッションクリティカルであるため、お客様は当社が多層セキュリティを提供するだけでなく、分散クラスターを安全に保つために継続的に改善する能力も備えていることを期待しています。 このブログでは、複数のクラスターにわたるインフラストラクチャ、applications、およびデータのセキュリティ保護の課題について説明します。

TL;DR (要約)

  1. ユーザーや従業員にapplicationsへの安全なアクセスを提供する方法は比較的よく理解されていますが (私たちは毎日、銀行口座や会社のメールにアクセスするときにこれを行っています)、検証プロセスに人間が関与していないため、アプリ間またはアプリからデータへのアクセスについては同じことを行うのはそれほど簡単ではありません。
  2. 異機種環境（エッジ、複数のクラウド、ネットワーク PoP）でアプリとデータを保護するには、アイデンティティ、認証と承認、シークレット、キー管理といった多層的な問題を解決する必要がありました。
  3. これら 4 つの問題に対しては、多くのポイント ソリューション (個々のクラウド プロバイダーからの複数のサービス、Hashicorp Vault、SPIFFE/Spire など) が利用可能ですが、クラウド プロバイダー間で機能したり、各サービスをシームレスに組み合わせて使いやすくする統合ソリューションは存在しません。
  4. 開発者チームと DevOps チームにはこれらの要素を統合する方法に関する専門知識が不足していたため、プラットフォーム チームがこれらの機能を使いやすい統合ソリューションとして提供することが不可欠になりました。 セキュリティ環境の変化と新しいテクノロジーにより、すべての変化に対応するのに必要な専門知識や帯域幅がないため、これらのチームにとってさらに困難になっています。
  5. 多層プラットフォーム セキュリティを実現する一環として、まったく新しい方法で 3 つの重要な問題を解決する新しいソフトウェア コンポーネントを構築しました。その 3 つの問題は、「亀がずっと下まで続く」問題に悩まされないユニバーサル ID の安全なブートストラップ、中央の金庫の侵害を心配することなく保管および配布できるシークレット (金鉱問題)、保存データのセキュリティを容易にする分散キー管理です。

安全保障問題の背景

上で述べたように、applicationsへのユーザー アクセス (たとえば、銀行口座や電子メールへのアクセス) を保護するという問題はよく理解されています。 ただし、検証プロセスに人間が関与しないため、アプリ間またはアプリからデータへのアクセスで同じことを行うのはそれほど簡単ではありません。

applicationが別のリソースに安全にアクセスするには (たとえば、オブジェクト ストアに保存されたデータや、別のapplicationへの API 呼び出しなど)、次のことを行う必要があります。 

  1. ID — 要求者は、必要なリソースにアクセスする際に、認証と承認の目的で使用できる検証可能な ID を安全に取得する必要があります。 要求者には、ピアの ID を確認するために使用できる必要な信頼アンカーが安全にプロビジョニングされる必要もあります。 
     
  2. 認証— 特定のリソースにアクセスするプロセスでは、要求者とリソース所有者がお互いの ID を安全に検証する必要があります。 ピアが主張する ID を提示された ID と照合するプロセスを認証と呼びます。 
     
  3. 承認— 要求者が認証されると、リソースへのアクセスが許可されているかどうかを確認するプロセスは承認と呼ばれます。

認証プロセスの一環として、要求側applicationは、PKI 証明書または秘密 (パスワードなど) やキーの形式で ID を提示できます。 シークレットまたはキーを ID として使用する場合、対処する必要がある問題が 2 つあります。 

  • 秘密と鍵はコード内に直接保存しないでください。これは簡単な攻撃ベクトルであり、鍵が漏洩すると大きな問題になる可能性があるためです。 
  • シークレットが外部の金庫に保存されている場合、シークレットを取得するためにどの ID (通常は別のシークレット) を使用する必要がありますか。また、シークレットを取得するためにこの ID をどのように保護しますか。

これらのセキュリティ操作 (アプリ間のやり取り) を信頼性が高く繰り返し実行することは、簡単な問題ではありません。 これが簡単ではない理由はたくさんあります: 

  1. applicationsは簡単に複製および生成できます (例: マイクロサービス)。 フォレンジック、監査、または観測の目的で必要になる可能性のある各クローンに対して、一意の ID を割り当てるにはどうすればよいでしょうか? 
  2. applicationID は、実行されている環境によって異なります。 たとえば、開発環境と本番環境ではapplicationは同じですが、環境ごとに異なる ID が必要です。 
  3. applicationが生成されるインフラストラクチャが、気付かれずに ID や秘密やキーを盗まないという信頼をどのように構築すればよいでしょうか? 
  4. 中央の金庫を攻撃から保護し、この金庫に保存されているすべての秘密と鍵を保護するにはどうすればよいでしょうか?

その結果、動的な環境全体でインフラストラクチャ、applications、データを保護することは非常に困難な問題となります。 クラウド プロバイダーはこの課題に立ち向かい、これらの問題に対処するための多くのツールを提供していますが、次の理由により、これらを統合して維持することは容易ではありません。 

  • 複雑さ- 各クラウド プロバイダでは、顧客が複数のサービスを構成および管理する必要があります。 たとえば、AWS では、メタデータ サービス、IAM ロール、サービス アカウント、RBAC、KMS、シークレット マネージャーなどがあります。 これらの各サービスは、セマンティクス、API、監視のいずれにおいても、クラウド プロバイダごとに大きく異なります。 
     
  • 相互運用性-クラウド プロバイダサービスが構成され、運用化された場合でも、相互運用性は実現されません。 たとえば、GCP で実行されている VM は、GCP サービス アカウントを使用して割り当てられた ID が AWS リソースで認識されないため、AWS のリソースにアクセスできません。 
     
  • 異機種環境— 環境がパブリック クラウドとプライベート クラウド、または複数のパブリック クラウドにまたがって分散している場合、あるいはさらに悪いことにエッジに分散している場合、パスワードやキーなどの秘密を集中的または分散的に、どこにどのように保存するかが課題になります。 
     
  • 環境固有- 資格情報のローテーションや失効のソリューションはクラウド プロバイダーごとに大きく異なりますが、エッジ クラスターにはそのようなソリューションは存在しません。

多くの企業は単一のクラウド プロバイダであり、そのプロバイダーのセキュリティ プリミティブの管理と強化にリソースを投資するだけで十分かもしれませんが、当社は異種環境 (ハイブリッド クラウドとエッジ) で運用しており、これらの問題を解決するために新しいソリューションを構築する必要がありました。

分散プラットフォームのセキュリティ保護ソリューション

私たちのチームには、図 1 に示すように、分散インフラストラクチャ全体に存在する可能性のあるapplications、インフラストラクチャ、およびデータのセキュリティを提供するという任務がありました。

キー管理-01
図1: 分散プラットフォームのセキュリティ保護 - アイデンティティ、シークレット、キー管理

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

  1. アイデンティティ管理— 暗号的に安全で偽造不可能な PKI ベースのアイデンティティを、applicationsだけでなく、異種環境 (複数のクラウド、グローバル PoP、地理的に分散したエッジ ロケーション) に分散され、複数の環境 (開発者マシン、ユニット テスト、本番環境など) として動作するインフラストラクチャにも配信する方法について説明します。 
     
  2. 認証と承認— 当社のインフラストラクチャは、PKI ベースの ID を活用し、使用されている通信プロトコルに関係なくすべての通信を相互に認証するマイクロサービス上に構築されています。 また、認証から認可を分離することで、共通の認可エンジンをさまざまな認可決定に使用できるようになり、ポリシー構造を統一できるようになりました。 
     
  3. シークレット管理システム— 顧客のワークロードだけでなく、当社のソフトウェアに必要なシークレットには多くの種類があります (TLS 証明書、パスワード、トークンなど)。 最も簡単な方法は、すべての秘密が保管される集中型の金庫を導入することだったかもしれませんが、このアプローチには、侵害されるとすべての秘密が明らかになるという欠点がありました。 ある程度のシンプルさを犠牲にして、より高いレベルのセキュリティを実現するために実装した別のアプローチについて説明します。 
     
  4. キー管理システム (KMS) —データ セキュリティは当社の分散システムにとって非常に重要であり、チームはクラウド プロバイダー間でシームレスに動作する KMS を提供する必要がありました。 KMS は、保存データの対称型暗号化と復号化、CSRF トークンの HMAC、バイナリのデジタル署名に使用されるキーを管理、バージョン管理、およびローテーションする必要があります。 この KMS を使用したセキュリティ重視の操作と、シークレット管理システムを使用したレイテンシ重視の操作の両方に機能を提供する方法について説明します。

インフラとアプリの偽造不可能な ID

アイデンティティは根本的な問題であり、アイデンティティの問題が解決されれば、多くのセキュリティ上の課題に簡単に対処できるようになります。 しかし、アイデンティティの問題を解決するには、アイデンティティが何を意味するのか、そして信頼できる方法でアイデンティティを発行するにはどうすればよいのかを定義する必要があります。 暗号マニアはあらゆることに独自の解釈を加えるのが好きで、アイデンティティの定義も例外ではありません。

人物または物が何であるか、または何であるかと見なされるかを構成する、信頼できる機関によって委任されていない安全なプロトコルを介して暗号で認証された、偽造不可能で暗号で検証可能な一意の特性のセット全体。

本質的に必要なのは、安全に配信される、偽造不可能で暗号的に検証可能な ID です。 このような ID を発行するのは、次の 2 つの理由で困難です。 1)アイデンティティのブートストラップと2)信頼のルート

アイデンティティに関連してよく議論されるアプローチがいくつかあります。SPIFFE と Hashicorp Vault です。 SPIFFE は、当社のシステムで ID ドキュメント (X.509 証明書) として使用できる命名スキームですが、その形式はバイナリ データを含む一部の ID 属性には適していないことを明確にしておきます。 Vault は ID 文書を発行するために使用できますが、ID のブートストラップと信頼のルートの問題の課題は解決されません。

  1. アイデンティティのブートストラッピング— 現実世界では、人が生まれると、その人のアイデンティティは出生証明書によって確立されます。 これにより、個人の ID が論理的にブートストラップされ、この証明書を使用して、個人はパスポート、運転免許証などの追加の ID 証明書を取得/要求できるようになります。 同様に、コンピューティングの世界では、application(またはマイクロサービス) を起動するたびに、ID をブートストラップする必要があります。 ID の確立は、実行中のコードが他のサービスと対話できるようにするために実行する必要がある最初のステップの 1 つです。 さらに、同じapplicationコードが複数回、異なる環境 (開発者のラップトップ、ユニット テスト、本番) で起動される可能性があるため、これらの起動ごとに個別のブートストラップ ID を確立する必要もあります。
  2. 信頼のルート— ブートストラップ ID の発行は簡単なプロセスのように見えるかもしれませんが、問題は誰がこの ID をプロビジョニングするかということです。 たとえば、現実世界では、アイデンティティの提供は、病院が特定の人物に特定の日付と時間に子供が生まれたという事実を主張することから始まり、病院が出生記録を適切なチェックで作成しており、偽造できないという仮定が立てられます。 その結果、出生記録文書は真実の源（または信頼のルート）として使用することができます。 同様に、applicationが人間または自動コードによって起動される場合、起動されたapplicationの ID を検証可能に主張できる信頼のルートが必要です。 このアサーションは、applicationの後続の ID ドキュメントを生成するために使用できます。

たとえば、VM が AWS で起動されると、ブートストラップ ID が提供され、AWS のメタデータ サービスが信頼のルートとして機能します。 ID ドキュメント (AWS が独自の暗号化キーを使用して署名したもの) は次のようになります。

生コード 1

instanceId は起動されたapplicationインスタンスの一意の ID を示す場合がありますが、他のapplicationsがこの特定のインスタンスと通信するために使用する既知の名前 (myserver.acmecorp.com) にチェーンされる必要があります。 その結果、この AWS ブートストラップ ID ドキュメントだけでは不十分ですが、applicationsが別のapplicationと通信するために使用できる別の ID を発行するために使用できます。

前述したように、applicationsがクラウド プロバイダーやエッジ ロケーション間で通信し、情報を共有できるようにする ID を提供することが重要でした (図 2)。 つまり、これらすべての環境で機能する ID ブートストラップと信頼のルートの両方のためのシステムを構築する必要がありました。

キー管理-02
図2: クラウドプロバイダー、ネットワーク PoP、エッジ間の通信

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

アイデンティティ機関は、K8s クラスターの 1 つが侵害された場合に「爆発半径」を最小限に抑える方法で、アイデンティティを作成するルールを適用します。 共通のルート CA または K8s クラスターのフェデレーションに依存する他の多くのソリューションでは、爆発半径を制限できません。これは、私たちの設計上の決定における主要な入力でした。

キー管理-03
図3: 各Kubernetesクラスタの信頼のルート

K8s の特定の Pod の場合、Pod の作成後に属性が変更される場合があります。たとえば、Pod は作成後に新しいサービスに接続できます。 つまり、ID 証明書を新しいサービスに合わせて更新する必要がありました。 Wingman は、K8s API サーバーの更新を追跡するバウチャーを継続的に監視します。

このメカニズムは、当社独自のワークロードであるか顧客のワークロードであるかに関係なく、当社のプラットフォーム上で実行されるすべてのapplicationインスタンスに、一意かつユニバーサルなグローバル ID を提供します。 この固有の ID とサイドカー (Wingman) は、分散システム全体のすべての通信、アクセス、およびキー/シークレットを保護するために使用されます。

認証と承認

Pod ごとに一意の ID を持つことは、通信するサービス間で相互認証を実装するタスクを容易にするため、素晴らしいスタートとなります。 私たちの基盤となるインフラストラクチャは、gRPC、REST、IPSec、BGP などのさまざまなプロトコルで実行されるさまざまなサービスで構成されています。 チームは当初から、プロトコルに関係なく、すべての通信当事者間の相互認証と通信セキュリティ (暗号化チャネル) を実現するという目標を設定しました。 これはまた、特定のプロトコル セット (HTTP/TCP と HTTPS など) に限定されるソリューション (Istio など) に ID を結び付けることができないことも意味します。 IP ベース)。

当社のプラットフォームでは、お客様が選択したワークロードを実行することもできるため、これらのワークロードはさまざまなプロトコルを実行できると予想しており、プラットフォームは特定のプロトコル セットに限定された ID を提供することでワークロードの能力を制限すべきではありません。 代わりに、認証は ID から分離され (Wingman 経由)、さまざまなサービス メッシュ テクノロジへの接続が可能になります。 当社のサービス メッシュ サイドカー/データプレーン (以前のブログで説明) は、この ID を使用して顧客のワークロードに mTLS を提供します。

私たち自身のインフラストラクチャ サービスの多くは Volterra Golang サービス フレームワーク (今後のブログで説明します) を使用して記述されていたため、(Wingman からの) ID を使用するロジックをフレームワークに直接組み込むことにしました。 これにより、開発者は mTLS のサービス メッシュ サイドカーに依存せずに、サービス間通信をすぐに保護できるようになりました。

相互認証された安全なチャネルを実現した後の次の論理的なステップは承認です。これは、要求の受信者 (サーバー) が、識別された発信者 (クライアント) からの要求を許可するかどうかを決定するプロセスです。 リクエストを許可しない理由は、割り当て制限、権限など、多数考えられます。 これらの理由とそのしきい値は動的に変化するため、承認のためのハードコードされた一連のルール (ポリシー) は、当社のプラットフォームでは実現不可能でした。

私たちは、Open Policy Agent のエンジンを出発点として使い、Wingman サイドカー内で認証用のラッパーを構築することにしました。 このラッパー コードは、関連するポリシーを動的に取得し、高速評価のためにそれらをホットな状態に保ちます。 認証と同様に、承認エンジンを ID (および認証) から分離することで、認証直後だけでなく、ビジネス ロジックの深いところまで含めたリクエスト処理の複数の段階で承認ポリシーを適用できるようになりました。

Wingman は顧客のワークロードを含むすべてのワークロードに挿入されるため、当社のプラットフォームは組み込み機能として認証エンジンを提供します。 Open Policy Agent (OPA) は Rego と呼ばれる強力な言語に基づいて構築されていますが、その複雑さを開発者や顧客から隠したいと考えていました。 当社のプラットフォーム上のすべてのポリシーは、はるかに理解しやすく直感的なポリシー構造を使用して定義できるため、ユーザー (DevOps) が Rego を学習する必要がなく、間違いを回避できます。 認証構成と同様に、Golang サービス フレームワークは、認証のために Wingman を自動的に呼び出し、開発者から認証の複雑さを隠すことで、Wingman の認証エンジンに接続されました。

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

集中管理された金庫なしの秘密管理

毎日、エンジニアはコード内にキーやパスワードを保存することで不注意なミスを犯し、それが何らかの形でパブリック コードやアーティファクト リポジトリに流れてしまいます。 秘密の管理は難しく、使いやすいツールキットと明確に定義されたプロセスがなければ、開発者は最短の道をたどることになります。 その結果、当社の設立当初から、プラットフォーム セキュリティ (ネットワーク セキュリティやアプリ セキュリティとは異なります) チームの使命は、開発者が「ソース コードや成果物などの秘密はどこに保存すればよいのか」といった質問をしなくても済むようにすることでした。

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

  1. Kubernetes シークレット— Kubernetes にはシークレット ソリューションが付属していますが、シークレットは保存時に暗号化されず、ポリシー構造は包括的ではなく、マルチクラスター シナリオを解決しないなど、さまざまな理由から特に有用ではありません。
     
  2. 集中型 Vault (例: Hashicorp または Cyberark Vault) — 別のアプローチとしては、秘密が集中的に保管され、承認された要求者に渡される Vault を使用することが考えられます。 秘密は、Vault の暗号化されたストレージに使用される単一の暗号化キーによって保護されます。 しかし、このアプローチの問題点は、秘密管理システムが暗号化された形式で保存されている場合でも、平文の秘密にアクセスでき、システムが侵害されるとすべての秘密が明らかになる可能性があることです。

私たちの場合、SaaS サービスであるため、いかなる侵害によっても顧客の秘密が漏洩しないように、顧客の秘密を保護するためのより堅牢な方法を考え出す必要がありました。

その結果、私たちは Volterra Blindfold (商標) と呼ぶ新しい手法を実装することにしました。これは、図 4 に示すように、セキュリティ サイドカーである Wingman と連携して機能します。 このアプローチにより、秘密の所有者は、秘密が望ましくない第三者（復号化サーバーを含む）に平文で公開されないように、秘密をロック（暗号化）することができます。 秘密は中央の復号化サーバーに保存されることもなく、この設計により、ある意味ではサーバー設計が大幅に簡素化されます。

キー管理-04
図4: 秘密管理のための目隠しとウィングマン

私たちは、完全にオフラインの設定で使用できる目隠しツールをユーザーに提供します。このツールは、シークレット (S) を暗号化して配布することができます。たとえば、シークレット自体をワークロードとともに保存し、レジストリにアップロードすることができます。 これを達成したら、次の手順を実行する必要があります。

これにより、集中型コントロール プレーンがクリア テキスト (S) のシークレットにアクセスすることはなくなり、シークレットはアクセス期間中、ポッドのランタイム メモリでのみ使用できるようになります。 さらに、アクセス ポリシーを適用して、誰がシークレットにアクセスできるのか定義することもできます。 ポリシーは、application名、場所、コンプライアンス レベルなどの ID 属性に基づいて定義できます。 この方法では、ワークロードの複雑なサブセットを切り分け、正確なアクセス制御を実現できます。 このポリシーは、暗号化、ブラインド化、復号化、およびブラインド解除のプロセスに暗号的に組み入れられており、ポリシーの意図を無効にすることは計算上不可能です。

当社独自の Blindfold 技術を使用して各秘密をロックし、Wingman を使用してポリシーと偽造不可能な ID に基づいて各秘密を開封することで、既存のソリューションの問題を克服し、中央の金鉱の侵害を心配することなく、分散環境で秘密管理を実現できます。

分散システムの鍵管理

シークレットとキー管理は同じ問題に対する 2 つの異なる名前のように聞こえるかもしれませんが、誰に尋ねるか、またソリューションをどのように実装するかに応じて、この 2 つの間には微妙な (しかし実際には重要な) 違いがあります。

秘密とは、秘密にされ、権限のない者には公開されないはずの情報を指します。 ある意味では、暗号鍵は秘密の特殊なケースです。 一方、キー管理とは、一般的に、機密性の高い暗号化キー素材を安全に保管し、その素材の使用を制御するシステムを指します。 場合によっては、キー管理システムがキーの生のバイトを許可された当事者に渡すことがあり、そのため秘密管理システムと混同される可能性があります。 ただし、ほとんどの場合、キー管理システムは実際にはキー マテリアルの生のバイトを配布せず、代わりに承認された要求者に対して操作を実行し、操作の出力のみを送信します。 多くのキー管理システムは、キーがソフトウェアに平文で公開されることがないように、キーマテリアル用のハードウェア ストレージ (HSM など) によってバックアップされています。

分散環境では、単一のクラウド プロバイダであっても、暗号キーの管理、同期、ローテーションの問題は非常に困難であり、現在のソリューションはエラーが発生しやすく、非効率的で、安全でもありません。 たとえば、現在 3 つの AWS リージョンを使用しており、3 つのリージョンすべてで同じ暗号キーを使用したい場合は、キーを手動で同期してローテーションする必要があります。 環境が複数のクラウド プロバイダー (パブリックおよび/またはプライベート) にまたがる場合、問題はさらに悪化します。 これらすべてを実行した後でも、application所有者はこれらの KMS 機能を利用するために複雑なコードを記述する必要があります。

当社のプラットフォームは、Wingman サイドカーにすべての面倒なapplicationを実行させ、暗号化、復号化、HMAC、HMAC 検証、デジタル署名、署名検証、キーの取得 (許可されている場合) などのキー管理要求を行うためのシンプルなインターフェイスをapplicationに提供することで、キー管理の複雑さをすべてアプリケーションから隠します。 これにより、当社独自のインフラストラクチャ サービスだけでなく顧客のワークロードでも、キー管理がまったく難しくなくなります。

次の図 (図 5) は、Volterra の KMS が環境間でどのように機能し、ワークロードがキー管理と暗号化操作を Wingman サイドカーにオフロードするのに役立つかを示しています。 設定に応じて、Wingman はキーをキャッシュし、applicationが認識することなくキャッシュを更新できます。 ここでの実現要因は、先ほど紹介した普遍的で偽造不可能なアイデンティティです。 各ポッドは、その場所に関係なく、グローバルに一意の ID を取得するため、Volterra KMS システムは、暗号キーや、暗号化、復号化、HMAC、HMAC 検証、デジタル署名、署名検証などの特定の操作にアクセス ポリシーを非常に正確に適用することが容易になります。

キー管理-05
図5: SaaSバックエンドのWingmanとKMSサーバー

すべてのキーは Volterra の SaaS バックエンドを介して管理されるため、異機種環境で実行されるワークロードはキーの同期、ローテーション、失効などを処理する必要はなく、保存データのセキュリティ ニーズすべてに対応するシンプルな Wingman API を知っておくだけで済みます。

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

多層プラットフォーム セキュリティを使用することで、まったく新しい方法で 3 つの重大な問題に対する包括的なソリューションを提供できるようになりました。 当社のシステムは、「タートルズ・オール・ザ・ウェイ・ダウン」の問題に悩まされることのないユニバーサル ID を安全にブートストラップし、金鉱問題を心配することなく保存および配布できる秘密を管理し、分散環境における保存データのセキュリティを容易にするキー管理を提供することができます。 これにより、社内チームと顧客に次のようなメリットがもたらされました。 

  1. セキュリティとコンプライアンス- 偽造不可能なユニバーサル ID、Blindfold、およびセキュリティ サイドカー (Wingman) はプラットフォームによって完全に統合され、自動的に管理され、すべての通信を保護し、すべてのアクセスを承認し、分散システム全体でキー/シークレットを管理します。 これらの進歩を活用することで、当社とお客様のコンプライアンス遵守能力を向上させる、より堅牢なセキュリティ ソリューションを提供できるようになりました。 
     
  2. 生産性の向上- DevOps プロセスとサービス フレームワークに統合されたセキュリティ ソリューションを使用すると、開発者と DevOps チームは、applicationとデータ セキュリティの重要な側面を心配することなく、成果物に集中できます。 
     
  3. 継続的な進化— セキュリティ環境の進化と新しいテクノロジーにより、Blindfold、Wingman、Golang サービス フレームワークは継続的に進化します。 その結果、applicationロジックを変更することなく、プラットフォームによって新しい機能が自動的に展開されます。

つづく…

このブログ シリーズでは、パブリック クラウド、プライベート ネットワーク PoP、エッジ サイトにある多数のapplicationクラスターを使用して、グローバルに分散された SaaS サービスを構築および運用するために必要なさまざまな側面について説明します。 次はapplicationとネットワークのセキュリティです…

私たちは、この機能をオープンソース プロジェクトとしてより広範なコミュニティに提供するために協力してくれるボランティアの開発者とソリューション アーキテクトを数名募集しています。何か楽しいことに参加することに興味がある場合は、 asingla@volterra.ioまで直接ご連絡ください。