はじめに

CLF試験対策を行っているときIAMとOrganizationsの違いが「うん？？」ってなったのでそれぞれのサービスについて書き留めておこうと思う

Amazon IAM(Identity and Access Managment)

AWSリソースへのアクセスを安全に管理するためのwebサービスで、「認証(相手が誰なのか確認すること)」と「認可(リソースへのアクセス権限を与えること)」を行うことができる。利用者のアクセス範囲を制御することができる。

AWSマネジメントコンソール、AWSコマンドラインツール、AWS SDK (ソフトウェア開発キット)を通じて使用し管理することが可能。

IAMのベストプラクティス

必要最小限の権限付与
ルートユーザーのアクセスキーをロックする
ロールを使用してアクセス許可を委任する
管理ポリシーを使用したアクセス許可の使用開始
ポリシーの検証
インラインポリシーではなく管理ポリシーを使用する
アクセスレベルを使用して、IAMのアクセス許可を確認する
ユーザーのために強度の高いパスワードポリシーを設定する
EC2インスタンスで実行するアプリケーションに対しロールを使用する
認証情報を定期的にローテーションする
不要な認証情報の解除
多要素認証の設定
追加セキュリティに対するポリシー条件を使用する
CloudTrailでモニタリングする

機能

ルートユーザー

AWSアカウントを作成した際に使用したメールアドレスとパスワードでサインインすると作成される。全てのリソースに対して完全なアクセス権限を持つ。

日常的な使用は厳禁！！
アクセスキーを使用すると、支払情報などの機密性の高い情報を含めたアカウントの全リソースに無制限にアクセスできてしまう。アクセスキーがある場合は削除を行い、保持する必要がある場合は定期的に変更を行うようにする(現在アクセスキーは自動削除される)

ルートユーザーしか出来ないこと

アカウントの設定変更
アカウント名、メールアドレス、ルートユーザパスワード、ルートユーザーアクセスキーのみ。それ以外の設定は管理者権限でも変更可能
他のAWSアカウントへのRoute53のドメイン登録の移行
請求情報とコスト管理コンソールへのIAMアクセスをアクティブにする
特定の税金請求書を表示
AWSアカウントを停止
リザーブドインスタンスマーケットプレイスに出品者として登録
MFAに対応するようにS3バケットを設定
無効なVPC IDまたはVPCエンドポイントIDが含まれているS3バケットポリシーを編集または削除する
GovCloudにサインアップする

IAMユーザー

付与された権限の範囲内でAWSリソースのアクセスが可能なユーザのこと。認証にはパスワードとアクセスキーの2パターンが必要
1つのアカウントで5000ユーザーの作成が可能。（グループは100こまで）

ユーザー作成時、AWSサービスのアクセスは全て拒否の設定になっている。マネジメントコンソールへはログイン可能

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

管理者権限の許可が付与されたIAMユーザーのこと。IAMの操作権限まであり、ルートアカウントしかできない権限は付与されない

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

IAM以外の全てのAWSサービスにフルアクセス権限を有するユーザー。IAMの操作権限は付与されていない

フェデレーティッドユーザー

事前にIAMロールのセキュリティ認証を使ってログインをすることができるユーザーのこと。

IAMポリシー

AWSリソースへの操作権限を設定する機能のこと。いわばルールブックみたいなもの。
認証主体(Identity:IAMユーザー、ロール、グループのこと)にアタッチして使用
複数のポリシーを適用することも可能

JSONの見方

単語	内容
Version	使用するポリシー言語のバージョンのこと。最新版は`2012-10-17`
Statement	ポリシーのメイン要素であり、以下の要素のコンテナになり複数のステートメントを含めることができる。宣言文のこと
Sid	複数のステートメントを区別するための任意のステートメントIDが含まれる
Effect	`Allow(許可)`または`Deny(拒否)`を使用してアクセス許可を指定する
Action	ポリシーで許可または拒否するアクションのリストが含まれる
Resorce	アクションが適用されるリソースのリストを指定する必要がある
Principal	アクセスを許可または拒否するアカウント、ユーザー、ロールまたはフェデレーティッドユーザーを指定する

