Now
a day’s most of the applications are moving to the cloud and more positive
towards cloud, at the same time they are also concerned about security. In short security is protecting the
data from unauthorized uses, uses https, TCP Etc protocols even it may not
helps sometime, looks for more and next question is how? Here the concept of
Encryption becomes prominent.
Encryption
is another way to enhance the security of a message or file by scrambling the contents
so that it can be read only by someone who has the right encryption key to
unscramble it.
For example, given a single application collecting an account number from each customer, you could encrypt it in any of several different places: the application, the database, or storage — or use tokenization instead. The data is encrypted (or substituted), but each place you might encrypt raises different concerns. What threats are you protecting against? What is the performance overhead? How are keys managed? Does it all meet compliance requirements? And today we see encryption growing at an accelerating rate in data centers.
Today
we help you pick the best encryption options for your projects. Our focus is on
encrypting in the data center: applications, servers, databases, and storage.
We will also cover tokenization and discuss its relationship with encryption.
Understanding Encryption
Systems
Let’s
begin with the basics which are still important to put into practice.
Three
major components involves in the building the structure of an encryption
system.
Data:
The object or objects to encrypt. It might seem silly to break this out, but
the security and complexity of the system depend on the nature of the payload,
as well as where it is located or collected.
Encryption
Engine: This component handles actual encryption (and decryption) operations.
Key
Manager: This handles keys and passes them to the encryption engine. In a basic
encryption system all three components are likely located on the same system.
As an example take personal full disk encryption (the built-in tools you might
use on your home Windows PC or Mac): the encryption key, data, and engine are
all stored and used on the same hardware. Lose that hardware and you lose the
key and data — and the engine, but that isn’t generally a concern for FDE.
(Neither is the key, usually, because it is protected with another key, or
passphrase, that is not stored on the system — but if the system is lost while
running, with the key in memory, that becomes a problem). For data centers
these components are likely to reside on different systems, increasing
complexity and security concerns over how they work together.
Building
an Encryption System
In
general we split the application into components like encryption engine in an
application server, the data in a database, and key management in an external service
or appliance.
-
Application,
which collets the data
-
Database
holds the data.
-
Files
where stores the data.
-
Storage
volume where files reside.
Encrypt
the data at application level and the data is protected all the way down and it
adds complexity to the system and always not possible.
Here
is an example. Let’s say someone tells you to “encrypt all the account number”
in a particular application. We will further say the reason is to prevent loss
of data in case a database administrator account is compromised.
The
data isn’t necessarily moving, but we want separation of duties to protect the
database even if someone steals administrator credentials. Encrypting at the
storage volume layer wouldn’t help, because a compromised administrative account
still has access within the database. Encrypting the database files alone
wouldn’t help either, because for the database to work authorized users work
inside the database where the files are no longer encrypted.
Encrypting
within the database is an option, depending on where the keys are stored (they
must be outside the database) and some other details which we will get to
later. Encrypting in the application definitely helps because that is completely
outside the database. But in either case you still need to know when and where
an administrator could potentially access decrypted data.
In summary, all ties together. Know why we are
encrypting and where can encrypt, how to position the components to achieve the
security.
That
covers the basics of encryption systems. Next section goes in the layers of
data encryption.
Encryption
Layers
You
can picture enterprise applications as a layer cake: applications sit on
databases, databases on files, and files are mapped onto storage volumes. You
can use encryption at each layer in your application stack: within the
application, in the database, on files, or on storage volumes. Where you use an
encryption engine dominates security and performance.
Higher
up the stack can offer stronger security, with higher complexity and
performance cost.
There
is a similar tradeoff with encryption engine and key manager deployments: more
tightly coupled systems offer less complexity, but also weaker security and
reliability. Building an encryption system requires a balance between security,
complexity, and performance. Let’s take a closer look at each layer and the
various tradeoffs.
Application Encryption
One
of the more secure ways to encrypt application data is to collect it in the application,
send it to an encryption server or appliance (or an encryption library embedded
in the application), and then store the encrypted data in a separate database.
The application has full control over who sees what so it can secure data
without depending on the security of the underlying database, file system, or
storage volumes. The keys themselves might be on the encryption server or could
be stored in yet another system. The separate key store increases security,
simplifies management of multiple encryption appliances, and helps keep keys
safe for data movement: backup, restore, and migration/synchronization to other
data centers.
Database Encryption
Relational
database management systems (RDBMS) typically offer two encryption options:
transparent and column. In the layer cake above columnar encryption occurs as
applications insert data into the database, whereas transparent encryption
occurs as the database writes data out. Transparent encryption is applied
automatically to data before it is stored at the file or disk layer. In this
model encryption and key management happen behind the scenes, without the user’s
knowledge, and without requiring application programming. The database
management system handles encryption and decryption operations as data is read
(or written), ensuring all data is secured, and offering very good performance.
When you need finer control over data access you can encrypt single columns, or
tables, within the database. This approach offers the advantage that only
authenticated users of encrypted data are able to gain access, but it requires
changing database or application code to manage encryption operations. With
either approach there is less burden on application developers to build a
crypto system, but slightly less control over who can access sensitive data. Some
third-party tools also offer transparent database encryption by automatically
encrypting data as it is stored in files.
These
tools aren’t part of the database management system itself, so they can work
with databases that don’t support TDE directly; they provide greater separation
of duties for database administrators, as well as better protection for file based
output like reports and logs.
File Encryption
Some
applications, such as payment systems and web applications do not use
databases; instead they store sensitive data in files. Encryption can be
applied transparently as the data is written to files. This type of encryption
is either offered as a third-party add-on to the file system, or embedded
within the operating system. Encryption and decryption are transparent to both
users and applications. Data is decrypted when a user requests a file, after
they have authenticated to the system. If the user does not have permission to
read the file, or has not provided proper credentials, they only get back
useless encrypted data. File encryption is commonly used to protect “data at
rest” in applications that do not include encryption capabilities — including
legacy enterprise applications and many big data platforms.
Disk/Volume Encryption
Many
off-the-shelf disk drives and Storage Area Network (SAN) arrays include
automatic data encryption. Encryption is applied as data is written to disk,
and decrypted for authenticated users/applications when requested. Most enterprise
class systems hold encryption keys locally to support encryption operations,
but rely on external key management services to manage keys and provide
advanced key services such as key rotation. Volume encryption protects data in case
drives are physically stolen. Authenticated users and applications have access
to unencrypted data.
Tradeoffs
In
general, the further “up the stack” you deploy encryption, the more secure your
data is. The price of that extra security is more difficult integration, usually
in the form of application code changes. Ideally we would encrypt all data at
the application layer and fully leverage user authentication, authorization,
and business context to determine who can see sensitive data. In the real
world, the code changes required for this level of precise control often pose
insurmountable engineering challenges or are cost prohibitive. Surprisingly,
transparent encryption often perform faster than application layer encryption,
even with larger data sets. The tradeoff is moving high enough “up the stack”
to address relevant threats while minimizing the pain of integration and
management. Later in this series we will walk you through the selection process
in detail.
Till
now we understood about the components involved in encryption. It’s not
sufficient to build a secure application.
Stay tuned to know one of the important factors in security which is
nothing but Key Management Options and then on how to implement it on cloud.
No comments:
Post a Comment