この記事は、Sansan Advent Calendar 2025 、7日目の記事です。
はじめに
こんにちは、技術本部 コーポレートシステム部 Corporate Architectureグループ所属の小松です。
最初に所属先のコーポレートシステム部門について簡単に紹介させてください。 コーポレートシステム部は、情報システム部門（いわゆる情シス）にあたります。部のミッションとして「EXをシンプルにする」ということを掲げています。EXとは Employee Experience（従業員体験）のことです。
本ブログでは、一部ではありますがEX向上の寄与に関連する AWS / Google Cloud / SaaS の横断的な権限管理基盤を作り直した話を書きたいと思います。正確には「作り直し始めた」段階で、まだ道半ばです。ただ、構想から1年以上が経ち、最近少しずつ運用も進み始めました。ここで一度、これまでの経緯を整理する意味も込めて、ブログにまとめることにしました。
既存の権限管理基盤は、元々技術本部ができる前の研究開発とデータ化を担う旧組織で開発されたものです。その後、組織改編を何度か挟みながら使ってきましたが、利用者も環境も、求められるセキュリティレベルもその頃とはかなり変わってきており、このギャップを解消する必要が出てきました。
背景と課題
まず前提として、今回対象にしている環境の規模感について共有します。
旧組織を源流とする部署では、現在複数の AWS アカウントと Google Cloud プロジェクトを利用しています。AWSアカウントは 20 近く、Google Cloudのプロジェクトも30近くあります。これに加えて業務アプリケーションも複数存在しています。これらの環境は、旧組織を源流とする部署だけではなく社内の複数のチームで広く利用されているような状況です。
では、このタイミングでなぜ基盤を見直す必要があったかについて説明します。
一つは、組織改編による責任の分散です。 「はじめに」で述べたように、この仕組みは元々旧組織の中で完結する前提で作られていました。しかし、旧組織自体がいくつかの部署に分かれていく中で、「誰がこの基盤を改善するのか」「運用にどこまで責任を持つのか」がだんだん曖昧になってきました。利用者は増えているものの、改善や運用に割けるリソースは見えづらくなっていた、という状況です。
もうひとつの理由は技術的な陳腐化です。 この仕組みを作った当時と比べると、AWS / Google CloudのIdentity周りのサービスは進化していました。より安全に、よりコストを抑えて権限管理ができるサービスやパターンが増えているのに対し、旧来のやり方を利用し続けている状態になっていました。 また、従来の運用には、いくつかの課題がありました。 まず、権限に関する設定変更──たとえば、申請者がアクセスできる環境や、申請内容を誰が承認するかといった情報は、限られたインフラメンバーだけが運用できる状態になっていました。結果として、細かな変更や調整のたびにインフラ側に依頼する形になっていました。
加えて、SaaS の利用が増えてきたことも影響しました。 セルフホストのRedashをはじめとした各種サービスでユーザ管理・アクセス管理が必要になりますが、サービスごとに手順が異なるため、利用者・運用者側の負担も大きくなっていました。
さらに、全社的に「Oktaを共通のIdPとして利用していく」という方針が強まりつつありました。旧来の仕組みはその方針と整合しない部分も多く、このままでは将来的に管理コストとセキュリティリスクの両方が増えていく懸念がありました。
こういった状況を踏まえ、運用の属人性やサービスごとに異なるフロー、そして全社方針とのギャップを解消するために、基盤そのものを見直す必要が出てきた、という流れでした。
取り組みの全体像
ここからは、権限管理基盤をどのような構成で作り直したのかを説明します。
今回の仕組みは、「申請 → 承認 → 権限付与 → 失効」という一連のプロセスを一つの流れとして扱えるように再設計しました。
基盤を構成するコンポーネントは、大きく分けて次の五つです。
- GitHub 権限情報を一元管理するための単一ソースです。申請者がどの環境にどういった権限でアクセスできるか、承認者は誰かといった情報をここに集約しました。
- Slack Bot 権限申請の入り口です。Slackのコマンドから申請できるようにしました。
- Kickflow 承認フローを扱うSaaSです。技術本部全体ですでにワークフローツールとして利用していたため、そのまま活用することにしました。Webhookなどの機能が充実しており、システム連携がしやすい点も採用理由の一つでした。
- API Server on EKS KickflowのWebhookを受け取り、AWS / Google Cloud / Oktaに対して権限付与・失効を実行します。今回の基盤の中核となります。
- Batch on EKS 申請時に指定された「付与を希望する時間」が経過したかを監視します。期限を過ぎていれば、Kickflowのワークフローを次のステップに進めます。CronJobとして定期的に起動し、ワークフロー側で失効処理が進むよう制御します。
APIサーバとバッチは、それほど大きなアプリケーションではありません。複雑でもなく、機能も限定的です。そのため、これだけのためにインフラを新設するのは過剰だと判断しました。社内ではEKS基盤（通称circuit）をホストしており、内製アプリ用のnamespaceも備わっています。サービス単位のURLの払い出しやデプロイ周りの仕組みもすでに整っていました。今回のコンポーネントはこの上で動かすのがリーズナブルで、運用上も自然だと判断しました。つまり、「この基盤のためにEKSを作った」のではなく、既存のcircuit上に小さく乗せたという位置づけになります。
まとめると、GitHubに権限情報を置き、SlackからKickflowに申請を流し、APIサーバで権限付与と失効を処理し、バッチが期限管理を行う流れになっています。これらが疎結合で動きながらも、権限管理のルールは一つに統一されるよう設計しました。
AWS / Google Cloud / SaaS の権限付与をどう扱うか
ここでは、AWS / Google Cloud / SaaSのそれぞれに対して、今回どのように権限付与を実現しているのかを整理します。
AWS
AWS IAM Identity Center を使っています。権限はPermissionSetとグループの組み合わせで管理し、実際の権限付与はグループにユーザーを追加するだけで完結します。IdentityStoreのGroup Membership を作成すると、その時点で対象アカウントに権限が反映される仕組みです。ユーザープロビジョニングについては、Identity Center に対してOktaをIdPとする構成をとりました。全社的にOktaを共通IdPとして利用する方針があるためです。Identity CenterのグループやPermission Setのリソースは、すべてTerraformで管理しています。
Google Cloud
IAMに直接ユーザーを追加するのではなく、Cloud Identityのグループを使う構成にしました。Googleグループに所属させるとIAMが効く仕組みです。Google Cloudについては、Google Workspace（GWS）と連携しています。GWSにはOktaからユーザープロビジョニングをしているため、今回の基盤では「Okta → GWS → Cloud Identity → Google Cloud」という流れでユーザー情報が反映される前提になっています。権限管理を本システムで扱うにあたって、Google Project × IAM Roleのペア単位で Googleグループを作成するようにしました （ex. google-project-a.admin@sansan.com ) 。これらのGoogleグループの作成は、コーポレートシステム部によりTerraform化されていたため、それをそのまま利用しています。
SaaS(Okta）
SaaS の権限管理については、OktaをIdPとして利用し、SSO / SCIMで各アプリケーションと連携することを前提にしています。グループにユーザーを追加すると、そのグループと紐づいているOkta Applicationに対してSSOやSCIMの設定がそのまま反映されます。グループがアプリケーションへのアクセス制御の単位になっているため、どのアプリを利用できるかは、この グループへの所属によって決まります。OktaでもGoogle Cloud同様に、Application × Role のペア単位で Okta グループを作成する必要がありました。こちらもコーポレートシステム部で Terraform 化されていたため、その仕組みを利用しています。 buildersbox.corp-sansan.com
今回扱う 3 つのプロバイダーは、それぞれ権限モデルが異なります。ただ、共通して扱いたい情報は「誰が、どのグループ（ロール）に、どの承認者の承認のもとアクセス可能か」という点でした。そのため、GitHubにある権限情報を扱うjsonではこの「抽象化された権限モデル」をそのまま表現する形にし、API Server側でproviderごとの処理に分岐する設計にしています。権限情報を扱うjsonは以下のようなイメージです。
[ # AWS { "group_name": "test-account.user", "type": "aws_identity_center", "approvers": [ "approver1@sansan.com", ], "members": [ "user1@sansan.com", ], }, # Google Cloud { "group_name": "test-project.admin", "type": "google_cloud_group", "approvers": [ "approver1@sansan.com", ], "members": [ "user1@sansan.com", ], }, # Okta Application { "group_name": "okta-group.admin", "type": "okta_group", "approvers": [ "approver1@sansan.com", ], "members": [ "user1@sansan.com", ], } ]
時限式の権限については、権限付与後にユーザーを特定のワークフローステップにとどめておき、そのステップを基準に期限管理をしています。バッチ処理で申請時に指定された利用時間をチェックし、期限を超えていれば次のステップに進めます。これを契機に失効処理が動きます。また、作業が早く終わった場合などは、申請者自身が次のステップに進めることもでき、その場合も同様に失効処理が動きます。Google CloudにはExpiryDetailというグループ追加時に失効時期を指定できる機能がありましたが、AWSとOktaには当時期限機能がなかったため、Kickflowのステップ遷移を失効の共通トリガーとしました。
振り返り：うまくいったことと、課題として残っていること
今回の取り組みを通じて、いくつか手応えを感じた点があります。
まず、権限情報を GitHubに集約し、共通のスキーマを持つjsonという形で管理できるようになったことです。単に一元管理しただけではなく、部門ごとにディレクトリを分け、その配下に各部の管轄となるAWS・Google Cloud・SaaSの権限情報を整理する構成にしました。さらに、そのディレクトリ単位で CODEOWNERSを設定したことで、権限情報の変更は各部門が自分たちで管理できるようになっています。これにより、旧組織時代のように一つのチームが全体を把握し続ける必要がなくなり、分割統治が効く状態になったのは大きかったです。
もう一点は、組織横断での協力が得やすかったことです。AWS / Google Cloud / Okta のそれぞれで必要な準備がありましたが、関係各所が前向きに対応してくれたことで、最低限必要なモデルが整い、基盤としての共通化につながりました。Kickflowを使った期限管理もうまく機能しており、クラウドやサービスごとの差異を吸収しながら権限を扱えるようになっています。
一方で、まだ課題として残っている部分もあります。
特にGoogle Cloudの権限周りは改善の余地があります。AWSは、Identity CenterのPermissionSet・グループが一つのリポジトリ内で確認できますが、Google Cloudについては「どの Googleグループに、どの IAM Roleが紐づいているのか」を一元的に見えるようになっていません。そのため、権限変更依頼が来た際に確認する情報が散在してしまい、属人化・運用負荷につながっている点は反省材料だと思っています。
また、Googleグループ / Oktaグループの作成が別リポジトリに分かれている点も課題として残りました。今回の基盤では「権限付与」を中心に据えているため、グループそのものはすでに存在する前提にしていましたが、グループ作成までを１つのリポジトリ内で一気通貫でIaC化できていないため、利用者の負担が想定より大きくなっていると感じています。
総じて言うと、今回の取り組みは「技術を作る」よりも「運用をどこまで整理するか」「どこまでを共通基盤として扱うか」といった、組織面の調整に時間がかかった印象です。ただ、これを通じて権限管理の基盤について改めて議論できたことや、IdPを中心に据えた構成のメリットを整理できたことは良い収穫でした。まだ道半ばではありますが、少しずつ改善しながら進めていきたいと思っています。
おわりに
今回のブログでは、旧組織を源流とする部署を対象に、AWS / Google Cloud / SaaSの権限管理基盤をどのように作り直してきたのかを書きました。ただ、技術本部には他にも複数の部署があり、それぞれが業務やプロダクトごとに独自の承認を伴う権限管理の仕組みを開発・運用しています。本来であれば、こういった仕組みは一つに統一できるはずであり、そのほうが運用面でもセキュリティ面でも効率的です。
また、SaaSという文脈まで範囲を広げると、この課題は技術本部に限った話ではありません。全社レベルで見渡すと数多くのSaaSが利用されており、それぞれに承認フローや権限付与の仕組みが必要になるケースがあります。現在は部門単位で個別に運用されている部分も多く、そこにどれだけの工数がかかっているのかを把握しづらい状況もあります。
コーポレートシステム部 Corporate Architectureグループでは、これらを踏まえて全社のアカウント管理をどう統一するかというプロジェクトを進めています。本ブログの内容はあくまでパイロット的な取り組みですが、ここで得られた知見や実装の一部は、全社向けの仕組みづくりにも活かせると考えています。現在、全社で使われているアカウント管理の実態、各SaaSに対してどのような権限付与フローが存在しているのか、どこに課題があるのか、といったヒアリングや調査が進んでおり、次のステップとしてPOCの作成も始まっています。
もし、こういった「アカウント管理基盤」の開発に興味がある方がいれば、ぜひカジュアル面談でお話しできると嬉しいです。技術と組織の両方に向き合う面白さのある領域ですので、興味のある方は気軽にご連絡ください。
