Is it best practices to separate databases that are used by public website applications into their own database instance, from those databases that have PII info and company IP info? The idea being for security reasons. I have around 30 databases that I am migrating to a new environment and I am finding this to be the hardest decision to make. Does anyone have any advise?
Best practise would to be have these databases on completely separate servers, although virtual servers could be a good option if the network interface is separated by the hypervisor (i.e. it is not possible for one VM to sniff the traffic of other VMs using the same card).
The reason is that if one database is breached, the others are not breached too. Yes, you can setup different users with permissions only to their own database, however defense in depth is recommended. If there are any misconfigurations in SQL server, this will add additional protection.
The risk calculation you have to make is whether any breaches will cost the company more than the cost of implementing this.
Single loss expectancy (SLE) = value of asset * exposure factor
Annualised loss expectancy (ALE) = SLE * annual rate of occurrence (ARO)
Value of asset is everything involved in setting up the databases, including acquiring the data, the value of it to owners and users, and the value of the asset to competitors or attackers.
Exposure factor is the percentage of loss a realised threat would have.
ARO is the number of times a threat takes place per year (1 for once a year, 0.5 for once every two years, 2 for twice a year).
So if your ALE is less than the cost to implement and maintain a system with a separate database server for each database per year, then it isn't. However, middle ground could be found and you could separate the data onto a few servers until the numbers stack up.
Different instances are a step up in security over the same instance. However, vulnerabilities that allow an attacker to gain control of the whole server will mean that all of your databases are compromised at once. Such as this one, in an earlier version of SQL Server. There is no guarantee that vulnerabilities such as this one will not be discovered in future.