IAMポリシーの管理画面で出てくる「AWS管理のジョブ機能」って何!?

マネジメントコンソールでIAMポリシーを確認している時に出てくる不思議な言葉について調べました。そもそもIAMポリシーとは何ぞやという部分も振り返ります。

#AWS IAM

#AWS

千葉幸宏（チバユキ）

2020.02.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンバンハ、千葉（幸）です。

マネジメントコンソールでIAMポリシーの画面を眺めていた時に、「今まで流していたけど、急に気になってくる言葉」があったので調べました。ついでにIAMポリシーのおさらいもしましょう。

先に結論

AWS管理のジョブ機能とは、「職務機能のAWS管理ポリシー」を指している
職務機能のAWS管理ポリシーとは、職務ごとに想定されるタスクにあわせて、必要な権限をカスタマイズされたAWS管理ポリシーである
全体的な位置付けとしては以下のイメージである

- アイデンティティベースのポリシー
   - 管理ポリシー
     - AWS管理ポリシー
         - 職務機能のAWS管理ポリシー #★ここ
         - それ以外のAWS管理ポリシー
     - カスタマー管理ポリシー
   - インラインポリシー
- リソースベースのポリシー

IAMポリシーでジョブ機能？

「ジョブ機能」。

ジョブと聞くと、JP1やバッチ処理の文脈におけるジョブを思い出します。「何でIAMポリシーの話してるのに、急にジョブの話してくるんですか!？」と思った瞬間がありました。

「Job function」。

英語に切り替えると、そんな言葉が出てきました。functionと聞くと、Lambdaファンクションを思い出します。やっぱりバッチ系の話？と思うなどしました。

「ジョブ機能」というよりは「職務上必要な権限」

「function」の訳としては「機能」「関数」を思い浮かべてしまうのですが、「職務」といった意味も持つようです。「job」と意味合いが被っている気がしますね。

https://ejje.weblio.jp/content/function

主な意味機能、働き、作用、目的、職務、職能、職分、役目、儀式、行事

「job function」というワードだと、「職務権限」という訳がヒットします。AWSのドキュメントにおいては、該当するポリシーは「職務機能の AWS 管理ポリシー」と表現されています。原文は「AWS Managed Policies for Job Functions」です。

「職務機能」は「職務」と何が違うのか理解が追いつきませんでしたが、「職務を果たすために（機能するために）必要な権限を付与するためのAWS管理ポリシー」と考えると、どことなく意味がわかる気がします。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_job-functions.html

職務機能のAWS管理ポリシーとは

ドキュメント上での説明は以下のようになっています。

職務機能の AWS 管理ポリシーは、IT 業界の一般的な職務機能と密接に連携するように設計されています。これらのポリシーを使用すると、特定の職務機能を持つ人によるタスクの実行に必要な権限を簡単に付与することができます。これらのポリシーは、多くのサービスの権限を一つのポリシーに統合しているため、権限が様々なポリシーに分散している場合に比べてより作業しやすくなっています。

ここで定義されている職務機能は以下の通りです。

管理者
Billing (料金)
データベース管理者
データサイエンティスト
開発者パワーユーザー
ネットワーク管理者
セキュリティ監査人
サポートユーザー
システム管理者
閲覧専用ユーザー

例えばネットワーク管理者であれば、「AWS ネットワークリソースの設定とメンテナンスを担当する」というユースケースが想定されており、そこにマッチしたポリシーが準備されています。

このポリシーでは、Auto Scaling、Amazon EC2、AWS Direct Connect、Route 53、Amazon CloudFront、Elastic Load Balancing、AWS Elastic Beanstalk、Amazon SNS、CloudWatch、CloudWatch Logs、Amazon S3、IAM、Amazon Virtual Private Cloud のネットワークリソースの作成とメンテナンスを行うアクセス許可を付与します。

逆の考え方をすると、一般的なAWS管理ポリシーでは、職務を想定した観点では分けられていないと言えます。「EC2に関してはすべての操作が可能」「RDSに関して参照可能」など、AWSサービスカットで分けられています。それが600以上準備されているので、必要となる権限の組み合わせなどを考慮するのはなかなか大変です。権限設定のハードルを下げるために、ある程度初めからユースケースに即したものとしてが導入されたのが職務機能のAWS管理ポリシーということだと理解しています。

