AlwaysEncrypted in SQL 2016

This isn't my usual stomping grounds - I'm your typical developer: security isn't a focus, and if I'm the one doing it, I wouldn't trust it either.  Get a real security professional involved if you're serious about doing encryption right!  In fact, I'm trying to do the same - if you happen to know a developer that breathes security, I'd love to talk to them to develop a presentation that doesn't just fake security, it's the real deal.
But until that happens, I can only describe what looks to be an excellent new feature in SQL 2016 - AlwaysEncrypted.  What makes it excellent?

• Encryption (that appears to be) done right
• Very easy to set up
• Does what it says on the tin
• Minimal, yet very understandable impacts on functionality

Starting At The Beginning - Why Encrypt?

It's a question of trust - always has been and always will be.  Whom do you trust with the information your business collects?  Today, the answer for most businesses will be "way too many people."  It's not that employees are inherently untrustworthy - if they were, your business probably wouldn't have hired them.  The reason you'd get this answer is a relatively straightforward one: "Do you really need to see X to do your job (well)?" - and the answer to that one is usually "no."
A standard example of this is HR information.  HR systems (front-end UIs) are typically locked down to only HR departments - that's pretty straightforward and accepted.  But does a DBA or a network admin need full access to these systems?  Almost surely not, except that it's easier to configure access broadly that includes the permissions they need, rather than tailoring access to just what's required.  AlwaysEncrypted makes it a little easier to help tailor that access - or more accurately, adding security at a different layer that means granting complete system access doesn't expose anything.

How Easy Is It?

For a database guy?  Pretty darn easy - and we're not always the sharpest tools in the drawer.  Of course, being a duller implement may make my claims of setting up AlwaysEncrypted "being easy" be completely undermined by my limited understanding of proper security.  I may be providing a false sense that it's actually effective, when it might not be.  (Again, if you happen to know a developer who focuses on security, I'd love to talk to them.)
It only takes a couple steps to set up - there's a nice Channel 9 video here - but there are some key points to be very aware of:

• Don't perform the configuration of AlwaysEncrypted columns on an "untrusted" machine.  Sensitive encryption keys are generated during setup, and it's best to have those keys never touch a system that is - or will be - part of the "untrusted" group.  Like your DB server itself.
• You can't fully test your system's effectiveness only from SQL Server Management Studio.  You WILL need the help of a developer - either an SSIS, SSRS, or code monkey.

What Does The Tin Say?

AlwaysEncrypted.

Duh.  So Does It Do What's On The Tin?

Sure seems to - and all the descriptions of how it works reinforce that belief.  The bottom line is that once you've configured AlwaysEncrypted on a column in a table, the data is only ever seen in plaintext form at the application client.  It's encrypted by the SQL client libraries on the client (be that a line of business application, SSIS, or SSRS), and stays encrypted (as cyphertext) everywhere else:

• In any non-client process space on the client machine (caches, etc)
• In the client OS as it prepares to send queries over the wire
• Over the wire (internal network or internet)
• On the server OS as it receives the query and routes it to SQL
• Inside SQL memory (the query optimizer, in-memory data pages)
• On disk (SQL MDF and LDF files)

It simply boils down to only the client having the key.  If only the client has the key, and the encryption is industry-standard "really, really difficult to brute force in the forseeable future" 256-bit process, there's no wiggle room.  Nobody else can see the plaintext.

What Can't I Do With An AlwaysEncrypted Column?

There's a full list of constraints halfway down this page - but in general, it falls into two categories:

1. Less-used data types and scenarios that Microsoft will in all likelihood address in "v2" - such as image data types.
2. Operations that require access to plaintext to perform properly - such as check constraints.

So yeah - complain about #1 while still being understanding.  But think about what you're asking for and/or complaining about first to make sure it doesn't fall into category #2.

AlwaysEncrypted - Start Using It

The reasons should be overwhelming:

• You're dealing with known-sensitive data
• Rolling your own encryption is HARD to get right - harder than getting your SAN set up right or getting execs to walk the talk that data quality isn't a technical problem
• Transparent Data Encryption (TDE) only protects on-disk data
• Wouldn't you feel better as a DBA/DBDev being protected from even the hint of responsibility for protecting this data?