この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
よく訓練されたアップル信者、都元です。AWSにおけるクレデンシャルには大きく「管理コンソールにログインするためのパスワード（Sign-In Credentials）」と「APIアクセスを行うためにAPIキー（Access Credentials）」の2種類があることをご紹介しました。そして、前者Sign-In Credentialsのセキュリティを強固なものにする手段として、MFAの活用についてもご紹介しました。
本当は怖いアクセスキー
しかし実は本当に怖いのは、後者Access Credentialsのセキュリティです。アクセスキーはMFAによる保護に向いていません。設定を工夫すれば、「MFAによる認証を経なければアクセスキーを使えないようにする」ことも可能です。しかし、一般的には「プログラムが使う認証情報」であることが多いため、MFAの認証コードがなければAPIが叩けない、というのは受け入れられないケースが多々あります。
さらに、こちらも当ブログにて警鐘が鳴らされている件ですが、アクセスキー *1があれば管理コンソールログイン時のMFAを解除できることが知られています。もちろん、ログインパスワードの変更もできてしまいますね。
このようなリスクを回避するため、AWSは公式ドキュメントにおいて、90日毎にアクセスキーのローテーションを推奨しています。何とも原始的ですが、やらないと後が怖いですよ。
キーローテの方法
まず、自分が管理するIAMユーザのアクセスキーについて、発行日時を確認しましょう。IAMのManagement Consoleでユーザを選択し、下部のタブで「Security Credentials」を選択します。Access Keysの項で、キーの発行日時が示されています。
なんと、発行から1年半近く経っていますね。これはいけません、ということでローテーションを行いましょう。
ちなみに、アクセスキーは1つのIAMユーザにつき2個作成できます。なぜ1個ではなく5個でもなく、2個なのでしょうか。その理由はどこかに書いてあるわけではありませんが、私は「キーローテーションのためだ」と思っています。前述の通り、アクセスキーはプログラムから利用されることが多い認証情報です。つまり、ローテートをしようとしている、まさに今、絶え間なくキーが使われているかもしれません。新しいキーを得ると同時に古いキーが無効になってしまったら、稼働中のシステムに障害が発生してしまうかもしれません。
それを避けるために、一時的にアクセスキーを新旧2つとも有効な状態で使えるように、という配慮で「2個作成できる」ようになっているのだと思います。アクセスキーは、2個作れるからといって、キーローテーション以外の何らかの目的で、便利に使うべきではありません。
ではまず、ローテ先の新しいアクセスキーを発行してみましょう。画面中の「Manage Access Key」ボタンをクリックします。
このポップアップで、「Create Access Key」をクリックします。
上記のような表示が出たら、Download Credentialsボタンでcsvファイル形式でダウンロードするか、またはShow User Security Credentialsをクリックして画面に表示するか、でアクセスキーを取得します。
ちなみにcsvをダウンロードせずにClose Windowをクリックすると上のような警告が出ますが、きちんと情報を取得できていれば問題ありません。
というわけで、上記の通り新しいアクセスキーを手に入れることができました。
この状態で、アクセスキーを新しいものに差し替えてください。アプリケーションの設定画面、設定ファイル等、利用方法によって違っているはずですが、古いキーは削除によって使えなくなるため、全てを書き換えてください。
続いて古いアクセスキーの削除、と行きたいところですが…。残念ながら「どこでこのアクセスキーが使われているのか把握しきれていないので、全てのキーが差し替えられているか不安だ」ということもあるかもしれません。これはセキュリティ的には非常に残念な状態です。その場合は以後気をつけるということで、まずは削除 (Delete) ではなく無効化 (Make Inactive) を行ってみるのもひとつの手です。アクセスキーを無効化してしばらく様子を見ておき、関連システムがエラーを出さなければ大丈夫でしょう。万一エラーが発生するような事態となったらすぐにActiveに戻し、キーの機能を復旧させることができます。
ただ上記は「試しに障害が起こるかどうかやってみる」という非常に乱暴な手です。運用中のクリティカルなシステムには使えません。…運用中のクリティカルなシステムでアクセスキーをどこで使っているか分からないなどという事態については、まず深く反省しましょう。次からはやっちゃいかんよ。
こうなったらば、残った救済策はCloudTrailくらいしか浮かびません。CloudTrailのログからは、いつ・どのAPIが・どのアクセスキーを使って呼ばれたのか、といった詳細な情報が得られます。一定期間ログを取得して古いアクセスキーが使われていないかチェック、使われているのであれば呼び出し元IPアドレス等から利用場所を突き止める、というような手はずになります。大変ですが、頑張って。
さて、以上で晴れて古いアクセスキーは不要になったはずなので、削除します。先ほどのポップアップで Delete のリンクをクリックし、下記のような確認を経れば、晴れてローテートの完了です。
そもそも
通常はIAM Roleによる一時キーを使うべきです。そうすればキーローテーションは自動で行われますので、このような苦行の必要はありません。IAMユーザのアクセスキーは、下記のような特殊な場面以外で使うべきではないと思っています。これ以外で、IAMユーザのアクセスキーを使っていなければ、キーローテの手間もそれほど大きいものではないでしょう。
- システムがEC2ではなく、オンプレミス環境で動いている（つまりIAM Roleが使えない）システムが利用する場合。
- 開発環境等、ローカルマシンで動いているアプリケーションからAPIをコールする必要がある場合。
- aws-cli等、オペレータがアドホックに利用するユーティリティで利用する場合。
- 一時キー（Temporary Security Credentials）をサポートしていないAPIを呼ぶ必要がある場合。（参考ドキュメント）
また、そもそも使っていないアクセスキーであった場合、ローテートするというよりも単純に削除してしまうのが最もセキュアです。これは本当に必要なキーなのか、この機会にじっくり考えなおしてみてはいかがでしょうか。
脚注
- IAMの権限を持っているもの。 ↩
8
