第2回 個人情報保護法とIT (2) アクセス記録と分析|これからの銀行を支えるIT戦略
金融庁の実務指針において、個人情報を扱うシステムに求められている主要要件は、1)システムの監視と監査、2)アクセス制御と毀損防止、3)利用者認証、の3つです。それぞれの要求事項を充足するためには、稼働中システムの既存機能の活用や、手運用でカバーできる分野も多く存在します。しかし中には、新しいIT技術の力を活用することで、大きな効果を得られる分野もあります。今回から3回に渡って、それらのIT技術を紹介していきます。
要求項目 | 有効なIT技術 | |
---|---|---|
1 | システムの監視と監査 | アクセス記録と分析 |
2 | アクセス制御と毀損防止 | 暗号化 |
3 | 利用者認証 | 本人確認機能 |
初回は、「システムの監視と監査」における「アクセス記録と分析」についてふれて行きます。
システムの監視と監査
実務指針においては、「システムの監視と監査」に関する要件は、4.5条~4.7条にて定義されています。
- 4.5条
- 個人データへのアクセス記録と分析
- 4.6条
- 個人データを取り扱う情報システムの稼動状況の記録及び分析
- 4.7条
- 個人データを取り扱う情報システムの監視及び監査
これら要件の中で、「個人データへのアクセス記録と分析」については、新たなIT技術を活用することで、大きな効果が期待できる分野の一つです。
【FISCの安全対策基準での要件】
FISCの安全対策基準(以下"安対基準"とします)では、技術基準37項で「アクセス記録と分析」について記述されています。その中では次の3つ対策が必須とされています。
- アクセス履歴取得と保管及び定期的なチェック
- アクセス履歴に基づく不正アクセスの分析と報告
- アクセス履歴の改ざん防止
- ログイン/ログオフ状況(指示端末、時刻、ID、行った処理)
- 不正なアクセス要求(指示端末、時刻、ID)
要は安対基準では、ただアクセス履歴を取得すれば良いのではなく、「必要情報の収集」、「不正アクセスの監視」、「アクセス履歴の保全」を求めています。
【身近なシステムも対象範囲に】
金融機関においては、同等な要件が金融検査マニュアルのチェック項目に包含されており、金融機関のデータセンターで運用されているような中枢システムであれば、ほぼ間違いなくそれらの要件は充足されているはずです。
しかし今回の実務指針では「個人データを扱うシステム」に焦点があてられているために、金融機関のデータセンターで運用されている中枢システムだけではなく、本部や営業店で使われている「部門システム」や「端末」までもがその対象範囲になりました。扱うデータの重要度に応じて、対応策の濃淡や優先順位はあってしかるべきですが、個人データを蓄積するデータベースで対応がまだ行われていないものがあれば、すぐにでも検討を行うべきです。
データベースでの対策
データベースに蓄積された個人データに対して、安対基準の要件を適用するにあたって、いくつかの考慮すべきポイントがあります。
- ユーザ識別での課題
- 運用上の課題
- 実現方法の選択
【1】 ユーザ識別での課題
昨今主流のWebベースのアプリケーションでは、データベースへのアクセスは、Webサーバ/アプリケーションサーバ経由で行われます。その場合データベースから見ると、利用しているユーザは「アプリケーションサーバ」と認識され、実際にアクセスしている「エンドユーザ名」までは認識できません。対してデータベースに直接アクセスする場合は、アクセス履歴に「エンドユーザ名」が記録されます。
このような環境下で、必要十分なアクセス履歴を取得するには、2種類のアクセス履歴を組み合わせることが必要になります。- アプリケーション利用時のアクセス履歴は、アプリケーション側で取得
- 運用者のアクセス履歴は、データベース側で取得
データベースへのパフォーマンス影響の緩和や、システムリソース有効活用の観点から、データベース側では、必要な情報のみを取得することは有効な方策です。
【2】 運用上の課題
データベースにおけるアクセス記録と分析を行うに当たっては、運用上考慮すべきいくつかの課題があります。
【統合管理の必要性】監査対象のデータベースが複数に渡る場合は、アクセス履歴を統合的に監査できる仕組みを構築することで、1)アクセス履歴の分析、2)監査ルールの管理、3)アクセス履歴の保全、の各運用局面において効率化によるメリットが享受できます。
【データに応じた監査レベルの設定】
アクセス履歴については、取れる情報を全て取得する方法は簡単ではありますが、大半の情報は監査には必要ないもので、無駄が多く発生します。システムリソースの有効活用や運用上の観点からは、必要な情報だけを選別して取得することは望ましいと対策と言えます。本当に監査が必要なのは、一部の列やテーブルのみというのが一般的であり、対象となるデータの重要度に応じて監査レベルを設定することが、現実的かつ有効な運用方法です。
【3】 実現方法の選択
商用データベースには、アクセス履歴の取得機能は標準で装備されています。しかし安対基準で求められる「不正アクセスの監視」、「アクセス履歴の保全」については、十分な機能を持ち合わせていません。足りない機能を補完する意味で、監査ツールを活用することは有効な手段です。現状日本で販売されている監査ツールはいくつかありますが、それらはアクセス履歴の収集方式の違いによって3種類に分類できます。
比較項目 | 監査ログ方式 | システムメモリ方式 | シパケット補足方式 |
---|---|---|---|
アクセス履歴の収集源 | データベースの監査ログ | データベースのシステムメモリ | ネットワーク上に流れるパケット |
特長 | データベースの標準機能ゆえの確実性、安定性 | 標準機能に比べ、より詳細なアクセス履歴取得が可能 | データベースとは完全に独立した監査が可能 |
課題 | データベースへのパフォーマンス影響の調整が必要 | 全てのアクセス履歴が捕捉できない | パケットが暗号化されないことが前提 |
データベースのパフォーマンス | 影響あり | 影響あり(監査ログを併用する為) | 影響なし |
対応データベース | オラクル、その他 | オラクルのみ | オラクル、その他 |
ツール障害時アクセス履歴取得 | データベースの標準機能で、漏れなく履歴を蓄積 | 履歴取得漏れが発生する | 履歴取得漏れが発生する |
安対基準の要件に加えて、確実性や安定性の面からは、データベースにおけるパフォーマンスの問題が解決できるのであれば、3種の方式の中では、「監査ログ方式」に優位性があると考えます。
まとめ
金融庁をはじめ行政機関から、「個人情報を保護すること」という基本方針は示されるものの、金融機関毎に扱う情報の種類やシステムは異なるため、「どこまで対策すれば良いの?」という質問に答えてくれるような具体的な指針は、今後も出てこないと考えられます。
そのような中で、残念ながらどのような対策を行ったとしても、事故を100%防ぐことはできません。ただ唯一言えることは、事故が起こってしまった場合、本要件における対策の実施/検討を行っているかどうかによって、社会的信用や行政機関の判断は大きく変わってくるということです。企業におけるリスクを軽減するためにも、今一度身近で使っているシステムの対応状況を確認されてはいかがでしょうか。