この記事はリクルート ICT統括室 Advent Calendar 2023 22日目の記事です。

はじめに

こんにちは。リクルート ICT統括室 コミュニケーションプラットフォームグループの 政岡 裕士 です。普段は まっぴぃ というハンドルネームでコミュニティ活動をしています。
リクルートでは、リクルートグループ従業員数万人が利用する Microsoft 365 や Power Platform 環境の運用・管理、開発支援をはじめ、Microsoft Azure 環境の運用・管理などを担当しています。
今回は、私が普段よりリクルートの情シス担当として Microsoft Graph API 利用時に心がけていることや注意していること、実際に業務内で行っていることを参考に、企業内で Microsoft Graph API を利用する際に情シス担当が把握しておくと良い点をご紹介できればと思います。

Microsoft Graph API

（すでにご存知の方も多いとは思いますが） Microsoft Graph API とは、Microsoft 365 サービス全体に保存されているデータへのアクセスを提供する API です。
API を使用することで、Microsoft 365 サービス内に保存されているデータをアプリケーションで利用したり、メール送信や Teams チャット投稿など、アプリケーションから Microsoft 365 サービスに対して操作を行うことができ、社内における業務の生産性を向上させることができます。

Microsoft Graph API については、上記の公式ドキュメントの他、Microsoft Graph REST API v1.0 (または beta) リファレンスというものがあり、利用の際は基本、こちらを参照することになると思います。

Microsoft Entra ID (旧 Azure AD) では、2022 年ごろから多要素認証デフォルト有効化の話があり、またそれに関連する形で Exchange Online で基本 (Basic) 認証廃止や ADAL (Active Directory Auth Library)、Azure AD Graph のサポート終了が発表されていました。
そのため、リクルートにおいても、2021 年頃から現在に至るまで、日々、Exchange Online や SharePoint Online などの Microsoft 365 サービスと連携をするための Microsoft Graph に関する問い合わせがたくさん寄せられています。

（下記は以前、コミュニティ内で登壇した内容です）

Microsoft Graph API を利用する際の勘所

具体的に Microsoft Graph API を利用する際の勘所をご紹介したいと思います。私たちは、リクルートの Microsoft 365 基盤の管理者として、Graph API 利用を許可する際の勘所について、以下が挙げられると考えています。

• 管理者・利用者の双方で、アクセス許可の種類について正しく理解しているか
• API のアクセス許可の内容は、必要最低限のものとなっているか
• 管理者の同意は本当に必要な操作であるか
• サービスプリンシパルの作成権限について、管理者側で制御ができているか
• 利用のためのシークレットや証明書は、正しい管理を行なった上で利用・運用・棚卸・更新がされているか

権限観点でのポイント

管理者・利用者の双方で、アクセス許可の種類について正しく理解しているか

リクルートで Microsoft Graph API の利用を行う際は、（できる限り）私たち管理者だけでなく、Graph API 利用を希望する社内のユーザーにおいても、アクセス許可の種類について理解をしていただくようにしています。なぜこれを行っているかと言うと、後述する API アクセス許可の内容が必要最低限のものとなっているか を管理者だけでなく、利用を希望する社内のユーザーにも正しく認識いただき、セキュアな状態を維持しつつ Microsoft Graph API を気軽に組織内で利用できる文化を形成したいからです。
そして、それはつまり、私たち管理者側は Microsoft Graph API のアクセス許可の種類について、より正しい認識や知識・知見を持たなければならないということを意味します。これは、私を含め、管理者として働いているメンバーのスキルアップや技術力向上に寄与できます。
（おそらく）企業の中で Microsoft 365 や Microsoft Entra ID を管理している方は、日々、いろいろなシーンで、社内外より Microsoft Graph API の利用希望の話を受けることがあると思います。
例えば、

• A 社の XXX という製品を導入し、Exchange Online のメールや予定表と連携をしたい
• スクラッチの社内アプリで SharePoint Online サイト上にあるファイル群を操作したい
• SAML や OIDC で SSO 連携しているエンタープライズアプリについて、連携しているセキュリティグループのメンバー管理を自動化したい

