|
Time
is Right for Database Encryption
Dec
9, 2003
By Don
MacVittie
Are
data-privacy regulations and dreams about stolen
employee data keeping you up at night? It may be
time to protect your data where it lives--in your
database.
Database-encryption
technology isn't new. Ingrian Networks' DataSecure
Platform, which lets you encrypt certain fields
before you enter them in the database and
automatically decrypts them on the way out, has been
around for a couple of years. But until recently,
database encryption wasn't right for most
enterprises. With the Health Insurance Portability
and Accountability Act (HIPAA) now a reality,
though, the stakes are higher than ever when it
comes to compromised customer and employee data, and
many organizations are taking a second look at
encrypting their databases.
But
you can't encrypt everything in your database.
Indexed fields, for example, can't be encrypted
because your database-management software will sort
the encrypted strings in hexadecimal values, which
won't match the real, unencrypted form. So your
index, which is supposed to speed access to the data
by preordering it, won't work. Even if you could
relate the encrypted index field to the original
data, the collation order wouldn't match. Until
databases support encryption natively, encrypted
indices will be a problem.
| Remember
that any indices generated from encrypted
fields won't be valid, either. And because
these fields don't relate to the actual data,
it'll be harder for the database administrator
and developer to debug problems. As a matter
of fact, unless you have a mechanism to
decrypt your database data on the fly, any
query that uses encrypted fields to search or
order data will cause trouble.
Database
software, such as Sybase's, lets you create
encrypted databases. Access requires a key,
which also lets you decrypt on the fly. This
all-or-nothing encryption, with the entire
database encrypted or not, can cost you in
overhead. However, Sybase
offers helpful tips for getting around the
problem. And though the all-or-nothing
approach is beyond the scope of this article,
it may prove a viable option in high-security
situations, given recent improvements in
hard-drive speed and capacity.
Trading
Spaces
Disk space is
an issue with database encryption because
encrypted fields are larger than unencrypted
fields. They're a little larger for textual
data and a lot larger for numeric and binary
data--data in a numeric field, for example,
gets encrypted one byte at a time and grows to
two bytes when it's encrypted. RAID arrays,
SANs and network-attached storage devices give
you plenty of space, unless you have a massive
database of millions of rows, each row with
hundreds of bytes.
Most
database-encryption mechanisms present
encrypted data as characters, one character
per hexadecimal digit. That's a big increase:
When encrypted, a 4-byte integer becomes an
8-byte character string. Most encryption
algorithms use 64-bit DES, so your 4-byte
(32-bit) integer becomes a string of 16
encrypted characters. Bottom line: When
building your disk capacity for database
encryption, anticipate that your data will
triple or quadruple in size. In addition, make
sure you have sufficient logical-memory space.
Keep in mind,
too, that encryption increases your data
fields. To allow for this, increase the size
of the field so the column is larger, and
change the field type to accommodate the
encrypted data. Numeric fields, then, would be
changed to character fields large enough to
store encrypted data.
And don't
encrypt anything that doesn't need it. Encrypt
a credit-card number, but don't bother
encrypting your customer's first name.
If you run a
high-volume database system, encryption and
decryption may not bring it to its knees, but
it might hurt performance. Ask your database
vendor which encryption-acceleration tools
work with its product. Many
database-encryption vendors have relationships
with acceleration-tool suppliers. Oracle's
database, for instance, has a working
relationship with nCipher.
|
|
