IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR
はじめに AWSのアクセス制御サービスであるIAMについて、2022年7月時点での機能および使用法を、初学者でも理解しやすいことを心掛けてまとめました。 IAMをよく分からないまま適当に設定するとセキュリティ的にまずいので、これを機に設定を見直して頂き、セキュリティレベル向上に貢献できれば幸いです。 特に、後述するIAM設定手順は、AWSに登録して最初に実施すべき設定に相当するため、セキュリティに興味がなくとも一度は実施することをお勧めします。 また公式のベストプラクティスは丁寧にまとめたつもりなので、初学者以外でもAWSのセキュリティ確保に興味がある方は、ぜひご一読頂けると嬉しいです。 IAMとは 「Identity and Access Management」の略です。 公式ドキュメントによると、IAMは「誰」が「どのAWSのサービスやリソース」に「どのような条件」でアクセスできるかを
ログ・モニタリングのやること AWS CloudTrail の設定 CloudTrail は AWS リソースに関して「誰が」「いつ」「何に」対して「どうような」操作をしたのかのイベントを記録するサービスです。イベント履歴から 90 日間分のイベントを確認することはできますが、イベントログの長期保管の設定（証跡の作成を行い、S3 に保管）をしておくことで、トラブル発生時の解析やインシデント発生時の調査などに利用できます。 有料です（無料利用枠もあります）。 [YouTube] AWS CloudTrail を触ってみた CloudTrail Insights イベントを利用することで、機械学習により異常なアクティビティを検出することもできます。通常の操作で検出されることがあるため、始めに試してみて、あまり活用しないようであれば無効化を検討でも良いと思います。 イベントログは S3 と Cl
概要 先日、非公式ながらGitHub ActionsのAWSアクションで以下のような面白い機能が発表されました。 よりわかりやすく嚙み砕くとこういうことです。 Circle CIやGitHub ActionsでAWSを使う場合は事前に環境変数にアクセスキーとシークレットキーを登録させてCIを動かしてきましたが、そのためにIAMユーザーを発行して鍵を管理するのは手間だったのでこれはいいアップデートです。 今回はTerraformとGitHub Actionsを組み合わせたCI/CDにこの機能を取り入れてGitHub ActionsにIAMロールを渡してEC2インスタンス構築のCI/CDを実装してみようと思います。 GitHub Actionsを用いたTerraformのCI/CD TerraformでAWSリソースをデプロイする際にGitHub ActionsやCircle CIでCI/CD
2019年11月11日にSecurity-JAWSで発表した資料です https://s-jaws.doorkeeper.jp/events/99569
皆さん、IAM使ってますか〜？ 今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。 IAMでのセキュリティのベストプラクティス まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。 docs.aws.amazon.com AWS アカウントのルートユーザー アクセスキーをロックする 個々の IAM ユーザーの作成 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する 最小権限を付与する AWS 管理ポリシーを使用したアクセス許可の使用開始 インラインポリシーではなくカスタマー管理ポリシーを使用する アクセスレベルを使用して、IAM 権限を確認する ユーザーの強力なパスワードポリシーを設定
IAM の評価論理をやんわり押さえるセッション「やんわり押さえよう IAM の評価論理」で登壇しました #devio2021 | DevelopersIO
【やんわり】（副詞） ━ものやわらかであるさま。おだやかなさま。 （デジタル大辞泉より） コンバンハ、千葉（幸）です。 皆さんは IAM の評価論理って難しいと思っていませんか？ 実は…… … …… ……… その通り、難しいんです。 やれアインディティベースポリシーとリソースベースポリシーだの、アカウントをまたぐまたがないだの、ガードレールがどうだの、暗黙的だの明示的だの、覚えることがたくさんあって難しいです。 詳細な内容は必要に迫られたときに考えるとして、「だいたいこういうことでしょ」とやんわり理解する状態を本セッションでは目指していきます。 セッションの雰囲気 これが…… こうなる感じ雰囲気のセッションです。 セッションで学べること 章ごとにサマリを描きます。 1. IAM JSON ポリシー IAM のポリシータイプは 6 つあること IAM JSON ポリシーの構成要素として Ef
最小権限のIAM Policy作成にCloudFormationのコマンドが役立つ | DevelopersIO
最小権限のIAM Policyを作成するのって地味に面倒ですよね。以前私は、Route53ホストゾーンにDNSレコード作成するのに必要な最小権限のPolicyを作るため、権限ゼロの状態から始めて、権限不足エラーが出るたびに権限を足していくという力技でPolicyを作ったことがあります。 Route53ホストゾーンにDNSレコードをTerraformで作成するのに必要な最小権限 | DevelopersIO もうちょっとスマートなやり方が、CloudFormation(CFn)のコマンドを使うとできる場合があることを学んだのでレポートします。 aws cloudformation describe-type そのコマンドが、 aws cloudformation describe-typeです。--typeオプションでRESOURCEを指定して、 --type-nameでCFnのリソースタイ
GitHub - iann0036/iamlive: Generate an IAM policy from AWS, Azure, or Google Cloud (GCP) calls using client-side monitoring (CSM) or embedded proxy
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
AWS IAM で障害が起こったらどうなるの？ AWS IAM のレジリエンス（復元力）に関する記述がドキュメントに追記されていた | DevelopersIO
コンバンハ、千葉（幸）です。 AWS サービスで広範囲の障害が起こったときにどう備えるか？は AWS を利用する上では避けて通れない課題です。 例えば Amazon EC2 であれば、アベイラビリティゾーン（AZ）単位での障害に備えてマルチ AZ 構成にしておく、リージョン単位の障害に備えて別リージョンにバックアップを退避させておく、などの構成が思いつきます。 では AWS IAM で障害が起こったときに備えてどうすべきか？改めて問われると難しい問題です。わたしはぼんやりと「そもそも障害が起こることはないんじゃないか？そもそも AWS IAM における障害って何？」という思いを抱いていました。 そんな折、いつものように AWS IAM のドキュメントの更新履歴を眺めていると IAM のレジリエンスに関する更新が行われていることに気がつきました。 Document history for I
AWS IAM Identity Center において一時的なアクセス許可を与える仕組みを提供する Temporary Elevated Access Management (TEAM) ソリューションを試してみた | DevelopersIO
AWS IAM Identity Center において一時的なアクセス許可を与える仕組みを提供する Temporary Elevated Access Management (TEAM) ソリューションを試してみた AWS IAM Identity Center で一時的なアクセス許可を与える仕組みを提供するソリューション Temporary Elevated Access Management (TEAM) が aws-samples で公開されました。例えば、特定の AWS アカウントへの AdministratorAccess 権限のアクセスを利用者が申請し、上長が承認する、といった運用を実現できます。 AWS のブログでも TEAM の使い方が紹介されています。 本ブログでは TEAM ソリューションをデプロイし、AWS アカウントへの一時的なアクセスの申請と承認を試してみます。
[アップデート] 「最小権限の実装」が容易に！過去の CloudTrail イベントに基づいて IAM ポリシーを生成できるようになりました | DevelopersIO
コンバンハ、千葉（幸）です。 IAM Access Analyzer により、過去のアクティビティイベントに基づいて IAM ポリシーの生成ができるようになりました！ 「必要最小限の権限に絞る」というアプローチが取りやすくなりましたね。 激アツアップデートなので冗長構成で記事を書いています。（平たく言うと被った。）あわせてご参照ください。 何が嬉しいのか 「今はユーザーに広めの権限を与えているけど、必要な権限のみを与えるように絞っていきたいなぁ」 「必要な権限ってなんだろう。洗い出すのが難しいな」 「過去 30 日間で一通り必要な操作はしたから、それができれば十分だな」 「実際の操作を洗い出してそのままポリシーにしてくれたりしたらいいのに」 はい、それができるようになりました。 「最小権限の実装」は、 AWS を使用する上で遵守すべきベストプラクティスです。小さな権限から始めて徐々に必要な
[アップデート]IAMのアクセスアドバイザーでは、140以上のAWSサービスを対象に、アクションレベルで「最終アクセス日時」が確認できるようになりました | DevelopersIO
[アップデート]IAMのアクセスアドバイザーでは、140以上のAWSサービスを対象に、アクションレベルで「最終アクセス日時」が確認できるようになりました はじめに AWS IAMのアクセスアドバイザーでアクションレベルでの「最終アクセス日時」が確認できるサービス数は、140以上に増えました。 IAMのアクセスアドバイザーとは、IAMエンティティ（ユーザー、ロール、グループなど）が、AWSサービスごとの最終アクセス日時や、アクセス可能なAWSサービスを確認できる機能です。 従来は、IAMやLambda、S3、EC2などの一部のAWSサービス数のみ、アクションレベルで「最終アクセス日時」が確認できていました。 以前も以下の記事のようにアップデートがありました。 今回のアップデートでは、140以上のAWSサービスを対象に、アクションレベルで「最終アクセス日時」が確認できるようになりました。 これ
![[アップデート]IAMのアクセスアドバイザーでは、140以上のAWSサービスを対象に、アクションレベルで「最終アクセス日時」が確認できるようになりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/bf00ad68b49f41acf5078ae9946ea858f9b1f486/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F08%2Faws-iam.png)
このアクション、いまのポリシー設定で実行できる？ IAM Policy Simulator でお手軽に確認しちゃおう | DevelopersIO
コンバンハ、千葉（幸）です。 IAM ポリシーを設計・設定したのちには、きちんと意図通りに動作するか確認したいものです。とはいえ、リソースに変更を加えるようなアクションはなかなかテストしづらいですよね。 テスト用のリソースを作ったり消したりして対応する場面も多いかと思いますが、それすら許容されないケースもあります。そんな時にあくまで机上での動作のシミュレートができるのが IAM Policy Simulator です。 使い方を確認していきましょう。 目次 目次 IAM Policy Simulator の全体像 IAM Policy Simulator へのアクセス方法 IAM Policy Simulator に必要な権限 IAM Policy Simulator のモード シミュレートするポリシーの設定方法 AWS Organizations SCPs IAM Policies、Pe
こんにちは。 サービスGの金谷です。 これまでIAMの設定を自分でやることがあまりなく、スイッチロールで何が起きているのか全然理解できていなかったのでまとめようと思います。 まず大前提 AWSアカウント≠ IAMユーザー です。 当然といえば当然なのですが別物です。 ざっくり説明するとAWSアカウントの中にIAMユーザーがいるといった形で、AWSアカウント＝ルートユーザーのようなイメージです。 私個人の経験としてはプライベートでAWSを学び触り始めたばかりのときは IAMを何も設定せずに他のサービスを触ったりしていましたが、通常は使用するべきではないです。 ちゃんとIAMユーザーを作成してそちらで作業するようにしましょう。 スイッチロールとは 名前の通りIAMロールを切り替える機能です。 アカウントを跨いだロールの切り替えも可能です。（というかこちらをメインに使います） 上図ではスイッチ元
AWS Single Sign-onがAWS IAM Identity Centerになりました！ | DevelopersIO
AWS Single Sign-on (AWS SSO) が AWS IAM Identity Center になりました。マネジメントコンソールで新しい設定画面を見る限り、AWS IAM Identity Center は AWS Single Sign-On の後継サービスの位置づけとなります。ざっくりと変更点を調べてみました。 AWS のブログでも紹介されています。 何が変わったのか 始めにまとめです。 現時点では、技術的な機能は変更されていない sso identitystoreなどの API、名前空間は下位互換性維持のため、変更されていない マネジメントコンソールを確認してみる 新しい設定画面を画面を見てみます。 メニューの構成は、AWS SSO のときからあまり変わっていないようです。関連コンソールとして、AWS IAM サービスへのリンクが追加されているくらいでしょうか。 冒
関西オープンフォーラム内で開催された"jus研究会大阪大会「AWS IAM - 設計上の戦略と戦術」"での発表資料です。 https://k-of.jp/backend/session/1299 運用設計ラボおよびJAWS-UG CLI専門支部での実践を例に、AWS IAM設計上の戦略と戦術について整理してみました。 (現在も、試行錯誤の途中であり、今後内容が改訂される可能性があります。) (運用設計ラボ合同会社 波田野裕一)
Identify Unintended Resource Access with AWS Identity and Access Management (IAM) Access Analyzer | Amazon Web Services
AWS News Blog Identify Unintended Resource Access with AWS Identity and Access Management (IAM) Access Analyzer Today I get to share my favorite kind of announcement. It’s the sort of thing that will improve security for just about everyone that builds on AWS, it can be turned on with almost no configuration, and it costs nothing to use. We’re launching a new, first-of-its-kind capability called A
AWS CLI で MFA 必須のアクセス制御を設定
AWS CLI を利用する場合は、通常はアクセスキーの設定が必要となります。(EC2 上でIAM ロールを割り当てる場合は除く） IAM ユーザ名/パスワードと違いアクセスキーはファイルなどに保存しておきますので漏洩のリスクが高くなります。そこでMFA 認証をしないとAWS CLI から各種AWS リソースにアクセスできないように設定する方法を記載します。 MFA 必須のIAM ポリシーの設定 まずは、以下のようなIAM ポリシーを設定します。MFA 認証をしていないとすべてのリクエストを拒否する設定となっています。 condition 内の記述ですが、”aws:MultiFactorAuthPresent” がMFA 認証されているかどうかを表していますが、MFA 認証をしていないとそもそもキーが存在しないため、”BoolIfExists” で存在チェックを入れています。 { "Vers
【AWS】IAMのスイッチロールの設定方法｜コラム｜クラウドソリューション｜サービス｜法人のお客さま｜NTT東日本
1.そもそもIAMとは？ AWS上のリソースへのアクセスを制御するものです。 IAMがあることで、役割に応じた権限を個別に付与できるようになるんです。 詳細は以下のコラムで書かれていますので、そちらをご参照ください。 AWS IAMによる権限設定のメリットと設定方法 2.スイッチロールとは？ ロールの機能のひとつで、他アカウントからのログインを許可するロールのこと。 付与するポリシーによってさまざまな権限を与えることができます。 （管理者権限であったり、EC2限定の閲覧権限であったり） 3.スイッチロールのない世界 複数アカウントを管理している場合、アカウント間を移動する際にログイン・ログアウトを繰り返していると非常に手間がかかりますよね？ 上図より開発アカウントからテストアカウントに移動する場合の作業。 ①開発アカウントからログアウト ②テストアカウント用のアカウントID、ユーザ名、パス
AWS CLIとシェルスクリプト、いつ使う？活用できる場面とTips紹介 #devio2024 / AWS CLI and Shell Tips
AWS CLIでスイッチロール - Qiita
CloudShellでスイッチする方法と、ローカルにインストールしたAWS CLIでスイッチする方法をやります。 複数アカウントの準備はおひとりさまOrganizationsやってみた参照。 スイッチロールするためのユーザ・ロール・権限の準備はAWSマネジメントコンソールでスイッチロールするを参照。 0.事前準備 今回はアカウントA（スイッチ元）からアカウントB（スイッチ先）にAWS CLIでスイッチロールする。 アカウントA（スイッチ元） IAMユーザ：AccountA_user 「AccountB_role」を引き受ける権限が必要 CloudShellを使う場合はAWSCloudShellFullAccess権限が必要 { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRo
Scale your workforce access management with AWS IAM Identity Center (previously known as AWS SSO) | Amazon Web Services
AWS Security Blog Scale your workforce access management with AWS IAM Identity Center (previously known as AWS SSO) AWS Single Sign-On (AWS SSO) is now AWS IAM Identity Center. Amazon Web Services (AWS) is changing the name to highlight the service’s foundation in AWS Identity and Access Management (IAM), to better reflect its full set of capabilities, and to reinforce its recommended role as the
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【2022年版ベストプラクティス】AWS IAMまとめ - Qiita
【資料公開】AWSアカウントで最初にやるべきこと 〜2022年6月版〜 | DevelopersIO
GitHub ActionsにAWSクレデンシャル情報を渡さずにTerraformでCI/CDをやってみた
Security-JAWS IAMの設計を言語化する
AWS IAMの最小権限追求の旅 - プログラマでありたい
IAM初心者がAWS CLIでスイッチロールするまで | DevelopersIO
AWS IAM 〜 設計上の戦略と戦術 / 20191109-kof-iam
AWSのABAC「ここが嬉しいよ、ここが辛いよ」