Amazon S3のアクセスに必要な最低限のIAMポリシーの設定 - JPCYBER
Amazon S3のアクセスに必要な最低限のIAMポリシーの設定 2023年12月14日 サポート AWS Amazon S3 バケットにアクセスするために必要な最低限の IAM ポリシーの設定は、以下のように設定してください。（IAM ユーザー、または IAM ロールの設定で、既に「AmazonS3FullAccess」ポリシーをアタッチ済みの場合、本設定は必要ありません） バケット名（my-bucket）は適宜置き換えてください。 ■ 読み取り専用の必要最低限の IAM ポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "arn:aws:s3:::*" }, { "Effect": "Allow", "Actio
このアクション、いまのポリシー設定で実行できる？ IAM Policy Simulator でお手軽に確認しちゃおう | DevelopersIO
コンバンハ、千葉（幸）です。 IAM ポリシーを設計・設定したのちには、きちんと意図通りに動作するか確認したいものです。とはいえ、リソースに変更を加えるようなアクションはなかなかテストしづらいですよね。 テスト用のリソースを作ったり消したりして対応する場面も多いかと思いますが、それすら許容されないケースもあります。そんな時にあくまで机上での動作のシミュレートができるのが IAM Policy Simulator です。 使い方を確認していきましょう。 目次 目次 IAM Policy Simulator の全体像 IAM Policy Simulator へのアクセス方法 IAM Policy Simulator に必要な権限 IAM Policy Simulator のモード シミュレートするポリシーの設定方法 AWS Organizations SCPs IAM Policies、Pe
IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR
設定ファイルと認証情報ファイルの設定 - AWS Command Line Interface
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 設定ファイルと認証情報ファイルの設定 頻繁に利用される構成設定および認証情報を AWS CLIが維持するファイルに保存することができます。 ファイルは profiles に分割されます。デフォルトでは、 は という名前のプロファイルにある設定 AWS CLI を使用しますdefault。替わりの設定を使用するには、追加のプロファイルを作成して参照できます。 サポートされた環境変数のいずれかの設定を使用するか、あるいはコマンドラインパラメータを使用して、個別の設定を上書きすることもできます。構成設定の優先順位の詳細については、「の設定 AWS CLI」を参照してください。
ポリシーの評価論理 - AWS Identity and Access Management
プリンシパルが AWS Management Console、AWS API、または AWS CLI を使用しようとすると、プリンシパルは AWS にリクエストを送信します。AWS サービスが、リクエストを受け取ると、AWS は、いくつかのステップを実行してリクエストの許可または拒否を決定します。 認証 – AWS は、必要に応じて、最初にリクエストを行ったプリンシパルを認証します。このステップは、匿名ユーザーからの一部のリクエストを許可するいくつかのサービス (Amazon S3 など) では不要です。 リクエストコンテキストの処理 – AWS は、リクエスト内で収集した情報を処理し、リクエストに適用するポリシーを決定します。 単一アカウント内のポリシーを評価する – AWS は、すべてのポリシータイプを評価します。ポリシータイプは、ポリシーを評価する順序に影響を与えます。 アカウント内
IAM と連携する AWS のサービス - AWS Identity and Access Management
以下に一覧表示されている AWS のサービスは、アルファベット順にグループ化されています。また、サポートされる IAM の機能に関する情報を含んでいます。 サービス – サービスの名前を選択し、このサービスの IAM 認可とアクセスに関する AWS ドキュメントを表示できます。 アクション – ポリシーで個々のアクションを指定できます。サービスでこの機能がサポートされていない場合、[visual editor] (ビジュアルエディタ) で [All actions] (すべてのアクション) を選択します。JSON ポリシードキュメントでは、* 要素に Action を使用する必要があります。各サービスのアクションのリストについては、「AWS のサービスの アクション、リソース、および条件キー」を参照してください。 リソースレベルのアクセス許可 – ARN を使用してポリシーで個々のリソース
サーバーレスアプリケーションから Amazon Aurora への IAM ロールベース認証 | Amazon Web Services
Amazon Web Services ブログ サーバーレスアプリケーションから Amazon Aurora への IAM ロールベース認証 ユーザー名とパスワードをアプリケーションに直接保存することはベストプラクティスではありません。セキュリティで保護されたアプリケーションでは、資格情報をプレーンテキストとして保存しないでください。ソリューションとして、AWS Identity and Access Management (IAM) ポリシーは、Amazon Aurora リソースを管理できるユーザーを決定するアクセス許可を割り当てることができます。たとえば、IAM を使用して、DB クラスター、タグリソース、またはセキュリティグループを作成、記述、変更、削除できるユーザーを決定できます。Amazon Aurora では、データベースユーザーを IAM ユーザーとロールに関連付けるこ
AWS CLI で MFA 必須のアクセス制御を設定
AWS CLI を利用する場合は、通常はアクセスキーの設定が必要となります。(EC2 上でIAM ロールを割り当てる場合は除く） IAM ユーザ名/パスワードと違いアクセスキーはファイルなどに保存しておきますので漏洩のリスクが高くなります。そこでMFA 認証をしないとAWS CLI から各種AWS リソースにアクセスできないように設定する方法を記載します。 MFA 必須のIAM ポリシーの設定 まずは、以下のようなIAM ポリシーを設定します。MFA 認証をしていないとすべてのリクエストを拒否する設定となっています。 condition 内の記述ですが、”aws:MultiFactorAuthPresent” がMFA 認証されているかどうかを表していますが、MFA 認証をしていないとそもそもキーが存在しないため、”BoolIfExists” で存在チェックを入れています。 { "Vers
【実録】アクセスキー流出、攻撃者のとった行動とその対策 | DevelopersIO
それぞれのフェーズの詳細は以下のようになります。 当該アクセスキーを利用した不正な操作が行われる 流出したアクセスキーを利用し以下の操作が行われました。APIレベルの操作です。一連の操作はスクリプト化されているように見受けられます。 CreateAccessKey 流出したアクセスキーを利用し新規のアクセスキーを作成 DeleteAccessKey 流出したアクセスキーを削除 CreateUser IAMユーザーを作成（権限不足により失敗） CreateKeyPair 新規のアクセスキーを利用しキーペアを作成 RunInstances 全リージョンでインスタンスを起動 各リージョンで20のインスタンスが立ちあがる（起動上限はデフォルトのまま） m5.24xlargeなどインスタンスサイズが大きいものが優先される その後、起動したインスタンスにて仮想通貨Moneroのマイニングが行われました
[アップデート] 「最小権限の実装」が容易に！過去の CloudTrail イベントに基づいて IAM ポリシーを生成できるようになりました | DevelopersIO
コンバンハ、千葉（幸）です。 IAM Access Analyzer により、過去のアクティビティイベントに基づいて IAM ポリシーの生成ができるようになりました！ 「必要最小限の権限に絞る」というアプローチが取りやすくなりましたね。 激アツアップデートなので冗長構成で記事を書いています。（平たく言うと被った。）あわせてご参照ください。 何が嬉しいのか 「今はユーザーに広めの権限を与えているけど、必要な権限のみを与えるように絞っていきたいなぁ」 「必要な権限ってなんだろう。洗い出すのが難しいな」 「過去 30 日間で一通り必要な操作はしたから、それができれば十分だな」 「実際の操作を洗い出してそのままポリシーにしてくれたりしたらいいのに」 はい、それができるようになりました。 「最小権限の実装」は、 AWS を使用する上で遵守すべきベストプラクティスです。小さな権限から始めて徐々に必要な
IAMユーザ本人にMFAを管理してもらうためのIAMポリシー | DevelopersIO
はじめに こんにちは、虎塚です。 組織でAWSアカウントを利用する際には、担当者ごとにIAMユーザを払い出し、各ユーザが自分でMFA (Multi-Factor Authentication) を有効にすることが推奨されています。クラスメソッドでも、お客様の環境ごとにIAMユーザを作成し、MFAを設定していただくようにお願いしています。 ここで問題になるのが、IAMのポリシーです。IAMユーザ本人に自分自身のMFAを管理できるようにするには、どんなポリシーが適切なのでしょうか？ このテーマは、当ブログの過去記事でも何度か登場していますね。 一般のIAMユーザにMFAを設定してもらう方法 ｜ Developers.IO IAMによるAWS権限管理 – プロジェクトメンバーへの権限付与方針に潜む闇 ｜ Developers.IO 2015年8月現在、上記で紹介されたポリシーでは正常に動かなかっ
IAMによるAWS権限管理 – IAMポリシーの記述と評価論理 | DevelopersIO
よく訓練されたアップル信者、都元です。本日は、IAMユーザやロール等に与えられるポリシーについて。 IAMは、AWSの操作に関するIDと権限を管理するためのサービスです。IAMユーザ等を作ることにより、そのIDで「誰が操作を行うのか」というアイデンティティを管理し、ポリシーによって「その主体はその操作を行う権限があるのか」を管理します。 関連エンティティの整理 IAMの世界には、ユーザ・グループ・ポリシー等のエンティティが出てきますので、まずはその関係を整理しましょう。 左の方はそこそこ理解しやすいと思います。ユーザはグループに所属でき、多対多の関係があります。ロールについては別エントリIAMロール徹底理解 〜 AssumeRoleの正体を御覧ください。 各ユーザ・グループ・ロールには、複数の「ポリシー」と呼ばれるものを0個または複数個付与できます。ポリシーというのは1つのJSONドキュメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
