August 19, 2018 at 6:38 am
So long story short, I have to encrypt all our databases in my system to satisfy GDPR requirements.
I had a plan for one particular host of MSSQL databases - to simply utilize TDE. I easily made the change in our non production. Then, just 30 minutes ago, I went to make our scheduled changes in production and realized a deadly mistake - TDE is not compatible with Standard. I missed this because we utilize Developer for all our non prod environments, which as you probably know unlocks everything. Very silly oversight on my part!
However now the plan is to use EBS level encryption.
We are on AWS, and the MSSQL instance in question is housed on an EC2 instance.
Right now I have the following plan:
1. Create encrypted log, data, and backup drives of otherwise identical specification as original volumes.
2. Schedule downtime, run alter database set offline, alter database modify file, alter database set online for each database to move underlying files to encrypted log and data volumes.
3. Configure full and log backups to encrypted backup drive.
However this only takes care of volumes on which the DB actually resides.
Does anyone know, for GDPR and other data regulations, if it is necessary to also encrypt the root volume, even if we do not house data in it? I know it can be an issue if it makes it easier for one to acquire the encrypted data that is housed on the encrypted volumes, but I'm not entirely sure about this. I'm having one of my guys check with our security folks on the matter, but just want to see if anyone here has any similar experiences.
August 19, 2018 at 6:44 am
eshults5 - Sunday, August 19, 2018 6:38 AMSo long story short, I have to encrypt all our databases in my system to satisfy GDPR requirements.I had a plan for one particular host of MSSQL databases - to simply utilize TDE. I easily made the change in our non production. Then, just 30 minutes ago, I went to make our scheduled changes in production and realized a deadly mistake - TDE is not compatible with Standard. I missed this because we utilize Developer for all our non prod environments, which as you probably know unlocks everything. Very silly oversight on my part!
However now the plan is to use EBS level encryption.
We are on AWS, and the MSSQL instance in question is housed on an EC2 instance.
Right now I have the following plan:
1. Create encrypted log, data, and backup drives of otherwise identical specification as original volumes.
2. Schedule downtime, run alter database set offline, alter database modify file, alter database set online for each database to move underlying files to encrypted log and data volumes.
3. Configure full and log backups to encrypted backup drive.However this only takes care of volumes on which the DB actually resides.
Does anyone know, for GDPR and other data regulations, if it is necessary to also encrypt the root volume, even if we do not house data in it? I know it can be an issue if it makes it easier for one to acquire the encrypted data that is housed on the encrypted volumes, but I'm not entirely sure about this. I'm having one of my guys check with our security folks on the matter, but just want to see if anyone here has any similar experiences.
The GDPR is not about encryption, although the application of encryption can mitigate some of the requirements for compliance. My thought is that you'll have to have a proper classification of the data and the data processes to determine what kind of changes are needed, i.e. encryption does not fulfill the requirements of the "right to be forgotten".
😎
August 19, 2018 at 6:48 am
Eirikur Eiriksson - Sunday, August 19, 2018 6:44 AMeshults5 - Sunday, August 19, 2018 6:38 AMSo long story short, I have to encrypt all our databases in my system to satisfy GDPR requirements.I had a plan for one particular host of MSSQL databases - to simply utilize TDE. I easily made the change in our non production. Then, just 30 minutes ago, I went to make our scheduled changes in production and realized a deadly mistake - TDE is not compatible with Standard. I missed this because we utilize Developer for all our non prod environments, which as you probably know unlocks everything. Very silly oversight on my part!
However now the plan is to use EBS level encryption.
We are on AWS, and the MSSQL instance in question is housed on an EC2 instance.
Right now I have the following plan:
1. Create encrypted log, data, and backup drives of otherwise identical specification as original volumes.
2. Schedule downtime, run alter database set offline, alter database modify file, alter database set online for each database to move underlying files to encrypted log and data volumes.
3. Configure full and log backups to encrypted backup drive.However this only takes care of volumes on which the DB actually resides.
Does anyone know, for GDPR and other data regulations, if it is necessary to also encrypt the root volume, even if we do not house data in it? I know it can be an issue if it makes it easier for one to acquire the encrypted data that is housed on the encrypted volumes, but I'm not entirely sure about this. I'm having one of my guys check with our security folks on the matter, but just want to see if anyone here has any similar experiences.
The GDPR is not about encryption, although the application of encryption can mitigate some of the requirements for compliance. My thought is that you'll have to have a proper classification of the data and the data processes to determine what kind of changes are needed, i.e. encryption does not fulfill the requirements of the "right to be forgotten".
😎
Yes, I realize this 100%. This is one of those instances where the developers aren't interested in making that kind of effort and we just want to be compliant. According to our corporate guys, who I assumed met with various consultants to get to this answer, all we need is encryption at rest to be compliant. It seems that validation was already done, and they have decided that we simply have to implement encryption-at-rest to remain compliant going forward.
In lieu of that, I don't think it would be necessary to encrypt root volume to satisfy the "encryption at rest" requirement, right?
August 19, 2018 at 7:03 am
It looks like we actually do have a squad directly dedicated to making sure things are GDPR requirement, so I will likely ask them tomorrow morning. Also looks like we do regular deletion of old data on these particular databases so I assume the "right to be forgotten" has been reviewed and already validated in this environment.
Still feel free to share any experiences that may be helpful! Thanks
August 19, 2018 at 7:17 am
Actually since TDE was already OK'd, and since that doesn't touch root volume, I don't see any reason that root volume encryption would be OK using the AWS EBS encryption approach. So now I'm 98% certain this will be fine.
August 19, 2018 at 7:25 am
You may want to test the performance of doing so, I'd be surprised if storing transaction logs on an encrypted volume didn't impact performance considerably more than just doing in-database encryption of the specific PII data.
August 19, 2018 at 7:35 am
eshults5 - Sunday, August 19, 2018 6:48 AMYes, I realize this 100%. This is one of those instances where the developers aren't interested in making that kind of effort and we just want to be compliant. According to our corporate guys, who I assumed met with various consultants to get to this answer, all we need is encryption at rest to be compliant.In lieu of that, I don't think it would be necessary to encrypt root volume to satisfy the "encryption at rest" requirement, right?
As I said, compliance is not necessarily achieved by encryption, if there is no risk of the encrypted data ever being used, then that might do. Encrypting or protecting the root volumes is part of the implied duo diligence but does not protect the data at rest if backups are not encrypted and reside somewhere else!
😎
My thought is NOT to try to mitigate regulatory and business requirements with any kind of technology unless that is agreed by all the stakeholders (and the legal team).
August 19, 2018 at 7:38 am
andycadley - Sunday, August 19, 2018 7:25 AMYou may want to test the performance of doing so, I'd be surprised if storing transaction logs on an encrypted volume didn't impact performance considerably more than just doing in-database encryption of the specific PII data.
Good call. These are tiny low volume DB's though. This is one of our shared DB servers for DB's of low activity and resource requirements. I don't anticipate any kind of performance issues but as usual, always good to test.
August 19, 2018 at 7:40 am
Eirikur Eiriksson - Sunday, August 19, 2018 7:35 AMeshults5 - Sunday, August 19, 2018 6:48 AMYes, I realize this 100%. This is one of those instances where the developers aren't interested in making that kind of effort and we just want to be compliant. According to our corporate guys, who I assumed met with various consultants to get to this answer, all we need is encryption at rest to be compliant.In lieu of that, I don't think it would be necessary to encrypt root volume to satisfy the "encryption at rest" requirement, right?
As I said, compliance is not necessarily achieved by encryption, if there is no risk of the encrypted data ever being used, then that might do. Encrypting or protecting the root volumes is part of the implied duo diligence but does not protect the data at rest if backups are not encrypted and reside somewhere else!
😎
My thought is NOT to try to mitigate regulatory and business requirements with any kind of technology unless that is agreed by all the stakeholders (and the legal team).
Yep that seems to be the valid go to, especially in this ultra-conglomerate of a million different teams and squads.
Sometimes I miss working for the small shops where such decisions largely fall in my plate, lol.
August 19, 2018 at 7:53 am
eshults5 - Sunday, August 19, 2018 7:40 AMEirikur Eiriksson - Sunday, August 19, 2018 7:35 AMeshults5 - Sunday, August 19, 2018 6:48 AMYes, I realize this 100%. This is one of those instances where the developers aren't interested in making that kind of effort and we just want to be compliant. According to our corporate guys, who I assumed met with various consultants to get to this answer, all we need is encryption at rest to be compliant.In lieu of that, I don't think it would be necessary to encrypt root volume to satisfy the "encryption at rest" requirement, right?
As I said, compliance is not necessarily achieved by encryption, if there is no risk of the encrypted data ever being used, then that might do. Encrypting or protecting the root volumes is part of the implied duo diligence but does not protect the data at rest if backups are not encrypted and reside somewhere else!
😎
My thought is NOT to try to mitigate regulatory and business requirements with any kind of technology unless that is agreed by all the stakeholders (and the legal team).Yep that seems to be the valid go to, especially in this ultra-conglomerate of a million different teams and squads.
Sometimes I miss working for the small shops where such decisions largely fall in my plate, lol.
Good luck on this one mate, and in this kind of situations, just get a written consent to cover you!
😎
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply