福岡オフィスの梶原です。 先日、福岡オフィスでこんな会話がありました。 「スイッチロールしたいけどできないんですよね。」 「できるでしょ。」 「いや、正確にはユーザからはスイッチロールできるんですけど、スイッチロールしてからスイッチロールできなくて。」 「できないでしょ。スイッチロール元のユーザーで制限かかってるから」 「えー、そうなんですかー」 （わいがや) 「スイッチロール元を制限したいんですけど、それをロールにできないんですか？」 （わいがや) 「え、できた・・・CLIだけど」 ということで、調べたところこの動きは用語としては、ロールの連鎖(Role chaining)という動きみたいです。 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 クラウド利用が進んできています。 企業内での複数 AWS アカウント契約も珍しくありません。 新規に AWS をご利用されるお客様においても 複数アカウント前提で話をすることが多くなっているように感じます。 複数アカウントを契約した場合のアカウント構成を どう考えたらよいかを整理してみました。 複数アカウントの使い分け アカウントを分割する際の基準を考えてみます。 リソース制限 クラウドの利点は、リソースを使いたい時にすぐ使えることですが、 無制限にリソースを作成できるわけではありません。 例えば、S3 バケットの上限はアカウントあたり 1,000 バケットです。(執筆日時点) 大量のリソースが必要な場合はアカウントを分割します。 リソース制限が本番サービ
SREチームの @tmknom です。ジョジョ5部のアニメ化に興奮を隠せない今日このごろです。 みなさん、AWS Organizationsは使ってますか？ クラウドワークスでも最近使い始めました。AWS Organizations、超絶便利です。こんなに便利なのに、意外と公開されてる事例が少なくて、ぐぬぬってなります。というわけで、使い始めたばかりですが、サクッと公開してみます。他の会社さんも、公開してくれ！！ AWS Organizations マルチアカウント戦略 先行事例の調査 コンセプト策定 Terraform戦略 Terraformモジュールによる共通化 インフラテンプレート VPCのIPアドレス空間 メールアドレスの管理ポリシー OU（Organizational Unit）の責務 管理用AWSアカウントの責務 Masterアカウントによるアカウント管理 組織 OU（Orga
こんにちは、CI部技術5課の村上です。 今回はS3にあるオブジェクトを異なるアカウントと共有する方法part2です。前回の記事ではバケットのレプリケーションによって共有する方法を紹介しました。この記事では残り2つの方法を紹介します。 ↓前回の記事はこちらからご覧ください。 S3にあるオブジェクトを異なるアカウントと共有する3つの方法 part1 やりたいこと 前回の記事でも記載しましたが、やりたいことを図にすると、以下のような感じです。 前提として、アカウントAのIAMユーザーであるuser-aがS3にオブジェクトを保存しているとします。このオブジェクトをアカウントBのIAMユーザーであるuser-bが参照または取得する方法を3つ検証してみましたので、その方法を紹介します。 今回検証した3つの方法 バケットのレプリケーションで実現する（前回記事に掲載済み） バケットポリシーとIAMポリシー
はじめに AWSチームのすずきです。 IAM権限の分離や、請求情報の明確化を実現する手段として、AWSアカウントの分割を実施する事があります。 AWSアカウントとVPC、分ける？ 分けない？: 分割パターンのメリット・デメリット 統合認証基盤と連携したSSOなどを利用しない場合、ユーザ管理の煩雑化が問題となる事がありましたが、 複数のAWSアカウントで構成された環境のIAMユーザ管理と、その権限管理を ログイン専用のAWS環境を用意し、効率化する機会がありました。 その内容について紹介させて頂きます。 概要図 基本方針 当該環境のAWS、IAMの利用方針は以下としました。 開発、本番環境では、IAMはRoleの利用を原則とします。 IAMユーザはログイン環境のみに設置します。 Roleに対応しないツールに限り、例外としてIAMユーザ(アクセスキー)の設置を認めます。 全てのIAMユーザは定
サービスを開発する際に、社外の業者さんに開発をお願いしたり、社外パートナーに開発に参加してもらう、ということがよくあります。 開発に使うAWS環境として、うちの会社で作成したAWSアカウントに入ってきてもらうこともあるのですが、このときにAWSアカウントの管理者として社外の開発メンバーにどのような権限を持たせるのが良いか、それをどう実現するのが良いか、いつも悩みます。 このエントリでは現時点での考えと実装方法をまとめておこうと思います。 課題 私が関わる案件で社外の開発メンバーに協力を仰ぐ場合、大抵はPoCから始まるような新規サービスの構築案件となるためAWSのどのサービスを使うか最初からすべて決まっていることは稀です。 最初は ALB + EC2 + RDS で作り始めたシステムにDynamoDBが導入され、AWS IoT coreが導入され、Kinesis Stream が導入され、、
Amazon Web Services ブログ AWS アカウントのセキュリティを改善するための 10 個の項目 クラウド・セキュリティを向上させたいと考えているなら、AWS のチーフ・インフォメーション・セキュリティ・オフィサー (CISO) であるステファン・シュミットが AWS re:Invent 2019で発表したクラウド・セキュリティのための上位 10 個の項目 を参照してみてはいかがでしょうか？ 下記が項目のサマリーです。皆様の理解のために、順番に説明していきます。 1) アカウント情報を正しく保つ AWS が AWS アカウントについて連絡が必要な場合、AWS マネジメントコンソールで設定された連絡先の情報を利用します。これは、アカウントを作成する時に指定した E メールアドレス、代替の連絡先の中で指定されている E メールアドレスになります。全ての E メールアドレスは個人
はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、本稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基本方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント（ルートユーザー）の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ
オペレーション部 江口です。 少し前の話になってしまいましたが、2019年9月に開かれた技術書典7で、「AWS IAMのマニアックな話」という書籍が頒布されました。私も参加して購入、読んでとても良い本だなあ、と思ったのですが、当ブログに書評は投稿していませんでした。 ところが最近、作者の佐々木拓郎氏のTwitterでこんなフリが。 ちなみにサンタさんのクリスマスプレゼントで、クラメソさんがIAMのマニアックな話の書評かいてくれないかなぁと期待しています — Takuro SASAKI＠技術書典-1日目 (@dkfj) December 18, 2019 これには答えざるを得ない。 ということで、この書籍を購入したクラメソ社員として不肖私がレビューさせていただきます。 最初に端的に感想を書いておくと、IAMについて知りたい技術者にとってはまさに必読と言えるでしょう。「マニアックな話」というタ
はじめに こんにちは。望月です。 過去に本ブログで、IAM Roleの仕組みについて都元から解説がありました。 - IAMロール徹底理解 〜 AssumeRoleの正体 IAM Roleの仕組みについて非常にわかりやすく解説されていますので、ぜひ読んでみてください。今日はもう少し利用側の観点に立ったブログを書いてみようと思います。 IAM Roleってどうやって使われてるの IAM Roleを利用する目的は、「ソースコード内にAWSのAPIキーをハードコードすることなく、AWSのAPIを叩きたい」というものが殆どだと思います。ですが、なぜIAM Roleを利用すると、アクセスキーをソースコードで指定することなくAWSのAPIが利用可能になるのでしょうか。 今日はその仕組みについて知りたくなったので、AWS SDK for Rubyのソースコードから読み解いてみました。SDKのバージョンは1
Amazon EC2 インスタンスで実行されるアプリケーションはその AWS API リクエストに AWS 認証情報を含める必要があります。デベロッパーは Amazon EC2 インスタンス内に直接 AWS 認証情報を保存し、そのインスタンス内のアプリケーションに対してそれらの認証情報の使用を許可できます。しかし、デベロッパーは認証情報を管理し、その更新時には各インスタンスに安全に渡して、各 Amazon EC2 インスタンスを更新する必要があります。これは、かなりの追加作業です。 代わりに、IAM ロールを使用すると、Amazon EC2 インスタンスで実行されるアプリケーションに対して一時的な認証情報を管理するだけで済みます。ロールを使用する場合、長期認証情報 (サインイン認証情報、アクセスキーなど) を Amazon EC2 インスタンスに配布する必要はありません。代わりに、ロールは
分割の基準を2つに絞っても、9パターンもありました。各構成を1つずつ見ていきましょう。 1. 単一のAWSアカウントを使う この構成パターンは、一見単純です。しかし、すべてのシステムを1つのAWSアカウントの中に構築するため、アカウント内の環境はかなり複雑になります。 1-1. 単一のAWSアカウント、単一のVPC default VPC以外のVPCを1つ明示的に作り、その中に複数のシステム、複数の環境を混在させる構成です 1-2. システムの種類と環境の用途でVPCを分割 システムの種類でVPCを分け、さらに本番用と開発用など環境の用途によってもVPCを分ける構成です 1-3. システムの種類でVPCを分割 システムの種類によってVPCを分けますが、開発環境や本番環境を1つのVPC内に構築する構成です 1-4. 環境の用途でVPCを分割 環境の用途によってVPCを分けますが、複数の異なる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く