1 © SMS Co., Ltd. 2025.5.26 株式会社エス・エム・エス 山口隆史 シンプルな設定ファイルで実現する AWS IAM Identity Center のユーザー管理と開発チームへの委譲 

2 © SMS Co., Ltd. エレベーターピッチ 「AWS IAM Identity Centerで200名以上の開発者 と130以上のアカウントを管理する中で、権限管理の 運用負荷が増加していました。 そこで、シンプルなテキストファイルとTerraformを 組み合わせることで、設定ファイルを編集するだけで 権限管理が完了する仕組みを実現できました。 開発チームへの安全な委譲も可能になり、運用負荷も 大幅に削減できました。」 

3 © SMS Co., Ltd. 自己紹介 氏名：山口隆史(やまぐちたかし) 所属：株式会社エス・エム・エス 　　　プロダクト推進本部　技術推進グループ 業務：全社SREとしての活動 略歴：フリーランス、SIer、Web系を渡り歩く→現職（2024/05〜） 自称：Security Hub芸人 好きなAWSサービス：営業、Security Hub、GuardDuty 他：AWS Community Builder(Security & Identity)、 　　JAWS-UG千葉支部運営、Snyk Ambassador 第022587号 

4 © SMS Co., Ltd. 

5 © SMS Co., Ltd. 会社概要
 *1：第7期迄は単体数値、第8期より連結数値にて記載 
 基礎情報
 株式会社エス・エム・エス（英語表記）SMS Co., Ltd. 
 2003年 4月4日 
 東京証券取引所プライム市場（証券コード:2175） 
 25億5,172万円（2025年3月31日時点） 
 連結：4,528人、単体：3,049人（2025年3月31日時点） 
 国内：4社、海外：アジア・オセアニア等16の国と地域 
 
 「高齢社会に適した情報インフラを構築することで人々の 生活の質を向上し、社会に貢献し続ける」 
 
 高齢社会に求められる領域を、医療・介護/障害福祉・ヘルスケア ・シニアライフと捉え、価値提供先であるエンドユーザ・従事者・事 業者をつなぐプラットフォームとしての情報インフラを構築し、40以 上のサービスを展開 
 会社名 
 設立
 市場情報 
 資本金 
 従業員数 
 関連会社 
 
 ミッション 
 業績
 売上推移 *1
 （売上高・億円） 
 社会課題の解決につながる事業を
 創造・拡大し、継続的に成長
 

6 © SMS Co., Ltd. 分野
 区分
 サービス
 キャリア 
 介護キャリア 
 
 
 医療キャリア 
 
 介護・障害福祉 事業者 
 
 
 ヘルスケア 
 
 
 
 
 
 
 シニアライフ 
 
 
 海外
 
 
 ＊1．柔道整復師、あん摩マッサージ師、はり師、きゅう師のこと 
 サービス一覧 
 看護師向け 
 人材紹介 
 介護・医療・福祉の 
 資格講座情報 
 PT/OT/ST向け
 人材紹介 
 介護職向け求人情報 
 ケアマネジャー向け
 人材紹介 
 看護学生向け 
 就職情報 
 放射線技師向け 
 人材紹介 
 高校生・看護学生 
 向け奨学金情報 
 臨床検査技師向け 
 人材紹介 
 看護師・看護学生向け 
 コミュニティ 
 臨床工学技士向け 
 人材紹介 
 保育士向け 
 人材紹介 
 治療家*1・セラピスト向け
 人材紹介 
 介護事業の 
 経営者・管理者向け情報 
 高齢社会の 
 調査・研究・情報発信 
 医療従事者向け医薬情報 
 治療家*1・セラピスト向け求 人情報 
 柔道整復師・あはき師
 向け受験参考書 
 管理栄養士・栄養士向け 
 人材紹介 
 介護職向け人材紹介 
 介護で働く人の
 ためのスクール 
 介護で悩む人向け
 コミュニティ
 高齢者向け
 食事宅配紹介
 高齢者向け
 住宅紹介 
 遠隔指導特定保健指導 
 サービス 
 管理栄養士・栄養士向け 
 コミュニティ 
 企業の介護離職 
 防止ソリューション 
 ICTを活用した 
 禁煙サポート 
 認知症患者とその家族
 向け認知症情報 
 認知症予防
 ソリューション 
 認知症予防の 
 習慣化サポート 
 遠隔指導重症化予防 サービス 
 女性の健康経営
 サポート 
 産業保健に
 関わる人向け情報 
 企業の健康管理 
 業務サポート 
 リフォーム会社
 紹介
 葬儀社紹介 
 ケアマネジャー 
 向けコミュニティ 
 医療従事者向け人材紹介 
 (マレーシア、フィリピン、アイルランド、UK、ドイツ等) 
 看護師向け
 キャリアサービス 
 行動療法に特化した
 禁煙サポート
 自治体向け調査・
 計画策定・予防事業
 医療介護業界特化型
 ストレスチェック
 介護/障害福祉
 事業者向け経営支援
 
 看護師の職場を 診断するツール 
 障害のある方向け
 就労支援事業所情報
 障害のある方向け
 人材紹介
 建設業界向け
 人材紹介
 