管理ポリシーの種類

◆AWS管理ポリシー
AWS側であらかじめ用意されているポリシー。適宜更新される

ポリシーの編集は不可！！

◆カスタマー管理ポリシー
ユーザがJSONファイルなどを利用して作成し管理する。IPアドレスの制御などAWS管理ポリシーよりも細かい制御が可能。

VPCはEC2の中に含まれているので、設定する際はEC2選択後に行う

管理ポリシーの特徴

再利用可能性
1つの管理ポリシーを複数のプリンシパルエンティティ(ユーザー、グループ、ロール)にアタッチして利用する
一元化された変更管理
管理ポリシーを変更すると、アタッチされているプリンシパルエンティティに適用される
バージョニングとロールバック
カスタマー管理ポリシーを変更しても、既存のポリシーは上書きされず新しいバージョンを作成する
アクセス許可管理の委任
ポリシーで定義されたアクセス許可を制御しながら、ユーザーにアタッチとデタッチを許可できる

インラインポリシー

特定のIAMユーザーやIAMロール専用に作成されるポリシー。インラインポリシーは1つのIAMユーザーなど1対1でしかつけることができない。付与されたユーザーやロール、グループを削除すると組み込まれたポリシーも削除されるため、管理ポリシーと違い使いまわしすることはできない

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

IAMロール

AWSのサービスに対して権限を付与するための仕組み。
ロールにはパスワードやアクセスキーなどのセキュリティ情報が関連付けておらず、ロールを引き受けると一時的なセキュリティ認証情報が使用できる

IAMロールを作成し、必要なポリシーを作成したロールにアタッチし割り当てることで権限を渡すことが可能になる。アクセスキーを用いないでプログラムアクセスを実行することができる

EC2やS3にはロールの設定がされていないと初期段階で操作、編集することは不可

IAMエンティティとは？？
認証に使用されるIAMリソースオブジェクト。つまり、AWSによって認証を受ける対象となるユーザー、ロールのことを指す

信頼ポリシー

IAMロールの権限移譲するためのポリシー。第三者が利用するユーザー(例えば外部のシステム監査の人とか)に対して一時的な権限を渡すことで、ポリシーで設定されている権限を利用することができる
ロール作成画面から「AWSアカウント」を選択しユーザーを指定することで作成することができる

アクセスキー

認証情報のことで、IAMユーザーまたはAWSアカウントの長期的認証情報を指す。「アクセスキーID」と「シークレットアクセスキー」から構成されていて、アクセスキーを使用したAPIで操作命令を出すことができる。
いくつかのAWSサービスで認証するために使用できるSSL/TLS証明書（サーバ証明書）もAPIで利用可能

アクセスキーの管理が不十分だった場合、情報漏洩、サービスの不正利用、セキュリティ攻撃に悪用されしまう可能性があるため極力使用、共有したりしないようにする

長期的な認証情報はEC2インスタンス内の組み込まれるため、使用しない場合はロールで設定したほうがベスト

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

1つのアカウントのプリンシパルが別のアカウントのリソースにアクセスを許可すること。許可する場合、プリンシパルが存在するアカウントを信頼されたアカウントと呼ぶ。
クロスアカウントアクセスを許可するには、共有するリソースにリソースベースのポリシーをアタッチする。

Permission boundaly

IAMユーザーに対してあらかじめ利用できる操作の範囲を制限する機能のこと。図のように許可される権限は「IAMポリシーで権限が付与されている」かつ「Permission boundalyで利用可能な範囲として定義されている権限」になる

IAM Access Advisor

マネジメントコンソールやCLIから特定のAPIを呼び出してIAMエンティティ（ユーザー、グループ、ロール）が最後にAWSサービスにアクセスした日付と時刻を確認することができる。

IAM Database Authentication

RDSのデータベースへはユーザーIDとパスワードで認証を行うが、IAMユーザーまたはロール認証と認証トークンを使用して接続することが可能。

