Security: Protecting SQL Server Applications

I read a good book called "Securing SQL Server, protecting your database from attackers, second and third editions by Denny Cherry" which has a lot of good information describing how to secure SQL Server databases and the best practices in clear words.

You can find more about this book in the following link(I encourage everyone to read it):

In this post, I will write tips related to SQL Server security and most of these tips from the above book but please note any mistakes in these tips it will be my mistake in understanding or rephrasing the words.

(1) Security Requirement

  • Identify the columns that need to encrypt and what is the objective.
  • Protect any information which has the risk of disclosing information in case of exploiting like password and phone.
  • Identify application design problems before proceed to the next phase because it will be difficult in later phase especially after go live.
  • Security aspects begins at the beginning of the development process by identifying which data will be stored and how people will access these data.
  • Identify the risks and try to mitigate them in early phases.
  • Good Objective "All data should remain secure" but no Guidance in this phase.
  • Most of development teams focus on the core business requirement and forget the security requirements.
  • Create prototype to show the client how the core data will be presented and stored.
  • Risks to avoid:
    • Dynamic SQL & Injections
    • Buffer overflow , for example submit input larger than the defined data type in the table
    • Disclosing error messages
    • Weak Validation for entry points
    • Brute force against databases
  • Remember, your web site security risks could affect other web sites in the time of exploiting.
  • In some cases, lawyers need to be involved to understand the government or local policies laws and privacy requirements.

(2) Security Network

  • In most cases, the lockdown of Network would be under the Network teams but it's good to have knowledge understanding of other technologies.
  • Network firewall is your perimeter between internal network and internet or ISP
    • Can be device or software
    • Block traffic based on rules and ports
      • For example restrict all ports except for port 80 (HTTP) , port 433(HTTPs) and for specific IPs use port 3389 (Remote access)
    • Some router doesn't has firewall loaded into them but can filter requests based on Access control list
    • Some firewall has additional protections like DDoS protection
    •  Firewall can be configured to Grant (open ports) and Deny(close ports)
    • Internal servers can use private IPs to access public internet by using NAT
  • Network topology designs for applications can be
    • Web Server on the public internet and in this case it will assign public IP address to Web server
    • Web Server on the internal side of the network and in this case router route the traffic to internal IP addresses
    • Web Server in the Demilitarized Zone and in this case Web server will be in zone different and SQL Server in internal zone (Recommanded)
  • Be restricted and block any ports don't need it to avoid risks like accessing file shares or malware.
  • OS Firewall
    • Another defense so enable it with the right configuration
    • In windows 2003 and previous versions , all traffic was open
  • Phoning home when an application makes requests back to the owner of software for legitimate reasons like check for windows update (Stop automatic windows update and consider the planned patching option)
    • It's not necessary (block it in outbound settings)
    • Illegitimate software could use it to run commands in case of botnet or zombie attacks
  • Examples of inbound rules in Web server
    • TCP to SQL Service (You can configure it by port or program)
    • UDP to SQL Browser Service
    • SMB to Network file shares
    • ICMP to allow Ping request
  • Examples of outbound rules in SQL Server
    • DNS lookups to connect Active directory DNS server
    • Full access to Active directory or domain controller
    • WSUS to access patching servers
    • Network access to storage array for example in case of clustering
    • Network file share access
    • Or Access to other database servers
  • Keep the role of SQL Server clear and don't install any unnecessary services.
    • If the SQL Server also acting as Active directory then you need to open more ports in order to allow AD replication and other features (by doing this, you increase the risks) 
  • In Case of SQL Server cluster, mail and integration services don't use Cluster IP and they used the first IP address so consider to open traffic to outside resources for direct IPs.
  • Don't make SQL Server available on the public internet to easy access because it will be exposed to attacks.
  • SQL Server 2000, allow for blank password so consider to review the environment.
  • Upgrade the software and update solution design and consider to use at least two tier layers.
  • Use VPN (encrypted channel) to access your servers in secure way instead of place it in the public.
    • Or use leased line but it's costly for long distance
    • Windows Server include a VPN server called "Routing and Remote Access Services RRAS"
    • In case of DirectAcess role , computer should be member of AD not link VPN
  • Use HTTPs in the applications to prevent network monitoring.
  • Plan ahead when selecting private IPs range and consider the movement into IPv6.
  • vLANs to segment the network for easily management and security(isolate Subnet with using Firewall).
  • Secure servers physically in data center by only allow access to authorized person and use alarms and auditing.
    • This include accessing the servers via wire or wireless
  • Disabled unneeded ports and services.
  • Train your employees to lock their workstations and create group policy for locking computers.
  • Configure Group policy for automatic locking computers
    • Under user configuration >> Administrative Templates >> Control Panel >> Display
    • There are the settings
      • Screen server
      • Screen saver executable name
      • Password protect the screen saver
      • Screen saver timeout (In seconds)
      •  Hide Screen Saver Tab (to hide it from the user)
  • Train your employees how to protect themselves from social engineering.
  • Common ways to find out the running instances (I will show you how to hide them to mitigate the risks)
    • Use sqlcmd –L
    • Or by powershell [System.Data.Sql.SqlDataSourceEnumerator]::Instance.GetDataSources()
    • These list could be not accurate because
      • If there hidden instances
      • Firewall block access to instances
      • Instance is not listening to port 1433
      • Instance is a named instance and SQL Browser is not running
      • SQL server in different subnet
      • Person request the list doesn’t has access to SQL instance or OS
  • Test your network security, for example brute force the VPN or Test for SQL injection.
  • Pen testing on regular basis and it can be done by third party and this testing include the black, white or gray box testing.
  • In some countries like US, any company that takes credit cards data from customer (even if it’s not stored) needs to able to pass some sort of PCI (Payment Card Industry) audit (laws and regulations).
  • Antivirus on SQL Server
    • Required CPU and RAM but it adds defense for OS and Programs
    • Prevent it from scanning any files with the extension mdf, ndf, ldf, bak, and trn (or other extensions that you use for database files)
    • Prevent it from scanning these directories:
      • “:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\ MSSQL\Binn” directory
      • Any folders with FILESTREAM data
      • Any network shares exposed as FILETABLE data
      • Folders with backup files
      • Folders with extended stored procedures

