Findy/ファインディの技術ブログ

全231件

2026/11/04

権限は「誰に渡すか」ではなく「何をするか」で分ける〜AWS IAM Identity Centerの許可セットを5種類に揃えた話〜

こんにちは。 CTO室/Platform開発チームでSREを担当している富田( @Cooking_ENG )です。ファインディでは、プロダクトごとにAWSアカウントを分け、AWS IAM Identity Center（以降、Identity Center）で各AWSアカウントへのサインインと権限を管理しています。AWSアカウントが増えても、サインイン方法を意識する必要はありません。一方で、各AWSアカウントで何ができるかを決めるアクセス許可セットの中身は、SREまたはプロダクトチームがプロダクトごとに個別に書いていました。そのため、プロダクトが増えるたびに、同じようなポリシーを一から書く必要がありました。そこで今回、アクセス許可セットの分け方を見直し、「リソースの状態を見る」「リソースの設定を変更する」のように、AWSアカウントで何をするかで分けました。どのプロダクトでも同じ5種類の許可セットを使う形に揃えています。この記事では、Identity Centerで複数のAWSアカウントの権限を管理している方や、これから導入を考えている方に向けて、ファインディで権限をどう整理したかをIdentity Centerの基本とあわせて紹介します。 IAM Identity Centerで権限を渡す仕組み見直し前の許可セットの管理方法ポリシーの本文を書く量変更の確認範囲インラインポリシーの文字数上限権限を「そのAWSアカウントで何をするか」で分ける許可セットが5種類に落ち着くまで許可セットの中身を2種類のポリシーで組み立てるプロダクトチームが触るのは3つのファイルだけ固有ポリシーに書けないものはTerraformで気づけるようにする見直し前の3つの課題はどう解けたか旧グループと並行して使える移行期間を置くまとめ IAM Identity Centerで権限を渡す仕組み Identity Centerは、複数のAWSアカウントへのサインインと権限を1か所で管理するためのサービスです。ユーザーはアクセスポータルに1回サインインし、そこから使えるAWSアカウントと権限を選んで入ります。マネジメントコンソールだけでなく、AWS CLIからも同じ仕組みでサインインできるので、AWSアカウントごとにIAMユーザーを作る必要はありません。本題に入る前に、Identity Centerで権限がどう渡るのかを整理しておきます。登場するのは次の4つです。ユーザー（User） : サインインする人そのもの。各AWSアカウントに作るIAMユーザーとは別物で、Identity Center側に1つだけ作るグループ（Group） : ユーザーをまとめる単位。権限はユーザー個人ではなくグループに対して渡すアクセス許可セット（Permission set） : 「どのAWSサービスに対して何を許可するか」を定めたポリシーの組み合わせ。AWSアカウントに割り当てると、そのAWSアカウントの中にIAMロールとして展開される。以降、許可セットと表記アカウント割り当て（Account assignment） : 「このグループに、このAWSアカウントで、この許可セットを使わせる」という紐づけ許可セットの中身は、次の3種類のポリシーを組み合わせて作ります。 AWS管理ポリシー（AWS managed policy） : ReadOnlyAccess のようにAWSが用意しているもの。名前を指定するだけで使えるカスタマー管理ポリシー（Customer managed policy） : 自分で作るIAMポリシー。許可セット側にはポリシーの名前だけを書き、割り当て先のAWSアカウントに同じ名前のポリシーが置いてあることが前提になる。1つの許可セットに複数本を付けられるインラインポリシー（Inline policy） : 許可セットに直接JSONを書き込むもの。AWSアカウントごとにポリシーを用意しなくてよい代わりに、文字数制限がある都合、複雑なポリシーを定義するには向かない今回設計し直したのは、この「許可セットの中身をどう組み立て、誰がどこで管理するか」の部分です。以前はインラインポリシーだけで組み立てていましたが、新しい構成ではカスタマー管理ポリシーを中心に組み立て、AWSが用意している範囲で足りる権限にはAWS管理ポリシーを使っています。インラインポリシーは使用していません。見直し前の許可セットの管理方法ファインディでは、Identity Centerのグループや許可セットをTerraformで管理しています。見直し前のTerraformの構成では、1つのTerraform stateの直下に、グループ1つにつき次の6ファイルを並べていました。 sso/ ├── group__<グループ名>.tf ├── permission_set__<グループ名>.tf ├── inline_policy__<グループ名>.tf ├── membership__<グループ名>.tf ├── account_assignment__<グループ名>.tf └── files/ └── policy__<グループ名>.json.tpl ※構成の説明用にファイル名を簡略化しています。 Identity Centerのグループ名は product_a_stg_developer のように「プロダクト名・環境・渡す相手の立場」をつなげた形です。この6ファイルの組がグループの数だけ並び、ポリシーのテンプレートだけでも60本を超えていました。この構成は長く安定して動いていましたが、プロダクトが増えるにつれて、見直したい点が出てきました。ポリシーの本文を書く量新しいプロダクトを立ち上げるときは、SREまたはプロダクトチームが既存のテンプレートをコピーして書き足す形でポリシーを用意していました。1プロダクト分で数百行のポリシーを個別に書くことになります。権限の追加はプロダクトチームがPRを出し、SREがレビューする流れで回っていましたが、ポリシー本文が長いぶん、PRを出す側にもレビューする側にも時間がかかっていました。変更の確認範囲すべてのグループが1つのstateにまとまっているため、1プロダクトの権限を直すときも、全体のplan結果を見て確認する形になっていました。グループが増えるほどplanに時間がかかり、変更のたびに待つ時間が長くなっていました。インラインポリシーの文字数上限インラインポリシーには、空白を除いて10,240バイトまでという上限があります。既存プロダクトのポリシーが育っていくなかで、この上限にかかるケースが出てきました。インラインポリシーのままでは書き足せないため、許可セットの中身をどう組み立てるかから見直す必要があると考えました。権限を「そのAWSアカウントで何をするか」で分ける見直しにあたって最初に決めたのは、許可セットを何を基準に分けるか、という点です。以前は「developer」や「release」のように、渡す相手の立場で分けていました。立場を基準にした名前からは、グループに入っている人がAWSアカウントでどの操作を許されているのかが読み取れません。Secrets Managerの値の更新のように職種を問わず必要な操作もあり、立場では境界を引きにくいことが設計の中で分かってきました。今回は、「コンテナに入る」「Secrets Managerの値を読む」のように、AWSアカウントで何をするかで分けることにしました。何をするかで分ければ、プロダクトが違っても同じ種類の許可セットに同じ中身を使えるので、種類ごとのポリシーを1本にまとめて管理できます。許可セットの種類を表す名前には、対象のリソース名を含めていません。操作できる対象は、どのAWSアカウントに許可セットを割り当てるかで決まるからです。同じoperatorでも、AWSアカウントAに割り当てればAのリソースだけを、AWSアカウントBに割り当てればBのリソースだけを操作できます。操作するリソースごとに許可セットを分ける必要はないので、種類の名前が表すのは、コンテナに入る、設定を変更するといったAWSリソースへの操作だけです。 AWSアカウントで何をするかで名前を付けると、グループ名を見るだけで、そのグループの人が何をできるのかが分かるようになります。どのプロダクトでも同じ5種類の許可セットを使うので、新しいプロダクトが増えたときも、許可セットの中身を考え直さずに並べるだけで済みます。許可セットの種類は、最終的に次の5つになりました。許可セットの種類作業主にできること viewer リソースの状態を見るリソースの閲覧 operator コンテナに入る、調べる ECS Execでコンテナに入る、作業用ECSタスクの起動と停止、コンテナの起動に必要なSecrets Managerの値の参照 deploy_manager デプロイに伴う作業をする Secrets Managerの値の更新、KMSでの暗号化と復号、CloudFrontのキャッシュ削除 executor タスクやジョブを動かすバッチ処理のECSタスクの起動、Step Functionsの実行、Athenaのクエリ実行、Bedrockの呼び出し editor リソースの設定を変更する ECSやLambda、CloudFrontなど主要サービスの設定変更、RDSの再起動やスナップショット作成 ※ファインディでは、動いているコンテナの中を調べるときにECS Execを使っています。表の「コンテナに入る」はこの作業を指します。許可セットに含める権限には、2つの前提を置いています。 1つは、どの許可セットにも閲覧の権限を含めることです。まずリソースの状態を確認してから、変更や実行に移れるようにするためです。もう1つは、権限の範囲そのものを変える操作や、元に戻せない操作をどの許可セットにも入れないことです。IAMポリシーやロールの作成は権限の範囲を変え、KMSキーやRDSインスタンスの削除は元に戻せません。IAMの変更や、KMSキーとRDSインスタンスの作成・削除はTerraformで管理し、PRのレビューを経て適用する流れにしているため、Identity Centerの許可セットには含めていません。許可セットが5種類に落ち着くまで最初はviewer、operator、editorの3つで考えていました。「リソースの状態を見る」「コンテナに入る、調べる」「リソースの設定を変更する」の3段階です。実際の運用に当てはめてみると、うまく収まらない操作が出てきました。デプロイのあとにCloudFrontのキャッシュを消したい、バッチ処理のECSタスクを手で起動したい、といった操作です。コンテナに入って調べる操作ではないのでoperatorには入れられず、editorを渡すと設定変更までできてしまいます。そこで、3種類に当てはまらなかった操作を改めて見直すと、デプロイに伴う作業と、タスクやジョブの実行の2種類に整理できました。前者をdeploy_manager、後者をexecutorとして追加し、最終的に5種類に落ち着きました。許可セットの中身を2種類のポリシーで組み立てる許可セットを5種類に揃えたあと、中身をどう組み立てるかを考えました。今回は、許可セットの中身を2種類のポリシーで組み立てています。1つは、種類ごとに1本ずつ用意する共通ポリシーです。共通ポリシーは、SREが全AWSアカウントに配ります。もう1つは、プロダクトごとに必要な権限を書く固有ポリシーです。固有ポリシーは、プロダクトチームが用意します。共通ポリシーの実体はカスタマー管理ポリシーで、名前は common_operator のように種類の名前で揃えています。全AWSアカウントへは、CloudFormation StackSetで配っています。StackSetは、1つのCloudFormationテンプレートを複数のAWSアカウントにまとめて展開する仕組みです。カスタマー管理ポリシーを許可セットから使うには、割り当て先のすべてのAWSアカウントに同じ名前で置いておく必要があります。StackSetで配ると、どのAWSアカウントにも同じ中身が同じ名前で置かれるので、この条件を自然に満たせます。許可セットは、プロダクトと環境ごとに product_a_stg_operator のような名前で作っています。中身は、種類に対応する共通ポリシーを名前で参照しているだけです。プロダクト固有の権限が必要になったら、固有ポリシーとしてカスタマー管理ポリシーをもう1本作り、同じ許可セットに追加します。許可セットをプロダクトと環境ごとに分けているのは、プロダクト固有の権限を追加できる場所が許可セットに限られるためです。許可セットをAWSアカウントに割り当てると、サインイン後に使うIAMロールが AWSReservedSSO_ で始まる名前で作られます。作られたIAMロールは保護されていて、ポリシーを直接付けることはできません。固有の権限はプロダクトごとに違うので、固有の権限を入れる許可セットもプロダクトと環境ごとに分けています。プロダクトチームが触るのは3つのファイルだけ新しい構成では、プロダクトごとに次のようなディレクトリを置いています。 sso/product_a/stg/ ├── terraform.tf ├── providers.tf ├── data.tf ├── data__users.tf ├── groups.tf └── files/ ├── group_catalog.yml ← どの種類の許可セットを作るか ├── members.yml ← 許可セットごとの所属メンバー └── policy_custom__operator.json ← プロダクト固有の権限 .tf ファイルはどのプロダクトでも同じ内容です。プロダクトチームが触るのは files/ 配下の3つだけで済みます。 group_catalog.yml には、プロダクト名と環境、使いたい許可セットの種類を並べるだけです。種類を1つ書くと、グループと許可セット、所属、AWSアカウントへの割り当てがTerraformで一式作られます。新しいプロダクトを追加するときの作業を、見直し前と比べると次のようになります。見直し前見直し後誰が SREまたはプロダクトチームプロダクトチーム何をする既存プロダクトのテンプレートをコピーし、数百行のポリシーを書き足す group_catalog.yml に使いたい許可セットの種類を並べる固有の権限ポリシー本文に直接書き足す必要になったときだけ固有ポリシーを置く共通ポリシーはSREが全AWSアカウントに配り終えているので、プロダクトチームが新しく書くものは固有ポリシーに限られます。プロダクト固有の権限が必要なときは、 files/policy_custom__<種類>.json を置きます。中身は普通のIAMポリシーのJSONです。たとえば、Session Managerでインスタンスに入る権限をoperatorに足したい場合は、次のようなファイルになります。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": [ " ssm:StartSession ", " ssm:ResumeSession ", " ssm:TerminateSession " ] , " Resource ": " * " } ] } このファイルを置くと、Terraformが product_a_stg_operator_custom というカスタマー管理ポリシーを作り、operatorの許可セットに追加してくれます。共通ポリシーと固有ポリシーのどちらに書くかには目安があります。複数のプロダクトで使う権限は共通ポリシーに、特定のプロダクトだけで使う権限は固有ポリシーに書きます。固有ポリシーに書けないものはTerraformで気づけるようにする固有ポリシーはプロダクトチームが自由に書けるぶん、固有ポリシーに含めない権限を先に決めておきました。 iam:PassRole 以外のIAMの操作 RDSの削除、KMSの鍵の削除予約 RDSとKMSのアクションでのワイルドカード指定すべてを許可する * Resourceを絞らない iam:PassRole Allowの中の NotAction IAMの操作と、RDSやKMSの鍵の削除は、Terraformで管理している範囲なので、固有ポリシーには書きません。 iam:PassRole だけは、ECSタスクなどにIAMロールを渡すときに必要なので、Resourceを絞ることを条件に固有ポリシーに書けるようにしています。 RDSとKMSでは、 rds:Del* のようなワイルドカード指定も固有ポリシーに書けないようにしています。アクション名は文字列で照合しているので、ワイルドカードで書かれると、固有ポリシーに含めない権限が入っていても見つけられません。ワイルドカードを使わずアクション名を1つずつ書いてもらえば、文字列の照合のみで確かめられます。閲覧の権限は ReadOnlyAccess でどの許可セットも持っているので、固有ポリシーに書くのはRDSやKMSの書き込み系のアクションのみです。すべてを許可する * 、Resourceを絞らない iam:PassRole 、Allowの中の NotAction は、意図した以上に権限が広がる書き方なので、固有ポリシーの外に置いています。 IAMの操作やRDSの削除といった権限が固有ポリシーに含まれていないかは、レビューの前にTerraformの precondition で確かめています。 precondition はリソースに条件を書いておく仕組みで、条件を満たさないとplanの時点でエラーになります。次のコードは、検査のうちアクション名を照合する部分を抜粋したものです。 locals { forbidden_action_patterns = [ "^\\*$" , "^\\*:\\*$" , "^iam:" , "^rds:delete" , "^kms:schedulekeydeletion$" , "^(rds|kms):.*[*?]" , ] forbidden_actions = distinct ( [ for a in local.allow_actions : a if lower (a) != "iam:passrole" && anytrue ( [ for p in local.forbidden_action_patterns : can ( regex (p, lower (a))) ] ) ] ) } resource "aws_iam_policy" "this" { name = var.name policy = jsonencode (local.document) lifecycle { precondition { condition = length (local.forbidden_actions) == 0 error_message = "custom policy '$ { var.name } ' contains forbidden actions: $ { join ( ", " , local.forbidden_actions) } " } precondition { condition = length ( jsonencode (local.document)) <= 6144 error_message = "custom policy '$ { var.name } ' exceeds the IAM limit of 6,144 non-whitespace characters." } } } IAMのアクション名は大文字と小文字を区別しないので、小文字に揃えてから照合しています。カスタマー管理ポリシーには空白を除いて6,144文字までという上限があるので、サイズも同じ precondition で見ています。見直し前の3つの課題はどう解けたかポリシーの本文を書く量は、固有ポリシーの分だけになりました。共通ポリシーは、 common_operator のようなポリシー名を許可セットに書くだけで使えるので、プロダクトチームが数百行のポリシーを一から書く作業はなくなりました。変更の確認範囲は、プロダクトと環境ごとにディレクトリとTerraform stateを分けたことで、自分のプロダクトのグループに限られるようになりました。全グループを毎回読み込んでいたplanの時間も短くなりました。インラインポリシーの文字数上限は、1つの許可セットに複数のカスタマー管理ポリシーを付けられる仕組みで解消しました。共通ポリシーを外に出したぶん固有ポリシーも短くなり、1本あたり6,144文字の上限にかかりにくくなっています。共通ポリシーはSREが一括で管理し、IAMの操作などの権限が固有ポリシーに含まれていないかはTerraformが先に確かめるので、レビューでは差分の意図を見ることに集中できます。見直し前に比べて、確認する範囲が狭くなっています。旧グループと並行して使える移行期間を置く旧グループを残したまま新しい許可セットに対応するグループを作り、どちらの許可セットでもAWSアカウントにサインインできる移行期間を置いています。新しい許可セットで権限が足りなかった場合は、メンバーに旧グループで作業してもらい、足りなかった権限をプロダクトチームが固有ポリシーに追加しています。新しいグループへの移行が終わったAWSアカウントから順に、旧グループを消しています。まとめ今回は、AWS IAM Identity Centerの許可セットを、「誰に渡すか」ではなく「そのAWSアカウントで何をするか」を基準に5種類に揃え直した取り組みを紹介しました。見直しの成果は、プロダクトチームが用意するものが固有ポリシーだけになったことです。数百行のポリシーを一から書く作業はなくなり、SREがレビューで見る範囲も固有ポリシーに絞られました。どのプロダクトでも同じ種類の許可セットなら同じことができる状態になり、新しいプロダクトを追加するときも、全AWSアカウントに配られている共通ポリシーをそのまま使えます。今後は、固有ポリシーに同じ権限が複数のプロダクトで現れたときに共通ポリシーへ移す、という見直しを続けていきます。この記事が、IAM Identity Centerの権限設計に取り組む方の参考になれば嬉しいです。最後までお読みいただきありがとうございました！ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

Findy/ファインディ の技術ブログ

コンテンツ

Findy/ファインディの技術ブログ