7 © SMS Co., Ltd. 注意事項 ● 今回発表する内容のコードは会社Blogで全量公開しています ● スライドも発表後に公開します https://tech.bm-sms.co.jp/entry/2025/05/20/110000 

8 © SMS Co., Ltd. ここから本題 

9 © SMS Co., Ltd. 01 02 03 04 05 06 今回の取り組みの背景 Identity Centerの基本 Terraformでの基礎的な実装・Planの課題 改善のアプローチとDSL 開発チームへの委譲 まとめ 目次 

10 © SMS Co., Ltd. 01 02 03 04 05 06 今回の取り組みの背景 Identity Centerの基本 Terraformでの基礎的な実装・Planの課題 改善のアプローチとDSL 開発チームへの委譲 まとめ 目次 

11 © SMS Co., Ltd. 今回の取り組みの背景 ● 数年前からIdentity Centerで外部IdPによるSSOは設定済み ● コード管理目的ですごく頑張ってTerraform importした ● tfactionを利用してCICDを入れた ● 開発者、AWSアカウントの増加に伴い運用負荷が増大 ● PR作成の自動化を目指してAmazon Q Developerを試してみ たがうまくいかなかった ● 開発チームに委譲できるように、ユーザー管理に伴う修正作業 をすごく簡単にしてみた ○ 生成AIなくてもいいんじゃね？くらいまで簡単になった ○ いまここ 

12 © SMS Co., Ltd. 01 02 03 04 05 06 今回の取り組みの背景 Identity Centerの基本 Terraformでの基礎的な実装・Planの課題 改善のアプローチとDSL 開発チームへの委譲 まとめ 目次 

13 © SMS Co., Ltd. Identity Centerとは 「AWS IAM アイデンティティセンターは、複数の AWS アカウントおよびビジネスアプリケーションへ のアクセスの一元管理を容易にします。＜中略＞IAM アイデンティティセンターを使用すると、AWS Organizations にあるすべてのアカウントに対する 一元的なアクセスとユーザーアクセス許可を簡単に管 理できます。」 https://aws.amazon.com/jp/iam/identity-center/features/ 

14 © SMS Co., Ltd. 主な概念 ● ユーザー ○ Identity Center で管理される個々の利用者 ● グループ ○ ユーザーの集合の名称 ● グループメンバーシップ ○ グループとユーザーとの紐付け ● 許可セット ○ アクセス制御の基本単位（ポリシーの集合体） ● アカウント割り当て ○ ユーザー／グループ、許可セットとアカウントとの紐付け 

