データベース「所有者」の目的は何ですか？
今日、サービスブローカーの問題をトラブルシューティングしているときに、データベースの所有者が退職した従業員のWindowsログインであることがわかりました。彼のログインは削除されたため、クエリ通知は失敗していました。
おそらくこれに対処するためのベストプラクティスは、「sa」をデータベース所有者にすることです。私たちはそれを変更し、それはキューをクリアしました。
私の（非常に初歩的な）質問：データベースの所有者とは何ですか？その目的は何ですか？
一方の側の「dbo」（ユーザー）と「db_owner」（固定ロール）のデータベースの概念と、もう一方の側の「データベース所有者」のインスタンスの概念との間には、いくつかの混乱があります。 「dbo」と「db_owner」は「データベース所有者」と呼ばれることがよくあります。あなたが尋ねていることでは、データベースを所有するサーバープリンシパルとしてのデータベース所有者について話している。
理論は次のようになります。アクセス許可を付与できるものはすべて 'セキュリティ設定可能' です。すべてのセキュリティ保護可能なアイテムには所有者がいます。セキュリティ保護可能なアイテムの所有者は、セキュリティ保護可能なアイテムを完全に制御し、特権を拒否することはできません。インスタンスレベルのセキュリティ保護可能なファイルは、サーバー プリンシパル （ログイン）が所有しています。データベースレベルのセキュリティ保護可能なファイルは、データベースプリンシパル（ユーザー）が所有しています。プリンシパルには、プライマリ（アイデンティティ）とセカンダリ（メンバーシップ）の2種類があります。サーバーレベルのセキュリティ保護可能なファイルは、デフォルトでは現在ログに記録されているプライマリサーバープリンシパルが所有しています。データベースレベルのセキュリティ保護可能なファイルは、デフォルトで現在のデータベースプリンシパルによって所有されます。ただし、デフォルトでスキーマ所有者が所有するスキーマバインドオブジェクトは例外です。すべてのセキュリティ保護可能なリソースは、作成時にAUTHORIZATION句をサポートして、別の所有者を適用します。 ALTER AUTHORIZATION は後で、セキュリティ保護可能な任意の所有者を変更するために使用できます。
データベースはセキュリティ保護可能なサーバーレベルであるため、デフォルトでは、CREATE DATABASEステートメントを発行したプライマリプリンシパルによって所有されます。つまり。退職した従業員のNTログイン。
だからあなたの質問は本当に「なぜセキュリティ保護可能な者が所有者を必要とするのですか？」です。所有者が信頼の根源だからです。オブジェクトに対する許可を付与、拒否、および取り消すのは所有者です。セキュリティシステムは、セキュリティ保護可能なリソースの所有者なしで設計できますか？おそらくそうですが、現在のモデルで所有者が果たす役割に取って代わる何らかのメカニズムが必要です。たとえば、父親のセキュリティ保護可能なユーザーには所有者がいないことを考えてください（たとえば、セキュリティ保護可能なユーザーを所有する代わりに、元の作成者にCONTROLが付与されるだけです）。セキュリティ保護可能なアカウントを作成し、everybody、自分自身を含む。所有者はロックアウトできないため、所有者の要件はこの問題を回避します。
元のNTログインが所有するセキュリティ保護可能な（データベース）を作成するというCREATE DATABASEのあまり知られていない副作用は、以前に多くのことを燃やしました。ルールはすべてのセキュリティ保護可能なもので同じですが、いくつかの要因がデータベース所有者の問題を悪化させます。
- 他のサーバーレベルのセキュリティ保護可能なもの（エンドポイント、サーバーロール、ログイン）はほとんど使用されず、移動されます。
- データベースレベルのセキュリティ保護可能なファイルは、通常、
dbo（データベースプリンシパル）または他のデータベースプリンシパルによって所有されることになるため、所有者はデータベースに含まれます - データベースの所有権をデフォルトでNTプライマリプリンシパルに設定すると、封じ込めの問題が発生します（所有者はADによって管理されるNT SIDであり、データベースファイルと一緒に移動しません。NTアカウントがサムストーン化されるなど）
- 最も重要なこと：データベース所有者には重要な副作用があり、具体的には
EXECUTE AS context。この後者の問題は、ほとんどのユーザーを燃やすものです。 Service BrokerはEXECUTE ASを広範囲に使用するため（メッセージ配信には暗黙のEXECUTE ASコンテキストがあり、明示的なコンテキストを持つキューのアクティブ化もある）、通常、この問題を最初に発見するService Brokerユーザーです。
ところで、元の問題を調査して修正してくれたKudos :)
データベースownerは、SQL Sever 2005で（適切な）スキーマが導入される前の時代に少し戻っています。
基本的にデータベースownerはデータベースのデフォルトのdbo（データベース所有者）であり、データベース自体はデータベースですオブジェクト。
SQL Server 20 docsから...
dboは、データベース内のすべてのアクティビティを実行する権限を暗黙的に持っているユーザーです。
以前のバージョンのSQL Serverでは、スキーマがオブジェクトを "所有"できなかった場合（またはむしろ、すべてのオブジェクト、テーブル、ビューなどがdboによって所有され、他のスキーマは存在しなかったことを明記する必要があります）「ユーザー」がそれを所有する必要がありました...理由は言うまでもありませんsomethingデータベースを所有する必要があります（そうでない場合、一般的な権限はかなり難しいでしょう。）
したがって、技術的には、SQL Serverの古いバージョン（またはアップグレードされたデータベース）では「Foo」テーブルではなく、「dbo.Foo」テーブルでした... dboが所有者でした。
SQL Server 2005の登場により、 "bar"という名前のスキーマと "Foo"という名前のテーブルがあると言うようなスキーマ所有のデータベースオブジェクトを持つことができます...これはbar.Fooになります...
SELECT * FROM bar.Foo WHERE etc = 'blah`;
トリッキーな部分は、ユーザー作成中データベースが自動的にownerとして設定され、問題が発生するという事実に関連しています従業員の離職など.
したがって、これをsaアカウントに変更するか、おそらく（私の経験では）組織のops/ITチームが管理できるドメインアカウントに変更するのがベストプラクティスです。
この article は、古い「所有者」の方法と新しい「スキーマ」ベースの所有権システムの違いを分析したものです。
所有者とスキーマの違いを理解するために、オブジェクトの所有権を確認してみましょう。 SQL Server 2000以前でオブジェクトを作成する場合、オブジェクトには所有者が必要です。ほとんどの場合、所有者は「dbo」であり、データベース所有者とも呼ばれます。