IAMとは

AWS Identity asd Access Managementの略。
安全に操作を実施するための認証・認可の仕組み。

・AWSアカウントないのユーザーを作成
・AWSリソースのアクセス権限を管理
・リソース間のアクセス権限を管理
・一時的なアクセス許可

個人やグループへ権限を設定できる。

< 個人 >
IAMのポリシーを設定し、許可権限を与える。

< グループ >
EC2、S3の両方のリソースにアクセスする権限が設定されています。

IAMの主要機能

・IAMポリシー
・IAMユーザー
・IAMグループ
・IAMロール

ポリシーとは
ユーザー、グループ、ロールに付与する権限をオブジェクトとして管理することです。

< IAM設定の流れ >
1.AWSサービスやAWSリソースに対する操作権限をIAMポリシーとして定義します。
2.IAMポリシーをIAMユーザーやIAMグループにアタッチします。
3.IAMユーザーあるいは、IAMグループに属するIAMユーザーがマネジメントコンソールにログインすると、付与された権限の操作を行うことができます。

IAMユーザー→利用者を特定することが前提
IAMコール→必要に応じてどのような権限を付与するかどうか役割を与えるサービス。

IAMポリシー

ユーザーにAWSサービスやAWSリソースに対するアクセス権限をJSON形式の設定ドキュメントで定義します。

作成されたポリシーをIAMユーザー、IAMグループ、IAMロールに付与することで権限の制御を行います。

ポリシーの効果として、許可を与えるポリシーと信頼を与えるポリシーが存在します。

許可ポリシー

AWSリソースへのアクセス許可・拒否を設定する通常のIAMポリシー。
許可するアクション範囲を設定します。

信頼ポリシー

特定のユーザーやリソースのアクセスを許可するための前提となる信頼を形成するためのポリシー。

信頼ポリシーが付与されているロールに基づいて、権限を委譲することができます。

IAMロールの信頼ポリシー

IAMロールは監査人などに一時的な権限を委譲する際にも利用されます。

IAMロールの権限移譲操作に特化したポリシー。
当該の信頼ポリシーを関連付けたIAMロールが保有する権限を、信頼ポリシーの操作主体であるPrincipalに移譲(許可)することができます。

IAMポリシーは、基本的にユーザーベースのポリシーと、リソースベースのポリシーです。他にも多数のポリシーが存在するので、用途によって使い分けます。

ユーザーベース(アイデンティティベース)のポリシー

管理ポリシー、インラインポリシーなど。
IAMアイデンティティ(ユーザー、グループ、ロール)にアタッチされるポリシー。

そのアイデンティティが実行できる内容を指定できます。

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

AWSリソースにアタッチさるポリシーであり、リソースに対するアクセス権限を実行します。(S3バケットポリシー、ロールの信頼ポリシー)

特定のリソース範囲のアクセスをリソース側から制御します。

JSON形式のドキュメントで定義されたインラインポリシーにアタッチして利用します。

IDベースのポリシー

アイデンティティベースのポリシーにより、特定のAWS
AWSリソースの操作権限が付与されます。

管理(マネージド)ポリシー

1つのポリシーを複数ユーザーやグループ、ロールに適応できます。

再生利用可能
1つの管理ポリシーを複数のプリンシパルエンティティ(ユーザー、グループ、ロール)にアタッチして利用可能です。

一元化されているので変更管理が簡単。

バージョニングとロールバック
カスタマー管理ポリシーを変更しても、変更されたポリシーによって既存のポリシーが上書きされずに新しいバージョンを作成します。

アクセス許可管理の委任
ポリシーで定義されたアクセス許可を制御しながら、AWSアカウントのユーザーにポリシーのアタッチを許可できます。

AWS管理ポリシーを優先して利用し、ない場合にカスタマー管理ポリシーを作成します。

AWS管理ポリシー

AWSが作成、官営しているIAM管理ポリシー。
既にAWSが設定しているポリシーがリスト化されており、適時ユーザーやロールに適応できます。
管理者権限やPowerUser、サービスごとのポリシーなどがあります。

カスタマー管理ポリシー

ユーザー自身が作成・管理するポリシーです。
同じポリシーを複数のIAMエンティティにアタッチできます。
記述法はインラインポリシーと同じですが、個別のユーザー・グループ内に閉じたポリシーなのか共有できるかの違いがあります。
最大5世代までのバージョンを管理できます。

< 使い分け >
AWS管理ポリシー→基本的な権限を付与
カスタマーポリシ→IPアドレス制限などの制約を行う
インラインポリシー→管理が煩雑になるので基本的に使わない

インラインポリシー

