DBセキュリティを見直す
今年４月に起きた、三菱UFJ証券の個人情報漏洩事件
。
（過去ネタですいません）
事件の内容を、おさらいしますと・・・・、
「部長代理の元社員が、情報を引き出す際、他の社員のＩＤとパスワードを使って
顧客データベース
に接続していたことがわかった。
同社のデータベースへの接続権限を持っていた社員は、部長代理を含め計８人もいた。
部長代理は、接続権限を持つ他の社員のＩＤとパスワードを入手し、これらの個人情報を使って、約１０日の間に、データベースに複数回接続し、顧客情報
を取り出していた」、
という。
私は元々、DB(Oracle、SQLServerなど）の設計技術者です。
過去の経験から、意外と、大手と呼ばれる企業のＤＢのユーザの権限管理はそんなに厳しくないな、と感じていました。（勿論、全部の企業がきちんとしていない、とは言いません）
まず、ＤＢ管理者権限（OracleでいうＳＹＳＴＥＭユーザ）のパスワードなど、簡単に予測がつきそうな英数字３文字とか５文字とかで設定されており、外注を含めた複数の開発者が知っており、悪意を持った人がいれば、本番データの持ち出しもいくらでも可能、といった危険なケースもいくつかありました。
※当然、ＤＢ管理者権限は、ＤＢ内で何でもできちゃいます
ＤＢのアクセス権限の管理も、それほど厳しくなく、監査ログのチェックなどを行っている所も
ほとんどなかったです。エンドユーザがＤＢセキュリティに詳しくない人であれば、ＤＢ管理者権限のパスワードが誰が知っているのか、まず関心を持ちません。大体、そういう危ないセキュリティ状況で納品されます。
あと、まず、ＤＢ管理者権限のパスワードは定期的に変更されることもありません。
本来であれば、ＤＢのアクセス権限も最小限に抑え、何か作業をする際は、
ＤＢ管理部門に作業申請書を提出し、作業内容以外のことは一切させないような運用（単独での作業も禁止）
と、定期的な監査ログのチェックが必要でしょう
まず他の社員のＩＤ，パスワードを簡単に知ることができて、管理職などがいつでも自由にアクセスできるといった運用をしていたから、今回のような事件が起きたと思います。
（システム部の管理職が悪意を持ったリスクを考え、それへの対策をたてなければなりませんね・・・・
システム部のお偉いさんだから、っていう特別扱いは通用しないようです）
三菱UFJ証券の個人情報漏洩事件は、ヒト事ではないな、・・・・と私は感じております
○●○●○●○●○●○●○●○●○●○●○●○
Ｐマークの取得をお考えの企業様へ 
取得まで完全サポート
の全額返金制度
気配りと真心！
誠意をもって対応します
資料請求、ご用命は
株式会社エイム･ソフト
情報セキュリティコンサルティング事業部
0120-966-831（フリーダイヤル）
○●○●○●○●○●○●○●○●○●○●○●○