ビッグデータの権限とセキュリティ

ビッグデータの権限とセキュリティ

1. 権限の概要

1.1. ビッグデータプラットフォームにおける権限管理と制御の現状

権限の管理と制御は、ビッグ データ プラットフォームにおいて常に最も厄介な問題の 1 つです。管理が厳しければ業務がスムーズに行かず利用者に不満が生じ、管理が甘いとセキュリティが確保されません。また、ビッグデータプラットフォームには多くのコンポーネントやサービスがあり、アーキテクチャやプロセスが複雑で、管理したくても管理できない場合もあります。

権限の制御、どこまでやるか、どのように行うか、そしてどれくらいのコストがかかるかは、目標の出発点によって異なります。アクセス許可制御の目標は、ユーザーの通常のビジネス行動の範囲を制限し、機密データを制御し、ビジネス ロジックとプロセスを制限することです。ユーザーに対する不必要なアクセス許可を削減することで、被害を受ける領域を減らし、ビジネス リスクの可能性を軽減し、また明確化を促進します。ユーザーの権利と責任。

1.2. 権限の管理と制御のための技術的ソリューション

関連する技術ソリューションには、Kerberos、LDAP、Ranger、Sentry、ACL が含まれ、各コンポーネントの権限管理および制御ソリューションと権限制御の目標が含まれます。

1.3. 権限の管理と制御の手順

権限管理には認証と認可の 2 つのステップがあり、前者は ID を認証し、後者は ID に基づいて権限を付与します。

認可プロセスでは、権限の一元管理をどのように実行するか、ユーザーが個別に権限を申請できるようにする方法、プラットフォーム管理者ではなく特定のビジネス リーダーに権限の管理を引き渡す方法、さまざまなコンポーネントを区別する方法が含まれます。ユーザー間の権限関係を確立します。

ユーザー ID 認証プロセスでは、権限構築の現在の主要なターゲット プロセスを分析し、適切な権限テクノロジ ソリューションを選択する必要があります。

2. 許可スキーム

2.1. 権利管理のための技術ソリューションの概要

権限管理に関連する作業は、次の 2 つの部分に分けることができます。

• ユーザー ID の管理、つまりユーザー ID 認証 (Authentication)
• ユーザーのアイデンティティと権限、つまり認可（Authorization）のマッピング関係管理

ユーザー ID 認証の場合、Hadoop エコシステムの一般的なオープン ソース ソリューションは Kerberos+LDAP です。認可の場合、一般的なソリューションには Ranger、Sentry など、およびゲートウェイ プロキシ サービスを使用する Knox などのソリューションが含まれます。

2.2、ケルベロス

Kerberos は、Hadoop エコシステムで最も広く使用されている集中型の統合ユーザー認証管理フレームワークです。

2.2.1. ワークフロー

集中認証サーバーの提供: さまざまなバックグラウンド サービスはユーザーの ID を直接認証せず、サードパーティ サービスの Kerberos を通じて認証します。ユーザーの ID と鍵情報は、Kerberos サービス フレームワークで一元管理されます。これにより、さまざまなバックグラウンド サービスがこの情報を管理したり、自身を認証したりする必要がなくなり、ユーザーは自分の ID とパスワード情報を複数のシステムに登録する必要がなくなります。

2.2.2. 原則

1. Kerberos は、パスワードではなくチケットに基づいて ID 認証を実装します。クライアントがローカル キーを使用して KDC から返された暗号化されたチケットを復号化できない場合、認証は失敗します。
2. クライアントは、認証サービス、チケット認可サービス、ターゲット サービスと順番に対話し、合計 3 つの対話を行います。
3. クライアントが他のコンポーネントと対話するとき、クライアントは 2 つの情報を取得します。1 つはローカル キーを使用して復号化できますが、もう 1 つは復号化できません。
4. クライアントがアクセスしたいターゲット サービスは、KDC と直接対話しませんが、クライアントのリクエストが正しく復号化できるかどうかによって認証されます。
5. KDC データベースには、すべてのプリンシパルに対応するパスワードが含まれています。
6. Kerberos での情報暗号化方式は、通常、対称暗号化です (非対称暗号化として構成できます)。
   

2.2.3. 核となるアイデア

Kerberos の中心的な考え方はキーベースのコンセンサスです。中央サーバーだけがすべてのユーザーとサービスのキー情報を知っています。中央サーバーを信頼する場合は、中央サーバーによって提供される認証結果も信頼できます。

