AWS IAMの重大な脆弱性6選とその回避方法

クラウドの脆弱性とは何でしょうか。簡単に言えば、クラウド環境に存在する、悪用可能な弱点です。脆弱性は多くの場合、クラウドリソースの設定ミスによって発生し、侵害やセキュリティ障害につながる可能性があります。特に、脆弱性がアイデンティティおよびアクセス管理（IAM）に関係する場合は注意が必要です。

IAMは非常に複雑で、設定を誤った場合の影響は深刻になりかねません。State of Cloud Security 2021レポートによると、IAMは最も多く指摘されたクラウドの設定ミスであり、回答者の41%が挙げています。また、Verizonの2021年データ侵害調査レポートによると、分析対象となった侵害の61%に認証情報が関与していました。

この記事では、AWS IAMに関連する複数の脆弱性と、それらを防ぐためのヒントをご紹介します。

AWS認証情報に関する脆弱性

アクセスキーをローテーションしない

脆弱性: ローテーションされていないIAMアクセスキー

危険な理由: アクセスキーは、IAMユーザーがCLIやAPIにプログラムからアクセスするために使用する長期有効の認証情報です。アクセスキーは、アクセスキーIDとシークレットアクセスキーで構成されます。有効な期間が長いほど、攻撃者に侵害される機会が増えます。アクセスキーが侵害されると、ユーザー名とパスワードが侵害された場合と同じくらい危険です。

対処方法: CIS AWS Foundations Benchmark v1.4.0では、90日ごと、またはそれより短い間隔でアクセスキーをローテーションすることを推奨しています。AWS Management Console、CLI、またはAPIを使って実施できます。基本的な手順は次のとおりです。

1. 新しいアクセスキーを作成する

2. アプリケーションが新しいキーを使用するように更新する

3. 古いキーを無効化する

4. アプリケーションが正常に動作することを確認した後、古いキーを削除する

こちらで修復手順をご確認ください。

パスワードの使い回し

脆弱性: 以前使用したパスワードの再利用

危険な理由: アクセスキーと同様、パスワードが有効な期間が長いほど侵害される機会が増えます。同じパスワードを繰り返し使うのも危険です。また、攻撃者が盗んだユーザー名とパスワードを多数試してアカウントへの侵入を試みる、パスワードリスト攻撃を受ける可能性もあります。

対処方法: CIS AWS Foundations Benchmark v1.4.0では、「パスワードの再利用を防止」を有効にし、「記憶するパスワードの数」を24に設定するパスワードポリシーを推奨しています。こちらで修復手順をご確認ください。

MFAを使用しない

脆弱性: MFAを使用していない

危険な理由: 多要素認証（MFA）はIAMユーザーを保護する追加のセキュリティ層です。MFAがなければ、AWSへのログインに必要なのはユーザー名とパスワードだけです。そのため、認証情報を侵害した攻撃者にすべての権限を握られてしまいます。一方、アカウントでMFAを有効にすると、ログイン時に仮想またはハードウェアのMFAデバイスで生成したワンタイムコードなど、追加情報の入力が求められます。この情報がなければログインできないため、攻撃を防ぐことができます。

対処方法: CIS AWS Foundations Benchmark v1.4.0では、コンソールアクセス権を持つすべてのIAMユーザーに対してMFAを有効にすることを推奨しています。こちらで修復手順をご確認ください。

IAMポリシーに関する脆弱性

S3バケットに対する広範な一覧表示アクションを許可する

脆弱性: IAMロールポリシーでS3バケットに対する広範な一覧表示アクションが許可されている

危険な理由: IAMロールのポリシーでS3バケットに対する広範な一覧表示アクションが許可されている場合、攻撃者がそのロールにアクセスすると、すべてのバケットを列挙し、データの保管場所を特定できます。s3 syncにも一覧表示権限が必要なため、攻撃者にバケット内の機密データを盗まれる可能性があります。特に必要でない限り、s3:ListAllMyBuckets、s3:List*、s3:*の各アクションはIAMポリシーに含めないようにしましょう。この脆弱性が2019年のCapital One侵害につながった可能性があります。詳しくはCapital Oneのクラウド設定ミスによる侵害の技術分析をご覧ください。

対処方法: IAMポリシーから過度に広範な一覧表示権限を削除します。こちらで修復手順をご確認ください。

すべてのプリンシパルにロールの引き受けを許可する

脆弱性: IAMロールの信頼ポリシーで、すべてのプリンシパルにロールの引き受けが許可されている

危険な理由: どのAWSアカウントのIAMユーザーでも自分のアカウントのロールを引き受けられるようにすると、そのIAMロールのすべての権限を与えることになります。これは壊滅的な事態につながりかねず、権限昇格やデータ流出などを招く恐れがあります。ロールの信頼ポリシーに、次の要素がすべて含まれていないことを確認してください。

• Effect: “Allow”

• Principal: “*”

• Action: “sts:AssumeRole”

対処方法: ワイルドカードを特定のプリンシパルに置き換えます。こちらで修復手順をご確認ください。

完全な管理者権限を許可する

脆弱性: IAMポリシーで完全な"*:*"管理者権限が許可されている

危険な理由: あらゆるサービスに対するすべての権限を許可するIAMポリシーは、セキュリティの基本原則である最小権限に直接反します。このようなポリシーを持つユーザーやロールに悪意のある人物がアクセスすると、AWSアカウント内のあらゆるものに無制限にアクセスされ、取り返しがつかなくなります。必要な権限だけを付与し、それ以上は与えないようにしましょう。

対処方法: ActionとResourceがどちらも*に設定されているAllowポリシーから、ワイルドカードを削除します。こちらで修復手順をご確認ください。

IAMのヒントとベストプラクティス

IAMを運用する際のベストプラクティスをいくつかご紹介します。

• 最小権限の原則を実践しましょう。タスクの遂行に必要な権限だけを付与します。最初から管理者権限を与えて後から削除するよりも、必要最小限の権限を持つロールから始め、必要に応じて権限を追加する方が安全です。

• パスワードを適切に管理しましょう。ユーザーのパスワードポリシーを作成して、パスワードの最低文字数（CISは14文字以上を推奨）、英字・数字・記号の組み合わせ、過去に使用したパスワードを再利用しないことなどの要件を設定できます。また、有効期限を設定し、たとえば90日ごとにパスワードを変更するようユーザーに求めることもできます。

• 認証情報は適切に保管しましょう。アクセスキーやパスワードを、非公開のものも含めてコードリポジトリに保存しないでください。それが2016年にUberがハッキングされた原因となりました。また、ユーザー間で認証情報を共有しないようにしましょう。

• IAMの設定を監視し、ポリシーが変更されたときやアクセスキーが有効化または無効化されたときに把握できるようにしましょう。組織固有の要件を徹底するカスタムルールを作成することも重要です。たとえば、AWSのパスワードを45日ごとに変更することをユーザーに求める組織であれば、その要件を強制するパスワードポリシーが各AWSアカウントに設定されているか確認する仕組みを用意しましょう。

さらに学びたい方は、よくあるAWSの設定ミス上位5件を解説するシリーズをご覧ください。