Cloudera Data Platformのセキュリティ・リファレンス・アーキテクチャの概要

Cloudera Data Platformのセキュリティ・リファレンス・アーキテクチャの概要

セキュリティエンジニアリングのベストプラクティスの4つの柱:境界、データ、アクセス、可視性

by Niel Dunnage
この記事は、2022/01/21に公開された「Security Reference Architecture Summary for Cloudera Data Platform」の翻訳です。

このブログでは、CDP Private Cloud Base クラスタのセキュリティアーキテクチャについてまとめています。このアーキテクチャは、セキュリティエンジニアリングのベストプラクティスの4つの柱である「境界」、「データ」、「アクセス」、「可視化」を反映しています。CDP Private Cloud Base のリリースでは、以下のようなセキュリティアーキテクチャの重要な機能強化が行われました。

  • セキュリティポリシー管理のためのApache Rangerの導入
  • Ranger Key Managementサービスの更新

テクノロジーに触れる前に、多重防御を可能にする階層化のアプローチという、セキュリティの重要な原則を理解しておくとよいでしょう。各レイヤーは以下のように定義されています。

これらの多層セキュリティは、データの機密性、整合性、および可用性を確保して、最も堅牢な規制要件を満たすために適用されます。CDP Private Cloud Base は、以下の機能を実装した3つのレベルのセキュリティを提供します。

0 Non-secure セキュリティが設定されていない。Non-secure なクラスタは、あらゆる攻撃や不正アクセスに対して脆弱なため、本番環境では絶対に使用しないこと。
1 Minimal 認証、承認、監査のために構成されている。まず、認証が設定され、ユーザーやサービスが ID を証明した後にのみクラスタにアクセスできるようになる。次に、認証メカニズムを適用して、ユーザーおよびユーザーグループに権限を割り当てる。監査機能は、誰がどのようにクラスタにアクセスしたかを追跡する。
2 More 機密データは暗号化される。暗号化キーはキー管理システムで管理。メタストア内のデータに対する監査が設定されている。システムのメタデータを定期的に見直し、更新している。理想的には、データオブジェクトの系統を追跡できるようにクラスタが設定されていることである(データガバナンス)。
3 Most 安全なクラスタとは、保管中のデータと転送中のデータの両方を含むすべてのデータが暗号化され、キー管理システムがフォールトトレランスであるクラスタのことである。監査機構は、業界、政府、および規制の標準(PCI、HIPAA、NIST など)に準拠しており、クラスタから統合する他のシステムまで拡張されている。クラスタ管理者は十分なトレーニングを受けており、セキュリティ手順は専門家によって認証されており、クラスタは技術審査に合格している。

セキュリティアーキテクチャの改善

レベル3の規制基準に準拠するために、お客様は、権限を持つ管理者のみが、アプリケーションを使って CDP のコアサービスにアクセスできるようなネットワークトポロジーを構築し、アナリストや開発者のアクセスは、Hue などの適切なゲートウェイサービスと適切な管理・監視用 Web インターフェースに限定します。Apache Knox の追加により、セキュアなアクセスのプロビジョニングが大幅に簡素化され、ユーザーは堅牢なシングルサインオン(SSO)を活用できます。Apache Ranger は、タグベースのアクセスコントロール、強力な監査、既存の企業ディレクトリとの統合により、セキュリティポリシー管理を統合します。

論理アーキテクチャ

クラスタキテクチャは、以下の図のようにいくつかのゾーンに分けることができます。

境界の外側にはソースデータとアプリケーションがあり、ゲートウェイゾーンでは管理者とアプリケーションが作業を行うコアクラスタゾーンとやり取りします。これらは構成や重要な資料を管理するデータ層によってサポートされます。各ゾーンのサービスは、Kerberos とトランスポート・レイヤー・セキュリティ(TLS)を組み合わせて、それぞれのホストロール間の接続とAPI コールを認証します。これにより、認証ポリシーを実施し、監査イベントを取得することができます。Cloudera Manager は、ローカルのKDC に対して直接、または企業ディレクトリの仲介者を介して認証情報を生成します。同様に、Cloudera Manager Auto TLS では、ホストごとの証明書を生成し、確立された認証機関による署名を得ることができます。必要に応じて、実装を簡素化するために、証明書に署名する権限を Cloudera Manager に委譲することができます。以下のセクションでは、各側面がどのように実装されるかについて詳しく説明します。

認証

