WinFormsアプリを使用して、背後にSQLサーバーがあるシステムで作業する企業イントラネットユーザーがいます。統合セキュリティがセットアップされ、すべてのユーザーに更新と削除のアクセス許可が許可され、アプリケーション セキュリティによってテーブルの更新の方法と場所が制限されます。
ただし、一部のユーザーは SQL クエリ ツールを自由に使用できるパワー ユーザーであり、レポートを作成するために DB に直接アクセスします。ただし、統合されたセキュリティを使用すると、アプリケーションが更新にルールを適用するため、テーブルに対するデフォルトの更新権限が付与されます。
これは、ユーザーが統合セキュリティの読み取り専用権限を取得する一方で、中央の SQL 認証ログインをアプリに提供する方が適切な例ですか?
Jon が述べたように、ストアド プロシージャはテーブルの直接変更に対する保護を提供します。他のオプションもあります。SQL Server の「アプリケーション ロール」を使用できます (sp_setapprole proc 経由)。これにより、すべてのユーザーに個別の ID を引き続き使用できますが、ユーザーの権限が昇格されるのは (フロントエンドを介した) アプリケーション接続時のみです。
共有 ID を使用することの主な欠点は、誰が SQL をサーバーに送信しているかを追跡できないことですが、それらがすべて内部の場合はマシン名を取得できます。
しかし、何か他のことが関係しています。ユーザーがデータベースに接続してクエリを自由に実行できるかのように聞こえます。直接接続された SQL セッションでのユーザーの動作が原因で、アプリケーションでダウンタイムが発生する大きなリスクがあります。成功できる場合は、ビジネスが許容できる間隔 (つまり、毎日) で更新されるレポート データベースを作成することをお勧めします。HTH
SQL 認証は 1 つのオプションです。ストアド プロシージャは別のものです。ただし、適切なアクセス許可を適切なユーザー タイプだけに割り当てるための、より詳細な役割を構築することは、実際に検討する必要がある場所です。
さらに、これらのユーザーに DB への直接アクセスを許可することはまったく避けたいと思います。セキュリティ上の理由は別として、SQL に精通していないユーザーが誤ってクエリを実行して、データベース サーバーを圧倒し、効果的なサービス拒否を作成することは、たいしたことではありません。プロでさえ、時々これを誤って行うことがあります。
代わりに、レポート サービスまたは分析サービス タイプのソリューションへのアクセス権を付与するか、レプリケーションを使用してデータのクローンへのアクセス権を付与します。このようにして、本番システムが保護されます。
質問の言い方から、アプリがSQLステートメントを直接実行していると思います。ストアド プロシージャを実行するようにリファクタリングできる場合は、プロシージャに対する実行権限を付与し、テーブルの直接更新を拒否できます。ただし、アプリの機能によっては、これが不可能な場合があります。
個人的には、ストアド プロシージャを介してすべてのアプリケーション データ アクセスを行います。統合セキュリティを設定して、ユーザーに SP の実行のみを許可し、データを直接操作しないようにします。
高度なアクセス権を DB 管理者に付与して、必要に応じてデータを直接操作することができます。
グループ ベースのアクセス許可により、アクセス権の柔軟性が大幅に向上し、これらを統合セキュリティで制御する際の管理負担が軽減されます。