(Translated by https://www.hiragana.jp/)
[7ページ] iamの人気記事 421件 - はてなブックマーク

検索けんさく対象たいしょう

並ならび順じゅん

ブックマーク数すう

期間きかん指定してい

  • から
  • まで

241 - 280 件けん / 421件けん

新着しんちゃく順じゅん 人気にんき順じゅん

iamの検索けんさく結果けっか241 - 280 件けん / 421件けん

iamの関連かんれんエントリー

  • [速報そくほう] AWS Identity and Access Management Access Analyzerがリリースされました！ #reinvent | DevelopersIO

    こんにちは。サービスグループの武田たけだです。 現在げんざいre:Invent 2019に参加さんかしていますが、キーノートを前まえにして新しん機能きのうのリリースが止とまりません！今回こんかい新あたらしく、AWS Identity and Access Management Access Analyzer（以下いか、IAM Access Analyzer）がリリースされましたのでお届とどけします。 Introducing AWS Identity and Access Management (IAM) Access Analyzer IAM Access Analyzerとは IAM Access Analyzerはサポートしているリソースが、意図いとしたどおりのアクセスのみを提供ていきょうしているかを継続けいぞく的てきにチェックできるサービスです。リリース時点じてんでサポートしているリソースは次つぎのとおりです。 Amazon S3バケット AWS KMSキー Amazon S

      [速報] AWS Identity and Access Management Access Analyzerがリリースされました！ #reinvent | DevelopersIO

    • IAM Roles Anywhere で AWS IAM ロールを AWS 外部がいぶのワークロードに拡張かくちょうする | Amazon Web Services

      Amazon Web Services ブログ IAM Roles Anywhere で AWS IAM ロールを AWS 外部がいぶのワークロードに拡張かくちょうする この記事きじは Extend AWS IAM roles to workloads outside of AWS with IAM Roles Anywhere を訳やくしたものです。 IAM Roles Anywhere のリリースの通とおり、AWS Identity and Access Management (IAM) を用もちいて AWS 外部がいぶで稼働かどうしているワークロードに IAM ロールを簡単かんたんに使用しようできるようになりました。この機能きのうは、IAM ロールの機能きのうを AWS 外部がいぶのワークロードに拡張かくちょうします。IAM Roles Anywhere を利用りようすることで、オンプレミスのサーバー、コンテナ、またはアプリケーションが一時いちじ的てきな AWS クレデンシャルを取得しゅとく

        IAM Roles Anywhere で AWS IAM ロールを AWS 外部のワークロードに拡張する | Amazon Web Services

      • IAM Permissions boundary（アクセス権限けんげんの境界きょうかい）で明示めいじ的てきに許可きょかしていないアクションでも条件じょうけん次第しだいで実行じっこうできるということを評価ひょうか論理ろんりの流ながれを眺ながめて再さい認識にんしきしてみた | DevelopersIO

        コンバンハ、千葉ちば（幸こう）です。 突然とつぜんですが問題もんだいです。 以下いかの条件じょうけんがあったとします。 同一どういつの AWS アカウントに S3 バケット A と IAM ユーザー A が存在そんざいする IAM ユーザー A の Permissions boundary には AWS 管理かんりポリシーViewOnlyAccessが設定せっていされている ここで、IAM ユーザー A が S3 バケット A に対たいしてPutObjectを実行じっこうしたいとします。（補足ほそくしておくと、ViewOnlyAccessにはPutObjectの Allow は含ふくまれていません。） 以下いかのうち、アクションの結果けっかについて最もっとも適切てきせつに説明せつめいしているものを選択せんたくしてください。 IAM ユーザー A の Permissions policy で適切てきせつな Allow が設定せっていされていればアクションは成功せいこうする S3 バケット A のバケットポリシーで適切てきせつな Allow が設定せっていされ

          IAM Permissions boundary（アクセス権限の境界）で明示的に許可していないアクションでも条件次第で実行できるということを評価論理の流れを眺めて再認識してみた | DevelopersIO

        • AWS Organizationsから新規しんきAWSアカウントを作成さくせいしてスイッチロールしてみた | DevelopersIO

          こんにちは、臼田うすだです。 みなさん、アカウント管理かんりしてますか？(挨拶あいさつ 今回こんかいはAWS Organizationsを利用りようして新規しんきのAWSアカウントを作成さくせいしてみました。ついでにスイッチロールでアクセスしてみます。 AWS Organizationsとは AWS Organizationsは複数ふくすうのAWSアカウントをまとめて管理かんりする事ことができる便利べんりな機能きのうです。 主おもに請求せいきゅうをまとめたり、アカウントを跨またいでSCP(サービスコントロールポリシー)で権限けんげん管理かんりを行おこなうなどガバナンスを効きかせたりすることができます。 Organizationsでは組織そしきという単位たんいを作成さくせいしてその中なかにアカウントを持もちます。 組織そしきにアカウントを追加ついかする方法ほうほうは、既存きそんのアカウントを招待しょうたいする方法ほうほうと、新規しんきアカウントをOrganizationsから作成さくせいする方法ほうほうがあります。 今回こんかいはOrganizationsから作成さくせいしてみます。 AWS Organizati

            AWS Organizationsから新規AWSアカウントを作成してスイッチロールしてみた | DevelopersIO

            • iamの関連かんれんエントリー

          • IAM ポリシーで新規しんき IAM ユーザーがマネジメントコンソールへアクセスするのを防ふせぐための対処たいしょ方法ほうほう | DevelopersIO

            困こまっていた内容ないよう IAM ポリシーで IAM ユーザー作成さくせい時じのプログラムによるアクセス用ようの IAM ユーザの作成さくせいは許可きょかするが、AWS マネジメントコンソールへのアクセス用ようの IAM ユーザの作成さくせいを拒否きょひするという設定せっていは可能かのうでしょうか。可能かのうな場合ばあいは方法ほうほうを教おしえてください。 IAM コンソールでは以下いかの設定せってい箇所かしょに該当がいとうします。 どう対応たいおうすればいいの？ プログラムによるアクセスを許可きょかし、AWS マネジメントコンソールへのアクセスを拒否きょひする IAM ポリシーは設定せってい可能かのうです。 IAM コンソールのチェック項目こうもくは以下いかの API に該当がいとうします。 プログラムによるアクセス: CreateAccessKey AWS マネジメントコンソールへのアクセス: CreateLoginProfile 新規しんき作成さくせいする IAM ユーザーの AWS マネジメントコンソールへのアクセスを判定はんていするアクションはiam:CreateLogi

              IAM ポリシーで新規 IAM ユーザーがマネジメントコンソールへアクセスするのを防ぐための対処方法 | DevelopersIO

            • IAMユーザーやAWSアカウントのルートユーザー に複数ふくすうの MFA デバイスを割わり当あてる事ことができるようになりました | DevelopersIO

              お疲つかれさまです。とーちです。 IAM に複数ふくすうの MFA デバイスを割わり当あてる事ことができるようになったというアナウンスを見みたので試ためしてみました。 かんたんまとめ AWS アカウントのルートユーザーや IAM ユーザーに最大さいだい８やっつの MFA を割わり当あてられる ログインするときには割わり当あてられた中なかのどれか一ひとつの MFA を使つかってログイン さっそく試ためしてみた 適当てきとうな IAM ユーザーを用意よういしてどんな動うごきになるのかを確認かくにんしてみました。 まずは MFA の設定せっていをします。MFA の設定せってい方法ほうほうは従来じゅうらいと変かわらず、AWS マネージメントコンソールの IAM 画面がめんから登録とうろくをしていきます。 2022/11/17 追記ついき： MFA の設定せってい方法ほうほうについて従来じゅうらいと変かわらずと記載きさいしておりましたが、正確せいかくには従来じゅうらいと異ことなり MFA の名前なまえをつける必要ひつようがあります。 またこの名前なまえについては、AWS アカウント内ないで一意いちい※１である必要ひつよう があり、例れい

                IAMユーザーやAWSアカウントのルートユーザー に複数の MFA デバイスを割り当てる事ができるようになりました | DevelopersIO

              • Google Cloud のアクセス管理かんりをおさらいしよう 2020アップデート版ばん

                この記事きじは Google Cloud Japan Customer Engineer Advent Calendar 2020 の 2日にち目めの記事きじです。 TL;DR本ほん記事きじではGoogle Cloud でのアクセス管理かんりについて整理せいりしていきます。 はじめにGoogle Cloud Japan Customer Engineer Advent Calendar 2019 で、Google Cloud の IAM をおさらいしよう という記事きじを書かいたのですが、多おおくの方ほうに読よんでいただいたのですが、逆ぎゃくに多おおくの方ほうが悩なやまれるトピックなのだなと感かんじました。2020年ねんも多おおくのアップデートがありましたので、改あらためて Google Cloud の アクセス管理かんりをおさらいしていきましょう。 クラウドを使つかう上うえで、ユーザー管理かんりや権限けんげん管理かんりは非常ひじょうに重要じゅうようです。Google Cloud を使つかう際さいに、どのようにユーザー管理かんりできるのか

                  Google Cloud のアクセス管理をおさらいしよう 2020アップデート版

                • 社外しゃがいの開発かいはつメンバーをAWSアカウントに入いれるときのIAM設定せっていを考かんがえている - kmiya_bbmのブログ

                  サービスを開発かいはつする際さいに、社外しゃがいの業者ぎょうしゃさんに開発かいはつをお願ねがいしたり、社外しゃがいパートナーに開発かいはつに参加さんかしてもらう、ということがよくあります。 開発かいはつに使つかうAWS環境かんきょうとして、うちの会社かいしゃで作成さくせいしたAWSアカウントに入はいってきてもらうこともあるのですが、このときにAWSアカウントの管理かんり者しゃとして社外しゃがいの開発かいはつメンバーにどのような権限けんげんを持もたせるのが良よいか、それをどう実現じつげんするのが良よいか、いつも悩なやみます。 このエントリでは現時点げんじてんでの考かんがえと実装じっそう方法ほうほうをまとめておこうと思おもいます。 課題かだい 私わたしが関かかわる案件あんけんで社外しゃがいの開発かいはつメンバーに協力きょうりょくを仰あおぐ場合ばあい、大抵たいていはPoCから始はじまるような新規しんきサービスの構築こうちく案件あんけんとなるためAWSのどのサービスを使つかうか最初さいしょからすべて決きまっていることは稀まれです。 最初さいしょは ALB + EC2 + RDS で作つくり始はじめたシステムにDynamoDBが導入どうにゅうされ、AWS IoT coreが導入どうにゅうされ、Kinesis Stream が導入どうにゅうされ、、

                    社外の開発メンバーをAWSアカウントに入れるときのIAM設定を考えている - kmiya_bbmのブログ

                  • GitHub ActionsにAWSクレデンシャルを直接ちょくせつ設定せっていしたくないのでIAMロールを利用りようしたい | DevelopersIO

                    こんにちは！コンサル部ぶのinomaso(@inomasosan)です。 前回ぜんかいと前々回ぜんぜんかいでGitHub ActionsからECSのCI/CDやIAMポリシーの最小さいしょう権限けんげん作成さくせいを試ためしてみました。 [初心者しょしんしゃ向むけ] GitHub ActionsからECS FargateにCI/CDしてみた GitHub ActionsからECSとECRへのCI/CDを最小さいしょう権限けんげんで実行じっこうしたい 今回こんかいはGitHub ActionsでAWSの一時いちじ的てきなクレデンシャル(アクセスキーID、シークレットアクセスキー)を利用りようしたいので、IAMユーザーの代かわりにOIDCプロバイダとIAMロールを設定せっていしていきます。 IAMユーザーのクレデンシャルだとダメなの？ IAMユーザーで発行はっこうしたクレデンシャルは永続えいぞく的てきに利用りよう可能かのうです。 GitHubではAWSのクレデンシャルをSecretsにより秘匿ひとく化かできますが、AWS外がいのサービスに永続えいぞく的てきなクレデンシャル

                      GitHub ActionsにAWSクレデンシャルを直接設定したくないのでIAMロールを利用したい | DevelopersIO

                    • GCPのWorkload Identityを使つかってAWSのRoleとGCPのサービスアカウントを連携れんけいさせる

                      GCPのWorkload Identityを使つかってAWSのRoleとGCPのサービスアカウントを連携れんけいさせる 2022.12.09 技術ぎじゅつ AWS, GCP 動機どうきと解決かいけつ法ほう サービスアカウントのシークレットキーjsonをEC2上じょうに置おくのやだなー（何なにかの拍子ひょうしに流出りゅうしゅつとかしたらめんどいなー） アクセス元もとのバッチがAWSにあるんだから、asumerole的てきなことがAWSとGCPをまたいでできれば便利べんりなんだけどなー という動機どうきから、表題ひょうだいの通とおり Workload Identity を使つかって、AWS IAM Role と GCP Service Account を連携れんけいさせました。 Workload Identity連携れんけい とは？ Workload Identity 連携れんけいは、キーなしの新あたらしいアプリケーション認証にんしょうメカニズムであり、オンプレミス、AWS、Azure で実行じっこうするワークロードは、外部がいぶ ID プロバイダ（I

                      • IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity | Amazon Web Services

                        AWS Security Blog IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity In 2019, AWS Identity and Access Management (IAM) Access Analyzer was launched to help you remove unintended public and cross account access by analyzing your existing permissions. In March 2021, IAM Access Analyzer added policy validation to help you s

                          IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity | Amazon Web Services

                        • AWS Identity and Access Management introduces IAM Roles Anywhere for workloads outside of AWS

                          AWS Identity and Access Management (IAM) now enables workloads that run outside of AWS to access AWS resources using IAM Roles Anywhere. IAM Roles Anywhere allows your workloads such as servers, containers, and applications to use X.509 digital certificates to obtain temporary AWS credentials and use the same IAM roles and policies that you have configured for your AWS workloads to access AWS reso

                            AWS Identity and Access Management introduces IAM Roles Anywhere for workloads outside of AWS

                          • AWSを使つかうにあたりIAMのベストプラクティスをもう一度いちど確認かくにんする

                            本当ほんとうはre:Inventかその周辺しゅうへんで発表はっぴょうされたアップデートについて書かこうかなと思おもったんですが、自分じぶん自身じしんの時間じかんの都合つごうと、例れいによって某ぼうブログに大量たいりょうに情報じょうほうがあるので今回こんかいは見送みおくりましたｗ zennに何なにか書かこうと思おもって書かくのも今回こんかいが初はつですね。 さて、今回こんかいは個人こじん的てきに以前いぜんから非常ひじょうに気きになってしまう使つかわれ方かたが多おおいIAMの使つかい方かたについて、あらためてネタにしようと思おもいます。 どちらかというとAWSにそれほど詳くわしくない人ひと向むけのつもりです。 しれっと使つかってますが、そもそもベストプラクティスって何なに？　という方ほうはとりあえずこちらを ベストプラクティス (best practice)とは あくまでもベストプラクティスなのでいきなり全部ぜんぶを満みたすのは難むずかしいかもしれませんが、こういうものがあるんだよ、というのを認知にんちしてもらえればと思おもいます。 とりあえず真まっ先さきに気きを付つけたほうがよいことや注意ちゅういしてほしいことは よく見みるまずい（と

                              AWSを使うにあたりIAMのベストプラクティスをもう一度確認する

                            • AWS IAM Identity Center を利用りようして Azure AD のユーザー情報じょうほうで AWS アカウントへのアクセスを試ためしてみる | DevelopersIO

                              AWS IAM Identity Center を利用りようして Azure AD のユーザー情報じょうほうで AWS アカウントへのアクセスを試ためしてみる Azure AD と AWS IAM Identity Center を連携れんけいさせて、Azure AD の認証にんしょう情報じょうほうで AWS アカウントにアクセスする設定せってい方法ほうほうをまとめました。 Azure AD ユーザーの認証にんしょう情報じょうほうを使つかって AWS IAM Identity Center 経由けいゆで AWS アカウントにアクセスする方法ほうほうを紹介しょうかいします。以前いぜんにも同様どうようのブログを書かきましたが、AWS Single Sign-On 時代じだいだったため、改あらためて書かき直なおしました。手順てじゅんに変かわりがないか確認かくにんしたい意図いともありましたが、ほぼ同おなじ手順てじゅんで設定せっていできました。 構成こうせいと全体ぜんたいの流ながれ 構成こうせい図ずと設定せってい内容ないようを示しめします。 ユーザー/グループ情報じょうほうの同期どうきは SCIM による自動じどう同期どうきを採用さいようしています。 設定せっていの流ながれ SA

                                AWS IAM Identity Center を利用して Azure AD のユーザー情報で AWS アカウントへのアクセスを試してみる | DevelopersIO

                              • AWS CLIで動うごかして学まなぶCognito IDプールを利用りようしたAWSの一時いちじクレデンシャルキー発行はっこう | DevelopersIO

                                「Cognito IDプールってやつはAWSリソースへのアクセスを制御せいぎょする認可にんか部分ぶぶんを担当たんとうしているらしいけど、いったいどういう理屈りくつでそうなってるんだ…？」 そんな自分じぶんの疑問ぎもんからAWSのドキュメントを読よみ実際じっさいに手てを動うごかして得えられたCognito IDプールに対たいする理解りかいをまとめました。 「Cognito IDプールってやつはAWSリソースへのアクセスを制御せいぎょする認可にんか部分ぶぶんを担当たんとうしているらしいけど、いったいどういう理屈りくつでそうなってるんだ…？」 そんな自分じぶんの疑問ぎもんからAWSのドキュメントを読よみ手てを動うごかして得えられたCognito IDプールに対たいする理解りかいを、 AWS CLIで再現さいげんできる形かたちにまとめてみました。 Cognito IDプールでAWSの一時いちじクレデンシャルキーを発行はっこうすることによって、Cognito IDプールの世界せかいからIAMの世界せかいへ落おとし込こめると、だいぶイメージが付つきやすいんじゃないかと思おもいます。 AW

                                  AWS CLIで動かして学ぶCognito IDプールを利用したAWSの一時クレデンシャルキー発行 | DevelopersIO

                                • GCPのIAMポリシー周まわりでドハマりした話はなし | フューチャー技術ぎじゅつブログ

                                  はじめにこんにちは、Technology Innovation GroupのDXユニット所属しょぞくの村田むらたと申もうします！ DXユニットとはデジタルトランスフォーメーションに関かかわる仕事しごとを主おもに推進すいしんしていくチームです。 私わたしは現在げんざいFuture IoTプロジェクトに携たずさわっており、最近さいきんはもっぱらクラウドインフラに従事じゅうじしています。 メインの仕事しごとは複数ふくすうのGoogle Cloud Platform(以下いか、GCP)プロジェクトとそれぞれの環境かんきょう（Production/Staging/Developmentなど）の構築こうちく・運用うんようです。 この中なかで個人こじん的てきにとても面白おもしろいと思おもった知見ちけんを得えたので「これはぜひブログにしよう！」といま筆ひつを走はしらせています。 クラウドインフラの使命しめいクラウドインフラと一言ひとことで言いっても意味いみする範囲はんいはとても広ひろいですが、私わたしがこのブログで紹介しょうかいする内容ないようはどちらかというと地味じみかもしれません。 私わたしが今日きょう紹介しょうかいしたいのは、GCPの「

                                  • CloudFormationでパスワードを自動じどう生成せいせいしてテンプレート内ないで利用りようする | DevelopersIO

                                    CloudFormationでパスワードを取とり扱あつかう場合ばあい、パスワードをどこに保存ほぞんするか悩なやましいです。 パラメータストアに保存ほぞんしておいて参照さんしょうするというのもよい方法ほうほうですが、 もっとサクッと作つくりたい！と、いうことで、CloudFormationでパスワードを自動じどう生成せいせいする方法ほうほうを紹介しょうかいします。 CloudFormationでパスワードを取とり扱あつかう場合ばあい、パスワードをどこに保存ほぞんするか悩なやましいです。 たとえば、CloudFormationでIAM Userを作つくりたい場合ばあい、IAM Userのパスワードはどこに保存ほぞんしましょう？ CloudFormationテンプレート内ないにハードコーディングするのは、セキュリティの観点かんてんから好このましくありません。 パラメータストアのSecureStringに保存ほぞんしておいて参照さんしょうするというのは、よい方法ほうほうだと思おもいます。 [新しん機能きのう]AWS CloudFormationでAWS Systems M

                                      CloudFormationでパスワードを自動生成してテンプレート内で利用する | DevelopersIO

                                    • [アップデート] IAM アクセスアドバイザーによる「アクションレベルでの最終さいしゅう実行じっこう履歴りれきの表示ひょうじ」に EC2、IAM、Lambda が対応たいおうしました！ | DevelopersIO

                                      コンバンハ、千葉ちば（幸こう）です。 IAM アクセスアドバイザーで、新あらたに EC2、IAM、Lambda もアクションレベルで最終さいしゅうアクセス時刻じこくを確認かくにんできるようになりました！ Review last accessed information to identify unused EC2, IAM, and Lambda permissions and tighten access for your IAM roles 必要ひつよう最小限さいしょうげんの権限けんげんに絞しぼっていく、そのアプローチがまた一ひとつ楽らくになりました。 何なにが変かわったのか IAM アクセスアドバイザーは、特定とくていの IAM リソース（ユーザー/グループ/ロール/ポリシー）に対たいして以下いかを分析ぶんせき、取得しゅとくしてくれる機能きのうです。 アクセス可能かのうな AWS サービス 最終さいしゅうアクセス時刻じこく IAM リソースのアイデンティティベースポリシーを基もとに「どのサービスにアクセス可能かのうか」を判断はんだんし、その上じょう

                                        [アップデート] IAM アクセスアドバイザーによる「アクションレベルでの最終実行履歴の表示」に EC2、IAM、Lambda が対応しました！ | DevelopersIO

                                      • IAM Identity Centerでもaws-vaultでセキュアにAWS CLIを使つかう - Nealle Developer's Blog

                                        こんにちはSREチームの宮みや後ご(@miya10kei)です。最近さいきん、トリュフナッツにハマりビール🍺の消費しょうひ量りょうが増ふえています。 AWS CLIを使用しようする時ときにaws-vaultは使つかっていますか？ AWSのユーザ管理かんりをAWS IAM Identity Centerに移行いこうした際さいにaws-vaultの設定せっていでつまずいたので解決かいけつ方法ほうほうを紹介しょうかいしたいと思おもいます。 AWS IAM Identity Centerとは？ 複数ふくすうの AWSアカウントやアプリケーションへのワークフォースのアクセスを一元いちげん管理かんりするためのサービスです。外部がいぶIDプロバイダーと接続せつぞくしSSO（シングルサインオン）連携れんけいをすることができます。ニーリーではGoogle Workspaceと連携れんけいさせGoogleアカウントでログインできるようにしています。 aws-vaultとは？ aws-vaultはAWS CLIを使用しようする際さいの認証にんしょう情報じょうほうを安全あんぜんに保存ほぞんし、アクセス

                                          IAM Identity Centerでもaws-vaultでセキュアにAWS CLIを使う - Nealle Developer's Blog

                                        • Terraform で GCP IAM 設定せっていどれ使つかうのがいいのか - pokutuna

                                          additive: add members to role, old members are not deleted from this role. authoritative: set the role's members (including removing any not listed), unlisted roles are not affected.

                                            Terraform で GCP IAM 設定どれ使うのがいいのか - pokutuna

                                          • RBAC DeepDive - SAML Authentication | IAM Role for Service Accounts

                                            「GW直前ちょくぜん！まだ間まに合あうコンテナバケーション with Amazon EKS」で話はなした内容ないようです。 SAML 認証にんしょうと IAM Role for Service Accounts について話はなしています。

                                              RBAC DeepDive - SAML Authentication | IAM Role for Service Accounts

                                            • You can now assign multiple MFA devices in IAM | Amazon Web Services

                                              AWS Security Blog You can now assign multiple MFA devices in IAM At Amazon Web Services (AWS), security is our top priority, and configuring multi-factor authentication (MFA) on accounts is an important step in securing your organization. Now, you can add multiple MFA devices to AWS account root users and AWS Identity and Access Management (IAM) users in your AWS accounts. This helps you to raise

                                                You can now assign multiple MFA devices in IAM | Amazon Web Services

                                              • 検証けんしょう環境かんきょうのURLが入はいったメールを本番ほんばん環境かんきょうのユーザーに送おくってしまった話はなし - Qiita

                                                この記事きじは「本番ほんばん環境かんきょうでやらかしちゃった人ひと Advent Calendar 2020」24日にち目めの記事きじです。 遠とおい昔むかし、はるか彼方かなたの銀河系ぎんがけいでの話はなしです。 TL;DR IAMの権限けんげんはしっかりやりましょう。検証けんしょう環境かんきょうと本番ほんばん環境かんきょうでアカウントを分わけるとより安心あんしんできます。 何なにをやらかしたのか やらかし前まえの状態じょうたい マッチングサービスの開発かいはつをしています。そのサービスにはサービス内ないでメッセージが届とどくとその旨むねをEいーメールで通知つうちする機能きのうがあります。 システム的てきにはサービスを動うごかしているWebアプリケーションからSQSのメール用ようのキュー（以後いごMaill Queue）にメッセージを送信そうしんし、メール送信そうしん用ようのWorkerがMaill Queueからメッセージを取得しゅとく、差出人さしだしにんやURLなどの情報じょうほうを埋うめてEいーメールを送信そうしんします。差出人さしだしにんやURLは本番ほんばん環境かんきょう、検証けんしょう環境かんきょうでそれぞれ別べつの値ねが入はいります。 また検証けんしょう環境かんきょうと本番ほんばん環境かんきょうは同一どういつのAWSアカウント内ないにあ

                                                  検証環境のURLが入ったメールを本番環境のユーザーに送ってしまった話 - Qiita

                                                • lambrollでシェルスクリプトをLambdaにデプロイして実行じっこうする

                                                  lambrollでシェルスクリプトをLambdaにデプロイして実行じっこうする投稿とうこう者しゃ: inamuu 投稿とうこう日び: 2023年ねん1月がつ19日にち2023年ねん1月がつ19日にち 概要がいよう 仕事しごとをしていると、歴史れきしのあるシェルスクリプトがEC2で動うごいていたりすることがある。 そういったスクリプトをなにかしらのスクリプト言語げんごで書かき換かえるのもやぶさかではないのだが、数かずが多おおいと諦あきらめの気持きもちが湧わき出でてくる。 そこで、シェルスクリプトのままでもLambdaにデプロイしてバッチ的てきに動うごかして、サクッと移行いこうできたりしないかなという思おもいが出でてきた。 そこで、Lambdaのデプロイツールにlambrollを検証けんしょうしてみることにした。 インストール 手元てもとがMacOSなのでbrewでインストール。 $ brew install fujiwara/tap/lambroll $ lambroll versions 2023/01/18 23:14:53 [i

                                                    lambrollでシェルスクリプトをLambdaにデプロイして実行する

                                                  • 管理かんりポリシーの差分さぶんを出力しゅつりょくする AWS CLI エイリアス aws diff を作つくってみた | DevelopersIO

                                                    コンバンハ、千葉ちば（幸こう）です。 管理かんりポリシー、特とくに AWS 管理かんりポリシーの変更へんこう差分さぶんを確認かくにんしたい機会きかいがたまにあります。 マネジメントコンソール上じょうで差分さぶん表示ひょうじするような機能きのうがあれば便利べんりなのですが、現時点げんじてんでは実装じっそうされていません。 ないなら AWS CLI でやってみるか、ということでエイリアスを組くんでみました。 管理かんりポリシーの差分さぶんを表示ひょうじするエイリアス 以下いかのエイリアスを設定せっていしました。 ~/.aws/cli/alias [toplevel] diff = !f() { VERSION=$(aws iam get-policy --policy-arn $1 --query 'Policy.DefaultVersionId' --output text | tr -d "v") BEFORE_VERSION=$((VERSION-1)) BEFORE_RESULT=$(aws iam get-polic

                                                      管理ポリシーの差分を出力する AWS CLI エイリアス aws diff を作ってみた | DevelopersIO

                                                    • How to create IAM roles for deploying your AWS Serverless app | Serverless First

                                                      Getting IAM permissions right is one of the hardest parts about building serverless applications on AWS. Many official tutorials and blog posts cop out of giving you the full details on how to set up IAM, preferring something vague like “ensure you use least-privilege permissions when creating this role”. Or worse, they give you a wide open wildcard or admin-level example policy with a “don’t use

                                                        How to create IAM roles for deploying your AWS Serverless app | Serverless First

                                                      • AWS CLIをAWS IAM Identity Center(SSO)で認証にんしょうさせるには? | DevelopersIO

                                                        AWS OrganizationsのAWS IAM Identity Center(旧きゅうAWS Single Sign-On;AWS SSO)を利用りようすると、Organizations配下はいかのAWSアカウントにSSOできます。 本ほん記事きじでは、同どう機能きのうをAWS CLIから利用りようする方法ほうほうを紹介しょうかいします。 AWS IAM Identity Centerの詳細しょうさいは次つぎのブログを参照さんしょうください。 なお、本ほん記事きじではAWS Identity Center directoryでユーザー管理かんりしているものとします。 ポイント IAM Identity CenterにはAWS CLI v2が対応たいおう。v1は未み対応たいおう 設定せっていファイルはAWS CLIだけでなくAWS SDK全般ぜんぱんで流用りゅうよう可能かのう IAM Identity Centerはリージョナル・サービス IAM ユーザーのように永続えいぞく的てきなアクセスキーは存在そんざいせず一時いちじ的てきな認証にんしょう情報じょうほうを利用りよう 各かくアカウントへ

                                                          AWS CLIをAWS IAM Identity Center(SSO)で認証させるには? | DevelopersIO

                                                        • IAM初心者しょしんしゃがAWS CLIでスイッチロールするまで | DevelopersIO

                                                          こんにちは。 サービスGの金谷かなやです。 これまでIAMの設定せっていを自分じぶんでやることがあまりなく、スイッチロールで何なにが起おきているのか全然ぜんぜん理解りかいできていなかったのでまとめようと思おもいます。 まず大前提だいぜんてい AWSアカウント≠ IAMユーザー です。 当然とうぜんといえば当然とうぜんなのですが別物べつものです。 ざっくり説明せつめいするとAWSアカウントの中なかにIAMユーザーがいるといった形かたちで、AWSアカウント＝ルートユーザーのようなイメージです。 私わたし個人こじんの経験けいけんとしてはプライベートでAWSを学まなび触さわり始はじめたばかりのときは IAMを何なにも設定せっていせずに他たのサービスを触さわったりしていましたが、通常つうじょうは使用しようするべきではないです。 ちゃんとIAMユーザーを作成さくせいしてそちらで作業さぎょうするようにしましょう。 スイッチロールとは 名前なまえの通とおりIAMロールを切きり替かえる機能きのうです。 アカウントを跨またいだロールの切きり替かえも可能かのうです。（というかこちらをメインに使つかいます） 上うえ図ずではスイッチ元もと

                                                            IAM初心者がAWS CLIでスイッチロールするまで | DevelopersIO

                                                          • AWSサービスに渡わたすIAMロールを制限せいげんする | DevelopersIO

                                                            EC2インスタンスやLambda関数かんすうにはIAMロールをアタッチすることができます。 ゆるいIAMポリシーを採用さいようしていると、STS 可能かのうな任意にんいのIAMロールを利用りようできてしまいます。 この問題もんだいを解決かいけつするために、IAMロールとロールを利用りようするAWSサービスのペアを制限せいげんする方法ほうほうを紹介しょうかいします。 AWSサービスに渡わたすIAMロールを制限せいげんする 例たとえば、EC2 インスタンスに特定とくていのIAMロールのみアタッチ出来できるようにするには、次つぎのように定義ていぎします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "IAMPassRoleForEC2", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "arn:aws:iam::12345:role/EC2Role", "Condition": {

                                                              AWSサービスに渡すIAMロールを制限する | DevelopersIO

                                                            • 【AWS】AWS APIの認証にんしょう・認可にんかの仕組しくみを理解りかいする【Signature V4】 - Qiita

                                                              はじめに Amplifyを利用りようしてアプリケーションを作つくる場合ばあい、Cognito User Pool／Cognito Identity Pool（Cognito Federated Identities）を利用りようしてAPI GatewayでAuthorizationする方法ほうほうが暗黙あんもく裡うらにデフォルトになっているように見みえます。 よく使つかわれるであろうと思おもわれる割わりには、その仕組しくみについての説明せつめいがあまり見当みあたらなかったので解説かいせつ記事きじを書かこうとしましたが、前提ぜんていとなる事項じこうがあまりにも多おおいことが分わかったので、個別こべつの記事きじとして分離ぶんりしました。 本稿ほんこうでは、AccessKeyIdやSecretAccessKeyの使つかわれ方かた、AWS APIにおけるSignature V4の仕組しくみなどについて解説かいせつします。 API GatewayのAuthorization方式ほうしきとして「AWS_IAM」という項目こうもくを選択せんたくできますが、本稿ほんこうの内容ないようを理解りかいす

                                                                【AWS】AWS APIの認証・認可の仕組みを理解する【Signature V4】 - Qiita

                                                              • Workload Identity Federationを図ずで理解りかいする - Carpe Diem

                                                                概要がいよう GCPのWorkload Identity連携れんけいはサービスアカウントで秘密ひみつ鍵かぎを作つくらずともGCPリソースへのアクセス権けんを他たの環境かんきょう（オンプレ、別べつパブリッククラウド）に付与ふよすることができます。 これにより AWSからGCPリソースにアクセスする GitHub ActionsからGCRにDocker imageをpushする CircleCIでGKEのデプロイを行おこなう といった連携れんけいが鍵かぎなしで実現じつげんできます。 ただ実装じっそうだけだとイメージしづらいので今回こんかいは図示ずししてみました。 Workload Identity Federation Workload Identity連携れんけいにおける登場とうじょう人物じんぶつは以下いかです。 左ひだりのWorkloadsがGCPリソースにアクセスしたいアプリケーションに当あたります。 準備じゅんび Workload Identity Poolの作成さくせいとサービスアカウントの作成さくせい まずはWorkload Identit

                                                                  Workload Identity Federationを図で理解する - Carpe Diem

                                                                • IAM ポリシー未み設定せっていの IAM ユーザーが生成せいせいした S3 署名しょめい付つき URL (presigned URL) を使つかってオブジェクトを Get できるのはなぜか | DevelopersIO

                                                                  IAM ポリシー未み設定せっていの IAM ユーザーが生成せいせいした S3 署名しょめい付つき URL (presigned URL) を使つかってオブジェクトを Get できるのはなぜか コンバンハ、千葉ちば（幸こう）です。 突然とつぜんですが以下いかのようなケースを考かんがえてください。 IAM ポリシーがアタッチされていない IAM ユーザーが存在そんざいする 当該とうがい IAM ユーザーが特定とくていの S3 バケット内ないのオブジェクトに対たいする署名しょめい付つき URL を生成せいせいする 生成せいせいされた URL を用もちいて任意にんいの利用りよう者しゃがオブジェクトを Get する 上記じょうきを実現じつげんしたいと考かんがえたときに必要ひつようとなる設定せっていが何なにか、皆みなさんは思おもいつくでしょうか。なお、 IAM ユーザーと S3 バケットは同一どういつの AWS アカウントに存在そんざいするものとします。 「そもそも IAM ポリシーが無ないのに署名しょめい付つき URL を生成せいせいできるの？」という部分ぶぶんから引ひっかかる方ほうもいるかと思おもいますが、実じつはできます。このエント

                                                                    IAM ポリシー未設定の IAM ユーザーが生成した S3 署名付き URL (presigned URL) を使ってオブジェクトを Get できるのはなぜか | DevelopersIO

                                                                  • IT未み経験けいけんの初心者しょしんしゃがIAMを理解りかいしようとしてみた | DevelopersIO

                                                                    はじめに AWSを初はじめて学習がくしゅうして難むずかしいと感かんじたIAMについて、自分じぶんなりの理解りかいを書かいてみました。 同おなじような初心者しょしんしゃの方ほうでも読よみやすいように、なるべく平易へいいな言葉ことばで書かくことを心掛こころがけています。 対象たいしょう者しゃ これからAWSを学習がくしゅうしたい初心者しょしんしゃ IAMって何なになのか、なんとなく理解りかいしたい方ほう そもそも何なにのためにそんな機能きのうがあるの？という疑問ぎもんを持もっている方ほう IAMとは IAMとは、「Identity and Access Management」の略りゃくで、その名なのとおり、IDとアクセス権けんを管理かんりする機能きのうです。IAMを使用しようすれば、誰だれがどのサービスにアクセスできるのかを、許可きょかまたは拒否きょひすることができます。全すべての人ひとが全すべてのサービスやデータに対たいしてアクセス権けんを持もつというのは安全あんぜんではありません。必要ひつような人ひとに、必要ひつよう最低限さいていげんの権限けんげんのみを付与ふよすることが推奨すいしょうされています。 そもそもなぜ管理かんり機能きのうが必要ひつようなの？ IT未み経験けいけんの自分じぶんがAWSを勉強べんきょうして

                                                                      IT未経験の初心者がIAMを理解しようとしてみた | DevelopersIO

                                                                    • [AWS Organizations] SCP(サービスコントロールポリシー)の継承けいしょうの仕組しくみを学まなぼう | DevelopersIO

                                                                      はじめに 大阪おおさかオフィスの川原かわらです。 AWS Organizations の SCP(サービスコントロールポリシー)の継承けいしょう について、 仕組しくみを学まなびましょう。 前提ぜんてい知識ちしき AWS Organizationsは マルチアカウントを統率とうそつするためのサービス です。 組織そしき単位たんい(OU) による アカウントのグループ化かや、 サービスコントロールポリシー(SCP) によるグループ単位たんいのサービス制限せいげんが可能かのうです。 – 画像がぞう: AWS Organizations の用語ようごと概念がいねん | AWSドキュメント OUとは 組織そしき単位たんい(Organizational Unit: OU) は AWSアカウントのグループ化か を実現じつげんする要素ようそです。 OU 配下はいかに他たOUをぶらさげる、ツリー構造こうぞうを構築こうちくできます。 SCPとは サービスコントロールポリシー(SCP)は OUまたはアカウントに指定していするポリシー です。 OU/アカウントで実行じっこうできるサ

                                                                        [AWS Organizations] SCP(サービスコントロールポリシー)の継承の仕組みを学ぼう | DevelopersIO

                                                                      • TerraformでGoogle CloudのIAMを管理かんりする際さいの注意ちゅうい点てん - G-gen Tech Blog

                                                                        G-gen の堂原どうばらです。 当とう記事きじでは、Terraform を用もちいて Google Cloud (旧称きゅうしょう GCP) の Identity and Access Management (IAM) を管理かんりする際さいに、注意ちゅういすべき点てんについて紹介しょうかいします。 はじめに google_xxx_iam の使つかい分わけ google_project_iam_xxx の使つかい分わけと注意ちゅうい点てん google_project_iam_policy google_project_iam_binding google_project_iam_member はじめに 改あらためて、当とう記事きじでは Terraform を用もちいて Google Cloud の IAM を管理かんりする際さいに注意ちゅういすべき点てんとして、 具体ぐたい的てきには google_project_iam_policy、google_project_iam_binding 及および google_projec

                                                                          TerraformでGoogle CloudのIAMを管理する際の注意点 - G-gen Tech Blog

                                                                        • Local cluster for EKS on AWS Outpostsについて紹介しょうかい - NTT Communications Engineers' Blog

                                                                          はじめに こんにちは、イノベーションセンターの鈴すずヶ嶺みねです。 本ほん記事きじでは、自社じしゃデータセンター等とうでAWSサービスを利用りよう可能かのうなAWS OutpostsにおけるElastic Kubernetes Service(EKS)で新あらたに追加ついかされたLocal clusterの概要がいようや通信つうしん切断せつだん検証けんしょうの結果けっかについて紹介しょうかいします。 以前いぜん記事きじにした2022年ねん3月がつ17日にち時点じてんでは、ワーカーノードはAWS Outposts上じょうで実行じっこうし、KubernetesコントロールプレーンはAWS Cloud上じょうで実行じっこうする構成こうせいでした。この構成こうせいがLocal clusterによってKubernetesコントロールプレーンもAWS Outposts上じょうで実行じっこう可能かのうになりました。これによりAWS CloudとAWS Outposts間あいだの通信つうしん切断せつだんなどによるアプリケーションのダウンタイムのリスクを軽減けいげんすることが可能かのうとなりました。 engineers.ntt.

                                                                            Local cluster for EKS on AWS Outpostsについて紹介 - NTT Communications Engineers' Blog

                                                                          • 多た要素ようそ認証にんしょう(MFA)するまで使つかえません！なIAMユーザを作成さくせいしてみた | DevelopersIO

                                                                            はじめに IAMユーザを利用りよう者しゃへ引ひき渡わたす際さいに「絶対ぜったいに多た要素ようそ認証にんしょう(MFA)の設定せっていを入いれてくださいね！！」と伝つたえても、 そのユーザが本当ほんとうにMFAを有効ゆうこう化かしてくれたのか、その確認かくにんや催促さいそくに手間てまがかかるときがあります。 そんな手間てまを省はぶくため、引ひき渡わたすIAMユーザには予あらかじめ MFAを利用りようしていないと権限けんげんに制限せいげんがかかる仕組しくみを仕込しこんでおくことができます。 概要がいよう IAMユーザに以下いかの権限けんげんを付与ふよすれば完了かんりょうです。 (1) MFAを設定せってい・有効ゆうこう化かするための権限けんげん (2) MFAを利用りようしていない場合ばあい、(1)以外いがいすべてのアクションを拒否きょひする権限けんげん (3) 本来ほんらい許可きょかしたい権限けんげん (2)の設定せっていでは、IAMポリシーのContdition要素ようそを使つかってMFA利用りよう有無うむによる条件じょうけん分岐ぶんきを設定せっていします。 (3)で許可きょかされた権限けんげんであっても、 MFAを利用りようしていない場合ばあいは(2)による明示めいじ的てきな拒否きょひ設定せっていが上回うわまわり、利用りようすることができなくなる仕組しくみです。

                                                                              多要素認証(MFA)するまで使えません！なIAMユーザを作成してみた | DevelopersIO

                                                                            • 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 サービスへのリンクが追加ついかされているくらいでしょうか。 冒おかせ

                                                                                AWS Single Sign-onがAWS IAM Identity Centerになりました！ | DevelopersIO

                                                                              • [UPDATE]フェデレーションでタグを渡わたせるSTSの新しん機能きのうSession Tagがリリースされました #reinvent | DevelopersIO

                                                                                こんにちは、臼田うすだです。 みなさん、ID管理かんりしていますか？ 今回こんかいはIDフェデレーションでIAMを利用りようしている際さいに、IdPから属性ぞくせい(Attribute)をAWSのタグとして受うけ取とることができるSession Tagの機能きのうがリリースされたので紹介しょうかいします。 New for Identity Federation – Use Employee Attributes for Access Control in AWS | AWS News Blog RBACとABAC 良よさを知しるにはまず背景はいけいから。 アクセス制御せいぎょの方式ほうしきとしてRBAC(Role-based Access Control)がよく使つかわれます。RBACでは、権限けんげんを個人こじんではなくRole(役割やくわり)に割わり当あてて管理かんりする方法ほうほうで、個人こじんごとポリシーをメンテナンスしなくて良よくなるのでユーザが増ふえても管理かんりが楽らくになる仕組しくみでした。 しかしこれも進すすんでくると、今度こんどは

                                                                                  [UPDATE]フェデレーションでタグを渡せるSTSの新機能Session Tagがリリースされました #reinvent | DevelopersIO

                                                                                • IAM ロールの信頼しんらいポリシーで設定せっていする外部がいぶ ID(sts:ExternalId) について | DevelopersIO

                                                                                  IAM ロールの信頼しんらいポリシーに設定せっていする外部がいぶ ID(sts:ExternalI) について勉強べんきょうしました。 こんにちは、岩城いわきです。 3rd Party 製せいの SaaS と AWS アカウントを連携れんけいする際さい、専用せんようの IAM ロールの作成さくせいと作成さくせいしたロールに以下いかのような信頼しんらいポリシーを定義ていぎして、特定とくていの AWS アカウントから AssumeRole を許可きょかすることがあります。 { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::xxxxxxxxxxxx:iamuser" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "xxx

                                                                                    IAM ロールの信頼ポリシーで設定する外部 ID(sts:ExternalId) について | DevelopersIO
                                                                                  前まえのページ 2 3 4 5 6 7 8 9 10 11 次つぎのページ

                                                                                  新着しんちゃく記事きじ

                                                                                  はてなブックマーク

                                                                                  公式こうしきTwitter

                                                                                  はてなのサービス

                                                                                  • App Storeからダウンロード
                                                                                  • Google Playで手に入れよう
                                                                                  Copyright © 2005-2024 Hatena. All Rights Reserved.