我開始在工作中使用一個小型的內部Web應用程序，主要是一個概念驗證，但我們想把它看作是一個「真實」的應用程序。作爲一名DBA我沒有太多經驗，我的團隊也沒有人（因爲它是一個PoC，所以有一個人並不特別重要）。我應該爲不同的查詢類型分開SQL帳戶嗎？
但我想知道，如果這個Web應用程序上市，我們應該有不同的查詢類型的數據庫服務器的帳戶？例如。有一個SQL帳戶用於SELECT查詢，另一個用於UPDATE/DELETE？我無法說服自己有這樣做的任何特殊優勢，但我之前聽說過這種技術，所以必須有一定的價值。
對於不同類型的任務（例如，批處理作業與Web服務）有不同的帳戶，並對連接計數等有各自的限制是有用的。這意味着如果你的批處理作業變得瘋狂，它無法取出你的網絡應用程序。
您還希望不同帳戶擁有不同的權限。例如，如果您的管理員和用戶應用是分開的，他們應該擁有自己的帳戶。這有助於確保如果您的用戶應用程序遭到入侵，它將無法對您的數據造成太大的損害。
在這兩方面有一個「只讀」用戶是有用的，但只有當你的應用程序沒有寫入。
對於查詢類型，您不需要單獨的帳戶。通常，與數據庫的連接使用與訪問Web應用程序的用戶無關的數據庫用戶。
您可以限制匿名用戶訪問該站點時有權訪問的主帳戶的查詢類型。但是，我認爲您不需要該子集中的每個查詢都有不同的用戶。
你想要關注的是每個用戶可以訪問哪些數據庫/表，而不是特定類型的查詢。
都是應用程序使用的這些帳戶類型，我會想象您所指的練習是試圖阻止sql injection attacks。如果您確保清理輸入信息，可能並不是必需的。記得bobby tables！
只讀帳戶的另一個原因是允許管理員用戶直接在db上運行報告來處理系統活動和調試生產問題。
在「公共」應用程序中，一個好的做法是使用服務帳戶訪問數據庫（運行查詢，exec存儲過程），並在代碼級別計算用戶訪問控制。
這可以防止您需要將新用戶添加到數據庫的安全管理器中。
我唯一一次看到單獨的SQL數據庫帳戶正在使用的是分開應用程序功能，即使如此，他們是服務帳戶。即
然後，您可以運行Web應用程序作爲ReportService的或TransactionService，根據自身的需要。
通過將這兩個概念相加（代碼中的用戶訪問，服務的功能區分），您可以有效地對您的用戶訪問控制機制進行單元測試。否則，你需要在數據庫中設置一個用戶，然後看看你從數據庫中得到了什麼樣的行爲。
是的。見Principle of least privilege。
在信息安全，計算機 科學等領域，最小特權 原則，也 稱爲最小 特權或只是最小特權原則， 要求，在特定 抽象層計算 環境中，每個模塊（如 過程中，用戶或 基礎上，我們正在考慮的層的上一個節目） 必須能夠僅訪問這樣 信息和資源所必需 其legitima te 的用途。 1 [2]當應用於用戶， 術語至少用戶訪問或 至少特權用戶帳戶（LUA） 也被使用，指的是 概念，在所有時間的所有用戶 應 用盡可能少的權限運行可能的，並且還用盡可能少的權限啓動應用程序 。
有很多技術可以幫助公司接受這一原則。許多技術屬於同一類別，重點在於保留每一層的最終用戶身份並回答以下問題：
'誰是真正的'用戶'？
您至少應該意識到決定忽略最低特權原則並使用單個共享數據庫用戶帳戶來處理中間層/應用程序服務器和數據庫之間的所有交互的後果和風險。有一些技術可以保持數據庫應用程序開發人員的工作效率，並且仍然在應用程序中提供強大的安全功能在這個空間技術的
實例包括但不限於：
除了安全性之外，還有其他一些優勢來支持最小權限原則。在許多數據庫中，只讀連接可以執行得更好，因爲它不需要知道和/或參與事務。
這個問題說它是在談論「SQL帳戶」。所以你的答案是多餘的。 – tialaramex 2009-06-20 14:45:37