aws-vault で認証情報とセッションを異なるセキュリティレベルで保管する

先日、aws-vault のバックエンドを keychain から passage に変えたと言う記事を書きました。その最後で触れた aws-vault 本体への PR feat: support separate session keyrings and Passage identity files が v7.16.1 でリリースされたので、今回はこの機能を使った私の運用を紹介します。

この運用では、IAM の永続キーなどを置くメインのストレージと期限付きのセッショントークンを置くストレージを別々の passage 鍵で暗号化しています。これで Touch ID などの生体認証が必要なのは作業開始時の 1 回だけになり、セッションが切れるまでは認証なしで aws-vault exec できます。

※前回同様、Secure Enclave が使える macOS を前提にしています。

免責事項 (Disclaimer)

一応セキュリティに絡む話題なので、書かれた内容を実践する際は自己責任でお願いいたします。

aws-vault の 2 つのストレージ

aws-vault は内部的に、保管するものによって 2 つのストレージを使い分けています:

メイン（コード上は Keyring）: IAM の永続キーや AWS SSO の OIDC トークン
セッション用（コード上は SessionKeyring）: STS で取得したセッショントークンや Identity Center の Permission set に対応する role のセッショントークン

前者は漏れた時の影響が大きいのに対し、後者はどちらも期限付きなので影響が及ぶのは期限が切れるまでです。コード上はこの様にセキュリティレベルの異なる概念として分かれていました。しかし PR 前は backend もその設定も 1 つしか指定できず、両方とも同じ場所に同じセキュリティレベルで保管されていました。実装上は分かれているのに、ユーザーはそれを活かせなかったと言う事です。

PR #436 では --session-* オプションと AWS_VAULT_SESSION_* 環境変数を追加し、セッション用のストレージに別の backend や設定を指定できる様にしました。指定しなかった項目はメインの設定を引き継ぎます。また、passage で使う鍵ファイル（identities file）をメイン側でも指定できる様に --passage-identities-file / AWS_VAULT_PASSAGE_IDENTITIES_FILE も追加しています。

実際の構成

メインもセッション用も backend は passage ですが、保管先のディレクトリと鍵を分けています:

~/.aws/vault/
├── credentials/   # メイン。.age-recipients があり、複数の鍵で復号できる
└── sessions/      # セッション用。メインとは別の鍵で暗号化

環境変数

これを実現する為に、.zshenv などで以下の環境変数をセットしています:

AWS_VAULT_BACKEND=passage
AWS_VAULT_PASS_PASSWORD_STORE_DIR=$HOME/.aws/vault
AWS_VAULT_PASSAGE_IDENTITIES_FILE=$HOME/.passage/identities_se_biometric
AWS_VAULT_PASS_PREFIX=credentials
AWS_VAULT_SESSION_PASSAGE_IDENTITIES_FILE=$HOME/.passage/identities_se_noauth
AWS_VAULT_SESSION_PASS_PREFIX=sessions

AWS_VAULT_SESSION_BACKEND と AWS_VAULT_SESSION_PASS_PASSWORD_STORE_DIR は指定していないので、セッション用もメインと同じく passage で ~/.aws/vault を使います。その中でプレフィックスだけを credentials と sessions に分けています。

※PASS と PASSAGE が混在しているのは aws-vault の仕様です。前回も書いた通り passage は pass の暗号化部分を age に置き換えただけの bash スクリプトなので、aws-vault でもいくつかの設定を pass と共有しています。

メインの鍵

AWS_VAULT_PASSAGE_IDENTITIES_FILE に指定しているのがメインの鍵です。前回の記事と同じく、利用時に Touch ID などの生体認証が必要な Secure Enclave の鍵を使っています。Secure Enclave に紐づいているので作った Mac でしか使えず、万が一鍵ファイルが盗まれてもそのままでは復号できません。

また credentials/ には .age-recipients を置いていて、バックアップ用のパスフレーズ付きの鍵でも復号できる様にしています（ここは前回の記事の通りです）。

セッション用の鍵

AWS_VAULT_SESSION_PASSAGE_IDENTITIES_FILE に指定しているのがセッション用の鍵です。同じく Secure Enclave の鍵ですが、こちらは生体認証なしで使える様に作っています:

age-plugin-se keygen --access-control=none -o ~/.passage/identities_se_noauth

作った Mac にログインしている状態なら、追加の認証なしで復号できます。バックグラウンドで何度も使いたい時に便利です。

入るのは期限付きのトークンだけなので、こちらはバックアップしません。sessions/ には .age-recipients を置いていないので、passage はこの鍵だけで暗号化します。

使ってみて

作業開始時に aws-vault exec some-profile を実行すると、メインの鍵を使うので最初だけ生体認証を求められます。一方そこで得たセッションは sessions/ に保管されるので、期限が切れるまでは同じ aws-vault exec some-profile を認証なしですぐに実行できます。

前回の構成だとセッションもメインの鍵で暗号化していた為、aws-vault exec の度に生体認証が必要でした。セキュリティは手放さずに手間だけ減らせたので、個人的にはかなり満足しています。

今回はどちらも passage にしましたが、backend 自体を分ける事もできます。例えば前回の記事で触れた、1Password が遅すぎて個人的に耐えられなかった問題も解消できそうです。メインを 1Password にしてセッション用を passage にすれば、1Password にアクセスするのは作業開始時だけになるからです（ただ私はその運用で使っていません）。

尚、これはあくまで人間用の運用です。AI エージェントに AWS を操作させる時はこのままでは使っていません。そちらはもう一捻りしているので、また別の機会に書こうと思います。

まとめ

aws-vault は内部的に、メインとセッション用の 2 つのストレージを持っている
v7.16.1 から、セッション用のストレージに別の backend や設定を指定できる
メインを生体認証必須の鍵、セッション用を認証なしの鍵にすれば Touch ID などの生体認証は作業開始時の 1 回で済む

aws-vault の backend に passage を使っていて、認証の回数が気になっている方は試してみてください。