15 © SMS Co., Ltd. 主な概念を図にしてみる ユーザー グループメンバー シップ アカウント割り当て 許可セット AWSアカウント グループ ポリシー 

16 © SMS Co., Ltd. 画面例 

17 © SMS Co., Ltd. 01 02 03 04 05 06 今回の取り組みの背景 Identity Centerの基本 Terraformでの基礎的な実装・Planの課題 改善のアプローチとDSL 開発チームへの委譲 まとめ 目次 

18 © SMS Co., Ltd. TerraformリソースとIdentity Centerの概念のマッピング Identity Centerの概念 Terraformリソース ユーザー aws_identitystore_user グループ aws_identitystore_group グループメンバーシップ aws_identitystore_group_membership 許可セット aws_ssoadmin_permission_set aws_ssoadmin_managed_policy_attachment aws_ssoadmin_customer_managed_policy_attachment aws_ssoadmin_permission_set_inline_policy アカウント割り当て aws_ssoadmin_account_assignment 

19 © SMS Co., Ltd. ［再掲］主な概念を図にしてみる ユーザー グループメンバー シップ アカウント割り当て 許可セット AWSアカウント グループ ポリシー 

20 © SMS Co., Ltd. 基礎的な実装の課題 ● ユーザー、AWSアカウントの増加に対してコード量がリニアに 増加する ○ アカウント割り当て＝AWSアカウント✖ユーザー数orグ ループ数✖付与する許可セット ● コードからユーザー、グループに付与した権限の棚卸しが困難 ○ 機械的にやろうとするとコードの解析やtfstateのパースが 必要になる ● 結果として、認知負荷が高く慣れている人しか安全に変更でき ない 

21 © SMS Co., Ltd. Terraform Planを見てみましょう 

22 © SMS Co., Ltd. ユーザーをグループに追加する # aws_identitystore_group_membership.example will be created + resource "aws_identitystore_group_membership" "example" { + group_id = "1234567890abcdef" + identity_store_id = "d-1234567890" + member_id = "b123456-1235-1234-1234-ab1234567890" + membership_id = (known after apply) } どのグループに 誰を 追加するのかが全 くわからない 

23 © SMS Co., Ltd. ユーザーをアカウントに割り当てる # aws_ssoadmin_account_assignment.example will be created + resource "aws_ssoadmin_account_assignment" "example" { + instance_arn = "arn:aws:sso:::instance/ssoins-1234567890abcdef" + permission_set_arn = "arn:aws:sso:::permissionSet/ssoins-1234567890abcdef/ps-1234567 890abcdef" + principal_id = "b123456-1235-1234-1234-ab1234567890" + principal_type = "USER" + target_id = "123456789012" + target_type = "AWS_ACCOUNT" } 誰に 何の権限を 割り当てるのか 全くわからない 

24 © SMS Co., Ltd. Terraform Planの課題 ● レビューが困難 ○ 誰に、何の権限を、どこに割り当てたのかをレビューした いが、誰と権限が、内部IDで表示されるため、Planだけで はわからない 

25 © SMS Co., Ltd. ここまでのまとめ ● Identity Centerは便利 ● Terraformの基礎的な実装はコード量がリニアに増大し、認知 負荷の増加も発生します ● Terraform Planで内部IDが表示されるため変更内容の レビューが困難 

26 © SMS Co., Ltd. 01 02 03 04 05 06 今回の取り組みの背景 Identity Centerの基本 Terraformでの基礎的な実装・Planの課題 改善のアプローチとDSL 開発チームへの委譲 まとめ 目次 

27 © SMS Co., Ltd. 前提条件：SMSでの運用規模 ● AWSアカウント数 130以上 ● ユーザー数 200名以上 ● グループ数 数十個程度 ● 許可セット数 10個程度 

