あるアプリケーションから、DBサーバへの接続をしようとしています。
想定1(NonSecure)
DBサーバは社員全員が共有している内容であり、特にアクセス制限を掛ける必然性も、持ち出しをとめる必要もないという場合には、ID、パスワードを設定する必要性はないかもしれません。
プログラムにIDとパスワードを埋め込んで利用してしまいましょう。
メリット
セキュリティなんて考えなくていい幸せな環境なので、めいいっぱい享受できる
デメリット
セキュリティが問題になった際に取り返しがつかない
こういったパターンのプログラムをセキュアな物に改変するのはかなりコストがかかる
想定2(Login & ServerID)
ユーザは社員の一部でごく一部の限られたユーザしか利用してはいけません。
一部のユーザ以外が見ることのないようにアクセス制限を掛けたい。
アクセス制限にはDBサーバの機能を用いることとします。
メリット
アクセス権限をDBサーバ側で制御可能
ユーザ管理をそのDBサーバの管理ツールで行える
直接DBサーバにアクセスされても適切な権限下でしか振舞えない。(ただし全件DELETEなどは可能)
デメリット
DBサーバに詳しくない人がロールの付与などを適切に行えなかった場合に復旧が難しい
ユーザ管理プログラムを作らないと、実際の権限がどうなっているか確認しづらい
ユーザがフラットなため人数が増えると適切な管理がしづらい
同一のDBサーバのインスタンスに複数のサービスを入れる場合に、ロール管理などプログラム側で行うと、余計な権限を剥奪することになったりしかねない。(他システムとの兼ね合いが難しい)
パスワードが平文で流れてしまう
想定3(Login & ProgramID)
ユーザは社員の一部でごく一部の限られたユーザしか利用してはいけません。
一部のユーザ以外が見ることのないようにアクセス制限を掛けたい。
プログラムと、テーブル内の権限情報を用いることとします。
メリット
ユーザ(管理者)にDBサーバを意識しない管理が可能
業務的な権限付けがプログラムに閉じて行えるため、影響個所が減る
業務的なIDとパスワードが漏れても、業務アプリを経由しないDBサーバへの侵入は行えない。
デメリット
IDなどがEXEに埋め込まれているため平易にIDとパスワードを取得可能
IDが漏れた場合に全てのデータを閲覧されてしまう可能性がある
パスワードが平文で流れてしまう
想定4(Login & ServerID + Windows NT Authority)
ユーザは社員の一部でごく一部の限られたユーザしか利用してはいけません。
一部のユーザ以外が見ることのないようにアクセス制限を掛けたい。
アクセス制限にはWindows統合認証機能を用いることとします。
メリット
アクセス権限をDBサーバ側で制御可能
ユーザ管理をそのDBサーバの管理ツールで行える
直接DBサーバにアクセスされても適切な権限下でしか振舞えない。(ただし全件DELETEなどは可能)
認証は既に済んでいる前提なので、パスワードの管理を行う必要が無い。
デメリット
DBサーバに詳しくない人がロールの付与などを適切に行えなかった場合に復旧が難しい
ユーザ管理プログラムを作らないと、実際の権限がどうなっているか確認しづらい
ユーザがフラットなため人数が増えると適切な管理がしづらい
同一のDBサーバのインスタンスに複数のサービスを入れる場合に、ロール管理などプログラム側で行うと、余計な権限を剥奪することになったりしかねない。(他システムとの兼ね合いが難しい)
パスワードが平文で流れてしまう
Windows環境でしか利用できない。(SQLServer7以上? Oracle9以上? その他のマイナーRDBは?)
想定5(DB PROXY & ProgramID)
クライアントプログラムからは直接DBサーバにアクセスするのではなく、プロクシアプリ(XMLWebサービス)を経由させる。DBサーバにはプログラムアクセス用IDから固定IDで接続。
DBサーバにアクセスするべきIDとパスワードの入ったアセンブリはサーバにのみ配置する。
メリット
ユーザ(管理者)にDBサーバを意識しない管理が可能
業務的な権限付けがプログラムに閉じて行えるため、影響個所が減る
他のPC向けにDBサーバのポートを空けたりしなくて良い
パスワードはクライアントプログラムでハッシュ化可能
業務的なIDとパスワードが漏れても、業務アプリを経由しないDBサーバへの侵入は行えない。
全ての業務作業のログを記録することが可能
デメリット
n層アーキテクチャで言うところの1層増える
規模増加
最新版はこちらにあります。http://blogs.users.gr.jp/naka/articles/2971.aspx