私たちには、マスターデータベースの認証を必要とするソフトウェア(db所有者のみが作業する)の製造元があります。残念ながら、製造元は、masterデータベースへのこのアクセスが必要な理由を教えてくれません。この権限がないと、アプリケーションは起動しません。
あなたの意見は何ですか?そのようなソフトウェアを見たことがありますか? 200の異なるアプリケーションがありますが、これは永続的なアクセスが必要な最初のアプリケーションです
セキュリティに異議はありますか?
代わりに、データベースが非常に小さいため、SQL Expressインスタンスをインストールできます。あなたの観点からマスターDBにアクセスすることは良い考えではありません。
少なくともインストール中に、sysadminサーバーロールメンバーシップを必要とするソフトウェアを見ました。ソフトウェアがmasterにdboが所有するオブジェクトを作成する可能性があります。db_ownerは、sysadminロールのメンバーシップに頼らずにそれを可能にする最も簡単な方法です。より詳細なアクセス許可を提供することは可能かもしれませんが、アプリケーションコードの変更が必要になる可能性があり、ソフトウェアが具体的に何をしているか、ベンダがそのような変更をサポートする必要があるかを明確に知らなければ、必要な最小限のアクセス許可を付与できません。
個別のインスタンス/マシン(Azureを含む)は、セキュリティ上の懸念を軽減するのに役立ちます。 SQL Server Expressは、リソースの制限内で作業できればHAオプションが制限されることに注意して、コストを削減するオプションになる場合があります。
おそらくこれは当てはまらないはずですが、多くのベンダーが適切に機能するためにインスタンスへの驚くほど高いレベルのアクセスを必要とすることを見てきました。本当に必要ない場合もあれば、必要な場合もありますが、意図的にセットアップ手順を無視すると、ベンダーがサポートしない場合があります。また、製品の更新によって物事は簡単に変更される可能性があるため、要件に注意しないと、将来の問題のリスクを負うことになります。
これらのタイプのシナリオでは、潜在的なセキュリティギャップの責任からあなたを排除するのに役立つセキュリティ例外/権利放棄にビジネスが喜んで署名することが常にわかりました。
同様のシナリオがあり、何が行われたか-必要な権限の付与、SQL監査/ XEventsのセットアップ、インストールの監視、作成されたオブジェクトの識別、一部のアプリケーション機能のトレースの最初の実行、アクセスされたオブジェクトのマスターでのキャプチャ、特権アクセスの取り消しと許可必要な(読み取り)アクセス。私たちの場合、アプリはマスターのパフォーマンスDMVからデータを読み取っています。これは長いプロセスですが、マスターDBを保護するのに役立ちます。 Dan Guzmanが述べたように、SQL Expressには独自の制限があります-DBサイズ、メモリ、SQLエージェントなし、HAなし、プロファイラーなし。
私たちの製品の1つで実際にCREATE Assembly ...
を使用することについて真剣な議論がありました。そうした場合、すべての更新でdba
レベルのアクセスが必要になります。一部の人々は、アプリケーションが更新のインストール手順中ではなく、起動時にデータベースの移行を行うように実際に設計します。これには、アプリケーションにdba
レベルのアクセス権が必要です。
無関係な理由でそれを使用しないことになった。
GRANT VIEW ANY DEFINITION TOが解決策でした。これで、アプリケーションはdb ownerロールなしで起動します。