| 2003年9月25日
『どっとねっとと雑多な日々 12』
先週まで、非常に暑い日が続いたかと思えば、今週は寒かったりと体調が悪くなりそうな季節になってきました。皆さんも気をつけてください。
さて、今回は ADO.NET の ConnectionString について考えてみたいと思います。
SQL Server への接続の場合、認証方法は 2 つあります。
1.信頼関係接続
2.SQL Server 認証(混合モード）接続
1. については、プログラムを動作させているユーザの ID で SQL Server に接続させるもので、ユーザの ID
やパスワードを入力することはありません。ただ、SQL Server には( Windows の）実行ユーザを登録してあげる必要があります。
※ Administrators に所属している場合はデフォルトでは、登録の必要はありません。
ConnectionString の例
string connectionString = "Data Source=(local);Initial Catalog=pubs;Truested_Connection=yes;";
2.の場合は SQL Server に登録した SQL Server のユーザを明示的に指定して接続します。
ConnectionString の例
string connectionString = "Data Source=(local);Initial Catalog=pubs;User
ID=user1;Password=password;";
となります。
2.の場合、ここで考えなければいけないのが、セキュリティの確保です。1.の場合は Windows 認証のため、ID とパスワードの記述がありません。ですが、2.の場合は
ID と パスワードが埋め込まれています。
こういった情報をどこに保存するのかが問題になってきます。
1.Assembly の中に埋め込む。
2.App.config や Web.Config などの設定ファイルに記述。
3.レジストリに記述。
4.独自ファイルに記述。
...etc.
1.の Assembly に埋め込んだ場合は、Anakrino( http://www.saurik.com/net/exemplar/
) のようなツールを使えば、解析可能である。また、環境の変更に弱い。
※ Dotfuscator( http://www.preemptive.com/
) のようなツールを使えば難読化は可能。
2.の場合は、.config ファイルを見られたら、終わり。しかし、環境の変更には比較的容易に対応できる。Web の場合は、ツールと
identity 記述を使うことにより、レジストリに情報を格納することが可能。
http://support.microsoft.com/default.aspx?scid=kb;ja;329290
3.の場合は、ある程度セキュリティを確保することは可能であるが、配布する場合、難しい局面がある。
4.の場合は、ある程度セキュリティを確保することは可能であるが、これも万全ではない。
と一長一短があります。
さて、皆さんならどうします？
可能であれば、Windows 認証を使うことが一番よいと思いますが、それができない場合は、それぞれの状況を考えた上で、最善の方法を選択する必要があります。ベストは状況次第なので、一概にはいえませんが、少なくとも誰でも見ることができるような形を選択しないことが重要となってくると私は考えます。
もし、この件で何かよいアイディア、意見などがありましたら、
pml-web@sqlpassj.org
の ML で議論しましょう。
|
