グループによるデータベースの所有権が許可されないのはなぜですか？どのユーザーがデータベースを所有する必要がありますか？

Question

ごと Microsoft "ALTER AUTHORIZATION for databases for SQL Server" ：

新しい所有者の要件：

新しい所有者プリンシパルは、次のいずれかである必要があります。

SQL Server認証ログイン。

Windowsユーザー（グループではない）を表すWindows認証ログイン。

Windowsグループを表すWindows認証ログインを介して認証するWindowsユーザー。

どうやらグループはデータベースを所有できない。確かに

alter authorization on database::MyDatabase to [domainname\SQLServerAdminGroup]

メッセージが表示されます

データベースタイプのエンティティは、ロール、グループ、アプロール、または証明書や非対称キーにマップされたプリンシパルが所有することはできません。

たとえば、SQL管理者のWindowsセキュリティグループの単一のメンバーがデータベース所有者になることは、そのアカウントが使用されなくなることに対して脆弱です。それは、所有している従業員がこの質問で会社を辞めたときに起こったようです。この回答は、データベース所有権がNTプライマリプリンシパルであるという問題を次のように要約しています。

データベースの所有権をデフォルトでNTプライマリプリンシパルにすると、封じ込めの問題が発生します（所有者はADによって管理されるNT SIDであり、データベースファイルと一緒に移動せず、NTアカウントをサムストーン化できるなど）。

私はSQL Serverの管理に不慣れで、ファイルなどの所有権と比較して、プライマリプリンシパルだけが所有者になることができるという制限が際立っています。あたり Microsoft "所有者の割り当てと変更の方法" ：

デフォルトでは、新しいオブジェクトの所有者は、作成プロセスに添付されたアクセストークンでデフォルトの所有者として識別されるセキュリティプリンシパルです。 ...唯一の例外は、ユーザーがAdministratorsグループまたはDomain Adminsグループのいずれかのメンバーである場合に発生します。どちらの場合も、ユーザーのアクセストークンの[所有者]フィールドには、個々のユーザーアカウントのSIDではなく、グループのSIDが含まれます。管理アカウントは、システムを管理するためだけに使用され、個々の目的には使用されないことが前提です。その結果、1人の管理者が作成したオブジェクトは、同じグループ内の他の管理者が管理できます。

言い換えると、

管理者が作成したfilesの場合、defaultファイルの所有者はgroup、一方
データベースの場合、所有者はグループにすることはできません。

これは私に次の質問を残します：

データベースをセカンダリプリンシパルが所有できない根本的な理由はありますか？
データベースを所有するプリンシパルはどれですか？ベストプラクティスはありますか？もしそうなら、そのベストプラクティスの背後にある理由は何ですか？

Laughing Vergil · Answer

正直なところ、saまたは完全に最小限の権限を持つ無効なSQL Serverアカウントが最良の選択です。なぜですか？ええと、3つまたは4つの段落を書き出すこともできますし、- データベースが所有するアカウントとその理由についてのお気に入りの記事を共有することもできます。すべてのベースをカバーする非常に徹底的な説明。強くお勧めします。

これがコアの抜粋です：（これを追加して編集された1/9/2020）

さてさてさてどうですか？追加のアクセス許可を付与するようなものではなく、終了したり、起動したりすることはできません。いずれにせよ、誰もそれを使用するべきではありません。ヘック、あなたはおそらくsaが無効になっているでしょう？あのね？それは実際には完全に合理的です！実際、saは、データベース所有者として使用する非常に一般的なIDです。

唯一のリスクは、データベースが信頼できる状態になった場合です。次に、saとして機能するストアドプロシージャを作成できます。それでも、EXECUTE AS句を使用してプロシージャを作成するには偽装権限が必要なため、それほど危険ではありません。つまり、そのストアドプロシージャを作成するために、db_ownerロールのメンバーを偽装する機能（明示的にこれを行わないでください）、または自分でdb_ownerのメンバーになることが明示的に許可されていることを意味します。これは、db_ownerを持つユーザーがsysadminになることができることを意味しますが、リスクはかなり軽微です。 TRUSTWORTHYはそれほど一般的ではありません。うまくいけば、それを使用している場合はリスクを理解し、危険なアクセス許可を回避できます。

しかし、リスクはリスクです。したがって、特に妄想的であるか、非常にデリケートなシステムがある場合、最も簡単な解決策は、SQLログインを作成し（だれもログインすることがないため、愚かな複雑なパスワードを使用して）、無効にし、それを使用することです。所有者として。