最終的にホスト マシン上の共有 SQL Server 2008 データベースに存在するデータベースを開発しています (ホスティング プロバイダー)。すべてのテーブルとクエリが dbo によって所有されていることに気付きました。これが共有ホスト上でのセキュリティ上の問題かどうかを知りたいです。データベース オブジェクトの所有権を割り当てるためのベスト プラクティスは何ですか。共有ホスティング環境では、db オブジェクトの所有権を db の管理者ユーザーに譲渡する必要がありますか?
ありがとう
最終的にホスト マシン上の共有 SQL Server 2008 データベースに存在するデータベースを開発しています (ホスティング プロバイダー)。すべてのテーブルとクエリが dbo によって所有されていることに気付きました。これが共有ホスト上でのセキュリティ上の問題かどうかを知りたいです。データベース オブジェクトの所有権を割り当てるためのベスト プラクティスは何ですか。共有ホスティング環境では、db オブジェクトの所有権を db の管理者ユーザーに譲渡する必要がありますか?
ありがとう
dbo を使用する場合のベスト プラクティス
dbo を使用してオブジェクト/テーブルを作成する場合、それらのオブジェクトにエイリアスするログインには db_owner ロールが必要であり、そのデータベース内で「何でもできる」ことを意味します。通常、そのデータベースにアクセスするユーザーは、ほとんどの場合 CRUD を必要とします。つまり、テーブル内のデータと SP の実行だけが、アカウントが実行できるすべてのはずです。ただし、 db_owner の場合、私の意見ではセキュリティ上の欠陥である何でもできます。
サービス アカウント (インタラクティブではない) であるアプリケーション アクセス (svcact_app1) 用のログインと、db_owner のものである DDL などの Windows ログイン (したがって、デフォルトで dbo) が必要です。各オブジェクトは dbo が所有できますが、付与は svcact_app1 ログインの関連付けられたユーザーに付与する必要があります。
これにより、アプリ接続がデータを変更し、それに付与された SP を実行するだけで、他には何もできないという分離が得られます。これを行わず、攻撃者が SQL インジェクションの起動に成功した場合、攻撃によってテイルがドロップされたり、SP が変更されたりする可能性があります。
dbo スキーマは、管理者または DB 所有者のスキーマです。これは、変更する手順を実行しない限り、テーブルを作成するときの既定のスキーマでもあります。
ホスト環境であっても、データベース内のセキュリティを制御できます。セキュリティ戦略に集中し、その戦略に基づいてデータベース内のオブジェクトに対する権限を付与、取り消し、または拒否する必要があります。dbo スキーマだけを回避しても、セキュリティは向上しません。