IAMポリシーのおさらい

そもそもAWS管理ポリシーって何？という部分もあるので、根本的なところからおさらいしておきましょう。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html

アイデンティティベースのポリシー
- 管理ポリシー
  - AWS管理ポリシー
    - 職務機能のAWS管理ポリシー
    - それ以外のAWS管理ポリシー
  - カスタマー管理ポリシー
- インラインポリシー
リソースベースのポリシー

絵に描くとこのような感じです。

「職務機能のAWS管理ポリシー」は、全体におけるここに位置するのだな、と捉えると腹落ちしやすいかと思います。順番に分類の切り口を確認していきましょう。

アイデンティティベースかリソースベースか

ポリシーをアタッチする対象によって分類されます。前者はいわゆるIAMポリシーです。アイデンティティ（ユーザー、ロール、グループ）にアタッチすることができ、アタッチ先に「〇〇に対して〇〇できる/できない」の権限を与えます。

後者は、AWSリソースに対してアタッチするポリシーです。S3のバケットポリシー、IAMロールの信頼関係ポリシー、VPCエンドポイントのエンドポイントポリシーなどが該当します。アタッチ先のリソースに「□□が□□してくるのを許可する/拒否する」の権限を与えます。

例:ログ出力（ELB→S3）

例えばELBのログをS3バケットに出力したいとなった場合、ELBに「S3に対してオブジェクトをputできる」という権限を与えることはできません。ELBに紐づくIAMロールが存在せず、アイデンティティベースのポリシーが適用できないためです。よって、S3のバケットポリシーにおいて、「ELBがオブジェクトをputしてくるのを許可する」という定義をしてあげる必要があります。

例：ログ出力（RDS→CloudWatch Logs）

RDSのログをCloudWatch Logsに出力する場合は、RDSにIAMロールを適用することが可能なので（サービスリンクドロール）、そこで「CloudWatch Logsに対してログを出力できる」という権限を与えることができます。CloudWatch Logs側では、特にリソースベースポリシーを意識する必要はありません。（後述にて補足）

評価論理

〇〇できる/できないの評価は、アイデンティティベースとリソースベースのポリシーに限って考えれば、両者を総合して以下のようになります。

明示的な拒否が設定されていれば、必ず拒否
明示的な拒否がなされていない状態で明示的な許可がされていれば、許可
明示的な拒否も明示的な許可もされていない場合、拒否（暗黙的な拒否）

上記の例で言えば、以下の組み合わせで、最終的にログ出力が許可されていることになります。

ELB（拒否も許可も設定なし） : S3（明示的な許可）
RDS（明示的な許可） : CloudWatch Logs（拒否も許可も設定なし）

リソースベースのポリシーを使用できるサービス

すべてのAWSリソースにリソースベースのポリシーが用意されているわけではありません。以下ページの、「リソースベース」のポリシーが「あり」のもののみ対応しています。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

上記の表で確認するとCloudWatch Logsではリソースベースのポリシーが「あり」になっています。S3のバケットポリシーのようにロググループにポリシーを適用できるのかな？と考えてしまいますが、そうではあリません。CloudWatch Logsというサービスにおいては以下の３種のリソースタイプが存在しており、リソースベースのポリシーを適用できるのは「送信先」と言うリソースのみです。

ロググループ
- (arn:aws:logs:region:account-id:log-group:log_group_name)
ログストリーム
- (arn:aws:logs:region:account-id:log-group:log_group_name:log-stream:log-stream-name)
送信先
- (arn:aws:logs:region:account-id:destination:destination_name)

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/iam-access-control-overview-cwl.html

このようにサービス単位での分類では細かい部分まで把握できないので、リソースベースのポリシーの「あり/なし」を確認したら、各サービスのドキュメントで詳細を確認するようにしましょう。

管理ポリシーかインラインポリシーか

スタンドアロンか、アタッチ先への埋め込みかによって分類されます。前述のポリシーに当てはめてみると、以下の考え方になります。

アイデンティティベースポリシー：管理ポリシーかインラインポリシーかが選択可能
リソースベースポリシー：インラインポリシーのみ

