しばたです。 AWS環境を構築・運用する際は各リソースの識別子となるAmazon Resource Names(ARN)をよく見ることになると思います。 ある日ふとタイトル通りの疑問が湧いたので調べてみることにしました。 Amazon S3のARNにある ::: ってなんだろう？ AWSの識別子であるARNの形式については以下のドキュメントに記載されています。 Amazon リソースネーム (ARN) ドキュメントの内容を一部引用するとARNは一般的に以下の:区切りの形式を採ります。 arn:partition:service:region:account-id:resource-id arn:partition:service:region:account-id:resource-type/resource-id arn:partition:service:region:account-
aws configure でアクセスキーを手打ちせず aws configure import で CSV ファイルからインポートしてみた コンバンハ、千葉（幸）です。 AWS CLI （など）を使用するためにアクセスキーを設定する際、皆さんは以下のような手順をとるのではないでしょうか。 「ひとまずaws configureを叩く。」 $ aws configure ↑（--profileオプションを付与すれば名前付きプロファイルへの設定となりますが、デフォルトではdefaultというプロファイルに対する設定となります。） 「各項目の入力が促されるため、必要な項目を入力していく。」 $ aws configure AWS Access Key ID [None]: #アクセスキーを入力 AWS Secret Access Key [None]: #シークレットキーを入力 Default
最近 Mackerel の AWS インテグレーション機能にいくつかセキュリティ強化のアップデートが入りました。 (「最近」と言っても最も古いアップデートは 2 年前ですが・・・) AWS インテグレーションで IAM ロールによる認証利用時の権限チェック頻度を変更しました ほか AWS インテグレーション CloudFront 連携で取得できるメトリックを追加しました ほか 【リリース予告】AWS インテグレーションの権限チェックを強化していきます AWS Step Functions インテグレーションをリリースしました ほか これらのアップデートは「混乱した代理問題(Confused deputy problem)」に対応するものです。 僕が AWS インテグレーションの設定をしている際にふと 「この機能、攻撃に利用できるのでは？」 と思いついてしまったので、 Mackerel サポ
こんにちは、サービス基盤のkumashunです。 freeeでは、ほとんどのサービスがAWSをインフラ基盤として利用しています。さまざまな目的や業務上の要件に応じて、複数のAWSアカウントを運用しており、時折、異なるアカウント間でのネットワーク通信やリソースへのアクセス、つまりクロスアカウントアクセスが必要となります。ここでは、リソースベースポリシーをサポートしていないAWSリソースにおける、クロスアカウントアクセスの実現方法についてご紹介します。 事例を "リソースベースポリシーをサポートしないAWSリソース" に限定しているのは、以下の背景からです。簡単に用語を説明します。 IAM Policy AWSリソースへのアクセス定義 誰がどのリソースに何をできる/できないかをJSON形式で定義できる IAM Role 1つ以上のIAM Policyをまとめたもの 人間がマネジメントコンソール
オンプレミス想定のActive DirectoryにVPN接続して、AD Connectorを作成、AWS SSOのIDソースにしました。 関連ブログ AWSクイックスタートのActive Directory Domain Services on AWS オンプレミスに見立てたオハイオリージョンにVyOSインスタンスを起動して東京リージョンからVPN接続 AD Connectorを作成してシームレスにドメイン参加する AD Connector作成が初回失敗して再実行 オンプレミス想定のActive Directory側のEC2のセキュリティグループで、AD Connectorを設置するサブネットのIPアドレスに53,88, 389 TCP/UDPポートを許可していなかったため、作成失敗しました。 オンプレミス想定のActive Directory側のEC2のセキュリティグループに上記を追加
こんにちは、AWS 事業本部の平木です！ AWS における PCIDSS v3.2.1を見た時に要件 8 を参照するとアカウントロックに関する要件があります。 現状、執筆時点では IAM ユーザーで連続してログイン失敗してしまったとしてもアカウントをロックできる仕様はありません。 ただ、AWS 公式のコンプライアンスガイドを見ると以下のように記述されていました。 PCI DSS 審査の適用範囲内であると判断された IAM ユーザーには、8.1.6 および 8.1.7 のアカウントロックに関する要件を満たす追加の仕組みが必要です。お客様がこれを達成するには、AWS CloudTrail、Amazon DynamoDB、AWS Lambda、Amazon CloudWatch を組み合わせて連続したログイン失敗を追跡して、ログイン失敗がしきい値である 6 回連続で発生した場合に制限を強めた I
[アップデート]GuardDutyが盗まれたEC2のクレデンシャルが別AWSアカウントで利用されたことを検知できるようになったので実際に試してついでにDetectiveで調査してみた GuardDutyがEC2から搾取されたクレデンシャルを別AWSアカウントで利用しても検知してくれるようになりました。実際にインシデントが発生した場合の対処方法も合わせて解説しています。 こんにちは、臼田です。 みなさん、GuardDuty使ってますか？(挨拶 今日は素晴らしいアップデートが来ました。EC2から搾取されたクレデンシャルが別AWSアカウントで利用されたときにAmazon GuardDutyで検知することが出来るようになりました！ Amazon GuardDuty now detects EC2 instance credentials used from another AWS account
![[アップデート]GuardDutyが盗まれたEC2のクレデンシャルが別AWSアカウントで利用されたことを検知できるようになったので実際に試してついでにDetectiveで調査してみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/667f87d2f54fdeff2f01ae7c6408e45a44404f8e/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-guard-duty.png)
こんにちは、上野です。 AWS Control TowerのLanding Zone 3.0がリリースされました。 変更内容が多いですが、ざっくりまとめると以下のとおりです。 組織レベルのAWS CloudTrail証跡が設定可能になった CloudTrailの設定をControl Towerからオプトアウト可能になった（オプトアウトした場合は独自で設定する必要あり） CloudTrailで各アカウントに出力されていたCloudWatch logsは、マネジメントアカウントに集約される CloudTrailアップデートに伴い、Control Towerが管理するIAMポリシーAWSControlTowerServiceRolePolicyの内容変更 AWS Config のグローバルリソースの記録がホームリージョンのみに変更 リージョン拒否ガードレールの変更（許可対象グローバルサービスの追
イベント Product Security Casual Talk vol.1 ジョブディスクリプション
BigQuery データセットへのアクセス権付与の特徴 BigQuery データセットへのアクセス権付与は、特定のユーザーやグループに対する直接的なアクセス管理を可能にします。これは小規模な共有には適していますが、大規模な組織や多くの外部パートナーとの共有では管理が煩雑になりがちです。特に、大規模なデータアクセスの場合、アクセス権の管理がセキュリティ上の課題となります。行レベルセキュリティと組み合わせるにしても、大量のアクセス権をデータセット単位で正しく設定するのには限界があります。 Analytics Hub と比べると以下のような特徴を持ちます。 BigQuery 全オブジェクトと機能、リージョンをサポート 新機能をすぐに使えるのが魅力 access 監査ログが残る BigQuery IAM で一貫性のある権限設定 Analytics Hub の特徴 Analytics Hub は以下
こんにちは、株式会社スマートラウンドSREの@shonansurvivorsです。 Terraform AWS Provider v4.33.0より、IAM Identity Center(AWS SSO)のグループとユーザーが作成できるようになりました！ 当社は以前からIAM Identity Centerを利用しており、これまではマネジメントコンソールによる管理だったのですが、今回早速Terraform化しましたので、そこで得られた知見を元にしたサンプルコードを紹介します。 なお、Identity Centerの許可セット(IAMポリシー情報)などは以前からAWS Providerで対応済みですが、それらリソースは本記事のスコープ外となります。ご承知おきください。 環境 Terraform 1.1.7 AWS Provider 4.33.0 工夫したポイント 各ユーザーがどのグループに
こんにちは！コンサル部の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外のサービスに永続的なクレデンシャル
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 クレデンシャルを取得
コンバンハ、千葉（幸）です。 突然ですが問題です。 以下の条件があったとします。 同一の 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 ポリシーで IAM ユーザー作成時のプログラムによるアクセス用の IAM ユーザの作成は許可するが、AWS マネジメントコンソールへのアクセス用の IAM ユーザの作成を拒否するという設定は可能でしょうか。可能な場合は方法を教えてください。 IAM コンソールでは以下の設定箇所に該当します。 どう対応すればいいの？ プログラムによるアクセスを許可し、AWS マネジメントコンソールへのアクセスを拒否する IAM ポリシーは設定可能です。 IAM コンソールのチェック項目は以下の API に該当します。 プログラムによるアクセス: CreateAccessKey AWS マネジメントコンソールへのアクセス: CreateLoginProfile 新規作成する IAM ユーザーの AWS マネジメントコンソールへのアクセスを判定するアクションはiam:CreateLogi
お疲れさまです。とーちです。 IAM に複数の MFA デバイスを割り当てる事ができるようになったというアナウンスを見たので試してみました。 かんたんまとめ AWS アカウントのルートユーザーや IAM ユーザーに最大８つの MFA を割り当てられる ログインするときには割り当てられた中のどれか一つの MFA を使ってログイン さっそく試してみた 適当な IAM ユーザーを用意してどんな動きになるのかを確認してみました。 まずは MFA の設定をします。MFA の設定方法は従来と変わらず、AWS マネージメントコンソールの IAM 画面から登録をしていきます。 2022/11/17 追記： MFA の設定方法について従来と変わらずと記載しておりましたが、正確には従来と異なり MFA の名前をつける必要があります。 またこの名前については、AWS アカウント内で一意※１である必要 があり、例
この記事は 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 を使う際に、どのようにユーザー管理できるのか
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
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
本当はre:Inventかその周辺で発表されたアップデートについて書こうかなと思ったんですが、自分自身の時間の都合と、例によって某ブログに大量に情報があるので今回は見送りましたｗ zennに何か書こうと思って書くのも今回が初ですね。 さて、今回は個人的に以前から非常に気になってしまう使われ方が多いIAMの使い方について、あらためてネタにしようと思います。 どちらかというとAWSにそれほど詳しくない人向けのつもりです。 しれっと使ってますが、そもそもベストプラクティスって何？ という方はとりあえずこちらを ベストプラクティス (best practice)とは あくまでもベストプラクティスなのでいきなり全部を満たすのは難しいかもしれませんが、こういうものがあるんだよ、というのを認知してもらえればと思います。 とりあえず真っ先に気を付けたほうがよいことや注意してほしいことは よく見るまずい（と
AWS OrganizationsのAWS IAM Identity Center(旧AWS Single Sign-On;AWS SSO)を利用すると、Organizations配下のAWSアカウントにSSOできます。 本記事では、同機能をAWS CLIから利用する方法を紹介します。 AWS IAM Identity Centerの詳細は次のブログを参照ください。 AWSアクセスポータルとIAMロールの2つのセッションの詳細は次のブログを参照ください。 なお、本記事ではAWS Identity Center directoryでユーザー管理しているものとします。 ポイント IAM Identity CenterにはAWS CLI v2が対応。v1は未対応 設定ファイルはAWS CLIだけでなくAWS SDK全般で流用可能 IAM Identity Centerはリージョナル・サービス I
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
こんにちは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 アクセスアドバイザーによる「アクションレベルでの最終実行履歴の表示」に EC2、IAM、Lambda が対応しました！ コンバンハ、千葉（幸）です。 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 リソース（ユーザー/グループ/ロール/ポリシー）に対して以下を分析、取得してくれる機能です。 アクセス
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
概要 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
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.
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
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2020」24日目の記事です。 遠い昔、はるか彼方の銀河系での話です。 TL;DR IAMの権限はしっかりやりましょう。検証環境と本番環境でアカウントを分けるとより安心できます。 何をやらかしたのか やらかし前の状態 マッチングサービスの開発をしています。そのサービスにはサービス内でメッセージが届くとその旨をEメールで通知する機能があります。 システム的にはサービスを動かしているWebアプリケーションからSQSのメール用のキュー（以後Maill Queue）にメッセージを送信し、メール送信用のWorkerがMaill Queueからメッセージを取得、差出人やURLなどの情報を埋めてEメールを送信します。差出人やURLは本番環境、検証環境でそれぞれ別の値が入ります。 また検証環境と本番環境は同一のAWSアカウント内にあ
概要 仕事をしていると、歴史のあるシェルスクリプトがEC2で動いていたりすることがある。 そういったスクリプトをなにかしらのスクリプト言語で書き換えるのもやぶさかではないのだが、数が多いと諦めの気持ちが湧き出てくる。 そこで、シェルスクリプトのままでもLambdaにデプロイしてバッチ的に動かして、サクッと移行できたりしないかなという思いが出てきた。 そこで、Lambdaのデプロイツールにlambrollを検証してみることにした。 インストール 手元がMacOSなのでbrewでインストール。 $ brew install fujiwara/tap/lambroll $ lambroll versions 2023/01/18 23:14:53 [info] lambroll v0.14.1 with function.json 2023/01/18 23:14:53 [error] fail
こんにちは。 サービスGの金谷です。 これまでIAMの設定を自分でやることがあまりなく、スイッチロールで何が起きているのか全然理解できていなかったのでまとめようと思います。 まず大前提 AWSアカウント≠ IAMユーザー です。 当然といえば当然なのですが別物です。 ざっくり説明するとAWSアカウントの中にIAMユーザーがいるといった形で、AWSアカウント＝ルートユーザーのようなイメージです。 私個人の経験としてはプライベートでAWSを学び触り始めたばかりのときは IAMを何も設定せずに他のサービスを触ったりしていましたが、通常は使用するべきではないです。 ちゃんとIAMユーザーを作成してそちらで作業するようにしましょう。 スイッチロールとは 名前の通りIAMロールを切り替える機能です。 アカウントを跨いだロールの切り替えも可能です。（というかこちらをメインに使います） 上図ではスイッチ元
はじめに AWSを初めて学習して難しいと感じたIAMについて、自分なりの理解を書いてみました。 同じような初心者の方でも読みやすいように、なるべく平易な言葉で書くことを心掛けています。 対象者 これからAWSを学習したい初心者 IAMって何なのか、なんとなく理解したい方 そもそも何のためにそんな機能があるの？という疑問を持っている方 IAMとは IAMとは、「Identity and Access Management」の略で、その名のとおり、IDとアクセス権を管理する機能です。IAMを使用すれば、誰がどのサービスにアクセスできるのかを、許可または拒否することができます。全ての人が全てのサービスやデータに対してアクセス権を持つというのは安全ではありません。必要な人に、必要最低限の権限のみを付与することが推奨されています。 そもそもなぜ管理機能が必要なの？ IT未経験の自分がAWSを勉強して
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
IAM ポリシー未設定の IAM ユーザーが生成した S3 署名付き URL (presigned URL) を使ってオブジェクトを Get できるのはなぜか コンバンハ、千葉（幸）です。 突然ですが以下のようなケースを考えてください。 IAM ポリシーがアタッチされていない IAM ユーザーが存在する 当該 IAM ユーザーが特定の S3 バケット内のオブジェクトに対する署名付き URL を生成する 生成された URL を用いて任意の利用者がオブジェクトを Get する 上記を実現したいと考えたときに必要となる設定が何か、皆さんは思いつくでしょうか。なお、 IAM ユーザーと S3 バケットは同一の AWS アカウントに存在するものとします。 「そもそも IAM ポリシーが無いのに署名付き URL を生成できるの？」という部分から引っかかる方もいるかと思いますが、実はできます。このエント
こんにちは！今回は、AWSのMFA（Multi-Factor Authentication）認証を使い、IAMロールにスイッチしながらS3バケットにアクセスするPythonスクリプトを紹介します。このスクリプトは、AWSのセキュリティベストプラクティスに従い、MFAを使用して一時的なセッションを取得し、S3バケットのリストを取得する方法を示しています。 さらに、1Passwordを活用してワンタイムパスワード（OTP）を自動的に取得する仕組みも組み込んでいるため、非常に便利で安全なアクセスが可能です。AWSのセキュリティを強化したい方や、MFA認証を自動化したい方に役立つ内容になっています。 背景 AWSでは、セキュリティを強化するためにMFAを使用することが推奨されています。MFAを使用すると、ユーザーは通常の認証情報（アクセスキーやシークレットキー）に加えて、ワンタイムパスワード（OT
コンバンハ、千葉（幸）です。 管理ポリシー、特に AWS 管理ポリシーの変更差分を確認したい機会がたまにあります。 マネジメントコンソール上で差分表示するような機能があれば便利なのですが、現時点では実装されていません。 ないなら AWS CLI でやってみるか、ということでエイリアスを組んでみました。 管理ポリシーの差分を表示するエイリアス 以下のエイリアスを設定しました。 [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-policy-version --polic
はじめに 大阪オフィスの川原です。 AWS Organizations の SCP(サービスコントロールポリシー)の継承 について、 仕組みを学びましょう。 前提知識 Organizations AWS Organizationsは マルチアカウントを統率するためのサービス です。 組織単位(OU) による アカウントのグループ化や、 サービスコントロールポリシー(SCP) によるグループ単位のサービス制限が可能です。 – 画像: AWS Organizations の用語と概念 | AWSドキュメント OUとは 組織単位(Organizational Unit: OU) は AWSアカウントのグループ化 を実現する要素です。 OU 配下に他OUをぶらさげる、ツリー構造を構築できます。 SCPとは サービスコントロールポリシー(SCP)は OUまたはアカウントに指定するポリシー です。 O
![[AWS Organizations] SCP(サービスコントロールポリシー)の継承の仕組みを学ぼう | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/d2c2cbb34cdcda62e4504734b6e345b95ceca145/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F04%2Faws-organizations.png)
G-gen の杉村です。Google Cloud (旧称 GCP) には組織 (Organization) という概念があります。ガバナンスとセキュリティのために重要なこの機能を解説します。 組織の基本 組織 (Organization) とは リソースの階層構造 組織リソース 組織 ID（顧客 ID） フォルダ・プロジェクト 組織のメリット・ユースケース 組織を使う理由 複数プロジェクト管理 利用可能なサービス・機能 組織を使わないリスク 組織の作成 Google Workspace (Cloud Identity) と Google Cloud 組織の作成方法 組織作成直後の特権 組織の表示 階層構造 (ツリー) の表示 表示に必要な権限 組織の管理 組織の管理者ロール 強力な管理権限 管理の委任 監査 組織と監査ログ（Cloud Audit Logs） 監査ログの収集 組織 (Res
AWS JSON ポリシーの要素: Principal - AWS Identity and Access Management
リソースベースの JSON ポリシーの Principal 要素を使用して、リソースへのアクセスを許可または拒否するプリンシパルを指定します。 リソースベースポリシー の Principal 要素を使用する必要があります。IAM など、いくつかのサービスが、リソースベースのポリシーをサポートしています。IAM リソースベースのポリシーのタイプは、ロールの信頼ポリシーです。IAM ロールでは、ロールの信頼ポリシー内の Principal 要素を使用して、だれがこのロールを引き受けることができるかを指定します。クロスアカウントアクセスとして、信頼されたアカウントの 12 桁の ID を指定する必要があります｡ 信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「IAM Access Analyzer とは」を
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[Tips] PyTorchにおける動的リンク](https://cdn-ak-scissors.b.st-hatena.com/image/square/409472b1b2f77f2a3b6890fd6db2fc966789eab9/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--_Uu_yUsy--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BTips%25255D%252520PyTorch%2525E3%252581%2525AB%2525E3%252581%25258A%2525E3%252581%252591%2525E3%252582%25258B%2525E5%25258B%252595%2525E7%25259A%252584%2525E3%252583%2525AA%2525E3%252583%2525B3%2525E3%252582%2525AF%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_34%3AKazuki%252520Fujii%252Cx_220%252Cy_108%2Fbo_3px_solid_rgb%3Ad6e3ed%252Cg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2VhNmQ4MDk1OGQuanBlZw%3D%3D%252Cr_20%252Cw_90%252Cx_92%252Cy_102%2Fco_rgb%3A6e7b85%252Cg_south_west%252Cl_text%3Anotosansjp-medium.otf_30%3ATech%252520Blog%252520-%252520Turing%252Cx_220%252Cy_160%2Fbo_4px_solid_white%252Cg_south_west%252Ch_50%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2NiYTAwZDNmYWIuanBlZw%3D%3D%252Cr_max%252Cw_50%252Cx_139%252Cy_84%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
Amazon S3のARNにある ::: ってなんだろう？と気になったはなし | DevelopersIO
![HDDの書き込み技術が20年ぶりに変わる。Seagateがいち早く製品化した「HAMR」技術とは ～BarraCudaやIronWolfなど、30TB時代の用途別の選び方も解説[Sponsored]](https://cdn-ak-scissors.b.st-hatena.com/image/square/72ffe67e99721b55b9c77f5650b29a41d89c7915/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fpc.watch.impress.co.jp%2Fimg%2Fpcw%2Flist%2F2017%2F179%2F01.jpg)
