IBM InfoSphere Guardiumを使用して、ビッグデータのセキュリティーと監査を実現するには

IBM InfoSphere BigInsightsおよびCloudera Hadoopをモニタリングし、監査目的でアクセスする方法

本記事を読むことによって、InfoSphere Guardium が提供するデータベース・アクティビティーのモニタリング機能と監査機能について学び、Hadoopのデータ保護機能を既存のエンタープライズ・データ・セキュリティー・システムにシームレスに統合できるようになります。システムの設定方法について学び、InfoSphere Guardiumが提供するHadoop環境に特化したセキュリティー・ポリシーとレポートの活用方法を確認することができます。さらに、IBM InfoSphere BigInsightsでのみ提供される、クイック・モニタリング機能の実装についても確認することができます。

Sundari Voruganti, QA Specialist, IBM

Sundari Voruganti photoSundari Vorugantiは、IBMのシリコンバレー研究所でInfoSphere Guardiumの品質保証を担当しています。以前は、System z上で稼働するIBM InfoSphre WarehouseのSWATチームに所属していました。12年以上のIT業界におけるキャリアのほとんどをIBMで過ごし、テスト業務とユーザー向け情報提供業務に携わっています。



Kathy Zeidenstein (krzeide@us.ibm.com ), InfoSphere Guardium Evangelist, IBM

Author Photo: Kathy ZeidensteinKathy Zeidensteinは長年にわたってIBMに勤務しています。現在は、IBMのシリコンバレー研究所でInfoSphere Guardiumによるデータ・アクティビティーのモニタリング機能をユーザーに対して啓蒙する業務を担当しています。以前はInfoSphere Optim(データ・ライフサイクル管理ツール)の製品マネージャーを務めていました。IBM社内のInformation Management製品とECM製品の担当部門で、技術情報の提供業務、製品管理業務、製品マーケティング業務を担当した経験があります。



2013年 1月 30日

はじめに

ビッグデータに関して脚光を浴びているのは高スピードで提供される大容量かつさまざまな種類のデータをサポートできるインフラと、このインフラで実現するリアルタイムの分析機能です。Hadoopのようなビッグデータ環境は比較的新しい環境であるものの、ビッグデータ環境においてはまず最初にセキュリティー上の問題を解決する必要があります。データが存在している環境では、プライバシー違反、不正アクセス、または権限を有するユーザーによる不適なアクセスといった問題が発生する可能性があります。

ビッグデータ環境であれ、従来のデータ管理アーキテクチャーであれ、コンプライアンス・イニシアチブは等しく実施する必要があり、導入テクノロジーが新しく発展途上であるからといって脆弱なデータ・セキュリティーを許容することはできません。それどころか、ビッグデータではより多くのデータがフィードされるため、データが保存されるレポジトリーのリスクと脅威は高まります。

企業内でデータ・セキュリティーに対して責任を持つ担当者は、以下をはじめとする問いに明確に回答できる必要があります。

  • ビッグデータに対するデータ・リクエストをサブミットしているのは誰か?どのようなMapReduceのジョブを起動しているのか?ユーザーは全ての機密データをダウンロードしようとしているのか、それとも通常のマーケティング・クエリーを実行して顧客データから知見を得ようとしているのか?
  • ハッカーがアルゴリズムに基づいて機密データにアクセスしようとした結果、パーミッションの例外が膨大に発生しているかどうか。
  • 特定のジョブがデータにアクセスするための適切なプログラムによるものなのか、それとも認識できていない新規のアプリケーションによって起動されたものか?

ここで必要となるのは、ビッグデータに関連するアプリケーションと分析機能を既存のデータ・セキュリティー基盤に統合することです。自社開発したスクリプトやモニタリング機能に依存するのは、業務処理が増大し、エラーが多発し、不適切な使用につながるため、お勧めできません。

本記事では、包括的なデータ・アクティビティーのモニタリングとコンプライアンスを実現するIBM InfoSphere Guardiumの機能を拡張することによって、Hadoopソリューションを対象としたアクセスのモニタリング機能とレポーティング機能を追加する方法について検証します。

本記事ではInfoSphere Guardiumに関する大まかな概要、およびデータをInfoSphere Guardiumコレクターに送信することによって、セキュリティー・アナリストがレポーティングを実行する方法については説明するものの、InfoSphere Guardiumコレクターのインストール方法と設定方法についての具体的な説明は省きます。Hadoopアクティビティーのモニタリングを行うために標準のサンプル・レポートも製品に組み込まれており、InfoSphere Guardiumの設定を行うことで、すぐにモニタリングを開始することが可能です。

InfoSphere Guardiumの概要について

図1のとおり、IBM InfoSphere Guardiumは軽微なソフトウェア・プローブを使用して継続的にデータベース・トランザクションのモニタリングを実行します。

図1. InfoSphere Guardiumによるデータ・アクティビティーのモニタリング
Staps are shown on cluster nodes feeding to a collector.

これらのプローブはS-TAP(「ソフトウェア・タップ」の略)と呼ばれ、データベースの監査ログに依存することなく、オペレーティング・システムのカーネル・レベルで権限を有するユーザーによるトランザクションを含む全てのデータベース・トランザクションをモニタリングし、同時に職務分掌も実現します。また、S-TAPを使用するにあたり、データベースやアプリケーションに変更を加える必要は一切ありません。

S-TAPはトランザクションをネットワーク上に存在する堅牢なコレクター(アプライアンス)に転送し、コレクターにおいてトランザクションを事前に設定したポリシーと照合することによって、ポリシー違反を検出します。その結果、システムはポリシーに基づいて設定したさまざまなアクション(アラートの発行など)を実行します。

InfoSphere Guardiumは、規模が大きく地理的に分散している情報基盤をサポートする幅広いシステムをサポートします。本記事ではInfoSphere Guardiumの基本機能についてはほとんど言及していないため、InfoSphere Guardiumの機能に関する詳細情報が必要な場合は、参考文献セクションのリンクをご参照ください。製品の全ての機能があらゆるデータソースに対応しているわけではないことにご留意ください。

HadoopのモニタリングのためにInfoSphere Guardiumを使用するメリット

InfoSphere Guardiumを使用することによって適切な情報に基づいて行動を起こすことができるようになるため、簡単に監査に対応できる環境を構築することができるようになります。Hadoop環境を監査に対応できるようにするための方策としてログ・データを保存しているものの、実際にログ・データを使用することは面倒だと考えているようでは、タイムリーな情報提供の観点からだけでも監査の要件を満たすことはできないでしょう。デジタル・フォレンジック分析の実行には多くの時間がかかり、自社開発したスクリプトが必要になります。自社でスクリプトを開発することによって多くのリソースが必要になり、Hadoopでビジネス・バリューを実現するために活用できるリソースが不足することになります。

InfoSphere Guardiumでは、複雑なモニタリング機能の多くが標準機能として提供されます。セキュリティー・ポリシーを設定することによって、どのようなデータを保持し、ポリシー違反が発生した際にどのように対応すべきかを指定します。データ・イベントはInfoSphere Guardiumコレクターに直接書き込まれ、権限を有するデータであれ本データにアクセスすれば、アクセス形跡を隠すことはできません。標準で提供されるレポートによって迅速にHadoopのモニタリングを開始することができ、これらのレポートを簡単にカスタマイズすることによって監査要件に対応することができます。