2.2.4. アプリケーションの難しさ

Kerberos は原理的には健全ですが、実装と実装が面倒です。

• すべてのバックグラウンド サービスは特に Kerberos フレームワークに接続する必要があり、すべてのクライアントも適応させる必要があります。対応するクライアント アクセス カプセル化 SDK を提供するには、バックグラウンド サービスが必要です。それ以外の場合は、Kerberos 認証プロセスに適応するようにクライアントを変更する必要があります。
• ユーザー ID 認証を真に実装するには、ビジネス リンク全体の完全な認証と配信を達成する必要があります。クライアントが単一のサービスに直接接続することは大きな問題ではありませんが、ビッグ データ プラットフォーム サービスの階層型プロキシやクラスターのマルチノード展開のシナリオでは、ユーザー ID 認証を必要とするリンク シリーズ接続はそれほど単純ではありません。 。
• ユーザーは、開発プラットフォームを通じて Hive スクリプト タスクを送信します。タスクは、最初に開発プラットフォームによってスケジューリング システムに送信され、次にスケジューリング システムによって Hive サーバーに送信されます。その後、Hive サーバーは実行のためにそれを Hadoop クラスターに送信します。 。各上流コンポーネントは、下流コンポーネントに対してユーザーを認証する必要があります。
• Hadoop クラスター上で実行されている MR タスクの場合、この認証関係チェーンを渡す必要があります。各リンクで Kerberos ベースの認証をサポートしたい場合は、秘密キーの送信を正しく処理するか、ユーザーのプロキシ メカニズムを実装する必要があります。
• ID 認証のタイムアウトの問題、キー情報のストレージと機密性の問題など。たとえば、MR タスクが途中でキーまたはトークンの有効期限が切れた場合はどうすればよいですか? タスクは中断できません。
• パフォーマンスの問題に関しては、集中管理はある程度単一点を意味しますが、各 RPC リクエストが Kerberos ユーザー認証プロセスを完了する必要がある場合、応答遅延、同時実行性、およびスループット能力が比較的大きな問題になります。

2.2.5. 使用シナリオ

一般に、Kerberos は現在最も効果的で完全な統合 ID 認証フレームワークですが、完全に実装するとコストが高くなります。ユーザー ID 認証は権利管理プロセスのほんの一部にすぎず、技術的には困難ですが、実際の影響を考慮すると、通常は合理的な権利モデルと標準化された管理プロセスがデータ セキュリティの鍵となります。

• 企業ネットワークにおけるユーザー認証とシングル サインオン。
• 分散システムにクロスドメインのユーザー認証と認可を実装します。
• クラウド環境でユーザーとサービス間の安全な通信を確保します。

2.3、レンジャー

2.3.1. 概要

Apache Ranger は、一元化されたセキュリティ管理フレームワークを提供し、承認と監査に対処します。HDFS、Yarn、Hive、Hbase などの Hadoop エコロジカル コンポーネントに対してきめ細かいデータ アクセス制御を実行できます。管理者は Ranger コンソールを操作することで、ユーザーのアクセス権限を制御するポリシーを簡単に設定できます。

2.3.2. レンジャーアーキテクチャ

Rangerは主に以下の3つのコンポーネントで構成されています

• Ranger Admin: Ranger Admin は Ranger のコア モジュールです。Web 管理ページが組み込まれており、ユーザーはこの Web 管理インターフェイスまたは REST インターフェイスを通じてセキュリティ ポリシーを策定できます。
• エージェント プラグイン: エージェント プラグインは、Hadoop エコロジカル コンポーネントに組み込まれたプラグインで、Ranger Admin から定期的にポリシーを取得して実行し、監査のために操作記録を記録します。
• ユーザー同期: ユーザー同期は、オペレーティング システムのユーザー/グループ (ユーザー/グループ) の権限データを Ranger データベースに同期します。
  

2.3.3. レンジャーのワークフロー

2.3.4. 使用シナリオ

1、HDP

Hortonworks Data Platform に含まれる Apache Ranger は、ポリシーを使用して、Hive、HBASE、HDFS などの Hadoop コンポーネントに対するきめ細かいアクセス制御と監査を提供します。

2、アパッチレンジャー

Apache Ranger 公式 Web サイトはソース パッケージ版であり、バイナリ インストール パッケージは提供されていないため、Maven でコンパイルし、自分でデプロイおよびインストールする必要があります。

2.4、見張り

