Dangerous permissions and shared logins on SQL Server

Performance gets attention because users complain. Security drift often does not — until audit, ransomware, or an ex-employee account becomes a story.

Common findings

• Many logins in sysadmin “just in case”
• Application uses a highly privileged shared login
• Personal logins with db_owner everywhere
• Legacy guest or public grants that nobody remembers
• Linked servers with stored credentials broader than needed
• xp_cmdshell or OLE automation enabled without a control story

Why shared logins hurt

You cannot attribute actions, revoke a single leaver cleanly, or apply least privilege. Every integration becomes a blast radius.

Practical hygiene without freezing the business

1. Inventory privileged principals
2. Separate human admin access from application access
3. Prefer Windows groups / modern identity patterns where possible
4. Grant the minimum that meets the app’s real needs
5. Document break-glass accounts and monitor their use

Health checks and trust

A free health check is not a full security audit. It does flag high-risk permission patterns so leadership can prioritise a proper lockdown without guessing.