認証を構成する。
認証は、デジタル インフラストラクチャ内のリソースにアクセスするときに資格情報を検証するプロセスです。 これにより、環境内のサービスにアクセスする必要がある個人またはサービスが、だれであるかを証明できます。 Azure Synapse Analytics では、さまざまな認証方法が提供されています。
認証する必要があるもの
Azure Synapse Analytics に格納されているデータを保護するために認証を行う必要があることを意味するさまざまなシナリオがあります。
一般的な認証の形態は、サービス内のデータにアクセスする必要があるユーザーに関するものです。 これは通常、個人がサービスに対して認証するためにユーザー名とパスワードを提供する場合に見られます。 ただし、これは認証要求を条件付きアクセス ポリシーと組み合わせて使用することでいっそう高度化されており、追加のセキュリティ手順によって認証プロセスがさらに保護されています。
目立たないこととして、サービスがシームレスに動作できるようにするために、サービスは他のサービスで認証を行う必要があるという事実があります。 この例として、Azure Synpase Spark またはサーバーレス SQL プールを使用して、Azure Data Lake ストアのデータにアクセスすることがあります。 Azure Synapse Analytics が認証された方法でデータ レイク内のデータにアクセスできるようにするには、認証メカニズムをバックグラウンドで実行する必要があります。
最後に、ユーザーとサービスが同時に動作する場合もあります。 ここでは、ユーザーがデータにシームレスにアクセスできるようにするために、ユーザーとサービスの両方の認証を内部で行っています。 この例では、Power BI を使用して、専用の SQL プールによって処理されているダッシュボードでレポートを表示しています。 ここでは、複数のレベルの認証を管理する必要があります。
セキュリティの種類
次に、Azure Synapse Analytics を使用する場合に注意する必要がある認証の種類を示します。
Microsoft Entra ID
Microsoft Entra ID は、セキュリティで保護できるオブジェクトを一元的に管理できるディレクトリ サービスです。 オブジェクトには、ユーザー アカウントとコンピューター アカウントを含めることができます。 組織の従業員は通常、組織の Microsoft Entra テナントで自分を表すユーザー アカウントを持ち、ユーザー アカウントをパスワードと一緒に使用して、ディレクトリ内に格納されている他のリソースに対してシングル サインオンと呼ばれるプロセスを使って認証を行います。
Microsoft Entra ID には、ログインは 1 回のみでよいという利点があります。また、Microsoft Entra ID では、パススルー認証を使用して、その内部に保持されている情報に基づき、他のリソースへのアクセスが管理されます。 あるユーザーと、Azure Synapse Analytics のインスタンスが同じ Microsoft Entra ID に含まれている場合、そのユーザーは明白なログインを行わずに Azure Synapse Analytics にアクセスすることができます。 管理者は Azure Synapse Analytics の専用 SQL プールにアクセスするためのユーザーの認可を付与するため、適切に管理されていればこのプロセスはシームレスです。
このような状況では、Azure 管理者がユーザー アカウントを作成し、Microsoft Entra ID の適切なロールとグループにこれらを割り当てるのが普通です。 次に、データ エンジニアは専用の SQL プールにアクセスするために、ユーザーまたはユーザーが属するグループを追加します。
マネージド ID
Azure リソースのマネージド ID は、Microsoft Entra ID の機能です。 この機能では、Microsoft Entra ID で自動的に管理される ID が Azure サービスに提供されます。 マネージド ID 機能を使用して、Microsoft Entra 認証をサポートする任意のサービスに対して認証を行うことができます。
Azure リソースのマネージド ID は、以前のマネージド サービス ID (MSI) の新しい名前です。 ワークスペースを作成すると、Azure Synapse ワークスペースに対して、システムによって割り当てられたマネージド ID が作成されます。
さらに Azure Synapse では、マネージド ID を使用してパイプラインを統合します。 マネージド ID のライフサイクルは、Azure Synapse ワークスペースに直接関連付けられています。 Azure Synapse ワークスペースを削除すると、マネージド ID もクリーンアップされます。
ワークスペース マネージド ID には、パイプラインで操作を実行するためのアクセス許可が必要です。 アクセス許可を付与するときに、オブジェクト ID または Azure Synapse ワークスペース名を使用してマネージド ID を見つけることができます。
Azure portal でマネージド ID を取得できます。 Azure portal で Azure Synapse ワークスペースを開き、左側のナビゲーションから [概要] を選択します。 マネージド ID オブジェクト ID がメイン画面に表示されます。
マネージド ID 情報は、マネージド ID 認証をサポートするリンクされたサービスを Azure Synapse Studio から作成するときにも表示されます。
Azure Synapse Studio を起動し、左側のナビゲーションから [管理] タブを選択します。 次に、 [リンクされたサービス] を選択し、 [+ 新規] オプションを選択して、新しいリンクされたサービスを作成します。
[新しいリンクされたサービス] ウィンドウで、「Azure Data Lake Storage Gen2」と入力します。 リストから [Azure Data Lake Storage Gen2] のリソースの種類を選択し、 [続行] をクリックします。
次のウィンドウで、 [認証方法] として [マネージド ID] を選択します。 マネージド ID の名前とオブジェクト ID が表示されます。
SQL 認証
Microsoft Entra ID に含まれていないユーザー アカウントの場合、SQL 認証を使用する方法もあります。 このインスタンスでは、ユーザーは専用 SQL プールのインスタンスに作成されます。 問題のユーザーに管理者アクセスが必要な場合は、ユーザーの詳細がマスター データベースに保持されます。 管理者アクセス権が不要な場合、特定のデータベースにユーザーを作成できます。 その後、ユーザーは Azure Synapse Analytics 専用 SQL プールに直接接続し、このときユーザー名とパスワードを使用してサービスにアクセスするように求めるメッセージが表示されます。
この方法は通常、データにアクセスする必要がある外部ユーザー、または Azure Synapse Analytics 専用 SQL プールに対してサード パーティまたはレガシのアプリケーションを使用している場合に便利です。
多要素認証
Synapse SQL では、Active Directory ユニバーサル認証を使用して、SQL Server Management Studio (SSMS) からの接続をサポートしています。
これで、ポリシーの一環として多要素認証を適用する条件付きアクセス ポリシーが使用されている環境で仕事をすることができます。
[キー]
Azure Data Lake などのリソースにアクセスするためにマネージド ID を使用できない場合は、ストレージ アカウント キーと共有アクセス署名を使用できます。
ストレージ アカウント キーを使用して。 Azure では、作成するストレージ アカウントごとにこれらのキーのうち 2 つ (プライマリとセカンダリ) が作成されます。 キーにより、アカウント内のすべてのものにアクセスできるようになります。 ストレージ アカウント キーは、Azure portal のストレージ アカウントのビューで見つかります。 [設定] を選択し、[アクセス キー] をクリックします。
ベスト プラクティスとして、ストレージ アカウント キーを共有しないでください。Azure Key Vault を使用してキーを管理し、セキュリティで保護することができます。
Azure Key Vault は、アプリ シークレット、つまりパスワードや接続文字列など常時保護する必要がある構成値を格納する一元的なクラウド サービスであるシークレット ストアです。 Key Vault はシークレットの管理を支援します。アプリのシークレットが中央の 1 か所に保存され、アクセスがセキュリティで保護され、アクセス許可が制御され、アクセスがログに記録されます。
Key Vault を使用する主な利点は次のとおりです。
- 機密性の高いアプリの情報を他の構成やコードから分離し、偶発的なリークのリスクを軽減する
- アプリとそれを必要とする個人に合わせて作成されたアクセス ポリシーを使用して、シークレットのアクセスを制限する
- 一元化されたシークレット ストレージにより、必要な変更を 1 か所で行うことが可能となる
- アクセスをログに記録して監視することで、シークレットにいつどのようにアクセスされたかを把握するのに役立つ
シークレットは個々のコンテナーに格納されています。これは、シークレットをグループ化するために使用される Azure リソースです。 シークレットのアクセスとコンテナー管理は、REST API を使用して行われます。これは、すべての Azure 管理ツールと多くの主要言語で使用可能なクライアント ライブラリでもサポートされています。 すべてのコンテナーには、その API がホストされている一意の URL があります。
共有アクセス署名
外部のサード パーティ製アプリケーションが内部のデータにアクセスする必要がある場合は、ストレージ アカウント キーを使わずに接続を保護する必要があります。 信頼されていないクライアントの場合は、Shared Access Signature (SAS) を使用します。 Shared Access Signature は、URI に添付できるセキュリティ トークンを含む文字列です。 Shared Access Signature を使用して、ストレージ オブジェクトへのアクセスを委任し、アクセス許可やアクセスの時間範囲などの制約を指定します。 顧客に共有アクセス署名トークンを付与できます。
Shared Access Signature の種類
"サービス レベル" の Shared Access Signature を使用すると、ストレージ アカウント内の特定のリソースへのアクセスを許可できます。 たとえば、ファイル システム内のファイルのリストの取得や、ファイルのダウンロードをアプリに許可するには、この種の Shared Access Signature を使います。
"アカウント レベル" の Shared Access Signature を使用すると、サービス レベルで許可できるすべてのものに加えて、他のリソースや機能へのアクセスを許可できます。 たとえば、アカウント レベルの Shared Access Signature を使用すると、ファイル システムの作成を許可できます。