みなさん、こんにちは。AWS CLI が好きな AWS サポート課の市野です。
先日、アクセスキーが流出した場合に何をしなければならないかを再確認する目的で「アクセスキーが流出した時、何をしなければならないか再考してみる」と題してブログを書きました。
その中で、一時的にはアクセスキーを無効化で良いが、最終的には流出したアクセスキーは削除していなければならないことに触れました。
アクセスキーの性質を踏まえながら、なぜ無効化だけでは不十分といわれてしまうのかを考察します。
なお、今回は非エンジニアの方を想定して書いているので、多少例え話が多めです。
結論としては、無効化したキーは再有効化できてしまうため、削除まで行わないとリスクが残る、ということです。
以前執筆したブログ
そもそもユーザーとしてのログインとアクセスキーの違い
アクセスキーは IAM ユーザーやルートユーザーの長期的な認証情報となります。
アクセスキーは、プログラムが AWS を操作するときに「自分は正規の利用者です」と証明するための情報です。アクセスキー ID とシークレットアクセスキーの 2 つがセットになっており、両方が揃って初めて使えます。
物理的な家の鍵になぞらえられる例もありますが、あくまで IAM ユーザーのログイン情報（ユーザー名とパスワード）が物理的な家の鍵に近いです。
概念を言葉にしてみる
| 認証情報の種別 | 概念 | 使用できる条件 |
|---|---|---|
| ルートユーザー | AWS アカウント という家に入るための鍵 | AWS という名前空間に対する ID とパスワードだということがわかれば利用できる AWS という名前空間＝ https://console.aws.amazon.com/ という住所と定義されている |
| IAM ユーザー | AWS アカウント という家に入るための鍵 | どの AWS アカウントに対するログイン情報か特定できれば利用できる AWS アカウント ID を含む https://123456789012.signin.aws.amazon.com/console 形式の URL にアクセスして、かつユーザー名とパスワードが合致する必要があるAWS アカウント ID という住所がわかっている必要がある1 |
| アクセスキー | AWS への API 実行に対する認証情報 | AWS 用のキーだとわかれば、どのアカウントのものか知らなくても使える |
アクセスキーは特定の家の鍵、というよりも、プログラムから AWS を操作するための認証情報となる。
少しだけテクニカルに表現してみる
処理の流れをシーケンス図で書いてみました。
比較すると同じ EC2 に対する操作、という観点でもアクセスキーを利用する方が通過する要素（コンポーネント）が少ないことがわかります。
IAM ユーザーとして EC2 の操作をする場合
アクセスキーを利用して EC2 の操作をする場合
アクセスキーが流出するとは
先ほどの概念を言葉にしたものや図解で家の概念と異なる、と述べているのに、引き続き家のイメージのイラストを利用しますがご容赦ください。
プログラムで利用できる認証情報というアクセスキーが外部からアクセスできる場所においてあったそれを拾われた、というイメージです。
実際には GitHub に上げられていたり、提供サービスの実行環境の環境変数から取得できてしまっていることが多い
その上で、先ほどの概念の説明で述べたように、どの家に対する鍵かを知っていなくても良いので AWS で利用されるアクセスキーとシークレットアクセスキーだということさえわかれば利用が可能 です。
つまり、物理的な家の鍵は、どの家の鍵かが特定されない限り悪用はできないですが、アクセスキーの場合は AWS API の実行をやってみるだけで利用が可能です。（あるいは試行をしてみて利用できないキーだということを知るのみ）
この AWS API の実行をやってみるのに都合が良いのが sts:GetCallerIdentity という API アクションです。
該当のアクションについては AWS でも攻撃の初動としても利用されると認識しており、その内容を佐竹さんが解説してくれているのでご一読ください。
AWS に対する正面突破ではないのか
AWS を不正利用がされている状況で対応中に、流出経路について問われることがあります。
EC2 などを利用して作成されたサーバーに対して SSH ログインを試行されて突破された結果、サーバー内部に保存していたアクセスキーを不正入手される可能性はあります。
ただ AWS マネジメントコンソールのログイン情報を総当たりで試されて AWS マネジメントコンソールに不正にログインされている事例はほとんどありません。
まったくゼロではないでしょうが、アクセスキーが不正に利用されている（ことが疑われる）と通知を差し上げた際は、AWS マネジメントコンソールを正面突破されてアクセスキーを盗まれた、という状況は稀です。
そのため、まずはアクセスキーのローテーションを早急にお願いしたいですが、その後落ち着いてプログラム的な脆弱性を抱えていないかのご確認をいただけると良いかと考えます。
アクセスキーのローテーションが必要な理由
AWS ではアクセスキーが流出したときに「ローテーション」をするように案内します。
このローテーションとは、新しいアクセスキーを作って入れ替えをしてから、一旦アクセスキーを「無効化」し、最終的には「削除」をしてください、の意味合いを込めた案内です。
まず、不正利用が行われている最中は第三者がアクセスキーを使用し続けている状況です。
そのため新たなリソースの作成や改変を防ぐために、第三者がアクセスキーを使えなくする必要があります。
ただ、その場合そのアクセスキーを正規に利用しているプログラムも影響を受けてしまい、お使いのシステムやプログラムの機能停止につながってしまうことが考えられます。
家の鍵と同等の感覚で考えた場合、正しい利用者である同居人が合鍵を使って入室できなくなってしまう状況と同一です。
そのため、新しいアクセスキーを作成して、正規に利用しているプログラムで使えるようにしてから、流出してしまったキーを無効化します。
いわば玄関に新しい鍵を取り付けて同居人に渡し、同居人が新しい鍵で入室できるようになったことを確認してから、古い鍵を使えなくする形です。
このときアクセスキーと物理の鍵が異なるのが、以下の観点です。
- AWS アカウント ID など「住所に当たる情報」を知り得なくても実行が可能
- 新しい鍵をかけているから、古い鍵をかけなくても良くなった、というような性質ではない
- AWS サービスのエンドポイントに直接リクエストし認証できるかの問い合わせしか行っていないため、何かの拍子に再有効化された際に利用再開ができてしまう
この何かの拍子に再有効化してしまうことがありうるか、については以下の可能性が考えられます。
- 対応から日が経って、アクセスキーが流出した過去を知らない運用者が再有効化をしてしまう
- 攻撃者が侵入中に、後から自分でキーを有効に戻せるような仕掛け（バックドア）を仕込まれていた
上記のことから、第三者が知り得たままの状態のアクセスキーが再有効化できてしまう余地があること自体が将来にわたって安全でないため、無効化だけでなく削除まで行う必要があります。
おわりに
アクセスキーの流出が疑われる事象が発生した際に AWS 通知が送信されますが、受信者が必ずしも技術に明るい方でないことも多々あります。
流出したアクセスキーを無効化した状態でも表面上は新しいリソースの乱立などが止まるため、他の調査に移ってしまってそのままとなることも多くあります。
いくつかの事例で無効化をした時点で十分に対応をした、として対処完了とお考えになる場面を拝見しています。
そのため、無効化したキーは再有効化できてしまうため削除まで行わないとリスクが残る、という観点から完全削除を求める背景をお伝えしました。
本エントリがどなたかのお役に立てば幸いです。
ではまた。
-
アカウントエイリアスを設定している場合は AWS アカウント ID を任意の文字列に読み替えることができます。その場合は
https://account-alias-string.signin.aws.amazon.com/consoleのような形式になりますが、内部的にはhttps://123456789012.signin.aws.amazon.com/consoleにリダイレクトされます。↩
市野 和明 (記事一覧)
マネージドサービス部・テクニカルサポート課
お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。
情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。
X（Twitter）：@kazzpapa3（AWS Community Builder）