通常、クラスタは、既存の企業ディレクトリと統合され、認証情報の管理を簡素化し、ユーザーアカウントとサービスアカウントの両方を管理・維持するための確立された人事手順と連携します。クラスタ内のすべてのサービスアカウントを認証するために Kerberos が使用され、企業ディレクトリ(IDM/AD)で生成され、Cloudera Manager で配布される認証情報が使用されます。これらの手順の安全性を確保するためには、CM、企業ディレクトリ、およびクラスタホスト間のすべてのやり取りが TLS を使用して暗号化されることが重要です。署名された証明書が各クラスタホストに配布され、サービスロールが相互に認証できるようになります。これには、Kerberos 認証情報の生成や配布などの設定変更が暗号化されたチャネルを介して実行されるように、Cloudera Manager サーバーとの TLS ハンドシェイクを実行する Cloudera Agent プロセスが含まれます。CM エージェントに加えて、Impala デーモン、HDFS ワーカーロール、管理ロールなどのすべてのクラスタ・サービス・ロールは通常 TLS を使用します。

Kerberos

Kerberosを有効にすると、すべてのクラスタロールは、有効なKerberosチケットがあれば相互に認証できます。認証チケットは、有効な認証情報の提示により、KDC(通常、ローカルの Active Directory Domain Controller、FreeIPA、または企業のケルベロス・インフラストラクチャとの信頼関係が確立された MIT Kerberos サーバー)によって発行されます。Cloudera Manager は、データベース内で安全に管理されている昇格された権限を使用して、これらの資格情報を生成し、各サービスロールに配布します。通常、管理者権限は、企業ディレクトリ内の特定の組織単位 (OU) 内の Kerberos プリンシパルの作成と削除を可能にします。グッドプラクティスとして、Kerberos keytab ファイルが暗号化された接続を介して転送されることを保証するために、Cloudera Manager とエージェント間の TLS セキュリティを最初に有効にします。

暗号化

転送中の暗号化は、手動または自動 TLS の2つのデプロイメントモードでTLS セキュリティを使用して有効になります。手動 TLS の場合、お客様は独自のスクリプトを使用して独自の証明書を生成し、クラスタホストにデプロイします。次に使用する場所を Cloudera Manager で設定して、クラスタサービスでの使用を可能にします。

通常、証明書などのセキュリティアーティファクトは、ローカルファイルシステムの /opt/cloudera/security に保存されます。cloudera-deploy Ansible オートメーションでは、この方法を使用しています。

Auto TLS を使用すると、Cloudera Manager は、スタンドアロンまたは既存の企業機関から委任された認証局として機能できます。CM は、証明書を生成して署名し、署名した証明書を関連するトラストストアとともにクラスタにデプロイします。デプロイされた証明書は、クラスタサービス間のネットワークトラフィックを暗号化するために使用されます。HDFS の透過的暗号化、データ転送とリモートプロシージャコール、そしてさまざまなユーザーインターフェースと API との通信という3つの主要な通信チャネルがあります。

https://docs.cloudera.com/cdp-private-cloud-base/latest/security-overview/topics/cm-security-authentication-overview.html

保存されたデータの暗号化

機密データを安全に保存するためには、保存データが暗号化されていることを保証すると同時に、復号化できる権限を持つユーザーやサービスが処理できるようにすることが重要です。安全な CDP クラスタは、完全に透過的な HDFS 暗号化機能を備えており、多くの場合、さまざまなストレージテナントやユースケースに応じて暗号化ゾーンを分けています。HDFS 全体を暗号化するのではなく、暗号化が必要なディレクトリ階層を暗号化することに注意ください。

HDFS だけでなく、YARN や Impala のスクラッチディレクトリ、ログファイルなどの主要なローカルストレージも同様にブロック暗号で暗号化できます。HDFS とローカルファイルシステムの両方を、安全なキー管理サービス(Key Trustee Service)に統合することができます。このサービスは通常、キー管理を担当する別のクラスタにデプロイされます。これにより、クラスタ管理者と、暗号化キーに対する責任を持つセキュリティ管理者との職務の分離を図ることができます。さらに、Key Trustee となるクライアント側の暗号化により、Apache Log4j2 CVE-2021-44228 などの脆弱性に対する多層防御が提供されます。

論理アーキテクチャ

Ranger KMS サービスの概要

