Hadoopが扱う機密データのマスキングについて

CDH 5.4 から導入された、Sensitive Data Redaction (機密データのマスキング) 機能を紹介します。

# できること
Hadoopクラスタのログファイル、Hive/Impalaクエリに含まれる任意の機密データのマスキングが可能です。

# 必要なもの
CDH 5.4 / Cloudera Manager 5.4

# 手順
1. Cloudera Managerにログインし、HDFSサービスを選択します。

![Screen Shot 2015-07-17 at 20.01.07.png](https://qiita-image-store.s3.amazonaws.com/0/32466/d467fb9a-bc65-396c-5211-4e04fcb25deb.png)
　
2. HDFSの設定画面で、「redaction」で検索します。

![Screen Shot 2015-07-17 at 20.29.49.png](https://qiita-image-store.s3.amazonaws.com/0/32466/819c8b27-9a85-79d0-7434-27e64f92ddcb.png)
　
3. デフォルトでは「クレジットカード情報」、「社会保障番号」、「ホスト名」、「メールアドレス」のマスキングテンプレートが用意されています。カスタムのマスキングを定義することも可能です。ここではクレジットカード情報をマスキングします。　

![Screen Shot 2015-07-17 at 20.03.13.png](https://lh3.googleusercontent.com/LqYR4KUvE2nRk2Q-VFOsqmjjuKyS5ZrwuoXILZ8jcVY=w696-h283-no)
![Screen Shot 2015-07-17 at 20.03.30.png](https://qiita-image-store.s3.amazonaws.com/0/32466/90335ffe-18c1-5237-5e15-49f3375f11ea.png)
　
4. 設定画面内で、マスキングがどのように動作するのか、テストすることができます。

![Screen Shot 2015-07-17 at 20.03.50.png](https://qiita-image-store.s3.amazonaws.com/0/32466/8006b9fc-6708-efe0-6876-7d80adf440da.png)

ポリシーに従い、マスキングされることが確認できました。変更を保存したらHDFS/YARN/Hive/Hueを再起動しましょう。
　
5. テストに使用するテーブルには以下のようなレコードが入っています。

![Screen Shot 2015-07-17 at 20.18.58.png](https://qiita-image-store.s3.amazonaws.com/0/32466/8301906a-60c2-6ade-364a-e573b7ba9373.png)
　
6. Hueからクエリを実行します。実行すると、気の利いた警告がバナーとして表示されます。

![Screen Shot 2015-07-17 at 20.25.05.png](https://lh3.googleusercontent.com/uJI7xSocLszu53_XHSX5twORjwtSZY8gQ4MmST4Cwkc=w845-h347-no)
　
7. 完了後、クエリの履歴を見てみましょう。

![](https://lh5.googleusercontent.com/-Zg6b3j1zu9g/Vaju-8-6wUI/AAAAAAAAZj0/1fnX8MjpbrM/w802-h441-no/Screen%2BShot%2B2015-07-17%2Bat%2B20.25.20.png)

クレジットカード情報がマスキングされています。
　
8. ジョブの設定ファイルにもクエリが記録されています。見てみましょう。

![](https://lh3.googleusercontent.com/qc07nEPPQSsX9w3jUs7gxH0pWJT4HNX-wtREpLXIHRE=w1097-h276-no)

通常であればWHERE句に表示されるはずのクレジットカード番号が、マスキングされています。
　
9. HiveServer2のログにもクエリが記録されますが、こちらもマスキングされています。

![](https://lh5.googleusercontent.com/-ksSSKlkc0n0/Vaju-8ZBHQI/AAAAAAAAZj4/ce2y1Fedf9g/w991-h44-no/Screen%2BShot%2B2015-07-17%2Bat%2B20.31.55.png)

# 仕組み
ログのマスキングにはLog4JのAppenderであるlogredactorを使用しています。対象のロガーをラップすることで、定義されたルールに基づいたマスキングを行っています。

https://github.com/cloudera/logredactor

Hiveが各所に記録するクエリ情報のマスキングには、下記JIRAで追加されたフック（書き込み時のインタフェース）をしかけることで対処しています。

https://issues.apache.org/jira/browse/HIVE-9408
https://issues.apache.org/jira/browse/HIVE-9994

Impalaの場合はBackendのサーバでマスキングし、各WebUIやログファイルに転送しています。

https://github.com/cloudera/impala/commit/803a95cc1b0fe02ea172d171103f0f0a4cc34fb7#diff-cbda887fc762b129fac6f0e34c5da698
https://github.com/cloudera/impala/commit/1f04e665e622dfc95fd1ae5747437597c9b43164

# 最後に
Hadoopに企業内のあらゆるデータが格納されるようになり、昨今ではクラスタのセキュア化は非常に重要な要件のひとつとなっています。Hadoopでは認証、認可、監査、暗号化といった各セキュリティ要件を満たすよう改善が進められているわけですが、せっかくセキュア化したデータも、ログやクエリの実行履歴から見えてしまっては困るというケースもあるでしょう。

たとえば、ある金融機関に、クラスタの運用チームとデータ解析チームがあるとします。データ解析チームにはすべての顧客のクレジットカード情報を閲覧できる権限が付与されていますが、運用チームには付与されていません。データ解析チームは ```select * from table where creditcard = '1234-5678-9012-3456';``` といった形で分析クエリを実行できますが、運用チームにはできません。しかし、運用チームにはログやWebUIの参照権限がありますので、WHERE句の中身が丸見えです。

本記事で紹介したマスキング機能を使えば、あらかじめ指定したフォーマットに合致する情報を、ログやクエリの履歴情報から削除することで上記のセキュリティリスクを回避できます。クラスタの実データやメタデータに手を加えるわけではなく、Kerberos認証などの前準備も不要なので、比較的気軽にとりかかれるのではないでしょうか。

## ドキュメント
http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/sg_redaction.html
http://blog.cloudera.com/blog/2015/06/new-in-cdh-5-4-sensitive-data-redaction/