SQL Serverアプリケーションロールの目的
Microsoft SQLサーバーのアプリケーションロールについて読んでいます。アプリケーションロールは、セキュリティ保護可能なリソースへのアクセス許可をアプリケーションロールに付与できるという点で他のロールと似ていますが、ストアドプロシージャを使用してアプリケーションから「呼び出される」必要があるという違いがありますsp_setapprole。
これを使用するために私が見ることができる唯一の理由は、DBAがアプリケーション（およびその開発者）にデータベースへの接続を許可し、サーバーログインまたはデータベースユーザーを提供する必要がないため、開発者がSQL Serverに直接接続できないためです（たとえばSSMSを介して）それでも、アプリケーション/開発者に提供されたアカウントにはとにかく必要な最小限のアクセス許可が確実に付与されるので、私は実際にこれの利点を見ることができませんか？
ここで何か不足していますか？
アプリケーションロールは、初期接続資格情報を提供する必要性を排除しません。アプリケーションロールをアクティブ化する前に、まずログイン（SQLまたはWindowsアカウント/グループ）、または含まれているデータベースユーザー）を使用してサーバー/データベースを認証する必要があります。
アプリケーションロールは通常、次の点で通常のデータベースロールとは異なります。
- メンバーがいない
- 認証が成功した後、アプリのロールパスワードで_
sp_setapprole_を使用して有効化されます - _
sp_unsetapprole_が_sp_setapprole_から返されたcookieを使用して設定解除されている（接続プールに必要）
アプリケーションデータベースへのアクセスに（アプリケーションで必要な権限を持つ）サービスアカウントを使用する場合、アプリケーションロールを使用しても意味がありません。
アプリケーションロールの使用例は、ユーザーが独自のセキュリティ資格情報（WindowsグループメンバーシップによるWindows認証など）を使用してアプリケーションからSQL Serverに接続するが、アプリケーションに必要な権限を持っていない場合です。このシナリオでアプリケーションロールをアクティブ化すると、CONNECT以外の権限を付与することなく、個々のユーザーアクティビティを監査できます（ORIGINAL_LOGIN()を使用）。レポートツールに必要です。これにより、アプリケーションを介した書き込みを制限しながら、レポートの読み取り専用アクセスが可能になります。