【2022年版ベストプラクティス】AWS IAMまとめ - Qiita
はじめに AWSのアクセス制御サービスであるIAMについて、2022年7月時点での機能および使用法を、初学者でも理解しやすいことを心掛けてまとめました。 IAMをよく分からないまま適当に設定するとセキュリティ的にまずいので、これを機に設定を見直して頂き、セキュリティレベル向上に貢献できれば幸いです。 特に、後述するIAM設定手順は、AWSに登録して最初に実施すべき設定に相当するため、セキュリティに興味がなくとも一度は実施することをお勧めします。 また公式のベストプラクティスは丁寧にまとめたつもりなので、初学者以外でもAWSのセキュリティ確保に興味がある方は、ぜひご一読頂けると嬉しいです。 IAMとは 「Identity and Access Management」の略です。 公式ドキュメントによると、IAMは「誰」が「どのAWSのサービスやリソース」に「どのような条件」でアクセスできるかを
AWSアカウント作成時にやるべきこと - NRIネットコムBlog
Amazon Web Services (以下AWS)の利用開始時にやるべき設定作業を解説します。AWSの利用開始とは、AWSアカウントの開設を意味しますが、より安全に利用するため、AWSアカウント開設直後にやるべき設定がいくつかあります。この連載ではその設定内容を説明します。 AWS Organizationsを使用することで、複数のアカウントに自動的にこういった初期設定を行うことも可能ですが、この連載では新規で1アカウントを作成した場合を前提とします。複数アカウントの場合も、基本的な考え方は同じになります。 設定作業は全１９個あり、作業内容の難しさや必要性に応じて以下３つに分類しています。 少なくともMUSTの作業については実施するようにしましょう。 MUST ：アカウント開設後に必ず実施すべき作業 SHOULD ：設定内容の検討または利用方法を決定のうえ、可能な限り実施すべき作業 B
AWSジョブ機能の 管理ポリシー - AWS Identity and Access Management
最小権限を付与するポリシーを使用するか、タスクの実行に必要な権限のみを付与することをお勧めします。最小限の権限を付与する最も安全な方法は、チームに必要な権限のみを使用してカスタムポリシーを作成することです。必要に応じて、チームがより多くの権限を要求できるようにプロセスを作成する必要があります。チームに必要な権限のみを提供する IAM カスタマーマネージドポリシーを作成するには時間と専門知識が必要です。 AWS マネージドポリシー を使用して、IAM ID (ユーザー、ユーザーのグループ、およびロール) へのアクセス許可の追加を開始。AWS 管理ポリシーは一般的な使用例をカバーし、AWS アカウント で利用できます。AWS 管理ポリシーは、最小特権のアクセス許可を付与しません。プリンシパルにジョブに必要な以上のアクセス許可を付与すると、セキュリティ上のリスクを考慮する必要があります。 ジョブ
【備忘録】CodeBuildで`aws ecr get-login`コマンド実行時にエラーが発生する - Qiita
問題点 CodeBuildでaws ecr get-loginコマンド実行時にエラーが発生する ビルド結果 buildspec.yml(抜粋) version: 0.2 phases: pre_build: commands: - # 省略 - $(aws ecr get-login --no-include-email --region ${AWS_DEFAULT_REGION}) - # 省略 [Container] 2018/08/23 06:59:56 Running command $(aws ecr get-login --no-include-email --region ${AWS_DEFAULT_REGION}) An error occurred (AccessDeniedException) when calling the GetAuthorizationToken
ざっくり絵で理解するAWSのIAM用語「ユーザ、グループ、ロール、ポリシー」 - Qiita
それなりにAWSを利用していますが、コード書きばかりに脳内リソースを割いておりアクセス権限などにあまり興味がいかない悪い癖があり困っています。 ４月ということで新人さんもいますし、自戒の念も込めたりしつつ、まずはざっくりと自分用に関係をまとめておこうかと思いました。 下の図を見るだけで、大体ざっくり理解できるように書いているつもりです。(本家のサイトは用語が多すぎて難しすぎるので…) もし間違いなどありましたらご指摘頂けると大変助かります。 IAMユーザ、グループ、ロール、ポリシー関係図 ポイント IAMユーザの認証方法には２種類があり、どちらかまたは両方を利用できる パスワード認証（Webコンソールから） アクセスキー＆シークレットキー認証（CLIやAPIから） AWSの認証機構として、IAMユーザ以外に「IAMロール」がある IAMロールはAWSサービスの実行リソース(例えばLambd
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が提供し
ポリシーの評価論理 - AWS Identity and Access Management
プリンシパルが AWS Management Console、AWS API、または AWS CLI を使用しようとすると、プリンシパルは AWS にリクエストを送信します。AWS サービスが、リクエストを受け取ると、AWS は、いくつかのステップを実行してリクエストの許可または拒否を決定します。 認証 – AWS は、必要に応じて、最初にリクエストを行ったプリンシパルを認証します。このステップは、匿名ユーザーからの一部のリクエストを許可するいくつかのサービス (Amazon S3 など) では不要です。 リクエストコンテキストの処理 – AWS は、リクエスト内で収集した情報を処理し、リクエストに適用するポリシーを決定します。 AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法 – AWS はすべてのポリシータイプを評価し、ポリシーの順序はそれ
【書評】IAMの管理・運用に関わる人なら必読！「AWS IAMのマニアックな話」レビュー | DevelopersIO
オペレーション部 江口です。 少し前の話になってしまいましたが、2019年9月に開かれた技術書典7で、「AWS IAMのマニアックな話」という書籍が頒布されました。私も参加して購入、読んでとても良い本だなあ、と思ったのですが、当ブログに書評は投稿していませんでした。 ところが最近、作者の佐々木拓郎氏のTwitterでこんなフリが。 ちなみにサンタさんのクリスマスプレゼントで、クラメソさんがIAMのマニアックな話の書評かいてくれないかなぁと期待しています — Takuro SASAKI＠技術書典-1日目 (@dkfj) December 18, 2019 これには答えざるを得ない。 ということで、この書籍を購入したクラメソ社員として不肖私がレビューさせていただきます。 最初に端的に感想を書いておくと、IAMについて知りたい技術者にとってはまさに必読と言えるでしょう。「マニアックな話」というタ
Amazon リソースネーム (ARN) で AWS リソースを識別する - AWS Identity and Access Management
Amazon リソースネーム (ARN) は、AWS リソースを一意に識別します。IAM ポリシー、Amazon Relational Database Service (Amazon RDS) タグ、API コールなど、すべての AWS 全体でリソースを明確に指定する必要がある場合は ARN が必要になります。ARN は、他の識別情報と同様に、慎重に使用および共有する必要がありますが、秘密情報、センシティブ情報、または機密情報とは見なされません。 ARN 形式 ARN の一般的な形式を次に示します。具体的な形式は、リソースによって異なります。ARN を使用するには、italicized のテキスト (arn 以外のすべて) をリソース固有の情報に置き換えます。一部のリソースの ARN では、リージョン、アカウント ID、または、リージョンとアカウント ID の両方が省略されていることに注
AWS IAMポリシーを理解する | DevelopersIO
はじめに こんにちは、川原です。 AWSのIAMサービスでは、各AWSサービスへの操作をアクセス制御するために「ポリシー」という概念があります。 AWSのドキュメントを読んでいると、ポリシーにはいくつか種類があることに気付くかと思います。本ブログではそれらのポリシーについて整理してみたいと思います。 ポリシーの基本 ポリシーは基本的に、「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述します。 記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現しています。 例えば、以下のJSONはAWS側で用意しているAmazonS3ReadOnlyAccessという名前のポリシーです(後述するユーザーベースポリシーのAWS管理ポリシーに該当)。
特定のS3のフォルダにのみアクセス権のあるIAMユーザーを使ってCyberduckから参照する | DevelopersIO
特定のS3のフォルダにしかアクセス権を与えたくない場合、 ポリシーを作成してIAMユーザーに付与し、そのユーザーからフォルダを参照しますが、 マネジメントコンソールから入るとトップページを表示する権限がないので以下のメッセージが表示され目的のフォルダにアクセスできません。 そのため今回は、S3のフォルダおよびそこにしかアクセス出来ないポリシーを作成し、そのポリシーを付与したIAMユーザーのクレンデンシャル情報を使ってCyberduckからアクセスする方法を紹介します。 手順 手順は以下になります。 フォルダの作成 ポリシーの作成 IAMユーザの作成 Cyberduckの設定 １．フォルダの作成 S3のコンソールから「バケットを作成」ボタンをクリックし、バケット名とリージョンを選択してバケットを作成します。 この時にバケット名の命名ルールに準じていないとバケットが作成出来ないので注意しましょ
[Amazon Redshift] RedshiftのIAM Roles利用が可能となりました。 ｜ DevelopersIO
はじめに AWSチームのすずきです。 先日のAWSのアップデートにより、Amazon Redshiftのインポート（COPY）、エクスポート（UNLOAD）先として利用する、 S3などのアクセス権限管理に、IAMロールを利用する事が可能になりました。 IAMロールを利用したCOPY操作を試す機会がありましたので、紹介します。 Amazon Redshift now supports using IAM roles with COPY and UNLOAD commands IAM設定 IAMロール作成 AWSコンソール、IAM（Identity & Access Management）を利用します。 ロールを指定し「新しいロールの作成」を行います。 任意のロール名を記入します。 新しく追加されたAWSサービスロール、「Amazon Redshift」を選択します。 ポリシーのアタッチにて、
![[Amazon Redshift] RedshiftのIAM Roles利用が可能となりました。 ｜ DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/977093929c7bae81ce8ef1fba07f72411d2c9ded/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_Redshift.png)
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キー
IAMロール徹底理解 〜 AssumeRoleの正体 | DevelopersIO
さて、皆様はIAMにどのようなイメージをお持ちでしょうか。プロジェクトに関わる複数人で1つのAWSアカウントを扱う時、各メンバーに配布するアカウントを作れる機能。そして、その気になればアカウントをグループ分けし、権限を厳密に管理できる機能。といったところかと思います。 上記のユースケースで出てきた主なエンティティ（要素）はUserとGroupですね。IAMのManagement Consoleで見てみると、IAMはこれらの他にRoleやIdentity Providerというエンティティによって構成されているようだ、ということがわかります。今日はRoleにフォーカスを当てて、その実態を詳しく理解します。 IAM Role IAM Roleを使うと、先に挙げたIAMのユースケースの他に、下記のようなことが出来るようになります。 IAM roles for EC2 instancesを使ってみ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
