プロダクト開発者⽬線での Entra ID 活⽤ Azure SQL Database と Managed Identity を活⽤した 認証・権限管理の実践例 Sansan株式会社 今村 有⼈ 

2 © Sansan, Inc. 自己紹介 2022年に中途で Sansan に⼊社。 以来 Sansan Data Hub の開発メンバーとして活動している。 ロール変更に伴い、これまであまり触れてこなかったインフラ レイヤーの技術に悪戦苦闘しつつ、刺激的な⽇々を送っている。 最近のテーマはエンジニアの運⽤負荷を下げて、いかに⽣産量 を増やせるかに興味がある。 今村 有⼈（Imamura Arito） 

3 © Sansan, Inc. 今⽇のテーマ Azure リソース間の認証を Managed ID 使って 実装したって話 

イントロダクション 

5 © Sansan, Inc. Sansan Data Hub のアーキテクチャ 

6 © Sansan, Inc. 概要 - ユーザーやグループ、アプリケーション、デバイスなどを⼀元管理するための IDaaS - Microsoft 365 (ex: Office 365) や Azure リソースなどの認証基盤 主な機能・役割 - シングル サインオン (SSO) - 多要素認証 (MFA) - ユーザー/グループ管理 - Azure リソースとの連携 ◀今回のお話 - Managed ID (User Assigned / System Assigned) を使って、 Azure VM, App Service, Functions がパスワードレスで認証 Entra ID (旧 Azure AD) とは 

7 © Sansan, Inc. Managed ID を使った Azure リソースの認証・認可 Managed ID がない世界 - プログラムは Azure リソースにアクセスするためのIDとパスワード、アクセスキーやSASといった認証 情報を持ってる必要がある ID: admin PW: ****** アクセス Azure リソース プログラム 

8 © Sansan, Inc. Managed ID を使った Azure リソースの認証・認可 Managed ID がある世界 - Managed IDのおかげでプログラムは認証情報を持つことなく Azure リソースにアクセス可能 - Azure RBAC によってリソースに対する細かいアクセス制御も可能になる Azure リソース プログラム Managed ID Entra ID アクセス アクセストークン アクセストークン を要求 ※詳細なフローは https://learn.microsoft.com/ja- jp/entra/identity/managed-identities- azure-resources/managed-identity-best- practice-recommendationsを参照 リソースに対する ロール 

9 © Sansan, Inc. Managed ID (MID) 項⽬ System Assigned (システム割り当て) User Assigned (ユーザー割り当て) ライフサイクル - リソースと1:1で紐づき、リソースを削除するとIDも⾃動的 に消える - リソースグループ単位で独⽴して存在し、リソース削除でも IDは残る (別リソースで再利⽤可能) 割り当て⽅法 - 1つのリソースにのみ 割り当てられる (⾃動⽣成される) - 複数リソース が同じUser Assigned Managed IDを共有して利 ⽤できる 利⽤シナリオ - シンプルな構成でリソース削除時にIDも同時消滅してよい 場合 - ⼩規模プロジェクト - ⼤規模環境で複数リソースに共通IDを使いたい場合 - 別リソースに移⾏する可能性がある場合 命名・管理⽅法 - Azure が⾃動⽣成したID (GUID) を使⽤ - ユーザーが名前を指定できない - 作成時に⾃由に名前を付けられ、Azureポータル・CLI 上で⼀ 覧管理 可能 メリット - 設定が簡単 (ワンクリック/数⾏のIaC) - リソースごとのID管理が楽 - 再利⽤可能 - 複数環境でIDを共有しやすい - ユースケースや満たしたいセキュリティ要件に応じてIDを作 成することで論理的にグルーピングされたAzure RBACを設計 できる デメリット - リソースを削除するとIDも消えるため、再利⽤/代替が難し い - 複数リソースで同じIDを使えない - それぞれのIDにAzure RBAC を設定する必要がある - 事前にUser Assigned Managed IDの作成作業が必要 - 管理者が増えるとIDが⼤量に作成され、命名・整理が必要 - サポートされてないリソースも存在する Managed ID には System Assigned と User Assigned の2種類ある System Assigned はリソースとIDが1:1対応、User Assigned は複数リソースに対して ID を共有できる 

10 © Sansan, Inc. Managed ID (MID) 4つの VM に Storage Account と Key Vault への読み取り権限を付与したいケース System Assigned だと必要な権限⾃体は2つだけなのに8つ ID への紐づけが必要になる https://learn.microsoft.com/ja-jp/entra/identity/managed-identities-azure-resources/managed-identity-best-practice-recommendationsより画像を引用 

11 © Sansan, Inc. Managed ID (MID) 4つの VM に Storage Account と Key Vault への読み取り権限を付与したいケース User Assigned だとひとつの ID に2つロールを付与するだけで済む https://learn.microsoft.com/ja-jp/entra/identity/managed-identities-azure-resources/managed-identity-best-practice-recommendationsより画像を引用 

Sansan Data Hub での活⽤事例 

13 © Sansan, Inc. 課題設定: Azure SQL DB に対するアクセスを UMID 化 - Sansan Data Hub では基本的に User Assigned Managed ID (UMID) によっ て Azure リソースにアクセスしている - しかし、App Service から SQL DB へのアクセスはID / パスワードによる認 証になっていた - 正確には接続⽂字列は Key Vault に格納しており、Key Vault 参照にしていた - しかし、実際には App Service 環境変数に展開されるため、開発者向けツール Kudu を使⽤すれば、開発者が接続⽂字列内の認証情報を閲覧できてしまう →これはセキュリティ上のリスクがある 