28 © SMS Co., Ltd. 目指す姿 ● レビューが楽にできる ○ Terraform Planにユーザー名、グループ名、許可セット名 を表示する ● 開発チームに安全に委譲できる ○ AWSアカウント単位で委譲できる仕組みにする ● 認知負荷を減らす ○ 運用しつづける必要があるという意味で重要 ○ 開発チームに委譲するという意味でも重要 

29 © SMS Co., Ltd. 実装のアプローチ ● DSL化 ○ ユーザー作成、ユーザーをグループに割り当てる、ユー ザー・グループに権限を割り当てる操作をDSL化 ● ディレクトリ、ファイル名を構造化 ○ ディレクトリ、ファイル名だけで目的が伝わる構造にする ■ プログラム処理が可能な構造にする 

30 © SMS Co., Ltd. 実装するときに考えたこと［リソース名］ ● コード量を削減するためにはfor_eachで回してリソースを作る 必要がある ● for_eachで回して作成したリソース名を連番にしないために は、for_eachで回す変数ブロックに名前をつける必要がある ○ 単純な配列でfor_eachを回すと、変更時に destroy→createが発生する ● 名前付き変数ブロックを人間が記述するのはコード量が増えて 大変なので、単純な構造から自動生成する必要がある 

31 © SMS Co., Ltd. 必要なデータ構造［リソース名：assignment］ # このようなObjectの配列に整形してからfor_eachを回す [awsaccount_id]_[permissionset]_[user_name]={ user_name = ”user1” account = “12345678” permission_set_arn = “arn:aws:sso:::permissionSet/ssoins-1234567890abcdef/ps-1234567 890abcdef” principal_type = “[USER|GROUP]” } ● User名でuser_idが引けるようにUser作成時にリソース配列の キーをUser名にしておく 

32 © SMS Co., Ltd. 必要なデータ構造［リソース名：group membership］ # このようなObjectの配列に整形してからfor_eachを回す [groupname]_[user_name]={ user_name = ”user1” group_name = “XXX-Developers” } ● Group名でgroup_idが引けるようにGroup作成時にリソース配 列のキーをGroup名にしておく 

33 © SMS Co., Ltd. 実装するときに考えたこと［CICD］ ● 特に制約がなければtfactionに乗るのが良さそう ○ https://github.com/suzuki-shunsuke/tfaction ● tfactionの機能で、moduleの変更検知を使えばTXTファイル の変更でCICDできそう ○ update_local_path_module_caller ○ TXTファイルを配置するディレクトリをmodule扱いにする ためにdummy.tfを配置してmodule呼び出ししておく 

34 © SMS Co., Ltd. 実装するときに考えたこと［委譲］ ● AWSアカウント単位で委譲するのが良さそう ○ GitHubのCODEOWNERをフォルダ単位で設定すればいけ そう ● 許可セットを自由に作成できなければ一定のガードレールにな りそう ○ 許可セットのCODEOWNERは全社SREで保有 

35 © SMS Co., Ltd. 実装するときに考えたこと［ディレクトリ構造］ ● プログラム処理することを考えるとディレクトリ名はAWSアカ ウントIDが良い ○ Terraformのfileset関数で列挙できる ● AWSアカウントIDをフラットなディレクトリ構造で配置する ○ 部門・部署・サービス名のディレクトリ構造にすることも 考えたが、依頼を捌くのは全社SREのことが多い ● 開発チームの認知負荷の軽減はSymlinkで別の構造を作ること で対応できそう 

36 © SMS Co., Ltd. 実際に出来たディレクトリ構造 

37 © SMS Co., Ltd. ディレクトリ構造 terraform/ ├── user/ # ユーザー管理 │ ├── user.txt # ユーザーリスト（メールアドレス） │ └── dummy.tf ├── membership/ # グループメンバーシップ │ ├── XXX-Developers.txt # 開発者グループ │ ├── XXX-SREs.txt # SREグループ │ └── dummy.tf ├── assignment/ # アクセス権限の割り当て │ ├── 12345678/ # AWSアカウントID │ │ ├── AdministratorAccess_GROUP.txt │ │ ├── PowerUserAccess_USER.txt │ │ └── dummy.tf │ ├── 23456789/ │ └── ... 

