株式会社ラック

トップレベルのセキュリティ技術を駆使した
ITトータルソリューションで、未来をきり拓く

セキュリティ事故発生時はこちら
閉じる

ご相談は予約不要、24時間対応

緊急対応窓口:サイバー救急センター®

セキュリティに係るお客様の緊急事態に際し迅速にお客様をご支援する緊急対応サービスです。
緊急事態が発生したら今すぐ「サイバー救急センター」にご相談ください。

電話で相談する

メールで相談する

サイバー救急センター®のメールアドレス

自分で調べる

ご相談は予約不要、24時間対応

緊急対応窓口:サイバー救急センター®

セキュリティ事故発生時はすぐにご連絡ください

LAC WATCH
2019年11月28日 | ラックピープル

Policy as Codeを実現するVaultの「Sentinel Integration」とは

ラックは、2019年8月7日に、HashiCorp社のシークレット管理製品「Vaultヴォルト」の販売を開始しました。
この記事では、HashiConf'19※1でも取り上げられた、Vaultのエンタープライズ版の機能の一つである「Sentinel Integration」をご紹介します。

※1 2019年9月にアメリカのシアトルで開催されたHashiCorp社主催のカンファレンス

Vaultとは

さらに詳しく知るにはこちら

HashiCorp Vault

Vaultは、マルチクラウド環境におけるシークレット(例えば、Azureなどにアクセスするための認証情報等)を、発行・更新・削除のすべてのライフサイクルにわたって一元管理できる製品です。ユーザが対象のサービスにアクセスする際に、Vaultからシークレットの払い出しを受けるため、シークレットをソースコードにハードコーディングする(埋め込む)必要がないという利点があります。また、Vaultの管理者はシークレットの払い出しに必要なアクセスキーに有効期限を設けることができ、万が一アクセスキーが漏洩した場合にも即座に停止することができるため、セキュアな運用を担保することができます。

さらに詳しく知るにはこちら

HashiCorp Vault
シークレット管理機能の利用例
シークレット管理機能の利用例

OSS版Vaultにおけるポリシー管理とその限界

システム管理者がVaultでシークレットを管理する場合には、「誰が」「どのシークレットに」「どのようにアクセスできるか」というポリシーを定義します。オープンソース(OSS)版のVaultでは、アクセスコントロールリスト(ACL)でユーザがアクセス可能なシークレットとそれに対する操作を定義します。

例えば、あるユーザにシークレット"personal"の読み込み「のみ」を許可するACLを作成する場合には、コマンドラインから次のように入力します(ファイルから読み込むこともできます)。

あるユーザにシークレット personal の読み込み「のみ」を許可するACLを作成する場合

このポリシーを適用したユーザは、"personal"への「読み込み」はできますが、「書き込み」や"personal"以外へのシークレットへのアクセスはできなくなります。

しかしVaultをチームや組織で運用する場合には、ユーザが所属するグループやアクセス対象のシークレットの性質に応じてより細かいコントロールが要求されるでしょう。例えば、以下のようなことが考えられます。

  • 本番環境にアクセスするためのシークレットは、特定の開発チームに所属するメンバーにのみ払い出したい
  • GDPRへの対応から、個人情報を取り扱うシステムのシークレットに対するアクセス元は、EU圏以外のIPアドレスに制限したい

また、上記のような複雑なポリシーを定義する場合には、例えば、シークレットへのアクセス権限を持つべきでないグループのユーザに対し権限を与えてしまった、というような設定誤りへの配慮も必要です。

Policy as Code

実際の開発現場で要求される、このように複雑なポリシーを管理する一つの考え方として「Policy as Code」があります。

Policy as Codeとは、ポリシーをコードベースで管理することです。コードベースで管理したポリシーを環境に適用することで、組織が定めたポリシーと実際のポリシーが一致し、権限の設定誤りや漏れを防ぐことができます。また、履歴管理も可能になります。そのため、ポリシーに問題があった場合には以前のバージョンを適用することで、復元が容易という利点もあります。

Policy as Codeの概念図
Policy as Codeの概念図

Sentinel Integrationによる解決

エンタープライズ版のVaultは、「Policy as Code」の考え方に基づき、複雑なポリシーを適切に管理するための機能「Sentinel Integration」を備えています。※2

※2 より正確には、HashiCorp社の「Sentinel」というOSSフレームワークを統合(Integration)する機能です。また、この機能はOSS版のACL機能と併用することができます。

具体的には、下記2つのポリシー制御をコードにより実現します。

Role Governing Policies(以下、RGPs)

RGPsは、Vault上の識別子(トークン、エンティティまたはグループ単位)でポリシーを定義します。
例えば、特定のグループ名やグループIDに該当するユーザにアクセスを認める場合には、次のように記述します。

特定のグループ名やグループIDに該当するユーザにアクセスを認める場合の記述

この場合、"develop-team"に所属しないユーザは、対象のシークレットにアクセスすることができません。

Endpoint Governing Policies(以下、EGPs)

EGPsは、エンドポイントすなわちアクセス元やアクセス対象のリソース単位でポリシーを定義します。 例えば、アクセスを営業時間内(9時~17時)に限り許可したい場合には、次のように記述します。

アクセスを営業時間内(9時~17時)に限り許可したい場合の記述

また、LDAP認証を利用したログインについて、特定の接続元IPに制限したい場合は、次のように記述します。

LDAP認証を利用したログインについて、特定の接続元IPに制限したい場合の記述

上記いずれの場合も、条件を満たさないアクセスは拒否されます(403エラー)。

なお、Sentinelの機能はCLIだけでなくGUIからも利用することができます。

Sentinelの機能はCLIだけでなくGUIからも利用することが可能

Sentinel Simulator

Sentinelにより作成したポリシーは、HashiCorp社のOSS「Sentinel Simulator」によりテストすることができます。
例えば、特定のシークレットに対してIP"122.22.3.4"からのアクセスのみ許可するポリシーを定義した場合、当該ポリシーに対する正常系のテストケースは次のようにJSON形式で記述します。

IP 122.22.3.4からのアクセスのみ許可するポリシーを定義した場合、当該ポリシーに対する正常系のテストケースはJSON形式で記述

作成したテストケースは、sentinelコマンドでテストすることができます。テストに成功すると、次のように「PASS」が表示されます。

sentinelコマンドでテスト、「PASS」が表示

このように作成したポリシーに対してテストを実施することで、ポリシーの設定内容が意図したものであるかどうかを確認することができます。

まとめ

マルチクラウド時代の開発において、採用するクラウドサービスやそれを利用する開発者が増えるほど、シークレットを適切に管理するためのポリシー運用コストも増えていきます。
Vaultエンタープライズ版の「Sentinel Integration」を適切に利用することで、組織の複雑化したポリシー管理に大いに役立つでしょう。

この記事は役に立ちましたか?

はい いいえ

サイバーセキュリティに関する
様々な情報をお届けします

メルマガでは、より厳選した情報を
月に2〜3回配信しています
詳しくはこちら

page top