Most of us are paranoid about security – be it in our work lives or our personal lives. Having said that, 2014 Verizon Data Breach Investigations Report states that with all the regulations in place, in 2013 alone there were 63,437 (an increase from 47,000) security related incidents of which 1,367 (an increase from 621) of them were confirmed to be data breaches. Most of these incidents were opportunistic attacks which means that they could have been prevented. There is a high requirement for tighter internal controls to prevent unauthorized disclosure of sensitive information. How are these being addressed from a database perspective? SAP ASE’s encryption and security technologies protect data from both internal and external security breaches allowing you to keep your data secure.
About 10+ years ago, ASE introduced the state-of-the-art column-level encryption which enabled administrators to protect sensitive data on disk and help meet security and privacy requirements. And with SAP ASE 16, ASE added support for full-database encryption. Both encrypted columns as well as fully encrypted databases can help companies meet their security and privacy requirements. One solution however, might be more suitable than the other, depending on specific circumstances. Column-based encryption might be preferable when a company can easily identify what data is sensitive for their business and different database users have different access rights on the sensitive data. Column-level encryption requires that each sensitive data attribute be evaluated individually to validate the access rights of different users and to identify the encryption technique used on the attribute. Even though it has its own advantages in terms of granularity, it has its dis-advantages as well. In specific scenarios, performance can be a concern. One example is when queries use common techniques such as range searches on the encrypted data field. This is because the encryption process will likely randomize the data such that it is no longer in alphabetical sequence. Another example is during data retrieval. This is because data is not only kept encrypted on disk, but also in main memory. So in this case, for each user accessing the data in the encrypted column, decrypting has to be done. Also one more limitation is you cannot create an index or have a constraint on an encrypted column.
On the other hand, full-database encryption may be beneficial for companies that have different requirements. The use of full database encryption is preferable when it is hard to identify which columns hold sensitive data. With full database encryption, we do not have to worry about identifying columns that have sensitive data. This is helpful especially since the definition of sensitive data differs from one location to another. Also, it might perform better especially if all database users have the same access rights (or a single database login is used). The fact remains that full database encryption is transparent to the user and the application as there is no change to the way one would query the data or manage the data. In SAP ASE 16 full-database encryption automatically encrypts all database objects – including data files, indexes and transaction logs. The entire encryption process is transparent to users and existing applications because the data is automatically decrypted when it is moved from disk to memory, and encrypted when it is moved from memory to disk. Encryption uses 256-bit symmetric keys and is implemented at the page level. Buffer manager is used to encrypt pages before they are written to disk and decrypt them when they are loaded into memory. One aspect of this functionality that is really very helpful is that it is implemented as an online operation. This means that an alter database command that fully encrypts a database executes in parallel with other database workloads and doesn’t interrupt any activities – be it – executing queries or doing an insert and update operations. Let us say we are going to encrypt a very large database. We know that it can take a long time. The good thing is that the encryption process can be executed along with other activities or it can be suspended and resumed, giving DBAs the flexibility to perform critical system maintenance as needed. If you remember, we had done this kind of mechanism with our maintenance activities like reorg operations and also creating an index giving more flexibility to users.
In closing, deploying technology that reliably keeps your enterprise data secure has become a necessary best practice to comply with security regulations. And SAP ASE does it once again with adhering to security using encryption – both column level encryption and full database encryption. Encryption algorithm in ASE uses FIPS140-2 certified modules for implementation.
