データベースで、次の役割を持つユーザーを作成しました。
問題は、ユーザーのロールを変更したくないが、データベースを復元する権限を与えたいことです。
restoreへのアクセス許可のみを付与し、データベースの削除や変更は行わない回避策はありますか?
背景情報:
私が働いている会社がアプリを作成しました。そのアプリのユーザーには、データベースをバックアップおよび復元する権限が必要ですが、別のデータベースを作成したり、既存のデータベースを削除したりすることはできません。また、お客様がdb_owner
の役割を持つ別のユーザーになりたくないので、顧客は好きなように物事を操作できます。
アプリの価格はクライアントの従業員数に基づいているため、クライアント側にアプリをインストールするときに、ファイルを使用してすべての詳細(従業員数を含む)を指定するデータベースを作成しますが、誰かがファイルを変更してデータベースを複数回追加する可能性があるため、ユーザーに何かを実行する権限を付与しないことでインスタンスを保護したいと考えています。それは複雑ですが、彼らが望んでいることです。
SQLサーバーレベルではこれを実行できません。しかし、OSレベルでこれを行うことができます。このルートを試してください:
ユーザーは物理ファイルにアクセスできるため、データベースを削除できます。しかし、データベースが暗号化されているため、データを変更したり、表示したりすることはできません。
注意してください!
。ldfおよび.mdfファイルのバックアップには明らかな欠点があり、SQL Serverを停止する必要があり、差分および増分バックアップを実行する方法はありません etc
ただし、明らかな欠点があり、そのようなバックアップに関する情報はシステムテーブル[msdb]。[dbo]に保存されません。 [Backupmediafamily]および[msdb]。[dbo]。[Backupset]。また、サーバーが増分バックアップまたは差分バックアップを実行している場合、.ldfファイルと.mdfファイルを復元すると、 backup chain に深刻な混乱が生じる可能性があります。
はい、これは実際には Module Signing を使用してかなり簡単に達成できます。モジュール署名を使用して、モジュール(この場合はストアドプロシージャ)を作成し、ユーザーやログインではなく、モジュールに必要なアクセス許可を付与します。モジュールを実行する権限のみをユーザーに付与します。そして、これを行うことで、復元機能を効果的に許可するのに十分なだけでなく、RESTORE
ステートメントをハードコーディングすることで、基本的に復元のみの権限を付与することになりますこの特定のデータベース。
詳細な手順、説明、およびウォークスルーデモは、次の場所にあります。
誰にも許可せずに安全かつ簡単に高レベルのアクセス許可を使用:サーバーレベル
ただし、簡単にするために、以下に基本的な手順を示します。
(ストアドプロシージャは[master]
DBに作成されると想定します。これは、証明書を別のDBにコピーする必要がないことを意味します。ストアドプロシージャは、ユーティリティデータベースで簡単に作成できます。その場合は、リンクされたブログ投稿の指示に従って、証明書を[master]
にコピーするだけです)
RESTORE
ステートメントと同じくらい簡単にすることも、@DBName sysname
の入力パラメーターを受け入れ、そのパラメーター値を使用して動的SQLを構築することもできます。これにより、特定のDBの復元が可能になります。 、またはCASE
ステートメントで使用される@DbToRestore TINYINT
パラメータを使用すると、事前定義されたデータベース名の限定されたセットから選択して復元できます。dbcreator
固定サーバーロールに追加します。[master]
にログイン用のユーザーをまだ持っていない場合:顧客のログイン用に[master]
にユーザーを作成します。EXECUTE
権限を付与します。セキュリティを強化するために、何らかの方法でパスワードを取得できた場合は、別のモジュールに署名したり、このモジュールに再署名したりしないようにすることをお勧めします。これは常に必要なわけではありませんが、システムを顧客に配布するので、ここではおそらく良い考えです。
秘密鍵がないと、証明書はモジュールが署名されていることのみを検証できますが、もはや何にも署名できません。モジュールに署名すると、関連付けられた証明書ベースのログイン(つまり、dbcreator
に追加されたログイン)のアクセス許可が適用されるため、顧客がこれらのアクセス許可を独自のモジュールに適用できなくなります。 。また、お客様がこのストアドプロシージャを変更して、防止しようとしていることを実行した場合、シグネチャは削除されます(つまり、ストアドプロシージャを元のコードに戻した場合でも)モジュールに昇格されたアクセス許可がなくなります。 。
同様の質問に対する、次のDBA.StackExchangeの回答もご覧ください。
既存のデータベースへの復元を実行するには、dbcreator権限が必要です。または、ログインは Microsoftのドキュメント に記載されているsysadminのメンバーである必要があります。
権限
復元するデータベースが存在しない場合、ユーザーはRESTOREを実行するためにCREATE DATABASE権限を持っている必要があります。 データベースが存在する場合、RESTORE権限のデフォルトは、sysadminおよびdbcreator固定サーバーロールのメンバーとデータベースの所有者(dbo)です(FROM DATABASE_SNAPSHOTオプション、データベースは常に存在します)。
RESTORE権限は、メンバーシップ情報が常にサーバーですぐに利用できる役割に付与されます。固定データベースロールのメンバーシップは、データベースがアクセス可能で損傷していない場合にのみ確認できるため(RESTOREが実行された場合とは限りません)、db_owner固定データベースロールのメンバーにはRESTORE権限がありません。
ddladmin-db_ddladmin固定データベースロールのメンバーは、データベース内の任意のデータ定義言語(DDL)コマンドを実行できますが、データベースを復元することはできません。
Ddladminとdbownerの権限の違いを理解したい場合は、これをチェックしてください thread 。
...復元する権限を付与しますが、データベースの削除や変更は許可しません
短い答え:いいえ。
データベースを復元するには、まず既存のデータベースを削除する必要があります。これらの責任を分離する方法はありません。
しかし、私にとってより重要なのは、なぜこれを実行したいですか?
ほとんどの人はデータベースの復元を理解していません(ヘック;ほとんどの人はデータベースが何であるかを理解していません!)
ほとんどの人にとって、データベースの復元は、デロリアンに入り、1955年に戻って、到着したときに彼らがはまだすべてを知っていることを知っているようなものですアポロの月面着陸、ウォーターゲートのスキャンダル、ZZトップなどについて。
彼らは彼らのデータベースが一緒に移動しないが、代わりに1955年のネイティブ、幸いにも無知これらすべてのもの、さらに悪いことに、彼らはほとんどまたは失われたデータをすべて取り戻す方法はありません。
(OK、本格的なOracleデータベース、RMAN、およびリカバリカタログを使用して実行できますが、ここではあまり役に立ちません)。
obliterateデータへのアクセス許可は非常に厳しく制御され、onlyが実際に何であるかを知っている人に与えられるべきですそれを使って.
そして、いつものように、alwaysBiggestツールとBestツールをツールボックスに保持します、他の人が作る混乱をクリーンアップできるようにします。