content[AWS]管理ポリシーとインラインポリシーの違いが分からなかったので改めてIAMポリシーのお勉強をするAWSIAM3年越しの加筆このqiitaの記事を書いたのは2017年ですが、その内容を取り込んで、2020年に以下の記事を書きました。[IAMポリシーの管理画面で出てくる「AWS管理のジョブ機能」って何?|クラスメソッドブログ]https://dev.classmethod.jp/cloud/aws/iam-job-function/併せてお読みいただけると、より理解が深まるかと思います。下記の一辺倒でしか闘ってきませんでした。IAMグループに「ポリシー」をアタッチするIAMグループにIAMユーザーを追加するポリシーの種類を深く考えることがなかったので、おさらいも兼ねて整理していきます。0.IDベースかリソースベースかいきなり少し脱線します。AWSにおけるアクセス権限を付与する方法は2種類あります。S3のバケットポリシー。policyやVPCエンドポイントポリシーが該当します。詳細は下記ページの[リソースベース]列がYesのものを参照してください。http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html今回はIAMポリシーの話なので、以降の記述はすべて1に該当します。1.IAMポリシーの適用先プリンシパルエンティティと呼ばれる下記3つに、IAMポリシーを適用することができます。「そのIAMグループに参加しているIAMユーザー」に継承されるというのがひとつのポイントです。「自身に適用されたポリシー」の両方の権限を持つことになります。そのポリシーも細分化されて...となっていきます。(これ以降、毎回”IAMユーザーやグループやロール..."というのはカッコ悪いので、すべて「プリンシパルエンティティ」と記載します。)2.IAMポリシーの種類まず、下記2種類に分かれます。管理ポリシーインラインポリシーそしてさらに前者が2種類に分かれます。管理ポリシーAWS管理ポリシーカスタマー管理ポリシーインラインポリシーそれぞれの違いを確認します。「ポリシー」単体として存在できて、複数のプリンシパルエンティティにつけたり外したりできる。「ポリシー」単体では存在できず、プリンシパルエンティティと1対1の関係にある。両者の使い分け基本的には、3管理ポリシーを使うことが推奨されているようです。各用途向けにさまざまなポリシーが用意されています。通常、インラインポリシーではなく、管理ポリシーを使用することをお勧めします。http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline1対多の関係でプリンシパルエンティティにアタッチできるポリシーの変更時にはアタッチ済みのプリンシパルエンティティすべてに反映されるポリシーの変更をバージョン管理できるこういったところが便利ですね。4インラインポリシーだとこうはいかず、プリンシパルエンティティごとに変更を加える必要があります。逆に、意図しない形でアクセス権の付与や変更が行われないようにしたい場合には、4を使用するのが良しとされているようです。AWSによって用意されている管理ポリシー。大まかに各AWSサービスごとにフル権限と読み取り権限が用意されている。利用者が独自に作成する管理ポリシー。ジェネレータで作成するか手書きで作成する。両者の使い分けこれはどこまで細かく権限を設定したいか、によって変わってくるかと思います。5AWS管理ポリシーは、あくまでざっくりと下記のような権限付与だけができます。EC2すべてに対して何でも操作可能S3バケットすべてに対して読み取りだけ可能それに対して6カスタマー管理ポリシーは、もう少しきめ細かい権限付与が可能です。特定のS3バケットに対してPUTのみ可能5と6を複数アタッチすることも可能(デフォルトで最大10まで)なので、セキュリティ要件によって適切にポリシーを設定しましょう。補足事項ポリシー一覧を見た時に、チェックボックスの隣にAWSのアイコンが表示されているのが5です。5は新サービスの開始などによって適宜内容が(AWSによって自動的に)修正され、「編集時刻」からアップデートされことを確認できます。3.ポリシーの評価論理ここまで見てきたようにポリシーには様々な種類があります。複数のポリシーを同一のプリンシパルエンティティにアタッチした場合、どういった風に権限が制御されるかを確認します。簡単に言えば、下記の通りになります。デフォルトでは拒否デフォルトの拒否より明示的な許可が強い明示的な許可より明示的な拒否が強いそしてこれは、IAMポリシーに限定した話ではありません。1のIDベース、2のリソースベース合わせての考え方となります。http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallowリクエストに適用可能なユーザーベースおよびリソースベースのポリシーすべてを、リソース、プリンシパル、アクション、および条件に基づいて評価します。実際の評価の流れを見ていきます。特定のAWSリソースに対してリクエストがなされた時に、12を含めて評価が行われ、許可もしくは拒否が決定されます。実例S3バケット「Backet」と、IAMユーザー「Batchi」で考えます。「Backet」内のオブジェクトを「Batchi」が参照したい場合。●両者ともポリシー設定なし→デフォルト拒否により参照できません。→明示的な許可により参照可能です。→明示的な拒否により参照できません。A"の場合に注意では次のケースではどうでしょうか。答えは、「参照可能」です。A"ですが、これは「明示的な拒否」ではなく「デフォルト拒否」として扱われます。よってIAMポリシーによる「明示的な許可」によって評価は「許可」になります。ここのあたりは要注意ですね。ドキュメントでは分かりやすいような分かりにくいような例が載っています。http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#AccessPolicyLanguage_InterplayおわりにというわけでIAMポリシーの話でした。IAMポリシーの話のはずでしたが、リソースベースのポリシーの話も含まれてきました。明示的な拒否と許可を意識して付与していったほうが良さそうですね。インラインポリシーと管理ポリシーは、基本的に管理ポリシーを使う。完全に「要件によりけり」ですが、個人的には、IAMユーザーにはAWS管理ポリシー多少広めに権限付与IAMロールにはカスタマー管理ポリシーでギッチギチの権限付与というのを見かける機会が多いかなと感じています。今回書いたようなことがみっちり書いてあって少し凹みました。http://qiita.com/ryo0301/items/791c0a666feeea0a704c以上です。requestStockLike47@Batchiヒヨコに足が生えたくらいのエンジニアです。upLoginユーザーは見つかりませんでした。