1

バインドされていないフォームで Microsoft Access 2010 を使用しています。リンクされたテーブルは許可されません。それ以外の場合、接続文字列はテーブル定義に格納されます。したがって、名前のないクエリ定義を使用して SQL SERVER にアクセスすることになります。これはマイクロソフトが推奨しています。ただし、どこかから接続文字列を取得する必要があります。そのため、難読化された名前のメソッドから返すことをお勧めします。アプリケーション ソースに接続文字列をプレーン テキストで埋め込まないことをお勧めします。そのため、暗号化を使用します。

これを行う良い方法は、アプリケーションの最初の実行時にアプリケーション管理者に接続文字列を定義するように要求し、この msdn の記事に従ってください。

...アプリケーションを実行するアカウントのユーザー固有のキーを使用して DPAPI を介してその値を暗号化し、暗号化された値を Windows レジストリに保存します。

accde は、ログオンした Windows ユーザー アカウントから起動します。その後、アプリ管理者は、上記の推奨事項に従って、ログインしてデータベースへの接続をセットアップできます。

私が今持っているように見える最も弱いリンクは、Windowsユーザーアカウントです。セキュリティスキームの実装を知っていれば、そのアカウントにログインした人は誰でも接続文字列を解読できたようです。これは、システムがまだ十分に安全でないことを意味します。

新しい Windows ユーザーを作成することもできますが、それはそのユーザーのパスワードを安全に保管する必要があることを意味します。つまり、秘密情報にアクセスするために使用されるパスワードを保護するという、正方形 1 に戻ることを意味します。

もっと簡単な方法があるはずです。アイデアはありますか?

4

1 に答える 1

0

セッション間で接続文字列を永続化する必要がある理由はありますか? 代わりに、ユーザーの資格情報、サーバー インスタンス、および接続先のデータベース名を受け入れるログイン フォームをアプリケーションに作成し、アプリケーションの実行中にこの情報をメモリに保持することはできますか?

これにより、管理者がデータベースを新しいサーバーに移動することを決定でき、接続文字列を変更して再暗号化することを心配する必要がなくなるという点で、柔軟性が向上する可能性があります。また、複数のデータベースを定義することもできます。運用サーバーにロールアウトする前に、変更をテストするために QA サーバーを定義する状況を考えています。

于 2011-04-14T15:16:49.087 に答える