日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR
AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!
はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、本稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基本方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント（ルートユーザー）の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ
AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 【はじめに】 昨今､アクセスキーの漏洩を契機とした不正利用の発生が多発しております｡AWS 利用のお客様へのビジネスリスクが非常に大きく､弊社としても憂慮する状況です｡ そのため､以下をお読み頂き AWS 利用のお客様は環境の見直しをお願い致します｡ 【この記事で伝えたいこと】 多額の費用発生リスクをなくすために､可能な限りアクセスキーの利用を
![[AWS利用者必読] アクセスキー漏洩による不正利用について | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/3a9299c22c271be79f273b6db38d8ba6bc81bd1c/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F05%2F8823428add162ea6925215296ff8c67f.png)
「AWSセキュリティを「日本語で」学習していくための良いコンテンツをまとめてみた」というタイトルでAWS Summit Japan 2024のCommunity Stageで登壇しました #AWSSummit | DevelopersIO
AWS Summit JapanのCommunity Stageで登壇した「AWSセキュリティを「日本語で」学習していくための良いコンテンツをまとめてみた」の解説です。 こんにちは、臼田です。 みなさん、AWSセキュリティの勉強してますか？(挨拶 今回はAWS Summit JapanのCommunity Stageで登壇した内容の解説です。 資料 解説 AWSとセキュリティの勉強をしていく時、嬉しいことにAWS関連の情報はたくさんあります。しかし、どの情報から勉強していくか迷いますよね？そこで、AWS Security Heroである私がオススメする「日本語で」学習するための良いAWSセキュリティのコンテンツたちを紹介します。 紹介するコンテンツは、最近実施しているAWSセキュリティ初心者がステップアップしていくことを目的としたmini Security-JAWSにてまとめたmini S
こんにちは、2019年7月よりトレタにJOINした @aibou です。 本記事はトレタ Advent Calendar 2019の16日目の記事です。 趣味はNFL観戦とボルダリングです。NFLは今年11月にマイナス気温の屋外で現地観戦してきました。 最近リードクライミングの講習を受けまして、ガシガシと岩を登っております。 さて、今回はAWSアカウントとAWS SSOのお話をしようと思います。 既に社内エンジニアへの共有や社内WikiにAWS SSOの利用マニュアルを残していますが、経緯や変遷について記載していないので、トレタ社員の方にも読み物として読んでいただければなと思っています。 免責事項 本記事を参考に実施したことで発生した金銭・セキュリティ等あらゆる問題について責任を負いかねますので、自己責任のもと実施していただくよう、よろしくお願いいたします。 また、誤り等あればはてブ等でご
AWS初心者にIAM Policy/User/Roleについてざっくり説明する | DevelopersIO
こんにちは、CX事業本部の夏目です。 先日、AWS初心者にIAM Policy/User/Roleについてざっくり説明する機会があったので、説明した内容を共有します。 IAM Policy/User/Role 結論だけ簡潔に表現すると、次のようになる。 IAM Policyは できること/できないこと を定義し、UserやRoleに紐づけて使う IAM Userは、Policyを紐付けて、ユーザーができることを定義する IAM Roleは、Policyを紐付けて、誰か/AWSのサービス ができることを定義する Policyは できること/できないこと を定義し、UserやRoleに紐づけて使う IAM PolicyはAWSで何ができるかを定義するものです。 これ単体では何もできず、IAM UserやRoleに紐づけて使用します。 これはS3ReadOnlyAccessという、AWSが提供し
さて、皆様はIAMにどのようなイメージをお持ちでしょうか。プロジェクトに関わる複数人で1つのAWSアカウントを扱う時、各メンバーに配布するアカウントを作れる機能。そして、その気になればアカウントをグループ分けし、権限を厳密に管理できる機能。といったところかと思います。 上記のユースケースで出てきた主なエンティティ（要素）はUserとGroupですね。IAMのManagement Consoleで見てみると、IAMはこれらの他にRoleやIdentity Providerというエンティティによって構成されているようだ、ということがわかります。今日はRoleにフォーカスを当てて、その実態を詳しく理解します。 IAM Role IAM Roleを使うと、先に挙げたIAMのユースケースの他に、下記のようなことが出来るようになります。 IAM roles for EC2 instancesを使ってみ
セキュリティインシデントを止めるには IAM から。IAM の正しい使い方を一度覚えればセキュリティリスクは低減できます。AWS のドキュメント「IAM のベストプラクティス」をできるだけ具体的に解説してみましたのでご一読ください。 はじめに AWS を利用するにあたり、セキュリティをいかに確保するかが最優先事項となります。 今回は AWS を利用する際に一番最初に設定するであろう IAM で必要な設定について、AWS が推奨しているベストプラクティスに添って可能な限り分かり易く説明していきます。 IAM とは AWS の操作をより安全に行うため、AWS リソースへのアクセスを制御するためのサービスです。 IAM により、複数のユーザーに AWS リソースへの安全なアクセスを簡単に提供できます。 とある会社の場合 例として以下のような会社を定義します。 社長 x 1人 部長 x 2人（営業
AWSのフルマネージド型サービスを使ったソフトウェアの開発でローカル開発端末からアクセスキーの漏洩を防ぐためのテスト方法 | DevelopersIO
AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 本記事の想定読者 本記事ではフルマネージド型サービス=IAMを使ってアクセス制御を行うサービスと置き換えられます、これらを一切使わない開発(ALB, EC2, RDSのみなど)をしている方は対象外です 本記事はAWS上にソフトウェアを構築する開発者(主にバックエンドエンジニア)や開発環境を提供するプラットフォーマーを想定読者としています Typ
【書評】IAMの管理・運用に関わる人なら必読！「AWS IAMのマニアックな話」レビュー | DevelopersIO
オペレーション部 江口です。 少し前の話になってしまいましたが、2019年9月に開かれた技術書典7で、「AWS IAMのマニアックな話」という書籍が頒布されました。私も参加して購入、読んでとても良い本だなあ、と思ったのですが、当ブログに書評は投稿していませんでした。 ところが最近、作者の佐々木拓郎氏のTwitterでこんなフリが。 ちなみにサンタさんのクリスマスプレゼントで、クラメソさんがIAMのマニアックな話の書評かいてくれないかなぁと期待しています — Takuro SASAKI＠技術書典-1日目 (@dkfj) December 18, 2019 これには答えざるを得ない。 ということで、この書籍を購入したクラメソ社員として不肖私がレビューさせていただきます。 最初に端的に感想を書いておくと、IAMについて知りたい技術者にとってはまさに必読と言えるでしょう。「マニアックな話」というタ
よく訓練されたアップル信者、都元です。AWSにはIAMという権限管理のサービスがあります。AWSを専門としている我々にとっては当たり前の知識なのですが、皆さんはこの機能を上手く使えているでしょうか。 AWSにおけるクレデンシャルとプリンシパル まず、AWSにおけるクレデンシャルは大きく2種類 *1に分かれます。 Sign-In Credential：Management Consoleログインのためのクレデンシャル（要するにパスワード） Access Credentials：APIアクセスのためのクレデンシャル（要するにAPIキー） また、プリンシパル（ログインする主体、ユーザ名等）にも大きく2種類 *2があります。 AWSアカウント IAMユーザ これらの組み合わせとして「AWSアカウントのパスワード」「AWSアカウントのAPIキー」「IAMユーザのパスワード」「IAMユーザのAPIキー
先日行われました AWS JAPAN SUMMIT ONLINE 2020 にて、「大規模な組織変遷と100以上のAWSアカウントの横断的セキュリティガードレール運用について」のテーマにて、私たちのグループで取り組んでいる全ての AWS に対する横断的な取り組みを ビジョナル CTO 竹内 と ビジョナル CIO 園田 より発表させていただきました。 今回は、その発表内容について、発表の中で伝えきれていない内容などより詳細にお話しさせていただきます。 こんにちは、システム本部 プラットフォーム基盤推進室 ORE (Organizational Reliability Engineering) グループ の 長原 です。 私が在籍するグループでは、 Visional グループの全事業のクラウドや非機能要件等に対して、横断的にエンジニアリングによる課題解決に取り組んでいます。 複数事業・マルチ
週1回のサウナが習慣になったCI部1課の山﨑です。 今回はIAMポリシー設計のポイントを考えて整理してみました。 はじめに IAMポリシーの基本 IAMポリシーの要素 ポリシー例 IAMポリシー設計のポイント 5Wで要件を整理する Organizations SCP リソースベースのポリシー IAMユーザー IAMロール まとめ はじめに AWSにおいて認証・認可（権限の付与）を司るサービスと言えば IAM（Identity and Access Management）です。IAMではJSON形式でポリシーステートメントに具体的に許可したい操作、拒否したい操作を記述して認可（権限の付与）を行い、IAMユーザーやIAMロールに関連付けたりしてポリシーを適用します。今回は実際にポリシーを設計する際のポイントを考えて整理してみました。なおAWSが扱うポリシーはいくつかの種類と評価の優先順位がある
よく訓練されたアップル信者、都元です。AWSにおけるクレデンシャルには大きく「管理コンソールにログインするためのパスワード（Sign-In Credentials）」と「APIアクセスを行うためにAPIキー（Access Credentials）」の2種類があることをご紹介しました。そして、前者Sign-In Credentialsのセキュリティを強固なものにする手段として、MFAの活用についてもご紹介しました。 本当は怖いアクセスキー しかし実は本当に怖いのは、後者Access Credentialsのセキュリティです。アクセスキーはMFAによる保護に向いていません。設定を工夫すれば、「MFAによる認証を経なければアクセスキーを使えないようにする」ことも可能です。しかし、一般的には「プログラムが使う認証情報」であることが多いため、MFAの認証コードがなければAPIが叩けない、というのは受
日本のAWSのAPN Ambassadorが集まって作り上げるJapan APN Ambassador Advent Calendar 2020の初日です。佐々木の方からは、最近の関心事項であるマルチアカウント管理の中から、認証（ログイン）の一元化の設計について考えてみましょう。 マルチアカウント管理における認証（ログイン）の一元化の必要性 AWSを本格的に使い始めるとすぐに直面するのが、利用するAWSアカウントの増大です。AWSのお勧めのプラクティスの一つとして、用途ごとにAWSアカウントを使い分けてリスクを下げるというのがあります。本番環境と開発環境が同居しているより、分離した上で使えるユーザーを役割ごとに限定した方がリスクを下げることができますよね。一方で、プロジェクトごと・環境ごとにAWSアカウントを分離していくとすぐに10や20のアカウントになってしまいます。その時に第一の課題と
2020年2月29日の技術書典8に発表予定だったAWSのアカウントセキュリティ本こと、『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』の執筆が完了し、BOOTHで販売開始しました。 内容 書名のとおり、セキュリティがテーマです。そしてただのセキュリティを題材にすると、いろいろな方面からまさかりが飛んできそうなので、AWSのアカウントセキュリティと限定しています。で、アカウントセキュリティとはなんぞやという話ですが、前作ではAWSを扱う上での認証認可のサービスであるIAMをテーマにしていました。ここをしっかりしていると、ことAWSのアカウントまわりという点では６〜７割くらいはカバーできているのではと思っています。一方で、長く使っていると気が付かぬ穴や、複数人で使って誰かがやらかす人も出てくる可能性があります。この辺りを仕組みとしてカバーできるようにしようというのが、今回のアカ
皆さん、IAM使ってますか〜？ 今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。 IAMでのセキュリティのベストプラクティス まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。 docs.aws.amazon.com AWS アカウントのルートユーザー アクセスキーをロックする 個々の IAM ユーザーの作成 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する 最小権限を付与する AWS 管理ポリシーを使用したアクセス許可の使用開始 インラインポリシーではなくカスタマー管理ポリシーを使用する アクセスレベルを使用して、IAM 権限を確認する ユーザーの強力なパスワードポリシーを設定
AWSマルチアカウント事例祭りとは、AWSを活用する複数社が集まりお話しする祭典です。株式会社リクルートの須藤氏からは基盤の権限設定からコスト配賦、リアルタイム監視まで、マルチアカウント管理に必要なことについて共有されました。 クラウドの恩恵をプロダクトに届けることをミッションに 須藤悠氏（以下、須藤）：では『「進化し続けるインフラ」のためのマルチアカウント管理』について発表いたします。私、須藤と申しまして、好きなAWSのサービスはFargateとOrganizationsです。ただOrganizationsは使い倒すっていうほど使いこなせてはいない状況です。 HashiCorpのプロダクトが好きでして、TerraformとかTerraform Enterpriseがとても好きです。あと猫とかピザが好きで、猫とピザの、（着ているTシャツを指し）このおもしろTシャツを着てたりします。 所属は
マネコン起動もできるAWSのスイッチロール用CLIツール「AWSume」の紹介 | DevelopersIO
プロファイル指定したマネジメントコンソールの起動までできる、コマンドラインツールです。全AWSユーザーが求めていたのはこれなんじゃないでしょうか。どすこい。 「スイッチロールからの作業、AWSのベストプラクティスだけれどツールの設定がめんどくさいよね」 ハマコー、最近会社のパソコンをIntel MacからM1 Macに切替たことがきっかけで、いろんなツールを再度セットアップしてました。 普段AWS触っている身としてはスイッチロールして作業する環境も必須なので、改めて最新ツールを物色していたところ、弊社技術番長の岩田御大に教えてもらったAWSumeというツールが圧倒的に便利だったので、前のめりに紹介します。 標準公式のconfigとcredentialファイルのみで動作し、別途設定ファイルは不要 コマンドラインから、プロファイル名の自動補完に対応 指定したプロファイルから、マネジメントコンソ
よく訓練されたアップル信者、都元です。今日もIAMです。 先日のエントリで、プロジェクトメンバーにはIAMユーザを配布しましょう、というプラクティスを示しました。ではそのIAMユーザの権限はどの程度与えれば良いのでしょうか、というのが今日のテーマ。先に断っておきますと、このエントリーは結論が出ません。非常に難しいです。では、いきましょう。 AWSは「よくあるポリシー」としていくつかのテンプレートを提供してくれています。 Administrator Policy Read Only Access Policy Power User Policy ... 上記の他に、UI上で様々なポリシーテンプレートが利用できるようになっています。これらの権限をいくつか見ていきましょう。 プロジェクトメンバー全員にAdministratorAccess権限を与えると… AdministratorAccessと
年明けから IAM 周りの整理をいろいろしなければいけなくなったので、佐々木拓郎さんの「AWSの薄い本」シリーズ2冊を読みました。今回はその読書メモです。 booth.pm booth.pm AWS は普段から使っているので、IAM の基本的な機能はもちろん知っているのですが、最近追加された機能（特にマルチアカウント管理に関する機能）については全然追えてなかったので勉強になりました。 以下、勉強になった点をまとめたメモです。AWS の情報は日々変わっていってしまうので、発行日も併せて記載しました。 AWSの薄い本 IAMのマニアックな話（発行日：2019年9月22日） 第1章 AWSとIAM AWS Organizations は本書の対象外 ポリシー記述の文法的な部分は本書では扱わない。詳細は公式のIAM JSON ポリシーのリファレンス を参照 第2章 IAMの機能 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
それぞれのフェーズの詳細は以下のようになります。 当該アクセスキーを利用した不正な操作が行われる 流出したアクセスキーを利用し以下の操作が行われました。APIレベルの操作です。一連の操作はスクリプト化されているように見受けられます。 CreateAccessKey 流出したアクセスキーを利用し新規のアクセスキーを作成 DeleteAccessKey 流出したアクセスキーを削除 CreateUser IAMユーザーを作成（権限不足により失敗） CreateKeyPair 新規のアクセスキーを利用しキーペアを作成 RunInstances 全リージョンでインスタンスを起動 各リージョンで20のインスタンスが立ちあがる（起動上限はデフォルトのまま） m5.24xlargeなどインスタンスサイズが大きいものが優先される その後、起動したインスタンスにて仮想通貨Moneroのマイニングが行われました
よく訓練されたアップル信者、都元です。ブログのエントリみてればわかるとおもいますが、最近AWSのセキュリティに凝ってます。 AWSにおける権限管理について知識を深め、各所に適切な設定を行って行くのは大事なことです。これが基本です。しかし、自分が管理するAWSの各種リソースについて、何らかの意図しない変更があったことにすぐ気付ける体制は整っていますでしょうか？ 仮に、アクセスキーが悪意のある第三者に漏洩し、当人がその事実に気づいていないケースを考えます。悪意の第三者は、きたる攻撃のタイミングに備え、各所にバックドアを仕込もうとするでしょう。 こっそりとIAMユーザを増やしているかもしれません。 アクセスキーが1ユーザにつき2つ作れることをいいことに、自分用のキーを追加で作成しているかもしれません。 IAMロールに対するIAMポリシーを書き換えているかもしれません。 セキュリティグループにおけ
[待望のアプデ]EC2インスタンスメタデータサービスv2がリリースされてSSRF脆弱性等への攻撃に対するセキュリティが強化されました！ | DevelopersIO
[待望のアプデ]EC2インスタンスメタデータサービスv2がリリースされてSSRF脆弱性等への攻撃に対するセキュリティが強化されました！ EC2のメタデータサービスv2がリリースされました。これまでSSRF等の脆弱性と組み合わせることによりクレデンシャルの流出が多発していましたが、v2を利用することにより簡単にセキュリティを向上することができるようになりました。 こんにちは、臼田です。 皆さんセキュリティ対策してますか？(挨拶 今回はEC2インスタンスメタデータサービスv2がリリースされたのでこの機能について解説していきます。 Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata
![[待望のアプデ]EC2インスタンスメタデータサービスv2がリリースされてSSRF脆弱性等への攻撃に対するセキュリティが強化されました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/e03678dab7b09cb34c564b7250c4c7eac8677103/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-ec2.png)
クラウドの運用者に焦点を当てた、技術者向けの新しいテックイベント「Cloud Operator Days Tokyo 」。ここで株式会社カサレアルの新津氏が「これやったの誰？」をテーマに登壇。自動化したオペレーションに対して生じた疑問と学びについて紹介します。 自己紹介と今回のテーマ 新津佐内氏（以下、新津）：みなさん、こんにちは。株式会社カサレアルの新津佐内と言います。本日は「これやったの誰？」というタイトルのお話をします。 「これやったの誰？」についてですが、DevOpsと合わせて自動化を進めていく中で、自動化したオペレーションに対しても生じたこの疑問に、実業務の中であらためて向き合ってみました。上記事例の詳細と現時点での我々の答えを紹介します。 まず本日お話しする内容ですが、スライドに書かれているような基盤の運用担当者のユースケースに関わるお話になります。どのようなユースケースかとい
AWSを活用する複数社が集まり、事例を共有する祭典「AWSマルチアカウント事例祭り」。第2回の今回は、ニフティ株式会社の石川氏が自社へのAWS導入と管理方法について話しました。 ニフティがAWSをどう管理しているか 石川貴之氏（以下、石川）：「AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと」という題でお話しします。まずは自己紹介です。 ニフティ株式会社の基幹システムグループにいる石川貴之です。担当業務はAWS/GCPの管理、Atlassian製品の管理、Webサービスのバックエンドを担当しています。 少しだけ会社紹介もしたいと思います。ニフティ株式会社は@nifty光を始めとする、ネットワークサービス事業と、@niftyニュースのようなWebサービス事業。グループ会社で、不動産などの行動支援プラットフォーム事業を営んでおります。「ニフティなんだからニフク
はじめに こんにちは、川原です。 AWSのIAMサービスでは、各AWSサービスへの操作をアクセス制御するために「ポリシー」という概念があります。 AWSのドキュメントを読んでいると、ポリシーにはいくつか種類があることに気付くかと思います。本ブログではそれらのポリシーについて整理してみたいと思います。 ポリシーの基本 ポリシーは基本的に、「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述します。 記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現しています。 例えば、以下のJSONはAWS側で用意しているAmazonS3ReadOnlyAccessという名前のポリシーです(後述するユーザーベースポリシーのAWS管理ポリシーに該当)。
2021/8/17 に行われた AKIBA.AWS ONLINE #06 – AWS IAM 編 で 『ここが嬉しいABAC、ここが辛いよABAC』 というタイトルで登壇しました。 登壇資料を共有します。参考になれば幸いです。 資料 参考リンク 属性ベースのアクセス制御（ABAC）とは？ メリットと適切なアクセス制御モデル | Okta AWS の ABAC とは - AWS Identity and Access Management IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する - AWS Identity and Access Management IAM でのポリシーとアクセス許可 - AWS Identity and Access Management SaaSテナント分離をAWS IAMとABACで実装する方法 | Ama
渡辺です。 最近は、システムの開発支援としてAWS環境構築などに関わる事が多いです。 そこで、開発者側視点で押さえておきたいAWSのノウハウや基礎知識を書いて展開してみたいと思います。 今回はEC2で動くプログラムがアクセスキー/シークレットキーを使わずにRoleを利用すべき、という話です。 Roleとは？ RoleはIAMの機能のひとつで、アクセスキー/シークレットキーを使わずに各種AWSリソースにアクセスすることができます。 例えば、EC2インスタンスからS3にオブジェクトを書き込んだり、SNSにメッセージを送信したりする場合に利用できます。 アクセスキー/シークレットキーとの違い ひとことで言えば、Roleはアクセスキー/シークレットキーに比べ、キーの管理をする必要がありません。 ただし、EC2インスタンスにしか割り当てることしかできません。 キー管理が不要 アクセスキー/シークレッ
はじめに TL; DR; 社内の普段はインフラ以外のところを主戦場にしている人向けに、AWS・GCPの権限に関する用語と概念を説明するために書いたものを加筆訂正して公開します AWS・GCPの権限管理は、基本的な概念は似ているが同じ英単語が別の意味でつかわれているのでややこしい 書いてあること 概念の説明と、関係を表す図 EKS・GKEからクラウドリソース *1 を使う時の考え方 書いてないこと 設定のためのコンソール画面のスクショや手順 Kubernetesからクラウドリソースを操作する方法は、以前のブログ「GitHub Actionsで実現する、APIキー不要でGitOps-likeなインフラCI/CD」でTerraformによるコードの例も紹介しているので、あわせて参考にしてみてください 想定読者 AWSはそこそこ使って慣れているけど、GCPにおける権限管理を理解したい人(またはその
最小権限の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のリソースタイ
特定の IAM ロールのみアクセスできる S3 バケットを実装する際に検討したあれこれ | DevelopersIO
今回は S3 バケットへのアクセスを特定 IAM ロールからのみに限定して利用する機会がありましたので、設定方法と検討したあれこれをご紹介します。 やりたいこと 構成図はこんな感じ 前提条件 IAM ロールと S3 バケットは同一アカウントに存在する IAM ロールには S3 を管理する権限がアタッチされている 今回は AmazonS3FullAccess ポリシーをアタッチしています NotPrincipal でやってみる 「特定 IAM ロール以外は制限する」という考え方でパッと思いつくのは、以下のような NotPrincipal で制限する方法かと思います。 バケットポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "NotPrincipal": { "AWS": "arn:aws:iam::xxxx
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アプリケーションにおける権限設計の課題 - kenfdev’s blog
[AWS利用者必読] アクセスキー漏洩による不正利用について | DevelopersIO
入社後にAWSアカウントの整理とAWS SSOを導入した話 - トレタ開発者ブログ
IAMロール徹底理解 〜 AssumeRoleの正体 | DevelopersIO
AWS を安全に使うために（IAM のベストプラクティス） | DevelopersIO
IAMによるAWS権限管理運用ベストプラクティス (1) | DevelopersIO
100を超えるAWSアカウント運用におけるガードレール構築事例
【入門編】IAMポリシー設計のポイントを整理してみる - サーバーワークスエンジニアブログ
AWSアクセスキー・ローテーションのススメ | DevelopersIO
AWSのマルチアカウント管理ことはじめ ログインの一元化の設計 - プログラマでありたい
AWSのアカウントセキュリティ本を書きました #技術書典 - プログラマでありたい
AWS IAMの最小権限追求の旅 - プログラマでありたい
「進化し続けるインフラ」でありたい リクルートのAWS基盤チームによるマルチアカウント管理
IAMによるAWS権限管理 – プロジェクトメンバーへの権限付与方針に潜む闇 | DevelopersIO
AWSの薄い本シリーズ（IAMのマニアックな話など）の読書メモ - 無印吉澤
IAM Roleの仕組みを追う – なぜアクセスキーを明記する必要がないのか | DevelopersIO
【実録】アクセスキー流出、攻撃者のとった行動とその対策 | DevelopersIO
【AWSセキュリティ】簡易侵入検知のススメ | DevelopersIO
AssumeRoleとPassRoleでクレデンシャル情報を保持しない運用を AWSの自動化したオペレーションに対して生じた疑問「これやったの誰？」
利用者にAdmin権限委譲しても大丈夫 ニフティがAWS導入時から行ってきたマルチアカウント管理法
AWS IAMポリシーを理解する | DevelopersIO
AWSにおけるABACの嬉しさ、辛さを語りました #AKIBAAWS | DevelopersIO
プログラムではアクセスキー/シークレットキーを使わずにRoleを利用する | DevelopersIO
AWS・GCPとKubernetesの権限まわりの用語を具体例から理解する - JX通信社エンジニアブログ