AWS IAM関連 の履歴差分(No.7)

• 履歴一覧
• 現在との差分 を表示
• ソース を表示
• 履歴 を表示
• AWS IAM関連 へ行く。
  • 1 (2022-12-26 (月) 12:54:20)
  • 2 (2022-12-31 (土) 19:45:31)
  • 3 (2023-01-17 (火) 09:17:49)
  • 4 (2023-01-23 (月) 09:20:14)
  • 5 (2023-01-23 (月) 21:48:28)
  • 6 (2023-01-24 (火) 15:44:38)
  • 7 (2023-01-26 (木) 11:57:10)
  • 8 (2023-02-01 (水) 10:37:02)
  • 9 (2023-02-17 (金) 22:03:27)
  • 10 (2023-03-01 (水) 13:58:22)
  • 11 (2023-03-14 (火) 22:09:07)
  • 12 (2023-03-23 (木) 10:17:12)
  • 13 (2023-04-08 (土) 12:00:45)
  • 14 (2023-04-11 (火) 11:03:46)
  • 15 (2023-04-19 (水) 09:55:47)
  • 16 (2023-04-21 (金) 14:49:29)
  • 17 (2023-05-02 (火) 21:49:11)
  • 18 (2023-05-19 (金) 14:20:17)
  • 19 (2023-05-22 (月) 00:13:23)
  • 20 (2023-06-30 (金) 13:13:19)
  • 21 (2023-07-31 (月) 18:02:08)
  • 22 (2023-08-27 (日) 21:34:51)
  • 23 (2023-10-05 (木) 15:41:13)
  • 24 (2023-10-06 (金) 22:10:51)
  • 25 (2023-10-23 (月) 13:40:50)
  • 26 (2023-10-31 (火) 09:41:45)
  • 27 (2023-11-12 (日) 14:58:19)
  • 28 (2023-11-30 (木) 18:25:37)
  • 29 (2024-03-27 (水) 09:31:58)

• 追加された行はこの色です。
• 削除された行はこの色です。

#author("2023-01-24T15:44:38+09:00","default:irrp","irrp")
#author("2023-01-26T11:57:10+09:00","default:irrp","irrp")
→認証技術

→Amazon Web Service

→AWS その他のサービス

→[[SSO関連]] ←AWS SSO/IAM Identity Center についてはこちら

#contents


