アプリケーションとミドルウェアのセキュリティを管理する
大規模な組織には、次のことを行う必要がある、さまざまなビジネス グループの複数のユーザーがいます。
- 安全な方法でクラスターにログインする
- 基になるデータへのアクセスに関して、最小限の特権の原則 (PLOP) を適用する
- セキュリティの上で重要なイベントをログに記録する。
HDInsight でのアプリケーション セキュリティの目的は、HDInsight に対して複数のユーザーを安全に認証する方法を提供すること、データに対するユーザーのアクセス権を、作業を実行するために必要な最小限のアクセス許可に制限する方法を適用すること、そして最後にセキュリティの上で重要なイベント (ログイン、特権の必要なアクションの試行、重要なレコードの変更など) をログに記録することです。
認証
認証は、ユーザーが本人であるかどうかを検証するための身元確認プロセスです。 通常、運用環境シナリオの HDInsight クラスターでは、さまざまなビジネス グループの幅広いユーザーがクラスターに対して認証を行い、ワークロードの構成、送信、実行、監視などのアクティビティを実行できるようにする必要があります。 HDInsight クラスターの作成時に "Enterprise セキュリティ パッケージ"(ESP) 機能を有効にすると、クラスターをドメインに参加させ、ドメイン ユーザーが自身のドメイン資格情報を使用してクラスターに対して認証を行うことができるようになります。 Active Directory グループを使用すると、組織内の職務または部門を表す個々のユーザーのグループを作成できます。作成時に、これらの複数のグループをクラスターに同期することができます。 クラスターには、1 人のドメイン クラスター管理者と、アクセスが制限された 1 つまたは複数のユーザー グループを用意する必要があります。 HDInsight 認証プロセスに関係するコンポーネントと関係者の図を次に示します。
Enterprise Identity ドメインの以下のコンポーネントが ESP クラスターの設定と認証プロセスに関与しています。
- Windows Server Active Directory: オンプレミスのドメイン コントローラーであり、ユーザー プリンシパル名 (別名 UPN) (例:
user@Contoso.com) とそれぞれのドメイン パスワードが格納されます。 - Active Directory Connect(AD Connect): ハイブリッド ID の設定を実現するために設計された Microsoft ツール。 パスワード ハッシュ同期などの機能は、HDInsight で ESP を設定する際に重要です。
- Azure Active Directory (Microsoft Entra ID):Microsoft Azure ベースの ID およびアクセス管理サービス。
- Azure Active Directory Domain Services (Microsoft Entra Domain Services):Windows Server Active Directory と完全に互換性のあるマネージド ドメイン サービス (ドメイン参加、グループ ポリシー、Lightweight Directory Access Protocol (LDAP)、Kerberos 認証、NTLM 認証など) が提供されます。 クラウドでドメイン コントローラーのデプロイ、管理、および修正プログラムの適用を行わなくても、これらのドメイン サービスを使用することができます。 Microsoft Entra Domain Services は既存の Microsoft Entra テナントと統合されるので、ユーザーは既存の資格情報を使用してサインインできるようになります。 さらに、既存のグループおよびユーザー アカウントを使用してリソースへのアクセスをセキュリティで保護することができます。このため、リフト アンド シフト方式でオンプレミスのリソースをよりスムーズに Azure に移行できます。
HDInsight は、2 種類の認証シナリオをサポートしています
- パスワード ハッシュが Microsoft Entra ID に同期されている場合。
- パスワード ハッシュがオンプレミスのドメイン コントローラーに保持されている場合。 ユーザーは、Windows Azure Storage Blob (WASB) または ADLS Gen2 Storage を使用して HDInsight クラスターを作成することを選択できます。その各認証プロセスにはわずかに異なる点があることに注意してください。 認証プロセスのすべての手順は自動的に実行され、ユーザーからは抽象化されていますが、ユーザーの認証までに至る一連のイベントの概要を理解するために役立ちます。
認証: パスワード ハッシュが Microsoft Entra ID に同期されている場合
- ユーザー John Doe は、ドメインの資格情報
user@contoso.onmicrosoft.com(ユーザー プリンシパル名または UPN と呼ばれます) とパスワードを使用して、HDInsight サービス (Ambari、ssh、Zeppelin など) に対して認証を行います。 ゲートウェイには、ユーザー名とパスワードを格納されています。 - リソース所有者パスワード資格情報 (ROPC) フローを使用して、ユーザーの指定した UPN とパスワードが HDInsight ゲートウェイから Microsoft Entra ID に送信され、OAuth アクセス要求が要求されます。 Microsoft Entra ID により、ユーザーの ID が確認され、資格情報サービスに保存される更新トークンが発行されます。これはヘッド ノード上で実行されます。 ADLS Gen 2 Storage アカウントを持つクラスターでは、ストレージ ドライバーが資格情報サービスと通信し、ADLS へのパススルー認証の目的で OAuth トークンが取得されます。
- 次に、ゲートウェイにより、Microsoft Entra Domain Services を使用してユーザーが認証され、Kerberos チケットが取得されます。 次に、ゲートウェイからヘッド ノードに Kerberos チケットが渡され、ユーザーがクラスターに対して認証されます。
MFA 認証: パスワード ハッシュが Microsoft Entra ID に同期されていない場合
Note
この設定は HDInsight Identity ブローカー (HIB) とも呼ばれ、多要素認証 (MFA) をサポートします。 この設定では、パスワード ハッシュが Microsoft Entra ID に同期されていない場合でも、ユーザーはゲートウェイに対して認証できます。
- ユーザー John Doe は、Ambari や Zeppelin などの Web ベースの HDInsight サービスを開始します。 このページにより、ユーザーは対話型のログイン画面にリダイレクトされます。
クライアントは、ユーザーが UPN
user@contoso.onmicrosoft.comを使用して認証できるように Microsoft Entra ID にリダイレクトされます。 - UPN を入力すると、クライアントはオンプレミスの ADFS サーバーにリダイレクトされ、そこでユーザーはパスワードを入力します。 MFA 認証が有効な場合、実行されるようになりました。 認証が成功すると、OAuth トークンがクライアントに発行されます。
- クライアントから HDInsight ゲートウェイに OAuth トークンが提示されます。
- HDInsight ゲートウェイにより、OAuth トークンを使用して HIB ノードから Kerberos チケットが取得されます。
- ゲートウェイによって Kerberos チケットが使用され、ヘッド ノードの資格情報サービスに OAuth トークンが登録され、クラスターに対して認証されます。
Note
パスワード ハッシュが Microsoft Entra ID に同期されていない場合、ドメイン ユーザーはヘッド ノードに ssh で接続できません。 ローカルの ssh ユーザーのみが ssh アクティビティを実行できます。 両方のシナリオで認証メカニズムを設定するためのガイダンスについては、「資格情報の管理に ID ブローカーを使用する」を参照してください。
承認
HDInsight での承認によって、基盤となるデータセットに対するユーザー特権の判断と適用が行われます。 特定のアクションや操作に対するきめ細かい認証は、Hive、HBase、および Kafka の HDInsight サービスで使用でき、Apache Ranger を介して管理されます。 Ranger にはロールベースのアクセス制御、属性ベースのアクセス制御の機能があり、ユーザー アクセスと管理アクションの監査が一元化されます。 通常、クラスター管理者のドメイン資格情報を使用して Apache Ranger に対する認証を行い、Ranger 上で制限されたグループまたはユーザーのポリシーを設定します。 Ranger ポリシーを作成し、Ranger のサンプル Hive テーブルにアクセス許可を設定する方法の例を次に示します。
URL
https://CLUSTERNAME.azurehdinsight.net/Ranger/を使用して Apache Ranger を起動します。 "CLUSTERNAME" はクラスターの名前に置き換えてください。 クラスター ドメイン管理者と対応するパスワードを使用してログインします。
[Add New Policy](新しいポリシーの追加) をクリックして新しい Ranger ポリシーを追加します。
次の情報を使用して、ポリシーの詳細を設定します。
- [Policy Name](ポリシー名): ポリシーの名前。
- [Database](データベース): Hive データベースを選択します。
- [Table](テーブル): 選択したデータベースの Hive テーブルを選択します。
- [Hive Column](Hive 列): ポリシーを適用する Hive 列を選択します。
- [Audit Logging](監査ログの記録) を [Yes](はい) に設定して、すべてのアクセスのログ記録を有効にします。
- [Allow Conditions]\(許可条件\):
- [Allow Conditions](許可条件) セクションで、Active Directory (AD) ドメイン ユーザーまたはドメイン グループにポリシーを適用できます。 AD グループ内のすべてのユーザーにポリシーを適用する場合は、その AD グループを [Select Group](グループの選択) セクションに追加します。
- または、個々のユーザーまたはさまざまな AD グループから選択したユーザーのセットにポリシーを適用する場合は、[Select User](ユーザーの選択) フィールドにユーザーの個々のドメイン ID をすべて追加できます。
- [Permissions](アクセス許可) チェックボックス バーの一連のアクセス許可から選択します。
下にスクロールして、[Add](追加) をクリックします。
この設定後、この規則はポリシーに含まれていたすべてのユーザーに適用されます。
HBase と Kafka の Ranger ポリシーの設定については、このセクションのそれぞれのハイパーリンクを参照してください。
監査
セキュリティの観点から説明すると、クラスターの運用期間中と、クラスターが削除された後でも、HDInsight での監査によって、発生した認証および承認要求の記録と監視が行われます。
HDInsight での監査は、Azure Monitor ログを使用して有効にします。また、クラスターのセキュリティにとって重要なログを記録するために使用できます。 クラスターのセキュリティにとって重要な情報を含むいくつかのログ テーブルを次に示します。
| ログ テーブル名 | 目的 |
|---|---|
| ranger_audit_logs_CL | ESP クラスター上の Apache Ranger からの監査ログ |
| log_gateway_audit_CL | 成功と失敗の試行を示すゲートウェイからの監査ログ |
| log_ambari_audit_CL | Ambari からの監査ログ |
| log_auth_CL | 成功と失敗の試行の SSH ログ |
Azure Monitoring は、Azure portal で数回クリックするだけで有効になります。
HDInsight クラスターで、左側のブレードにある [Azure Monitor] をクリックします。 [Azure Monitor Integration](Azure Monitor の統合) で [True] を選択し、[ワークスペースを選択してください] で、ドロップダウンから事前に作成された Log Analytics ワークスペースを選択します。
Log Analytics ワークスペースを起動し、クラスターの種類に関連する HDInsight 監視ソリューションをインポートします。 ソリューションを起動し、[ログ] をクリックします。
セキュリティに関連するログ テーブルは、左側の [カスタム ログ] セクションにあります。 次に、これらのクエリを実行して、関連するアクセス情報を抽出できます。
