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.
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.
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
--
Angular momentum makes the world go 'round.
|
