AWS IAM（IAMユーザー、IAMグループ、IAMポリシー、IAMロール）

2020年12月8日2026年3月27日

IAM（Identity and Access Management）とは AWS の各リソースに対する認証認可の機能を提供するサービスです。

IAM の仕組みについて

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/intro-structure.html

ルートユーザー（root ）

AWS アカウントのルートユーザーは、その AWS アカウントを作成したときに最初から存在する特別なユーザーです。AWS アカウントを作成するために使用したメールアドレスとパスワードは、ルートユーザーとしてサインインするために使用する認証情報です。

アカウント所有者です。
AWS アカウントの作成時に作成されます。

基本的にルートユーザーは封印しておきます。

ルートユーザーしかできないこと

ルートアカウントの設定を変更する。（アカウント名、E メールアドレス、パスワード、アクセスキーなど）
特定の税務関連・請求書を表示する。
AWS アカウントを解約する。
IAM ユーザーアクセス許可を復元する。
AWS サポートプランを変更する、AWS サポートプランをキャンセルする。
リザーブドインスタンスマーケットプレイスに出品者として登録する。
MFA（多要素認証）
Delete に対応するように Amazon S3 バケットを設定する。
無効な VPC ID または VPC エンドポイント ID が含まれている Amazon S3 バケットポリシーを編集または削除する。
GovCloud へのサインアップをする。
CloudFront のキーペアを作成する。 (非推奨、AWS アカウントの root ユーザーが必要)

CloudFront のキーペアを作成するのが、非推奨となっている理由ですが、昔の CloudFront の署名付き URL / 署名付き Cookie の方式では CloudFront key pair を使い、その作成・管理に AWS アカウントの root ユーザー が関わります。しかし今はその方式より、trusted key groups を使う方式を推奨しています。

IAM ユーザー

IAM ユーザーは AWS で作成するエンティティであり、AWS とやり取りするためにこれを使用するユーザーまたはアプリケーションを表します。AWS のユーザーは名前と認証情報で構成されます。近年は IAM ユーザーを増やすのではなく IAM ロール中心や管理するなら IAM Identity Center を利用するなどが大きな方向性となっています。また、MFA の徹底なども必須の流れとなっています。

IAM グループ

IAM ユーザーグループとは、IAM ユーザーの集まりです。

ユーザーグループを使用すると、複数のユーザーに対してアクセス許可を指定でき、それらのユーザーのアクセス許可を容易に管理することができます。

IAM ポリシー

ポリシーはアイデンティティやリソースに関連付けられて許可を定義します。

アイデンティティベースのポリシー

IAM ユーザー、グループ、ロールにアタッチされます。IAMアイデンティティベースポリシーとも言います。

リソースベースのポリシー

リソースにアタッチします。S3バケットポリシーなど。

ポリシーの大原則

どこかに明示的な拒否（Explicit Deny）が1つでもある場合 → Deny（絶対）
Deny がないなら、Allow がどこかに1つでもある場合 → Allow
Allow がどこにも当たらなければ → Implicit Deny（デフォルト拒否）

属性ベースのアクセス制御（ABAC）

属性に基づいてアクセス許可を定義することもできます。AWS では、これらの属性を「タグ」と呼びます。

プリンシパルのタグがリソースタグと一致する場合に操作を許可する ABAC ポリシーを設計できます。

IAMロール

IAMユーザーやグループやポリシーはどのようなものかすぐに想像できると思いますが、IAMロールが若干複雑な概念になります。

今まで AWS の公式サイトや BlackBelt などで IAM について勉強してきましたが、正直あいまいな理解で終わっていました。しかし以下のサイトで IAM ロールの説明をしていますが、「IAM ロールとはお面のようなものである」という説明が一番イメージできてしっくりときました。

IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた

https://dev.classmethod.jp/articles/iam-role-passrole-assumerole

実際に IAM ロールを作成してみます。

IAM のダッシュボードに移動し左側ペインより「ロール」をクリックします。

「ロールを作成」ボタンをクリックします。

「ロールの作成」画面を確認すると、以下の4つの「信頼されたエンティティ」を選択できます。

AWS サービス（EC2、Lambda、およびその他）
別の AWS アカウント（お客様またはサードパーティーに属しています）
ウェブ ID（Cognito または OpenID プロバイダ）
SAML 2.0 フェデレーション（企業ディレクトリ）