14 © Sansan, Inc. 課題設定: Azure SQL DB に対するアクセスを UMID 化 やったことは 1. ⽤途に応じたUMID を設計・作成 2. 作成した UMID を各リソースに紐づけ 3. 接続⽂字列を修正することで UMID 認証に変更 と、並べてみると単純そうなんですけど、意外とややこしくて⾯倒でした…… 

15 © Sansan, Inc. ややこしかった点1⃣: SQL DB アカウントの多段構造の理解 SQL DB の「アカウント」には2種類ある 1. ログイン (Login) - SQL Server (論理サーバ) 全体に対する認証アカウント 2. データベースユーザー (Database User) - 特定 DB 内における認証アカウント →それぞれの違いや、それらが Entra IDとどのように関連するのかを理解するのが ややこしかった 

16 © Sansan, Inc. ややこしかった点2⃣: Sansan Data Hub 固有の事情 Sansan Data Hub には開発 (dev)、ステージ (stg)、本番 (prod) と環境が 3⾯あり、SQL DB も UMID も環境ごとに存在する →環境ごとに UMID が異なるので、共通のマイグレーションSQLスクリプトは使えない 利⽤ユーザーが増えるたびに DB をプロビジョニングするフローになっている →プロビジョニングは⼈⼿ではなく、⾃動化しておきたい ⾃動化するので CREATE USER ** FROM EXTERNAL PROVIDER を実⾏する際に SQL Server に紐 づく UMID に Graph API の権限が必要だけど、その権限を付与できるのはセキュリティ管理部⾨の み →簡単な検証をするにも他部署とのやり取りが必要だし、セキュリティ管理部⾨の⽅は往々にして 忙しい 

17 © Sansan, Inc. 最終的な構成 UMID SQL Server⽤ID DB User: アプリ⽤ID DB のプロビジョニング 及び CREATE USER `アプリ用ID` FROM EXTERNAL PROVIDER の実行 プロビジョニング⽤ID 管理者グループ Microsoft Entra admin UMID プロビジョニング⽤ID Graph API を使うことで UMID に関して問い合わせを⾏う DBをプロビジョニング する処理 UMID アプリ⽤ID 各アプリケーション DB の読み書き SQL Server SQL DB 

18 © Sansan, Inc. 最終的な構成 UMID 名 ⽤途 割り当て先 付与するロール 補⾜ SQL Server ⽤ID 各環境における SQL Server の Primary ID Azure SQL Database CREATE USER ** FROM EXTERNAL PROVIDERを実⾏時に Graph API 経由で Entra ID に問い合わせるので、 Graph API に対する権限 が必要 プロビジョニング⽤ID DBプロビジョニング時に CREATE USER ** FROM EXTERNAL PROVIDER を実⾏するための ID DBをプロビジョニング する処理 管理者グループに⼊れ る アプリ⽤ID プログラムからDB読み書き ⽤ App Service / Function など - db_datareader - db_datawriter ※SQL DB としての権限 DB User として作成する 

19 © Sansan, Inc. User ID を割り当てた UMID の Client ID にしてやり、Authentication プロパティを変更し てあげるだけで UMID 認証になる 接続⽂字列 // Before Server=tcp:{serverName},1433;Initial Catalog={dbName}; User ID={user};Password={password}; Encrypt=True;Trust Server Certificate=False;Connect Timeout=xx; Before // After Server=tcp:{serverName},1433;Initial Catalog={dbName}; User ID={アプリ用IDのClientID}; Encrypt=True;Trust Server Certificate=False;Connect Timeout=xx; Authentication=ActiveDirectoryDefault After 

20 © Sansan, Inc. Authentication プロパティにもいくつか選択肢があって、今回はローカル開発でも同じコードを使いか ったので`Active Directory Default`を採⽤ 接続⽂字列 指定できる値※ 概要 メリット デメリット Active Directory Managed Identity Managed ID を使う認証モード Managed IDによる確実なパスワードレス認証 ローカル環境では使えない Active Directory Default 環境に応じて認証⽅式を⾃動選択してくれる モード ⾃動で認証⽅式を選択してくれるのでローカ ル開発も楽 どの認証⽅式が選ばれるか不明確 Active Directory Interactive 実⾏時に対話的に認証するモード 対話的に認証できるので直感的 ⾃動化できない Active Directory Password Entra ID のユーザー名とパスワードによる認 証モード MID の設計をすることなくシンプルに認証で きる パスワード管理が必要 漏洩リスク Active Directory Service Principal クライアントIDとシークレットによるサービ スプリンシパルでの認証モード MID の設計をすることなくシンプルに認証で きる シークレットの管理が必要 漏洩リスク ※他にもあります。詳細はhttps://learn.microsoft.com/en-us/sql/connect/ado-net/sql/azure-active-directory-authentication?view=sql-server-ver16#setting-microsoft-entra-authentication 参照 

21 © Sansan, Inc. 補⾜:アクセストークン取得の流れ https://learn.microsoft.com/ja-jp/entra/identity/managed-identities-azure-resources/managed-identity-best-practice-recommendationsより画像を引⽤ 

クロージング 

23 © Sansan, Inc. - Azure リソース (SQL Database) へのアクセスを Managed ID を活⽤す ることでパスワードレスに実現できた - User assignend Managed ID を活⽤することで、Azure リソースとの接 続をよりシンプルかつセキュアにできる - 「今だったらこうする…」教訓的な気づき - 環境ごとに Identity 名を変えなくてよかったかもしれない - Subscription 単位で環境を分ているのだから、統⼀した Identity 名で設計す るほうがシンプル まとめ 

No content