データベースへの接続文字列について
投稿者 魔界の仮面弁士 (社会人)
投稿日時
2022/6/9 11:18:21
「ネットワーク上の SQL Server インスタンスの一覧」は
SqlDataSourceEnumerator.Instance.GetDataSources() などで取得できます。
そのため、問題となるのは接続文字列というよりも認証部分だけでしょうね。
> データの集計などを行うWindowsフォームアプリケーションを作成しようとしています。
[EXE Application] ⇔ [Web Server] ⇔ [Database Server]
のように通信階層を一つ挟むという方法があります。
この場合、アプリケーション側にデータベースへのアクセス権を持たせる必要はなく、
SQL Server Client の導入も不要です。
EXE は単に、Web Service のための URL のみを知っていれば済みます。
データベースサーバーを別セグメントのネットワークに追い出せば、さらに安全。
> 悪意のあるユーザーが接続文字列にたどり着く可能性
えぇと、一般ユーザー向けに公開するアプリケーションではなく、社内向けのシステムなんですよね。
外部からの侵入や PC の無断利用は別途防御しているでしょうから、この場合の
「悪意あるユーザー」とは、内部犯行のことを想定しているのだと思いますが、
管理者や開発者自身の犯行だとどうにもならないので、その EXE を
誰が利用できる状態にしてあるか、という点も踏まえて、そこはコンプライアンスで…。
いずれにせよ、そうした点を気にするのであれば、普通は SQL Server 認証ではなく、
Active Directory などを組んで Windows 認証を採用すべきかと思います。
SQL 認証だと、パスワードを変更する必要が生じた場合の手間もかかりますし。
あるいは SQL 認証＋ハードウェアキーという組み合わせもありますが、
こちらはコストも手間もかかるので、今回の件では過剰になりそう。
> 一般的には外部のテキストファイルに接続文字列を書いておき、
ただのテキストを想定しているのであれば、一般的では無いと思います…。
.config と違って暗号化の仕組みも無いですし、むしろ脆弱性を広げる結果になるかと。
その設定ファイルに対する NTFS の読み取りアクセス権限で制限するという
手段は一応ありますが、それなら最初から Windows 認証を用いた方がスマートです。
SqlDataSourceEnumerator.Instance.GetDataSources() などで取得できます。
そのため、問題となるのは接続文字列というよりも認証部分だけでしょうね。
> データの集計などを行うWindowsフォームアプリケーションを作成しようとしています。
[EXE Application] ⇔ [Web Server] ⇔ [Database Server]
のように通信階層を一つ挟むという方法があります。
この場合、アプリケーション側にデータベースへのアクセス権を持たせる必要はなく、
SQL Server Client の導入も不要です。
EXE は単に、Web Service のための URL のみを知っていれば済みます。
データベースサーバーを別セグメントのネットワークに追い出せば、さらに安全。
> 悪意のあるユーザーが接続文字列にたどり着く可能性
えぇと、一般ユーザー向けに公開するアプリケーションではなく、社内向けのシステムなんですよね。
外部からの侵入や PC の無断利用は別途防御しているでしょうから、この場合の
「悪意あるユーザー」とは、内部犯行のことを想定しているのだと思いますが、
管理者や開発者自身の犯行だとどうにもならないので、その EXE を
誰が利用できる状態にしてあるか、という点も踏まえて、そこはコンプライアンスで…。
いずれにせよ、そうした点を気にするのであれば、普通は SQL Server 認証ではなく、
Active Directory などを組んで Windows 認証を採用すべきかと思います。
SQL 認証だと、パスワードを変更する必要が生じた場合の手間もかかりますし。
あるいは SQL 認証＋ハードウェアキーという組み合わせもありますが、
こちらはコストも手間もかかるので、今回の件では過剰になりそう。
> 一般的には外部のテキストファイルに接続文字列を書いておき、
ただのテキストを想定しているのであれば、一般的では無いと思います…。
.config と違って暗号化の仕組みも無いですし、むしろ脆弱性を広げる結果になるかと。
その設定ファイルに対する NTFS の読み取りアクセス権限で制限するという
手段は一応ありますが、それなら最初から Windows 認証を用いた方がスマートです。
投稿者 SSD (社会人)
投稿日時
2022/6/9 13:34:27
魔界の仮面弁士 様
ご回答ありがとうございます。
私はここのサイトでVBを勉強してVisual Studioを使い始めた身で、
色々分からないことが多かったので調べてみました。
わからないなりにも大体の仕組みを理解することができました。
一般的には教えて頂いたWebサーバーやActiveDirectoryなどが使われているのですね。
そうすれば接続文字列が...のようなこと自体がそもそも問題にならないのですね。
勉強になりました、ありがとうございます。
ご回答ありがとうございます。
私はここのサイトでVBを勉強してVisual Studioを使い始めた身で、
色々分からないことが多かったので調べてみました。
わからないなりにも大体の仕組みを理解することができました。
一般的には教えて頂いたWebサーバーやActiveDirectoryなどが使われているのですね。
そうすれば接続文字列が...のようなこと自体がそもそも問題にならないのですね。
勉強になりました、ありがとうございます。
投稿者 SSD (社会人)
投稿日時
2022/6/9 13:35:44
解決にチェックを入れ忘れてしまったので、チェックを入れます。
投稿者 るきお (社会人)
投稿日時
2022/6/9 20:59:34
補足します。
Windows認証の場合、接続文字列にはユーザー名とパスワードは埋め込まれず、代わりに Integrated Security=true; のような文字列が入ります。ユーザーはアプリケーションを実行しているユーザーとして認証されます。SQL Server 側ではそのユーザーに権限を付与しておく必要があります。
https://docs.microsoft.com/ja-jp/sql/connect/ado-net/connection-string-syntax?view=sql-server-ver16#windows-authentication
ユーザー数が多い場合、同時接続やネットワークの負荷の問題で、SQL Serverにうまくつながらないユーザーがいたり、動作が遅くなったりするかもしれません。ユーザー数が少なければこのような心配もなく権限の管理の手間も気にならないこともあります。
ここ20年くらいはWebアプリケーションとしてシステムを構築して接続周りのことをサーバー側に集約する事例の方が多いように思います。
この掲示板も、データベースにデータを保存していますが、Webシステムなので接続文字列が使用者に公開されることは通常ありません。
参考
https://docs.microsoft.com/ja-jp/sql/relational-databases/security/choose-an-authentication-mode?view=sql-server-ver16
Windows認証の場合、接続文字列にはユーザー名とパスワードは埋め込まれず、代わりに Integrated Security=true; のような文字列が入ります。ユーザーはアプリケーションを実行しているユーザーとして認証されます。SQL Server 側ではそのユーザーに権限を付与しておく必要があります。
https://docs.microsoft.com/ja-jp/sql/connect/ado-net/connection-string-syntax?view=sql-server-ver16#windows-authentication
ユーザー数が多い場合、同時接続やネットワークの負荷の問題で、SQL Serverにうまくつながらないユーザーがいたり、動作が遅くなったりするかもしれません。ユーザー数が少なければこのような心配もなく権限の管理の手間も気にならないこともあります。
ここ20年くらいはWebアプリケーションとしてシステムを構築して接続周りのことをサーバー側に集約する事例の方が多いように思います。
この掲示板も、データベースにデータを保存していますが、Webシステムなので接続文字列が使用者に公開されることは通常ありません。
参考
https://docs.microsoft.com/ja-jp/sql/relational-databases/security/choose-an-authentication-mode?view=sql-server-ver16
データベースへの接続はSQL認証で、アプリケーションの設定から接続文字列を入力しました。
SQL ServerへはSQLDataAdapterなどを使って設定(My.Settings)から接続文字列を取得し接続しています。
ただ、これらの文字列はexeファイルから取得することができ、セキュリティー上よくないということですが、一般的には外部のテキストファイルに接続文字列を書いておき、それを取得するといった運用が主流なのでしょうか？
もしそうだとしても接続文字列が書かれたテキストファイルのパス自体はコードの中に書くことになり、そのファイルパス自体はexeファイルから取得することができてしまうので、悪意のあるユーザーが接続文字列にたどり着く可能性を断ち切ることはできないような気がするのですが、これは直接的に接続文字列を取得されるよりはまし程度であって、完全に接続文字列にたどり着く可能性を排除することはできないものと考えた方がいいのでしょうか？