Ranger KMS サービスは、Ranger KMS サービスと Key Trustee KMS を1つのサービスに統合したもので、Ranger KMS DB または Key Trustee Service の両方をサービスのバッキングキーストアとしてサポートします。どちらの実装も、KTS のバッキングサポートと HMS の統合をサポートしており、複雑さとハードウェアの追加が必要となりますが、完全な職務の分離と幅広い HSM を提供します。運用を簡素化し、大規模に運用するためには、RKMS + KTS をサポートすることが望ましいです。Ranger KMS は以下をサポートします。
– キー管理:Web UI または REST API を使用して、キー作成、更新、削除を行う
– アクセスコントロール:Ranger KMS 内でアクセスコントロールポリシーを管理する機能を提供。アクセスポリシーは、キーを生成または管理するためのアクセス許可を制御し、HDFS で暗号化されたデータのセキュリティをさらに強化
– 監査:Ranger KMS によって実行されるすべてのアクションの完全な監査トレースを提供
– すべてのポリシー:Ranger サービスによって維持される

キー・セキュリティ・サービス

Cloudera Security and Governance サービスは、Cloudera Manager でデプロイ・管理できるクラスタの SDX レイヤーの一部を構成します。これらについては、次のセクションで詳細に説明します。

Apache Ranger

Apache Ranger は、プラットフォーム全体で包括的なデータセキュリティを実現、監視、管理するためのフレームワークです。CDP スタック内のすべてのサービスについて、データやその他の関連オブジェクトにアクセスするためのポリシーを作成・管理するために使用され、以前のバージョンと比較して多くの改良が施されています。

  • CDPより前の Rangerは、ポリシーでサポートされているのはユーザーとグループのみでした。CDP では、Ranger に、以前 Apache Sentry に存在した「ロール」機能が追加されています。ロールとは、特定のオブジェクトにアクセスするためのルールのコレクションです。Ranger には、これらの役割を特定のグループに割り当てるオプションがあります。Ranger のポリシーは、ロールに対して、あるいはグループや個々のユーザーに対して直接設定することができ、すべての CDP サービスに一貫して適用することができます。
  • CDH からの CDH ユーザー向けに CDP で導入された重要な変更の1つは、Apache Sentry を Apache Ranger に置き換えたことです。これにより、YARN、Kafka、Hive、HDFS、および Solr サービス用のより豊富なプラグインが提供されます。HDP をご利用のお客様には、Apache Sentry で以前提供されていたHiveのテーブルレベルの権限を HDFS のファイルシステムと同期させる新しい Apache Ranger RMS の機能をお使いいただけます。

Apache Ranger は従来より広範に以下機能を提供します。

  • 一元化された管理インターフェースと API
  • すべてのコンポーネントで標準化された認証方法
  • ロールベースのアクセスコントロールや属性ベースのアクセスコントロールなど、複数の認証方法をサポート
  • 管理者および監査アクションの集中的な監査

Apache Ranger は、いくつかのコンポーネントを備えています。

  • 管理ポータルの UI と API
  • Ranger Plugins:各コンポーネント用の軽量 Java プラグインで集中管理方式のサービスからポリシーを取り込み、ローカルに保存するように設計されています。各ユーザーのリクエストは、ポリシーに照らして評価され、リクエストをキャプチャし、別の監査イベントを介して Ranger 監査サーバーに送信されます。
  • ユーザーグループ同期:UNIX や LDAP からユーザーやグループのメンバーシップを同期し、ポリシー定義のためにポータルによって保存されます。

お客様は通常、OS でユーザーのグループメンバーシップを解決するために、SSSD や同様の技術を導入します。Ranger Audit サーバーは、クラスタの Solr Infrastructure サービスを使用してこれらのイベントをインデックス化し、分析とレポート作成を容易にします。

注:Hive の権限シンクロナイザーには注意が必要です。この機能は Hive 内で実行され、すべての Hive オブジェクトに対して5分ごとに権限を定期的にチェックします。これにより、何千もの Hive オブジェクトがある場合、Hive のメモリ要件が大きくなり、Hive メタストアのパフォーマンスが低下します。この機能は、Beeline を使用している場合や、SQL ベースのステートメントを使用して Grant を操作・確認している場合にのみ必要となります。少なくとも、同期の速度を遅くし、hive.privilege.synchronizer.interval=3600で1時間ごとにチェックするか(デフォルトは720)、完全に無効にして Ranger の UI でポリシーを管理することをお勧めします。

セキュリティゾーン

