1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@handson-lab(ハンズオンラボ)

AWSのIAMを「とりあえず管理者権限」で運用してはいけない理由

1
Posted at

はじめに

「とりあえず管理者権限つけておけばエラー出ないから」

SESエンジニアとして複数の現場を経験してきた中で、この言葉を何度聞いたか分かりません。特にプロジェクト初期の忙しい時期、IAMの設計に時間をかけたくないという気持ちは理解できます。作業が止まる方がよっぽど困る。そういう現場の空気感は確かにあります。

でも、「とりあえず管理者権限」の運用は、後になって必ず代償を払うことになります。

私が関わった案件でも、開発用のIAMユーザーにAdministratorAccessが付いたまま運用されていたことがありました。そのユーザーのアクセスキーがGitHubのパブリックリポジトリに誤ってコミットされ、数時間のうちに大量のEC2インスタンスが知らない誰かによって起動された——という話ではありませんが、そうなってもおかしくなかったという状況は確実にありました。

この記事では、「管理者権限でいいや」がなぜ危ないのか、そして現場で今すぐできる改善を具体的に説明します。

この記事を読むと、以下のことができるようになります。

  • 管理者権限の放置がどんなリスクにつながるかが分かる
  • 最小権限の原則の考え方が理解できる
  • 今日から始められる3つの改善が分かる

実際に何が起きるか

「とりあえず管理者権限」がどんなリスクを生むのか、具体的に整理します。

アクセスキー流出時のダメージが最大になる

IAMユーザーにアクセスキーを発行して、プログラムやCLIから使うことはよくあります。問題は、そのキーが管理者権限を持っていた場合です。

もし管理者権限のアクセスキーが流出したら、攻撃者は以下のすべてを実行できます。

  • 全リージョンでEC2を無制限に起動できる
  • S3の全バケットの中身を読み取れる
  • IAMユーザーを作成して永続的なバックドアを仕込める
  • RDSのデータを全件ダウンロードできる
  • CloudTrailのログを削除して証跡を消せる

最小権限で絞られたキーなら、流出しても「S3の特定バケットにしかアクセスできない」という状態を作れます。被害の上限を設計できるのが最小権限の本質です。

誤操作の影響範囲がコントロールできない

管理者権限を持ったまま作業していると、コマンドを1つ間違えただけで本番のデータベースを削除することもできます。

「自分は注意するから大丈夫」ではなく、権限の設計で物理的に操作できないようにするのがセキュリティの考え方です。

たとえば、開発環境しか触らないエンジニアが本番のRDSに対するDeleteDBInstance権限を持つ理由はありません。持っていなければ、間違えても実行できない。

誰が何をやったか追いにくくなる

全員が管理者権限を持っていると、「この変更は誰がやったのか」が分からなくなります。

CloudTrailには操作ログが残りますが、複数の人間が同じ権限セットで動いていると、「この操作をやれる人が10人いる」という状態になります。インシデント発生時の原因特定が格段に難しくなる。

最小権限の原則（Principle of Least Privilege）とは

IAMを語るときに必ず出てくる概念です。一言でいうと、

「必要な操作だけを、必要な期間だけ、必要なリソースだけに対して許可する」

という考え方です。

「最初から絞るのは難しい」という意見もよく聞きます。確かにゼロから設計するのは手間がかかります。ただ、AWSはこれを支援するツールを用意しています。

IAM Access Analyzerを使うと、実際の利用状況から「このユーザーが過去90日間で使ったアクションはこれだけ」という分析ができます。後から絞っていく、という現実的なアプローチが可能です。

# AWS CLIでIAM Access Analyzerを使って未使用の権限を確認
aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::123456789012:user/developer-01

# 結果の取得
aws iam get-service-last-accessed-details \
  --job-id <上のコマンドで返ってきたJobId>

現場でよく見る悪いパターン3選

実際の現場で目にしたことのある、よくないIAM運用をまとめます。

パターン 内容 なぜ問題か
全員にAdministratorAccess 「権限で詰まりたくない」からと全員に管理者権限を付与 流出・誤操作のリスクが全員に波及。インシデント時の追跡が困難
ルートアカウントを日常使い AWSアカウント作成時のルートユーザーで日々作業している ルートは全権限を持つ。MFAなしで流出すると取り返しがつかない
個人ユーザーのアクセスキーを共有 チーム内でアクセスキーをSlackやメモで共有して使い回す 誰が使ったか追跡不能。退職・プロジェクト離脱時の鍵管理が崩壊する

