2009年11月20日に、「金融分野における個人情報保護に関するガイドライン」(平成21年11月20日金融庁告示第63号)が更新されました。
ITにおける個人情報保護対策に焦点を絞ると、今までのガイドラインと比べ、技術的安全管理措置が明確になったと思われます。
第10条 安全管理措置(法第20条及び基本方針関連)の6の(技術的安全管理措置)を抜粋すると以下の通りです。
|
技術的安全管理措置 |
@ 個人データの利用者の識別及び認証 A 個人データの管理区分の設定及びアクセス制御 B 個人データへのアクセス権限の管理 C 個人データの漏えい・き損等防止策 D 個人データへのアクセスの記録及び分析 E 個人データを取り扱う情報システムの稼働状況の記録及び分析 F 個人データを取り扱う情報システムの監視及び監査 |
昨今、留まることを知らない情報漏えい事件ですが、今年は大手金融機関で事件が相次いぎ、そのためかこのガイドラインが改めて更新されたとの見方もあります。
しかしながら、このガイドラインも具体的な対応方法は記載されていません。それが、この個人情報保護対策を遅らせてしまっているのではないでしょうか。
PCIDSSのように、具体的にセキュリティ対策がガイドライン化されているものと比べ、非常に抽象的な内容に感じてしまいます。これでは、各金融機関も、形式だけ整えるようなITツールを誤って選択してしまうことにつながり、対応レベルがバラバラなりかねません。
技術的安全管理措置の@〜Fを拝見すると、
@〜Bがアクセス制限(ブロック)、
D〜Fがアクセス監査を指していると考えられ、
それらを対処することによってCが実現できる、
と捉えることができます。
不正なアクセスを予め制限する“アクセス制限”と、アクセスをすべて取得しておき、そのアクセスに不正がないか監査する“アクセス監査”を効果的に実施することが求められていると考えられます。
個人情報漏えい事件は、上図1〜3を通り抜ける権限を持った内部の方の犯罪です。よって、上図4のアクセス監査を実施しない限り、情報漏えい事件に終わりはありません。
そう考えると、ガイドラインのD、E、Fはアクセス監査に該当しますので、昨今の事件には非常に効果的と考えられます。(@、A、Bはアクセス制限。これももちろん重要です)
では具体的にどのような対策が考えられるのでしょうか。
「技術的安全管理措置」に記載のある“情報システム”を考えると、個人情報は“データベース”もしくは“ファイル”に格納されていると分類できます。
この二つの情報にアクセスした記録(ログ)を、“分析できる状態”で蓄積し、監査することを求められているわけです。
“分析”とはなんでしょうか。個人情報の参照を、誰が、いつ、どこから、どのような経路で、どれだけの量をアクセスしたか、を監査でき、またそれらの集計をして、月次もしくは年次ベースでアクセスの統計を把握し、利用状況を確認すること(Eより)だと考えられます。
これらの情報を保持するために、
データベースへのアクセス : SQL
ファイルへのアクセス : コンピュータの操作
を漏れなく保持し、“分析”できるように蓄積しておくことが求められると考えられます。
上記の対策を取るために、アクセスログを取得・保持するツールを検討されていると思われますが、ここで非常に重要なポイントがあります。
漏れなくアクセスログを蓄積するのは当然として、単に蓄積すれば良い、というものではないということです。
“個人情報保護”の対策でアクセスログを蓄積するわけですから、蓄積したアクセスが個人情報へのアクセスか否か、判断できなければ意味がありません。
ここで皆さんは、「それはアクセスログを見ればわかるだろう」と思われたかもしれませんが、1件1件アクセスログを見ていけば、多大なる監査コストがかかることは明白です。
また、データベースへのアクセス言語SQLを理解して、どのようなアクセスかを判断するにはスキルが必要になりますし、担当者の異動があれば、そのスキルも引き継がなくてはなりません。
これでは「技術的安全管理措置」を実現することは非常に困難なことになります。
ポイントは、膨大なアクセスログの中から、個人情報へのアクセスかどうかを、人手ではなくシステム化して判断し、そのアクセスのみを抽出する機能が必要になります。
データベース、ファイル、それぞれで、個人情報かどうかの判断をするものは、
データベース : テーブル名、フィールド名
ファイル : ファイル名
と考えられます。よって、アクセスログは、テーブル、フィールド単位、およびファイル単位、に蓄積されていなけば、アクセス監査を実現することは困難と言えます。
よく、SQL文をそのままログとして蓄積するツールや、RDBMSから標準出力されるログを保管することで対策をされている企業を見受けますが、上記のログ蓄積ができていなければ、それはログを蓄積しているだけであり、「技術的安全管理措置」ができているとは言えないと思われます。
上記のポイントを踏まえたアクセスログを蓄積できれば、個人情報が格納されたテーブル、フィールド、及びファイルを事前に登録しておき、アクセスログと突合させることで自動監査が行えます。
また、監査ノウハウをIT化できていることになるため、引き継ぎも容易に行うことができ、投資対効果を望めます。
これらをすべて対応しているのがWEEDS Trace Seriesです。
昨今、アクセスログツールが注目されていますが、“単にログを蓄積するだけ”、“Windowsのイベントログなどの、OS既存のログを蓄積するだけ”(分析できるログ情報は取得できない)という製品が目立ちます。
しかし、本当に監査できる機能をもっていなければ、意味をなしません。よって、その投資は無駄になってしまいます。
我が社はITのプロとして、真の解決策、意味のある解決策をITでサポートすることが信念です。
ぜひ、本当の意味でのアクセス監査対策をWEEDS Trace Seriesで行って下さい。
製品のお問合せは、お電話(03-5950-6350)もしくはお問合せフォームからお気軽にどうぞ。
<技術的安全管理措置D〜F>
データベースアクセス監査 : WEEDS DB-Trace
Windows操作監査 : WEEDS Windows-SecureControl
UNIX操作監査 : WEEDS UNIX-Trace
<技術的安全管理措置@〜B>
Windows操作制限 : WEEDS Windows-Guardian
UNIX操作制限 : WEEDS UNIX-Guardian
「金融分野における個人情報保護に関するガイドライン」は、http://www.fsa.go.jp/common/law/kj-hogo/ へアクセスしていただき、ご確認下さい。
.jpg)