使用存儲過程訪問數據會提供哪些安全優勢？

我已經看到了一些指導，這建議您通過分層通過存儲過程的所有數據訪問安全的數據庫。使用存儲過程訪問數據會提供哪些安全優勢？

我知道，SQL Server，可以保護表，偶數列針對CRUD操作。

例如：

--// Logged in as 'sa' 
USE AdventureWorks; 
GRANT SELECT ON Person.Address(AddressID, AddressLine1) to Matt; 
GRANT UPDATE ON Person.Address(AddressLine1) to Matt; 

--// Logged in as 'Matt' 
SELECT * from Person.Address;      --// Fail 
SELECT AddressID, AddressLine1 from Person.Address; --// Succeed 
UPDATE Person.Address SET AddressLine1 = '#____ 2700 Production Way' 
     WHERE AddressID = 497;      --// Succeed

既然你可以確保表和偶數列針對CRUD操作，如何使用存儲過程中沒有提供額外的安全性，還是安全性的管理？

來源

2009-01-07 Matt Brunell

可能是因爲如果你是一名DBA是有效的最關鍵類型的安全性 - 它可以保護利用程序代碼的程序員來編寫查詢數據庫。（半開玩笑......） – dkretz 2009-01-08 22:36:02

存儲過程，允許用戶，但只有有限的方式執行CRUD操作（插入，更新，刪除）提供額外的安全。例如，允許用戶Matt更新某些行的地址，但不能更新其他行的地址。

它允許你添加數據的檢查，以確保插入的數據是有效的數據，不是隨機的垃圾。對於大多數情況，您可以使用約束和/或觸發器來完成這些工作，但有一些限制。存儲過程通過確保用戶允許執行的操作來增強安全性。

它很容易，雖然單點接入，通過應用程序來控制，而不是通過任意數量的接口來跟蹤對數據庫的更改。該過程可以更新審覈日誌。

來源

2009-01-07 19:00:02

因爲通過限制所有訪問這些存儲的特效，你已經建立了一個定義的數據庫接口，通過它所有的訪問必須發生......既然你將有DENY'd直接選擇，插入，更新和刪除操作依據表和視圖，沒有人可以直接寫自己設計的SQL，做任何他們想要的...如果你想插入到限制在員工分配到三個以上的項目，只有具有這些員工的職員表如果能力測試的分數大於85，那麼你可以在SaveEmployee sproc中寫入這個約束條件，並且它會拋出一個例外情況給任何試圖這樣做的客戶端代碼...

當然你可以做同樣的事情使用客戶端代碼，但使用sProcs make S中的過程更容易設計和管理，因爲它是在同一個地方，並嘗試訪問該數據庫系統所有應用程序都符合你的存儲過程定義任何約束和/或安全規定......沒有惡意開發者編寫如果該SProc是插入或更新記錄的唯一方式，則命中數據庫的新獨立客戶端應用程序可以忽略或解決SProc中的約束或安全規定...

來源

2009-01-07 19:00:13

這是「流氓」，而不是「胭脂」......除非他們正在開發新的化妝品系列） – 2009-01-09 14:57:54

呵呵！謝謝......我編輯了拼寫錯誤......（我從一個他們沒有教我們打字的年齡......我從來沒有學過......所以我用了三個手指，並做了很多拼寫錯誤！） – 2009-01-09 15:39:54

您可能不想給馬特carte -blanc直接更新某些表或列。如果Matt決定這樣做：

UPDATE Person.Address SET AddressLine1 = NULL

哎呦。 Matt忘記了WHERE子句並且只是清理了你的數據庫。或者，也許馬特剛剛對他的老闆生氣，並決定在一天結束時退出。或者，也許馬特的密碼並不像應該有的那樣安全，現在是黑客了。

這只是一個簡單的例子。對錶和列的控制可能變得更加複雜，並且可能通過除存儲過程以外的任何其他方法而變得不可行。

來源

2009-01-07 19:00:20

嗯...不知道這是否真的是安全性好處...保護數據庫免受開發人員犯錯誤...備份？ – 2010-01-27 12:42:36