こういった相談を受ける中で、まず議論の論点になるのが 要求する Graph API のアクセス許可は Delegated (委任) と Application (アプリケーション) のどちらであるか という点です。
こちらを正しく認識し、また可能であればどのようにアプリケーションが Graph API 経由で Microsoft 365 などのリソースにアクセスするのかについて、管理者と利用希望者の双方で把握することが重要と考えます。

Delegated と Application の違い

Microsoft Graph API には、Delegated と Application という 2 種類のアクセス許可の種類が存在しています。この 2 つがどのように異なっているのかについて、しっかりと理解した上で必要最小限の権限付与ができるようにする必要があります。

上記は、Microsoft 公式のドキュメントのものですが、少しわかりにくい部分があるので、リクルート内では普段、以下のような形でユーザーに対し説明を行なっています。

ちなみに、社内における各ユーザーの IT リテラシーには違いがありますので、言葉だけで説明するのは少し難しい部分ももちろんあります。その場合は、公式の図に倣って、絵コンテなどを使って説明したりする時もあります。

API のアクセス許可の内容は、必要最低限のものとなっているか

サービスプリンシパルに付与する Microsoft Graph API の権限内容について、必要最低限のものを要求しているか、払い出しを行う際に、管理者側・ユーザー側双方で確認をしています。これは、サービスプリンシパルを利用して行いたい業務フロー内容や、なぜ指定の Microsoft Graph API 権限を要求するのかについて正しく理解し、不必要な権限は付与しないようにし、当社における情報漏洩などのセキュリティリスクを最小限にするようにするために実施しています。
そして、この確認は、スクラッチ開発で利用する場合に加え、他社 SaaS 製品などにおける利用時などでも実施しています。
当社内でも過去、他社様の SaaS 製品において、製品アップデートによりそれまでに要求されていた Microsoft Graph API のアクセス許可要求の内容が大きく変更された事案があったり、本来必要のない権限過多のアクセス許可要求の内容を求められてしまった事案がいくつかありました。

管理者の同意は本当に必要な操作であるか

Microsoft Graph API の権限の中には、管理者の同意 がないと利用できないものが存在します。

これは、例えば、テナント下に存在する全ユーザー情報の取得をはじめ、SharePoint 上に存在する情報へのアクセスであったり、サインインログや監査ログの取得など、管理者操作であったり、ユーザーが操作できるものの中でも強い権限がないと実行ができない操作内容に対して、テナント管理者の事前の承認がなければ利用ができない、というものです。
つまり、逆を言えば、Graph API などの中には、この 管理者の同意 が不要な権限も存在します。例えば、Delegated のアクセス許可に関して言うと、以下のようなものがあります。

• Mail.Read (Delegated)
• Mail.Send (Delegated)
• Sites.Read.All (Delegated)
• Sites.ReadWrite.All (Delegated)
• User.Read (Delegated)

例として挙げた上記のアクセス許可は、管理者の同意を行う必要なく、利用が可能です。そのため、これらの Delegated のアクセス許可を利用する際は、ユーザーログイン時などにおけるアクセス許可の画面にて、ログインするユーザーそれぞれに対して上記のアクセス許可の承諾をさせるだけで良いということになります。

※実際に誰がどんなアクセス許可を承諾したかについては、エンタープライズアプリの画面で確認することが可能です。

ですが、本来不要な管理者の同意（組織に代わって同意する）が求められることも多く存在しています。
企業の情シス担当として、本来は、

• 必要としているユーザーにのみ対してだけ
• 製品・サービス・システム内で利用するために必要最小限のアクセス許可

を付与したいので、製品・サービスの担当者の方や利用を希望するユーザーに説明を行い、場合によっては修正いただくこともあります。リクルートでは、必要最小限の権限付与をできる限り守れるよう、情シス担当としてこのような取り組みを行っている次第です。

サービスプリンシパル観点でのポイント