リソースベースポリシーの場合、必ずインラインポリシーになります。例えばS3のバケットポリシーはS3バケットと１対１の関係であり、複数のバケットに同時にアタッチすることはできません。アタッチ先の対象リソースのパラメータの一つとして直接埋め込むことになり、ポリシー自体がARN（Amazon Resource Name）を持つことはありません。

アイデンティティベースポリシーの場合は、インラインポリシーだけでなく、管理ポリシーの選択も可能です。管理ポリシーはスタンドアロンなポリシーであり、独自のARNを持ち、複数のアイデンティティ（ユーザー、ロール、グループ）にアタッチ/デタッチすることができます。ポリシーの内容変更時には複数のアイデンティティに一括で適用できることや、ポリシーのバージョン管理とロールバックが可能である点にメリットがあります。

逆にインラインポリシーを選択するメリットとしては、特定のアイデンティティにのみ適用したいポリシーがあり、他とポリシーを共有することによって意図せぬ変更が発生することを避けたいケースが考えられます。両者の使い分けについての詳細は、以下をご覧ください。

管理ポリシーとインラインポリシー

Permissions policyかPermissions boundaryか

管理ポリシーをIAMエンティティにアタッチする場合、以下のいずれとしてアタッチするかを選択可能です。（目がチカチカするので以降カタカナで書きます。）

Permissions policyとしてアタッチ
Permissions boundaryとしてアタッチ

ここでIAMエンティティという概念に含まれるのはユーザーとロールのみで、グループは含まれません。IAMグループはあくまでIAMユーザーを論理的にグルーピングするためのリソースであり、「IAMグループが〇〇を実行する」という考え方ではないことを鑑みると理解しやすいでしょう。改めて整理すると、管理ポリシーをどの位置付けでアタッチできるかの候補としては、以下の「●」が付与されている五箇所になります。

アイデンティティ	Permissionsポリシー	Permissionsバウンダリー
IAMユーザー	●	●
IAMグループ	●	×
IAMロール	●	●

一般的には、「IAMポリシーをアタッチする」と言えばPermissionsポリシーのことを指します。Permissionsバウンダリーは未設定であるというケースが多いのではないでしょうか。Permissionsバウンダリーを設定した場合、Permissionsポリシーで与えられている権限とAND条件で評価が行われるようになります。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-eval-logicより

「両者で」「明示的に許可」されている状態でないと、IAMエンティティはアクションを実行するがことできません。「明示的な許可」と「何も設定しない（暗黙的な拒否）」の組み合わせの場合も、拒否になります。明示的な拒否がなくてもこの結果になってしまうため、アイデンティティベースとリソースベースでの評価の仕方と混同しないようにしましょう。

IAMに関する強い操作権限をPermissionsポリシーとして与える際に、予め決めた範囲から逸脱しないようにPermissionsバウンダリーを設定する、といったものがユースケースとして考えられます。

AWS管理ポリシーかカスタマー管理ポリシーか

管理ポリシーを管理する主体による分類です。前者はAWSがポリシーの内容をメンテするものであり、カスタマーが変更を加えることはできません。例えばAWS管理ポリシーの一つであるPowerUserAccessのバージョン履歴を確認すると、以下のようになっています。

過去に数回アップデートがかかっていることが確認できます。新しいAWSサービスの登場など、APIに変更があった際に内容が見直されています。出来合いのAWS管理ポリシーでは要件を満たさず、より細かく制御を行いたい、あるいはAWS側の変更によって意図せぬ権限が増えることを避けたい、といった場合には、カスタマー管理ポリシーを使用することになります。

職務機能のAWS管理ポリシーかそうでないか

冒頭で説明した通りです。AWS管理ポリシーのうち、ユースケースを想定してサービスカットに囚われない幅広い権限を用意したものが職務機能のAWS管理ポリシーです。改めてIAMポリシーのおさらいをすると、より理解が進んだのではないでしょうか。とにかくおすすめだぞ、という圧を感じます。

AWS 管理ポリシーの中でも特に有用なカテゴリーは、職務機能用に設計されているものです。これらのポリシーは、IT 業界でよく使用される職務機能に密接に連携しています。この目的は、これらの一般的な職務機能への権限付与を簡単にすることです。職務機能ポリシーを使用する重要な利点としては、新しいサービスとして AWS によってこれらの保守や更新が行われ、API オペレーションが導入されることが 1 つ挙げられます。