存儲過程更好，因爲在存儲過程（IIRC）的安全性將在表/列王牌安全。

對於單表訪問，這沒什麼大不了的。但是，如果您的操作涉及多個表上的多個列，則對於表/列有一個訪問/拒絕標誌可能無法適用於所有情況。

但是，存儲過程可以執行組合操作，您可以在其上適當地設置安全性。

來源

2009-01-07 19:01:26 casperOne

在大多數（所有？）RDBMS中，您可以將特定表上的「授予」訪問權限給特定用戶。一個存儲過程可以作爲一個不同的用戶運行，而一個用戶可以訪但是，存儲過程與訪問整個表格不同，它可能會首先檢查某些內容並僅返回符合您特定安全性問題的行。

您可能能夠對視圖執行類似的檢查，但存儲過程通常更靈活，因爲它們幾乎可以運行任何SQL - 比較結果並決定返回哪些行。

來源

2009-01-07 19:04:13

在SQL Server中，如果正確使用存儲的特效（不需要動態SQl），則不必授予對錶的任何直接訪問權限。這意味着你的用戶只能執行由proc定義的東西。如果您的數據庫中有任何財務數據或敏感數據，則只有儘可能少的人（通常只有dbas）才能直接訪問表。這嚴重降低了欺詐或心存不滿的員工甩掉了您的業務關鍵數據或員工竊取個人信息從而實施身份盜用的風險。在會計方面，這是一個必要的內部控制和開發人員的便利或個人希望從用戶界面動態地執行所有操作應該被數據的不安全性所壓倒。不幸的是，在所有太少的公司中，事實並非如此。大多數開發者似乎只擔心他們的數據會受到外部威脅，但內部威脅通常要關鍵得多。

如果您限制用戶在表級別，然後用戶啓動查詢來執行合法插入，則不會發生。如果您授予他們插入權限，則他們可以執行任何他們想要的特定插入，而不僅限於來自用戶界面的插入。通過存儲過程，他們只能執行proc特別定義的事情。

來源

2009-01-08 19:41:27 HLGEM

簡而言之，它可以讓你在功能上而不是結構上定義安全。換句話說，它限制了用戶允許做的事情（具有更大的粒度），而不是什麼數據庫對象可訪問（以非常粗的粒度）。

請注意，我們正在談論「由DBA「而不是站點或系統管理員或軟件模塊，所有這些都是有用的，並且是整體安全基礎架構的一部分。

來源

2009-01-08 19:50:58 dkretz

在這裏詳細討論的第一個好處是對權限的更好控制 - 用戶可以被限制到特定的行，而不僅僅是每列（在大型系統中這是一個很好的方法）; SP可以執行業務邏輯和事務邏輯;數據可能只能根據其他數據（例如連接）進行檢索;更新可能一次只限於單行;等等。

其次，這可以提供額外的防範SQL注入（儘管它不完整和自動）的保護層。雖然這可能被破壞，但是SP中的動態SQL或錯誤的串聯調用，SP確實會強制執行參數類型，而不會將代碼與數據分離。

第三，它涉及到控制，在開發階段 - 通常你已經訓練數據庫管理員寫的SP，而不是程序員（誰在代碼中訓練的...）

這是不提到非安全性好處，例如更好的性能。

來源

2009-01-08 22:32:19 AviD

在存儲過程中，您可以添加邏輯控件。如果某些內容不正確，則可以返回錯誤代碼，而不是直接更新表數據。

例如，您有一個反饋系統。反饋只能在管理員開始反饋活動後提交。它只是更新某個表中的一個標誌。然後，當用戶提交反饋時，SP可以檢查標誌是否已設置。

Select @IsFeedbackDefined = IsFeedbackDefined From sometable where ID = @ID 

IF @IsFeedbackDefined is Null or @IsFeedbackDefined = false 
Begin 
    Return -2 --can not submit feedback 
End

來源

2009-01-20 11:19:51

使用存儲過程訪問數據會提供哪些安全優勢？

回答

相關問題