用於讀取和寫入表的單獨 SQL 登錄是好的設計嗎？
這是 SQL Server 的一個問題，但可能適用於幾乎任何 SQL 實現。
客戶端將使用 Web 服務 API。從安全的角度來看，我的想法是將所有相關數據 ETL 到一個表中，並讓客戶端從該表中提取。我們將表稱為 FoobarTbl。我還鎖定了 SQL 登錄，只能訪問這個表而沒有其他權限。
我通過創建兩個 SQL 登錄更進一步：
- 可以對錶執行 SELECT 的 SQL 登錄。（即 FoobarLoginRead (
- SQL 登錄，可以對錶執行 INSERT 和 UPDATE。（即 FoobarLoginWrite）。
這是一個很好的安全設計，還是矯枉過正和有問題？我觀察到，如果不添加 SELECT，UPDATE 操作就無法執行，這有點違背了使用單獨登錄來讀取和寫入同一個表的目的。
我的思考過程是：如果一個邪惡的使用者以某種方式獲得了 FoobarLoginWrite 的信任，他們將只能看到一個表，但他們實際上無法獲取任何數據。使用者惡意更新或插入數據是可接受的損失，因為源數據正在 ETL 到此表中。更大的問題是從表中獲取數據。
我是不是想多了，或者這是鎖定 SQL 登錄的合理方法？
“鎖定 SQL 登錄”是指對 SQL 登錄可以訪問的資源（例如表、視圖等）的有效權限。在我的例子中，我創建了兩個 SQL 登錄。兩者都有權訪問一張表。我的想法是給一個登錄 SELECT 權限到這個表，另一個登錄獲得 INSERT 和 UPDATE 權限到同一個表。
簡而言之，我要問的是同一個表有兩個單獨的登錄名，上面概述的內容是保護 SQL 數據的好方法，還是我做得過火了，這會被認為是糟糕的設計？
您只需要遵循最小特權原則。
如果您有一個實體，無論是使用者還是應用程序，該實體都應該有一個帳戶，該帳戶具有完成其工作所需的最低權限。因此，如果您將擁有一個只能從一個表中讀取的 Web API，那麼它的網站應該使用一個僅有權讀取該表的帳戶。
您的問題似乎沒有表明誰或什麼將使用讀/寫帳戶。如果沒有人會寫入表（我猜這是正確的，基於數據來自另一個來源的事實），那麼只有 ETL 程序應該有權寫入表。
我會使用 2 個單獨的儲存過程，一個用於讀取，另一個用於更新；如果需要插入，則第三個程序將執行此操作。
這樣，您只授予相關過程的權限，而不授予表本身的權限。
這並不總是可能的，但我發現這是一種合適的方法，可以提供最少的特權，同時具有允許所有必需操作所需的靈活性。
但是，需要更多的工作來建構健壯的儲存過程，如果存在其他約束/要求（例如：項目經理定義規範、客戶需要 XYZ 方法），這可能不是一個容易處理的負擔