Formal Lecture.ppt
- 2. 2 A Truly Secure Database
- 3. 3 So In The Real World Database security protects the database against unwanted effects, accidental or deliberate There is always a trade off between high security and performance/user convenience Excessive security can in itself be a security threat - workarounds The first step is always a security audit This lecture looks at the use of encryption as part of a security policy
- 4. 4 Excessive Security Can In Itself Be A Security Threat Dilbert
- 5. 5 Before Deciding on Encryption Know the data and the database What should be encrypted? Which encryption algorithms? DBMS or external encryption? What is the acceptable performance hit? Who are you protecting against? Is the benefit worth the cost?
- 6. 6 The Role of Encryption Most database security techniques focus on controlling access – passwords, privileges, encrypting data as it travels There is much less focus on protecting data at rest (data in storage) We are assuming here that access encryption has already been used – this lecture focuses on data in storage Encryption is increasingly being used to protect data in storage Which includes backups And all the pen drives, portable hard drives, mobiles that get lost or stolen Encryption is often described as ‘the last line of defence’
- 7. 7 Whole Database Encryption The whole database is encrypted This protects the data at rest but requires decryption for use Whole DB encryption has traditionally been regarded as too expensive – SQL Server TDE, new with 2008, claims to reduce the performance hit but still acknowledges a cost (1)
- 8. 8 (2)
- 9. 9 Partial Data Encryption Partial encryption provides more granularity plus the data is not decrypted until it is used Usually referring to column encryption although it can also be cell level or encryption of DB objects such as triggers Rule of thumb – encrypting a single column is likely to produce a 5% performance hit, but this varies wildly Traditional partial encryption can produce a massive performance hit as indexes are not recognised – but this depends on the DBMS Highly configurable – can allocate different keys to different users With the downside that this increases the key management problem
- 10. 10 Partial Data Encryption For SQL Server 2008, Microsoft suggest that with cell level encryption, basic query performance tends to be around 20% worse. Problem increases with scaling “One sample application with 10,000 rows was four times worse with one column encrypted, and 20 times worse with nine columns encrypted. Because cell-level encryption is custom to each application, performance degradation will vary depending on application and workload specifics.” (1) “Custom to each application” - this is an “it depends” area
- 11. 11 The Encryption Process Encrypt Decrypt Plaintext Plaintext Cyphertext
- 12. 12 Encryption Algorithms: Data Encryption Standard DES has a short (56 bit) key plus 8 bits used for parity checking Very susceptible to brute force attacks “No sane security expert would consider using DES to protect data.” (2) Now outdated – older versions of DBMS encryption routines used DES e.g. early versions of Oracle
- 13. 13 Encryption Algorithms: 3DES The limitations of DES led to 3DES – uses the DES algorithm but employs a triple key approach Plain Text Cipher Text Much more secure but slower
- 14. 14 Encryption Algorithms: AES Key size 128,192 or 256 bits Consists of a set of processing rounds – the number varies depending on the key size e.g. 14 rounds for 256 length keys More secure
- 15. 15 Encryption Algorithms:RC5 Symmetric (same key used for en/decryption) block cypher Fast and flexible – the user can specify the number of rounds Allows for a variable length key Supported in Oracle & DB2
- 16. 16 Encryption in the DBMS Some of the initial problems with DBMS encryption are on the way to being solved Disk size was a major problem as ciphers may produce output in fixed block sizes, meaning that the input must be padded – requiring resizing of columns DBMS encryption was typically criticised for using outdated algorithms such as DES & even 3DES Sometimes compatibility issues A plus with DBMS encryption is that there should be minimal change implications
- 17. 17 Key Management The encryption is only as secure as the key DBMS based encryptions (typically) store the key inside the database Which raises issues such as How many keys Who manages them Where are they stored What happens if you lose your key?
- 18. 18 Encryption Servers As an alternative to encrypting within the DB, a central encryption server can be used to encrypt data in applications as well as in the database This is a heavily vendor led area; benefits claimed include More secure key management Wider choice of algorithms Wider coverage of data Easier management of encryption Removing computation overhead from DBMS/application servers The downside is: Added complexity Applications changes Cost And – is the extra layer necessary?
- 19. 19 Further Work You should understand the significance of the different encryption algorithms but the main areas to focus on are: The benefits of encryption in a DB context The downside to encryption in a DB context The business environment in which encryption would be useful What and how you should encrypt if you decide encryption would be useful How encryption would fit into your overall DB security policy
- 20. And a personal opinion My view: If someone truly wants to get into your database, they will probably manage it The biggest risk to data is accidental or casual intrusion People will lose pen drives – but an encrypted pen drive should not be too much of a problem Should we focus less on the main database and more on data storage? 20
- 21. 21 References 1. http://msdn.microsoft.com/en- us/library/cc278098.aspx 2. http://msdn.microsoft.com/en- us/library/bb934049.aspx 3. http://www.tropsoft.com/strongenc/des3.htm