2.4.1. 概要

Apache Sentry は、Cloudera によってリリースされた Hadoop オープン ソース コンポーネントであり、きめ細かいロールベースの認証とマルチテナント管理モデルを提供します。
Sentry は、Hadoop クラスター上の認証されたユーザーとアプリケーションのデータに対する正確なレベルのアクセス許可を制御および強制する機能を提供します。Sentry は現在、Apache Hive、Hive Metastore/HCatalog、Apache Solr、Impala、および HDFS (Hive テーブル データのみ) で動作します。

2.4.2. セントリーでの役割

• オブジェクト: 保護されたオブジェクト
• 特権: オブジェクトへのアクセス権
• 役割: 権限の集合
• ユーザー: ユーザー
• グループ: ユーザーの集合
  

2.4.3. 使用シナリオ

1、CDH

2.5、ノックス

2.5.1. 概要

Apache Knox Gateway は、Apache Hadoop デプロイメントの REST API および UI と対話するためのアプリケーション ゲートウェイです。Knox Gateway は、Apache Hadoop クラスターとのすべての REST および HTTP 対話に単一のアクセス ポイントを提供します。

2.5.2. 提供されるサービス

Knox は、次の 3 つのユーザー向けサービスを提供します。

• プロキシ サービス: Apache Knox プロジェクトの主な目標は、HTTP リソースをプロキシすることによって Apache Hadoop へのアクセスを提供することです。
• 認証サービス: USTAPI アクセスと UIS の WebSSO フローを認証します。LDAP/AD、ヘッダーベースの PROAUTH、Kerberos、SAML、OAUTH はすべて利用可能なオプションです。
• カスタマー サービス: クライアントの開発は、DSL によるスクリプト作成、または SDK として Knox Shell クラスを直接使用して行うことができます。
  

2.5.3. 使用シナリオ

• クラスターへのすべてのユーザーの Rest/HTTP リクエストは、Knox プロキシを介して転送されます。これはプロキシであるため、転送プロセス中に一部の ID 認証と権限検証の管理作業を実行できます。これは Rest/HTTP サービスのみを対象としているため、は完全な権利管理フレームワークではありません。
• ゲートウェイ モデルの使用には、シングル ポイント、パフォーマンス、プロセスなどの大きな制限がありますが、Rest/HTTP シナリオに適合すると考えることができます。その利点は、Hadoop 関連サービスへの入り口を閉じることで Hadoop クラスターのトポロジー ロジックを隠蔽できることです。また、権限認証管理をサポートしていないサービスに対して、ゲートウェイは独自に権限制御のレイヤーを重ねることもできます。

3. 権限モデル

3.1. 概要

• 権限制御は、権限制限として理解できます。つまり、異なる人は異なる権限を持っているため、異なるものを表示および使用する可能性があります。アプリケーション システムに応じて、ユーザーは異なるデータ権限 (参照) と操作権限 (使用) を持つ場合があります。
• 基本的に、アクセス許可管理モデルの種類に関係なく、ユーザー、システム/アプリケーション、ポリシーという 3 つの基本要素を抽象化できます。
• オープンソース プロジェクトにおける一般的なアクセス許可モデルの概念: RBAC/ACL/POSIX/SQL 標準。

3.2. RBAC モデル

3.2.1. 概要

「user-role-permission」の許可ロジックは、業界で一般的に使用されている RBAC (Role-Based Access Control) 許可モデルです。その核心は、ロールの概念を導入し、ロールを仲介者として使用して、ユーザーと権限の構成をより柔軟にすることです。

3.2.2. RBAC モデルの適用

• RBAC はロールベースのアクセス制御であり、ユーザーのロールを権限に関連付けることによってシステム リソースへのアクセス制御を実装します。
• RBAC には柔軟性、拡張性、セキュリティという利点がありますが、実装が難しく、管理者に高い技術レベルが求められます。
• RBACを実装する場合は、ロール、権限、リソース、アクセス制御ポリシーなどに基づいて定義し、仕様に従って適用する必要があります。
  

3.3. POSIXモデル

3.3.1. 概要

POSIX 権限モデルは、Linux システムのファイル システム権限に似た、ファイルベースの権限モデルです。つまり、ファイルには対応する OWNER と GROUP があり、OWNER、GROUP、およびその他のユーザーのアクセス許可の設定のみをサポートできます。許可されたアクセス許可には、読み取り、書き込み、および実行のアクセス許可のみが含まれます。

