##1.AWS Identity and Access Management(IAM) とは？##
ユーザ等に対する権限設定を行えます。ユーザのAWSサービスおよびリソースへのアクセスを安全にコントロールするためのものです。
ユーザーおよびグループを作成および管理し、アクセス権を使用してAWS リソースへのアクセスを許可および拒否ができます。
ルートユーザではなく、必要な作業ができる権限だけを持った自分用の「IAM ユーザー」というユーザを作って普段はそちらを使いましょう！
AWSコンソールからは作ったユーザとパスワードでログインします。
コマンドやプログラムからアクセスする場合はユーザーごとに設定したアクセスキーを使ってアクセスすることとなります。
必要に応じてアクセスキーを設定します。
コマンドでアクセスしたくない場合は、設定をしない。
##2.実行できる内容##
IAMユーザー
ユーザーを作成し、そのユーザーの個々のセキュリティ認証情報、多要素認証デバイスなどを割り当てるか、一時的なセキュリティ認証情報リクエストすることによって、AWSのサービスやリソースへのアクセス権をユーザーに提供します。また、権限を管理することで、ユーザが実行できるオペレーションを制御できます。
IAMグループ
IAMユーザを束ねる機能です。１ユーザーは１０グループまで所属することができます。
IAMロール
ロールが割り当てられたエンティティやAWSのサービスが実行できるオペレーションを実行できます。
フェデレーションユーザー
企業などで導入されている認証の仕組みとAWSの認証の仕組みを紐付けます。
##3.ルートユーザー##
ルートユーザの認証情報の権限を制限することはできないため、ルートユーザーのアクセスキーを削除することをおすすめします。
管理レベルの権限が必要な場合は、IAMユーザーを作成し、そのユーザーにそのユーザーにすべての管理アクセスを付与してから、その認証情報を使用して、AWSを操作します。
ルートユーザでしかできないこと。
AWS アカウントのルートユーザー 認証情報が必要な AWS タスク
##4.AWSにアクセスする方法##
- プログラムによるアクセス
- アクセスキーIDとシークレットアクセスキーを使って、AWSのAPI、CLI、SDKおよびその開発ツールを利用できます。
##5.IAMポリシー##
ユーザ、グループ、ロールに権限を割り当てるためには、ポリシーを作成する必要があります。
ポリシーは権限を明示化したドキュメントです。
なお、ユーザ、グループ、ロールに割り当てることができるポリシーは1つです。
-
管理ポリシー
-
AWS管理ポリシー:AWS側が作成して管理するポリシー
-
カスタム管理ポリシー:AWSアカウントで作成、管理するポリシー
-
インラインポリシー:ユーザ、グループ、ロールにアタッチするポリシー
下記はポリシーの例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
}
]
}
## Effect で Allow か Deny
## Action で 対象のAWSを指定
## Resource で対象のAWSリソースを ARN で記述。
AND条件とOR条件
Condition下のブロックはAND条件、演算子に対する値はOR条件。
アクセス可否のロジック
暗黙的なDeny < 明示的なAllow < 明示的なDeny
##6.IAM ユーザーは1 人に1 つ##
本著では1 人だけで作業をする想定なので、IAM ユーザーも1 人しか作りません。
ですがもし業務などで複数名でマネジメントコンソールにサインインする場合は、IAM ユーザーは必ず1 人につき1 つずつ作成してください。まったく同じ作業をするから開発チーム内のA さんとB さんは同じIAM ユーザを共有すればいいのでは？ と思われる場合でも、必ずA さんB さんそれぞれに別々のIAM ユーザーを用意することをお勧めします。
なぜならばAWS では「いつ・どのIAM ユーザーが・なにをしたのか」をすべて記録していて、後から調べることができるのですが、仮にA さんとB さんが1 つのIAM ユーザーを共用していた場合、何か重大なトラブルが起きたとき*7に「結局、誰がやらかしたのか？」を人単位で追いかけることができなくなってしまうからです。
##7.IAM のベストプラクティス##
・ルートアカウントの MFA を有効化
アカウントのセキュリティを保てるように、AWS ルートアカウントで多要素認証（MFA）を有効化して、別の保護レイヤーを追加します。
・個々の IAM ユーザーの作成
IAM ユーザーを作成して、必要なアクセス許可のみを付与します。ルートアカウントには AWS リソースへの無制限のアクセス許可が付与されるため、日常の操作にルートアカウントを使用しないでください。
・グループを使用したアクセス許可の割り当て
アカウントのアクセス許可の管理と監査を簡略化するため、IAM ユーザーへのアクセス許可の割り当てに IAM グループを使用してください。
・IAM パスワードポリシーを適用すること
パスワードポリシーを使用して、強力なパスワードの作成とそれらのパスワードの定期的なローテーションを IAM ユーザーに要求します。
・アクセスキーのローテーション
定期的にアクセスキーを変更し（少なくとも年に 1 回）、誤って公開されるリスクを減らすために未使用のアクセスキーを削除してください。
##8.MFA##
多要素認証です。
＊ちなみにMFAデバイスは紛失したり、後初期化しないように！
ただ、そんな時は↓があるようです。
参考：MFA デバイスの紛失および故障時の対応
AWS IAM ハンズオン もご覧ください。
##9.ネットワーク設計の注意点##
-
異なるシステムを同一アカウント内に作るのは有りか。
→なし。アカウント単位で作るべきです。 -
では、同一システムの各環境はアカウントで分ける？VPCで分ける？
| ＋ | ー | |
|---|---|---|
| アカウントで分ける。 | 他のリソースの環境が見えない。 IAMの設定がシンプル。 |
環境ごとにIAMの設定が必要。 |
| VPCで分ける。 | IAMの設定は1度でいい。 環境間でリソースを使い回しコストメリットがある。 |
各環境のリソースが見えてしまい、作業しにくい。事故の元に。 それに避けるには複雑なIAM設計が必要。 |
##10.インラインポリシーとマネージドポリシー##
| ポリシー | |
|---|---|
| インラインポリシー | 自分で作成 |
| マネージドポリシー | AWSが予め用意 |
インラインポリシーの例
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
##11.クロスアカウントアクセス##
これは、AWSアカウントAからAWSアカウントBのAWSリソースを扱う時に用いる機能です。
- 用途
- AWSアカウントAのCloudTrailの結果をAWSアカウントBのS3に保存する。
- AWSアカウントAで作成したデータをAWSアカウントBのS3に保存する。
- SaaSプロバイダにアカウントかAからSaaS利用者アカウントBの特定のAWSリソースを参照する。
利用したことはありませんが、簡単に言うと アカウント間でアクセス可能 と言うこと。
##12.ユーザのアクティビティの記録に役立つサービス##
- IAMのアクセスアドバイザー
- 認証情報レポート
##13.AWS STS##
AWS STS は、一時的な認証情報を発行してくれるサービスです。
この3つの一時的な認証情報を使うことで、許可された別のアカウントのリソースにアクセスすることができます。
下記ののサーバーワークスさんのブログで図解やら設定でわかりやすく説明してくれているので、こちらの記事を読むと直ぐに理解できるかと思います。
##14.IAMの作成支援するツール##
- ビジュアルエディタ機能
- AWS Policy Generator
- ポリシー言語の文法チェック機能
- IAM Policy Validator
- IAM Policy Simulator
##15.IAMPolicy Simulator##
IAMポリシーのテストとトラブルシューティングに使用できるサービス。
IAMPolicy Simulator を使用した IAM ポリシーのテスト
##16.Access Analyzer##
-
Access Analyzer を有効化することで、対象のリソースタイプが信頼ゾーンの外部のエンティティからアクセス可能な状態になっていないかを確認してくれます。無料です。
設定例については、サーバーワークスさんが、動画で紹介してくれているので、下記のページがわかりやすいと思います。
【はじめてのAWS】AWS IAM Access Analyzer を設定しよう -
なお、 IAM ポリシーの作成時にチェックもしてくれるようになりました。
[アップデート] IAM ポリシーと SCP でベストプラクティスに則れ！ IAM Access Analyzer が新機能「ポリシーチェック」に対応しました
##17.ユーザーベースとリソースベース##
| ユーザーベースのポリシー | リソースベースのポリシー | |
|---|---|---|
| Principal | 無 IAMユーザー、グループ、ロールで、 指定されるのでPrincipalが存在しない。 |
有 Principalで誰がアクセスするかを指定する。 |