Webアプリケーション用のSQL Serverのユーザー/ロールに関するベストプラクティス

Question

私はオンラインで少しだけ検索し、データベース上のユーザー/ロールを設定する方法を実際に見つけ出したり、拠点をカバーしているものは見つかりませんでした。

基本的には、通常のデータベース操作（選択、挿入、更新、削除）のためにデータベースにアクセスする必要があるアプリケーション（この場合はWebアプリケーション）からデータベースにアクセスするためのユーザーがいます。 （execを使用して他のストアード・プロシージャー/ UDF内のストアード・プロシージャーを実行する）ストアード・プロシージャーを実行する。

次に、メインの管理者になるユーザーがいることになります（これは十分簡単です）。

私は現在、私の意見ではセキュリティをあまり良く管理していない開発環境を持っています（アプリケーションはイントラネットアプリケーションですが、db_ownerロールを持つユーザーを使用します）。イントラネットアプリケーションでも、セキュリティを念頭に置いており、開発者がこの種の環境でユーザー/ロールを設定する方法のいくつかを見たいと思っています。

EDIT：WebアプリケーションとSQL Serverは、別々のマシンに存在します。

EDIT：直接読み書きアクセスが必要なORMが使用されていることを忘れてしまいました。

質問： ユーザーにアプリケーションアクセスを設定する際の「ベストプラクティス」とは何ですか？どのような役割が適用され、いくつかのキャッチは何ですか？

Answer 1

まず、単一のユーザープリンシパルに添付するのではなく、データベースの役割にアクセス許可をカプセル化する傾向があります。ここでは大きな役割を果たすのはデータベースの役割なので、セキュリティを完全にスクリプト化してから、「ユーザーを追加してこの役割に追加する」という展開タイプを伝えることができ、SQL許可ブーゲイメンと戦っていません。さらに、これにより、db_ownerモードでの開発を避けることができ、自分のことをもっとよく感じることができるだけでなく、プレイするような練習や一般的に問題を避けることができるように、クリーンな状態が維持されます。

このロールの権限を適用する場合は、特にORMを使用してアプリケーションを介してセキュリティを処理している場合は、ネットをより広く使用する傾向があります。 T-SQLの用語では、それは次のようになります。

GRANT SELECT, UPDATE, INSERT, DELETE, EXECUTE on SCHEMA::DBO to [My DB Role] 

これは、最初は少し怖いように見えるかもしれないが、それは実際にはない - その役割は、操作するデータ以外の何もすることができません。他の大きな利点は、テーブルやプロシージャの追加のようにスキーマを変更すると、そのスキーマ内にとどまっている限り、それ以上のセキュリティ作業は必要ありません。

SQL 2005+では、オブジェクトのグループを保護するためにデータベーススキーマを使用することも考慮する必要があります。ここで大きなトリックは、多くのORMと移行ツールでは好きではありませんが、デフォルトのスキーマ[dbo]をアプリケーションにレンダリングすると、特別なセキュリティで保護されたものに代替スキーマを使用できます。たとえば、管理者が手動で実行する特別な残酷なデータベースクリーンアッププロシージャーのADMINスキーマを作成します。または、より詳細なDB権限を必要とする、アプリケーションの特別に安全性の高い部分の個別のスキーマです。

ドメインがなくても、Windows認証（Sql Serverの用語では統合認証）を使用することができます。両方のボックスで同じ資格情報（ユーザー/パスコンボ）を持つユーザーを作成してください。 Webボックスでそのユーザーとして実行するアプリケーションドメインをセットアップし、そのプリンシパルによってバックアップされたSQL ServerユーザーをSQLボックスと利益にセットアップします。つまり、デプロイメント・タイプはSQLユーザーの作成および必要に応じて接続文字列の変更を処理できる必要があるため、データベースの役割を使用すると、この決定から離脱する可能性があります。

Answer 2

Webアプリケーションが使用するユーザー 'webuser'を作成します。

このユーザーには、stored procの実行権限のみを付与します。直接テーブルの読み書きを許可しないでください。あなたがテーブルから何かを読む必要があれば、procを書いてください。データを書き込む必要がある場合は、別のprocを書きます。

このようにすべてが素敵でシンプルに保たれます。関連する権限のみを持つ1人のアプリユーザー。セキュリティが侵害された場合、侵入者はprocsを実行することができます。

Answer 3

データベースへのアプリケーションアクセスのガイドラインは、データへのアクセスをストアドプロシージャに分離し、プロシージャをスキーマにグループ化し、アプリケーションで使用されるプリンシパルに対してスキーマに対して実行を許可することでした。所有権の連鎖は、プロシージャの呼び出し側へのデータアクセスを保証します。ストアドプロシージャを調べることでアクセスを確認できます。これは簡単なモデルで、理解しやすく、設計し、展開し、管理します。ストアドプロシージャを使用すると、コード署名、最も細かく強力なアクセス制御方法、および改ざんされた唯一のもの（手順が変更された場合に署名が失われます）を活用できます。

問題は、Visual Studioデザイナーが出す技術のすべてが、この勧告の面で飛んでいることです。開発者には、ストアドプロシージャで排他的に使用するのは難しいモデルが用意されています。開発者はクラスモデルを最初に設計し、論理モデルからテーブル構造を生成することが大好きです。手順ベースのガイドラインは、アプリケーションの最初の行が書かれる前に、最初に存在する手順を再構築します。これは、現代的な開発の反復的な方法のために、実際に開発に問題があります。これは、チームリーダーが問題を認識し、それに対処している限り、解決不可能ではありません（つまり、手順がの場合はとなります。