こんにちは。λ沢です。
皆さんは普段どのようにローカルから AWS の API を実行していますか?
AWS の基礎を学んだ人の多くは aws configure
コマンドを使ってアクセスキーを入力し、 aws-cli
や AWS SDK を使用しているのではないでしょうか。
しかし aws configure
コマンドはアクセスキーを平文でローカルマシンの ~/.aws/credentials
に保存します。
いくらローカルマシンとはいえ、様々なセキュリティリスクが存在する現代では平文でアクセスキーを管理することは好ましくないです。
最近だと faker.js と colors.js に DoS 攻撃のコードが仕込まれたことが話題になりました。
もしこのコードが DoS 攻撃ではなく、~/.aws/credentials
の内容を悪意を持った人に対して送信するコードだとしたら、何が起きるでしょうか?
恐らく被害者はマイニングなどに EC2, ECS, Lambda などの計算資源が使用され、 AWS から多額の請求を受けると思います。
今回はこのような攻撃の対策として、 aws-vault
を使用して暗号化されたアクセスキーをシームレスに扱う方法を紹介します。
aws-vault とは?
主に 99designs という企業がメンテナンスを行っている Go 製のコマンドラインツールです。
2022/01 時点で 5.8k 個のスターが付いており、活発に開発されています。
https://github.com/99designs/aws-vault
Mac を使用している場合、以下のコマンドでインストールできます。
$ brew install --cask aws-vault
それ以外のプラットフォームを使用している場合は README を参照するか、リリースページからスタンドアローンのバイナリをダウンロードすることで対応できます。
この記事では以下のバージョンを使用してます。
$ aws-vault --version
v6.3.1
アクセスキーを暗号化して保存する
以下のように aws-vault add
コマンドを使うことによってアクセスキーを暗号化して保存することができます。
ここでは irisawa-demo
という名前のプロファイルでアクセスキーを保存しています。
使い勝手は aws configure
コマンドとほとんど変わりません。
$ aws-vault add irisawa-demo
Enter Access Key ID: AKIAXXXXXXXXXXXXXXXX
Enter Secret Access Key:
Added credentials to profile "irisawa-demo" in vault
暗号化されたアクセスキーは Mac 標準のキーチェーンで管理されます。
このタイミングで新たにキーチェーンが作成されるためパスワード入力が求められます。
このパスワードでアクセスキーが暗号化されることになります。
Linux の場合は Gnome Keyring などで、 Windows の場合は Credential Manager で管理されます。
アクセスキーの一覧を確認する
aws-vault add
で登録されたキーの一覧は aws-vault ls
コマンドで確認できます。
$ aws-vault ls
Profile Credentials Sessions
======= =========== ========
irisawa-demo irisawa-demo -
暗号化されたアクセスキーを使用する
さて、無事にキーを暗号化して保存することができました。
次はこのキーを復号して使用してみましょう。
試しに microcms-aws-vault-introduction
という名前の S3 バケットを作ってみます。aws-cli
や AWS SDK にはキーチェーン内の暗号化されたアクセスキーを復号するような仕組みは無いため、従来のコマンドをそのまま使用することはできません。
$ aws --profile irisawa-demo s3 mb s3://microcms-aws-vault-introduction
Unable to locate credentials. You can configure credentials by running "aws configure".
aws-vault exec
コマンドを使うことによって、先程登録したアクセスキーと同等の権限を持った状態でコマンドを実行することができます。
$ aws-vault exec irisawa-demo -- aws s3 mb s3://microcms-aws-vault-introduction
make_bucket: microcms-aws-vault-introduction
この時、裏側では複合されたアクセスキーがそのまま使われるのではなく、短期間でのみ有効な一時的なアクセスキーが使われています。
そのため、上記の例でいうと何らかの理由で aws-cli
がマルウェアに置き換えられていたとしても、被害は一時的なものに抑えられる可能性が高いです。
復号されたアクセスキーを確認する
何らかの理由で復号されたアクセスキーを確認したい場合、以下のように --no-session
オプションを付けた上で env
コマンドを使って環境変数を表示し、 AWS_
という文字列で出力を絞ることで対応できます。--no-session
を付けない場合も何かしらアクセスキーは出力されますが、それは aws-vault
が発行した一時的なアクセスキーであり、元のアクセスキーとは異なります。
$ aws-vault exec irisawa-demo --no-session -- env | grep AWS_
AWS_VAULT=irisawa-demo
AWS_ACCESS_KEY_ID=AKIAXXXXXXXXXXXXXXXX
AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXXXXX
セッションの期限を調整する
キーチェーンはデフォルトで5分に1回パスワード入力を求めてきますが、このインターバルは以下のような手順で調整可能です。
まず以下のコマンドでカスタムキーチェンを開きます。
$ open ~/Library/Keychains/aws-vault.keychain-db
サイドバーの aws-vault
を右クリックして 「キーチェン"aws-vault"の設定を変更…」 をクリックします。
パスワード入力の頻度を1時間にしたい場合は、以下のように設定してください。
また、前述の通り aws-vault exec
実行時は一時的なアクセスキーが発行されています。
この期限はデフォルトでは1時間に設定されています。
このアクセスキーの期限を調整したい場合は以下のように --duration
オプションを設定することで対応できます。
$ date -u +"%Y-%m-%dT%H:%M:%SZ"
2022-01-26T08:13:53Z
$ aws-vault exec irisawa-demo --duration 12h -- env | grep AWS_SESSION_EXPIRATION
AWS_SESSION_EXPIRATION=2022-01-26T20:09:03Z
MFA のコード入力を求められる頻度が多すぎると感じる場合はこの値を大きくすると良いでしょう。ただしスイッチロールをしている場合この期限の上限は1時間になっています。(2024/07/04追記:現在はスイッチロールであっても上限時間は伸ばせるようになっております。詳しくはAWSドキュメントをご確認ください。)
従来の利便性を取り戻す
ここまで aws-vault exec
を使うコマンド例をいくつか紹介してきました。
しかし従来は直接 aws
コマンドを使えていたのに、それができなくなってしまうと不便です。
この問題は ~/.aws/config
にcredential_process
の設定を書くことで対処が可能です。
これを設定することによって aws-cli
はアクセスキーが必要な時に credential_process
に書かれたコマンドを実行してアクセスキーを取得します。
詳しくは aws-cli
のリファレンス を参照してください。
設定例は以下のようになります。
[profile irisawa-demo]
credential_process=aws-vault exec irisawa-demo --json --prompt=osascript
以下のようなコマンドを従来通りに扱えます。
$ aws --profile irisawa-demo s3 ls s3://microcms-aws-vault-introduction
2022-01-26 16:00:52 0 test.txt
環境変数で AWS_PROFILE
を指定している場合も従来通りに扱えます。
$ export AWS_PROFILE=irisawa-demo
$ aws s3 ls s3://microcms-aws-vault-introduction
2022-01-26 16:00:52 0 test.txt
終わりに
aws-vault
を使用してアクセスキーをより安全に、可能な限り便利に扱う方法を紹介しました。
最近はサプライチェーンのインシデントを頻繁に見かけます。
現代ではローカルマシンのデータを守ることをより積極的に考えていく必要があるのではないかと思います。
しかしルールや運用を厳しくしすぎても日々の業務に支障が出てしまうため、 aws-vault
のような安全性と利便性の両方を持ったツールを活用するのが望ましいと考えています。
皆さんが扱うシステムの柵を取り除くためにこの記事が役立てば幸いです。