Mistake #1: accepting sysadmin as the default fix. A principal should receive only the permissions needed for daily work; temporary privileges should be granted for a specific task and then revoked. section 14.1
The vendor account that can reach everything
An application team may request sysadmin rights to create and delete databases on a nonproduction server. A backup, monitoring, or security vendor may demand sysadmin on every instance. That account would have unrestricted access; if compromised, it could expose organizational data. Treat the request as a permissions-design problem, not an automatic approval. section 14.1
Listing 14.1 Creating a custom server role
CREATE SERVER ROLE AvailabilityGroupsFailover ; GO ALTER SERVER ROLE AvailabilityGroupsFailover ADD MEMBER [NT AUTHORITY\SYSTEM] ; GRANT ALTER ANY AVAILABILITY GROUP TO AvailabilityGroupsFailover ; GRANT CONNECT SQL TO AvailabilityGroupsFailover ; GRANT CREATE AVAILABILITY GROUP TO AvailabilityGroupsFailover ; GRANT VIEW SERVER STATE TO AvailabilityGroupsFailover ;
Use a custom server role to grant only the required server-level capabilities, such as availability-group operations, SQL connectivity, creation rights, and server-state visibility. section 14.1
Listing 14.2 Database role to allow stored procedure execution
USE model ; GO CREATE ROLE ExecSP ; GO GRANT EXECUTE TO ExecSP ;
Use a database role when the requirement is limited to executing stored procedures rather than controlling the entire SQL Server instance. section 14.1