IAM ロールに対してポリシーをアタッチできます。下図は例として「AmazonS3ReadOnlyAccess」ポリシーをアタッチしています。

IAM エンティティ

AWS によって認証に使用される IAM リソースオブジェクトです。

これらには、IAM ユーザーおよびロールが含まれます。

IAM エンティティと IAM プリンシパルの違い

IAM エンティティは IAM ユーザーやロールという「作成される主体（名詞）」を指します。

IAMプリンシパルはリソースにアクセスする「認証された主体（動詞：誰が）」を指します。

実質的には同じものを指すことが多いですが、プリンシパルは特に「認証とアクセス権限行使」のコンテキストで使われます。

プリンシパル（Principal）

プリンシパル（Principal）は、IAMポリシー内でリソースへのアクセス権を持つ「主体（誰が）」を表しています。例えば、IAMユーザー、ロール、ルートユーザー、フェデレーティッドユーザー、AWSサービスなどが該当し、リソースベースのポリシーにおいてアクセス許可の対象を定義します。

ポリシーで定義された権限を受け取るユーザー、サービス、またはアカウントを指します。例えば「AはCに対してBを実行する権限を持っている」という文の場合、プリンシパルはAになります。

プリンシパルの例

AWS アカウント
IAM ユーザー
IAM ロール
フェデレーティッドユーザー
AWS サービス

Access Advisor について

IAM の Access Advisor は、特定の IAM ロールやユーザーが AWS サービスに最後にアクセスした時期に関する情報を提供します。Access Advisor の Last Accessed Data に IAM エンティティ(ユーザー、グループ、ロール) が最後に AWS サービスにアクセスした⽇付と時刻が表⽰されるので、IAM アクセス権限の分析ができます。

Access Advisor と Access Analyzer の違い

Access Advisor　←　その IAM エンティティが 何を使ったかの履歴を見る
Access Analyzer　←　その権限やリソース共有が 安全か、過剰か、外部に開いていないかを分析する

IAM Access Analyzer は、外部公開や外部共有、内部共有、未使用アクセス、ポリシーの妥当性、ポリシー生成 まで含めて分析する機能です。S3 バケットが外部アカウントや公開状態になっていないか、KMS キーや IAM ロールが外部エンティティに共有されていないかなど分析ができます。

AWSインフラ研究所

AWS IAM Access Analyzer

https://go-journey.club/archives/18673

Black BeltAWS IAM Access AnalyzerAWS IAM Access Analyzer とはAWS IAM Access Analyzer とは「その権限や共有設定で、誰が何にアクセスできてしまうか」を検出するサービスです。特に強いのは、意図しない外部公開、重要リソースへのアクセス経路、使われていない権限、危険なポリシーを見つけることです。IAM Access Analyzer ポリシーの生成IAM Access Analyzer は AWS CloudTrail ログを確認し、指定した日付範囲内のロールが使用したアクセス許可を含むポリシーテンプレートを生成します。テンプレートを使用して、特定のユース...

タグを使用した AWS リソースへのアクセス制御

リソースタグを利用して AWS リソースへのアクセス制御ができます。

【参考】リソースタグを使用した AWS リソースへのアクセスの制御

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_tags.html

署名付き URL と署名付き Cookie を作成できる署名者の指定

https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html#private-content-creating-cloudfront-key-pairs

MFA（多要素認証）

IAM ユーザーまたは AWS アカウントのルートユーザーに対して MFA を有効にすることができます。IAM ユーザーの仮想 MFA デバイスを有効にするには、AWS マネジメントコンソール、AWS CLI コマンドまたは AWS API オペレーションを使用します。（ただし、AWS ルートユーザーの場合は AWS マネジメントコンソールから実行する必要があります。）

（IAMユーザーの場合）

（ルートアカウントの場合）

【例】特定の S3 バケットへのアクセスに MFA を必須とする

特定の S3 バケットへアクセスする用に IAM ロールを作成しているとします。そのロールにスイッチするために MFA を必須とする場合のポリシーの設定例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWSアカウントID>:user/<ユーザー名>"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Condition を付けて MultiFactorAuthPresent を必須とします。

■SSL 証明書の管理について

IAM は、ACM でサポートされていないリージョンで HTTPS 接続をサポートする必要がある場合にのみ、証明書マネージャーとして使用します。
IAM はプライベートキーを安全に暗号化し、暗号化されたバージョンを IAM SSL 証明書ストレージに保存します。

