Standardmäßig sind alle Datenbanken für alle Nutzer sichtbar, da jeder MSSQL Nutzer automatisch auch der PUBLIC Rolle zugewiesen ist.

Das wirft zum einen sicherheitstechnische Bedenken auf, das jeder die Namen aller Datenbanken sehen kann.

Zum anderen resultiert es in unnötig hohen Ladezeiten, wenn man sich beispielsweise mit Microsoft SQL Server Management Studio verbindet – denn hier lädt es dann erst einmal die gesamte Liste aller Datenbanken auf der Instanz, obwohl man sich ggf. nur auf ein paar wenige verbinden könnte. Hier könnte man zwar mit Filtern im Management Studio tricksen (die auch jedes mal wieder nach Beenden verloren gehen). Aber das ist auch nur Symptombehandlung.

Hier gibt es Abhilfe – man kann wie folgt Security Hardening betreiben.
Über folgenden SQL Befehl, ausgeführt auf der MASTER Datenbank, entfernt man das Recht, dass die Gruppe PUBLIC alle Datenbanken listen kann:

DENY VIEW ANY DATABASE TO PUBLIC

Wenn man nun neue User in der Datenbank anlegt, ist es wichtig, dass als Default-Datenbank für den User eine Datenbank angegeben wird, auf die er tatsächlich Zugriff hat. Für einen User, der noch keine Datenbanken hat und als DBCreator fungieren soll, kann man hier tempdb als Default Database verwenden. Dann kann dieser User sich einloggen, neue Datenbanken anlegen, diese haben dann automatisch ihn als owner. Er kann seine eigenen Datenbanken auch wieder löschen – und er sieht immer nur seine eigenen Datenbanken.

Falls man kein DBCreator benötigt, ist es Best Practice, bei einer angelegten Datenbank deren owner anschließend auf einen ganz anderen account zu setzen, als den ServiceUser, der später von außen drauf Zugriff haben soll. Und anschließend einen dedizierten User anzulegen (oder vorhandenen zu verwenden), der mit den ganz speziellen, wirklich benötigten Berechtigungen auf der Datenbank ausgestattet ist. Denn macht man das nicht, hat der User automatisch implizit sysadmin Rechte auf die Datenbank. Und das ist im Normalfall viel zu weitreichend (damit kann er auch andere Nutzer berechtigen, etc.).

Da lohnt es sich, genau zu prüfen und zu dokumentieren, was der Serviceuser wirklich machen muss. Read, Write, ggf. Ausführen ausgewählter Stored Proc, u.s.w. – das mag zwar auf den ersten Blick mühsälig erscheinen, ist es aber am Ende in jedem Fall wert.