December 10, 2020 at 12:00 am
Comments posted to this topic are about the item Data Sovereignty Issues
December 10, 2020 at 1:55 pm
This is an especially important when you store personal information, as the laws of the local area apply to the data and the transmission of such data. Thus a country may have laws which protect its own citizens, but allow the government to access information or transmissions which originate in other countries.
December 10, 2020 at 3:39 pm
We are in the beginning stages of architecting this for our organization. It's not going to be an easy project. Some of the folks on the team think that we are going to be able to flip a switch and turn on <fill in technology> and it will work like magic.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
December 10, 2020 at 10:03 pm
Hi Steve, this is a major topic for most countries outside the USA. We have to be vigilant where our data is stored and to knowingly make decisions on a risk and sovereignty basis. I may be misinterpreting your comment "I'd think this is easier for database professionals, as we just duplicate stores in different places." - but its not ok to just duplicate the store. Lets say you have EU, AU, and USA customers for your business. The EU people must be stored within the EU to ensure the GDPR data protections, similarly the AU customers must be stored in Australia for their local privacy protections. Both must not be stored in the USA even though they're friendly allies politically because of the Patriot Act which opens all data on non USA citizens and specifically drops all privacy protections on that data. This is why you can't just duplicate the store, you must have separate stores with separate data in the geographic locations. You also have to ask the provider where the backups are and where they might keep any other performance or contingency copies. This is particularly important if you're dealing with government data when you may need to choose a store and location specific to those needs.
Paul
December 11, 2020 at 3:45 pm
Paul,
I wasn't implying data being duplicated, and that section was poorly worded. I was more implying the schema/setup is easy for us. Data needs to be only inside the geography where it is allowed.
December 13, 2020 at 7:41 pm
I've been hitting this very problem lately. There are two problems really. The first is in the vague understanding of what it means for data to "leave a given region". E.g., suppose I have a server in the EU for GDPR reasons and I query it from a US machine. Is the data I view still "stored" in the EU? Is it not transferred over the wire to the US when I view it? If yes and if it cannot be duplicated to the US, then it would mean it would be nearly impossible to manage a server in the EU from the US. If no to these two questions, then the very concept of data "stored" in any given region is itself a superfluous concept. Legislation that forces data must be "stored" in a given region doesn't afford people the level of security they think it might because of the nature of the internet.
The second problem is the CLOUD act which ended the US vs. MS case. The CLOUD act effectively runs directly counter to GDPR. Thus, companies that are putting their EU data in EU data centers are doing it mostly to appease EU administrators. However, when it comes down to it, that EU data on EU citizens managed by US companies can still be extracted by US law enforcement because where it is stored is less relevant than who has control over accessing it.
December 13, 2020 at 10:30 pm
Thanks for the clarification Steve, yes that makes sense.
Certainly challenging things to consider Thomas. The laws governing data within the state of Victoria within Australia where I work aren't that dissimilar to GDPR in intent. The considerations are storage and control of the data. To get around your issue I would suggest you'd need service end points geographically co-located with the data stored in the EU that serve EU customers. Perhaps the only data you bring into the US either via copy or query from services should be de-identified and/or summary data (e.g. sales figures). So many things for us to think about when we architect solutions these days and certainly becoming a stronger focus for the organisations we work for. I often work with our legal team on privacy issues and its very interesting and also very challenging. There really aren't any perfect answers and we can just do the best we can and make sure our businesses understand and accept the risks.
Paul
December 14, 2020 at 6:02 pm
Yep. With you there on the challenges. I also agree that everyone generally wants to do the right thing and it is frustrating when it's difficult to determine what the right thing is. Part of the source of the challenge is that the people making the laws generally do not understand the technology which the law is designed to regulate.
December 14, 2020 at 6:15 pm
Completely agree with that last statement. Lawmakers are woefully behind in understanding, and in making rational debate.
I think I generally go with guidance from my auditor or regulator, because they will have to sign off or approve decisions. The pedantic view I (or tech people) may have about where data is or what's important, is less relevant than complying.
BTW, the CLOUD act doesn't give US companies or the government here direct access to anything. It provides means for search warrants and other requests for data to go through some process in the originating country. That's one reason I am glad Microsoft fought against pulling data from their Irish DC to satisfy a US warrant without approval from an EU court.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply