SnowflakeとPower BI DesktopをSSO認証で接続する手順

はじめに

こんにちは、STS技術チームです。

普段はSnowflakeを中心としたデータ分析基盤の検証や情報発信を行っています。Power BIはMicrosoftが提供するBIツールで、Snowflakeに格納したデータをグラフや表として簡単に可視化できます。SSO（シングルサインオン）認証を使えば、パスワードを都度入力する必要がなくなり、セキュリティ面でも安心して利用できます。本記事では、「Power BI Snowflake SSO 接続手順」を知りたい方に向けて、設定方法から実際の接続手順までをわかりやすくご紹介します。

本記事でわかること

SnowflakeでPower BI用のセキュリティ統合を作成する方法
SnowflakeユーザーのログインIDをMicrosoft Entra IDのUPNに合わせて変更する方法
Power BI DesktopからSnowflakeへSSO認証で接続する手順

概要

SnowflakeはMicrosoft Entra ID（旧Azure AD）と連携したExternal OAuth認証に対応しており、Power BIからSnowflakeに接続する際、パスワードを入力せずにシングルサインオン（SSO）で接続できます。Power BI Desktopの場合、後述の手順⑦〜⑨のとおり、Snowflakeへの接続時にMicrosoftアカウントでサインインすることで、Microsoft Entra IDの資格情報を使ってSnowflakeにアクセスできます。そのため、パスワード管理の手間やセキュリティリスクを減らせます。なお、Power BI Serviceの場合はSSOを有効にする設定が別途必要になる可能性があります。

接続の流れとしては、まずSnowflake側でPower BI用のセキュリティ統合を作成し、続いてSnowflakeユーザーのログイン名をMicrosoft Entra IDのUPN（ユーザープリンシパル名）と紐づける設定を行います。その後、Power BI Desktop側でSnowflakeへの接続を行うと、SSO認証で接続できるようになります。

事前準備

設定を始める前に、以下の点を確認しておくとスムーズです。

確認項目	判断基準	詳細の参照先
ネットワークポリシー	Entra IDが使用するIPアドレス範囲（`PowerBI.<リージョン名>`）を許可リストに追加しているか	補足①／①Power BI用のセキュリティ統合を作成する[補足：Azure Government環境をご利用の場合]
デフォルトロールとWarehouse権限	接続ユーザーの`DEFAULT_ROLE`に対象Warehouseの`USAGE`権限と参照先の`SELECT`権限があるか（接続後のロール切り替えは不可）	補足②／⑩接続完了を確認する
ユーザー属性のマッピング	LOGIN_NAME／NAME／EMAILのいずれかがEntra IDのUPN属性と一致しているか	補足③／②Snowflakeユーザーのログイン名を変更する
特権ロールの扱い	ACCOUNTADMIN等を使う予定がある場合、`EXTERNAL_OAUTH_ALLOWED_ROLES_LIST`で明示的に許可する準備があるか	補足④／①Power BI用のセキュリティ統合を作成する
Power BI Desktopのバージョン	Power BI DesktopおよびSnowflakeコネクタが最新版か	–

補足①：ネットワークポリシー
Snowflakeでネットワークポリシーを使用している場合、Power BI Gatewayを使用しない構成（本記事のPower BI Desktopを含む）では、Microsoft配布のJSONファイルからPowerBI.<リージョン名>（例：東日本リージョンの場合はPowerBI.JapanEast）を検索し、addressPrefixesのIPアドレス範囲をネットワークポリシーに追加してください（許可IPアドレスには10万文字の上限あり）。複数のAzureサービス（Power BI、SCIM等）を併用している場合は、必要なIPアドレス範囲についてAzure管理者に確認してください。詳細はSnowflake公式ドキュメント「Power BI SSO to Snowflake」の前提条件／考慮事項をご確認ください。

補足②：デフォルトロールとWarehouse権限
Power BIはEntra IDトークンから特定したユーザーのDEFAULT_ROLEでセッションを確立し、接続後のロール切り替えは不可です（EXTERNAL_OAUTH_ANY_ROLE_MODEをENABLEにしていても切り替え不可）。既定ではセカンダリロール（DEFAULT_SECONDARY_ROLES）も非活性のため、必要な権限が複数ロールに分散している場合はDEFAULT_ROLE単体で満たせるように設計してください。未設定の場合、後述の手順⑦〜⑨で認証エラーや接続失敗が発生します（詳しい切り分け方法は⑩を参照）。