(3) Key Management

  • Service Master key (a Symmetric key)
    • The top of keys hierarchy which is protected by Windows Database Protection API(DPAPI)
    • It's the key that's used to encrypt all other keys below
    • It Created by SQL Server during installation process and you can only alter it (per instance has their key)
    • Keys at the top can open keys at lower
    • Read the below graph from bottom to top
    • We can secure the data either by using “Symmetric Key” or “Password” as the above graph
    • “Symmetric Key” can be secured via “Certificate”,“ Asymmetric Key”, “Enterprise Key Manager”, Another “Symmetric Key”, or “Password”
    • If we store “Symmetric Key” using another “Symmetric Key” that “Symmetric Key” can be secured any of the ways that any other “Symmetric Key” can be secured
    • If “Symmetric Key” is secured by “Asymmetric Key” that “Asymmetric Key” can be secured via “Database Master Key”, “Password”, or “EKM”
    • If “Symmetric Key” is secured via “Certificate” that certificate can be secured via “Password” or the “Database Master Key”
    • “Database Master Key” can be secured via “Password” or “Service Master Key“
    • We can change “Service Master Key“ if compromised or SQL service account changed (from place other than Configuration Manager) because can’t read the old key
    • In some cases , SQL Server service can’t regenerate “Service Master Key” without losing access to data which has been encrypted (data can no longer be decrypted with "Service Master Key”) then we can use a FORCE keyword with ALTER SERVER MASTER KEY
      • If you have access to “Password” of “Database Master Key” then the data is still decryptable.
    • “Service Master Key” should be backed up using BACKUP SERVER MASTER KEY statement each time the Service Master Key is changed
      • Backup of “Service Master Key” is encrypted by a password
      • Should be stored offsite in a secure location because “Service Master Key” it gives an attacker access to all the encrypted data on the system
  • Database Master Key (a Symmetric key)
    • It is used to encrypt all the objects within the database such as “Symmetric Keys”, “Asymmetric Keys”, and “Certificates”… etc.
    • Can be created by using the CREATE MASTER KEY command
    • Per Database (or catalog) has one “Database Master key”
    • You can configure the “Database Master Key” to not be encrypted by the Service Master Key.
    • When “Database Master Key” is changed , all of the keys which it protects must be decrypted and re-encrypted using the new “Database Master Key”
    • “Database Master Keys” should be backed up when they are changed to ensure that the data can be recovered if the key is lost in the database.
      • Backup of “Database Master Keys” is encrypted by a password
      • Should be stored offsite in a secure location
    • “Symmetric Keys” , “Asymmetric Keys” and “Certificates” are additional keys to increase the granularity of the encrypted data within the database
    • These keys encrypted by “Database Master Key”
    • “A Symmetric Key” is a single key that is used to encrypt and decrypt data
    • “Asymmetric Keys” are the combination of a private key and a public key
    •  “Certificates” are private or public keys that are digitally associated with an individual or device. The use of a Certificate is very similar to Asymmetric Key
  • Enterprise password management
    • Manage it properly by securing the passwords and the backups for these keys
    • The most important step is to backup these keys when they are changed
    • The backups of these keys should then be stored offsite
    • Copies of the passwords for the various keys must be kept onsite (for easy access) as well as offsite
  • Enterprise key management
    • In this case , third party tools create and store the keys and then given to SQL Server when need them
    • Some of these tools are physical appliances and some are software
    • For example "Alliance key Manager" from Townsend Security is physical appliance
      • It also available as a virtual appliance to deploy it to Hyper-V or VMware platforms
    • Help to have more control over the key creation process
      • Team who manage the keys don't have access to databases and DBA don't have access to key management system
      • This follows the concept of "Separation of duties"
    • Supported with SQL Server 2008+ enterprise editions
    • Whenever possible use a longer key for better data protection
    • Longer keys are more secure but require more CPU power to encrypt and decrypt the data while shorter keys require less CPU power but are less secure
  • If the key will be used for "Transparent Data Encryption" then it must be created within "master" database. If the key will be used for row level using functions such EncryptByKey then the key should be created within the user database.
(4) Database Encryption
  • To protect your data in database.
  • No one encryption solution is correct for every database (based on requirements).
  • Remember more data you encrypt and the stronger the encryption , the more CPU power will be required
    • Be sure to balance the encryption requirements with the increased system load
  • SQL Server it does support some of the most popular algorithms from weakest to strongest like DES, TRIPLE_DES, TRIPLE_DES_3KEY, RC2, RC4, RC4_128, DESX, AES_128, AES_192, and AES_256  (this list available since SQL 2005 till SQL 2014)
  • Triple DES (or 3DES)
    • Use DES algorithm three times for each block of data for each 64 bit block
    • Three keys are used k1,k2 and k3
      • Has three forms
        • The strongest option: three keys with different values of 56 bits, represented within SQL Server as the TRIPLE_DES_3KEY algorithm or the DESX algorithm.
        • A little weaker: keys k1 and k3 use the same key values and k2 uses a different value, which is represented within SQL Server as the TRIPLE_DES algorithm.
        • A weaker TRIPLE_DES algorithm, which is backwards compatible with the DES algorithm. It uses the same key values for all the possible keys.
  • RC algorithms
    • RC2 uses a 49 bit key size
    • RC4 uses key sizes from 40 to 2048 bits , but in SQL you can select from 40 to 128 bit
    • All these are deprecated and they are weak
    • RC4 used with SSL for both SSH and HTTPs
  • AES
    • Has three sizes : 128 , 192 and 256 bits (AES_128 …)
    • Attacker has some success in breaking the lower end AES encryption
    • To date , the higher versions of AES have remained stable
    • C# Encryption and Decryption Example (Add System.Security Reference) (AES still is consider secure not like DES)
static void Main(string[] args)
var plainText = "Test";
var key = GenerateRandomNumber(32);
var iv = GenerateRandomNumber(16);

var encrypted = Encrypt(Encoding.UTF8.GetBytes(plainText), key, iv);
var decrypted = Decrypt(encrypted, key, iv);

Console.WriteLine("Encrypted Text = " + Convert.ToBase64String(encrypted));
Console.WriteLine("Decrypted Text = " + Encoding.UTF8.GetString(decrypted));


static byte[] GenerateRandomNumber(int length)
using (var randomNumberGenerator = new RNGCryptoServiceProvider())
//Fixed length
var randomNumber = new byte[length];

return randomNumber;

static byte[] Encrypt(byte[] dataToEncrypt, byte[] key, byte[] iv)
using (var aes = new AesCryptoServiceProvider())
aes.Mode = CipherMode.CBC;
aes.Padding = PaddingMode.PKCS7;

aes.Key = key;
aes.IV = iv;

using (var memoryStream = new MemoryStream())
var cryptoStream = new CryptoStream(memoryStream, aes.CreateEncryptor(), CryptoStreamMode.Write);
cryptoStream.Write(dataToEncrypt, 0, dataToEncrypt.Length);

return memoryStream.ToArray();

static byte[] Decrypt(byte[] dataToDecrypt, byte[] key, byte[] IV)
using (var aes = new AesCryptoServiceProvider())
aes.Mode = CipherMode.CBC;
aes.Padding = PaddingMode.PKCS7;

aes.Key = key;
aes.IV = IV;

using (var memoryStream = new MemoryStream())
var cryptoStream = new CryptoStream(memoryStream, aes.CreateDecryptor(), CryptoStreamMode.Write);

cryptoStream.Write(dataToDecrypt, 0, dataToDecrypt.Length);

var decryptBytes = memoryStream.ToArray();

return decryptBytes;
  • Hashing
    • One way encryption , same hash value for the same value
    • You can use MD2... MD5 and SHA or SHA1
    • With SQL 2012 , SHA2 256 or 512 was added
    • Hashing is done by HASHBYTES function (for all algorithms)
      • Two prams : the algorithm to use and the value to hash
        • HAShBYTES(‘MD5’,@Password)
        • HAShBYTES(‘SHA2_256’,@Password)
      • Doesn’t support string longer than 8000 bytes
        • ASCII = 8000 char (CHAR or VARCHAR data types)
        • Unicode = 4000 char (NCHAR , NVARCHAR)
    • In 1996 , first collisions were identified with MD5
    • In 2005 , research able to create X.509 certificates which produced the same hash
      • In this year , the creator of MD5 (Ron) wrote “MD5 and SHA1 are both clearly broken”
    • In 2008 , researches announced that they able to use MD5 and create fake CA certificate by RapidSSL so then allow them to create certificates for websites
    • but in SQL 2008 R2 , MD5 and SHA1 are the most secure hashing algorithms that are available
      • The only way to support more secure algorithm is to use .NET CLR assembly
    • In SQL 2012 , introduced SHA2 which is considered this more secure
    • There are two ways to find hashed value
      • Compared to pre-generated hashes database
      • Second is called a MD5 collision attack (two different values with the same hash)
  • SHA2 and SQL Server
    • In SQL 2012 , it support SHA2_256 ,SHA2_512 hashing algorithm
    • Was published in 2001 by NIST as US Federal information processing Standards
    • SHA2 fixes the security issues in SHA1
    • The first different points between SHA2_256 and SHA2_512 is the amount of CPU power required
    • The second is the size of the hash which is returned (Need to check table variables length)
      • 256 key return 256 bit (32 bytes)
      • 512 key return 512 bit (64 bytes)
  • Converting from MD5/SHA1 to SHA2
    • Decrypt the data and hash it with new algorithm
    • Adding extra columns to store the new hashes because the size is different
  • C# Hashing Example(Add System.Security Reference)(Still is consider secure not like MD5)
 static void Main(string[] args)
var plainText = "Test";
var hashedMessage = HashDataSHA256(Encoding.UTF8.GetBytes(plainText));
Console.WriteLine("Hashed Message = " + Convert.ToBase64String(hashedMessage));

private static byte[] HashDataSHA256(byte[] toBeHashed)
using (var sha256 = SHA256.Create())
return sha256.ComputeHash(toBeHashed);
  • Encrypting Objects
    • To protect them from being viewed and modified by others (client side)
    • Objects supported are stored procedures and functions (table and scalar functions)
    • You simply add WITH ENCRYPTION before AS (when go to client servers)
    • Decryption of encrypted objects is Fast
      • But for troubleshooting loses the ability to view the estimated or actual execution plan
      • You can’t monitor SP:StmtStarting and SP:StmtCompleted by SQL Profiler when these objects are encrypted and also can’t view execution plans
  • Ways to get the code behind the encrypted objects by connecting to DAC and then querying the system catalog or use third party(cracked many years ago)
  • Encrypting data within Tables
    • Where to encrypt your data , at web server , client or database
    • Each option has pros and cons
    • At database
      • Pros: minimal changes to the web server
      • Cons: CPU load at database server
      • Cons: Certificate stored in database (with given enough time , any encryption schema is crackable)
    • At application tier (Web Server or Client desktop)
      • Pros: spread the load across all servers
      • Cons: a load of application changes (add extra servers due to the nature of increase by 10% to 20%)
  • Note: Data Encryption laws
    • Based on company based , customer or location
    • Some has consequences if your data is leaked
    • When designing an encryption plan be sure to include legal counsel
  • Encrypting within SQL Server
    • If you have SQL 2000 or older don’t go with native support
      • Use third party like DLL
      • Only hashing function that you can use it is “pwdencrypt” , this function is deprecated in new version
        • undocumented function return 255 varbinary
        • SELECT pwdencrypt(‘test’)
    • Starting from SQL 2005 , you can use native encryption and hashing functions
    • To encrypt data
      • EncryptByCert()
        • Certificate stored within database
        • You can easily move it from platform to another
        • Purchased from a third party like VeriSign and GoDaddy
      • EncryptBykey()
        • Symmetric key
        • This key can be created by password , a certificate or another symmetric key
      • EncryptByPassPhrase()
        • Passphrase is used as the key in symmetric encryption
    • Till  2014, none of these can be used in SQL Azure and it will return error so you need to do it at the web tier
  • Encrypting within Application Tier
    • More scalable
    • The data is transmitted between the database and the application tier is encrypted without need to configure IP Sec
    • Use .NET native functions ( you can use salt , iteration ,IV …)
  • Moving from plain text to encrypted values in an existing application
    • For small application you can accept the outage
    • But for large application
      • Add additional column with bit data type (IsEncrypted)
      • Handle it in your application , if it’s plain get the plain and encrypted and if it’s encrypted then get the encrypted based on this column
      • After all data were encrypted then remove the plain text column
  • Encrypting Data at Rest
    • In SQL 2008 , Microsoft introduced a feature called Transport Data Encryption which encrypt the data as it’s written to the hard disk and decrypts the data when it read from disk into memory
    • Advantages
      • Able to encrypt all data
      • Backup is also encrypted
    • The encryption is done by encrypting the blocks of data instead of the data stored within the blocks
      • The difference between two concepts is that when the data is encrypted, only the data tables is encrypted while TDE will encrypt the metadata about the tables also …
    • The downside , that anyone access the SQL by normal means like Injection , or SSMS then can querying the data
    • Also TDE will increase CPU load on SQL server
    • Turn On TDE , right click on database and select properties , select options , Enable encryption (true) , the data within the page will be encrypted , also data written to transaction log will encrypt
    • If you don’t have a master key created within the database the master key must be created using the CREATE MASTER KEY command before you can enable TDE
    • Also it will be enabled for Tempdb for storing temporary data
      • This will cause a performance impact to other databases within your instance that use the tempdb database for storing temporary data
    • When enable TDE , make sure to backup encryption key and store them securely
      • If you lose the key , you can’t restore backup
      • If someone get the key , he can read your database backup or attach it
    • If you’re using Mirroring then both the primary and mirror will be encrypted (log will be encrypted during movement to protect the data from sniffing)
    • If you use full-text indexing with TDE , the data within index will be encrypted
      • This will not happen immediately (Microsoft is not recommend to index sensitive data using TDE)
    • Database backup , it will use much lower amount of compression because encryption decreases the unique data
    • If you use replication , you need to enable TDE on the subscriber and distributor to have fully protected
    • TDE only with Enterprise edition (2008) or Enterprise and Data center editions (2008 R2)
    • Note: when we create the certificate we don’t specify the expire data. By default SQL create a certificate for one year
      • What happened when it expire?
        • Nothing,because no way to renew the internal certificates that used for TDE
  • TDE and FileStream
    • Data written via FILESTREAM will not be encrypted (only data stored in mdf , ndf or ldf) will encrypted with DTE
    • User can access files directly via windows network share (either encrypt the files before store them to FILESTREAM or use a file-system-based encryption process (like Encryption File Stream(EFS) encryption)
  • Log Shipping , Mirroring and Always ON
    • You need to first restored the encryption key to destination server to be able to restore the data
    • Also the certificate in master database should be restored
    • Then in destination server Create (restore) it
    • Delete the certificate backup file
  • Key protection
    • If someone access the certificate , your data and encryption is useless
    • It’s recommended to backups these backups and placed in a sealed envelope with signature (for tampering detection)
      • Also it’s good to have another copy in different place or office
  • Encrypting data on the wire
    • To encrypt data as it flows over the network between the SQL server and client to prevent sniffing
    • Done by either SSL for the SQL connection or using IPSec to secure all network communication (or subnet of network)
    • Using SSL , you manage the encryption from SQL server and also the encryption limited to SQL packets
    • The advantage of IPSec can offload the work from CPU to a processor on the network card
    • The good example to use SSL for public connection and with report service when the user pass his credential to open the reports
  • SQL Server over SSL
    • You need to acquire SSL from a trusted Certificate Authority
      • You can get one from internal enterprise CA or a recognized CA such as GoDaddy or others
    • Then you need to export the certificate from the server you first requested and import it to other server if you have cluster
    • When you request a certificate you need to specify the name that your users will connect to SQL as the subject of the certificate
    • Certificate must be stored in either local store or current user store (SQL account)
    • From and to date must be valid to local system time
    • Certificate must be a server authentication Certificate that requires Enhanced Key Usage property of the Certificate to specify server authentication
    • The Certificate must be created using Key-Spec option of AT_KEYEXCHANGE, optionally the key usage property will include it
    • SQL 2008 R2 supports the use of wildcard not like the prior version
    • You can use self-signed certificates but not recommended as this opens the server up to MITM attacks where the user connects to another process , that process decrypts the connect and then forwards the connection along to the final destination while reading all traffic
  • SQL Server 7 and 2000
    • No UI to tell SQL server which certificate to use. By default it will use the certificate that has the same name of SQL Server
      • To change the name of certificate then you need to modify the registry key (SuperSocketNetLib) (add thumbprint value)
    • Configuring SQL 2000 to use encryption , open SQL Network Utility
      • Select instance you wish to configure and check the box that says “Force protocol encryption”
      • Restart SQL service
      • If SQL can’t start then check the Error-Log if SQL can’t find the certificate
  • SQL Server 2005 and Up
    • Expand “SQL Server Network Configuration” (if you install 32 bit in 64 bit OS then select 32 bit)
    • Go to properties , select the certificate and “Force Encryption option”
    • SQL will reject any connection do not support encryption if you forced and if you not then SQL will accept both connections
    • In connection string use , Force Encryption=true
    • Restart SQL Service
  • Authentication
    • From SQL 2000 SP 3 + , authentication information passed between SQL and client is encrypted
    • In old version if you use Multiprotocol Net-Library also has native encryption (RPC encryption API)
    • When using TCP/IP or Named Pipes to connect to the same instance , the authentication is not encrypted using drivers older than SQL 2005 native client
    • Multiprotocol Net-Library can’t be used to connect to named instances so no encryption is supported in SQL 2000 unless SSL used
    • SQL Server 7 don’t support named instances
  • Certificate Strength Differences
    • If it’s from a third party like GoDaddy then it’s most likely a 128 bit (although older certificates could be as 64 bit)
    • If it’s from internal CA then it could be weaker than 64 bit or stronger than 128 bit
    • The difference in protection comes from the length of the private key
    • The longer the private key is the more secure the data is
    • The longer private key comes at a price as it will require more CPU power
    • Selecting the right strength is a decision of management and business
      • How they need the secure data
    • Also longer encryption string is that the network will be used more by SQL Server than before
      • SQL Server probably has at least 1 Gig uplink
      • Maybe you need to upgrade your WAN or LAN
  • Managing SSL Certificates
    • Because all clients connect to SQL server , you need to manage SSL certificate in SQL by reissuing or change CA
    • Same configuration as first setup
  • Hiding the instance
    • Hide it from listing
    • Go to SQL Server properties and select hide instance
    • Restart the service
    • User must know the name to connect
  • IP Sec
    • All network communication between two computers is encrypted
    • Can be configured either on local machine or domain via group policies
  • Encrypting Data with MPIO Drivers
    • Multi-path Input Output drivers are only used when SQL server connect to a storage array via either fiber channel or Internet Small computer system interface (iSCSI)
    • Needs multiple cables (multi-path) to have redundant connection
    • Some drivers like EMC PowerPath , include encryption features which encrypt and decrypt all traffic between the server and storage array
      • EMC purchase of RSA a few years ago
    • The upside , nothing change in your code but the downside load in SQL CPU and also you need to manage the certificate used by MPIO driver
  • PowerPath Encryption with RSA requirements
    • RKM server software that is provided by RSA
    • Certificate          
      • must be a password-protected PKCS#12 file
      • The hosts are authenticated against the RKM server using a PEM (Privacy Enhanced Mail) encoded trusted root certificate
  • Encrypting data via HBAS
    • Her offloaded from SQL Server CPU to the processors on the actual HBAs
    • But here you are locked into a specific vendor (Emulex)
    • Works with PowerPath drivers
  • No single answer to the question “How should I encrypt my database”
  • With SQL Azure , encryption can be handled within the application tier
    • SQL Azure , support Hashing as the onsite server instances
  • Key Encryption Tutorial with Script


  • Please test these tips before go live.
  • I will be happy with your feedback because your feedback is very important ,if you have comments or new points please send it to me @ or Tweet me @ .
Change Logs:
  • Published with 4 sections .[9/9/2015]

Comments (1)

  1. Eng.Sultan Al-Mutrif says:

    in the beginning of page 5 we consider to add another configure related Window domain tree with three layers having two-way transitive trust between them Figure (1) and Figure (2)…

    Need more explanations regarding EKM ,SMK..

    What is the difference between AES and DES ,since it is already descripe the meaninig of  AES with short explanations as points .

    All the best of your summarizations .

    Best Regards;

Skip to main content