15分の有効期限があるためパスワードをリセットする必要はない
IAMを使用して外部的に管理されるため、ユーザー認証情報をデータベースに保存する必要はない

Amazon Organizations

複数のAWSアカウントを一元管理できるサービス。複数のアカウントをグループ化し、そのグループごとに共通ポリシーを設定することができるサービス。2つの方式を選択することができる

Consolidated Biling Only
支払い一括代行のみを実施する場合に利用する
All Feature
支払い一括代行も含めて、企業内の複数アカウントを統制したい場合に利用する

特徴

AWSアカウントの一元管理
複数のAWSアカウントを「組織単位(OU)」として管理し、その中で「管理アカウント(マネジメントアカウント)」「メンバーアカウント」と分け様々なポリシーを適用して制御することが出来る。管理アカウントは1つの組織の中に1つしか存在しない。
部署などのグループ単位でSCP(サービスコントロールポリシー)を設定することができる
新規アカウントの作成・管理
個々のAWSアカウントを作成し、内部で利用可能な権限範囲を管理することも出来る
請求とコストの一元管理
一括請求(コンソリデーティッドビリング)を使用して、組織内のすべてのAWSアカウントに対して単一の支払い方法を設定できる。それぞれのアカウントのサービス使用量を集約し、EC2やS3の従量制割引などの料金面の恩恵を受けれる
アカウント間のリソース共有
EC2リザーブドインスタンスをアカウント間で共有することができようになる。また、AWS RAM(Resource Access Manager)を用いることで、AWSアカウント間やOU間でリソースの共有を行うことができる。

SCP(サービスコントロールポリシー)

AWS Organizationsで管理しているすべてのAWSアカウント内のIAMアイデンティティ（ユーザー、グループ、ロール）に必要な特定のAWSサービスへのアクセス許可、またはそれ以外のアクセス許可するための権限範囲を設定する。ホワイトリスト、ブラックリストみたいなものを作成することによって詳細な設定を行うことができる。
SCP自体は権限を与えるものではなく「ここまでは許可できる」という境界を設定するもの。
デフォルト有効時は「FullAWSAccess」権限が付与されている

大まかな制御はSCP、特定ユーザーに対して細かな制御はIAMポリシーで設定する

AWS Control Tower

AWS Organizationsと連携して複数アカウントに対してランディングゾーン(事前設定された安全な環境)の設定を自動化するサービス。マルチアカウントのAWS環境セットアップを自動化して、各アカウントのセキュリティ設定を統制することができる。

AWS RAM(Resource Access Manager)

AWS Organizationsと連携することで、組織内のAWSアカウント間やOU間でリソースの共有を行うことができる。これによって、VPCサブネットなどの基本的なインフラストラクチャを共有し、複数のアカウントがアプリケーションリソースを同じサブネットにデプロイできるようになる

VPCをアカウント間で共有可能
共有リソースに必要な最小限の許可を付与
プライベート認証局などのリソースを一元的に管理

一括請求のメリット

①複数のアカウントに対して１つの請求
全てのアカウントによって発生したAWSコストをまとめて表示した単一の請求書が生成される
②容易な追跡
支払いアカウントに関連付けられている個々のAWSアカウントの詳細なコストレポートと料金を簡単に追跡できる
③使用料とボリューム割引の組み合わせ
全てのアカウントの使用量を組合わせてボリューム割引、リザーブドインスタンス割引、SavingsSPlanを共有することができ、実際には料金が下がる可能性がある
各アカウントの全ストレージを統合させることでS3のストレージコストを削減できる
④フリー層
一括請求を使用して複数のアカウントにわたる支払いを統合する利用者は、1つの無料利用枠にしかアクセスできず、アカウント間で統合されない

IAM Policy Simulator

アイデンティティベースのポリシー、IAMアクセスの許可の境界、組織のSCP、リソースベースのポリシーをテスト及びトラブルシューティングすることができる。

まとめ

複数のアカウント管理はOrganization
アカウント内に作成したユーザー管理はIAM

IAMとOrganizations