セキュリティゾーンでは、Ranger のリソースやタグベースのポリシーを特定のグループにまとめ、管理を委任することができます。例えば、特定のセキュリティゾーンでは、以下のようになります。

  • セキュリティゾーン 「finance 」には、「finance」Hive データベース内のすべてのコンテンツが含まれる
  • ユーザーとグループは、セキュリティゾーンの管理者として指定できる
  • ユーザーは、自分が管理者となっているセキュリティゾーンでのみ、ポリシーを設定することができる
  • セキュリティゾーンで定義されたポリシーは、そのゾーンのリソースにのみ適用される
  • ゾーンは、HDFS、Hive、HBase、Kafka などの複数のサービスのリソースを含むように拡張することができ、ゾーンの管理者は、組織が所有するリソースに対して、複数のサービスにまたがってポリシーを設定することができます。

Apache Atlas

Atlas は、スケーラブルで拡張可能なガバナンスサービスのコア基盤であり、企業が CDP のコンプライアンス要件を効果的かつ効率的に満たし、企業のデータエコシステム全体との統合を可能にします。
企業はデータ資産のカタログを作成し、これらの資産を分類および管理し、データサイエンティスト、アナリスト、データガバナンスチームにこれらのデータアセットに関するコラボレーション機能を提供することができます。Apache Atlas は、論理的には以下のように構成されています。


Apache Knox

Apache Knox は、すべてのリモートアクセスイベントのプロキシとして機能することで、CDP Web UI および API へのシングルサインオン( SSO )を提供し、クラスタインタフェースへのアクセスを簡素化します。これらの API の多くは、構成の変更を、その場で監視および発行するのに役立ちます。

ステートレスなリバースプロキシフレームワークである Knox は、CDP のREST API へのリクエストをルーティングする複数のインスタンスとしてデプロイすることができます。負荷の増加に応じて Knox ノードを追加することで、線形的にスケールアップします。ロードバランサーは、リクエストを複数の Knox インスタンスにルーティングすることができます。

また、Knox は REST/HTTP コールを傍受し、一連の拡張可能なインターセプターパイプラインを通じて、認証、認可、監査、URL の書き換え、Web 脆弱性の防止、その他のセキュリティサービスを提供します。

Knox によって保護されている各 CDP クラスタには、単一のクラスタ固有のアプリケーション・コンテキスト・パスで表される REST API のセットがあります。これにより、Knox Gateway は複数のクラスタを保護すると同時に、 REST API 利用者に、複数のクラスタ間で必要なすべてのサービスにアクセスするための単一のエンドポイントを提供できます。

CDP では、一部のプロバイダー(sso、pam、admin、manager)とトポロジー(cdp-proxy、cdp-proxy-api)はすでに構成されており、ほとんどが Cloudera Manager の設定 UI に統合されています。さらに CDP には、ユーザーのための便利な構成済みのホームページが付属されています。

クラスタ定義は、トポロジーデプロイメント記述子の中で定義され、ユーザー向け URL とクラスタ内部との間のルーティングと変換を目的として、Knox Gateway にクラスタのレイアウトを提供します。

トポロジーデプロイメント記述子を Knox インストールの topologies ディレクトリに書き込むだけで、新しい CDP クラスタ定義が処理され、ポリシー施行プロバイダが構成され、アプリケーションコンテキストパスが API コンシューマーによって使用可能になります。CDP Private Cloud Base には、さまざまなクラスタサービスのための構成済みトポロジーが付属しており、顧客はそれぞれの環境に合わせて拡張することができます。

まとめ

CDP Private Cloud Base クラスタの主要なセキュリティ機能をまとめました。今後の記事では、すべての主要な機能の参考となる実装例を挙げて、より詳細に説明します。

  • 企業ディレクトリとの統合
  • Hive テーブルを作成して保護する
  • Rangerポリシーの評価フローを説明する
  • ロールを使ってグループやユーザーに特定の Hive オブジェクトを有効化し保護する方法の例を示す
  • Hive テーブルとその下の hdfs ディレクトリに適用できるタグベースのポリシーを説明する
  • Ranger監査グループとロールをマッピングする手順を説明する

Cloudera Data Platform Security の詳細については以下の URL にアクセスしてください。
https://docs.cloudera.com/cdp-private-cloud-base/7.1.7/cdp-security-overview/topics/security-data-lake-security.html

Cloudera Japan Marketing
この著者の他の記事

コメントする

あなたのメールアドレスは公開されません。また、コメントにリンクを貼ることはできません。