If you are old enough, you might remember that commercial that played late at night and went something like this... “It’s 10 p.m., do you know where your children are?” This was a super-short commercial that ran on late night TV in the 1980s; it always kind of creeped me out a bit. So the title of this post is slightly different, changing the time to 2 a.m., because accessing your data is much more than just a 10 p.m. or earlier affair these days. We want access to our data 24/7/365! The premise of that commercial was all about the safety of children after “curfew” hours. If you knew your children were asleep in their beds at 10 p.m., then you were good. If not, you had better start beating the bushes and find out where they are. Back then you couldn’t just send a text saying “Get home now!!!” with an angry emoji . Things are different now, we’re storing entire data centers in the cloud, so I think it’s time to look back into this creepy commercial from late night 80s TV and apply it to our data in the cloud. “It’s 2 a.m., do you know where your data is?”
Here are some ways we can help ensure the safety of our data and know where it is, even at 2 a.m.
Understanding the Cloud Hosting Agreement
Much like anything else, read the fine print! How often do we read it? I’m guilty of rarely reading it unless I’m buying a house or something to do with a legal matter. But for a Cloud Hosting Agreement, you need to read the fine print and understand what it is you are gaining or losing by choosing them for your data. I’m going to use Amazon Web Services (AWS) as an example (this is by no means an endorsement for Amazon). Amazon has done a really good job of publishing the fine print in a way that’s actually easy to read and won’t turn you blind. Here’s an excerpt from their data privacy page on their website:
Ownership and Control of customer content:
Access: As a customer, you manage access to your content and user access to AWS services and resources. We provide an advanced set of access, encryption, and logging features to help you do this effectively (such as AWS CloudTrail). We do not access or use your content for any purpose without your consent. We never use your content or derive information from it for marketing or advertising.
Storage: You choose the AWS Region(s) in which your content is stored. We do not move or replicate your content outside of your chosen AWS Region(s) without your consent.
Security: You choose how your content is secured. We offer you strong encryption for your content in transit and at rest, and we provide you with the option to manage your own encryption keys.
Choose Where Your Data Lives
Cloud storage companies don’t put all their eggs, or more accurately, all your eggs, in one basket. Amazon, Microsoft, and Google have data centers all over the world. Most of them allow you to choose what region you wish to store your data in. Here’s an example with Microsoft Azure; in the U.S. alone, Microsoft has 8 data centers from coast to coast where you data is stored at rest. The locations are Quincy, WA; Santa Clara, CA; Cheyenne, WY; San Antonio, TX; Des Moines, IA; Chicago, IL; Blue Ridge, VA; and Boydton, VA. AWS offers their customers the choice of which region they wish to store their data, with the assurance that they “won’t move or replicate your content outside of your chosen AWS Region(s) without your consent (https://aws.amazon.com/compliance/data-privacy-faq/).” With both of these options, it’s easy to know where your data lives at rest.
Figure 1 Microsoft Azure Data Centers in the US
Monitor, Monitor, Monitor
It all comes back to systems monitoring. There are so many cloud monitoring tools out there. Find the right one for your situation and manipulate it to monitor your systems the way you want them to be monitored. Create custom dashboards, run health checks, manage backups, make sure it’s all working how you want it to work. If there is a feature you wish was included in your systems monitoring tool, ping the provider and let them know. For most good companies, feedback is valued and feature requests are honestly looked at for future implementation.