0

I would like to do this as somewhat of a last line of defense as we will be replicating production to test regularly. Is this good practice?

nene
  • 9
  • 1
  • 1
    For replication you can use cross-site restores. i.e. you can restore backup of prod db on dev database. By doing this you will get fresh data in dev, you will validate that prod backups can be restored, you will get hand-on practice on backup/restore procedures and also your dev will be identical copy of prod (including physical layout, statistics and exec plans). – ibre5041 May 14 '15 at 08:06
  • @ibre5041 - execution plans will almost certainly not be the same, unless everything about the two machines is exactly the same. – Hannah Vernon May 14 '15 at 19:40

2 Answers2

3

Not only is it a best practice, it's mandatory to any major compliance requirements such as PCI V2 & V3, SOX, and almost any auditor will ask about it. Yes, having them on the same network is asking for major problem.

Page 5 of the PCI DSS V2:

For example, there must be a clear segmentation of functions and segregation 
of networks with different security levels; segmentation should 
prevent the sharing of production and test/development environments;

Page 32: 6.4.1 Separate development/test and production environments.

Ali Razeghi - AWS
  • 7,518
  • 1
  • 25
  • 38
1

I have to say yes. By blocking dev/test you are making sure that application changes are not accidentally updating production data. In many cases sensitive data on dev/test is scrubbed after restore and by blocking you are making certain that no one with access to test can access sensitive data in production.

If you are using SQL Server with MSDN licensens you have to segment the Development servers from the production servers anyways. (https://www.directionsonmicrosoft.com/licensing/2013/06/licensing-sql-server-development-and-test)

Spörri
  • 4,714
  • 13
  • 28