データベースの「所有者」の目的は何ですか？

今日、サービスブローカーの問題のトラブルシューティングを行っているときに、データベースの所有者が退職した従業員のWindowsログインであることを発見しました。彼のログインは削除されたため、クエリ通知は失敗していました。

おそらくこれに対処するためのベストプラクティスは、「sa」をデータベース所有者にすることです。変更して、キューをクリアしました。

私の（非常に初歩的な）質問：データベースの所有者は何で、その目的は何ですか？

一方の「dbo」（ユーザー）と「db_owner」（固定ロール）のデータベース概念と、もう一方の「データベース所有者」のインスタンス概念との間には混乱があります。「dbo」および「db_owner」は「データベース所有者」と呼ばれることがよくあります。あなたが求めているのは、データベースを所有するサーバープリンシパルとしてのデータベース所有者についてです。

理論は次のようになります。パーミッションを付与できるものはすべて「セキュリティ保護可能」です。すべてのセキュリティ保護可能な人には所有者がいます。保護可能な人の所有者は、保護可能な人を完全に制御し、特権を否定することはできません。インスタンスレベルのセキュリティ保護可能なオブジェクトは、サーバープリンシパル（ログイン）が所有しています。データベースレベルのセキュリティ保護可能なオブジェクトは、データベースプリンシパル（ユーザー）が所有しています。プリンシパルには、プライマリ（アイデンティティ）とセカンダリ（メンバーシップ）の2つのフレーバーがあります。サーバーレベルのセキュリティ保護可能なオブジェクトは、デフォルトで、現在ログに記録されているプラ​​イマリサーバープリンシパルによって所有されます。データベースレベルのセキュリティ保護可能なオブジェクトは、デフォルトでは現在のデータベースプリンシパルが所有しています。ただし、デフォルトではスキーマ所有者が所有するスキーマバインドオブジェクトを除きます。すべてのセキュリティ保護可能なエージェントは、作成時にAUTHORIZATION句をサポートして、異なる所有者を強制します。ALTER AUTHORIZATION 後でセキュリティ保護可能な所有者を変更するために使用できます。

データベースはセキュリティ保護可能なサーバーレベルであるため、デフォルトでは、CREATE DATABASEステートメントを発行したプライマリプリンシパルによって所有されます。すなわち。退職した従業員のNTログイン。

それで、あなたの質問は本当に「なぜセキュリティ保護可能な人には所有者が必要なのですか？」です。所有者は信頼の根だからです。オブジェクトの許可を付与、拒否、および取り消すのは所有者です。セキュリティシステムは、セキュリティ保護可能な所有者なしで設計できますか？おそらくはありますが、現在のモデルで所有者が果たす役割を置き換えるために、何らかのメカニズムが必要になります。たとえば、そのお父さんのセキュリティ保護可能なリソースは何の所有者がありません考える（例えば。代わりに、セキュリティ保護可能なを所有しているのを、原作者はそれ以上のCONTROLが付与されている）、にその上に固定可能なおよびREVOKEのアクセスを作成することは可能であろう誰も彼自身を含め、。所有者の要件は、所有者がロックアウトできないため、この問題を回避します。

元のNTログインが所有するセキュリティ保護可能なデータベース（データベース）を作成するCREATE DATABASEのあまり知られていない副作用は、以前から燃えています。ルールはすべてのセキュリティ保護可能なもので同じですが、データベース所有者の問題を悪化させるいくつかの要因があります。

• 他のサーバーレベルのセキュリティ保護可能なエンドポイント（エンドポイント、サーバーの役割、ログイン）はめったに使用されず、移動されます。
• 通常、データベースレベルのセキュリティ保護可能なものはdbo（データベースプリンシパル）または他のデータベースプリンシパルによって所有されているため、所有者はデータベースに含まれています
• データベースの所有権をデフォルトのNTプライマリプリンシパルに設定すると、封じ込めの問題が発生します（所有者はADによって管理されるNT SIDであり、データベースファイルと一緒には移動しません。NTアカウントはサムストーンなどになります）
• 最も重要なことは、データベース所有者が重要な副作用、特にEXECUTE AS context。この後者の問題は、ほとんどのユーザーを燃やすものです。Service BrokerはEXECUTE AS（メッセージ配信には暗黙的なEXECUTE ASコンテキストと明示的なコンテキストを持つキューのアクティブ化があります）を広範囲に使用するため、通常、この問題を最初に発見するのはService Brokerユーザーです。

ところで、あなたの元の問題を調査して修正したことに対する称賛:)

データベースownerは、（適切な）スキーマがSQL Sever 2005に導入される前の時代に少し戻っています。

基本的に、データベース所有者はデータベースのデフォルトdbo（データベース所有者）であり、データベース自体がデータベースオブジェクトです。

SQL Server 2000のドキュメント...

dboデータベース内のすべてのアクティビティを実行する権限を暗示しているユーザーです。

SQL Serverの以前のバージョンでは、スキーマがオブジェクトを「所有」できなかった（または、すべてのオブジェクト、テーブル、ビューなどが所有されdbo、他のスキーマがなかったと述べる必要がある）ために必要でした「ユーザー」がそれを所有します... 何かがデータベースを所有する必要がある理由は言うまでもありません（そうでなければ、一般にパーミッションはかなり難しいでしょう）。

したがって、技術的には、SQL Serverの古いバージョン（またはアップグレードされたデータベース）では、「Foo」テーブルではなく、「dbo.Foo」テーブルでした... dbo所有者です。

SQL Server 2005の登場により、「bar」という名前のスキーマと「Foo」という名前のテーブルがあるなど、スキーマ所有のデータベースオブジェクトを持つことができました...これは次のbar.Fooようになります...

SELECT * FROM bar.Foo WHERE etc = 'blah`;

トリッキーな部分には、データベースを作成しているユーザーが所有者として自動的に設定されるという事実があり、従業員の転職などの問題につながります。

したがって、これをsaアカウントに変更するか、おそらく（私の経験では）組織の運用/ ITチームが管理できるドメインアカウントに変更するのがベストプラクティスです。

この記事では、古い「所有者」のやり方と、新しい「スキーマ」ベースの所有権システムの違いを分析します。

所有者とスキーマの違いを理解するために、オブジェクトの所有権を確認してみましょう。SQL Server 2000以前でオブジェクトを作成する場合、オブジェクトには所有者が必要です。ほとんどの場合、所有者は「dbo」であり、データベース所有者とも呼ばれます。