 | |
[Info-Ingres] Column Encryption
comp.databases.ingres comp.databases.ingres
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: [Info-Ingres] Column Encryption -
03-12-2010
, 11:37 AM
|
staff, appropriate access controls, etc, it still is an significant issue that "select column from table" shows sensitive data in clear-text. |
and/or databases are encrypted if the *session* connecting to the
encrypted objects is not then you're exposed in a way that's much
simpler to penetrate.
IMO, having encrypted columns is another important
Quote:
|
"security layer". On the down side, I think the implementation of encrypted columns, if not done properly, would be a nightmare...... |
LDAP integration, which IMO, is preferable to encrypted databases. If I
have LDAP access control, "fortifide" with Kerberos, and if I'm forcing
the use of SSL certificates, then I can prevent the execution of any
queries not authorized for a particular user which relies on an
integrated set of technologies.
Even features like Oracle (Enterprise) Security Labels don't account for
the "modern" computing infrastructure which is most often servicing
sessions that are distributed across a variety of internal and external
networks. Simply relying on DBMS internal security, including
encryption, is an incomplete security model.
Samba 4 is on the way, with the ability to act as a Domain Controller,
making managing LDAP, and integrating such with Microsoft Active
Directory, quite simple. I would love to see INGRES DBMS support LDAP
integration, where when integrated with Samba, you'd have the ability to
control not only the access to the DBMS objects, but also the access to
the file system objects, providing an end-to-end security model without
the overhead of multiple local DBMS and system accounts and without the
overhead of table and/or database encryption.
~~~~~~~~~~~~~~~~~~~~
Mark R. Winston
www.datavailable.com
~~~~~~~~~~~~~~~~~~~~
Quote:
|
On Fri, Mar 12, 2010 at 9:31 AM, Roy Hann specially (AT) processed (DOT) almost.meat> wrote: Mike wrote: James K. Lowden wrote: Martin Bowes wrote: Ditto, This is probably more useful to me than MVCC! Why? A database's job is to keep data. One might argue that "protect" is part of "keep", and that access control is part of a database server's job. But I don't understand the enthusiam for encryption in the database. It's a little like asking the fire department to burn down the house. Data properly protected don't need to be encrypted. It's becoming a regulatory requirement round here in the medical world. Regardless of whether it makes sense, being able to say that your data is encrypted "at rest" ticks the auditor's boxes and they go away happy. There are a number of ways of achieving this, but having it encrypted in the database is possibly the most convincing to an outside observer because you can run "select column from table" and point to the gibberish... I have no objection to ticking boxes if it is cheap and easy. I have rather more objection to investing lots of time and effort in doing something that is actually futile, and doubly so if doing it lulls people into not taking other steps that really would be effective (like encrypting the disks and vetting the staff). One could hope these hypothetical auditors of yours are not so easily satisfied as you say. :-) -- Roy UK Ingres User Association Conference 2010 will be on Tuesday June 8 2010 Go to http://www.iua.org.uk/join to get on the mailing list. _______________________________________________ Info-Ingres mailing list Info-Ingres (AT) kettleriverconsulting (DOT) com mailto:Info-Ingres (AT) kettleriverconsulting (DOT) com http://ext-cando.kettleriverconsulti...fo/info-ingres _______________________________________________ Info-Ingres mailing list Info-Ingres (AT) kettleriverconsulting (DOT) com http://ext-cando.kettleriverconsulti...fo/info-ingres |
#12
| |||
| |||
|
|
On 3/12/2010 12:06 PM, Cory Nemelka wrote: [snip]Even with encrypted disks, proper vetting of staff, appropriate access controls, etc, it still is an significant issue that "select column from table" shows sensitive data in clear-text. ...not to suggest that you've overlooked this, but even when the tables and/or databases are encrypted if the *session* connecting to the encrypted objects is not then you're exposed in a way that's much simpler to penetrate. IMO, having encrypted columns is another important "security layer". On the down side, I think the implementation of encrypted columns, if not done properly, would be a nightmare...... INGRES DBMS supports Kerberos integration, but it doesn't yet support LDAP integration, which IMO, is preferable to encrypted databases. If I have LDAP access control, "fortifide" with Kerberos, and if I'm forcing the use of SSL certificates, then I can prevent the execution of any queries not authorized for a particular user which relies on an integrated set of technologies. Even features like Oracle (Enterprise) Security Labels don't account for the "modern" computing infrastructure which is most often servicing sessions that are distributed across a variety of internal and external networks. Simply relying on DBMS internal security, including encryption, is an incomplete security model. I agree with everything in your response. Just to clarify the point above, relying on DBMS internal security alone, is not "security in layers" and I |
Quote:
|
Samba 4 is on the way, with the ability to act as a Domain Controller, making managing LDAP, and integrating such with Microsoft Active Directory, quite simple. I would love to see INGRES DBMS support LDAP integration, where when integrated with Samba, you'd have the ability to control not only the access to the DBMS objects, but also the access to the file system objects, providing an end-to-end security model without the overhead of multiple local DBMS and system accounts and without the overhead of table and/or database encryption. ~~~~~~~~~~~~~~~~~~~~ Mark R. Winston www.datavailable.com ~~~~~~~~~~~~~~~~~~~~ On Fri, Mar 12, 2010 at 9:31 AM, Roy Hann specially (AT) processed (DOT) almost.meat> wrote: Mike wrote: James K. Lowden wrote: Martin Bowes wrote: Ditto, This is probably more useful to me than MVCC! Why? A database's job is to keep data. One might argue that "protect" is part of "keep", and that access control is part of a database server's job. But I don't understand the enthusiam for encryption in the database. It's a little like asking the fire department to burn down the house. Data properly protected don't need to be encrypted. It's becoming a regulatory requirement round here in the medical world. Regardless of whether it makes sense, being able to say that your data is encrypted "at rest" ticks the auditor's boxes and they go away happy. There are a number of ways of achieving this, but having it encrypted in the database is possibly the most convincing to an outside observer because you can run "select column from table" and point to the gibberish... I have no objection to ticking boxes if it is cheap and easy. I have rather more objection to investing lots of time and effort in doing something that is actually futile, and doubly so if doing it lulls people into not taking other steps that really would be effective (like encrypting the disks and vetting the staff). One could hope these hypothetical auditors of yours are not so easily satisfied as you say. :-) -- Roy UK Ingres User Association Conference 2010 will be on Tuesday June 8 2010 Go to http://www.iua.org.uk/join to get on the mailing list. _______________________________________________ Info-Ingres mailing list Info-Ingres (AT) kettleriverconsulting (DOT) com mailto:Info-Ingres (AT) kettleriverconsulting (DOT) com http://ext-cando.kettleriverconsulti...fo/info-ingres _______________________________________________ Info-Ingres mailing list Info-Ingres (AT) kettleriverconsulting (DOT) com http://ext-cando.kettleriverconsulti...fo/info-ingres _______________________________________________ Info-Ingres mailing list Info-Ingres (AT) kettleriverconsulting (DOT) com http://ext-cando.kettleriverconsulti...fo/info-ingres |
#13
| |||
| |||
|
|
staff, appropriate access controls, etc, it still is an significant issue that "select column from table" shows sensitive data in clear-text. |
and/or databases are encrypted if the *session* connecting to the
encrypted objects is not then you're exposed in a way that's much
simpler to penetrate.
IMO, having encrypted columns is another important
Quote:
|
"security layer". On the down side, I think the implementation of encrypted columns, if not done properly, would be a nightmare...... |
LDAP integration, which IMO, is preferable to encrypted databases. If I
have LDAP access control, "fortifide" with Kerberos, and if I'm forcing
the use of SSL certificates, then I can prevent the execution of any
queries not authorized for a particular user which relies on an
integrated set of technologies.
Even features like Oracle (Enterprise) Security Labels don't account for
the "modern" computing infrastructure which is most often servicing
sessions that are distributed across a variety of internal and external
networks. Simply relying on DBMS internal security, including
encryption, is an incomplete security model.
Samba 4 is on the way, with the ability to act as a Domain Controller,
making managing LDAP, and integrating such with Microsoft Active
Directory, quite simple. I would love to see INGRES DBMS support LDAP
integration, where when integrated with Samba, you'd have the ability to
control not only the access to the DBMS objects, but also the access to
the file system objects, providing an end-to-end security model without
the overhead of multiple local DBMS and system accounts and without the
overhead of table and/or database encryption.
~~~~~~~~~~~~~~~~~~~~
Mark R. Winston
www.datavailable.com
~~~~~~~~~~~~~~~~~~~~
Quote:
|
On Fri, Mar 12, 2010 at 9:31 AM, Roy Hann specially (AT) processed (DOT) almost.meat> wrote: Mike wrote: James K. Lowden wrote: Martin Bowes wrote: Ditto, This is probably more useful to me than MVCC! Why? A database's job is to keep data. One might argue that "protect" is part of "keep", and that access control is part of a database server's job. But I don't understand the enthusiam for encryption in the database. It's a little like asking the fire department to burn down the house. Data properly protected don't need to be encrypted. It's becoming a regulatory requirement round here in the medical world. Regardless of whether it makes sense, being able to say that your data is encrypted "at rest" ticks the auditor's boxes and they go away happy. There are a number of ways of achieving this, but having it encrypted in the database is possibly the most convincing to an outside observer because you can run "select column from table" and point to the gibberish... I have no objection to ticking boxes if it is cheap and easy. I have rather more objection to investing lots of time and effort in doing something that is actually futile, and doubly so if doing it lulls people into not taking other steps that really would be effective (like encrypting the disks and vetting the staff). One could hope these hypothetical auditors of yours are not so easily satisfied as you say. :-) -- Roy UK Ingres User Association Conference 2010 will be on Tuesday June 8 2010 Go to http://www.iua.org.uk/join to get on the mailing list. _______________________________________________ Info-Ingres mailing list Info-Ingres (AT) kettleriverconsulting (DOT) com mailto:Info-Ingres (AT) kettleriverconsulting (DOT) com http://ext-cando.kettleriverconsulti...fo/info-ingres _______________________________________________ Info-Ingres mailing list Info-Ingres (AT) kettleriverconsulting (DOT) com http://ext-cando.kettleriverconsulti...fo/info-ingres |
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres
#14
| |||
| |||
|
#15
| |||
| |||
|
|
Mike wrote: James K. Lowden wrote: Martin Bowes wrote: Ditto, This is probably more useful to me than MVCC! Why? A database's job is to keep data. One might argue that "protect" is part of "keep", and that access control is part of a database server's job. But I don't understand the enthusiam for encryption in the database. It's a little like asking the fire department to burn down the house. Data properly protected don't need to be encrypted. It's becoming a regulatory requirement round here in the medical world. Regardless of whether it makes sense, being able to say that your data is encrypted "at rest" ticks the auditor's boxes and they go away happy. There are a number of ways of achieving this, but having it encrypted in the database is possibly the most convincing to an outside observer because you can run "select column from table" and point to the gibberish... I have no objection to ticking boxes if it is cheap and easy. I have rather more objection to investing lots of time and effort in doing something that is actually futile, and doubly so if doing it lulls people into not taking other steps that really would be effective (like encrypting the disks and vetting the staff). One could hope these hypothetical auditors of yours are not so easily satisfied as you say. :-) |
As others have said, defence in depth is the best approach, but my
experience is that auditors I deal with seem to place more faith in
anything with the word "encryption", and less faith in what they
perceive as "weak" methods such as "access control".
However, it's more convincing to say that the data reside
- on an encrypted volume
- to which access is controlled
- and that personal identifiers are encrypted within the volume
than to simply say one of the above.
I calculated recently that I had spent almost 10% of my work-time this
year saying the above, or similar, to differening regulators on
different studies...
Mike.
#16
| |||
| |||
|
#17
| |||
| |||
|
|
Meanwhile... I remember there was an example how to "extend" our beloved Ingres with new "commands" somewhere. And if I remember well, example shows how to implement MD5 digest, so one can actually use MD5('something') on Ingres. Unfortunately, I do not remember where I found it.  I think it is somewhere on the Ingres wiki.I think http://community.ingres.com/wiki/OME_checksum() |
looking for. I've created http://community.ingres.com/wiki/MD5_checksum
<http://community.ingres.com/wiki/OME_checksum%28%29> as a redirect so
that Google et. al. can also pick it that way.
--
Grant Croker, Ingres Corp
Ingres PHP and Ruby maintainer
http://blogs.planetingres.org/grant
The World Wide Web is the only thing I know of whose shortened form -
www - takes three times longer to say than what it's short for.
#18
| |||
| |||
|
|
-----Original Message----- From: info-ingres-bounces (AT) kettleriver...ting (DOT) com [mailto:info- ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of Ingres Forums Sent: 25 March 2010 18:05 To: info-ingres (AT) kettleriverconsulting (DOT) com Subject: Re: [Info-Ingres] Column Encryption Meanwhile... I remember there was an example how to "extend" our beloved Ingres with new "commands" somewhere. And if I remember well, example shows how to implement MD5 digest, so one can actually use MD5('something') on Ingres. Unfortunately, I do not remember where I found it. I think it is somewhere on the Ingres wiki.-- dejan ----------------------------------------------------------------------- - dejan's Profile: http://community.ingres.com/forum/me...p?userid=13077 View this thread: http://community.ingres.com/forum/sh...ad.php?t=11685 _______________________________________________ Info-Ingres mailing list Info-Ingres (AT) kettleriverconsulting (DOT) com http://ext-cando.kettleriverconsulti...fo/info-ingres |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.