InfoSphere GuardiumのS-TAPはもともとオーバーヘッドを下げたうえでパフォーマンスを高めるために設計されたコンポーネントです。また、S-TAPはデータベース製品の環境をモニタリングするために活用することができます。Hadoopではオーバーヘッドが3%を超えることはほとんどないため、ほとんどのHadoopワークロードではオーバーヘッドは微々たるものです。

最後に、図2のとおりInfoSphere Guardiumはユーザー・インターフェースからストレージに至るHadoopスタック全体に対してモニタリング機能を提供します。

図2. InfoSphere Guardiumは、Hadoopスタック全体に対してデータ・アクティビティーのモニタリングを実行
図2. InfoSphere Guardiumは、Hadoopスタック全体に対してデータ・アクティビティーのモニタリングを実行

この機能が重要な理由とは何でしょうか?Hadoopが提供するアクティビティーのほとんどはMapReduceとHDFSに分類できますが、このレベルではよりユーザーが実行しようとした処理の内容は判別できず、そもそもどのユーザーがジョブを実行したのかも判別できません。データベースの監査証跡ではなく、ディスク・セグメントで実行されたI/O処理の内容が提供されるようなものです。したがって、さまざまなレベルでモニタリングを実行することによって、アクティビティーの内容を把握できるだけでなく、スタックのより低いレベルで実行されるアクティビティーについても監査が行えるようになります。

Hadoopアクティビティーのモニタリング

モニタリング可能なイベントには、以下が含まれます。

  • セッション情報とユーザー情報
  • HDFSにおける演算処理とコマンド情報(cat、tail、chmod、chown、expungeなど)
  • MapReduceにおいて実行されるジョブ(ジョブ、演算、パーミッション)
  • 例外状況(認証の失敗など)
  • HiveまたはHBaseで行われたクエリー(alter、count、create、drop、get、put、listなど)

以下の例では、単純なHadoopコマンドがInfoSphere Guardiumのレポートでどのように表示されるのかについて説明しています。

用語

InfoSphere Guardiumを初めて使用する場合は、レポートやポリシー・ルールにおいてリレーショナル・データベースの用語が頻繁に使用されていることに驚くかもしれません。SQLはファイル・システムのデータには使用されないものの、共通の用語を使用することによって、Guardiumを通じてさまざまなデータベースのアクティビティーを参照することができるようになります。

HBase: 以下はHbaseで使用されるcreateコマンドです。

create ‘test_hbase’, ‘test_col’.

InfoSphere Guardiumは、図3のとおりHBaseに提供される実際のコマンドを表示します。

図3. HBaseレポート
図3. HBaseレポート

HDFS: 環境で使用可能なシンプルな-lsコマンドは以下のとおりです。

hadoop fs –ls(図4を参照)

図4. HDFSのlsコマンド
図4. HDFSのlsコマンド

図4のとおり、本コマンドは2種類のコマンドに分類でき、本コマンドに基づいて関連するファイル情報を確認できることが分かります。

表面上は単純なアクティビティー・モニタリングを実行しているように見えますが、実際はポリシーの設定とレポーティングを強力かつ柔軟に実行するインフラが存在しています。本記事では、未知のユーザーが機密データにアクセスした際に、イベントのログを記録し、アラートを生成する方法について後述しています。新規のアプリケーションや未知のアプリケーションがHadoopデータにアクセスした際に当該状況を検出するために役立つ監査レポートを作成することもできます。

IBM InfoSphere BigInsightsが提供するクイック・モニタリング機能

IBM InfoSphere BigInsightsにはGuardium Proxyという名前の統合機能が含まれ、分析とレポーティングのためにログ・メッセージの読み取りとログ・メッセージのInfoSphere Guardiumへの送信を行うことができます。本プロキシーを使用することによって、BigInsightsはHadoopのログに基づいて生成したメッセージをInfoSphere Guardiumコレクターに送信することができます。

本プロキシーのメリットとしては以下が挙げられます。

  • 簡単に機能の設定と起動を行うことができます。S-TAPのインストールやポートの設定は必要ありません。ネーム・ノードでプロキシーを有効化すれば、設定は完了します。
  • 本プロキシーはInfoSphere Guardiumに送信するメッセージとしてApacheのログ・データを使用するため、本メッセージには、ステータスやハートビートのような除外すべき情報はそれほど含まれていません。
  • GuardiumではBigInsightsの新バージョンに迅速に対応するため、メッセージ・プロトコルの変化に柔軟に対応できます。

制限条件: Hadoopはログ・データに例外状況を記録しないため、例外状況をInfoSphere Guardiumに送信することはできません。例外状況に関するレポーティングが必要な場合は、S-TAPを実装する必要があります。さらに、HiveやHBaseが提供するMapReduceやHDFSに関するメッセージを参照することができるものの、HBaseやHiveに対して行われるクエリーをモニタリングすることはできません。

InfoSphere BigInsightsが提供するGuardium Proxyを使用したい場合は、参照資料Aをご参照ください。本セクションでは、Hadoopサービスのために本プロキシーを有効化するための設定に関する説明があります。


前提条件

本セクションでは、InfoSphere GuardiumとCloudera Hadoopの両方で必要となる前提条件について説明します。

InfoSphere Guardiumによるセキュリティーとコンプライアンスを実現するソリューションの場合

IBM InfoSphere Gardiumソリューションは、以下のとおり提供されます。

  • ハードウェア・ソリューション: IBMが提供する物理アプライアンスに基づいて提供される、完全に設定が行われたソフトウェア・ソリューション
  • ソフトウェア・ソリューション: ユーザーのハードウェアに実装可能(仮想アプライアンスとして実装することも可能)なソフトウェア・イメージとして提供されるソリューション

Hadoop環境のモニタリングを行うには、InfoSphere Guardium Appliance V9.0パッチレベル2(ハードウェアまたはソフトウェア)をコレクターとして設定し、Hadoop環境のためにInfoSphere Guardium Standard Activity Monitorのライセンスを取得する必要があります。Hadoopのモニタリングを開始する前に、IBMのサポート・サイトで必要なパッチが他に存在しないか確認する必要があります。

システムの成長に合わせて、集中管理機能兼アグリゲーターとして設定したアプライアンスを取得することもできます。本アプライアンスは単一のWebベースのコンソールを通じて複数のコレクターを集中管理し、複数のコレクターに基づいてフェデレーションされたシステムを構築することができます。本アプライアンスを活用することによって、アーカイブのスケジュール、パッチのインストール、ユーザー管理などのセキュリティー・ポリシーやアプライアンスの設定を管理することができます。さらに、複数のコレクターが提供する生データやレポートを集約することによって、全社レベルの包括的な監査報告書を生成することもできます。

本記事はIBM InfoSphere Guardiumアプライアンスのインストールと設定については説明しません。以下、ネットワーク上で1台以上のアプライアンスがHadoopクラスターに接続していることを想定し説明します。

Cloudera

InfoSphere Guardiumは、Red HatまたはSUSE Linux上で稼働するClouderaの以下のバージョンのモニタリングを行うことができます。

  • CDH3: アップデート2、アップデート3、アップデート4
  • CDH4
  • Hiveでは、BeeswaxデータベースとしてMySQLを使用する必要があります。InfoSphere GuardiumはMySQLでのみ提供されるBeeswaxレポートの特定のメッセージ形式を必要とするためです。

