ある国内SaaS企業は、AWSを6ヶ月間利用した後、ある日AWSから異例の請求メールを受け取った。月額料金が突然2,000ドルから18,000ドルに跳ね上がったのだ。
調査の結果、元従業員のアカウントが期限内に削除されず、アクセスキーが漏洩していたことが判明した。ハッカーはこのキーを利用して、複数の地域で仮想通貨マイニング用の高性能GPUインスタンスを起動していた。
そもそもAWS IAMを正しく設定していれば、この事件は完全に回避できたはずだった。
IAM（アイデンティティおよびアクセス管理）は、AWSアカウントのセキュリティにおける第一の防衛線ですが、同時に最も見落とされやすいものでもあります。
1. AWS IAMとは何ですか？どのような問題を解決しますか？
AWS IAMは、AWSが提供するIDおよびアクセス管理サービスです。その主な機能は…AWSリソースへのアクセス権限と、アクセス可能な操作内容を制御します。。
IAMが存在しない世界では、何が起こるだろうか？
- 全員がルートアカウントのユーザー名とパスワードを共有します。
- インターン生はCTOと同じ権限を持つ。
- 外部パートナーがS3バケットにアクセスすると、すべてのRDSデータベースも閲覧できるようになります。
IAM を使用すると、次のようなことを正確に制御できます。
- 誰が（人員／システム）はアクセスできます
- どれのAWSのサービスとリソース
- どんな作戦ですか？（読み取り／書き込み／削除／管理）
- どのような条件下で（IPアドレス制限／時間制限／多要素認証）
IAMは無料サービスであり、追加料金は一切かかりません。
II. IAMの4つのコアコンセプト
実際に運用する前に、まずIAMの基本構成要素を理解しておく必要があります。
1. IAMユーザー
は特定の人物またはアプリケーション各IAMユーザーは、固有のログイン認証情報（ユーザー名＋パスワード、またはアクセスキー）を持っています。
適切なシナリオ:
- 開発チームのメンバーごとに、個別のアカウントを作成してください。
- 自動化スクリプト/CI/CDツール専用のアカウントを作成する
2. IAMユーザーグループ
複数のユーザーを1つのグループにまとめることで、管理権限を一元化できます。ユーザーグループにポリシーを割り当てると、グループ内のすべてのユーザーに自動的にポリシーが継承されます。
適切なシナリオ:
- 開発チーム、運用チーム、データチームにはそれぞれ異なる権限が割り当てられた。
- 新入社員は、別途権限を設定する必要なく、自動的に該当するグループに追加されます。
3. IAMポリシー
戦略は権限ルールのJSONドキュメント「許可される操作と拒否される操作」を定義します。
AWSは2種類の戦略を提供しています。
- AWS マネージド ポリシー管理者アクセスや読み取り専用アクセスなど、一般的に使用されるAWSポリシー。
- クライアント主導型戦略独自の戦略により、より高い精度を実現できます。
4. IAMロール
キャラクターは一時的に引き受けることができる権限固定のユーザー名とパスワードはありません。
適切なシナリオ:
- EC2インスタンスはS3にアクセスする必要があります（コード内でアクセスキーを記述するのではなく、EC2インスタンスにロールをバインドすることによって）。
- クロスアカウントアクセス（AアカウントのサービスがBアカウントのリソースにアクセスする）
- AWSアカウントにサードパーティサービス（GitHub Actionsなど）をデプロイする
| コンセプト | 類推 | 主な用途 |
|---|---|---|
| IAMユーザー | 社員証 | 特定の担当者/システムのログインID |
| IAMユーザーグループ | 部門 | 同一タイプのユーザーに対する権限の一括管理 |
| IAM戦略 | 権限リスト | 何ができるか、何ができないかを明確に定義する。 |
| IAMロール | 一時滞在者パス | AWSサービス間/アカウント間の一時的なアクセス許可 |
III. 最小権限の原則：IAMセキュリティの中核概念
IAM権限を設定する前に、次の原則を念頭に置いておく必要があります。
最小特権の原則
各ユーザー/役割/サービスに、必要最低限の権限のみを付与し、それ以上の権限は付与しない。
これはつまり：
- 開発者は開発環境においてEC2とRDSへのアクセス権のみを必要とし、本番環境の権限は必要ありません。
- データアナリストに必要なのはS3の読み取り権限のみであり、EC2の起動権限は必要ありません。
- Lambda関数はDynamoDBへの書き込み権限のみを必要とし、S3への読み取り権限は必要ありません。
多くの企業は、時間を節約するために、全員に管理者権限を付与するが、これは最も危険な行為である。
IV．実践的な設定：安全なIAMシステムをゼロから構築する
ステップ1：ルートアカウントを保護する
ルートアカウントはAWSアカウントシステムにおいて「最高権限」を持つアカウントであり、もし盗まれた場合、その影響は予測不可能です。
ルートアカウントを安全に保つための3つのポイント：
- 多要素認証（MFA）を有効にするAWSコンソールで、[セキュリティ認証情報] → [多要素認証を有効にする] に進み、認証アプリを携帯電話にリンクします。
- AccessKey は作成しないでくださいルートアカウント用のプログラミングアクセスキーを生成しないでください。
- 請求管理専用IAMユーザーアカウントに切り替えることで、すべての定型操作が完了しました。
ステップ2：管理者IAMユーザーを作成する
日常的な運用とメンテナンスのために、IAMコンソールで管理者ユーザーを作成し、ログインに使用するrootアカウントを置き換えてください。
設定ポイント：
- ユーザー名は、admin-zhangsan のように、実名または社員番号を使用してください。
- アクセスタイプ：「AWSマネジメントコンソール経由でアクセス」を選択してください。
- アクセス制御ポリシー：管理者アクセス権限を追加（正規の管理者のみ対象）
- このユーザーに対しても多要素認証（MFA）が有効になっています。
今後は、このIAMユーザーを使用してAWSにログインしてください。ルートアカウントは今後の使用のためにロックしておいてください。
ステップ3：ユーザーグループを作成し、権限を割り当てる
チームの機能に基づいてユーザーグループを作成し、各グループに適切な戦略を割り当てます。
推奨される基本的なユーザーグループ構成：
| ユーザーグループ名 | 適任者 | 追加の戦略が推奨されます。 |
|---|---|---|
| 開発者 | 開発エンジニア | Amazon EC2 FullAccess + Amazon S3 FullAccess（開発環境のみ） |
| データアナリスト | データアナリスト | AmazonS3読み取り専用アクセス + AmazonAthenaフルアクセス |
| DevOps | オペレーションエンジニア | PowerUserAccess（IAM管理者権限は除く） |
| 請求する | 財務・経営 | AWS請求読み取り専用アクセス |
| 読み取り専用 | 監査／コンプライアンス | 読み取り専用アクセス |
ステップ4：EC2/LambdaのIAMロールを設定する
これは最も見落とされやすいステップであり、安全事故が発生しやすい高リスク領域でもある。
不適切な実践これは、アクセスキーIDとシークレットキーをEC2インスタンスのコードまたは設定ファイルに直接書き込むことを意味します。これらのキーがGitHubに送信されたり、漏洩したりすると、攻撃者はすぐにそれらを悪用できるようになります。
正しいアプローチIAMロールを作成し、それをEC2インスタンスにバインドします。
具体的な手順：
- IAMコンソールで、[ロール] → [ロールの作成]に移動します。
- 信頼できるエンティティとして「AWSサービス」→「EC2」を選択してください。
- 追加で必要な戦略（Amazon S3の読み取り専用アクセスなど）
- キャラクターに名前を付けます。例: ec2-s3-readonly-role
- EC2インスタンスの設定で、このロールをインスタンスにアタッチしてください。
EC2インスタンス上のコードは、インスタンスのメタデータから一時的な認証情報を自動的に取得するため、コード内にキーをハードコーディングする必要がなくなります。
ステップ5：独自のきめ細かな戦略を作成する
AWSのマネージドポリシーでは粒度が不十分な場合、カスタムポリシーを作成する必要があります。
典型的なシナリオとしては、すべてのS3バケットではなく、特定のS3バケットのみをユーザーが読み取れるようにする、といったことが挙げられます。
カスタム戦略の中核となる要素は、以下の4つの分野から構成されます。
- 効果許可または拒否
- アクションs3:GetObjectやec2:DescribeInstancesなどの特定のAPI操作
- リソース: 特定のリソースの ARN (Amazon リソース ネーム) を指定します。ワイルドカードもサポートされています。
- 状態（オプション）：IP制限、MFA要件などの追加条件
「読み取り専用の特定のS3バケット」を例にとると、戦略ロジックは次のようになります。s3:GetObjectとs3:ListBucketの2つの操作の実行を許可しますが、リソースをすべてのS3リソースではなく、特定のバケットのARNに限定します。
V. 高度なIAMセキュリティ：見落としがちな4つの重要な設定
パスワードポリシーを設定する
IAMコンソール → アカウント設定 → パスワードポリシーで、以下の設定を行うことをお勧めします。
- パスワードの最小文字数：12文字以上
- 大文字、小文字、数字、および特殊記号を含める必要があります。
- パスワードの有効期間：90日間
- 過去5回のパスワードは再利用しないでください。
アクセスキーを定期的に見直し、ローテーションする
IAMの「認証情報レポート」機能を使用すると、以下のユーザーを含むすべてのユーザーのアクセスキー使用情報をエクスポートできます。
- 鍵は90日以上回転されていませんか？
- そのキーは一度も使用されていないか（使用されていない場合は直ちに削除すべきか）？
- ユーザーの最終ログイン時刻（長期間ログインがない場合は、この機能を無効にする必要がある場合があります）。
四半期ごとに伝票監査を実施することをお勧めします。
AWS CloudTrailを有効にして、すべてのIAM操作をログに記録します。
CloudTrailは、IAM構成の変更、ユーザーログイン、リソースアクセスなど、アカウント内のすべてのAPI呼び出しを記録します。
これは、セキュリティインシデントの発生源を追跡するための重要なツールです。異常が発生した場合、どのユーザー/役割/サービスがいつ、どのような操作を実行したかを正確に特定できます。
CloudTrailのログをS3に同期し、暗号化ストレージを有効にして、少なくとも1年間は保存することをお勧めします。
権限の境界を設定してください。
下位の管理者（DevOpsリーダーなど）にIAMユーザーの作成権限を与える必要があるものの、作成されたユーザーの権限が自身の権限を超えてしまうことを懸念している場合は、「権限境界」機能を使用できます。
権限の境界は、ユーザーまたは役割を定義します。ユーザーが持つことができる権限の最大数ポリシーでより高い権限が指定されていたとしても、実際の実行は依然として境界制約の対象となる。
VI. 一般的なIAMの問題のトラブルシューティング
質問1：ログイン時に「アクセスが拒否されました」というメッセージが表示されます。
捜査命令：
- ユーザーがポリシーの対象となっているか（または、そのユーザーグループにポリシーが適用されているか）を確認してください。
- リソースARNが正しく記述されているか確認してください（多くの人がARNを誤って記述しています）。
- 許可ポリシーを上書きする明示的な拒否ポリシーが存在するかどうかを確認してください（拒否の方が優先度が高いです）。
質問2：EC2はS3にアクセスできません
最も一般的な原因は、EC2インスタンスがIAMロールにバインドされていないか、バインドされているロールポリシーにS3のアクセス許可が含まれていないことです。
質問3：アカウント間アクセスに失敗しました。
アクセスされるアカウントのリソースポリシーが他のアカウントのARNを許可するように、またアクセスするアカウントのユーザー/ロールが想定されるターゲットロールの権限を持つように、両側で設定する必要があります（sts:AssumeRole）。
結論は
AWS IAMの設定は複雑に見えるかもしれませんが、その核心となるロジックは実際には非常にシンプルです。最小権限、ロールベースのキー、および定期的な監査。
これら3つのことを行うことで、80%のクラウドセキュリティリスクを回避できます。
創業当初に2万ドル近くの損失を被りかけたこの会社は、「従業員ごとに固有のIAMユーザーを作成し、退職時にアカウントを即座に削除する」という対策を講じていれば、このような事態は起こらなかっただろう。
クラウドセキュリティのコストは、多くの場合、過失が発生した時点で既に決まっている。
AWS 環境をセットアップしている場合、または既存の IAM 構成が安全かどうか不明な場合は、aws-oncloudai.comの技術チームへのお問い合わせをお待ちしております。弊社では、無料のAWSアカウントセキュリティ評価サービスを提供しています。
この記事は、aws-oncloudai.comのクラウドアーキテクチャチームによって執筆されました。転載の際は出典を明記してください。
