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
たびたびTweetしておりますが、2019年9月22日の技術書典7に、『AWSの薄い本 IAMのマニアックな話』という本を出展します。名前の通りAWS本ですが、IAMだけを取り扱っています。初の同人誌を引っさげて、技術書典デビューします。 IAM本の目的 書いた本はIAMの特化本ですが、何故IAMと聞かれるのでここに書いておきます。AWSが不正利用されて100万円の請求が来たというようなニュースが、たまにネットを駆け巡ることがあります。原因の多くがIAMのアクセスキーをGitHubに誤ってコミットしてしまい、そのキーを不正利用されたケースです。そういった事態を防ぐために正しくIAMを知って貰いたいのです。 IAMは、AWSの利用権限を管理する極めて重要な機能です。AWSには多種多様な機能があり、IAMはそれに応じて様々な記述方法で権限を設定できるようになっています。その分設定項目が多く、I
概要 先日、非公式ながら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 権限を確認する ユーザーの強力なパスワードポリシーを設定
それぞれのフェーズの詳細は以下のようになります。 当該アクセスキーを利用した不正な操作が行われる 流出したアクセスキーを利用し以下の操作が行われました。APIレベルの操作です。一連の操作はスクリプト化されているように見受けられます。 CreateAccessKey 流出したアクセスキーを利用し新規のアクセスキーを作成 DeleteAccessKey 流出したアクセスキーを削除 CreateUser IAMユーザーを作成（権限不足により失敗） CreateKeyPair 新規のアクセスキーを利用しキーペアを作成 RunInstances 全リージョンでインスタンスを起動 各リージョンで20のインスタンスが立ちあがる（起動上限はデフォルトのまま） m5.24xlargeなどインスタンスサイズが大きいものが優先される その後、起動したインスタンスにて仮想通貨Moneroのマイニングが行われました
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
はじめに AWS IAMのアクセスアドバイザーでアクションレベルでの「最終アクセス日時」が確認できるサービス数は、140以上に増えました。 IAMのアクセスアドバイザーとは、IAMエンティティ（ユーザー、ロール、グループなど）が、AWSサービスごとの最終アクセス日時や、アクセス可能なAWSサービスを確認できる機能です。 従来は、IAMやLambda、S3、EC2などの一部のAWSサービス数のみ、アクションレベルで「最終アクセス日時」が確認できていました。 以前も以下の記事のようにアップデートがありました。 今回のアップデートでは、140以上のAWSサービスを対象に、アクションレベルで「最終アクセス日時」が確認できるようになりました。 これによって、IAMロールに指定された権限が実際に必要かどうかを判断し、不必要な権限を削除することで、IAMのベストプラクティスである「最小権限の原則」の実現
![[アップデート]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)
サーバーレスアプリケーションから Amazon Aurora への IAM ロールベース認証 | Amazon Web Services
Amazon Web Services ブログ サーバーレスアプリケーションから Amazon Aurora への IAM ロールベース認証 ユーザー名とパスワードをアプリケーションに直接保存することはベストプラクティスではありません。セキュリティで保護されたアプリケーションでは、資格情報をプレーンテキストとして保存しないでください。ソリューションとして、AWS Identity and Access Management (IAM) ポリシーは、Amazon Aurora リソースを管理できるユーザーを決定するアクセス許可を割り当てることができます。たとえば、IAM を使用して、DB クラスター、タグリソース、またはセキュリティグループを作成、記述、変更、削除できるユーザーを決定できます。Amazon Aurora では、データベースユーザーを IAM ユーザーとロールに関連付けるこ
こんにちは。 サービスGの金谷です。 これまでIAMの設定を自分でやることがあまりなく、スイッチロールで何が起きているのか全然理解できていなかったのでまとめようと思います。 まず大前提 AWSアカウント≠ IAMユーザー です。 当然といえば当然なのですが別物です。 ざっくり説明するとAWSアカウントの中にIAMユーザーがいるといった形で、AWSアカウント＝ルートユーザーのようなイメージです。 私個人の経験としてはプライベートでAWSを学び触り始めたばかりのときは IAMを何も設定せずに他のサービスを触ったりしていましたが、通常は使用するべきではないです。 ちゃんとIAMユーザーを作成してそちらで作業するようにしましょう。 スイッチロールとは 名前の通りIAMロールを切り替える機能です。 アカウントを跨いだロールの切り替えも可能です。（というかこちらをメインに使います） 上図ではスイッチ元
このアクション、いまのポリシー設定で実行できる？ 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
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でスイッチロール - 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
サーバー間 GraphQL と webmock-graphql の話 / server-to-server graphql and webmock-graphql
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
When and where to use IAM permissions boundaries | Amazon Web Services
AWS Security Blog When and where to use IAM permissions boundaries Customers often ask for guidance on permissions boundaries in AWS Identity and Access Management (IAM) and when, where, and how to use them. A permissions boundary is an IAM feature that helps your centralized cloud IAM teams to safely empower your application developers to create new IAM roles and policies in Amazon Web Services (
園部です。 Service Quotas で IAM 上限管理が可能となりました！ 要注意なのは、バージニア北部リージョンから申請を行う必要がある点です。 You can manage your IAM quotas in the US East (N. Virginia) region, when using AWS Service Quotas. 引用：Manage your AWS Identity and Access Management quotas with AWS Service Quotas AWS ではリージョンに紐づかないグローバルなサービスがあります。 IAM もその一つのため、特定リージョン（バージニア北部）から申請を行う必要があるようです。CloudWatch のメトリクスなども同様にバージニア北部に集約されていますね。 サポートケースから上限緩和申請する際には
IAM policy types: How and when to use them | Amazon Web Services
AWS Security Blog IAM policy types: How and when to use them You manage access in AWS by creating policies and attaching them to AWS Identity and Access Management (IAM) principals (roles, users, or groups of users) or AWS resources. AWS evaluates these policies when an IAM principal makes a request, such as uploading an object to an Amazon Simple Storage Service (Amazon S3) bucket. Permissions in
スイッチしまくってやるよ～ 1.準備 アカウントAのユーザでアカウントBのロールを引き受け、アカウントAのユーザでアカウントB内のリソースを操作する。 1-1.アカウントB側の準備（スイッチ先） アカウントBにロールを作る。IAMのサービス画面から[ロールを作成]をクリックする。 [AWSアカウント]を選択する。 [別のAWSアカウント]を選択しアカウントAのアカウントIDを記入する。 次へ。 ロールに許可するポリシーを選択する。今回は[ReadOnlyAccess]を選択して次へ。 ロールの名前を入力する。 [ステップ1:信頼されたエンティティを選択する]には、このロールに付与する「信頼ポリシードキュメント」が表示されており、次のようになっている。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action
https://support.serverworks.co.jp/hc/ja/articles/5045982948889-%E6%96%B0%E8%A6%8FIAM%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%81%8C%E5%88%9D%E5%9B%9E%E3%83%AD%E3%82%B0%E3%82%A4%E3%83%B3%E6%99%82%E3%81%AB-%E5%88%9D%E6%9C%9F%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89%E5%A4%89%E6%9B%B4%E3%81%97%E3%82%88%E3%81%86%E3%81%A8%E3%81%99%E3%82%8B%E3%81%A8-iam-ChangePassword-%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%99%E3%82%8B%E6%A8%A9%E9%99%90%E3%81%8C%E7%84%A1%E3%81%84-%E3%81%AE%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%A8%E3%81%AA%E3%81%A3%E3%81%A6%E3%81%97%E3%81%BE%E3%81%84%E3%81%BE%E3%81%99
IAMポリシーで、特定のリソース/タグに限定してアクションを許可したい場合、どのように記載すればいいですか？ | DevelopersIO
この記事は アノテーション株式会社 AWS Technical Support Advent Calendar 2022 | Advent Calendar 2022 - Qiita 22日目の記事です。 困っていること IAMポリシーで、以下のように RDS インスタンスについて、開始、停止、再起動するポリシーを記載しました。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rds:StartDBInstance", "rds:StopDBInstance", "rds:RebootDBInstance" ], "Resource": "*" } ] } これについて、特定のリソースにだけアクションを許可するよう、制限を付与する要件があります。 その他、特定のタグが付与されたリソースに
AWS IAM アイデンティティセンター (AWS Single Sign-On の後継サービス) を使用して、ユーザーセッション管理をより詳細に制御できるようになりました。組織のセキュリティ要件とエンドユーザーエクスペリエンスの求めに応じて、コンソールを使用してカスタムセッション期間 (最大 7 日) を設定できます。この機能により、セッションを終了して、不要になったセッションや疑わしいセッションの管理ができます。 セッション期間を 15 分から 7 日までの間で設定して (デフォルトでは 8 時間)、サインインしたユーザーが AWS ユーザーポータルと AWS アカウントに 1 回の認証でアクセス可能な期間を調整できるようになりました。最大 7 日のカスタムセッション期間のサポートに加え、新しい機能によってアクティブなユーザーポータルセッションをユーザー別に調べて、不要なアクセスからの
Amazon RDS: タグ所有者がタグ付けした RDS リソースへのフルアクセスを許可する - AWS Identity and Access Management
この例は、タグ付けした RDS リソースへのフルアクセスをタグの所有者に許可する ID ベースのポリシーを作成する方法を示しています。このポリシーでは、AWS API または AWS CLI から、このアクションをプログラムで完了するために必要なアクセス権を許可します。 { "Version": "2012-10-17", "Statement": [ { "Action": [ "rds:Describe*", "rds:List*" ], "Effect": "Allow", "Resource": "*" }, { "Action": [ "rds:DeleteDBInstance", "rds:RebootDBInstance", "rds:ModifyDBInstance" ], "Effect": "Allow", "Resource": "*", "Condition": {
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【2022年版ベストプラクティス】AWS IAMまとめ - Qiita
【資料公開】AWSアカウントで最初にやるべきこと 〜2022年6月版〜 | DevelopersIO
#技術書典 に出展する『AWSの薄い本 IAMのマニアックな話』はこんな本 - プログラマでありたい
GitHub ActionsにAWSクレデンシャル情報を渡さずにTerraformでCI/CDをやってみた
Security-JAWS IAMの設計を言語化する
AWS IAMの最小権限追求の旅 - プログラマでありたい
【実録】アクセスキー流出、攻撃者のとった行動とその対策 | DevelopersIO
IAM初心者がAWS CLIでスイッチロールするまで | DevelopersIO
AWS IAM 〜 設計上の戦略と戦術 / 20191109-kof-iam
AWSのABAC「ここが嬉しいよ、ここが辛いよ」
Service Quotas から IAM 上限管理が可能になりました！ | DevelopersIO
AWSマネジメントコンソールでスイッチロールする - Qiita
IAM アイデンティティセンターがユーザーエクスペリエンスとクラウドセキュリティ向上のため、セッション管理機能を追加