サポート対象のClouderaのリリース・レベルやその他のサポート対象のHadoopディストリビューションの最新情報については、ibm.comに掲載されるInfoSphere Guardiumのシステム要件をご参照ください。

IBM InfoSphere BigInsights

IBM InfoSphere BigInsightsのバージョン1.4以降が必要です。IBM InfoSphere Guardiumでは、Cloudera環境における上書きインストール機能もサポートしています。


データ・アクティビティーのモニタリング機能を設定する

本機能のインストールと設定を行うためのステップには、以下が含まれます。

  1. プランを立てる。現在使用しているHadoopクラスターのネットワーク・アーキテクチャー(IPアドレスと該当するポート番号を含む)について詳細を確認することが必要です。
  2. S-TAPをインストールし、適切なHadoopノードでモニタリング・エンジンを設定する。
  3. 検証する。アクティビティー・レポートの作成と参照を通じて、アクティビティーが適切にモニタリングされていることを確認します。
  4. セキュリティー・ポリシーをインストールする。

プランを立てる

InfoSphere GuardiumとHadoopをスムーズに統合するには、適切なプランを立てる必要があります。以下のセクションでは、本アーキテクチャーの概要について認識すべき情報を提供します。

注意: 本機能を初めて実装する際には、特定のビジネス要件をサポートする単純な設定を行い、その後機能を追加することが有効です。例えば、HDPSとMapReduceのみをモニタリングする機能を実装し、コンフィギュレーションを検証し、その後必要に応じてHiveとHBaseのモニタリング機能を追加します。

図5は、InfoSphere Guardiumが提供する包括的なモニタリング機能を実現するために、クラスター内のどのコンポーネントに特定のOSをサポートするS-TAPをインストールする必要があるのかを示しています。

図5. Hadoopスタックをモニタリングするために必要なS-TAP
図5. Hadoopスタックをモニタリングするために必要なS-TAP

IBM InfoSphere GuardiumはGuardium Installation Managerを使用することによって複数のS-TAPのインストールとアップデートを一括管理し、S-TAPの管理の簡略化と自動化を実現します。

注意: スレーブ・ノードに関しては、挿入データ(HBaseのputコマンド)のモニタリングのためにS-TAPが必要になるのはHBaseのリージョン・サーバーに限られます。

適切なノードに特定のOSをサポートするS-TAPをインストールすると、S-TAPのモニタリング・エンジンを定義することによって、S-TAPがモニタリングするポートを設定することができます。このモニタリング・エンジンには、特定のモニタリング・プロトコルが設定されています。S-TAPがネットワーク・パケットをキャプチャーし、コピーを作成し、解析と分析を行い、InfoSphere Guardiumコレクターに情報を送信します。その後、IさらにnfoSphere Guardiumコレクターの内部データベースで本情報に対する解析と分析が行われ、保存されます。

次のステップに進む前に、以下を確認する必要があります。

  • • サポート対象のバージョンのClouderaまたはInfoSphere BigInsightsが稼働していることを確認する。
  • • Hadoopクラスターから収集したトラフィックを受領するInfoSphere GuardiumコレクターのIPアドレスを確認する。
  • • S-TAPが必要になるサーバーのIPアドレスを確認する。
  • • 表1とに記載された情報に基づいて、モニタリング対象のポートと本ポートが存在するホストの情報を書き留める。本記事においては、Clouderaの標準のポート(基本的にはIBM BigInsightsのポートと同じ)に基づいてポートの設定を行いました。ただし、ユーザーによって設定が異なる場合があります。
表1. モニタリングの対象となるHadoopのサービス・ポート
サービスポート
HDFSのネーム・ノード8020、50470、および50070
HDFSのThriftプラグイン(Hue向け)(ネーム・ノード)10090
MapReduceのジョブ・トラッカー8021、9290、および50030
HBaseマスター60000および60010
HBaseリージョン60020
HBaseのThriftプラグイン9090
Hiveサーバー10000
Beeswaxサーバー8002
Cloudera Manager Agent9001

S-TAPをインストールし、モニタリング・エンジンを設定する

S-TAPは特定のオペレーティング・システムをサポートするため、対象となるノードごとにRed HatまたはSUSE LinuxをサポートするS-TAPをインストールする必要があります。本プロセスは、InfoSphere GuardiumのS-TAPガイドに詳しく記載されています。インストールは、InfoSphere Guardium Installation Managerを通じて実行することもできれば、同一のコマンドで複数のノードに対するインストールを実行できるインタラクティブでないインストール・プロセスを通じて実行することもできます。

次に、モニタリング対象となるノードとサービスに対して、適切なモニタリング・エンジンを設定します。モニタリング・エンジンにおいてモニタリングを行う際に使用するプロトコル(Hadoop)を指定し、モニタリングの対象となるポートを指定します。表1は、InfoSphere Guardiumでモニタリング可能な、Clouderaが標準で使用するポートの一部を示しています。ただし、ユーザーの環境によってポートが異なる場合があります。

表2は、本記事においてHadoopクラスターの設定を行うために使用した情報(標準のClouderaポートに基づく)について説明しています。

表2. Hadoopクラスターのモニタリングと設定を行うために使用されるHadoopサービスのポート
モニタリングの対象となるコンポーネントプロトコルポートの範囲KTAP DBリアル・ポート
HDFS、ジョブ・トラッカー、BeeswaxサーバーHADOOP8000-8021 8021
MapReduceのマスターとThriftプラグインHADOOP9000-9291 929l
HiveサーバーとHDFS Thriftプラグイン(Hue向け)HADOOP10000-10090 10090
HDFSのネーム・ノードHADOOP50010-50470 50470l
HBaseマスターHADOOP60000-60010 60010
HBaseリージョンHADOOP60020-60020 60020l

注意: サーバーごとに複数のモニタリング・エンジンを指定することができますが、これを行うことができるのはプロトコルが同一の場合です。また、各モニタリング・エンジンについてポートの範囲を広げすぎるのは避ける必要があります。必要ではない範囲のポートを設定することによってInfoSphere Guardiumコレクターで不適切なトラフィックを分析する必要が発生し、追加のオーバーヘッドが発生するためです。しかし、管理を簡略化するために、一部のモニタリング・エンジンについてポートの範囲を広めに設定することが適切な場合があります。

モニタリング・エンジンを追加する際には、以下のユーザー・インターフェースを利用します。 Administration Console >Local Taps >S-TAP Control >Add Inspection Engine

もしくは、API (create_stap_inspection_engine)を利用することもできます。標準のポートを使用してモニタリング・エンジンを作成するために使用できるAPIコマンドのサンプルについては、参照資料Bをご参照ください。

図6は、作成されたモニタリング・エンジンの例を示しています。

図6. Hadoopのモニタリング・エンジンの例
図6. Hadoopのモニタリング・エンジンの例