38 © SMS Co., Ltd. ディレクトリ構造 ├── su/ # symlinkによる組織構造 │ ├── 医療キャリア/ # 開発者グループ │ │ ├── prd -> ../../assignment/12345678 │ │ ├── stg -> ../../assignment/23456789 │ │ └── dev └── others/ # Terraformの実装コード ├── variables.tf # 変数定義 ├── assignmeents.tf # assignmentの実装コード ├── assignmeents_dummy.tf # dummy.tfを読み込むための実装コード ├── memberships.tf # group membershipの実装コード ├── permissionsets.tf # permission setの実装コード ├── users.tf # userの定義コード └── groups.tf # Groupの実装コード 

39 © SMS Co., Ltd. 実際に出来たDSLはこんな感じ 

40 © SMS Co., Ltd. ユーザーを追加する時 ● ユーザー管理ファイル（user.txt） ○ Identity Centerに登録するユーザーのメールアドレスを記 載 [email protected] [email protected] … … 

41 © SMS Co., Ltd. グループにユーザーを追加する時 user1 user2 … … ● グループ管理ファイル（[GROUP名].txt） ○ Groupに所属させるユーザーのメールアドレスのメールア カウント部分（＠より左側）を記載 

42 © SMS Co., Ltd. ユーザーに許可セットを付与する時 user1 user2 … … ● ユーザー・許可セット管理ファイル（[AWSアカウントID]/[許 可セット名]_USER.txt） ○ 対象AWSアカウントに許可セットを付与するユーザーの メールアドレスのメールアカウント部分（＠より左側）を 記載 

43 © SMS Co., Ltd. グループに許可セットを付与する時 XXX-Developers … … ● ユーザー・許可セット管理ファイル（[AWSアカウントID]/[許 可セット名]_GROUP.txt） ○ 対象AWSアカウントに許可セットを付与するグループ名を 記載 

44 © SMS Co., Ltd. Terraform Planはこんな感じになりました 

45 © SMS Co., Ltd. ユーザーの追加 # aws_identitystore_user.this["user1"] will be created + resource "aws_identitystore_user" "this" { + display_name = "[email protected]" + external_ids = (known after apply) + id = (known after apply) + identity_store_id = "d-1234567890" + user_id = (known after apply) + user_name = "[email protected]" } リソースキーで 追加したユーザー名を 判別可能 

46 © SMS Co., Ltd. ユーザーをグループに追加する # aws_identitystore_group_membership.this["XXX-Developers_user1"] will be created + resource "aws_identitystore_group_membership" "this" { + group_id = "abc12345-1234-1234-1234-abc123456789" + id = (known after apply) + identity_store_id = "d-1234567890" + member_id = (known after apply) + membership_id = (known after apply) } リソースキーで どのグループに どのユーザーを 追加したか判別可能 フォーマット：[Group名]_[ユーザー名] 

47 © SMS Co., Ltd. ユーザーをアカウントに割り当てる #aws_ssoadmin_account_assignment.this["123456789012_AdministratorAcce ss_USER_user1"] will be created + resource "aws_ssoadmin_account_assignment" "this" { + id = (known after apply) + instance_arn = "arn:aws:sso:::instance/ssoins-1234567890abcdef" + permission_set_arn = "arn:aws:sso:::permissionSet/ssoins-1234567890abcdef/ps-1234567890a bcdef" + principal_id = (known after apply) + principal_type = "USER" + target_id = "123456789012" + target_type = "AWS_ACCOUNT" } リソースのキーで どのAWSアカウントIDに どの許可セットで どのユーザーを 追加したか判別可能 フォーマット：[AWSアカウントID]_[許可セット名]_USER_[ユーザー名] 

