☰

アプリケーション別のODBC

tag-icon • tag-icon windows-server-2012 odbc microsoft-dynamics-gp
アプリケーション別のODBC

システム別の ODBC (システム DSN) とユーザー別の ODBC (ユーザー DNS) についてはよく知っています。アプリケーション別の ODBC が必要です。特定のアプリケーション (GP 2010) で使用できる ODBC 接続を制限します。ターミナル サーバーに複数の GP アプリケーションがインストールされており (複数の Dynamics.exe アプリケーションを格納する Program Files 内の複数の GP ディレクトリ)、GP 2010 から接続する ODBC が複数あります。

特定の GP 2010 アプリケーション (Dynamics.exe) のみが特定の ODBC を起動して接続できるようにするルールを適用したいと考えています。つまり、次の間に 1:1 の関係を作成するルールを適用したいと考えています。

  1. GP 2010 アプリケーション (Dynamics.exe)、および
  2. ODBC (GPをサポートするSQLインスタンス)

環境情報:

  • Windows Server 2012 標準 64 ビット
  • SQL 2008 R2 SP2
  • GP 2010 SP3

これまでに試したこと/学んだこと:

特定の GP 環境では、グループ ポリシーを使用して、ユーザー DSN を使用することで Windows ユーザーが利用できる ODBC を制限しようとする試みが見られました。ただし、Windows ユーザーが複数の GP アプリケーションに正当にアクセスできる場合には、このようなアプローチは役に立ちません。GP アプリケーションを起動すると、Windows ユーザーが利用できる任意の ODBC を選択できます。

私はGP 2010の使用を試しましたログインマクロこの問題を解決しようと試みました。ただし、この方法は安全ではなく、拡張性がありません。まず、ユーザー名とパスワードが管理者に知られており、通常は変更されないことが前提となっています。この場合、資格情報 (ODBC とともに) をログイン マクロ (プレーン テキストでどこかに保存されている) に埋め込むことができます。それでも、ログイン マクロを使用するには、ユーザーが起動する GP 2010 ショートカットにログイン マクロを渡す必要があります。各 GP アプリケーションに汎用ターゲット パスを指定できるようにするには、各ユーザーのログイン マクロをユーザーごとに共通の場所 (ユーザーのデスクトップなど) に保存する必要があります。これはユーザーごとに構成する必要があるため、この管理オーバーヘッドによって拡張性が制限されます。

答え1

あなたがしようとしていることは、Windows セキュリティ モデルの動作方法と一致していないため、望む結果が得られる可能性は低いと思います。

ODBC DSN はレジストリに保存されます (システム DSN の場合は HKEY_LOCAL_MACHINE、ユーザー DSN の場合は HKEY_CURRENT_USER)。レジストリには、セキュリティ プリンシパル (ユーザーまたはグループ) を参照するアクセス許可を設定できますが、アプリケーション ソフトウェアを参照するアクセス許可は設定できません (アプリケーション ソフトウェアはセキュリティ プリンシパルではないため)。同様に、レジストリへのアクセスに使用される API には、アクセスを実行するアプリケーションに基づいてアクセス許可を実装する機能がありません。セキュリティは、ユーザーとそのグループ メンバーシップに基づいており、ユーザーが実行しているアプリケーションに基づいているわけではありません。

ODBC DSN へのユーザー アクセスを削除しても、ユーザーがアクセス権を持っている場合、バックエンド データベースへのアクセスが実際に停止されるわけではありません。DSN を隠してアクセスを「隠す」だけで、実際には何も保護されません。隠すことによるセキュリティは、実際にはセキュリティではありません。

Great Plains の経験はありませんが、バックエンド ストレージは SQL Server ベースであると思われるため、バックエンド データベースへのユーザー アクセスを制限するための正しい方法はSQL Server セキュリティであると思います。Great Plains データをホストする SQL Server インスタンスにアクセスするユーザーは、ODBC DSN で Windows 認証を使用していると仮定すると、Windows ユーザー コンテキストで SQL Server に「認識」されます。ユーザー (または、ユーザーがメンバーになっているグループ) に対応する SQL Server「ログイン」を作成し、組み込みの SQL Server 機能を使用してアクセスを制限できます。これは、多く特にデータベース自体がアクセスを強制するため、ユーザー アクセスを制限するにはより適した場所です。

(これまで Great Plains を使用したことがなく、ソフトウェアが SQL Server ネイティブ認証などの厄介なものを使用する可能性があり、その可能性が高いことを認めています。その場合、混乱が生じます。)

答え2

いいえ、しかし、それが大きな問題であれば、Hyper-V の下の独自の VM で各アプリケーションを実行するだけです。

関連情報