シークレットを安全に保護、管理するVaultの主な5つの機能
1. シークレットの動的管理
Vaultの最大の特長である「シークレットの動的管理」機能により、一時的にシステムにアクセスできるID、パスワードをVaultが自動生成し、IDに対して有効期限を設定することで自動廃止や使用期限の延長および手動廃止が可能となります。これによりマルチクラウド環境での複数システムの認証情報を、ユーザーに代わってVaultが安全に一元管理をオンデマンドで行います。この動的管理機能は他のシークレット管理サービスでは実装されておらず、HashiCorp Vault独自機能となります。（2019年5月時点）
2. さまざまなシークレットを一元管理
シークレットといってもさまざまな種類があります。Vaultで管理できるシークレットには以下のようなものがあります。
- パブリッククラウドにアクセスするためのアクセスキー
- データベースにアクセスするためのアクセスキー
- APIへアクセスするためのAPIキー
- SSHキー
- PKI証明書
また、多彩なプラットフォームもサポートしています。
Vaultで管理できるシークレット（一例）
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- Active Directory
- Database
- SSH
- Key value
多様なプラットフォームをサポート
Vaultでは以下の動作環境をサポートします。
- Linux
- Windows
- Mac OS X
- FreeBSD
- NetBSD
- OpenBSD
- Solaris
3. 多種多様な暗号化アルゴリズムをサポートし、連邦情報処理規格FIPS 140-2に準拠
Vaultでサポートする暗号化アルゴリズム
Vaultではさまざまな暗号化アルゴリズムを利用しシークレット情報を暗号化することができます。
- aes256-gcm96
- chacha20-poly1305
- ed25519
- ecdsa-p256
- rsa-2048
- rsa-4096
連邦情報処理規格FIPS 140-2に準拠
Vault Enterprise0.9以降では、ハードウェアセキュリティモジュール（HSM）との連携により連邦情報処理規格FIPS 140-2※1に準拠している旨、認定を受けております。
※1 FIPS 140-2（Federal Information Processing Standardization 140-2）は2001年5月に発行された、米国連邦政府の省庁等各機関が利用するハードウェア及びソフトウェアの暗号モジュール要件に関する規定です。米国連邦政府機関が暗号モジュールを調達する際にはFIPS 140-2、もしくはその前身であるFIPS 140-1適合認定を取得しているものである必要があります。
4. シークレットへのアクセスコントロール
ACLを定義しシークレット情報およびシステムへのアクセス権を制御します。これにより運用担当者と開発者で参照可能なシークレット情報を分ける等の管理が可能となります。
5. シークレットへのアクセスの監査
いつ・誰が・どのシークレットへアクセスしたか記録します。
Vaultによる課題の解決ケース
Vaultは、シークレット管理におけるID漏洩リスクやID管理の負荷など様々な解決策を提供します。
複数のユーザーでパブリッククラウドのアクセスキーを共有している場合
- ユーザーが同一のアクセスキーを使用するため、多くの権限を付与しなければならず、リスクにつながる
- アクセスキーの漏えい時の影響は広範囲となる
- 誰が、いつ、どこにアクセスしたのか確認できない
- ID管理者に代わり、Vaultがユーザーごとにアクセスキーを発行するため、誰が、いつ、どこにアクセスしたか把握できる
- 万が一アクセスキーの漏洩があった場合でも、早急にアクセスキーを廃止するなどの対応ができ、漏洩による影響範囲を最小限にすることができる
- ユーザーごとのアクセスキーを自動的に作成するため、運用管理業務の削減が図れる
- ユーザーごとの権限をポリシーとして定義し、自動でアクセスキーを発行することで、人為的なミスを防げる
データベースへのアクセス情報がソースコードにハードコーディングされている場合
- クラウドインスタンスを大量に起動される、もしくは機密情報の漏えいにつながる
- 誰が、いつ、どこにアクセスしたのか確認できない
アクセスキーを含んだソースコードを公開リポジトリに登録した場合、公開されたアクセスキーを攻撃者に奪取され、最終的に、攻撃者がアクセスキーを使用してクラウドインスタンスを大量に起動することが可能となります。そこから流出したアクセスキーを不正に使われ、クラウド事業者からの高額な請求がきてしまう被害などが発生します。アクセスキーを不正使用され機密情報の漏えいにもつながります。
Vault導入後は、アプリケーションはアクセスキーをVault経由で取得するため、ソースコードに直接アクセスキーをハードコードすることはありません。そのため、公開リポジトリにソースコードを登録しても、アクセスキーが含まれていないため、攻撃者がアクセスキーとともに、クラウドインスタンスを立ち上げることはできず、高額請求のような被害を防ぐことができます。
その他、シークレットへのアクセスログや監査ログを取得していない場合も、Vaultが監査ログを記録することで、過去のアクセス履歴を確認し、情報漏えい時の早期解決や監査証跡管理を実現できます。
DevOps時代のセキュリティ
DevOpsやデジタルトランスフォーメーションによりシステム構築やリリースのスピードが加速していく中、情報漏えいによるセキュリティ事故は後を絶ちません。この背景には、システムがクラウドのような新しい環境に移行している一方で、既存のシステムセキュリティのノウハウのままで新しいシステムを運用している点があげられます。
クラウド活用が進む中、セキュリティの要がネットワーク単位の通信の領域からIDの領域に移ろうとしています。システムは益々ダイナミックな環境となり、従来型のFirewallに代表される、境界防御だけではセキュリティは守れません。実際、多くのクラウド先行企業で次のような「シークレット（Secrets）」※2の漏えいによる不正アクセスを経験しています。
※2 ITサービスを利用するために必要な情報であり、外部に漏れてしまったら多大な損害を被る可能性の高い情報の総称。「クレデンシャル情報」と言う場合もあります。
シークレットの例：ユーザーID/パスワード、APIトークン、証明書、シークレットキー
シークレットの漏えいによる不正アクセスの例
パブリッククラウドのアクセスキーを含んだソースコードを公開リポジトリ登録してしまい、そこから流出したアクセスキーを攻撃者に使用されることにより、以下の事故が発生。
- パブリッククラウドのインスタンスを仮想通貨マイニング目的のために大量に起動され、その結果、高額のクラウド利用料が請求される
- データベースへの不正アクセスにより暗号化されていない顧客情報が漏えいする
ラックは、マルチクラウド環境でシークレットを保護・管理する「Vault」により、DevOpsにセキュリティの要素を加えたDevSecOpsの実現を支援します。
価格
お気軽にお問い合わせください。
- LAC×HashiCorpリソースセンター
- 関連記事
- Policy as Codeを実現するVaultの「Sentinel Integration」とは
- Vaultの動的シークレットでTerraformのセキュリティレベルを向上させるには
- インシデント事例に学ぶ、シークレットの動的管理の必要性
- データ暗号化は機密情報保護の最後の砦"Encryption as a Service"としてのVaultの使い方
- HashiCorp Vaultの最新バージョン1.4がリリース、ラックが注目する2つの新機能とは？
- コンテナのシークレットを安全に管理するHashiCorp VaultとAqua Security
- 技術者でない人のためのVault入門
- 本番環境でも使えるVaultクラスタをAWS上に構築する（5分以内で！）
- 複雑なポリシーを適切に管理する、HashiCorp Vault SSH CA動的シークレットエンジンとSentinel
- 企業の機密情報を保護する、HashiCorp Vaultの暗号化ソリューション