*一般 [#u27d6bd8]
-[[IAM セキュリティの設定ミスの悪用とその検出方法 | コンテナ・セキュリティ | Sysdigブログ | コンテナ・Kubernetes環境向けセキュリティ・モニタリング プラットフォーム>https://www.scsk.jp/sp/sysdig/blog/container_security/iam.html]] 2022.12

-[[IAM Identity Centerの所属するユーザー名とグループ名のリストをシェルスクリプトで抽出してみた | DevelopersIO>https://dev.classmethod.jp/articles/shellscript-identitystore-list-users-in-group/]] 2022.9

-[[同じ名前のIAMプリンシパルを区別する方法 | DevelopersIO>https://dev.classmethod.jp/articles/how-to-distinct-same-iam-principal/]] 2022.9
--IAMプリンシパル名を同じにした場合、ARNは同じになりますが、ユニークIDは異なります。
--プリンシパルごとに区別したい場合はユニークIDを利用しましょう！

-[[AWSのマルチアカウント戦略が難しい！ | DevelopersIO>https://dev.classmethod.jp/articles/aws-multiaccount-muzu/]] 2022.7

-[[最小権限実現への4ステップアプローチ 前編 | Amazon Web Services ブログ>https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp/]] 2021
--[[最小権限実現への4ステップアプローチ 後編 | Amazon Web Services ブログ>https://aws.amazon.com/jp/blogs/news/systematic-approach-for-least-privileges-jp2/]] 2021

-[[AWS IAM のコントロールプレーンはバージニア北部リージョンにのみ存在しその設定内容は各リージョンのデータプレーンに伝播される | DevelopersIO>https://dev.classmethod.jp/articles/aws-iam-controlplane-dataplane/]] 2022.6

-[[AWS IAM で障害が起こったらどうなるの？ AWS IAM のレジリエンス（復元力）に関する記述がドキュメントに追記されていた | DevelopersIO>https://dev.classmethod.jp/articles/aws-iam-resilience/]] 2022.6

-[[AWS再入門ブログリレー2022 AWS IAM編 | DevelopersIO>https://dev.classmethod.jp/articles/re-introduction-2022-aws-iam/]] 2022.3

-IAMは認証だけでなくリソースの権限管理の機能も併せ持つ


*用語 [#yb881824]
-[[AWS IAM の概念をざっくり理解する - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/re-getting-started-iam]] 2022.4

-[[AWS アクセスキーとは？AWS アクセスキーの作り方や使い方を紹介！ | FEnet AWSコラム>https://www.fenet.jp/aws/column/aws-beginner/764/]] 2021.1

-API KEY（プログラムからAWS各種サービスを操作できる
--[[Amazon API GatewayでAPIキー認証を設定する>https://dev.classmethod.jp/articles/apigateway-apikey-auth/]] 2015

-MFA…多要素認証
-ARN…AWS上のリソースを一意に特定するID

-プリンシパル…認証してエンティティを使う主体のこと。以下のいずれか
--人（ユーザ、もしくはフェデレーテッドユーザ）
--アプリケーション

-IAMの管理単位
--IAMグループ…フラットな階層でしか管理できず、階層構造は持てない
--IAMユーザ
--IAMロール…EC2上で実行されるプログラムに実行権限を割り当てるのに使う、API KEYが要らなくなる

-[[AWS初心者にIAM Policy/User/Roleについてざっくり説明する | DevelopersIO>https://dev.classmethod.jp/articles/iam-policy-user-role-for-primary-of-aws/]] 2020.1
    IAM Policyは できること/できないこと を定義し、UserやRoleに紐づけて使う
    IAM Userは、Policyを紐付けて、ユーザーができることを定義する
    IAM Roleは、Policyを紐付けて、誰か/AWSのサービス ができることを定義する

-プリンシパルエンティティ…プリンシパルがポリシーを付与する対象となるエンティティのことか？
--IAMユーザ
--IAMグループ
--IAMロール

-IAMエンティティ…プリンシパルエンティティと一部被っている？
--IAMユーザ
--IAMロール

-[[AWS IAMリソース パスのススメ | DevelopersIO>https://dev.classmethod.jp/articles/aws-iam-with-path/]] 2022.5
--階層構造を作る場合は取得したい単位を考える
--後からパスの設定は不可能

-AWS STS: [[Welcome to the AWS Security Token Service API Reference - AWS Security Token Service>https://docs.aws.amazon.com/ja_jp/STS/latest/APIReference/welcome.html]]
--AWS provides AWS Security Token Service (AWS STS) as a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users you authenticate (federated users). 
--AWS STSとはIAMユーザを持っていないユーザやアプリに対して一時的に利用できるアクセスキーを付与する機能


* IAMロール [#bafdd1f9]
-[[AWSマネジメントコンソールのスイッチロール履歴を使いたくないので自動削除設定をしてみた | DevelopersIO>https://dev.classmethod.jp/articles/aws-management-console-switch-role-history-auto-delete/]] 2023.1

-[[人が使う IAM ロール（信頼されたエンティティが AWS サービスでない IAM ロール）だけを棚卸しする | DevelopersIO>https://dev.classmethod.jp/articles/iam-role-inventory-aws-cli/]] 2022.12
-[[【AWS】スイッチロールを実践してみる - BFT名古屋 TECH BLOG>https://bftnagoya.hateblo.jp/entry/2022/08/08/171735]] 2022.8

-[[IAM Roles Anywhereのハンズオンを通して、OpenSSLとか証明書とかについて勉強できたのでメモ - Qiita>https://qiita.com/hatahatahata/items/12a47fc6c3f2e528591a]] 2022.9
-[[AWS IAMロールAnywhereのPKI基盤にHashicorp Vaultを使う | DevelopersIO>https://dev.classmethod.jp/articles/hashicorp-vault-pki-for-iam-role-anywhere/]] 2022.7

-[[Assumed-role セッションプリンシパルのサービス名前空間を iam にしたが そっと sts に書き換えられた | DevelopersIO>https://dev.classmethod.jp/articles/assumed-role-session-principal-service-namespace/]] 2022.10
-[[PowerShellでassume-roleを楽にするツールaws-masqueradeを使ってみた | DevelopersIO>https://dev.classmethod.jp/articles/using-aws-masquerade-with-power-shell/]] 2022.6
-[[IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO>https://dev.classmethod.jp/articles/iam-role-passrole-assumerole/]] 2020.12

-[[同名のIAMユーザーを再作成した場合はスイッチロール先IAMロールの信頼ポリシー更新が必要 | DevelopersIO>https://dev.classmethod.jp/articles/note-when-recreating-iam-user-with-the-same-name/]] 2022.6

-[[IAMロールを削除する際にはインスタンスプロファイルに注意 | DevelopersIO>https://dev.classmethod.jp/articles/delete-iam-role-with-instance-profile/]] 2022.6
-[[[小ネタ] EC2用にIAMロールを作ったのに、EC2へ割り当てられない！ | DevelopersIO>https://dev.classmethod.jp/articles/how-to-create-iam-instance-profile-using-amc/]] 2022.5
-[[帽子をかぶって、スイッチロールをマスターしよう - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/switch-role]] 2022.4
-[[IAMのスイッチロールを理解したい | DevelopersIO>https://dev.classmethod.jp/articles/iam-switchrole-for-beginner/]] 2020.2
--複数のアカウントで作業する際にアカウントの切り替えを楽にする機能

-[[【小ネタ】GitHub Actions用のIAMロールをAWSマネジメントコンソールから作成する際の注意点 | DevelopersIO>https://dev.classmethod.jp/articles/create-iam-id-provider-for-github-actions-with-management-console/]] 2021.11


* IAMユーザ管理 [#zeac37cb]
-[[IAMユーザーのパス設定を変更してみる | DevelopersIO>https://dev.classmethod.jp/articles/change-iam-user-path/]] 2022.8

-[[あれ？ログインして使っているIAMユーザー自身とかIAMロールって削除できるんだっけ？を実際にやってみた | DevelopersIO>https://dev.classmethod.jp/articles/can_delete_current_loggedin_iam_user/]] 2022.8

-[[AWS アカウント・ユーザ設計について - Qiita>https://qiita.com/yu-yama-sra/items/c300c65d6a1a24492631]] 2019

-[[IAM ユーザーのパスワードの管理 - AWS Identity and Access Management>https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_passwords_admin-change-user.html]] 
--AWS Management Console にサインインして、IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
--ナビゲーションペインで [Users] (ユーザー) を選択します。
--パスワードを変更するユーザーの名前を選択します。
--[認証情報] タブを選択してから、[サインイン認証情報] で [Console password (コンソールパスワード)] の横の [パスワードの管理] を選択します。
--[Manage console access (コンソールアクセスの管理)] の [Console access (コンソールアクセス)] で、[Enable (有効化)] を選択します (まだ選択していない場合)。コンソールアクセスが無効になっている場合、パスワードは不要です。
--[Set password (パスワードの設定)] で、IAM によってパスワードを自動的に生成するか、カスタムパスワードを作成するかを選択します。
--ユーザーに初回サインイン時に新しいパスワードの作成を求めるには、[Require password reset (パスワードのリセットが必要)] を選択します。次に、[Apply (適用)] を選択します。
重要
--[Require password reset (パスワードのリセットが必要)] オプションを選択した場合は、ユーザーが自分のパスワードを変更するアクセス許可を持っていることを確認します。詳細については、「IAM ユーザーに自分のパスワードを変更する権限を付与する」を参照してください。

-[[[AWS]IAMで作業用ユーザーを作成>https://qiita.com/kono-hiroki/items/c904a61aa2320a83609f]] 2020

-[[IAMユーザガイド>https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction.html]]

-[[IAM ユーザーの作成手順 - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/2022/01/07/180000]] 2022.1

-[[AWS IAM Userアクセスキーのローテーションを自動化しました | Money Forward Engineers' Blog>https://moneyforward.com/engineers_blog/2022/03/23/automation-for-access-keys/]] 2022.3
-[[IAM ユーザーのアクセスキーの管理 - AWS Identity and Access Management>https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_access-keys.html]]

-[[マルチアカウントな AWS環境のマネジメントコンソールへのアクセス方法をまとめてみた | DevelopersIO>https://dev.classmethod.jp/articles/how-to-access-aws-console-in-multi-accounts/]] 2021.11
--全て IAMユーザー
--IAMユーザーからスイッチロール
--SSO(SAML)
--AWS SSO



*IAMポリシー [#c0b14f1d]
-メモ(2023.1)
--１つのIAMグループに対して管理ポリシーやインラインポリシーはそれぞれ最大10までしか付与できない。
--10以上の管理ポリシーを付与したい場合は、複数のIAMグループを作り、それらのグループにポリシーを分散して付与した上で、ユーザを両方のグループに所属させるとよい。
--したがって、IAMグループは、付与するポリシーを意識したグルーピングにした方が良さそう。
--このような使い方を踏まえ、IAMグループは単なる「ユーザの組織単位での集まり」としてよりも付与するポリシーの分類を意識したグルーピングにした方が良さそう。

-[[管理者権限を与えつつIAMユーザーまわりの操作だけ禁止するIAMポリシー | DevelopersIO>https://dev.classmethod.jp/articles/not-iam-user-operation/]] 2021

-[[リソースベースポリシーの Principal に存在しないプリンシパルを指定すると Invalid principal in policy などのエラーが発生する | DevelopersIO>https://dev.classmethod.jp/articles/resource-base-policy-invalid-principal-error/]] 2022.12

-[[IAM ユーザーが所属している IAM グループとアタッチされている IAM ポリシーの一覧を AWS CLI で取得する | DevelopersIO>https://dev.classmethod.jp/articles/iam-user-inventory-aws-cli/]] 2022.11

-[[【更新】AWSにおけるアクセスポリシーの評価ロジック - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/iam/policy/evaluation-logic/2021-update]] 2022.6

-[[誤って削除したIAM PolicyをAWS Configを使って復元してみた | DevelopersIO>https://dev.classmethod.jp/articles/the-way-to-restore-iam-policy/]] 2022.3

-ポリシータイプ…参照：[[IAM でのポリシーとアクセス許可 - AWS Identity and Access Management>https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html]] 2022.4
--アイデンティティベースのポリシー…ユーザーやロールなどのアイデンティティにアタッチするポリシー。管理ポリシーとインラインポリシーがある。
--リソースベースのポリシー…インラインポリシーをリソースにアタッチするポリシー。
--セッションポリシー…AWS CLI または AWS API を使用してロールまたはフェデレーティッドユーザーを引き受ける場合に使うポリシー
--アクセス許可の境界…アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限
--サービスコントロールポリシー(SCP)…組織または組織単位 (OU) のメンバーアカウントのアクセス許可の上限
--アクセスコントロールリスト(ACL)…ACL がアタッチされているリソースにアクセスすることができる他のアカウントのプリンシパルを制御。クロスアカウントのアクセス許可
--※分類軸がぐちゃぐちゃでわかりづらいが、本当にポリシーのタイプという感じなのは最初の３つで、あとの３つは上限値と他アカの制御

-[[今日のハンズオンで出てきた、アクセス制御境界(Permission Boundary)とインラインポリシーの関係について整理してみました>https://twitter.com/tcsh/status/1522107952936620032]] 2022.5
--縦方向はAND、横方向はORの関係にあるので、アクセス制御境界とインラインポリシーの両方で明示的な許可がないと拒否されます。
--&ref(policy.png);

-IAMポリシーは何を対象にアタッチするポリシーかで２つに分かれる
--アイデンティティベースポリシー…ユーザ／グループ／ロールにアタッチするポリシー
--リソースベースポリシー…リソースとは主にAWSの個々のサービス(例えばS3)を指す
---[[S3のアクセスコントロールまとめ - Qiita>https://qiita.com/ryo0301/items/791c0a666feeea0a704c]] 2014

-アイデンティティベースポリシーはスタンドアロンかどうかで別れ、さらにスタンドアロンポリシーは管理主体によって２つに分かれる
--スタンドアロンポリシー(管理ポリシー）
---AWS管理ポリシー
---カスタマー管理ポリシー
--インラインポリシー
--[[管理ポリシーとインラインポリシー - AWS Identity and Access Management>https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html]] 2022.4
--[[[AWS]管理ポリシーとインラインポリシーの違いが分からなかったので改めてIAMポリシーのお勉強をする - Qiita>https://qiita.com/Batchi/items/a2dde3d2df27568cc078]] 2017

-リソースベースポリシーはインラインポリシーしかない
-リソースベースのポリシーとして最も一般的な例
--Amazon S3 バケットポリシー
--IAM ロールの信頼ポリシー
---[[信頼ポリシーにおいてスイッチロールできるIAMユーザーを複数指定する方法 | DevelopersIO>https://dev.classmethod.jp/articles/how-to-trust-iam-users-that-can-switch-role/]] 2022.6

-[[JSON ポリシー>https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html#access_policies-json]] 2022.4
--Version – 使用するポリシー言語のバージョン。2012-10-17
--Statement – このポリシーのメイン要素であり、以下の要素のコンテナになります。ポリシーには、複数のステートメントを含めることができます。
--Sid (オプション) – 複数のステートメントを区別するための任意のステートメント ID が含まれます。
--Effect – Allow / Deny
--Principal (一部の状況でのみ必須) 
---リソースベースのポリシーを作成する場合は、アクセスを許可または拒否するアカウント、ユーザー、ロール、またはフェデレーティッドユーザーを指定する必要があります。
---ユーザーまたはロールにアタッチする IAM アクセス許可ポリシーを作成する場合は、この要素を含めることはできません。プリンシパルは、そのユーザーまたはロールを暗黙に示しています。
--Action – ポリシーで許可または拒否するアクションのリストが含まれます。(Resource 一部の状況でのみ必須) 
---IAM アクセス許可ポリシーを作成する場合は、アクションが適用されるリソースのリストを指定する必要があります。
---リソースベースのポリシーを作成する場合は、この要素はオプションです。この要素を含めない場合、アクションが適用されるリソースは、ポリシーがアタッチされているリソースです。
--Condition (オプション) ポリシーでアクセス許可を付与する状況を指定します。



*フェデレーション [#tadf5608]
-IDフェデレーション…使用頻度の低いユーザにアカウントを与えるのではなく一時的な認証を与え、短時間のみサービスへのアクセスを許す仕組み
-AWS Security Token Service (STS) と AWS フェデレーションは、どちらも一時的な権限付与の仕組みですが、使用用途や方法が異なる。
-STSは、AWSアカウントの代理人として操作を行うために使用されます。STSを使用すると、一時的なセキュリティトークンを取得して、アクセスキー、シークレットアクセスキー、セッショントークンを使用してAWSサービスにアクセスすることができる。
-AWS フェデレーションは、組織内のユーザーやシステムからAWSにアクセスするために使用する。
-AWS フェデレーションを使用すると、組織内の認証システムとAWSアカウントを連携させることができ、組織内のユーザーやシステムがAWSサービスにアクセスするために必要なアクセスキーやシークレットアクセスキーを取得することができる。

-[[ID プロバイダーとフェデレーション>https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers.html]]
--すでにユーザー ID を AWS の外で管理している場合、AWS アカウントに IAM ユーザーを作成する代わりに、IAM ID プロバイダーを利用できます。
--ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を与えることができます。
これは、会社に既に企業ユーザーディレクトリなどの独自の ID システムがある場合に便利です。
--また、AWS リソースへのアクセスが必要なモバイルアプリやウェブアプリケーションを作成する場合にも便利です。

-フェデレーション（英：federation）とは、一度認証を通ればその認証情報を使って許可されているすべてのサービスを使えるようにする仕組み
--参考：https://wa3.i-3-i.info/word12731.html
--「一度認証すればOKだよ！」を意味する言葉が「シングルサインオン(SSO)」で、シングルサインオンを実際に行うための手法のひとつとして「フェデレーション」がある



* MFA [#l4d0806b]
-[[AWS CLI で MFA を有効化してみた - Qiita>https://qiita.com/sugimount-a/items/5c522af2f5354ab7ab9f]] 2022.12

-[[IAMユーザに2つ目のMFAデバイスを登録してみる - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/multiple-mfa-device]] 2022.11

-[[AWS MFAの設定 - Qiita>https://qiita.com/akkisu/items/f9695d0c635d74d2d7ee]] 2015

-[[AWS での多要素認証 (MFA) の使用 - AWS Identity and Access Management>https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa.html]]

-簡単に言うと、スマホなどにOTPツールを入れてそのパスワードを入れるような仕組みにする