Somewhere in the blizzard of EMC-related news this week, the pieces of an interesting story started to come together, e.g. some new thinking and capabilities around storage encryption.
The story came out kind of piecemeal (see here and here), and I thought it'd be useful to re-assemble some of the pieces.
Many of you are doing some form of storage or tape encryption today, or are thinking about doing it.
I think there's now a better way to do this sort of thing than there was before.
A Bit Of Background
Storage encryption is sometimes referred to as "data at rest" encryption.
The idea is two-fold: (1) prevent harm if storage media falls into the wrong hands (e.g. tape cartridge lost, disk drive misplaced, etc.) and (2) create a barrier that prevents unauthorized hosts from accessing sensitive information stored on the array.
I think of this technology as something that ought to be used selectively. There's no way to get around the added cost and complexity of introducing industrial-strength crypto and key management to your environment.
That being said, we're seeing more and more customers encrypting more and more of their information, leading to the desire for unified approaches that give different options, scale effectively, provide single points of control, and so on.
And there's no "right place" to do encryption. I can make viable cases (depending on use case) to do it in the application, at the server/LUN level, in the network, on the device itself, etc. etc.
Enter RSA Key Manager
Any extended discussion around encryption will lead to the realization that key management becomes a very important topic before long.
RKM started life with an application focus -- if you'd used RSA encryption technology at the point of information capture, RSA offered a nice software key manager.
When EMC acquired RSA, two things emerged very quickly: one, key management was going to be important at an information infrastructure level, and, two, key management looked very, very different in the storage domain.
If you think about storage-related key management, a couple of things jump out. First, there are copies of information everywhere: snaps, replicas, tape images and so on. Key management concepts have to extend (and be integrated with) common storage use cases.
Second, scalability and availability of key management becomes more important when implemented across a fundamental technology as storage. Put differently, you're going to have a really bad IT day if your key manager isn't working as expected.
Finally, the ideal key manager should be open enough and integrated enough with other vendors' products so that IT can make a single choice for everything, and stay with it.
I'd offer that -- as far as I can tell -- RKM now does this very well, and probably does it significantly better than other key managers in the marketplace.
First, it has all the required functionality. Using a configurable, policy-based interface, it can generate and distribute keys, securely distribute them, vault them securely, expire and turnover keys, as well as monitor and audit the entire process.
Second, it comes on a pre-configured hardware appliance that scales nicely, does HA, and can be optionally configured to support remote failover.
Nothing like a Bad Key Management Day to give you a really Bad IT Day.
But, most importantly, there's a nice suite of pre-integrated capabilities -- out of the box, so to speak -- that makes it immediately useful.
Finally, there's the all-important service component: trained people who can assess your situation, recommend a practical approach, help manage the implementation, and make sure you've got the processes set up so that things work smoothly.
So, What's Integrated?
Some familiar stuff, and a few new interesting options.
First, there's the file system option. In addition to a file-server resident adapter (naturally), there's a separate piece of functionality (the file security adapter manager) that allows for role separation between the person who manages all of the keys, and the person who hands out specific keys for specific files.
Second, there's a nifty Oracle option. Oracle has built some preliminary interfaces for external key management (allowing, for example, the encryption of a column or an entire table), and RKM can now use these interfaces. The primary benefit (other than scalable and consistent key management across multiple domains) is, once again, the separation of roles between the Oracle DBA and a centralized security authority.
Third, there's an nice integration with tape libraries that support encryption. RKM supplies keys and key IDs during the backup process (working with existing backup applications and backup devices) and does the same during the restoration process, which might be on an entirely different setup of tape drives, backup applications, etc. If you see yourself becoming a heavy user of tape encryption, you'll want to consider this sort of setup.
Fourth, Cisco (through EMC's Connectrix) is now offering SME (storage media encryption) as a dedicated blade in the MDS products. The initial use case is tape encryption without having to buy special tape drives. Although Cisco offers some basic key management features as part of the product, they (and EMC) recommend for anything substantial, consider something like RKM.
And, finally, my favorite -- PowerPath Encryption with RSA. If you're not familiar with PowerPath, it's EMC ubiquitous MPIO path manager. There's something like 600,000 copies out there in production. Not only is it supported on a wide range of servers and operating systems, it also supports non-EMC storage, like HDS, IBM et. al.
This allows IT users to selectively encrypt LUNs on a server, if they've got a few extra CPU cycles to spare, something like 5-15%. Most of the time, this enhancement can be installed non-disruptively, a nice benefit. A small software component (and no extra hardware) is all that's required.
Not announced in the general materials, but being worked on, are key management integrations with other products out there. More about this as it nears availability.
So, What Does This Mean?
For me, it's an interesting picture.
We can now think in terms of different options of where it's ideal to encrypt. I've said this before, but I'll say it again: think of encryption as a feature, not a product. It's something we'll see all over the IT landscape.
The focus now moves to key management and integration. How can we implement a reliable, scalable key management capability that integrates with the products and processes we use today? Ideally, key management (and the processes and roles around it) should be just about as transparent as possible.
And, as we discover information in our environment that ought to be encrypted (watch for forthcoming DLP discussion), we now have a "safe" place to store it, audit it, and so on.
About a year ago, I was talking to customers who were under pressure to start encrypting some of their storage. They weren't happy with the idea of dedicated encryption appliances (e.g. Decru, NeoScale), nor were they happy about the idea of new tape hardware all around, and -- most importantly -- they weren't happy about the state of affairs with enterprise key management.
Hopefully, we've got some better answers now ...
Comments