RE: Postgresql database encryption - Mailing list pgsql-general

From Ahmed, Nawaz
Subject RE: Postgresql database encryption
Date
Msg-id BAAE097528E6CB4FB2BE65AEFA6EEE04939AB768@SYD1217
Whole thread Raw
In response to Re: Postgresql database encryption  (Ozz Nixon <ozznixon@gmail.com>)
List pgsql-general

Hi Folks,

 

I would like to add to the list FUJITSU Software Enterprise Postgres as well, a commercial version of FSEP offers both TDE (AES 128 / 256) and Data Masking features

 

PremierSQL TDE
MariaDB 10.1.3+
MySQL 5.7.11+

Microsoft uses TDE

Oracle AdvSec uses TDE
DB2 v7.2 UDB

MangoDB uses AES-256

PostgreSQL does - but the key is public (dumb)

FUJITSU Enterprise Postgres 9.5 (TDE / DM)

 

 

 

Best Regards,

 

Nawaz Ahmed
Software Development Engineer

Fujitsu Australia Software Technology Pty Ltd

14 Rodborough Road, Frenchs Forest NSW 2086, Australia
T +61 2 9452 9027
Nawaz@fast.au.fujitsu.com
fastware.com.au


 

From: Ozz Nixon [mailto:ozznixon@gmail.com]
Sent: Saturday, 21 April 2018 10:43 AM
To: Ron <ronljohnsonjr@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Subject: Re: Postgresql database encryption

 

Thanks Ron, I was trying to find that -- memory had it down as "Persona" and I could not find that, haha.

 

On Fri, Apr 20, 2018 at 8:39 PM Ron <ronljohnsonjr@gmail.com> wrote:


Also, Percona (a MySQL fork) 5.7.

On 04/20/2018 07:31 PM, Ozz Nixon wrote:

PS. the following database servers do offer internal encryption on a page/block oriented read/write (for encrypted data at rest security requirements)

PremierSQL TDE
MariaDB 10.1.3+
MySQL 5.7.11+

Microsoft uses TDE

Oracle AdvSec uses TDE
DB2 v7.2 UDB

MangoDB uses AES-256

Just because you do not see the reason for it, does not make the reason a bad idea.

 

On Fri, Apr 20, 2018 at 8:19 PM Ozz Nixon <ozznixon@gmail.com> wrote:

Well, actually since 2003, this has been a standard requirement from the Credit Card industry. And it does make sense in the field of "while at rest" the data still cannot be accessed.

Requirement 1. No NPI data should be displayed without controls - e.g. reports, PDF, etc.

Requirement 2. Same data, must be secured during transmission - fetching to client screen etc.

Requirement 3. NPI data should not be logged nor stored on a physical device in non-encrypted mode.

There are more steps to this, but, to chalk it off as another half-assed required is typical. Hashing is a useful one-way technique, however, trapping the hash made using a hash useless! When I worked for the credit bureaus we ran encrypted drive arrays, DB/2 encrypted, SSL/TLS encryption over P2P VPN connections, and masked output fields when the data would go to reports or screens to PCs outside our control.

Anyone with Linux and use LUKS encryption on an LVM partition to achieve security where the database may not, or logs or something may exist where NPI might be see. Oh yeah, NPI (Non-Pubic Information, like your social, you bank account, you paycheck information, etc. things that should not exist outside of controls)...

PS. You cannot simply take a drive from one machine to another, when doing proper RAID and LUKS encryption.

Ozz

15 years experience with federal data security requirements.

 

On Fri, Apr 20, 2018 at 7:55 PM Tim Cross <theophilusx@gmail.com> wrote:


Vikas Sharma <shavikas@gmail.com> 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

 

--
Angular momentum makes the world go 'round.

Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.

Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.

If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe@fast.au.fujitsu.com

Attachment

pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: Same condition in the CTE and in the subsequent JOIN using it
Next
From: Michael Paquier
Date:
Subject: Re: Pulling initial physical replication pg_basebackup from adownstream server