サイトアイコン IT & ライフハックブログ｜学びと実践のためのアイデア集

AWS IAMの基礎と権限設計：Google Cloud IAM・Microsoft Entra ID／Azure RBAC比較

greeden

AWS IAMを設計するときは、先にサービス名やJSONの書き方を覚えるより、誰が、どのリソースに、どの操作を、どの条件で実行できるのかを整理する必要があります。

人のログインとシステムの実行主体を分け、必要な権限だけをロールで渡し、組織のガードレールと監査ログで継続的に見直すことが基本です。

この記事では、AWS IAMを軸に、Google Cloud IAM、Microsoft Entra ID、Azure RBACの役割を対応づけ、権限設計を実務へ落とし込む手順を解説します。

IAMを理解するための三つの用語

アイデンティティとは、アクセスする人やプログラムを識別する情報です。

認証は、その主体が名乗った本人または正当なシステムであることを確かめる処理です。

認可は、認証済みの主体に、どの操作を許可するかを決める処理です。

IAM（Identity and Access Management）は、これらの情報を使って「誰が、何に、何をできるか」を制御します。

IdP（Identity Provider）は人の認証元であり、ロールやポリシーはクラウド上の認可を表します。

この二つを分けて考えると、SSO、MFA、IAMロール、アクセス権の関係を整理しやすくなります。

AWS、Google Cloud、Microsoftの対応関係

三つのクラウドには似た部品がありますが、同じ名前や評価方式ではありません。

比較するときは、製品名ではなく、ID、認可、ワークロード、組織ガードレールの四層に分けます。

設計層 AWS Google Cloud Microsoft Azure
人のID IAM Identity Centerまたは外部IdP Googleアカウント、グループ、フェデレーションされたID Microsoft Entra ID
クラウドリソースの認可 IAMロールと各種ポリシー プリンシパル、ロール、リソースに対するAllow、Denyなどのポリシー Azure RBACのロール割り当て
ワークロードのID サービスに関連づけたIAMロール サービスアカウントやWorkload Identity Federation マネージドIDやサービスプリンシパル
組織の制御 AWS OrganizationsのSCPなど リソース階層、Organization Policy、IAMのDenyなど Management Group、Azure Policyなど

Microsoft Entra IDのロールはディレクトリ内の管理権限を扱い、Azure RBACはAzureリソースへのアクセスを扱います。

同様に、Azure Policyはリソース構成の基準を適用する仕組みであり、Azure RBACのロール割り当てそのものとは役割が異なります。

クラウド全体の特徴を先に整理したい場合は、AWS、Azure、Google Cloud、OCIの実務比較も参考になります。

AWS IAMのポリシー評価

AWSのリクエストは原則として暗黙的に拒否され、適用されるポリシーによる明示的な許可が必要です。

一方、適用対象のポリシーに明示的な拒否があれば、明示的な許可より拒否が優先されます。

ただし、クロスアカウントアクセスやリソースベースポリシーが関係する場合は評価経路が増えるため、「どこかにAllowが一つあれば通る」とは限りません。

四つのポリシーを役割で分ける

種類 付与先 主な役割
アイデンティティベースポリシー ユーザー、グループ、ロール 主体が実行できる操作を定める
リソースベースポリシー S3バケットなど対応リソース リソース側からアクセス元と許可範囲を定める
Permissions boundary ユーザーまたはロール アイデンティティベースポリシーで付与できる権限の上限を定める
SCP 組織のルート、OU、メンバーアカウント 組織配下で利用できる権限の上限を定める

Permissions boundaryとSCPは権限を付与するポリシーではありません。

アイデンティティベースポリシーが操作を許可していても、上限側で許可されていなければ実行できないという関係です。

SCPはAWS Organizationsの管理アカウント内のユーザーやロールには作用しないため、管理アカウントの保護は別に設計します。

最小構成のJSONポリシー

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

この例は、指定したS3バケットのreports/以下にあるオブジェクトを読む操作だけを許可します。

実務では、誰に付けるのか、ほかにどのポリシーが作用するのか、条件を追加する必要があるかまで確認します。

人とワークロードのIDを分ける

権限設計の最初の分類は、人、クラウド上のワークロード、外部システムです。

人のアクセス

従業員や委託先のアクセスは、可能な範囲で組織のIdPに集約し、SSOから権限セットやロールへ割り当てます。

これにより、入社、異動、退職に伴うIDライフサイクルを一つの管理経路に寄せやすくなります。

ただし、各クラウドにローカルユーザーや長期キーが残っていれば、IdPでアカウントを無効化するだけではアクセスを完全に止められません。

クラウド上のワークロード

アプリケーションには、人用のパスワードやアクセスキーを埋め込まず、実行環境に関連づけたロールから短期認証情報を取得させます。

EKSの認証と運用を詳しく確認したい場合は、Amazon EKS、GKE、AKSの運用比較で周辺設計を確認できます。

外部システム

他クラウド、オンプレミス、外部SaaSからのアクセスは、対応するフェデレーション方式で短期認証情報へ交換できるかを先に検討します。

長期キーが避けられない場合は、保管場所、利用者、失効、ローテーション、監査の手順を例外管理として明文化します。

最小権限を作る手順

