AWSにおけるIAMと最小権限の原則 - ユーザー・グループ・ロールによるアクセス管理

どうも、Shinyaです。この記事では、AWSにおけるアクセス管理の基盤であるIAM（Identity and Access Management）について解説します。ルートユーザーのセキュリティ対策、IAMの4つの構成要素（ポリシー、ユーザー、ユーザーグループ、ロール）、そして最小権限の原則に基づいた運用方法を整理します。

ルートユーザーのセキュリティ対策​

AWSアカウントを作成すると、登録メールアドレスとパスワードの組み合わせで認証するルートユーザーが作成されます。ルートユーザーはAWSの全リソースに対するフルアクセス権限を持ち、請求情報や個人情報といった機微な情報にもアクセスできます。

この強力な権限を持つルートユーザーは、作成後は極力使用せず、以下の手順でロックダウンすることがAWSのベストプラクティスとして推奨されています。

1. 予測が困難な強力なパスワードを設定する
2. ルートユーザーの認証情報はパスワードマネージャーに保存し共有しない
3. MFA（多要素認証）を有効化する
4. CLI等で使用するために発行したアクセスキーがある場合は削除する
5. 管理者権限をアタッチしたIAMユーザーを作成し、以降はそのIAMユーザーで作業を行う

IAMとは​

IAM（Identity and Access Management）は、AWSリソースへのアクセスをポリシーベースで管理するサービスです。「誰が」「どのリソースに対して」「どのアクションを」実行できるかを細かく制御できます。

AWSにおいては最小権限の原則での運用がベストプラクティスとして推奨されています。必要最小限の権限のみを付与することで、ヒューマンエラーやセキュリティインシデントのリスクを低減できます。

IAMは以下の4つの構成要素で成り立っています。

ポリシー​

ポリシーは、特定のAWSリソースに対するアクセス権限を定義するJSONドキュメントです。個々のAWSサービスの個々のアクションに対して、許可（Allow）または拒否（Deny）を指定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

ポリシーにはAWSが事前に作成したAWS管理ポリシーが多く用意されていますが、ユースケースによってはAWS管理ポリシーが必要以上に広い権限を持つ場合があります。そのような場合は、より制限の厳しいカスタム管理ポリシーを作成することが推奨されます。

IAMユーザー​

IAMユーザーは、ルートユーザーのアカウント内に作成する仮想ユーザーです。個々の作業者や用途ごとに作成します。

IAMユーザーの特徴は以下の通りです。

• 作成時点では一切のアクセス権限がない（明示的にポリシーをアタッチする必要がある）
• デフォルトではマネジメントコンソールへのアクセスが許可されていない（必要に応じて有効化する）
• IAMユーザーへの直接的なポリシーのアタッチは非推奨（後述するユーザーグループ経由が推奨）

ユーザーグループ​

ユーザーグループは、単数または複数のIAMユーザーの集合です。ユーザーグループにポリシーをアタッチすると、そのグループに所属するすべてのIAMユーザーにポリシーが伝播します。

ユーザーグループ経由の権限管理が推奨される理由は以下の通りです。

• 担当や部門ごとにグループを作成し、必要最小限のポリシーをアタッチできる
• 担当変更時はIAMユーザーのグループ所属を変更するだけで権限が切り替わる
• 個々のIAMユーザーに直接ポリシーを管理する必要がなくなる

ロール​

ロールは、AWSリソース同士のアクション許可や、IAMユーザーへの一時的な権限付与に使用します。

AWSリソースは、そのリソースを作成したIAMユーザーの権限に関係なく、デフォルトでは他のAWSリソースへのアクセス権を一切持ちません。例えば、Lambda関数からS3バケットにアクセスする場合、Lambda関数に対してS3へのアクセスを許可するロールを明示的にアタッチする必要があります。

このように、AWSでは最小権限の原則を徹底するために、AWSリソースはデフォルトで他のリソースへのアクセス権を持たない設計になっています。

また、IAMユーザーに本来のポリシーとは異なる一時的な作業が必要になった場合に、ロールを使って一時的に権限を付与することも可能です。

AWSの全操作はAPIコール​

AWSの全サービスがポリシーベースのアクセス許可を前提としている背景には、AWSにおけるすべての操作がAPIコールで行われているという仕組みがあります。IAMユーザーがマネジメントコンソールで操作を行った場合も、バックグラウンドではCLIと同様のAPIコールが実行され、ポリシーに基づいた認可処理が行われています。AWSリソース同士のアクションにおいても同様です。

使用されていないIAMユーザーの管理​

不要になったIAMユーザーに対しては、以下の措置を講じてセキュリティリスクを低減します。

• 権限の剥奪（ポリシーのデタッチ、ユーザーグループからの削除）
• アクセスキーの削除
• マネジメントコンソールへのアクセス無効化
• 不要であればIAMユーザーの削除

まとめ​

この記事では、AWSにおけるIAMと最小権限の原則について解説しました。ルートユーザーのロックダウンを行った上で、IAMの4つの構成要素（ポリシー、IAMユーザー、ユーザーグループ、ロール）を組み合わせて、必要最小限の権限のみを付与する運用がAWSのベストプラクティスです。ポリシーはユーザーグループ経由でIAMユーザーに適用し、AWSリソース同士のアクセスにはロールを使用することで、セキュアで管理しやすいアクセス制御を実現できます。

参考リンク:

• AWS IAM公式ページ
• IAMベストプラクティス
• 最小権限の原則への体系的アプローチ
• AWS CloudTrail