引き続き、Atlas + Valut 連携に関する記事の日本語訳です。
これは Atlas におけるデータの暗号化と何が異なるのでしょうか。1つめは、暗号化と複合化に関する責任を、秘密情報を保管するよう設計されたサービスに対して委譲します。Vault は監査のログや鍵、緊急時におけるアクセス権の取り消しといった一流のサポートを提供するだけでなく、鍵の差し替えも間もなく提供します。Vault は秘密情報の管理に特化した製品です。
2つめは、システムの数が増加すると、データ暗号化に対する攻撃は、より危険になります。もし Atlas が暗号化に責任を持つのであれば、暗号化された鍵を知る必要があります。この鍵というのはディスクかメモリ上に保管されているものです。攻撃者がアプリケーションに対してアクセスができても、データベースの値は全てが暗号化されているため、暗号化鍵を取り出すことはできません。
暗号化を Vault で行うようにすると、Atlas は決して暗号化鍵・復号化鍵を知ることはありません。その代わり、Atlas はトークンを使って Vault と認証のために通信を行います。トークンは Vault に対するアクセスを制限されたものであり、いつでも無効化できます。不正侵入の疑いがある場合は、トークンを無効化するか、Vault でシール︵封印︶できます。それ故、もし攻撃者が Atlas 全てを危険にさらしたとしても、暗号化データを復号化するには Vault を必要とするのです。追加ボーナスとして、各々のデータベース・テーブルの個々の列は、異なったキーで暗号化されているため、危険性を高めることはより複雑になります。
■ 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 を必要とするのです。追加ボーナスとして、各々のデータベース・テーブルの個々の列は、異なったキーで暗号化されているため、危険性を高めることはより複雑になります。