最小権限は、最初から細かなJSONを書くことではなく、業務に必要な操作を説明できる状態を保つことです。

  1. 主体を特定する
    管理者、開発者、監査担当、バッチ、アプリケーションなど、権限を使う主体を分けます。
  2. 対象リソースを絞る
    アカウント全体ではなく、対象のバケット、テーブル、関数、環境を特定します。
  3. 必要な操作を列挙する
    閲覧、更新、デプロイ、権限管理など、実際の作業に対応するAPI操作を選びます。
  4. 条件と有効時間を検討する
    MFA、接続元、タグ、セッション時間など、許可を狭める条件を確認します。
  5. ログとエラーで調整する
    業務を妨げない範囲で段階的に適用し、必要な操作だけを残します。
  6. 定期的に棚卸しする
    使われていないロール、退職者、例外、長期キー、過剰なワイルドカードを見直します。

管理者、開発者、閲覧者という三つのロールは出発点になりますが、すべての組織にそのまま当てはまる完成形ではありません。

担当業務とリソース境界が異なるなら、ロールを分け、不要な操作を外します。

マルチアカウントとマルチクラウドの境界

権限を個別に設定する前に、どの階層へガードレールを置くかを決めます。

クラウド 主なリソース階層 設計上の注意
AWS Organization、Root、OU、Account SCPはメンバーアカウントの権限上限であり、管理アカウントには別の保護が必要
Google Cloud Organization、Folder、Project、Resource 上位階層のIAMポリシーや組織ポリシーが下位へ影響する
Azure Management Group、Subscription、Resource Group、Resource Entra IDのテナントとAzure Resource Managerのスコープを混同しない

AWSでOUとSCPを設計するときは、AWS Organizationsと各クラウドのリソース階層も併せて確認してください。

人のIDを一つのIdPへ寄せる設計は、退職や異動への対応をそろえるうえで役立ちます。

一方、各クラウド固有の認可モデル、緊急用アクセス、サービスID、監査ログまですべて同じ仕組みになるわけではありません。

ゼロトラストとIAMの関係

ゼロトラストは「ネットワークを使わない」という意味ではなく、社内ネットワークにいるという理由だけでアクセスを信頼しない考え方です。

IAMでは、主体、対象、操作、端末やMFAなどの条件を確認し、必要な範囲へ権限を絞ります。

Microsoft Entra Conditional Accessは認証後のアクセス判断にIDや端末などのシグナルを使う機能であり、Azure RBACはAzureリソースに対する操作権限を決める仕組みです。

両者を組み合わせると、ログイン条件とリソース権限を別々の層で制御できます。

設計レビューに使えるチェックリスト

確認項目 決めること 残す証拠
IDソース 人のIDをどこで作成、変更、無効化するか IdPと同期範囲の一覧
主体の分類 人、ワークロード、外部連携をどう分けるか 主体と所有者の台帳
標準ロール 職務ごとに必要な操作と対象をどう定めるか ロール定義と承認記録
長期認証情報 例外を誰が承認し、いつ失効または交換するか キーと例外の台帳
組織ガードレール SCPや各クラウドの組織制御をどの階層へ置くか 検証結果と適用範囲
監査ログ 誰が、いつ、何をしたかをどこへ保存するか 保存先、保持方針、アラート
棚卸し ロール、例外、未使用権限をいつ見直すか レビュー結果と是正期限
障害対応 誤った拒否や緊急付与にどう対応するか Runbookと事後レビュー

監査証跡の保存と調査方法は、AWS CloudTrail、Cloud Audit Logs、Azure Activity Logの比較で詳しく解説しています。

規模別の設計例

次の例は、特定企業の導入実績ではなく、設計判断を確認するための一般的なモデルです。

少人数の開発チーム

人のログインをIdPとIAM Identity Centerへ寄せ、管理、開発、閲覧など少数の権限セットから始めます。

ただし、管理ロールを日常作業で使い続けず、ワークロードには人と別のロールを割り当てます。

複数部門を持つ組織

本番、検証、共有基盤、セキュリティなどの境界に合わせてアカウントとOUを分け、SCPを小さな適用範囲で検証してから広げます。

管理アカウント、サービスリンクロール、緊急時の手順にはSCPだけで対応できないため、別の統制を用意します。

マルチテナントSaaS

AWS IAMが制御するのはAWSリソースへのアクセスであり、利用企業ごとの業務データ権限はアプリケーション側でも検証する必要があります。

テナントIDによる認可、データの分離、ワークロードのIAM権限を別の層として設計し、一つの仕組みに責任を集中させないことが大切です。

最初に着手する五つの作業

  1. 人、ワークロード、外部連携を一覧にし、それぞれの所有者を決める。
  2. 人のログイン経路と、残っているIAMユーザーや長期キーを確認する。
  3. 高権限ロールから利用目的、対象リソース、利用条件を文書化する。
  4. ワークロードの静的な認証情報を、実行環境のロールへ段階的に移す。
  5. 監査ログ、権限レビュー、例外対応を定期運用として担当者へ割り当てる。

JSONポリシーの最適化だけを先に進めると、不要なIDや例外運用が残ります。

主体の台帳、認証経路、権限の上限、ログ、棚卸しを一つの運用としてつなげることで、最小権限を維持できます。

確認に使える公式資料

権限設計の結論

AWS IAMの中心は、ロールやポリシーの数ではなく、必要なアクセスを説明し、不要になった権限を外せる運用です。

人には統一した認証経路、ワークロードには短期認証情報、組織には権限の上限、運用にはログとレビューを用意します。

Google CloudやAzureでも同じ設計課題はありますが、ポリシーの種類と階層は異なるため、共通方針とクラウド固有の実装を分けて管理してください。

この記事に関連する株式会社greedenの取り組み

権限設計は、開発時だけでなくリリース後の運用まで見通してこそ定着します。株式会社greedenは、要件定義から設計、実装、テスト、保守改善まで、Webシステム開発を一貫して支援します。

モバイルバージョンを終了