Vikas Sharma <shavikas@xxxxxxxxx> writes: > Hello Guys, > > Could someone throw light on the postgresql instance wide or database wide > encryption please? Is this possible in postgresql and been in use in > production?. > > This is a requirement in our production implementation. > This sounds like a lazy management requirement specified for 'security' purposes by people with little understanding of either technology or security. I suspect it comes form a conversation that went along the lines of .... "There has been lots in the news about cyber threats" "Yes, we need our system to be secure" "I know, lets make one of the requirements that everything must be encrypted, that will stop them" "Great idea, I'll add it as requirement 14". This is a very poor requirement because it is not adequately specified, but more critically, because it is specifying a 'solution' rather than articulating the requirement in a way which would allow those with the necessary expertise to derive an appropriate solution - one which may or may not involve encryption or hashing of data and which may or may not be at the database level. What you really need to do is go back to your stakeholders and ask them a lot of questions to extract what the real requirement is. Try to find out what risk they are trying to mitigate with encryption. Once this is understood, then look at what the technology can do and work out the design/implementation from there. It is extremely unlikely you just want all the data in the database encrypted. When you think about it, such an approach really doesn't make sense. In basic terms, if the data is encrypted, the database engine will need to be able to decrypt it in order to operate (consider how a where clause needs to be able to interpret actions etc). If the db can read the data, the keys must be in the database. If the keys are in the database and your database is compromised, then your keys are compromised. So provided you protect your database from compromise, you achieve the same level of security as you do with full data encryption EXCEPT for access to the underlying data files outside of the database system. For this, you will tend to use some sort of file system encryption, which is typically managed at the operating system level. Again, for the operating system to be able to read the file system, the OS must have access to the decryption keys, so if your OS is compromised, then that level of protection is lost as well (well, that is over simplified, but you get the idea). What this level of protection does give you is data at rest protection - if someone is able to access hour disks through some other means, they cannot read the data. This is the same principal most people should be using with their laptops. Protect the OS with a password and have the data on disk encrypted. Provided nobody can login to your laptop, they cannot read your data. Without this encryption, you can just take the disk out of the laptop, mount it on another system and you have full access. With disk encryption, you cannot do that. Same basic principal with the server. At the database level, a more typical approach is to use one way hashing for some sensitive data (i.e. passwords) and possibly column level encryption on a specific column (much rarer) or just well structured security policies and user roles that restrict who has access to various tables/columns. To implement this successfully, you need details regarding the domain, sensitivity of various data elements and the threats you need to protect against. If you cannot get this information because your stakeholders don't really know what their risks are and have not done a proper assessment and what you are really dealing with is bureaucracy which just as a dumb "data must be encrypted" policy, just use full disk encryption and state that all data is encrypted on disk" and your done. Tim -- Tim Cross
