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

公開日時：2020年12月08日　/　最終更新日時：2021年11月20日

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

IAM の仕組みについて

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

IAMユーザー

IAM ユーザーは AWS で作成するエンティティであり、AWS とやり取りするためにこれを使用するユーザーまたはアプリケーションを表します。

AWS のユーザーは名前と認証情報で構成されます。

IAMグループ

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

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

IAMポリシー

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 ユーザーおよびロールが含まれます。

ルートユーザー

■ルートユーザーとは

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

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

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

※CloudFront のキーペアを作成するが非推奨になっているのがよく分かりません。

■Access Advisor について

Access Advisor の Last Accessed Data に IAM エンティティ(ユーザー、グループ、ロール) が最後に AWS サービスにアクセスした⽇付と時刻が表⽰されるので、IAM アクセス権限の分析ができます。（※最後にアクセス）
Access Advisor は、ユーザーのサービスアクセス監査、不要なアクセス権限の削除、IAM エンティティ (ユーザー、ロール、グループなど) が AWS サービスに最終アクセスしたタイムスタンプ取得のための適切なアクセス権限の設定を支援します。（※最後にアクセス）

■リソースアクセス制御

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

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

署名付き 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ユーザーの場合）

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

■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 の管理コンソールにログインして利用できるようになります。

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/*"
        ]
    }]
}