うまくいけば、これは単純なものです。私は答えを見つけられません！C＃サービスのセキュリティで保護された設定
いくつかのクエリを実行するために定期的にSQL Serverデータベースに接続するサービスとして実行するC＃アプリケーションを作成したいと考えています。 SQL Serverの接続の詳細は、サーバーが取得できる場所に保存する必要がありますが、プレーンテキストファイルに保存する必要はありません。私はそれらを暗号化されたファイルに保存することができましたが、パスワードがサービスにアクセスできる場所にパスワードを格納する必要があります。
ある種のアプリケーション/サービスレベルの暗号化または安全なストレージAPIが存在し、設定/データを安全に保管できるため、パスワードをファイルのどこかに保存する必要はありませんか？
乾杯！
app.configを完全に暗号化することができます（詳細はthis blogを参照）。ただし、管理者（またはプログラムにデバッガを接続できるユーザ、またはプログラムが暗号化されずに送信された場合にプログラムとサーバの間でプロキシを設定できるユーザ）は、復号化されたパスワード。
あなたが心配している場合は、別のセキュリティモデルを検討する必要があります。たとえば、Trusted Subsystem Modelを使用すると、ユーザーはデータベースへの接続が信頼されている仲介サービスに対して認証されます。このサービスは、クレーム、ロール、またはユーザーベースの認証を使用してユーザーを認証し、データベースにアクセスする必要があるかどうかを判断し、接続文字列に格納されているパスワードを決して配布しないようにすることができます。
また、可能であれば、SQL Serverでログインとユーザー/グループを使用することを検討することもできます。信頼できる認証を使用し、接続文字列にパスワードを必要としません（ただし、暗号化されていても、マシンへの管理アクセス権を持つアプリケーションのユーザーは、暗号化されていると見なす可能性があります）。
これらの方法にはさらにオーバーヘッドがあります。ロール/クレーム/ユーザーをあるレベルで維持して、必要なユーザーのみが接続できることを確認する必要があります（アプリケーションにアクセスできるユーザーとの接続を常に受け入れる）
こんにちはダン、ありがとう。誰かが私のサービスが稼働しているそのマシンへの管理者アクセス権を持っているなら、とにかくすべてのベットはオフになっているので、私はあまり心配していません。質問を投稿する前に私はDPAPIに出くわしましたが、それが私の目的に合っているかどうかは正確には分かりませんでした。それはそうであるように聞こえる。良いですね！ – Drewll
通常、接続文字列と資格情報は、サーバー上の構成ファイルに格納されます。あなたのサーバはすでに安全であるはずですので、アカウントのパスワードを平文で保存することは問題ではありません。潜在的な脆弱性を減らすには、権限が制限されているSQLサーバー用のアカウントを作成し、アプリケーションでこれらの資格情報を使用する必要があります。 –
@CallbackKid私は、悪意のあるユーザーが暗号化されたパスワードを持っているあなたのウェブサーバーに、あなたのアプリケーションの他の部分に侵入した場合、平文でパスワードを保存するのは常に避けるべきです、db/apiなどは、深い防御。 – Macilquham
これはWebサーバー上にあると想定しているのはなぜですか？質問はちょうどサービスとして実行しているC＃アプリケーションを言う... –