Security Encryption at Rest

Encryption at rest
as I mentioned it’s a ScyllaDB Enterprise only feature, it’s important
to understand what encryption at rest protect you from because at least in my
mind it’s less critical than encryption at transit, encryption at rest protect
you from someone breaking into your data center take your hard drive or take
your computer run away with it to his lab open it, I don’t know try to enable
it and try to read the information from there, so this is the main thing that
encryption at rest protect you from it’s a valid concern but if you for
example run it in AWS you are pretty much protected against that, ok you are
it still protect you from malicious AWS user or something like
that but I think it’s less of a concern, please note and this is
something that confuses many people and not just for ScyllaDB for
encryption at rest in general it doesn’t protect you from someone login or SSH
into your machine and read the data from disk it does give an extra layer of
protection but it doesn’t give you a full protection because if someone is
already in your machine you can read the keys to the encryption from memory or
from disk or whatever the keys are saved and potentially read the data from
there and decrypt the data using this key, I’m not saying it’s easy especially
if the key as we’ll see later is on different machine but it
still needs to be in the memory of the. ScyllaDB server, otherwise ScyllaDB will not
be able to read information so it doesn’t give you full protection against
that, so we support using openSSL, we support all kind of algorithm how to
encrypt the data and when you create a table as
see in a minute, you can choose which algorithm what’s the key length and such
like you have another systems, you have two types of information you want to encrypt
on the disk, on storage. One is easy, is the user information in the
SSTable, for those of you not familiar with a SSTable, that’s basically the
way that ScyllaDB store the persistent information on disk, it’s starting from Memtable
then flush to SSTable most of your data at any time is
probably in SSTable and this is what you encrypt with as SSTable encryption
there is also information which might be sensitive user information in other file
on the disk and it can be on the commitLog, hinted handoff files and batchlog
all of those are basically temporary cues which hold user information and
usually not as much it can have a lot of information or some information but not
as much as the SSTable and each of this component has slightly different
definition of encryption so for the first, for SSTable I will skip that in
essence of time, this is how you encrypt. SSTable you’re just doing a create, when
you create a table as part of the schema you specify what algorithm you want to
use, what key want to use and the key providers, the key provider I have a
slide just on that so I’m not going to spend time on it now and once I do that
every new SSTable written to disk will be encrypted, now this is an
important thing you need to understand once I do that and or if I alter
the table to use an encryption only new table, new SSTable will be encrypted
okay and why is it important, it’s important especially if I’m doing an
ALTER TABLE, for example either changing the key or enable/disable encryption
existing SSTable will not be rewritten or encrypted with the new key just new
SSTable, new SSTable can come from two sources, one of them is Memtable
flush to SSTable, what is the second?
compaction right, so these are the two cases when we write new SSTable and
each of this new SSTables will b encrypted with the new key or you
can actually disable encryption as well with the same command, with ALTER TABLE
so if you want to encrypt all of your information with the new key you need to
use a nodetool facility called nodetool upgradesstable that will basically
read all the SSTables from disk and write them again with the new parameters
by the way this is a general command, you can also use it to change all the
compaction strategy on all tables or something like that but for
encryption it would write the information with a new encryption key
another side effect of that if you are changing the key and you should
change the key from time to time you cannot naively throw away the old
key you need to keep it available because some of the SSTable might be
with the old key, (what about the materialized views?) the same thing materialized view internally, materialized views are
just table in ScyllaDB, it is nothing different, they have their own SSTable
it’s exactly the same okay I’m speeding things up here a little
bit because I’m a little bit late here. An encryption of system level
information which is a hinted handoff and commitlog and such, it’s not
something it you can specify through the schema, it is something you can specify
through the scylla.yaml, so you write down in the scylla.yaml
that you want to encrypt this part as well and ScyllaDB will do it for you
and now the provider, the provider is an interesting thing or so the provider
is where do ScyllaDB get the keys from or put it in another direction where
do ScyllaDB keeps the keys of the encryption so the first version of ScyllaDB Enterprise
with encryption at rest at 2019.1.1 only have the local provider
local provider means that the keys are store on disk, can be on different disks
or the same disk but there are stored on disks, so someone login to
machine very easy for him to read the key and just use it, other in the
upcoming version of ScyllaDB Enterprise 2019.1.3
will provide two more providers, so one of them is a KMIP
a protocol, commit protocol is a standard protocol to exchange keys so if you have
a KMIP compatible server on your organization you can keep the keys there
and ScyllaDB will read the keys from there over KMIP for example a Hershey Corp
just added KMIP compatibility to the vault and there are other product
out there that support KMIP, AWS key management does not support KMIP yet
unfortunately I hope they will add it but if not we will probably going to add
protocol to this key management at some point