補足③：ユーザー属性のマッピング
本記事ではLOGIN_NAMEを使用しますが、メールアドレスを使う場合は、後述のセキュリティ統合のパラメータに'email_address'を指定します（この場合、EMAILは全ユーザーで一意である必要があります）。

補足④：特権ロールの扱い
ACCOUNTADMIN、ORGADMIN、GLOBALORGADMIN、SECURITYADMINは既定でPower BIからの接続に使用できません。使用する場合はセキュリティ統合のEXTERNAL_OAUTH_ALLOWED_ROLES_LISTパラメータで明示的に許可してください（強い権限のロールを許可する際は取り扱いに十分注意）。

なお、Azure Government環境をご利用の場合の注意点は、次の「①Power BI用のセキュリティ統合を作成する」の末尾にまとめて記載していますので、あわせてご確認ください。

Snowflake側の設定

①Power BI用のセキュリティ統合を作成する

Snowflakeで以下のクエリを実行し、Power BIとの接続に使用するセキュリティ統合を作成します。セキュリティ統合作成は、Snowflakeの「ACCOUNTADMIN」ロール、またはグローバルの「CREATE INTEGRATION」権限を持つロールでのみ実行できます。

create security integration powerbi
    type = external_oauth
    enabled = true
    external_oauth_type = azure
    external_oauth_issuer = 'https://sts.windows.net/[テナントID]/'
    external_oauth_jws_keys_url = 'https://login.windows.net/common/discovery/keys'
    external_oauth_audience_list = (
        'https://analysis.windows.net/powerbi/connector/Snowflake',
        'https://analysis.windows.net/powerbi/connector/snowflake'
    )
    external_oauth_token_user_mapping_claim = 'upn'
    external_oauth_snowflake_user_mapping_attribute = 'login_name';

※セキュリティ統合の各パラメータ値は大文字・小文字が厳密に区別されます。external_oauth_audience_listに大文字・小文字が異なる2つのURLを併記しているのは、公式サンプルが両方の併記を指示しているためです。

※external_oauth_issuerは末尾のスラッシュ（/）を含めて正確に指定してください。値がトークンのissuerクレームと一致しない場合、認証エラーになります。誤った値で作成した場合はALTER SECURITY INTEGRATIONでは修正できないため、DROP INTEGRATIONで削除したうえで、CREATE SECURITY INTEGRATIONから再作成する必要があります。なお、後述のとおりExternal OAuthセキュリティ統合は他のクライアント（Tableauなど）と共用されている場合があり、削除するとそれらの連携も停止します。削除前にDESC SECURITY INTEGRATIONで設定値を控え、共用でないことを確認してください。

[テナントID]には、Microsoft Entra IDのテナントIDを入力します。テナントIDは、Azureポータルの自社のディレクトリ（例：〇〇株式会社 – Microsoft Azure）のページから確認できます。

注意：同一issuer（テナント）に対するAzure External OAuthセキュリティ統合は、1アカウントにつき1つのみ有効になる点にご注意ください（既存の統合がある状態で同一issuerの統合を新規作成しようとするとエラーになります）。これは、Snowflakeがアクセストークンのissuerクレームからセキュリティ統合を一意に解決する仕組みによるものです。既存の統合の有無は、以下のクエリで事前に確認できます。

show integrations;

すでにMicrosoft Entra ID向けのExternal OAuthセキュリティ統合を作成済みの場合は、上記のCREATE文を実行せず、ALTER SECURITY INTEGRATION文で既存の統合にPower BI用の値を追加してください。

注意：ALTER SECURITY INTEGRATION ... SETは、指定したパラメータの値を既存の値に「追加」するのではなく、丸ごと「置き換え」ます。 そのため、既存の統合に他のクライアント（Tableauなど）向けのexternal_oauth_audience_listやexternal_oauth_jws_keys_urlが設定されている場合、そのまま以下の例を実行すると既存の値が失われ、既存の連携が動作しなくなるおそれがあります。ALTER文を実行する前に、必ず以下のクエリで現在の設定値を確認してください。

