「ネットワーク上の 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 認証を用いた方がスマートです。