Is it best practice to revoke server permissions to the server “public” role on SQL Server instances?

Question

We have evaluated the Microsoft "best practice" policies (located at C:\Program Files (x86)\Microsoft SQL Server\number\Tools\Policies\DatabaseEngine\1033) on each of our SQL Server instances (example here). The following issue has been flagged up to us:

This provides a link to a Microsoft page which states the following as being best practice:

Do not grant server permissions to the server public role.

On reviewing the security, we can see that the public role has server permissions to view any database by default. We have run the following and re-evaluated the policy, but the issue is still flagged up.

REVOKE VIEW ANY DATABASE TO [public] AS [sa];

The only other permissions attributed to this server role are endpoint permissions to be able to connect via TCP/VIA/Named Pipes/Local Machine. If we remove these, surely the role will be superfluous.

QUESTIONS

• Should we be concerned about this? Is this something we really should look to address?
• What else do we need to do to properly resolve this issue?
• Are there any implications for doing this or not doing this?

Answer 1

Yes, you should fix this. If you have multiple DBs in the server, a legitimate user in one DB might have nothing to do in another DB and will not be a user in that and hence 'public'. Why would you give pubic user permission to view/access objects in a DB they are not entitled to?

Make sure to test the application after you fix these. Sometimes even a legitimate user might be missing appropriate grant permission and might have been working based on public Access, which won't work after you fix the 'public' role access. They needs to be granted explicit access through grant stmt to specific objects or via database roles or via user roles.

Answer 2

When revoking the "view any database" permission from the public server role, logins cannot see the databases any more by querying select * from sys.databases (except for master and tempdb), but they can easily circumvent this revocation by querying:

select db_name(5); 
select db_name(6);

So that "best practice" sounds nice, but is worth nothing.