desc security integration <既存の統合名>;

確認した既存の値とPower BI用の値をすべて含めた形でALTER文を実行してください（以下は既存の値がない場合の例です。既存の値がある場合は、リストにその値も加えてください）。

-- 既存統合にPower BI用の値を追加する例（DESCで確認した既存の値を必ず残す）
alter security integration <既存の統合名> set
    external_oauth_audience_list = (
        '<DESCで確認した既存のaudience>',
        'https://analysis.windows.net/powerbi/connector/Snowflake',
        'https://analysis.windows.net/powerbi/connector/snowflake'
    )
    external_oauth_jws_keys_url = (
        '<DESCで確認した既存のキーURL>',
        'https://login.windows.net/common/discovery/keys'
    );

既存統合のexternal_oauth_token_user_mapping_claimとexternal_oauth_snowflake_user_mapping_attributeの設定値が本記事の想定（'upn'／'login_name'）と異なる場合は、既存の設定に合わせて以降の手順（②のログイン名変更など）を読み替えてください。

補足として、UPN属性値がSnowflakeユーザーのメールアドレスと一致する環境の場合は、最後の行を以下のように変更してください（この場合、EMAILは全ユーザーで一意である必要があります）。

    external_oauth_snowflake_user_mapping_attribute = 'email_address';

また、Microsoft Entra IDのB2Bゲストユーザーにも本手順でPower BI SSOを利用させたい場合は、external_oauth_token_user_mapping_claimに'unique_name'を指定してください（詳細はSnowflake公式ドキュメント「Power BI SSO to Snowflake」内の「B2B ゲストユーザーでのPower BI SSO の使用」を参照）。

補足：Azure Government環境をご利用の場合

SnowflakeアカウントまたはPower BIサービスがMicrosoft Azure Governmentクラウドリージョンにある場合は、以下の点にご注意ください。

セキュリティ統合作成時、external_oauth_audience_listの値を以下のように変更してください。
external_oauth_audience_list = ( 
    'https://analysis.usgovcloudapi.net/powerbi/connector/Snowflake', 
    'https://analysis.usgovcloudapi.net/powerbi/connector/snowflake'
 )
Power BI Desktop側で接続がうまくいかない場合は、上記の値が正しく設定されているかを確認してください。

②Snowflakeユーザーのログイン名を変更する

この設定は、対象ユーザーに対するOWNERSHIP権限を持つロール（通常はSECURITYADMINロール、またはACCOUNTADMINロール）で実行します。

Entra IDユーザーのUPN属性値と、SnowflakeユーザーのLOGIN_NAME属性値を紐づけるため、以下のクエリを実行して対象ユーザーのログイン名を変更します。ALTER USER文で指定する識別子はユーザーオブジェクトの一意な識別子であるNAME属性です。LOGIN_NAME（ログインID）とは異なる場合があるため、変更前に以下のクエリでNAMEとLOGIN_NAMEを確認してください。

show users like '%<検索文字列>%';

確認した[ユーザー名（NAME）]を指定して、以下のクエリを実行します。

alter user [ユーザー名（NAME）]
    set login_name = '[メールアドレス]';

[ユーザー名（NAME）]：SHOW USERSで確認したSnowflakeユーザーオブジェクトのNAME属性の値
[メールアドレス]：Microsoft Entra IDに登録しているメールアドレス（UPN）

本記事では、Snowflakeへのログイン時に入力する識別子を便宜上「ログインID」、SnowflakeユーザーオブジェクトのLOGIN_NAME属性を指す場合は「ログイン名（LOGIN_NAME）」、ユーザーオブジェクトの一意な識別子であるNAME属性を指す場合は「ユーザー名（NAME）」と表記して区別しています。

注意：この手順を実行すると、以降Snowflakeにログインする際のログインIDがメールアドレスに変わりますので、ご注意ください。また、複数のユーザーがPower BI経由でSnowflakeに接続する場合は、対象ユーザー全員分でこの設定が必要です（多数のユーザーに展開する場合は、SCIM連携でLOGIN_NAMEをUPNに揃える方法もあります）。