対象ごとに作成・付与するポリシーです。
複数のユーザー・グループに同種の権限を付与するには向いていません。

ポリシーとそれが適用されているIDとの厳密な1対1の関係を維持する際に利用します。

1つのブリンシパルエンティティ(ユーザー、グループ、ロール)に埋め込まれた固有ポリシーです。

管理ポリシーと異なり再利用できずに1つのアイデンティティにしか適用できません。

ポリシー内のアクセス権限が意図したアイデンティティ以外のアイデンティティ以外に間違って割り当てられないようにしています。

付与したアイデンティティを削除すると、そのアイデンティティに組み込まれたポリシーも削除されます。

アカウントにインラインポリシーがある場合は、管理ポリシーに変換することができます。

・インラインポリシーは、対象ごとに個別に適用する。
・管理ポリシーは、複数のユーザー・グループにまとめて適用する。
・カスタマー管理ポリシーはユーザー自身が管理する。

ユーザーのアクティビティの記録

目的に応じて様々なツールを利用して記録できます。

アクセスアナライザーは部外者アクセス発見機能。
アドバイザーは内部ユーザーのアクセス範囲の確認機能。


IAMアクセスアナライザー	S3バケットやIAMロールなどリソースベースのポリシーを確認して、信頼ゾーンの外からアクセスの有無を特定します。
IAMアクセスアドバイザー	IAMユーザーのアクセス可能なリソースと最終アクセス日時を確認することができます。
Credential Report	すべてのユーザーの認証情報が記載されたレポート
AWS Config	IAMのユーザー、グループ、ルール、ポリシーの変更履歴、構成変更を管理するサービス。
AWS CloudTrail	各種アカウントアクティビティやAPIコールををログに記録し、モニタリングするサービス。

IAMユーザー

AWSを利用するために各利用者に1つずつ与えられるIDです。
AWS上の利用者はIAMユーザーという権限を付与されたエンティティとして認定されます。

IAMユーザーの認証方法は以下の2通りです。

< ユーザーIDとパスワード >
Webコンソールにログインするときに使用します。
多要素認証(MFA)を組み合わせるのが良い。

< アクセスキーとシークレットアクセスキー >
CLIやAPIからAWSのリソースにアクセスする場合に使用します。

ルートユーザー(IAM以外)

最初に登録したメールアドレスのアカウント。
全てのAWSサービスとリソースを使用できる。
この中に、複数のユーザーを作成して共有することがで共同開発が可能。
権限が強すぎるため、日常的なタスクはルートユーザーを使用するべきではない。

【ルートユーザーのみの実施権限】
・ルートアカウントのメールアドレスやパスワードの変更
・IANユーザーの課金情報へのアクセスに関するactivate/deactivate
・他のAWSアカウントへのRoute53のドメイン登録の移行
・AWSサービスサポートのキャンセル
・AWSアカウントの停止
・コンソリデイテッドビリング(一括請求)の設定
・脆弱性診断フォームの提出
・逆引きDNS申請

管理者権限(IAMユーザー)

管理者権限の許可が付与されたIAMユーザー。
IAMの操作権限もありAWS内のほとんどのサービスにアクセスできる。
ルートアカウントしかできない権限は付与されない。

パワーユーザー(IAMユーザー)

IAM以外の全てのAWSサービスにフルアクセス権限を有する。

IAMユーザグループ

グループ全体に権限が付与されます。
グループではAWSへのアクセス認証情報は保持しません。
認証はあくまでユーザーで行い、グループは認証されたユーザーがどういった権限を持つかを管理します。

IAMロール

一時的にAWSリソースへのアクセス権限を付与する場合に使用します。
AWSリソースが別のリソースに対するアクセス権限を付与。
別のAWSアカウントのIAMユーザーにアクセス権限を委譲。

以下、使用例

〇AWSリソースへの権限付与
EC2インスタンス上で稼働するアプリケーションに一時的にAWSのリソースへのアクセスする権限を与える。EC2インスタンス作成時にロールを付与することで実現。

〇クロスアカウントアクセス
複数のAWSアカウントの間のリソースを1つのIAMユーザーで操作したい。

〇IDフェデレーション
社内のAD(Active Directory)サーバーに登録されてるアカウントを使用して、AWSリソースにアクセスしたい、

〇Wed IDフェデレーション
FacebookやGoogleのアカウントを使用してAWSリソースにアクセスしたい。

IAM権限のベストプラクティス