オンラインで提供されるS-TAPガイドでは、モニタリング・エンジンの設定フィールドについて詳細情報を確認することができますが、以下に主なフィールドのいくつかについて説明します。

  • Protocol: モニタリングの対象となるデータソースの種類(Hadoop)を指します。本オプションはプルダウンメニューで提供されます。
  • Port Range: 特定のモニタリング・エンジンがモニタリングの対象とするポートの範囲を指します。前述のとおり、できるだけ狭い範囲で設定する必要があります。対象となるポートは、9000番台や50000番台など、できるだけまとまった範囲で設定します。
  • K-TAP real port: 本パラメーターでは、モニタリング・エンジンがカバーするポートの範囲の最後のポートを設定します。1つのポートのみが設定されている場合、K-TAP DBリアル・ポートはそのポートと一致します。
  • Client IP Addresses/Masks: 各モニタリング・エンジンは、1つ以上のクライアントIPアドレスと1つ以上のサーバーIPアドレスの間で発生するトラフィックをモニタリングします。本フィールドは、モニタリング対象のクライアントの設定と制限を行うためのパラメーターとして指定します。例えば、監査を実施する必要のない信頼性の高いクライアントが存在する場合、そのようなクライアントを事前に除外することによって、コレクターの全般的な負荷を削減することができます。IPアドレスは単一のロケーションを指し、マスクは一連のIPアドレスを定義するためのワイルドカードとして機能します。「255.255.255.255」というマスク(ゼロのビットを含まない)はIPアドレスに基づいて指定された単一のアドレスを指します。本記事では、全てのクライアントがモニタリングの対処となるようにクライアントとマスクのパラメーターとして「0.0.0.0」を指定しています。
  • Connect to IP: モニタリングの対象となるデータソースにアクセスするためにS-TAPが使用するIPアドレスを指します。Hadoopでは、標準のパラメーターである「127.0.0.1」を使用することができます。
  • Process name: Hadoopシステムでは、本パラメーターは必要ありません。

アクティビティーがモニタリングされていることを検証する

管理者権限でInfoSphere GuardiumのWebコンソールのSystem Viewタブにアクセスし、Hadoopクラスターに対するS-TAPが有効化されていて、S-TAPに関するステータスが緑色のバックグラウンドで表示されている(S-TAPがInfoSphere Guardium コレクターに接続していることを示しています)ことを確認します。図7は、あるホストに関して本情報がどのように表示されるのかを示したものです。

図7. S-TAPのステータス・モニター
図7. S-TAPのステータス・モニター

該当する全てのノードでS-TAPが適切に設定されていることを検証すると、システム上で稼働するあらゆるジョブをキャプチャーできるようになります。シェル・コマンドまたはサンプルのワードカウントのジョブを起動することによって、データが適切に表示されることを検証することができます。いずれの場合でも、InfoSphere Guardiumのドリルダウン・レポート(Viewタブからユーザーがアクセス可能)を使用するか、アクティビティーを参照するために独自のレポートを作成する必要があります。

Hadoopレポートについては、「InfoSphere Guardiumに含まれるHadoopレポート」のセクションにおいてより詳細に説明しています。検証を行うためのプロセスとして、本記事では本システムにおいてユーザーのロールを設定されたセキュリティー管理者が使用することができるドリルダウン・レポートの活用方法について説明します。

ユーザー権限でログインし、「View」タブをクリックすると、図8のようなグラフが表示されます。このグラフをダブルクリックすると、さらに詳細データをドリルダウンすることができます。

図8. 詳細データをドリルダウンする
図8. 詳細データをドリルダウンする

データはさまざまな方法で分析することができます。図9では、あるドリルダウンの形態を示しています。

図9. ドリルダウンのサンプル
図9. ドリルダウンのサンプル

レポートに含まれる行をクリックすると、一連の選択可能なオプションが表示され、さらに詳細なレポートを参照することができます。


InfoSphere Guardiumに含まれるHadoopレポート

InfoSphere Guardiumには、以下をはじめとするHadoopに対応するいくつかの標準レポートが含まれています。

  • BigInsightsとClouderaのMapReduceレポート
  • 不正なMapReduceジョブ
  • Hue/Beeswaxのアクティビティー
  • HDFS、HBase、およびHiveのアクティビティー
  • 例外レポート

ユーザー権限でログインすると、「View」タブをクリックすることによって事前に設定されたレポートを参照することができます。左側のナビゲーション・ペインから「Hadoop」をクリックすると、レポートが表示されます。

管理者権限でログインすると、コンソールにレポートを追加する必要があります。使用しているコンソールに「My New Reports」タブが既に存在し、管理者としてログインしている場合には、以下のステップを実行する必要があります。

  1. 「Tools」>「Report Building」>Report Builderとクリックします。
  2. 2. レポートのタイトルが表示されたウィンドウで、プルダウンメニューから1つのレポート(Hadoop - Hue/Beeswaxレポートなど)を指定し、「Search」をクリックします。
  3. 3. レポートの検索結果のウィンドウで、「Add to My New Reports」ボタンをクリックします(図10を参照)。
    図10. 「My New Reports」ペインにレポートを追加する
    図10. 「My New Reports」ペインにレポートを追加する
  4. 4. Hueを使用してBeeswax上でコマンドを起動し、レポートを参照することができます。本記事においては、図11のとおり以下のHiveコマンドを入力しました。
    図11. Beeswax上でクエリーをサブミットする
    図11. Beeswax上でクエリーをサブミットする
  5. 「Hue/Beeswax」レポートにアクセスすると、「No data found」というメッセージが表示されます。これは、ライタイム・パラメーターを指定することによって、システムに対して表示すべきデータを指示する必要があるためです。指示を出すには、図12のとおり、鉛筆のアイコンをクリックしてクエリーをカスタマイズします。
    図12. Beeswax上でクエリーをサブミットする
    図12. Beeswax上でクエリーをサブミットする
  6. 図13のとおり、クエリーの対象となる期間(いつからいつまで)を指定し(ワークロードによっては、数時間から1日程度の短い期間を指定したほうがよい場合があります)、「LIKE」フィールド、「SQL」フィールド、および「Table_Name」フィールドにおいて「%」記号やその他の検索パラメーターを指定します。
    図13. Hue/Beeswaxレポートのために、ランタイム・パラメーターを指定する
    図13. Hue/Beeswaxレポートのために、ランタイム・パラメーターを指定する
  7. レポートでデータが表示されます(図14を参照)。
    図 14. Hue/Beeswaxレポート
    Hue/Beeswaxレポート
  8. 管理者の場合、同じステップに基づいてMapReduceレポートを発行することができます。
    1. Tools>Report Building>Report Builderとクリックする。
    2. MapReduceレポートを検索する。
    3. レポート・ペインに追加する。
    4. レポートを編集し、ランタイム・パラメーターを追加する。
  9. MapReduceジョブを起動します。本記事では、Clouderaがサンプルで提供するワードカウント・プログラムを使用しました。ワードカウントのシンタックスは以下のとおりです。 bin/hadoop jar hadoop-*-examples.jar wordcount in-dir out-dir
  10. 10. 本記事では、以下のプログラムを起動しました。 hadoop jar hadoop-0.20.2-cdh3u4-examples.jar wordcount /user/svoruga /user/svoruga/wc100 図15のとおりレポートが表示されます。
    図15. MapReduceレポート

    クリックして大きなイメージを見る

    図15. MapReduceレポート

    本記事では、クエリーのパラメーターをカスタマイズすることによって、svorugaword%count がメッセージ(Full SQL)に含まれるアクティビティーのみをレポートに表示するよう設定しました。

トラブルシューティング

