AWSを使うにあたりIAMのベストプラクティスをもう一度確認する
本当はre:Inventかその周辺で発表されたアップデートについて書こうかなと思ったんですが、自分自身の時間の都合と、例によって某ブログに大量に情報があるので今回は見送りましたｗ zennに何か書こうと思って書くのも今回が初ですね。 さて、今回は個人的に以前から非常に気になってしまう使われ方が多いIAMの使い方について、あらためてネタにしようと思います。 どちらかというとAWSにそれほど詳しくない人向けのつもりです。 しれっと使ってますが、そもそもベストプラクティスって何？ という方はとりあえずこちらを ベストプラクティス (best practice)とは あくまでもベストプラクティスなのでいきなり全部を満たすのは難しいかもしれませんが、こういうものがあるんだよ、というのを認知してもらえればと思います。 とりあえず真っ先に気を付けたほうがよいことや注意してほしいことは よく見るまずい（と
【2022年版ベストプラクティス】AWS IAMまとめ - Qiita
はじめに AWSのアクセス制御サービスであるIAMについて、2022年7月時点での機能および使用法を、初学者でも理解しやすいことを心掛けてまとめました。 IAMをよく分からないまま適当に設定するとセキュリティ的にまずいので、これを機に設定を見直して頂き、セキュリティレベル向上に貢献できれば幸いです。 特に、後述するIAM設定手順は、AWSに登録して最初に実施すべき設定に相当するため、セキュリティに興味がなくとも一度は実施することをお勧めします。 また公式のベストプラクティスは丁寧にまとめたつもりなので、初学者以外でもAWSのセキュリティ確保に興味がある方は、ぜひご一読頂けると嬉しいです。 IAMとは 「Identity and Access Management」の略です。 公式ドキュメントによると、IAMは「誰」が「どのAWSのサービスやリソース」に「どのような条件」でアクセスできるかを
IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR
AWS IAM で障害が起こったらどうなるの？ AWS IAM のレジリエンス（復元力）に関する記述がドキュメントに追記されていた | DevelopersIO
コンバンハ、千葉（幸）です。 AWS サービスで広範囲の障害が起こったときにどう備えるか？は AWS を利用する上では避けて通れない課題です。 例えば Amazon EC2 であれば、アベイラビリティゾーン（AZ）単位での障害に備えてマルチ AZ 構成にしておく、リージョン単位の障害に備えて別リージョンにバックアップを退避させておく、などの構成が思いつきます。 では AWS IAM で障害が起こったときに備えてどうすべきか？改めて問われると難しい問題です。わたしはぼんやりと「そもそも障害が起こることはないんじゃないか？そもそも AWS IAM における障害って何？」という思いを抱いていました。 そんな折、いつものように AWS IAM のドキュメントの更新履歴を眺めていると IAM のレジリエンスに関する更新が行われていることに気がつきました。 Document history for I
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
