Azure でのクラウド規模の分析の認証
認証は、ユーザーまたはアプリケーションの ID を検証するプロセスです。 ID 管理と認証を処理する単一のソース ID プロバイダーをお勧めします。 このプロバイダーは、ディレクトリ サービスと呼ばれます。 これにより、ディレクトリ データを保存し、このデータをネットワーク ユーザーと管理者が利用できるようになります。
どのデータ レイク ソリューションも、既に使用されているディレクトリ サービスを使用し、これに統合する必要があります。 ほとんどの組織にとって、Active Directory は、すべての ID 関連サービスのためのディレクトリ サービスです。 これは、すべてのサービスおよびユーザー アカウントを一元管理するプライマリ データベースです。
クラウドでは、Microsoft Entra ID は、一元化された ID プロバイダーであり、ID 管理の優先ソースです。 認証と認可を Microsoft Entra ID に委任すると、ユーザーが特定の場所にいる必要がある条件付きアクセス ポリシーなどのシナリオが可能になります。 多要素認証がサポートされ、アクセス セキュリティのレベルが向上されます。 可能な場合は、Microsoft Entra 統合を使用してデータ レイク データ ストア サービスを構成します。
Microsoft Entra ID をサポートしていないデータ サービスの場合、認証にアクセス キーまたはトークンを使用します。 クライアントでは、アクセスキーを Azure Key Vault などのキー管理ストアに保存する必要があります。
クラウド規模の分析の認証シナリオについて説明します。
- ユーザー認証
- アプリケーションとサービス間認証
ユーザー認証
データ サービスまたはリソースに接続するユーザーは、資格情報を提示する必要があります。 この資格情報は、ユーザーが主張している人物であることを証明します。 この後、ユーザーはサービスやリソースにアクセスできるようになります。 認証により、サービスがユーザーの ID を認識することもできます。 サービスでは、ID の検証後にユーザーが表示および実行できることを決定します。
Azure Data Lake Storage Gen2、Azure SQL Database、Azure Synapse では、Microsoft Entra 統合がサポートされます。 対話型ユーザー認証モードでは、ユーザーはダイアログ ボックスに資格情報を入力する必要があります。
重要
認証の目的で、ユーザーの資格情報をアプリケーションにハード コーディングしないでください。
アプリケーションとサービス間認証
これらの要求は特定のユーザーに関連付けられません。また、資格情報を入力できるユーザーはいません。
サービス間認証
サービスでは、ユーザーの操作なしに別のサービスにアクセスする場合でも、有効な ID を提示する必要があります。 この ID は、サービスが本物であることを証明します。 アクセスされたサービスでは、ID を使用することにより、サービスで実行できることを決定できます。
サービス間認証の場合、Azure サービスを認証するための方法として、マネージド ID の使用をお勧めします。 Azure リソース用マネージド ID を使用すると、明示的な資格情報を使用することなく、Microsoft Entra 認証をサポートするすべてのサービスに対して認証を行うことができます。 詳細については、「Azure リソース用マネージド ID とは」を参照してください。
マネージド ID はサービスプリンシパルであり、Azure リソースでのみ使用できます。 たとえば、マネージド ID は、Azure Data Factory インスタンスに対して直接作成できます。 このマネージド ID は、Microsoft Entra ID に登録されるオブジェクトです。 これは、このデータ ファクトリ インスタンスを表します。 この ID を使用して、コードで資格情報を指定せずに、Data Lake Storage などの任意のサービスに対する認証を行うことができます。 サービス インスタンスで使用される資格情報は、Azure によって処理されます。 ID は、Azure Data Lake Storage 内のフォルダーなどの Azure サービス リソースに対する認可を付与できます。 このデータ ファクトリ インスタンスを削除すると、Azure により、Microsoft Entra ID 内の ID がクリーンアップされます。
マネージド ID を使用するベネフィット
Azure サービスを別の Azure サービスまたはリソースに対して認証するには、マネージド ID を使用する必要があります。 これには次の利点があります。
- マネージド ID は、これを作成するサービスを表します。 対話ユーザーを表すものではありません。
- マネージド ID の資格情報は、Microsoft Entra ID で保守、管理、格納されます。 ユーザーが保持するパスワードはありません。
- マネージド ID を使用する場合、クライアント サービスでパスワードは使用されません。
- システム割り当てマネージド ID は、サービス インスタンスが削除されると削除されます。
これらのベネフィットは、資格情報の保護が強化され、セキュリティが侵害される可能性が低いことを意味します。
アプリケーションとサービス間の認証
もう 1 つのアクセス シナリオは、アプリケーションです。たとえば、Azure サービスにアクセスするモバイル Web アプリケーションなどがあります。 Azure サービスにアクセスするユーザーは誰でも、アクセサーがその ID を提供し、その ID は検証される必要があります。
Azure サービス プリンシパルは、マネージド ID をサポートしないアプリケーションやサービスが Azure リソースに対して認証を行うための代替手段です。 Azure サービス プリンシパルは、Azure リソースにアクセスするアプリケーション、ホステッド サービス、および自動化ツールで使用するために作成される ID です。 このアクセスは、サービス プリンシパルに割り当てられたロールによって制限されます。 セキュリティ上の理由から、ユーザー ID によるサインインを許可するのではなく、自動化されたツールまたはアプリケーションでサービス プリンシパルを使用することをお勧めします。 詳細については、Microsoft Entra ID プラットフォームのアプリケーションとサービス プリンシパルのオブジェクトに関するページを参照してください。
Note
マネージド ID とサービス プリンシパルは共に、Microsoft Entra ID で作成され保守されます。
マネージド ID とサービス プリンシパルの違い
| サービス プリンシパル | マネージド ID |
|---|---|
| Microsoft Entra ID で、手動で作成され、アプリケーション、サービス、ツールで特定の Azure リソースにアクセスするために使用されるセキュリティ ID。 | 特別な種類のサービス プリンシパル。 これは、Azure サービスの作成時に作成される自動 ID です。 |
| 任意のアプリケーションまたはサービスで使用できます。 これは、特定の Azure サービスに関連付けられません。 | Azure サービス インスタンス自体を表します。 他の Azure サービスを表すために使用することはできません。 |
| 独立したライフサイクルがあります。 明示的に削除する必要があります。 | Azure サービス インスタンスが削除されるときに自動的に削除されます。 |
| パスワードベースまたは証明書ベースの認証。 | 認証のために明示的なパスワードを指定することはできません。 |
データベース認証とアクセス許可
クラウド規模の分析には、ポリグロット ストレージが含まれている可能性があります。 例としては、PostgreSQL、MySQL、Azure SQL Database、SQL Managed Instance、Azure Synapse Analytics などがあります。
- PostgreSQL での認証に Microsoft Entra ID を使用する
- Azure SQL Database、SQL Managed Instance、Azure Synapse Analytics で Microsoft Entra 認証を使用する
- MySQL での認証に Microsoft Entra ID を使用する
データベース オブジェクトをセキュリティで保護するには、個々の Microsoft Entra ユーザー アカウントではなく、Microsoft Entra グループを使用することをお勧めします。 これらの Microsoft Entra グループを使用して、ユーザーを認証し、データベース オブジェクトを保護します。 データ レイク パターンと同様に、データ アプリケーションのオンボーディングを使用して、これらのグループを作成できます。
注意
データ アプリケーションでは、機密データ製品を Azure SQL Database、SQL Managed Instance、または Azure Synapse Analytics プールに格納できます。 詳細については、「機密データ」を参照してください。
クラウド規模の分析における Azure Data Lake のセキュリティ
データ レイク内のデータへのアクセスを制御するには、ファイルおよびフォルダーのレベルでアクセス制御リスト (ACL) を使用することをお勧めします。 Azure Data Lake では、POSIX と同様のアクセス制御リスト モデルも採用されています。 POSIX (ポータブル オペレーティング システム インターフェイス) は、オペレーティング システムの標準ファミリです。 1 つの標準では、ファイルやフォルダーにアクセスするためのシンプルでも強力なアクセス許可構造が定義されています。 POSIX は、ネットワーク ファイル共有や UNIX コンピューターで広く採用されています。
Azure RBAC の一般的なプラクティスと同様に、ACL には次のルールを適用する必要があります。
グループを使用してアクセスを管理する: 継続的なアクセス管理のために、Microsoft Entra グループへのアクセスを割り当て、グループのメンバーシップを管理します。 「Azure Data Lake Storage でのアクセス制御とデータ レイクの構成」を参照してください。
最小特権。 ほとんどの場合、ユーザーが持つ必要があるのは、データ レイク内の必要なフォルダーおよびファイルへの読み取りアクセス許可のみです。 Azure Data Factory で使用されるようなマネージド ID またはサービス プリンシパルには、読み取り、書き込み、実行のアクセス許可があります。 データ ユーザーに対しては、ストレージ アカウント コンテナーにアクセスできないようにする必要があります。
データ パーティション構成に合わせる: 効果的なデータ アクセス制御を確保するために、ACL とデータ パーティションの設計を合わせる必要があります。 詳細については、「データ レイク パーティション分割」を参照してください。