【日本語参考訳】Atlasは秘密情報の管理にVaultをどう使うのか

引き続き、Atlas + Valut 連携に関する記事の日本語訳です。

■ Atlas は秘密情報の管理にどのように Vault を使うのか

How Atlas uses Vault for Managing Secrets – HashiCorp
https://www.hashicorp.com/blog/how-atlas-uses-vault-for-managing-secrets.html

先日の Atlas GitHub 統合に関する投稿では、Vault を使って Atlas 上にシークレットの保管やアクセスができると、ついでに言及していました。今回の投稿では、Atlas 上で安全に個人情報や GitHub トークンのような秘密情報を扱うには、Vault をどう使えばよいのか、深く掘り下げていきます。この強力な新しい統合機能は、近々 Atlas で利用可能となる、すばらしい新機能の土台となるものです。

Atlas がどのように Vault にデータを保管し、秘密情報や繊細な情報を扱っているかについて学ぶには、このまま読み進めてください。

■ 背景

どうして私達が Atlas 上での秘密情報（シークレット）の保管に Vault を選んだのか、そこに深く飛び込む前に、既存の解決策は何故このケースにおいて適切でないのか、それを理解することは重要です。理解の範囲を必要なところのみに絞るため、GitHub OAuth トークンを例に扱いますが、Atlas の多くのコンポーネントで Vault による暗号化を使っています。

GitHub アカウントと Atlas を繋ぐ時、GitHub は JSON 形式のペイロードを応答します。ペイロードに含まれる領域には、GitHub ユーザ名や GitHub OAuth トークンのように、いくつかの秘密情報が含まれています。OAuth にあまり慣れていなければ、こちらから詳細を知ることができますが、重要なのは OAuth トークンとは外部サービスに対するパスワードのようなものである点です。この情報を安全に保つこと自体が、極めて大切になります。

ユーザ名とパスワード認証を提供するアプリケーションにおいて、初期のユーザ登録時、単なる文字列のパスワードにハッシュ暗号化を施し、その処理結果をデータベースに保管します。ユーザがシステムで認証しようとすると、入力されたパスワードに対して同じハッシュ暗号化を施し、データベースの結果と比較します。一致すると、ユーザが認証されます。一致しなければパスワードが一致しませんので、認証は失敗します。ハッシュ化の手法を用いているため、もし攻撃者がデータベースにアクセスできたとしても、オリジナルのパスワードはハッシュ値から見ることができません。テキスト文字列のパスワードはデータベースの中には存在しないのです。

パスワードとは異なり、GitHub OAuth トークンの保存に一方通行のハッシュ化は使えません。Atlas が GitHub と通信する時に必要となるのは、自分の代わりに認証リクエストを送る必要があります。そのため、Atlas が GitHub に対してリクエストするには、単なる文字列である GitHub OAuth トークンが必要となります。OAuth トークンをパスワードのように扱おうにも、文字列をデーベースにそのまま保存するわけにいけません。私達は対称暗号化アルゴリズム(symmetric encryption algorithm)を採用し、GitHub の OAuth トークンを Atlas が与えるようにしました。Atlas によるトークンの暗号化には、Atlas のみが知っている暗号鍵を使いデータベースに暗号化された値を保存します。Atlas が GitHub の通信時に文字列が必要となる場合、以前使ったものと同じ鍵でデータを復号化します。もし攻撃者がデータベースにアクセスできたとしても、見えるのは暗号化された値だけです。しかし、この手法も同様の問題を抱えています。

この手法では、アプリケーション自身に極めて重い責任を負わせています。Atlas が必要とされるのは、鍵の管理、鍵のローリング（差し替え）、break-glass procedure （不正アクセスなど緊急時のアクセス制御手順）です。これらの機能が Atlas を通して直接扱えるように、私達は Vault と連携する vault-rails プラグインを使います。Atlas のデータ暗号化に Vault が使われているのは、驚くべきことではないでしょう。私達は Vault を、非常に厳密なアクセス制御を持つプライベートなネットワークで使っています。

Vault-rails は開発者による利用を念頭に設計されたもので、既存のアプリケーションとシームレスに連携します。インストールの詳細やセットアップ手順は vault-rails README に記載していますが、既存のアプリケーションが連携するために最低限必要なのは、次のようなものです：

class MyModel < ActiveRecord::Base
  include Vault::EncryptedModel
  vault_attribute :secure_field
end

この例では、vault-rails プラグインは「secure_field」という仮想アトリビュートを作成します。新しい値がセットされると、Vault で暗号化され、データベースには暗号化された値が保管されます。仮想アトリビュートがリクエストされると、Vault はアプリケーションに復号化した文字列を入手しますので、元の文字列を得ることができます（認証が必要です）。最も重要なのは、全ての過程が開発者に意識させない点です。開発者は Vault や Vault の設定に関する心配をしなくてよく、アプリケーションのコードを書くのと同じように、簡単に書くだけです：

my = MyModel.new
my.secure_field = "s3cRet"
my.secure_field #=> "s3cRet"

vault-rails プラグインの助けにより、私達の内部 Vault サーバーに Vault の transit backend を経由して（リンク）、Atlas に暗号化や復号化を委ねることができます。transit backend は vault を通して透過的に暗号化・復号化するためのエンドポイントです。

これは Atlas におけるデータの暗号化と何が異なるのでしょうか。1つめは、暗号化と複合化に関する責任を、秘密情報を保管するよう設計されたサービスに対して委譲します。Vault は監査のログや鍵、緊急時におけるアクセス権の取り消しといった一流のサポートを提供するだけでなく、鍵の差し替えも間もなく提供します。Vault は秘密情報の管理に特化した製品です。

2つめは、システムの数が増加すると、データ暗号化に対する攻撃は、より危険になります。もし Atlas が暗号化に責任を持つのであれば、暗号化された鍵を知る必要があります。この鍵というのはディスクかメモリ上に保管されているものです。攻撃者がアプリケーションに対してアクセスができても、データベースの値は全てが暗号化されているため、暗号化鍵を取り出すことはできません。

暗号化を Vault で行うようにすると、Atlas は決して暗号化鍵・復号化鍵を知ることはありません。その代わり、Atlas はトークンを使って Vault と認証のために通信を行います。トークンは Vault に対するアクセスを制限されたものであり、いつでも無効化できます。不正侵入の疑いがある場合は、トークンを無効化するか、Vault でシール（封印）できます。それ故、もし攻撃者が Atlas 全てを危険にさらしたとしても、暗号化データを復号化するには Vault を必要とするのです。追加ボーナスとして、各々のデータベース・テーブルの個々の列は、異なったキーで暗号化されているため、危険性を高めることはより複雑になります。

■ 未来

Vault は急速に成長している製品ですが、既に秘密情報の管理とPII(個人情報；Personally Identifiable information)データの保管ソリューションを提供しています。これは安全な土台上で構築されたものを提供しています。vault-rails は開発者が親しみやすい方法で Vault を使えるという例です。私達は Atlas のアップデートと、vault-rails プラグインを Vault の新機能として追加するつもりです。

HashiCorp は、モダンなデータセンタにおける組織の管理手法と運用を変えるための、オープンソースのツールを構築します。HashiCorp は私達のお客さまのために、データセンタを安全にするという非常に大きな責任がありますので、最高級と考えられる安全性を作ります。セキュリティの脆弱性や懸念がありましたら、どうか security@mashicorp.com までメールをお願いします。