1

歴史的/監査可能なデータベースに対する@PerformanceDBAの回答を読んで、彼は次の声明を出しました:

実際の (標準 ISO/IEC/ANSI SQL) データベースでは、ユーザーに INSERT/UPDATE/DELETE パーミッションを付与しません。GRANT SELECT と REFERENCES のみ (選択したユーザーに対して) すべての INSERT/UPDATE/DELETE は、ストアド プロシージャを意味するトランザクションでコード化されます。次に、各ストアド プロシージャの GRANT EXEC を選択したユーザーに付与します (ROLES を使用して管理を軽減します)。

これは本当ですか?INSERT/UPDATE を動的に生成する ORM ツールとどのように連携しますか?

アップデート

では、例を示します。AdminUserの 2 つのインターフェイスを備えた Web アプリケーションがあります。管理者側は、数千とは言わないまでも数百の個別の SQL コマンドを動的に生成できる重いORM を使用します。

ユーザーとのやり取りははるかに簡単で、いくつかの投票ボタンの UPDATE/INSERT を処理する SP が 10 個ほどあります。明らかに、アプリケーションを実行するユーザーの権限セットは大きく異なります。管理者側では、ORM の DB ユーザーは関連するテーブルへの完全な CRUD アクセス権を持っています。このアプリケーションには SP はまったく使用されていません。また、ドメイン モデルのビジネス ロジックを経由せずにデータに触れることは考えられません。 . バルク データ インポートでさえ、ORM を通じて処理されます。ユーザー側の SP は、特殊なケースであるという理由だけで、この原則に対する小さな譲歩を考えています。

さて、元の質問の上記のステートメントはやや気がかりです。これは「実際の」データベースのようなものであるか、少なくともそれに近いものであると考えているからです。

4

2 に答える 2

1

これが最良の設計であり、私が通常実践したいことです。アプリケーションからのアドホック クエリは煩雑で、調整が難しく、トラブルシューティングとトレースがさらに困難になる可能性があるため、ストアド プロシージャを使用して抽象化のレベルを設定するのが最も簡単です。アプリケーションは、ストアド プロシージャの呼び出しのみを行うことができます。ストアド プロシージャは、データベースへの API と考えてください。

したがって、上記が設計目的である場合、アプリケーション ユーザーはデータベース上でSELECTのみ必要です。EXECUTEこれが理由です:

create procedure MyTestProcedure
with execute as 'UserWithDMLRights'
as

    -- your CRUD code

go

一般的なアプリケーション ユーザーが と のみを持っている場合はSELECTEXECUTE上記のストアド プロシージャを実行する権限で十分です。INSERT/UPDATE/DELETEストアド プロシージャ内の は、 のセキュリティ コンテキストで実行され、そのデータベース ユーザーはアクセス許可UserWithDMLRightsを持っている必要があります。INSERT/DELETE/UPDATE

ORMに関しては、私はあなたに同意する傾向があります。L2S は で多数のアドホック クエリ呼び出しを行うだけsp_executesqlであると信じているため、その理論と上記のセキュリティ プラクティスを使用すると問題が発生すると思います。

于 2011-12-28T13:15:06.103 に答える
1

レイブでおじいちゃんのようにジャイブします。ORM は SP を利用できますが、SP を最大限に活用することはできません。

SP Only は確かにかつての生活のようでした。それは第 11 の戒めのようなものでしたが、ご指摘のとおり、ORM は実際にはそのようには機能しません。以前は、SP レイヤー全体を一種の思春期前の ORM と考えていました。リレーショナル DB を取得し、多数の結合を作成し、オブジェクトにデータを入力するために必要な列/プロパティを含む一連のデータを返しました。

最近では、動的 ORM タイプのアプリでは、テーブルにパーミッションを指定する必要があります。DBA が仕事をしている場合、安全性は劣らず、作業が少し増えるだけで、テーブルで何が許可されているかについて、より多くのコミュニケーションが必要です。 DELETE が必要ない場合、DBA は、DELETE のパーミッションを与えないようにする必要があります。

優れた DBA は、テーブル アクセスを使用する保護された DB が SP のみのアクセスを使用する DB と同じくらい安全であることを知っています。自信のない DBA にそのことを納得させるのは、はるかに難しい問題です。

于 2011-12-28T13:29:44.330 に答える