サービスプリンシパルの作成権限について、管理者側で制御ができているか

これも非常に重要な内容だと考えます。Microsoft Entra ID では、既定だと、Microsoft Graph API のアクセス許可のために必要となる サービスプリンシパル の発行が、誰でも実行でき、かつ発行者がサービスプリンシパルの所有者になることが出来るように設定されています。
リクルートでは、この状態は組織内で Microsoft Graph API を利用するにあたり、セキュリティ面において問題があると考えており、サービスプリンシパルの作成は、Microsoft Entra PIM (Privileged Identity Management) にて承認されたアプリケーション管理者のみが実施でき、一般ユーザーによるサービスプリンシパルの作成は一切できないよう、制御を入れています。
サービスプリンシパルの作成を誰でも簡単に実施出来るということ（かつ、作成者が自身が作成したサービスプリンシパルの所有者になれること）は、任意のユーザーが以下の操作を行うことが可能ということになります。

• サービスプリンシパルの実行に必要となるシークレットの追加発行・削除や証明書の追加登録・削除が自由に出来てしまう
• シークレットの発行や証明書の登録、シークレットおよび証明書の有効期限をテナント管理者は制御できない

シークレットの発行を自由に行えるようにした場合、数年・数十年といった長期間利用可能なシークレットを発行したり、不要となったシークレットが削除されずに残ってしまうことが考えられます。
また、サービスプリンシパルは、通常のユーザー ID と異なり、利用に際して多要素認証などの 2 段階認証をとることができません。つまり、シークレット情報が他に流出してしまった場合に、普段と異なる環境からアクセスされているかどうかの判断が非常に難しいものとなっています。（サインインログなどから追跡や確認は可能ですが、毎回どこからアクセスされているのかを常に把握するのは困難です）
もちろん、サービスプリンシパルを発行した個々のユーザーがシークレットを適切に管理できるのであれば問題ないのですが、当社では安全性を重視しました。そのため、一般ユーザーによる自由な発行は禁止とし、申請を受けて管理者が発行する運用としている状況です。

利用のためのシークレットや証明書は、正しい管理を行なった上で利用・運用・棚卸・更新がされているか

サービスプリンシパルを利用する上で、シークレットや証明書の管理は非常に重要なものになります。なぜならば、これらの流出は、Microsoft Graph APIなどへの不正アクセスにつながるからです。特に、シークレットについては、単なるフラットな文字列でしかないため、社内外問わず、流出する危険性を多くはらんでいます。
リクルートでは、サービスプリンシパルの利用条件として、証明者やシークレットに関するルールをいくつか定めており、これらの順守をユーザーに求めています。

• 証明書/シークレットは半期に 1 度の棚卸、年 1 回の更新を行う
• 共有ストレージ（ファイルサーバ、SPO・OneDriveやGoogle Driveなど）への証明書/シークレットのアップロードの禁止※登録設定作業時などを除く
• ソースコード管理システム（GitHubやGitLabなど）への証明書/シークレットのアップロードの禁止
• メールやMicrosoft Teams、Slack を利用した証明書/シークレットの受け渡しの禁止
• プログラム内におけるシークレットのハードコーディングの禁止※AWS Secret ManagerやAzure Key Vaultなどの利用を推奨
• 証明書/シークレットが記録されている場所に対する必要最低限となるアクセス設定の対応

社内の本番環境に対するデータアクセスにつながる証明書やシークレットについては、その保管や利用に関してもしっかりとルール作りを行い、運用・管理していくことで、有事の際にも柔軟に対応できるよう、管理者・ユーザー双方で理解を深めながらサービスプリンシパルを利用することが重要と考えます。

さいごに

今回は、リクルートで行っている取り組みを参考に、Microsoft Graph API を安心して使うためのポイント５選についてご紹介させていただきました。
リクルート ICT統括室 Advent Calendar 2023では、リクルートの社内ICTに関する記事を投稿していく予定です。もし興味があれば、ぜひ他の記事もあわせてご参照ください。