ちゃっぴの監禁部屋

ガチガチに締めすぎて動きがとれなくなる。。。

ホーム 連絡をする 同期する ( RSS 2.0 ) Login
投稿数  405  : 記事  5  : コメント  12074  : トラックバック  134

ニュース

記事カテゴリ

書庫

日記カテゴリ

Communities

Personal Information

SQL injection を防ぐもうひとつの方法

DB への接続 user を共用した場合の client-server 構成での 問題点

上記で SQL injection の根本的原因は DBMS で access control を行っていないことだと述べました。

DB への接続 user を個人単位で割り当て DBMS の acess control で制御してやりたいが、要求される performance と resource のため、どうしても利用することが難しい。そんな場合もあると思います。でも、DB への接続 user を共用化した場合は DBMS の access control を全く利用できないんでしょうか?

違いますよね。DB への接続 user を共用化するといっても、user は一つしか使ってはいけないということはないでしょう。処理の内容によって user を使い分けることはできるはずです。

たとえば、SELECT と UPDATE する user を分ける。Logon に利用する user も分離する。重要な data を扱う user も分離する。そして、それぞれ必要な最小限の権限のみ割り当てれる。

こうゆうことをやれば多少なりとも驚異を軽減することにつながるでしょう。Performance に関しても高々数 user を追加したところでさして変わるとは思えませんし。

多層で防御すればするほど security level は向上します。Stored procedure なり、parameterized query なり、sanitizing なりで SQL injection 対策を行うとともに、このような方法も検討してみてはいかがでしょうか?

投稿日時 : 2008年5月11日 21:03

コメント

# re: DB への接続 user を共用する場合でも少しでも脅威を軽減できるように設計しよう 2008/05/12 15:02 凪瀬
そういえばデータのアクセス権限を管理するための設計パラダイムってあったっけ?
DBとの接合部分だけではなく、システム全体を通してアクセス権を管理できるような方法論ってどうなりますかね。

# re: DB への接続 user を共用する場合でも少しでも脅威を軽減できるように設計しよう 2008/05/12 22:35 ちゃっぴ
太古の昔からある最小権限の原則を徹底して、resource も必要なもののみ扱えるように制限をするってところですかね。

System 全体という意味だと、Windows 環境では Active Directory で一括管理可能ですね。Resource へは group 単位で ACL を設定して、user は その group へ参加させる。Microsoft 製品では固めるとこういうことが楽にできますね。

Post Feedback

タイトル
名前
Url:
コメント