3.3.2. POSIXモデルの適用

このモデルはエンタープライズ ユーザーには適していません。明らかな欠点は、グループが 1 つしかなく、異なるグループを実装して異なる権限を持たせることができず、洗練された権限管理も実現できないことです。ファイル レベルでのみ承認でき、許可されたアクセス許可も制限されており、読み取り、書き込み、実行のアクセス許可のみです。

3.4. ACL モデル

3.4.1. 概要

アクセス制御メカニズムである ACL (Access Control List) アクセス制御リストには、主にユーザー (User)、リソース (Resource)、および操作 (Operate) の 3 つの主要な要素が含まれています。ユーザーがリソースの操作を要求すると、リソースの権限リストがチェックされ、リソースの権限リストにユーザーの操作権限が存在する場合は許可され、存在しない場合は拒否されます。

3.4.2. ACL モデルの適用

ACL は Access Control List の略で、ACL 権限モデルは POSIX 権限モデルの欠点を補い、より洗練された権限管理を実現します。アクセス制御リストを設定すると、1 人のユーザーに複数の権限を付与したり、異なるユーザーに異なる権限を付与したりできます。ただし、ACL には明らかな欠点もあります。ユーザーの数が増えると、ACL リストが大きくなり、保守が困難になります。この問題は、特に大企業で顕著です。

3.5. SQL 標準権限モデル

3.5.1. 概要

SQL 標準モデルは、Hive/Spark 使用許可モデルの 1 つであり、基本的に SQL 認可構文を使用して許可を管理します。Hive の権限モデルも ACL および RBAC モデルに基づいています。これは、個々のユーザーが直接またはロールを通じて権限を付与できることを意味します。

3.5.2. SQL 標準モデルの適用

SQL 標準権限モデルは、モデルの観点から見ると ACL モデルと基本的には異なりません。SQL に似た構文を使用してシステム内のユーザーと対話するために、MySQL などの従来のデータベースの標準認可構文を模倣しているだけです。

4. データセキュリティ

4.1. データセキュリティが直面するリスクとプレッシャー

4.1.1. 企業の内部監督

現在、企業にはデータセキュリティのための技術的手段や効果的な管理システムが不足しており、データ漏洩のリスクが増大しています。
もう一つは、社内従業員のセキュリティ意識の不足によるデータ情報の漏洩です。

4.1.2. 外部の法的およびコンプライアンスの要件

国内外の政府や業界は情報セキュリティを非常に重視しているため、関連する法規制や管理システムが制定され、データセキュリティの強化とより詳細なセキュリティ要件が常に求められています。例えば、我が国の「中華人民共和国サイバーセキュリティ法」は2017年6月に正式発効し、EUの「一般データ保護規則」（GDPRと呼ばれる）は2018年5月に発効し、中国のGB/Tは35273 2018年5月施行の「情報セキュリティ法」 個人情報セキュリティ技術仕様書など

4.1.3. データ漏洩のリスク

IT テクノロジーが進化し続けるにつれて、データ漏洩につながるリスク経路は増加し続けており、データ漏洩のリスクが増大しています。
悪意のある攻撃のリスクが高まっていることも側面です。

4.1.4. データセキュリティの現状と問題点

データ セキュリティの観点から、さまざまな業界や企業が直面しているセキュリティ問題の一部を分析します。

1. データ資産管理の問題

データ資産管理の問題は主に次の 3 つの側面に反映されます。

• 資産状況が不明瞭
• アクセス状況が不明瞭
• 許可状況が不明瞭

データ資産の分類は継続的なプロセスであり、データとビジネスは常に変化するため、データ資産管理を実行するには自動化ツールが必要です。データ資産のセキュリティ状況を正確に把握することは、データセキュリティ体制を構築するための基本条件です。例: 保管場所、管理者、部門、分類、分類など。

2. データ管理責任の問題

データ管理の責任の問題は、主に次の 2 つの側面に反映されます。

• データ資産には責任がありません
• 管理上の役割の境界があいまいになる

データ セキュリティ管理の役割は、一般に研究開発、運用保守、セキュリティ、運用担当者によって実行されますが、独立したチームや仮想チームが存在しないため、権利と責任が不明確になり、データ セキュリティ保護機能の全体的な向上にはつながりません。データ資産管理者、データベース管理者、セキュリティ監査人、セキュリティ検出エンジニア、データ運用および保守エンジニア、権限管理者などのデータ セキュリティ管理の役割を確立することが重要です。

