We've just had a look at how to secure your connection in Part 1 so obviously everything is now all honkey dorey on that end.
Some of the other areas that you naturally have to look at is the environment/infrastructure/network and your data itself.
It's not much use to encrypt and secure the data that you're transferring if the actual data itself isn't protected.What i hear you say? my IT guys got that under control..firewalls up the wazzooo...everything's patched and service packed!Of course that's not really enough and we know this - we just sometimes choose to leave that in the hands of those other people - network engineers.
If we look at SQL Server 2008 then there's a lot of new capabilities available to us for data security.
SQL Server 2008 Encryption Capabilities
in-built cryptography hierachy for the creation of assymetric, symmetric keys as well as certificates
Transparent Data Encryption (using database encryption keys - DEK)
Signing of code modules (using keys or certificates)
Creating certificates It's not that complex to create certificates (btw, all SQL Server certificates comply with the IETF X.509v3 certificate standards) on SQL Server 2008. it's as simple as using T-SQL.Self-signed certificate
CREATE CERTIFICATE name ENCRYPTION BY PASSWORD = 'strong password goes here' WITH SUBJECT = 'subject goes here' EXPIRY_DATE = 'expiry date goes here'
Certificate from a signed executable file
CREATE CE ...