プロジェクト用のフォーム アプリケーションを作成しました。ユーザーがダウンロードしてテストできるように、自分の Web サイトでホストしたいと考えています。構成マネージャーを使用しているため、アプリケーション用のバックエンド リモート データベースがあるため、.exe と共に構成ファイルを含める必要があります。そしてもちろん、自分の接続文字列がすべての人に見えるようになったことに今やっと気づきました。app.config の名前を web.config に変更しようとしましたが、vista マシンで管理者として実行すると、aspnet_regiis -pef コマンドはヘルプ メニューを返すだけです。このコマンドが機能し、web.config の名前を app.config に戻しても、ダウンロード時にアプリを実行するマシンは、接続文字列を自動的に復号化しますか? 結論として、初心者がこのジレンマに取り組むための最良の方法は何ですか? aspnet_regiis -pef が実行されないのはなぜですか? このトピックに関する他の投稿も見ましたが、残念ながら、これまでのところうまくいきませんでした.
2 に答える
ユーザー/特定の接続文字列を作成するか、一部の Web サービスですべてのデータ アクセスをラップして、承認を制御できます。
ユーザー固有の接続文字列を作成するのが最も簡単ですが、DB 料金に影響を与える可能性があります。接続文字列を 1 つ保持することはできますが、Windows ID を使用して接続します。どちらの場合も、ユーザーが許可されている以上のことを実行できないようにするために、ある程度の努力を払う必要があります。
データ アクセスを Web サービスにラップすると、はるかに管理しやすくなりますが、機能させるには追加の作業が必要になります。たぶん、RIA Servicesを参照してください。利点は複数あります。Web サービス内でアクセス許可を制御でき、不要なクエリの公開を減らすことができます。
また、構成ファイルで接続文字列を暗号化した場合でも、悪意のあるユーザーが暗号化を解除できることに注意してください。簡単な逆コンパイラで復号化キーが強調表示されます。
接続文字列を暗号化して app.config に保存することもできますが、アプリケーションのどこかに暗号化キーを含める必要があります。したがって、誰もがアプリケーションを逆コンパイルするか、デバッガーをアタッチして接続文字列を抽出できるため、これは安全ではありません。または、ネットワーク トラフィックを監視します。実際、これが起こらないようにする方法があります。アプリケーションでできることは、誰でも (アプリケーションへのアクセス権があれば) 手動で行うことができます。
設計上の欠陥は、アプリケーションが最初にデータベースに直接アクセスする必要があることです。このシナリオでデータベースが破損しないようにすることはほぼ不可能です (データベースがデータの読み取りのみに使用されている場合を除く)。基本的に、データベース サーバーでビジネス ロジックの大部分を複製して、一連の要求が状態を破壊しないようにする必要があります。
より良い解決策は、Web サービスを介して間接的にのみデータベースにアクセスすることです。これにより、サーバー側の検証、さらにはユーザーごとの認証と承認の実装をより適切かつ簡単に実行できます。