One of the biggest barriers for enterprises to migrate to the cloud has been the lack of a comprehensive and reliable security solution. Even early on, experts raised serious questions on the security of data in the cloud, and there is a great reason to back up this apprehension. To move data to the cloud, enterprises faced a new dimension in their security challenge—to ensure that no PII, PCI, HIPAA, or data complying with a similar policy could leave their on-premises environment.
In this free ebook, our data experts share tips on:
- What’s different about security in the cloud
- Understanding the shared security responsibility model
- How to selectively migrate data to the cloud
Storage Got Cheap Before It Got Secure
The technologies that made large-scale data storage affordable were built to solve cost, scale, reliability and availability. Security was not the design goal, and the result was a generation of platforms with excellent economics and meager protection.
The security industry spent years catching up with the Hadoop ecosystem, and by the time it had, attention had already moved to the cloud, which offered more compute and cheaper storage again.
Why Security in the Cloud Is a Different Question
Before the cloud, enterprise data sat in data centers the enterprise owned. Collecting sensitive data was accepted on the understanding that it stayed inside an environment the organization could protect and could demonstrate compliance for, whether that meant personal data, card data or health information.
Resources therefore went into the perimeter and into access control. Moving data to the cloud inverts that, because the data leaves the environment those controls defend.
The Shared Responsibility Model, Stated Plainly
Cloud providers have invested heavily in securing their infrastructure and take responsibility for it. They do not take responsibility for the customer data inside it. Ownership of that data never transfers.
The division is usually summarized as the provider securing the cloud and the customer securing what is in the cloud. The practical consequence is that a migration moves the data without moving the obligation attached to it.
Secure Before You Migrate, Not After
The sequence matters more than it appears to. Sensitive data protected before it leaves the on-premises environment arrives protected, and no window exists in which an unprotected copy sits in a location the organization has not yet configured.
Protecting after arrival means the first state of that data in the cloud was its unprotected one, and that state is what any subsequent audit will ask about.
Migrate Selectively
Not all data needs to move, and not all of it should. Discovery before a migration establishes which records are regulated, which are genuinely required by the workload being moved, and which are simply being carried along because they happened to be in the same location.
Deciding that per data type rather than per system is what keeps a migration from expanding the compliance footprint, and it usually reduces the volume being moved at the same time.
What Protection Looks Like Once the Data Has Moved
Encryption suits data that authorized systems must read in full. Masking suits copies used for development, testing and analysis, where the shape of the data matters and the identities behind it do not. Redaction suits records that have to be shared in part, with the sensitive elements removed rather than hidden.
Choosing per data type rather than applying one method everywhere is what keeps protected data usable. A cloud analytics platform fed entirely encrypted input produces nothing, and a team that cannot work with the protected copy will eventually ask for an unprotected one.