As data flows between systems, applications and databases,
valuable information is pass along either internal, external or a combination
of both types of networks. The data can be intercepted by several different
tools including monitoring tools that companies use to verify that the applications
are working and network availability. There is a great deal of security focused
on the network and encrypting information being sent back and forth. Even with minimizing
risk and various network security in place, there are opportunities to sniff or
pull data in transit. It would seem like this security control would be a
default for a secure configuration. However, there are still questions and open
issues with database encryption and data encryption from to and from the
database.
This seems like a first place to start for database
security. Data in transit and data at rest can be encrypted with basic implementation
steps and become part of a standard database build. With several database
platforms these types of encryption are transparent to applications and data
users. The client configurations received the data encrypted because the server
has setup the proper configuration for encrypting the data in transit.
The question is still, why is this not a standard? It could be because of other focus areas for
the business or resource issues. It can
also be because this is something that is being handled after the databases
have been created, and because of concerns of how the applications might handle
the secured settings of the database servers if changed. However, since this
configuration is part of the server, even if not part of the initial install,
it can be part of the configurations and the standard build of the databases.
Database as a Service (DBaaS) can provide these types of configurations as a
baseline installation of the database server. Using a service like this or
having these configurations as part of the deployment of the database will
eliminate the question of encryption in transit.
Set up the DBaaS with the needed encryption configuration
will take care of the future standard, new builds, migrations, etc. But what
about existing servers? This will need to be planned to change the
configuration. Just as changes to parameters and patches are made, these server
side configurations can be made and tested in non-production. As much as I would
normally like to do one change at a time, there are a few things I would group
this change with especially because there are limited maintenance windows.
The database servers need to be configured to use SSL which
is on the server side for both Oracle and Microsoft SQL Server. This is a high
level view of what needs to be done for each database environment, which is
basically parameter changes and restarting of a service or listener.
For Oracle parameters are set in the sqlnet.ora file:
SQLNET.ENCRYPTION_SERVER = required
SQLNET.CRYPTO_CHECKSUM_SERVER = required
For SQL Server, the Server Configuration Manager will help
set the Protocols under the Network Configuration for the server. The
properties for should have Force Encryption set to Yes.
Should this still really be a question? Encryption of data should
just be a standard. Start by verifying that the data in transit is encrypted.
Data at rest encryption would be the next step, followed by other data access
controls and protection.