We need to walk a fine line when granting privileges to a user to perform certain task. Principle of Least Privilege says that a user be granted only those privileges, which are required to perform their task – nothing more, nothing less. This principle is also known as the principle of minimal privilege or the principle of least authority.
We should always follow the principle of least privilege when granting permissions to database users. A database user, whose task is to extract reports, should be granted read permissions to the schema. Image if the same user has write permissions to the database, potentially database can be compromised; sales data can be fudged to make it look great before the management if a user has extra privileges.
There is no direct way or a charter, which lists set of permissions vis-à-vis functional task. It varies from organization to organization. In order to come up with a security model, start by assigning least level of privileges (that may seem appropriate to you) to perform the intended task and then test. As a quick tip try to remove one privilege at a time and check the impact on the task under consideration. This way you will be able to formulate a security model.
I came across an incident recently where a team received a database backup (was in Oracle though not SQL Server) from a customer to fix an issue and a user account that was used to restore the backup actually overwrite password profiles that were set-up internally. It was discovered very late when some of the application users reported passwords being expired after one week of creation.
Security is very important for an organization to sustain for long, and there is no alternative but to conscientiously follow principle of least privilege.
SQLpathy 