・人間のユーザーが一時的な認証情報を使用してAWSにアクセスするには、IDプロバイダーとのフェデレーションの使用が必要です。
・AWSにアクセスするには、ワークロードがIAMロールを使用して一時的な資格情報を使用する必要があります。
・多要素認証(MFA)が必要です。
・長期的な認証情報を必要とするユースケースのためにアクセスキーを定期的にローテーションする。
・ルートユーザーの認証情報を保護し、日常的なタスクには使用しない。
・最小特権アクセス許可を適用する。
・AWS管理ポリシーの開始と最小特権のアクセス許可への移行
・IAM Access Analyzerを使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する。
・未使用のユーザー、ロール、アクセス許可、ポリシー、認証情報を定期的に確認にして削除する。
・IAMポリシーで条件を指定して、アクセスをさらに制限する。
・IAM Access Analyzerを使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する。
・IAM Access Analyzerを使用して、IAMポリシーを検証し、安全で機能的なアクセス許可を確保する。
・複数のアカウントにまたがるアクセス許可のガードレールを確保する。
・アクセス権限の境界を使用して、アカウント内のアクセス許可の管理を委任する。

< 用語説明 >

〇IDプロバイダー(IdP)
ユーザーのIDを保存、管理を行います。
IdPは、人間のユーザーの検証に限定されません。コンピュータやデバイス、ネットワークまたはシステムに接続されているすべてのエンティティを認証できます。
IdPによって保存されるエンティティは(ユーザーではなく)、プリンシパルと呼ばれます。IdPは、ユーザーIDを管理するためにクラウドコンピューティングで最もよく使用されます。

〇フェデレーション
複数のインターネットサービス間のユーザー認証連携。
一度認証されれば、その認証情報を使用して、許可されているすべてのサービスを使えるようになる仕組み。

〇ワークロード
コンピューティングやシステムなどにかかる処理の負荷の大きさ。

〇クロスアカウントアクセス
複数のAWSアカウントをまたいたアクセス手段。

IAMグループへのポリシー適応

・自社組織に必要な権限を設計する
・自分で独自のポリシーを作成する
・グループを作成しポリシーを適応する

自社に必要な権限設計

< IT管理者 >
IT管理者としてルートユーザーも保持し、権限設定などお責任を負っている。

→アクセスの管理者権限の付与。多要素認証(MFAが)必要。

管理ポリシー Adminstrator

< 運用管理者 >
運用管理全般を担っているスタッフで、様々なモニタリングと障害対応などで直接アプリに触れることもある。

→運用ツール全般と開発環境へのアクセスも付与して、DevOpsに参加できるようにする。

DevOpsとは
開発(Development)と運用(Operations)を組み合わせた造語。
開発担当と運用担当が緊密に連帯して、柔軟かつスピーディにシステム開発を行う手法です。

ELB/EC2/RDB/S3/Auto-Scaling/VPC
Config/CloudTrail/CloudWatch

< アプリ開発者 >
主だったAWSサービスを利用してサービス開発を行っている。

→担当しているアプリの開発範囲でのみアクセス権限を付与する。

ELB/EC2/RDB/S3/Auto-Scaling/VPC

IAMロールへのポリシー適応

1.ロールを設計する。
2.ロール向けのポリシーを作成する。
3.ロールを作成しポリシーを適用する。

システム設計

システム設計からAWSサービス間の連携有無を抽出する。

〇システム設計
システム設計からAWSサービス間の連携箇所を特定。

EC2インスタンスがバッチ処理でS3にデータを保存。

↓

〇必要な権限設定の設定
リソースに対して必要な権限設定の割り出しを実施。

EC2インスタンスにS3へのアクセス権限を設定

IAMロールの権限移譲

< IAMロールの信頼ポリシー >
IAMロールは監査人などに一時的な権限を委譲する際にも利用されます。

・IAMロールの権限移譲操作に特化したポリシー
・当該の信頼ポリシーを関連付けたIAMロールが保有する権限を、信頼ポリシー操作主体であるPrincipalに移譲することができる。

< 主な流れ >
1.現在利用しているアカウントAで別アカウントBへの権限移譲用ロールを設定。
2.新規アカウントを作成して、そのアカウント内で権限移譲用ロールをポリシーとして設定。
3.2のポリシーをIAMユーザーに設定。
4.3のIAMユーザーを利用してIAMロールをスイッチすることで、アカウントAにアクセス。

アクセス権限の境界設定

Permissons boundary(権限境界)

IAMユーザーに対して権限境界を設定して、付与可能な権限範囲をあらかじめ制限できます。

Rermissions boundaryで権限範囲に入っている + IAMポリシーでアクセス許可が設定
されていると、実際に操作可能となります。

権限付与が適切にされているかを分析→アクセスアナライザー

AWS Organizations

AWS Organizationsについては以下の記事を書きました。