Ms AccessフロントエンドとMysqlバックエンドをよりユーザーに認識させるにはどうすればよいですか？
Mysqlバックエンドを使用する分散MsAccessフロントエンドデータベースがあります。
WindowsシステムDSN ODBC接続を使用してサーバーに接続します。すべてのリンクテーブルはそのODBC接続を参照します。ただし、すべて使用します。各コンピューターにハードコードされている同じユーザー名とパスワード。
各ユーザーがログインできるように実装するためのより良い方法は何でしょうか。
各DSN接続は「ハードワイヤード」であるため、アプリがクラッシュした瞬間にDSN設定が残るため、アプリケーションが起動するたびにレジストリを書き換えることが安全な方法であるとは思いません。
プロンプトのユーザー名とパスワードなしでシステムDSNを離れることができるかどうかはわかりませんが、4つの異なるデータベースに接続しているため、ユーザーを苛立たせるだけなので、ユーザーに情報を4回入力させたくありません。
システムDSNユーザーをユーザーテーブルへの読み取り専用として使用できるか、またはユーザーを検証するプロシージャとして使用できるかどうかを考えていました。ただし、検証後は、すべてのテーブルをどのように接続するかがわかりません。グローバル変数をODBC接続文字列に格納できますか？
MsAccessをよりユーザーに認識させるためのより良い方法は何ですか？
（MSACCESSのセキュリティ設定を調べましたが、Microsoftはそれを弱めているようで、それを確立しようとすると完全にロックアウトされ、ログイン検証の形式は表示されません。セキュリティとして未亡人のログインを使用しているだけだと思いますがそれは本当の解決策ではありません）そしてここに免責事項があります：
Access 2010セキュリティの概要（office.Microsoft.com）
アクセスとユーザーレベルのセキュリティ
Accessは、新しいファイル形式で作成されたデータベース（.accdbおよび.accdeファイル）のユーザーレベルのセキュリティをサポートしていません。ただし、Access 2010で以前のバージョンのAccessからデータベースを開き、そのデータベースにユーザーレベルのセキュリティが適用されている場合、これらの設定は引き続き機能します。
重要ユーザーレベルのセキュリティ機能を使用して作成されたアクセス許可は、悪意のあるユーザーからデータベースを保護するものではなく、セキュリティバリアとして意図されたものでもありません。この機能を使用して、信頼できるユーザーのデータベースの使いやすさを向上させることが適切です。データを安全に保つために、Windowsファイルシステムのアクセス許可を使用して、信頼できるユーザーのみがデータベースファイルまたは関連するユーザーレベルのセキュリティファイルにアクセスできるようにします。
データベースをユーザーレベルのセキュリティを備えた以前のバージョンのAccessから新しいファイル形式に変換すると、Accessはすべてのセキュリティ設定を自動的に削除し、.accdbまたは.accdeファイルを保護するためのルールが適用されます。
最後に、新しいファイル形式のデータベースを開くと、すべてのユーザーがいつでもすべてのデータベースオブジェクトを表示できることに注意してください。
私が理解しているように、アプリケーション内のエンドユーザー（「アプリケーションユーザー」）に、よりパーソナライズされたエクスペリエンス/環境を提供すると同時に、ユーザー認証プロセスをOBDC DSN接続資格情報（「データベース」）と組み合わせることでセキュリティを向上させたいと考えています。ユーザー"）。
このカスタマイズされたユーザー環境は、通常、エンドユーザーにアプリケーションで自分自身を認証させることによって実現されます。これは通常、アプリケーションのロード時にユーザーにユーザー名とパスワード（通常はmy_app_db.usersテーブルに格納されます）を入力させることによって行われます。
このアプリケーションのユーザー認証を行う前に、アプリケーション自体（またはマシン）がデータベースサーバーとの接続を確立する必要があります。この「データベースユーザー」は通常、次の方法で実現されます。
- アプリケーション（および/またはインストーラースクリプト/バイナリ）にハードコードされた、静的な事前定義されたデータベースユーザー/パスワード。インストールスクリプトは通常、サーバー管理者に、（とりわけ）
CREATEおよびGRANT権限（通常はrootユーザー）を持つデータベース資格情報を要求し、インストーラーがデータベースを作成できるようにします。必要なユーザー。 - 適切な権限で事前に作成されたユーザー定義のデータベースユーザー。次に、インストーラーはこれらの資格情報を提供するように要求します。これらの資格情報をクライアントのどこかに保持するために、アプリケーションは独自の可逆暗号化（または難読化）方法を使用して保存します（.datファイル、レジストリキーなど）。データベース接続が確立される前に読み取ることができる方法。
セキュリティに関しては、ここで最小特権の原則が重要です。このデータベースユーザーには、アプリケーションが正しく機能するために必要な最小限の特権（SELECT、INSERT、UPDATE、場合によってはDELETE、およびアプリケーションのデータベースのみ）のみを付与する必要があります。 、システム/マスターデータベースは絶対に使用しないでください）。
これをnotと組み合わせて、データベースの資格情報をプレーンテキストでエンドユーザーのマシンに保存すると、を保護することができます。 ）不正アクセスからのアプリケーション。悪意のあるユーザーがアプリケーションがインストールされているマシンへのローカル管理者アクセスを取得した場合、それはほとんどゲームオーバーであることに注意してください。彼らはその接続文字列を復号化されたメモリから引き出したり、 MySQLトラフィックをスニッフィング =データベースユーザーの資格情報を取得するためのネットワークインターフェイス上で、その時点で、そのユーザーをどの程度制限したか（そして、MySQLに定期的にパッチが適用されることを願っています）、攻撃者がどれほど洗練され、決定されているかによって異なります。
多くのデータベースアプリケーションはアプリケーションサーバーを使用することに注意してください。これは基本的に、クライアントに代わってデータベースとの間の接続を仲介する中央の「ウォッチガード」です。これは通常、パフォーマンス/スケーラビリティの理由で行われますが、データベースサーバーをアプリケーションサーバーのみに分離/制限でき、エンドユーザークライアントが直接アクセスできないというセキュリティ上の利点もあります。
ODBC DSNオプションとMySQLに関しては、私は利用可能なものにそれほど精通していません。しかし、それ以降のバージョンでは Windowsネイティブ認証サポート があるようです。 MySQLの。
MySQLおよびASP.NETアプリケーションと組み合わせてセキュリティ証明書を備えたMySQL/NETコネクタを使用することに成功しましたが、それがMicrosoftAccessにまで及ぶかどうかはわかりません。おそらくそこに.NET接着剤を書く必要があるでしょう。
そして、それが詳細に落ち着いたら、その時点で Stack Overflow で質問したほうがよいでしょう。
お役に立てれば。