3番目の「アクセスキーをSlackで共有」は、信じられないかもしれませんが現場ではそれなりに見かけます。「急いで作業したかったから」「新人に渡す鍵の発行を後回しにしていた」——理由は理解できますが、これが一番危ない。

正しいIAM設計の考え方：ロール・グループ・ユーザーの使い分け

IAMには複数の概念がありますが、混乱しやすいのでここで整理します。

IAMユーザー

人間が使うアカウントです。1人1アカウントを原則にします。アクセスキーを発行して使う場合も、必ず個人に紐付けます。

IAMグループ

役割（開発者・運用者・閲覧者など）ごとにグループを作り、グループにポリシーをアタッチします。個人のユーザーにポリシーを直接つけるのではなく、グループを経由することで管理がシンプルになります。

# グループを作成
aws iam create-group --group-name Developers

# グループにポリシーをアタッチ
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

# ユーザーをグループに追加
aws iam add-user-to-group \
  --group-name Developers \
  --user-name developer-01

IAMロール

AWSサービス（EC2、Lambda、ECSなど）が使うための権限です。EC2インスタンス上で動くアプリケーションがS3にアクセスする場合、そのEC2にロールをアタッチします。アクセスキーをEC2上に置く必要がなくなります。

// EC2がS3の特定バケットだけ読み取れるポリシーの例
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    }
  ]
}

最初の一歩：今日からできる3つの改善

「全部は無理でも、これだけはやろう」という優先度の高い3つを紹介します。

1. MFAの有効化

ルートアカウントと、管理者権限を持つIAMユーザーには必ずMFA（多要素認証）を有効にします。パスワードが流出しても、MFAがあれば二段階目の認証がなければログインできません。

AWSコンソールから設定する場合：

  1. IAM → ユーザー → 対象ユーザーを選択
  2. 「セキュリティ認証情報」タブ → 「MFAデバイスの割り当て」
  3. Google AuthenticatorなどのTOTPアプリでQRコードをスキャン

ルートアカウントのMFA設定は特に最優先です。AWSのトップナビゲーションに「ルートユーザーのMFAを推奨します」という警告が出ていたら、それを先に対処してください。

2. AdministratorAccessの使用者を限定する

「誰がAdministratorAccessを持っているか」を今すぐ確認します。

# AdministratorAccessポリシーがアタッチされているエンティティを確認
aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# IAM認証情報レポートをダウンロード（全ユーザーの状態を一覧で確認）
aws iam generate-credential-report
aws iam get-credential-report \
  --query 'Content' \
  --output text | base64 -d

管理者権限が本当に必要なユーザーを除いて、より絞ったポリシーへの切り替えを検討します。「外してみて作業できるか確認する」というアプローチでも構いません。

3. CloudTrailで操作ログを有効にする

IAMの改善と並行して、誰が何をやったかを記録するCloudTrailを有効にします。

# S3バケットにCloudTrailのログを保存する設定
aws cloudtrail create-trail \
  --name my-management-trail \
  --s3-bucket-name my-cloudtrail-logs-bucket \
  --include-global-service-events \
  --is-multi-region-trail

# トレイルを開始
aws cloudtrail start-logging \
  --name my-management-trail

CloudTrailを有効にしておくと、「このリソースをいつ誰が操作したか」が後から追跡できます。何か問題が起きたときに「ログがなくて調査できない」という事態を防げます。

CloudTrail自体の操作も記録されるため、「CloudTrailのログを削除した」という操作も残ります。完全に隠蔽することはできない構造になっています。

まとめ

この記事では以下のことを解説しました。

  • 「とりあえず管理者権限」は、流出リスクの最大化・誤操作の無制限化・追跡困難という3つの問題を生む
  • 最小権限の原則は「必要な操作だけを、必要な期間だけ、必要なリソースだけに対して許可する」こと
  • よく見る悪パターンは「全員にAdministratorAccess」「ルートアカウントの日常使い」「アクセスキーの共有」
  • IAM設計の基本はユーザー・グループ・ロールの役割を理解して使い分けること
  • 今日からできる改善は「MFA有効化」「AdministratorAccess使用者の限定」「CloudTrailの有効化」の3つ

「あとで直す」と思っているIAMの設計は、たいてい直されません。プロジェクトが進むほど変えにくくなる。今日、この記事を読んだタイミングで1つだけでも動いてみてください。

ハンズオンラボでは、未経験からでも「作って覚える」をモットーにしたITハンズオンイベントを定期開催しています。

👉 イベント一覧はこちら

運営メンバーのXはこちら
えむ / わたる

面白かったら
「👇いいね」で応援

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?