AWS IAM セキュア化の取り組み
鍵がいっぱいあるよこの記事は Eureka Advent Calendar 2021 の 13日目の記事です。 はじめにこんにちは、エウレカ SREチーム のハラダです！ 2020年頃から今年にかけて、 エウレカのSREチームとSecurityチームではAWS IAMのセキュア化を注力ポイントのひとつとして、継続的に取り組んできました。 本記事では、その実践から学んできたIAM管理で守るべき大原則および、具体的にどうやってセキュアな理想像に近づけてきたか、今後の方向性などを話したいと思います。 Why “IAM” so important ?そもそもなんでIAMが注力ポイントなの？と疑問に思われる方もいるでしょう。 クラウドの大きな強みである「すべてをAPI経由で操作できる」という性質ゆえに、IAMは大きなAttack Surfaceでもあります。 Gartner社の予測によると、2023
IAM 評価論理ファン必見！AWS ドキュメントにリソースベースポリシー評価論理のプリンシパルごとの違いが記載されました | DevelopersIO
IAM の評価論理、完全に理解した。 コンバンハ、IAM 評価論理おじさん（幸）です。 私としたことがしばらく気づいていなかったのですが、2021年10月5日に IAM の AWS ドキュメントで激アツな更新がされていました。 Document history for IAM - AWS Identity and Access Management （機械翻訳）リソースベースのポリシーや同一アカウント内の異なるプリンシパルタイプの影響についての情報を追加しました。 これまで、同一アカウントの IAM 評価論理でリソースベースポリシーによる Allow が最終的にどのような評価をもたらすか、「プリンシパルごとに異なる動作をする場合がある」という記載がされていました。 え……その詳細が分からないと困るのでは……という状態でしたが、ついにプリンシパルごとの挙動の違いが記載されました。 「プリンシ
GitHub ActionsでAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利用できるようになったようです | DevelopersIO
GitHub ActionsでAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利用できるようになったようです アクセスキー、撲滅してますか？ ナカヤマです。 目黒方面より、以下のような福音が聞こえてきました。 何がどのくらい最高かと言いますと！ GitHub Actions に AWS クレデンシャルを直接渡さずに IAM ロールが使えるようになることがまず最高で！ クレデンシャル直渡しを回避するためだけの Self-hosted runner が必要なくなるところも最高です！！✨✨✨ https://t.co/IUQmfzkIB0 — Tori Hara (@toricls) September 15, 2021 元ネタはこちら。 Ok I blogged about it. That's how excited I am. 1. Deploy this CFN templ
クライアントサイドモニタリングで IAM ポリシーを作成する iamlive
iamlive はクライアント側での AWS API 呼び出しを監視して、 IAM ポリシーを作成してくれるツール https://github.com/iann0036/iamlive の README から引用 セットアップ cd /tmp curl --location https://github.com/iann0036/iamlive/releases/download/v0.10/iamlive-v0.10-darwin-amd64.tar.gz --remote-name tar xzvf iamlive-v0.10-darwin-amd64.tar.gz ./iamlive --set-ini # iamlive を起動しているのとは別のターミナルから AWS CLI で `aws sts get-caller-identity` などを実行し、 IAM ポリシーが表示さ
IAM Access AnalyzerのPolicy生成機能を使ってみた - LayerX エンジニアブログ
CTO室の@ken5scal (鈴木）です。 2021/04/08にAWS IAM Access Analyzerの新機能として、CloudTrailのログをもとにIAM Roleのポリシーを生成するリリースが発表されました。 ところで、やはりというべきか、さすがというべきか、すでにクラスメソッドさんからブログがリリースされています。 dev.classmethod.jp しかしながら、statementの単位でｳﾝｳﾝ唸ったり、下手なポリシーをつけて撃ち抜いた足の数など数え切れない一介のIAMマンとしては、歓喜をもってこのリリースを迎えざるを得ません。その昂りは、ブログネタ被りの羞恥心など容易に吹き飛ばすほどのものです。というわけで、早速、今回のリリースについて書いていこうとおもいます。 IAM運用のつらみ Identity is new perimeterといわれ、早10年弱。セキュリ
IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR
【書評】IAMの管理・運用に関わる人なら必読！「AWS IAMのマニアックな話」レビュー | DevelopersIO
オペレーション部 江口です。 少し前の話になってしまいましたが、2019年9月に開かれた技術書典7で、「AWS IAMのマニアックな話」という書籍が頒布されました。私も参加して購入、読んでとても良い本だなあ、と思ったのですが、当ブログに書評は投稿していませんでした。 ところが最近、作者の佐々木拓郎氏のTwitterでこんなフリが。 ちなみにサンタさんのクリスマスプレゼントで、クラメソさんがIAMのマニアックな話の書評かいてくれないかなぁと期待しています — Takuro SASAKI＠技術書典-1日目 (@dkfj) December 18, 2019 これには答えざるを得ない。 ということで、この書籍を購入したクラメソ社員として不肖私がレビューさせていただきます。 最初に端的に感想を書いておくと、IAMについて知りたい技術者にとってはまさに必読と言えるでしょう。「マニアックな話」というタ
AWS構成図をCacooに自動で挿入する機能をリリースしました | Cacoo（カクー） ブログ
仕様やUI(画面)は現行バージョンと異なる可能性があります。 Cacooの最新版についてはこちらからご確認ください。 CacooでAWS構成図を作成されてるみなさまに朗報です！この度、AWSの構成図を自動でCacooに挿入する新機能をリリースしました。 本機能はAWSのアイコンを自動で配置するため、AWS構成図をより簡単に、よりスピーディに描画できます。 解決できる課題 一からステンシルをCacooに置く必要がなくなります 今回の機能で取得できるサービスは全てCacooのステンシルに対応した上で配置するので、そこから自由に各リソースを配置し直すことができます。 現在のAWSの状況を把握できるのに役立ちます CacooのUI上で視覚化できるので現在のAWSの状況を把握しやすくなります。 AWSの構成図をチームで共有しやすくなります Cacooでは複数人の編集、閲覧ができます。自動で作成を行う
AWS、何から勉強したらいい？に対する俺の答え - Qiita
このツイートがわりと好評だったので解説。 「AWS、何から勉強したらいい？」に対する俺が考えた回答がこれ。 pic.twitter.com/ouuP3P27Bu — 伊藤 祐策(パソコンの大先生) (@ito_yusaku) 2018年4月17日 これは誰向け？ メンテナー以上の領域を目指す人向け。 オペレータ ... システムの運用、監視、障害調査＆対応をする人 メンテナー ... システムの拡張、改善をする人 アーキテクト ... システムを１から設計、構築する人 解説 各科目の選定基準 必修科目 ... AWSを本番運用するにあたって絶対に避けては通れないサービス。 重要科目 ... 間違った設計をすると、あとから取り返しがつかないサービス。 選択科目 ... 学習量を削るために仕方なく必修から外したが、Webサービスを構築するにあたりほぼ必須となるサービス。 必修科目で押さえておく
Serverless Framework利用時のアカウント毎のIAM権限について考えてみた - Qiita
serverless frameworkを使って複数人で開発する場合のアカウント毎の権限について考えてみた。 やりたいこと 参画ユーザ毎にアカウントを発行 各アカウントでstage作成するための権限設定 開発者の入場、退場に合わせた柔軟な運用 前提条件 各アカウントとserverlessのステージ名を同一にしておく 開発環境やステージング環境の設定は既に終わっているものとする 参画ユーザ毎にアカウントを発行 IAMの管理についてはmiamで良いかなと思っていたが、greeさんで作られているsubiamを使うことにした。 Subiamを使いAWSのIAM管理をコードベースでおこなう 以降はこのツール前提での話を進めていきます。 各アカウントでstage作成するための権限設定 stage作成にはcloudformationの作成やapigatewayの操作等、必要な権限が多いため非常に悩んだが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - iann0036/iamlive: Generate an IAM policy from AWS, Azure, or Google Cloud (GCP) calls using client-side monitoring (CSM) or embedded proxy
ORNEW