【2022年版ベストプラクティス】AWS IAMまとめ - Qiita
はじめに AWSのアクセス制御サービスであるIAMについて、2022年7月時点での機能および使用法を、初学者でも理解しやすいことを心掛けてまとめました。 IAMをよく分からないまま適当に設定するとセキュリティ的にまずいので、これを機に設定を見直して頂き、セキュリティレベル向上に貢献できれば幸いです。 特に、後述するIAM設定手順は、AWSに登録して最初に実施すべき設定に相当するため、セキュリティに興味がなくとも一度は実施することをお勧めします。 また公式のベストプラクティスは丁寧にまとめたつもりなので、初学者以外でもAWSのセキュリティ確保に興味がある方は、ぜひご一読頂けると嬉しいです。 IAMとは 「Identity and Access Management」の略です。 公式ドキュメントによると、IAMは「誰」が「どのAWSのサービスやリソース」に「どのような条件」でアクセスできるかを
最小権限実現への4ステップアプローチ 前編 | Amazon Web Services
Amazon Web Services ブログ 最小権限実現への4ステップアプローチ 前編 AWS のセキュリティベストプラクティスを実現するに当たり、「最小権限の原則」に戸惑ったことはありませんか？ AWS の利用では AWS Identity and Access Management （IAM）サービスを避けて通ることは出来ません。そのベストプラクティスとして掲げられているのが、最小権限の原則です。特に強固なセキュリティを求めるユースケースではこの原則の実現が課題になることが多いかと思います。本ブログでは、この最小権限の原則をシステマチックに検討するアプローチの一例をご紹介します。 はじめに 「最小権限を適切に運用する」ことを計画する際、まず思いつくのはシステムの運用や開発の視点で「必要」となる操作の権限のみを人やアプリケーションに付与するというアプローチです。シンプルですが、権限が
AWS IAMの属人的な管理からの脱却【DeNA TechCon 2021】/techcon2021-19
AWSをはじめとするクラウドプラットフォームの普及に伴い、DevとOpsの境目はかなり曖昧になっています。その中でもIAMの管理は設定によっては権限昇格を引き起こしかねないことから、その管理権限は慎重な管理になりがちです。結果的に、IAMは属人的な管理を行っている組織が多いのではないでしょうか。 …
IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR
AWS IAMの最小権限追求の旅 - プログラマでありたい
皆さん、IAM使ってますか〜？ 今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。 IAMでのセキュリティのベストプラクティス まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。 docs.aws.amazon.com AWS アカウントのルートユーザー アクセスキーをロックする 個々の IAM ユーザーの作成 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する 最小権限を付与する AWS 管理ポリシーを使用したアクセス許可の使用開始 インラインポリシーではなくカスタマー管理ポリシーを使用する アクセスレベルを使用して、IAM 権限を確認する ユーザーの強力なパスワードポリシーを設定
Terraform+Atlas+GitHubでAWSのIAMユーザのグループポリシーをいいかんじに管理する - クラウドワークス エンジニアブログ
はじめに クラウドワークスのインフラエンジニアの森田（@minamijoyo）です。 クラウドソーシングのクラウドワークスではサービスを提供するためのサーバ群をAWS(Amazon Web Services)で運用しています。 AWSではIAM(Identity and Access Management)という権限管理の仕組みを利用して、複数の担当者をグループで管理して必要な権限を割り当てることが可能です。 IAMはAWSを使う以上は避けては通れない機能ですが、すこぶる使い勝手が悪く、IAMポリシー編集とかやったことある人は分かると思いますがツライです。 何がツライかというと、 何も考えずに弱い権限のユーザとしてReadOnlyAccess権限とかだけ渡すと、自分のパスワード変更すらできない 個別に権限付与しようとすると権限の種類がいっぱいある上、サービス増える度に追加されるのにもかかわ
『新卒研修環境の構築をTerraformで自動化してみた』
アドテクスタジオのDynalystというチームで働いている黒崎 (@kuro_m88) です。 たまに社内で自作ドローンを飛ばしたりしています。 早いもので入社2年目になりました。つい先月まで新卒だったはずなのですが…(・・;) 今年も新卒の技術者が約60名入社し、新入社員全体の研修が終わり現在はエンジニアの技術研修が行われています。 今回はその環境構築で行ったことについて紹介しようと思います。 エンジニアの新卒研修の概要 今年の研修のゴールは「アーキテクチャをゼロから考え、実装できるようになる」というもので、研修課題は2つあります。 1つ目は現在まさに取り組んでもらっているのですが、2週間でミニブログシステムを3～4名のチームで制作してもらいます。 チームによってスキルセットが違うので、ネイティブアプリに特化するチームもいれば、バックエンドやインフラでいかにスケールしやすい構成にするか、
非エンジニアにこそ知ってほしいAWSのアカウント管理 ｜ Developers.IO
森永です。 今回は技術寄りの話ではなく、概念的な話です。 がっつりインフラエンジニアの方というよりは、情シスなどでAWSに関わるの非エンジニアの方向けに書いていきます。 AWSを利用する上ででてくる「アカウント」についてまとめてみました。 オンプレと何が違うの？、というお話をよく耳にしますので、オンプレとの対比を挟みながら説明していきます。 AWSで使用するアカウント AWSでは以下の3つのアカウントに大別されます。 OS（Linux/Windows）アカウント IAM AWSアカウント この中でさらに2つに大別でき、OSアカウントはOS以上のレイヤについて、IAMとAWSアカウントは物理やネットワークレイヤといったAWSで管理されるレイヤについて管理するアカウントになっています。 各アカウントについて、管理方針も含めてもう少し深くまとめていきます。 OSアカウント 特に説明はいらないかと
iPhoneでAmazonクラウド（AWS）管理コンソールのセキュリティを簡単に高める方法 - ヴェルク - IT起業の記録
よく「クラウドはセキュリティが・・・」なんて言われていますが 従来のデータセンタにサーバを置くことに比べて 現実的なセキュリティリスクというのは大差がないと思っています。 ただ、明らかに1つセキュリティ的に異なる箇所が1つあって それは管理画面のセキュリティです。 当然、管理画面はID・パスワードによる認証が必要ですが、 IP制限がかけられるわけではないため、 実際、それを理由に見送ったお客さまもいるくらいです。 そこでID・パスワードにプラスαしてセキュリティを高める方法があります。 Amazonクラウドはワンタイムトークン、 ニフティクラウドは乱数表による多要素認証が可能です。 普段Amazonクラウドを使っているので Amazonクラウドでの多要素認証の方法を紹介します。 ID・パスワードに加え、以下のようなハードウェアで生成される ワンタイムトークンを使って認証します。 このハード
【新機能】IAMユーザーをManagement Consoleからクロスアカウントで色々なRoleにスイッチする事ができるようになりました。 | DevelopersIO
【新機能】IAMユーザーをManagement Consoleからクロスアカウントで色々なRoleにスイッチする事ができるようになりました。 こんにちは、せーのです。今日はIAMにできたなかなか面白い機能をご紹介します。IAMで役割(Role)を予め作っておき、AWS Management ConsoleからIAMユーザーをそのRoleにスイッチさせることにより一つのユーザーで様々な役割でのアクセスが可能になる、というものです。 どういう時に使うの 普段IAMユーザーに役割を割り振る時にはその業務別で権限を分けているかと思います。例えばDeveloper(開発者)であれば開発環境には触れるけれども本番環境には触れない、運用担当であれば状態を見ることはできるけども変更することは出来ない、みたいな感じです。 でも一時的に権限を与えたい場合などがあるかと思います。本番環境にシステムをデプロイする
IAMによるAWS権限管理運用ベストプラクティス (2) | DevelopersIO
よく訓練されたアップル信者、都元です。前回（昨日）はAWSのクレデンシャルとプリンシパルを整理し、「開発運用スタッフ」が利用するクレデンシャルについてプラクティスを整理しました。今回はAWS上で稼働する「システム」が利用するクレデンシャルについてのプラクティスを整理しましょう。 システムが利用するクレデンシャル システムが利用するとはどういうことかといいますと、要するに「ユーザがアップロードしたファイルをS3に保存する」だとか「S3バケットに保存されたファイル一覧を取得して表示する」だとか、そういう操作をするシステムを作ることです。このようなシステムでは、APIキーを利用しますね。 AWSのAPIキーには、これもまた大きく分けて2種類があります。 long lived credentials （永続キー） short lived session credentials （一時キー） 皆さん
IAMによるAWS権限管理運用ベストプラクティス (1) | DevelopersIO
よく訓練されたアップル信者、都元です。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/credentials を唯一のAPIキー管理場所とすべし【大指針】 | DevelopersIO
よく訓練されたアップル信者、都元です。AWSを利用していると、APIキーの利用は必要不可欠です。数多くのAWSアカウントを扱っていれば、たまたまAPIキーは利用せず、管理コンソールへのパスワードだけで済んでしまうケースもあるかもしれませんが、これはごく例外的な状況です。しっかりとAWSを使いこなしている以上、APIキーを管理する機会が必ずあります。 鍵管理が大変 というわけで、皆さんは自分用のAPIキーを数多く管理しているわけですが、その管理は行き届いているでしょうか。少なくとも「失くしたｗｗｗ」なんていう事態は是非避けたいものです。大丈夫すか？ では、とあるキーがありましで、それが書き込まれている場所を全て挙げられますか？ あちこちのファイルに書き込んだりしていませんでしょうか。aws-cli用の設定ファイルはもちろん、環境変数設定用の~/.bash_profileの中、シェルのhist
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSでのセキュリティ運用 ～�IAM,VPCその他
IAM Recommended Practices