データベースアカウントの数
特定のアプリケーションに対していくつのユーザーアカウントを設定する必要がありますか？分離はどこにあるべきですか？
- アプリケーションごとに1回のログインにする必要がありますか？
- プログラムごとに1つのアプリケーション？
- フロントエンドとバックエンドに1？
データベースアカウントをどのように設定しますか？
私は設定します：
- oOBに付属する株式管理アカウント。他のアカウントではできないことのためにこれを使用してください。それをロックしたままにして、選択の余地がない場合にのみそれを運び出します。
- セカンダリ管理者アカウント管理者ごとに1つ。 allの日常の管理者はこのアカウントで作業しますが、これらの管理者アカウントでは、本当に危険なもの（DROP DATABASE、DROP SCHEMAなど）の特権を省略し、out-を使用します。そのための上記のof-box管理者アカウント。 （別のアカウントとしてログインするように強制することは、潜在的に損害を与える可能性のあることを実行しようとしていることを示す精神的な指標である必要があります。また、1日の管理アカウントには組み込みの「安全スイッチ」があります。データベースを不自由にする可能性のあるアクションのプライベートが欠落している形式）
- マシンベースの接続（接続プーリング、プロキシ接続など）を使用している場合は、そのためのアカウントを使用します。このアカウントが機能するために必要な最低限の特権を付与します（アカウントがDROP DATABASEなどを介して甚大な被害を与えるのを防ぐため）。
- エンドユーザーから直接接続している場合、エンドユーザーごとに1つのアカウント、エンドユーザーが幅広いカテゴリでない限りおよびプライベートを分離する必要はありませんそのカテゴリ。その場合、ユーザーごとに1つのアカウントgroup。
2009-07-03明確にするために再編集。
私は一緒に行きます：それは異なります。それは本当にあなたのデータベースがどのように使われるかに依存します。さまざまなシナリオ：
- ユーザーに代わって接続する内部アプリケーション。この場合、ドメイン内にサービスアカウントを作成し、ドメインへのアクセスを許可します。アプリケーションは、この1つのアカウントをすべてのデータベースアクセスに使用します。
- 外向き（インターネット）アプリケーション。この場合、WebサーバーはDMZにあり、したがってドメインにはないため、SQL Serverログインを作成します。アプリケーションは、すべてのデータベースアクセスにこの1つのアカウントを使用します。
- 内部アプリケーションは、ユーザーの資格情報を渡します。これは、SQL Server Reporting Servicesや、実際の資格情報を渡すことが重要なその他のケース（監査証跡）で見られます。この場合、さまざまなレベルの権限がある可能性があります。各レベルには、適切なWindowsドメインセキュリティグループが必要です。 Windowsユーザーは、これらのグループのメンバーである必要があります。これらのグループは、データベース内のユーザー定義のデータベースロールに関連付ける必要があります。これらのデータベースロールには、すべての権限が必要です。
- データベースへの直接アクセス。これは、レポートタイプのシステムでさらに詳しくわかります。この場合、Windowsセキュリティグループは、データベースロールを使用してアクセスが許可されます。
これについては、さまざまな答えが得られます。
接続文字列で使用される単一のアプリケーション（「アプリケーションごと」と読む）アカウントを設定しました。 （私の開発グループ以外の）ユーザーはデータベースに直接アクセスできません。
私は主に企業のMS環境（.NET、SQL Server、Active Directory）で働いています。通常、認証は、現在ログインしているユーザーコンテキストとアプリケーション固有のセキュリティテーブルを介して行われます。コードは認証を処理してから、データベースからアプリケーションの承認を取得します。これにより、ユーザーメンテナンスの負担が大幅に軽減され、IT部門に負担がかかります（パスワードポリシーとリセット、アカウントの有効期限、無効化など）。
- 1つのdb-clientで問題が発生した場合に、サーバーへのすべてのアクセスを無効にせずにそのアカウントを無効にできるように、少なくとも十分なアカウントが必要だと思います。
- 通常、アカウントの設定を使用して、複数のデータベースにアクセスすることはありません。
- Webアプリケーションと内部クライアントに別々のアカウントを使用しています。