SQL 20XX and Replication Manager

Hi Mike,

He could look at SQL encryption to secure the data within the database

Mike

Apologies for grammar and spelling errors. Sent from Windows 7.5 HTC

Hi Mike,

if you know where to change that data in the tables, then i would think that a sql script is able to do so. Some customers doing SQL modifications when cloning SAP using RM. RM does only do the SQL copy, mount and sql recover portion. After that they use a set of scripts around RM to modify the database and SAP environment to form a Test, QA or DEV environment...

Chris

Hi Mike's

Couple of options for SQL Encryption. The scenario will control point at which encryption occurs and the level of compliance needed. They may just need to alter mutliple columns of data i.e. all personal information, but this may need to be done in a controlled manner so there are no gaps occuring. Running a script needs to be done in a controlled manner to meet any such compliance issues.

Database Encryption in SQL Server 2008 Enterprise Edition

Summary: With the introduction of transparent data encryption (TDE) in SQL Server 2008, users now have the choice between cell-level encryption as in SQL Server 2005, full database-level encryption by using TDE, or the file-level encryption options provided by Windows. TDE is the optimal choice for bulk encryption to meet regulatory compliance or corporate data security standards. TDE works at the file level, which is similar to two Windows® features: the Encrypting File System (EFS) and BitLocker™ Drive Encryption, the new volume-level encryption introduced in Windows Vista®, both of which also encrypt data on the hard drive. TDE does not replace cell-level encryption, EFS, or BitLocker. This white paper compares TDE with these other encryption methods for application developers and database administrators. While this is not a technical, in-depth review of TDE, technical implementations are explored and a familiarity with concepts such as virtual log files and the buffer pool are assumed. The user is assumed to be familiar with cell-level encryption and cryptography in general. Implementing database encryption is covered, but not the rationale for encrypting a database.

I assume we want to continue to allow access of that critical data to another party within the customer organization or a third party.  Encryption will break that access.

This is a question outside of EMC Core, more EMC Consulting...

But because data security is a significant concern, we should _not_ rely on RM in doing any of this data de-sensitizing.  We should indemnify RM out of that task and put it squared on the customer team with their scripts. 

What if a RM post-script fails to fire?  The third party now gets access to sensitive data and causes a security violation? No thanks.

We should also consider we are writing to a replica.  If we are writing to a clone, then all recovery from that clone to production in the event of a DR is gone.

Recommend;

  *   Mount replica read-write and with recovery in RM (ideally snap of clone in VNX)

  *   Identify what columns need changing and like mentioned perform a bulk update script on those columns with an cremental data or number source (1-100000000 etc) or use a RAND function in T-SQL.

  *   Let the third party access the data

  *   Upon completion, unmount and disgard that replica (if not a snap or RP bookmark) - acutally delete it.

James.