InfoSphere Guardiumが提供するHue/Beeswaxレポートは、Thriftのメッセージ形式とMySQLデータベースが使用されることを想定しています。MySQLを使用しているにもかかわらずHue/Beeswaxレポートにデータが表示されない場合は、ポート番号8002(本記事で説明するシステムにおいてThriftが使用するポート)を使用するためにBeeswaxを以下のとおり設定する必要があります。

  1. Hueの.iniファイルにアクセスする。
    • CDH3の場合: /etc/hue/hue-beeswax.iniにアクセスする。
    • CDH4の場合: /etc/hue/hue/ini(「/user/lib/hadoop 」ディレクトリーに「-hadoop *examples.jar "*」が存在すること)にアクセスし、正しいjarファイルと置き換える。
      in-dirは、入力ファイルが存在するHDFSディレクトリーを指します。
      out-dirは、出力ファイルが出力されるHDFSディレクトリーを指します。
  2. 以下の行を非コメント化する。
    beeswax_server_port=8002
  3. 以下のコマンドに基づいて、Hueの停止と再起動を行う。
    • /etc/init.d/hue stop
    • /etc/init.d/hue start

セキュリティー・ポリシーをインストールする

InfoSphere Guardiumでは、あるセキュリティー・ポリシーにはクライアントとサーバー間のトラフィックに適用される一定のルールが含まれています。1つ以上のルールを組み合わせることによって、ポリシーを構築することができます。本記事で説明する本記事で取り上げるHadoopのセキュリティー・ポリシーでは、InfoSphere Guardiumコレクターに記録されるトラフィックの量を削減するために役立つアクセス・ルールが規定されています。

注意:サンプル・ポリシーを修正するのではなく、クローンを作成し、クローンに基づいてポリシーを修正してください。

Hadoopポリシーにアクセスしてクローンを作成するには、以下を実行します。

  1. 管理者権限でログインし、Tools>Config & Control>Policy Builderとクリックする。
  2. Policy FinderからHadoop Policyを選択し、Cloneボタンをクリックする。
  3. ポリシーに新しい名前を付けた後、Saveをクリックする。

ポリシーをインストールするには、以下を実行します。

  1. 管理者権限でログインし、Administration Console > Configuration > Policy Installationとクリックする。
  2. 2. 作成したHadoopポリシーのクローンを選択し、該当するインストール・アクションを選択する。ポリシーのインストールの方法と2つ以上のポリシーを設定することによって発生する影響についいては、オンライン・ヘルプをご参照ください。

図16は、Hadoopポリシーに関する一連のルールを示しています。プラス(+)マークをクリックすると、より詳細な内容を確認することができます。鉛筆のアイコンをクリックすると、ルールを編集することができます。

図16. サンプルのHadoopポリシーに含まれるルール
図16. サンプルのHadoopポリシーに含まれるルール

本ポリシーに含まれる各ルールの内容は以下のとおりです。

  • Access Rule: Low interest objects: Allow

    本ルールの定義は図17のとおりです。

    図17. Hadoopに関するそれほど重要でないオブジェクトに関するアクセス・ルール
    policy shows a group called Hadoopskipobjects and indicates the group biulder idcon for that group. slao shows actions allow.

    本ポリシーにおいては、以下の2種類の項目に留意する必要があります。

    • o ユーザー設定のような一連のオブジェクトの定義はそれほど重要ではありません。Group Builderのアイコンをクリックすると、図18のとおり、「HadoopSkipObjects」グループに含まれるオブジェクトを参照することができます。
      図18. Hadoopに関するそれほど重要でないオブジェクト
      図18. Hadoopに関するそれほど重要でないオブジェクト
      必要に応じて、本グループを修正することができます。
    • アクションとして指定された「Allow」は、これらのオブジェクトついてポリシー違反は記録されず、さらに詳細の分析の対象ともならないことを意味しています。
  • Access Rule: Low Interest Commands: Allow

    上記のルールと同様ですが、本ルールは特にコマンドに関するものです。

  • Access Rule: Filter based on Server IP: Log Full Details

    本ルールを適用することによって、同じInfoSphere Guardiumコレクターを使用するHadoop以外のサーバーによって生成されるアクティビティーをモニタリング対象から除外することができます。

Important:モニタリングの対象とならないサーバーの全てのIPアドレスを含むHadoop以外のサーバー のグループを必ず指定する必要があります。そのようなサーバーが存在しない場合は「0.0.0.0」以外のダミーのIPアドレスを入力する必要があります。本グループに関して何らかのIPアドレスを指定しないかぎり、レポートは適切に発行されません。


InfoSphere Guardiumの先進機能

本セクションでは、Hadoop環境における監査要件とコンプライアンス要件を満たすために、InfoSphere Guardiumで実行できる先進機能について説明します。本セクションの機能を活用することによって、本記事の冒頭で示された以下の問いに回答することができます。

不正ユーザーが機密データにアクセスしていないか検証する

監査要件を達成するために役立つルールを作成するにあたっては、さまざまなルールを活用することができます。

ヒント:Hadoopポリシーのクローンにルールを追加する場合は、既存のルールについて「Continue to next rule」が選択されていることを確認します。本パラメーターが選択されていないと、新規に作成したルールを検証することができません。

図19は、以下の2種類のグループに関するルールを規定しています。

  • 既知のHadoopユーザー
  • 既知の機密データのオブジェクトまたはファイル
図19. 機密ファイルにアクセスする際に適用されるポリシー・ルールの例
図19. 機密ファイルにアクセスする際に適用されるポリシー・ルールの例

本ルールは既知のユーザーに対しては適用されません。つまり、既知のグループに含まれないユーザーが機密データにアクセスした場合のみ情報が記録され、さらに詳細情報を分析するインシデント・レポートに当該インシデントに関する情報が記録されます。正当なアクセスであることが判明した場合は、当該ユーザーを既知のグループに追加することができます。

新規のMapReduceジョブがシステムにアクセスしていないか検証する

多くの企業では、自社データにアクセスする新規アプリケーションを適切にトラッキングすることに不安を感じており、この課題に対応するには自動化されたレポートが役立ちます。InfoSphere Guardiumが提供する不正なMapReduceジョブに関するレポートをカスタマイズすることによって、新規のMapReduceジョブがシステムにアクセスした際に当該ジョブを検出することができるようになります。

バックグラウンドで実行される監査プロセスの一環として、本レポートを定期的に発行することができます。この結果、新規のジョブがシステムにアクセスした際に通知を受けることができ、当該ジョブを適切に検証し、承認済みのジョブの一覧に適宜追加することができます。

本レポートを設定するにあたっては、多少プロセスが必要です。以下のステップに基づいて、「Hadoop Authorized Job List」という名称のグループの作成とカスタマイズを行う必要があります。

  1. 使用しているシステム内に存在する既知のジョブと承認済みのジョブの一覧に基づいて、本グループを作成し、データを入力します
  2. 組織内の適切なユーザーがレポートを作成する際に本グループの参照と使用を行えるように、本グループにロールを割り当てます。
  3. 「Hadoop-Unauthozed MapReduce Jobs」レポートをカスタマイズすることによって、本グループをランタイム・パラメーターとして追加します。

本グループの設定に必要なステップの詳細は以下のとおりです。

  1. 管理コンソールから、Tools > Config and Control > Group Builderとクリックする。もしくは、ユーザー権限でログインしている場合は、Monitor/Audit > Build Reports> Group Builderとクリックし、その後Nextをクリックする。
  2. Create New Groupのフィールドで、Application TypeとしてPublicを指定し、任意の名前(Hadoop Authorized Job Listなど)を付け、Group Type Descriptionのドロップダウン・リストからOBJECTSを選択する(図20を参照)。その後、Addボタンをクリックする。
    図20. 新規のグループに名前を付ける
    図20. 新規のグループに名前を付ける
  3. 「Manage Members」ペインで、Create & add new membersフィールドにおいてMapReduceジョブの名前を入力し、Addボタンをクリックして本メンバーをグループに追加する。その後、図21のとおり、ジョブの名前をさらに追加する。MapReduceジョブの名前の追加が完了した時点で、Backボタンをクリックする。
    図21. グループに承認済みのジョブを追加する
    図21. グループに承認済みのジョブを追加する
  4. 図22のとおり、Group Builderにおいて「Modify Existing Groups」の一覧に本グループが含まれていることを確認し、Rolesボタンをクリックする。.
    図22. グループにロールを関連付ける
    図22. グループにロールを関連付ける
  5. 5. 本グループを使用できるロールを選択する。(ここでは単純に、図23のとおりAll Rolesを選択します。)Applyボタンをクリックする。
    図23. 本グループを使用できるロールを指定する
    図23. 本グループを使用できるロールを指定する

「Hadoop Authorized Job List」グループを作成するタスクが完了したため、次のタスクに進み、本グループとレポートの関連付けを行います。

  1. InfoSphere Guardiumに含まれるHadoopレポート」セクションで説明したとおり、ユーザー権限でログインしている場合は、Viewタブをクリックすることによって事前に設定されたレポートを参照することができます。左側のナビゲーション・ペインから「Hadoop」をクリックすると、レポートが表示されます。
  2. 「Hadoop – Unauthorized MapReduce Jobs」をクリックします。「No data found」と表示されます。図24のとおり、鉛筆のアイコンをクリックすることによって、本レポートをカスタマイズします。.
    図24. レポートをカスタマイズする
    図24. レポートをカスタマイズする
  3. 図25のとおり、一覧から本グループの名前を選択します。本レポートが正しく機能していることを確認するために、少なくとも何らかの検索結果が表示されることが確実に分かっている期間をデータ・パラメーターとして指定します。その後、Updateボタンをクリックします。
    図25. ランタイム・パラメーターに本グループを追加する
    shows the authorized group list added to the report runtime parms.
  4. 左側のナビゲーション・ペインから、再度Hadoop – Unauthorized MapReduce Jobsレポートをクリックします。承認済みのジョブ・グループに含まれないレポートに関するデータが表示されるはずです。本レポートの一部を図 26に示します。ジョブの名前として「PiEstimator」が表示されていますが、これは本ジョブが承認済みのジョブの一覧に含まれていないためです。
    図26. レポートには、承認済みのジョブ・グループに含まれないジョブのアクティビティーが含まれる
    図26. レポートには、承認済みのジョブ・グループに含まれないジョブのアクティビティーが含まれる

異常な件数のパーミッション・エラーが発生していないか検証する

InfoSphere Guardiumは、Hadoop環境で発生した例外状況を検出するための標準機能を提供します。ユーザー権限でログインすると、View > Hadoop > Hadoop - Exception Reportとクリックすることによって、図27で示されるような標準レポートを参照することができます。

図27. Hadoop環境の例外レポートのサンプル
図27. Hadoop環境の例外レポートのサンプル

本レポートで使用されるクエリーと同じクエリーを使用して、アラートを作成することもできます。アラートを設定することによって、特定の条件(ファイル・パーミッションに関する例外状況など)が一定の限度を超えると電子メールが送信されます。

アラートをポリシー違反として記録することもできます。この場合、アラートはInfoSphere Guardiumの「Incident Management」タブで管理することができます。

例外状況を検索するクエリーを作成し、アラートを有効化するステップの概要は以下のとおりです。

  1. Alert Builderにアクセスする。
    • 管理者の場合は、Tools>Config and Control> Alert Builderとクリックする。
    • ユーザーの場合は、Protect>Correlation Alert> Alert Builderとクリックする。
  2. 「Alert Finder」の画面でNewボタンをクリックする。
  3. 図28のとおり、「Add Alert」画面の「Query Definition」セクションで、プルダウン・メニューからHadoop – Exception Report を選択し、その他のアラート条件を設定する。
    図 28. 例外レポートのクエリーを使用して、アラートを作成する
    例外レポートのクエリーを使用して、アラートを作成する

図29は、本記事のために作成されたアラートの例です。ファイル・パーミッションの例外として例外番号101を規定しています。

図29. Alert Builder
図29. Alert Builder

アラートはポリシー違反として記録されるため、生成されたアラートはIncident Managementタブにも表示されます。また、上記の画面の下部に表示されるとおり、アラートが生成されるとDavid Rozという名前の管理者に少なくとも1通の電子メールが送信されます。


結論

本記事では、InfoSphere Guardiumを使用してセキュアなCloudera Hadoop環境を実現する方法について説明しました。Hadoopを使用中または評価中で、本システムに関するセキュリティー戦略を検討している場合、本記事で説明される情報を参照することによって、IndoSphere Guardiumに基づいてセキュリティーを実現する方法を確認することができます。既にInfoSphere Guardiumを使用しているユーザーは、現在のデータ・セキュリティー・プロセスと監査プロセスを簡単に拡張することによって、Hadoopに対応することができます。

謝辞

本記事の作成にあたって多大な協力を提供してくれた以下のメンバーに感謝します。

  • レポートとポリシーの構築方法のアドバイス提供、さまざまなサポート提供:David Rozenblat
  • 解決すべきビジネス上の課題の例示:Joe DiPietro
  • 技術的側面に関するアドバイス提供:Ury Segal

参照資料A: IBM InfoSphere BigInsightsにおいてGuardium Proxyを設定する

本参照資料は、IBM InfoSphere BigInsightsにおいてGuardium Proxyを有効化することによって、関連するログ・メッセージのコピーをInfoSphere Guardiumに送信する方法について説明します。

本ソリューションのアーキテクチャーは、図30のとおりです。

図30. Guardium Proxyに送信された後、InfoSphere Guardiumコレクターに転送されるログ・メッセージ
図30. Guardium Proxyに送信された後、InfoSphere Guardiumコレクターに転送されるログ・メッセージ

まずGuardium Proxyの有効化を行い、その後クラスター内に存在するlog4jプロパティーのファイル上でGuardium Proxyのログ・アペンダーを設定することによって、ログに記録されたイベントがネーム・ノード上のGuardium Proxyに送信されます。ログ・イベントはソケット接続で送信されます。ソケット接続には、ポート番号16015が使用されます。その後、本プロキシーがInforSphere Guardiumコレクターにメッセージを転送し(標準ポートとしてポート番号16016を使用)、本コレクターがGuardiumの内部テーブルでメッセージの解析と保存を行い、レポーティングやアラートの生成などを実行します。

本ソリューションを設定するためには、以下のステップが必要です。

  1. システム統合のプランを立てる
  2. システム統合を実現する
  3. log4jプロパティーのファイルを設定し、クラスター内でプロパティーの同期を行う
  4. ネーム・ノード上でGuardiumProxyを起動し、その後Hadoopを再起動する
  5. コンフィギュレーションを検証する

システム統合のプランを立てる

次のステップに進む前に、以下の情報を確認します。

  • IBM BigInsightsの適切なバージョンが稼働していることを確認する(IBM BigInsightsのEnterprise Editionのバージョン1.4以降が必要)。
  • InfoSphere GuardiumコレクターとHadoopクラスターのネーム・ノードのIPアドレスを確認する。
  • 担当者に、BigInsightsのプロパティーとログ・ファイルの設定を修正する権限が設定されていることを確認する(biadmin権限が必要)。

システム統合を実現する

プロパティー・ファイルの変更を行う前に、BigInsightsの全てのサービスを停止します。そのためのスクリプトは以下のロケーションにあります。 $BIGINSIGHTS_HOME/bin.

  • stop-all.sh によって、Hadoopによる全てのサービスを停止することができます。
  • stop.sh hadoop oozieによって、HadoopとOozieによるサービスを停止することができます。

IBM BigInsightsとInfoSphere Guardium間のシステム統合の有効化と無効化を行うには、以下のロケーションに存在するファイルを使用します。
$BIGINSIGHTS_HOME/conf/guardiumproxy.properties

  • guardiumproxy.enable:標準では「yes」と設定されています。本設定を「yes」に変更すると、IBM BigInsightsとInfoSphere Guardiumの間でシステム統合を実現することができます。
  • guardiumproxy.host:Guardium Proxyが存在するホストを指します。標準では、BigInsightsがインストールされたネーム・ノードに設定されています。クラスター内のベストのホスト上で起動する場合を除いて、本設定を変更する必要はありません。
  • guardiumproxy.port: Guardium Proxyがログ・メッセージを受領するポートを指します。標準の値として、「16015」と設定します。
  • guardium.server: InfoSphere GuardiumコレクターのIPアドレスを指します。
  • guardium.server.port:InfoSphere Guardiumコレクターがログ・メッセージを受領するポートを指します。標準の値として、「16016」と設定します。

プロキシー・ファイルのサンプルは以下のとおりです。

リスト1. IBM InfoSphere BigInsightsのGuardium Proxyファイル
# Flag to enable or disable guardium proxy. Turn off this switch, user won't be 
# able to start guardium proxy. If turn it on, run start.sh guardiumproxy to start 
# proxy on Biginsights NameNode ( by default on hdfs, other FS uses jobtracker ), 
# it communicates the guardium server defined in guardium.server, 
# sends messages to the server. 
# After start guardium proxy, log4j.properties files in hadoop/oozie component must be 
# updated based on the template, then restart hadoop/oozie. 
guardiumproxy.enable=yes
                
# The hostname or ip address a guardium proxy instance will be running on, only one host
# can be specified for this property.
guardiumproxy.host=hadoop-bigi-node01.guard.nnn.nnnn.ibm.com
                
# The port guardium proxy will be listening on.
guardiumproxy.host.port=16015
                
# The maximum size in megabyte the message queue in guardiumproxy will approx. use, 
#   audit log events arriving at guardium proxy will be dropped if queue is full.
# Recommended default: 100 MB
guardiumproxy.queue.maxsize=100
                
# The timeout in seconds the guardium proxy will wait in case of a 
# refused or lost connection to the Guardium server.
# Recommended default: 60 seconds
guardiumproxy.reconnection_timeout=60
                
# The timeout in seconds until a background script restarts a guardium proxy
# (JVM) in case it terminated.
# Recommended default: 600 seconds
guardiumproxy.restart_timeout=600
                
# The log4j logging level on which the guardiumproxy will log about such 
# events like connection status and failures
#   set to DEBUG to retrieve information for each processed audit log, 
# but use INFO in productive mode
#   valid values are FATAL, ERROR, WARN, INFO, DEBUG
# Recommended default: INFO
#guardiumproxy.loglevel=DEBUG
guardiumproxy.loglevel=INFO
                
# The host name or ip address where a guardium server is running. 
# ake sure the guardiumproxy.host  can connect to the server host.
guardium.server=nnnn.guard.nnn.nnnn.ibm.com
                
# The port guardium server is listening on.
guardium.server.port=16016

log4jプロパティーのファイルを設定し、プロパティーの同期を行う

本ステップでは、ネーム・ノード上で2種類のlog4jプロパティーのファイルを修正することによって、InfoSphere BigInsights (Guardium Proxy)がどのようなログ・メッセージをInfoSphere Guardiumに送信すべきかを指定し、その後クラスター内で変更内容を同期することができます。修正が必要な2種類のファイルとは以下のとおりです。

  • HDFS、MapReduce、およびHadoop RPCの場合は、以下のファイルを修正します。 $BIGINSIGHTS_HOME/hdm/hadoop-conf-staging/log4j(を参照)
  • Oozieの場合は、以下のファイルを修正します。 $BIGINSINGHTS_HOME/hdm/components/oozie/conf/oozie-log4j.properties(を参照)

どちらの場合でも、Guardium Proxyがログ・メッセージを受領するポート番号(16015)とネーム・ノードのIPアドレスを検証する必要があります(標準コンフィギュレーションに基づいて、Guardium Proxyがネーム・ノード上で稼働している場合)。どちらのファイルの場合でも、いくつかの行を非コメント化する必要があり、非コメント化の対象となる行はファイルで明示されています。

リスト2. HDFS、MapReduce、およびHadoop RPCに関する、BigInsightsのlog4j設定
# GUARDIUM PROXY INTEGRATION - Setup for HDFS, MapReduce and Hadoop RPC
# Set up following lines
log4j.appender.GuardiumProxyAppender=org.apache.log4j.net.SocketAppender
# Set RemoteHost to cluster node (main node, the one from which you installed BI)
log4j.appender.GuardiumProxyAppender.RemoteHost=hadoop-bigi-node01.guard.swg.usma.ibm.com
# When changing the Port for cluster-intern communication with GuardiumProxy,
#   also change it in $BIGINSIGHTS_HOME/conf/guardiumproxy.properties (main node)
log4j.appender.GuardiumProxyAppender.Port=16015
log4j.appender.GuardiumProxyAppender.Threshold=INFO
# MapReduce audit log Guardium integration: Uncomment to enable
log4j.logger.org.apache.hadoop.mapred.AuditLogger=INFO, GuardiumProxyAppender
log4j.additivity.org.apache.hadoop.mapred.AuditLogger=false
# Hadoop RPC audit log Guardium integration: Uncomment to enable
log4j.logger.SecurityLogger=INFO, GuardiumProxyAppender
log4j.additivity.SecurityLogger=false
# GUARDIUM PROXY INTEGRATION - End of Setup
リスト3. Oozieに関するBigInsightsのlog4j設定
# GUARDIUM PROXY INTEGRATION - Setup for HDFS, MapReduce and Hadoop RPC
# GUARDIUM PROXY INTEGRATION - Setup for Oozie
# Set up following lines
log4j.appender.GuardiumProxyAppender=org.apache.log4j.net.SocketAppender
# Set RemoteHost to cluster node (main node, the one from which you installed BI)
log4j.appender.GuardiumProxyAppender.RemoteHost=hadoop-bigi-node01.guard.swg.usma.ibm.com
# When changing the Port for cluster-intern communication with GuardiumProxy,
#   also change it in $BIGINSIGHTS_HOME/conf/guardiumproxy.properties (main node)
log4j.appender.GuardiumProxyAppender.Port=16015
log4j.appender.GuardiumProxyAppender.Threshold=INFO
# Oozie audit log Guardium integration: 
#    Switch (un)comment between lines to enable GuardiumProxyAppender for Oozie
#log4j.logger.oozieaudit=INFO, oozieaudit (make sure this line is COMMENTED OUT)
log4j.logger.oozieaudit=INFO, oozieaudit, GuardiumProxyAppender (UNCOMMENT this line)
# GUARDIUM PROXY INTEGRATION - End of Setup

ファイルの同期を行う: プロパティーのファイルを更新後、 $BIGINSIGHTS_HOME/binにアクセスし、syncconf.shを起動します。

Hadoopを再起動する

Hadoop(およびGuardium Proxy)を再起動することによって、変更を有効化する必要があります。Hadoopサービスを再起動することによって、Guardium Proxyを自動的に起動することができます(上記のプロパティー・ファイルにおいて適切にGuardium Proxyを有効化済みの場合)。再起動のためのスクリプトは、以下のロケーションにあります。 $BIGINSIGHTS_HOME/bin

  • start-all.sh によって、Guardium Proxyを含む全てのHadoopサービスを起動することができます。
  • start.sh hadoop oozie guardiumproxyによって、Hadoop、Oozie、およびGuardium Proxyを起動することができます。

コンフィギュレーションを検証する

ジョブ(サンプルのワードカウント・ジョブを含む)をサブミットし、InfoSphere Guardiumのレポートで結果を参照することによって、コンフィギュレーションが正しく設定されたことをテストすることができます。

BigInsightsのWebコンソールからジョブをサブミットします。本プロセスの実行方法については、参考文献セクションで示されるBighInsightsのインフォメーション・センターをご参照ください。

ユーザー権限でInfoSphere GuardiumのWebコンソールにログインし、Hadoopレポートのうちの1つ(「BigInsights - MapReduce」など)を選択します。図31では、プロキシーを使用してBigInsights上でMapReduceレポートを選択した場合の分析結果を示しています。

図31. BigInsightsが提供するMapReduceレポートの一部

クリックして大きなイメージを見る

図31. BigInsightsが提供するMapReduceレポートの一部

パーミッションに関する情報は、本レポートのフルSQLのセクションで確認することができます。本レポートでは、ジョブの名前やジョブをサブミットしたユーザー名の情報に加え、ジョブのjarファイル名の情報までもが含まれていることが分かります。本情報はフルメッセージから解析を行った結果であり、レポートのフィールドとして表示されるため、このようなフィールドに対して様々な処理(アラートの生成など)を行うことができます。レポートのカスタマイズに関する詳細情報については、本記事の本セクションをご参照ください。


参照資料B: サンプルのGuardAPIコマンドを使用して、モニタリング・エンジンの設定を行う

コマンドラインからInfoSphere Guardiumの機能にアクセスできるGuardAPIを使用することによって、繰り返し実行されるタスクを自動化することができます。このようなコマンドを実行するには、コマンドライン・インターフェース(CLI)のアカウントでログインし、管理者またはCLIのロールが設定されている必要があります。本APIに関するさらに詳細な情報については、InfoSphere Guardiumのオンライン・ガイドをご参照ください。

リスト4は、本記事のサンプル環境においてAPIを使用してモニタリング・エンジンを作成した際に使用したコマンドを示しています。

リスト4. 本記事のサンプル環境においてモニタリング・エンジンを設定するために使用したgrdapiコマンド
#hdfs job tracker, hdfs name node beeswax server 
grdapi create_stap_inspection_engine client=0.0.0.0/0.0.0.0 protocol=HADOOP 
ktapDbPort=8021 portMax=8021 portMin=8000 stapHost=<My Hadoop Node IP>
                
#Mapreduce job tracker, cloudera agent and thrift plugin
grdapi create_stap_inspection_engine client=0.0.0.0/0.0.0.0 protocol=HADOOP 
ktapDbPort=9291 portMax=9291 portMin=9000 stapHost= <My Hadoop Node IP>
                
#hive server, thrift plugin
grdapi create_stap_inspection_engine client=0.0.0.0/0.0.0.0 protocol=HADOOP 
ktapDbPort=10090 portMax=10090 portMin=10000 stapHost= <My Hadoop Node IP>
                
#HDFS name node ports
grdapi create_stap_inspection_engine client=0.0.0.0/0.0.0.0 protocol=HADOOP 
ktapDbPort=50470 portMax=50470 portMin=50010 stapHost= <My Hadoop Node IP>
                
#HBase region servers
grdapi create_stap_inspection_engine client=0.0.0.0/0.0.0.0 protocol=HADOOP 
KtapDbPort=60010 portMax=60010 portMin=60000 stapHost= <My Hadoop Node IP>

使用するモニタリング・エンジンは、Hadoopノードにインストールされた該当するサービスを提供するHadoopノードに適切に合致する必要があります。上記の例では1ノードのシンプルな構成であったため、モニタリング・エンジンは似通ったポート番号に基づいて設定されています。ユーザーの環境によっては、コンフィギュレーションがより複雑になる場合があります。


参照資料C. Guardiumのコマンドライン・インターフェース(CLI)を使用することによって、Hadoopによって発生するノイズを除外する

InfoSphere Guardiumは機能豊富なコマンドライン・インターフェース(CLI)を提供します。CLI(除外対象の特定のHadoopのアプリケーションやパターンを指定する「store gdm_analyzer_rule new」コマンド)を使用して直接コレクターの分析コンポーネントを設定することによって、セキュリティー・ポリシーを使用することなく、Hadoopによって発生するノイズを除外することができます。リスト5は、本コマンドを使用してHbaseのgetServerRegionメッセージを除外するプロセスの例を示しています。

リスト5. CLIを使用して、コレクターのフィルタリング機能を修正する
store gdm_analyzer_rule new
Please enter rule description (optional): HDP
Please enter rule type (required): 5
Please enter rule acdtion (optional. Default to 0):
Please enter active flag (optional. Default to 1):
Please enter DB protocol (required): 25
Please enter server IP (optional):
Please enter server IP mask (optional. Default to 255.255.255.255):
Please enter service name (optional):
Please enter pattern (optional): getServerRegion
Please enter format (optional): 1

重要なオプションとしては、以下があります。

  • Rule type:Hadoopの除外ルールを設定するために、「5」を指定する。
  • Rule action:標準設定をそのまま使用する。
  • DB Protocol:Hadoopの設定を行うために、「25」を指定する。
  • Pattern:除外対象となるメッセージ・パターンの名称(大文字と小文字を区別すること)を入力する。
  • Format:除外対象のHadoopサービスのコードを入力する。入力可能な値としては、以下があります。
    0 - HDFS
    1 - HBase
    2 - Hadoop IPC
    3 - ジョブ・トラッカー

参考文献

学ぶために

製品や技術を入手するために

  • developerWorksから直接ダウンロード可能なIBMの試用版ソフトウェアを活用することによって、次の開発プロジェクトに役立てることができます。
  • 最適な方法でIBM製品を評価することができます。評価版の製品をダウンロードし、製品をオンラインで使用し、クラウド環境で製品を使用し、SOAサンドボックス上で数時間をかけて効率的にサービス指向アーキテクチャーを実装する方法について学ぶことができます。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=854667
ArticleTitle=IBM InfoSphere Guardiumを使用して、ビッグデータのセキュリティーと監査を実現するには
publish-date=01302013