アクセスレベルについて

AWS アカウントのセキュリティを向上させるには、IAM ポリシーを定期的に確認し、モニタリングする必要がありますが、ポリシーを確認する場合、そのポリシー内の各サービスのアクセスレベルの要約を含むポリシー概要を表示できます。
AWS は、各サービスのアクションを、各アクションが実行する内容に基づいて、5 つのアクセスレベル (List、Read、Write、Permissions management、または Tagging) のいずれかに分類します。

IAM データベース認証

DB クラスターに対して認証を実行するには、AWS IAM データベース認証を使用します。
IAM データベース認証は Aurora MySQL および Aurora PostgreSQL で利用できます。
パスワードを使用せずに認証トークンを使用します。

IAM でのセキュリティのベストプラクティス

IAM のクロスアカウントアクセス

IAM ロールを使用して、別の AWS アカウントにあるリソースへアクセスさせることができます。

特定の AWS アカウントにあるリソースを別の AWS アカウントのユーザーと共有します。

例えば、企業 A がサービスを顧客 B に提供していて、更に企業 A は顧客 B のEC2 インスタンスのログなどを必要するとします。

その場合、顧客 B にてクロスアカウントアクセス用の IAM ロールを作成して、企業 A がその IAM ロールを引き受けます。

それによりアカウントが異なっていても安全に外部からアクセスさせることができるようになります。

SAML（Security Assertion Markup Language）

AWS は SAML 2.0 (Security Assertion Markup Language)を使用した ID フェデレーションをサポートしています。

SAML は、多くの ID プロバイダー (IdP) により使用されているオープンスタンダードです。

この機能はフェデレーティッドシングルサインオン(SSO)を有効にします。

SAML を利用すると、組織内の全員について IAM ユーザーを作成しなくても、ユーザーは AWS マネジメントコンソールにログインしたり、AWS API オペレーションを呼び出したりできるようになります。

SAML は Wikipedia によると OASIS で標準として策定されたマークアップ言語で、主にシングルサインオンやID連携で利用されているとあります。

SAML とは言語であり、シングルサインオンを実現する場合に利用します。

上でも例にあるように一般的な企業では AWS にログインする際にはすでにある Active Directory のアカウントとパスワードは利用せずに、別途作成した IAM ユーザーとパスワードを設定してログインしてもらっていますが、SAML を利用することで Active Directory で作成したアカウントとパスワードでそのまま AWS の管理コンソールにログインして利用できるようになります。

ID プロバイダー（IdP）

主な ID プロバイダー

Microsoft Entra ID
Okta Identity Cloud
HENNGE One
CloudGate UNO
Gluegent Gate
Keycloak

IAM 認証情報レポート（Credential Report）

アカウントのすべてのユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータス最終使用日時が示された認証情報レポートを生成し、ダウンロードできます。例えば誤ってアクセスキーが流出した場合に、実際に流出したアクセスキーを利用された形跡があるかを確認することができます。インシデントが発生した場合の調査に利用できます。

各種認証情報のステータス

以下のステータスを確認できます。

IAM ユーザーのアクセスキーの作成日
アクセスキーの最終使用日
MFA の有効化状況
パスワードの最終変更日

NotPrincipal について

■AWS JSON ポリシーの要素: NotPrincipal

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_notprincipal.html

“Effect”: “Deny” で明示的にすべて拒否してから例外を与えていきます。

ただし、アクセスを許可されてはいないので、別途明示的に許可（”Effect”: “Allow”）の設定をする必要があります。

■例

{
    “Version”: “2012-10-17”,
    “Statement”: [{
        “Effect”: “Deny”,
        “NotPrincipal”: {“AWS”: [
            “arn:aws:iam::444455556666:user/Bob”,
            “arn:aws:iam::444455556666:root”
        ]},
        “Action”: “s3:*”,
        “Resource”: [
            “arn:aws:s3:::BUCKETNAME”,
            “arn:aws:s3:::BUCKETNAME/*”
        ]
    }]
}

上記の例では「arn:aws:iam::444455556666:user/Bob」が許可されたわけではなく、「拒否されていない」という意味になります。

その為、別途許可する必要があります。

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

サイト管理人

コメントする

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。