バクラク事業部Platform Engineering部の id:itkq です。先日ラブライブ！決勝をこの目で見届けることが叶いました。蓮ノ空女学院スクールアイドルクラブのみなさま、優勝本当におめでとうございます。

さて、以前Fintech事業部からMicrosoft Entra IDのPrivileged Identity Management (以降、PIM) についてのブログが投稿されましたが、バクラク事業部でも2024年5月頃から本運用しています¹。 tech.layerx.co.jp

この記事ではバクラク事業部におけるPIM for Groupsの運用事例と、申請を素早く上げるための工夫を紹介します。

PIM for Groups

Entra IDのPIMがサポートするリソースにはRoleとGroupの2つがあります。このうち、今回紹介するものはGroupのみです (PIM for Groups)。

learn.microsoft.com

これを利用して、SCIMプロビジョニングしている特権的なGroupにPIMで所属することで、一時的な権限昇格を実装することが可能です。動作は次のイメージです（以前私が発表した資料から引用）。

承認機能付きの一時的な権限昇格を自前で実装する場合、それなりに考慮する点があり面倒です。一方PIM for Groupsを利用することで、Entra IDをIdPとして利用でき、かつSCIMプロビジョニングをサポートしているあらゆるXaaSで使えることになります。

PIMの運用

バクラク事業部が提供するサービスではお客様の財務情報を扱うこともあり、エンジニアであっても本番環境へのWrite operationは通常制限されています。しかし障害などの対応としてWrite operationが必要な場面があり、ここでPIMによる権限昇格を活用しています。 現時点では次のサービスで利用しています。

• AWS
• Google Cloud
• Twingate
• Snowflake

2024年5月にTerraform provider hashicorp/azuread がPIM for Groupsのリソースをサポートしたため²、以降はTerraformで設定を管理しています³。

グループの規約

権限昇格を前提とするだけでなく、そのサービスの管理者など恒常的に権限を与えたい場合もあります。これを考慮し、PIMを活用するグループは次のように標準化しています。

• グループ名: {prefix}-{div}-{provider}-{env}-{permission}
  • prefix
    • pim: 権限昇格
    • regular: 恒常
  • div
    • Division. バクラクの場合は bakuraku
  • provider
    • 対応するXaaSなど
  • env
    • 環境。基本的に dev, stg, prd のいずれかまたは組み合わせ
  • permission
    • 権限レベルを表す表現
• グループを作る基準
  • regular が必要かにかかわらず常に pim と regular はセットで作成する

例えば、バクラク事業部のAWS本番環境でWrite operationができるグループ名は pim-bakuraku-aws-prd-operator-access といった具合です。

承認

承認なし or 自己承認による昇格は一切使っていません。 承認を必須としている理由は「一人の判断だけで危険な操作が完結することを防ぎたい」ためです。一方で承認可能な範囲は広く取っており、自分以外の正社員エンジニアであれば承認可能、をベースとしています。

PIMのツラみ: Webでの申請に時間がかかる

ここまで紹介したように、PIMはたいへん便利なのですが、「申請にやたら時間がかかる」という不満があります。Trotto go links ⁴ で申請をするURLに直接アクセスするなど申請までの時短工夫はしていますが、申請画面を開いてから申請が終わるまでの時間がかかります。検証のためのリクエストが必ず走り、これが遅いように見えています。このリクエストが完了するまでの時間にはバラツキがありますが、最も遅いときで 30秒程度 (!!) かかることもありました。また、申請の理由は必須に設定しており、それを書く必要がありますが、検証が終わるまでは書き始められないこともストレスです。

APIでPIM申請できないか?

PIM for GroupsのAPIは提供されているため、必要最低限のAPIを使うことで高速に申請ができないかを考えました。その本体はCreate assignmentScheduleRequestです。このAPIに必要なスコープは PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup です。

az CLI が使用するEnterprise Applicationではこのスコープが設定されておらず、また az account get-access-token で取得することも叶いませんでした。 az rest でもPIM for Rolesしか対応されていないようでした。

github.com

結論として az では難しそうでした。そこで頼みの綱となったものが m365 CLI です。m365 CLIはコミュニティ主導でメンテナンスされているOSSです。これは任意のApp Registrationを利用できるため、PIM APIに必要なスコープを指定可能です。

pnp.github.io

実際に検証したところ、自分のidentityとしてPIM申請をあげることができました。

Special Thanks: この検証は私ではなく @civitaspo がやってくれました

PIM申請するCLIを提供する

バクラク事業部では開発を便利にするためのCLI lxtool が存在します。ここにPIM申請をする機能を組み込みました。社内ツールであるため実装は割愛しますが、次のことをします:

1. privilegedAccessGroupEligibilitySchedule: filterByCurrentUser APIで昇格可能なグループを探してリストする
2. 昇格するグループを選ぶ
3. 理由と期限を入力する
4. Create assignmentScheduleRequest APIで申請をあげる

実際に実行した録画が以下です。昇格可能なグループを探すAPIはすぐ帰ってくるため、期限と理由を書き始められるまでは一瞬なのもあり、ストレスはだいぶ軽減されたと感じます。

おわりに

今回はバクラク事業部におけるPIM for Groupsの運用と工夫について紹介しました。CLIを使ってもらったエンジニアからは喜びの声が届きました。申請だけでなく承認もCLIでやりたい、や承認依頼通知も含めてSlackで全部やりたい、などの要望もあり、このあたりはFuture worksとしたいと思います。PIM自体はバクラク事業部の運用としてかなり根付いてきており、今後もさらなる活用や改善に取り組みたいです。

また、私が所属していたDevOpsチームは、最近「SREチーム」へと名前を変えました。 tech.layerx.co.jp

今回紹介したPIMも含め、様々な角度から本番環境の改善に向き合っていく仲間を募集しています!! カジュアル面談でもお待ちしています。

open.talentio.com