3. 不完全なデータシステムの問題

不完全なデータ システムの問題は、主に次の 2 つの側面に反映されます。

• システム仕様が実装されていない、または実装が困難である
• 監査手段の欠如

データ管理システムは、データセキュリティコンサルティング計画を通じて実際のシステム仕様を確立し、データセキュリティ管理部門が監査の欠如により実装状況をタイムリーに把握できないことを回避するために、データセキュリティ管理措置およびSLA評価指標を策定します。メソッド。

4. わかりにくいデータ交換管理の問題

混沌としたデータ交換管理の問題は、主に次の 2 つの側面に反映されています。

• 交換および共有の方法とインターフェースは標準ではありません
• 運用および保守担当者とアプリケーション システム マネージャーに対するデータ管理と制御のプレッシャーは高い

データは、外部、内部、およびパートナーと交換および共有されます。オープン インターフェイスがオープンになるにつれて、交換関係はますます複雑になります。交換および共有のためのメソッドとインターフェイスを標準化することで、機能の重複、複雑な呼び出し、および複数の機能の重複が回避されます。クリック ログインやその他の現象は、データ アプリケーションの開発には影響しません。

5. 点在する安全技術対策

安全技術対策の点在する問題は、主に次の 2 つの側面に反映されています。

• データセキュリティ製品には機能が細分化されている
• セキュリティ機能の島々

データセキュリティ機能の構築も組織ベースで実施し、さまざまな組織の散在的な構築を回避し、統一されたデータライフサイクルからの防御体制を確立します。

6. 不十分なデータ監査機能

データ監査機能が不十分であるという問題は、主に次の 2 つの側面に反映されています。

• 安全ルールの実効性の違い
• 違法なものや準拠した業務は監査されない

攻撃の運用追跡とパターンを監査することでセキュリティ リスクを発見でき、関連する動的な信頼メカニズムを確立できます。

4.2. データセキュリティにおけるリスクポイント

4.2.1. データセキュリティのリスクポイント

4.3. データセキュリティのライフサイクル管理

4.3.1. データセキュリティのライフサイクル管理

4.4. データセキュリティライフサイクル機能モデル

4.4.1. データセキュリティライフサイクル機能モデル

4.5. データセキュリティガバナンス

4.5.1. 多次元のデータセキュリティガバナンス

• 組織管理構築

  自社の組織構造に基づいて、上から順に経営陣、事業部門、実施部門、コンプライアンス監視・監査部門、事業部門などの関連責任を定義します。

• 標準システムと仕様構成

  データ漏洩防止のための全体的な戦略、管理方法、緊急時方法、具体的な運用手順を確立または改善します。組織内システムからの情報漏えい防止業務を支援します。

• テクニカルツールの構築

  専門的で成熟したテクノロジーを使用し、経営陣が承認した詳細な戦略を実装し、プラットフォームを介したデータ漏洩を実現し、データ漏洩を記録、警告、ブロックします。漏れを防ぐという目標を技術的に達成します。

• コア技術の全体的な実装

  データ資産管理、分類と分類、データ権利管理と監査、KMS+CA、ゼロトラスト、データ セキュリティ ゲートウェイ、データ プロファイリング、DLP、ブロックチェーン プライバシー、ウォーターマーク、TEE、フェデレーテッド ラーニング、準同型暗号化。

4.5.2. データセキュリティプラットフォーム

自社の組織構造に基づいて、上から順に経営陣、事業部門、実施部門、コンプライアンス監視・監査部門、事業部門などの関連責任を定義します。

• 標準システムと仕様構成

  データ漏洩防止のための全体的な戦略、管理方法、緊急時方法、具体的な運用手順を確立または改善します。組織内システムからの情報漏えい防止業務を支援します。

• テクニカルツールの構築

  専門的で成熟したテクノロジーを使用し、経営陣が承認した詳細な戦略を実装し、プラットフォームを介したデータ漏洩を実現し、データ漏洩を記録、警告、ブロックします。漏れを防ぐという目標を技術的に達成します。

• コア技術の全体的な実装

  データ資産管理、分類と分類、データ権利管理と監査、KMS+CA、ゼロトラスト、データ セキュリティ ゲートウェイ、データ プロファイリング、DLP、ブロックチェーン プライバシー、ウォーターマーク、TEE、フェデレーテッド ラーニング、準同型暗号化。

4.5.2. データセキュリティプラットフォーム