Power BI Desktop側の設定

ここからは、Power BI Desktop側でSnowflakeへ接続する手順です。事前準備で触れたとおり、Power BI Desktopは最新版を使用することをおすすめします。

③Power BI Desktopを起動する

Power BI Desktopを起動します。

④「他のソースからデータを取得する」を選択する

「ホーム」タブから「他のソースからデータを取得する」を選択します。

⑤「Snowflake」を選択して接続する

データソースの一覧から「Snowflake」を選択し、「接続」を押下します。

⑥ServerとWarehouseを入力する

「Server」と「Warehouse」を入力し、「OK」を押下します。

Server：Snowflakeの管理画面（Snowsight）に表示される「セッションの詳細」（Snowflakeコンテキスト）の「https://」以降のサーバー情報を入力します
（例：xxxxxxx.japan-east.azure.snowflakecomputing.com）
Warehouse：接続先として使用するWarehouse名を入力します
（例：ANALYTICS_WH）

⑦「Microsoft Account」でサインインする

認証方法として「Microsoft Account」を選択し、「サインイン」を押下します。

⑧Microsoftアカウントを選択する

サインイン画面で、自身のMicrosoftアカウントを選択します。

⑨「接続」を押下する

⑩接続完了を確認する

Snowflakeへの接続が完了し、テーブルが参照できることを確認します。これでPower BI DesktopからSnowflakeにSSO認証で接続する設定は完了です。

なお、接続がうまくいかない場合は、以下の点を見直してみてください（Azure Government環境をご利用の場合の注意点は、「①Power BI用のセキュリティ統合を作成する」の補足ボックスをご確認ください）。

ネットワークポリシーでMicrosoft Entra IDのIPアドレス範囲（またはPower BI Desktopからのアクセスに必要なIPアドレス範囲）が許可されているか
SnowflakeユーザーのLOGIN_NAME（またはメールアドレス）がMicrosoft Entra IDのUPNと一致しているか
使用しているロールが特権ロール（ACCOUNTADMINなど）でブロックされていないか
接続に使用したSnowflakeユーザーにDEFAULT_ROLEが設定されており、そのロールに対象WarehouseのUSAGE権限と参照したいオブジェクトへのSELECT権限があるか（Power BI経由の接続ではEXTERNAL_OAUTH_ANY_ROLE_MODEをENABLEにしていてもロールを切り替えることはできないため、必要な権限はデフォルトロールへ事前に付与しておく必要があります）

上記を確認しても解決しない場合は、以下のシステム関数でエラーの詳細を切り分けることができます。

SYSTEM$VERIFY_EXTERNAL_OAUTH_TOKEN( '<access_token>' )：
取得済みのアクセストークンを引数に渡して有効性を検証する関数で、戻り値のValidation ResultがFailedの場合、Failure Reasonに原因が入ります
SYSTEM$GET_LOGIN_FAILURE_DETAILS：
ログイン失敗時のエラーメッセージ末尾に表示されるUUIDを指定すると、EXTERNAL_OAUTH_AUDIENCE_VALIDATION_FAILEDやEXTERNAL_OAUTH_USER_CLAIM_MISSINGなど具体的なエラーコードを取得できます（MONITOR権限を持つロールでのみ実行可能です）

参考

Power BI SSO からSnowflakeへ | Snowflake Documentation

外部 OAuth 用 Microsoft Entra ID の構成 | Snowflake Documentation

CREATE SECURITY INTEGRATION （外部 OAuth） | Snowflake Documentation

ALTER SECURITY INTEGRATION （外部 OAuth） | Snowflake Documentation

ビジネスインテリジェンス（BI） | Snowflake Documentation

まとめ

本記事では、SnowflakeとPower BI DesktopをMicrosoft Entra ID（旧Azure AD）と連携したExternal OAuth認証（SSO）で接続する手順について、Snowflake側の設定からPower BI Desktop側の接続操作までご紹介しました。ポイントをまとめると、以下のとおりです。