48 © SMS Co., Ltd. グループをアカウントに割り当てる #aws_ssoadmin_account_assignment.this["123456789012_AdministratorAcce ss_GROUP_XXX-Developers"] will be created + resource "aws_ssoadmin_account_assignment" "this" { + id = (known after apply) + instance_arn = "arn:aws:sso:::instance/ssoins-1234567890abcdef" + permission_set_arn = "arn:aws:sso:::permissionSet/ssoins-1234567890abcdef/ps-1234567890a bcdef" + principal_id = “abc12345-1234-1234-1234-abc123456789” + principal_type = "GROUP" + target_id = "123456789012" + target_type = "AWS_ACCOUNT" } リソースのキーで どのAWSアカウントIDに どの許可セットで どのグループを 追加したか判別可能 フォーマット：[AWSアカウントID]_[許可セット名]_GROUP_[グループ名] 

49 © SMS Co., Ltd. ここまでのまとめ ● DSL化することで、日常的に発生する作業が開発チームに委譲 できるくらい簡単になりました ● リソース名に意味を持たせることで、Terraform Planを見る だけでレビューができるようになりました ● Symlinkを利用することで、AWSアカウントIDに意味を持たせ ることができ、開発チームの認知負荷が下がりました 

50 © SMS Co., Ltd. 01 02 03 04 05 06 今回の取り組みの背景 Identity Centerの基本 Terraformでの基礎的な実装・Planの課題 改善のアプローチとDSL 開発チームへの委譲 まとめ 目次 

51 © SMS Co., Ltd. ［再掲］ディレクトリ構造 terraform/ ├── user/ # ユーザー管理 │ ├── user.txt # ユーザーリスト（メールアドレス） │ └── dummy.tf ├── membership/ # グループメンバーシップ │ ├── XXX-Developers.txt # 開発者グループ │ ├── XXX-SREs.txt # SREグループ │ └── dummy.tf ├── assignment/ # アクセス権限の割り当て │ ├── 12345678/ # AWSアカウントID │ │ ├── AdministratorAccess_GROUP.txt │ │ ├── PowerUserAccess_USER.txt │ │ └── dummy.tf │ ├── 23456789/ │ └── ... AWSアカウントID単位で 開発チームを CODEOWNERに追加 （全社SREもCODEOWNER） 

52 © SMS Co., Ltd. ディレクトリ構造 ├── su/ # symlinkによる組織構造 │ ├── 医療キャリア/ # 開発者グループ │ │ ├── prd -> ../../assignment/12345678 │ │ ├── stg -> ../../assignment/23456789 │ │ └── dev └── others/ # Terraformの実装コード ├── variables.tf # 変数定義 ├── assignmeents.tf # assignmentの実装コード ├── assignmeents_dummy.tf # dummy.tfを読み込むための実装コード ├── memberships.tf # group membershipの実装コード ├── permissionsets.tf # permission setの実装コード ├── users.tf # userの定義コード └── groups.tf # Groupの実装コード 開発チームが 管理しやすい形式を Symlinkで 開発チーム自身が 作成する 

53 © SMS Co., Ltd. 01 02 03 04 05 06 今回の取り組みの背景 Identity Centerの基本 Terraformでの基礎的な実装・Planの課題 改善のアプローチとDSL 開発チームへの委譲 まとめ 目次 

54 © SMS Co., Ltd. 何が楽になったか ● 運用作業がテキストファイルの変更だけですむようになった ● Terraform Planに人が読んでわかる名前がでるのでレビュー が楽になった ● Symlinkで自由に名称が付与できるのでAWSアカウントIDを覚 えなくてもよくなった 

55 © SMS Co., Ltd. 結果としてどうなったか ● Identity Centerの権限付与・削除作業を開発チームに安全に 委譲できるようになった ● 工数の削減、リードタイムの短縮 ○ 依頼から反映までのリードタイム：0.5日から1日→10min から30min程度