Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

Started by Chetan Kosanamover 3 years ago18 messagesgeneral
Jump to latest
#1Chetan Kosanam
chetan.kosanam@tcs.com

TCS Confidential

Hi Support@ PostgreSQL Team,

Greetings !!

We are operating within one of the AWS business units of TCS. Our team is working on the Database migration from Oracle(on Amazon EC2) to PostgreSQL. The reason for this e-mailer is to seek your earnest required support from you on the Implementation of Wallet configuration ( which is in Oracle) by its equivalent configuration on the PostgreSQL side.

Thanks & Regards,
Chetan Kosanam
TCS, HYDERABAD
Contact : 9502753544
Mailto : chetan.kosanam@tcs.com

TCS Confidential
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

#2Alicja Kucharczyk
zaledwie10minut@gmail.com
In reply to: Chetan Kosanam (#1)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

śr., 21 gru 2022 o 18:33 Chetan Kosanam <chetan.kosanam@tcs.com> napisał(a):

TCS Confidential

Hi *Support*@ *PostgreSQL* Team,

*Greetings* *!!*

We are operating within one of the *AWS business* units of *TCS*. Our
team is working on the *Database migration from Oracle(on Amazon EC2) to
PostgreSQL*. The reason for this e-mailer is to seek your earnest
required support from you on the *Implementation of Wallet configuration*
( which is in Oracle) by its *equivalent* configuration on the
*PostgreSQL* side.

Thanks & Regards,

Chetan Kosanam

TCS, HYDERABAD

Contact : 9502753544

Mailto : chetan.kosanam@tcs.com

It seems you are looking for consultant:
https://www.postgresql.org/support/professional_support/

#3Sandeep Saxena
sandeep.lko@gmail.com
In reply to: Alicja Kucharczyk (#2)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

I could find old post on postgres community ,

/messages/by-id/20180625142233.GD20745@momjian.us

On Thu, May 17, 2018 at 07:07:00AM +0000, ROS Didier wrote:

Hi

Regarding the encryption of data by pgcrypto, I would like to
know the recommendations for the management of the key.

Is it possible to store it off the PostgreSQL server?

Is there the equivalent of Oracle "wallet" ?

Late reply, but the last presentation on this page shows how to use
cryptographic hardware with Postgres:

https://momjian.us/main/presentations/security.html

You could modify that to use a key management system (KMS).

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

On Wed, Dec 21, 2022 at 12:42 PM Alicja Kucharczyk <
zaledwie10minut@gmail.com> wrote:

Show quoted text

śr., 21 gru 2022 o 18:33 Chetan Kosanam <chetan.kosanam@tcs.com>
napisał(a):

TCS Confidential

Hi *Support*@ *PostgreSQL* Team,

*Greetings* *!!*

We are operating within one of the *AWS business* units of *TCS*. Our
team is working on the *Database migration from Oracle(on Amazon EC2) to
PostgreSQL*. The reason for this e-mailer is to seek your earnest
required support from you on the *Implementation of Wallet configuration*
( which is in Oracle) by its *equivalent* configuration on the
*PostgreSQL* side.

Thanks & Regards,

Chetan Kosanam

TCS, HYDERABAD

Contact : 9502753544

Mailto : chetan.kosanam@tcs.com

It seems you are looking for consultant:
https://www.postgresql.org/support/professional_support/

#4Laurenz Albe
laurenz.albe@cybertec.at
In reply to: Chetan Kosanam (#1)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

On Wed, 2022-12-21 at 04:48 +0000, Chetan Kosanam wrote:

We are operating within one of the AWS business units ofTCS. Our team is working on
the Database migration from Oracle(on Amazon EC2) to PostgreSQL. The reason for this
e-mailer is to seek your earnest required support from you on theImplementation of
Wallet configuration ( which is in Oracle) by its equivalent configuration on the
PostgreSQL side.

There is no exact equivalent, but there is something similar and much better: you can
authenticate the client with SSL client certificates:
https://www.postgresql.org/docs/current/auth-cert.html

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com

#5Rainer Duffner
rainer@ultra-secure.de
In reply to: Laurenz Albe (#4)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

Am 21.12.2022 um 22:34 schrieb Laurenz Albe <laurenz.albe@cybertec.at>:

There is no exact equivalent, but there is something similar and much better: you can
authenticate the client with SSL client certificates:
https://www.postgresql.org/docs/current/auth-cert.html <https://www.postgresql.org/docs/current/auth-cert.html&gt;

Isn’t the wallet the part where the encryption keys are stored?

Indeed, one of the few remaining features that only Oracle (and of course other commercial RDMSs) has seems to be full HSM support for TDE.

Rainer

#6Benedict Holland
benedict.m.holland@gmail.com
In reply to: Rainer Duffner (#5)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

What would you be missing? You can encrypt databases. You can encrypt the
s3 buckets using kms. You can govern access via ssh Auth. When you do
backups, you can encrypt the tar.gz files or whatever format and store it
on s3. Same with the wal files. The fact that oracle charges for this is a
joke. Of course, you would need to ensure compliance with your opsec teams
and stuck with best security practices but it seems top to bottom
encryption is unrelated or tangentially related to the databases.

Also, if you lose the encryption keys for your backups then bad things
happen. I doubt what I did was production viable but I limited database
access to a handful of users, encrypted the disks, left the Wal files
unencrypted but mounted with read access for a single user, compressed full
backups with encryption and a password, generated sah keys for anyone who
needed service accounts to access the systems, enforced database ownership
permissions, and and gave server access to a tiny team with 2fa. The way 8
figured it, if someone somehow rooted the box we were screwed anyway.

For an internal database, this seemed sufficient. For an external database,
I would highly recommend paid consulting security firms or hire people who
know to build an externally facing platform.

Thanks
Ben

On Wed, Dec 21, 2022, 4:39 PM Rainer Duffner <rainer@ultra-secure.de> wrote:

Show quoted text

Am 21.12.2022 um 22:34 schrieb Laurenz Albe <laurenz.albe@cybertec.at>:

There is no exact equivalent, but there is something similar and much
better: you can
authenticate the client with SSL client certificates:
https://www.postgresql.org/docs/current/auth-cert.html

Isn’t the wallet the part where the encryption keys are stored?

Indeed, one of the few remaining features that only Oracle (and of course
other commercial RDMSs) has seems to be full HSM support for TDE.

Rainer

#7Ron
ronljohnsonjr@gmail.com
In reply to: Benedict Holland (#6)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

If a hacker gets in with root access, they can copy /your/ (and my)
Postgresql database files (or, more easily, the backup files) off site,
restore them, and then have access to your database.  Not so much
TDE-encrypted databases, since the backups are encrypted too and you need
the key to decrypt them,

As for the Bad Things which happen if you lose the keys... well, *don't lose
the keys!!*

On 12/21/22 16:25, Benedict Holland wrote:

What would you be missing? You can encrypt databases. You can encrypt the
s3 buckets using kms. You can govern access via ssh Auth. When you do
backups, you can encrypt the tar.gz files or whatever format and store it
on s3. Same with the wal files. The fact that oracle charges for this is a
joke. Of course, you would need to ensure compliance with your opsec teams
and stuck with best security practices but it seems top to bottom
encryption is unrelated or tangentially related to the databases.

Also, if you lose the encryption keys for your backups then bad things
happen. I doubt what I did was production viable but I limited database
access to a handful of users, encrypted the disks, left the Wal files
unencrypted but mounted with read access for a single user, compressed
full backups with encryption and a password, generated sah keys for anyone
who needed service accounts to access the systems, enforced database
ownership permissions, and and gave server access to a tiny team with 2fa.
The way 8 figured it, if someone somehow rooted the box we were screwed
anyway.

For an internal database, this seemed sufficient. For an external
database, I would highly recommend paid consulting security firms or hire
people who know to build an externally facing platform.

Thanks
Ben

On Wed, Dec 21, 2022, 4:39 PM Rainer Duffner <rainer@ultra-secure.de> wrote:

Am 21.12.2022 um 22:34 schrieb Laurenz Albe <laurenz.albe@cybertec.at>:

There is no exact equivalent, but there is something similar and much
better: you can
authenticate the client with SSL client certificates:
https://www.postgresql.org/docs/current/auth-cert.html

Isn’t the wallet the part where the encryption keys are stored?

Indeed, one of the few remaining features that only Oracle (and of
course other commercial RDMSs) has seems to be full HSM support for TDE.

Rainer

--
Angular momentum makes the world go 'round.

#8Ron
ronljohnsonjr@gmail.com
In reply to: Benedict Holland (#6)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

And encrypting a tar.gz file presumes a pretty small database.  (The --jobs=
option was added to pg_dump/pg_restore for just that reason.)

On 12/21/22 16:25, Benedict Holland wrote:

What would you be missing? You can encrypt databases. You can encrypt the
s3 buckets using kms. You can govern access via ssh Auth. When you do
backups, you can encrypt the tar.gz files or whatever format and store it
on s3. Same with the wal files. The fact that oracle charges for this is a
joke. Of course, you would need to ensure compliance with your opsec teams
and stuck with best security practices but it seems top to bottom
encryption is unrelated or tangentially related to the databases.

Also, if you lose the encryption keys for your backups then bad things
happen. I doubt what I did was production viable but I limited database
access to a handful of users, encrypted the disks, left the Wal files
unencrypted but mounted with read access for a single user, compressed
full backups with encryption and a password, generated sah keys for anyone
who needed service accounts to access the systems, enforced database
ownership permissions, and and gave server access to a tiny team with 2fa.
The way 8 figured it, if someone somehow rooted the box we were screwed
anyway.

For an internal database, this seemed sufficient. For an external
database, I would highly recommend paid consulting security firms or hire
people who know to build an externally facing platform.

Thanks
Ben

On Wed, Dec 21, 2022, 4:39 PM Rainer Duffner <rainer@ultra-secure.de> wrote:

Am 21.12.2022 um 22:34 schrieb Laurenz Albe <laurenz.albe@cybertec.at>:

There is no exact equivalent, but there is something similar and much
better: you can
authenticate the client with SSL client certificates:
https://www.postgresql.org/docs/current/auth-cert.html

Isn’t the wallet the part where the encryption keys are stored?

Indeed, one of the few remaining features that only Oracle (and of
course other commercial RDMSs) has seems to be full HSM support for TDE.

Rainer

--
Angular momentum makes the world go 'round.

#9Benedict Holland
benedict.m.holland@gmail.com
In reply to: Ron (#8)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

Yea. I wasn't clear. I tar up the dump files as part of the command. Dont
lose your keys is awesome in theory. AWS comes with managed keys. The Wal
command will let you encrypt your Wal files too but if I were a hacker then
I would also copy ssh folders. It depends on security and business needs.
If I migrated this to a production environment we would have quite a bit
more infrastructure, likely a dedicated s3 location for Wal files, backups,
redundancy, k8's for nodes, a complex file server, and a bunch more stuff
that you pay people to set up, configure, and manage.

Like, does oracle give you something more? Probably. It's also a ton of
money and I mean a geuine ton. At that point, you also need security
audits, security protocols, requirements, backup and retention policies,
and redundancy key locations. If someone has root, I don't know how they
also don't have your encryption keys. Maybe they don't on a USB but then
th3 USB breaks or gets lost. Unencrypted Wal files on an RW partition with
a single user able to read or write along with nightly encrypted pgdump
might meet security needs. Or not. But that is true about anything. I have
never set up a credit card database. I assume those are locked down way
more than I ever will lock down a system.

On Wed, Dec 21, 2022, 6:13 PM Ron <ronljohnsonjr@gmail.com> wrote:

Show quoted text

And encrypting a tar.gz file presumes a pretty small database. (The
--jobs= option was added to pg_dump/pg_restore for just that reason.)

On 12/21/22 16:25, Benedict Holland wrote:

What would you be missing? You can encrypt databases. You can encrypt the
s3 buckets using kms. You can govern access via ssh Auth. When you do
backups, you can encrypt the tar.gz files or whatever format and store it
on s3. Same with the wal files. The fact that oracle charges for this is a
joke. Of course, you would need to ensure compliance with your opsec teams
and stuck with best security practices but it seems top to bottom
encryption is unrelated or tangentially related to the databases.

Also, if you lose the encryption keys for your backups then bad things
happen. I doubt what I did was production viable but I limited database
access to a handful of users, encrypted the disks, left the Wal files
unencrypted but mounted with read access for a single user, compressed full
backups with encryption and a password, generated sah keys for anyone who
needed service accounts to access the systems, enforced database ownership
permissions, and and gave server access to a tiny team with 2fa. The way 8
figured it, if someone somehow rooted the box we were screwed anyway.

For an internal database, this seemed sufficient. For an external
database, I would highly recommend paid consulting security firms or hire
people who know to build an externally facing platform.

Thanks
Ben

On Wed, Dec 21, 2022, 4:39 PM Rainer Duffner <rainer@ultra-secure.de>
wrote:

Am 21.12.2022 um 22:34 schrieb Laurenz Albe <laurenz.albe@cybertec.at>:

There is no exact equivalent, but there is something similar and much
better: you can
authenticate the client with SSL client certificates:
https://www.postgresql.org/docs/current/auth-cert.html

Isn’t the wallet the part where the encryption keys are stored?

Indeed, one of the few remaining features that only Oracle (and of course
other commercial RDMSs) has seems to be full HSM support for TDE.

Rainer

--
Angular momentum makes the world go 'round.

#10Rainer Duffner
rainer@ultra-secure.de
In reply to: Benedict Holland (#9)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

Am 22.12.2022 um 00:57 schrieb Benedict Holland <benedict.m.holland@gmail.com>:

Like, does oracle give you something more? Probably. It's also a ton of money and I mean a geuine ton. At that point, you also need security audits, security protocols, requirements, backup and retention policies, and redundancy key locations. If someone has root, I don't know how they also don't have your encryption keys.

They are not on the same box. They are in a HSM. A dedicated piece of tamper-proof hardware that stores secrets (keys).
The Oracle-server needs to talk to the HSM to get the keys.

This is not a low-budget setup (well, it’s Oracle…) - rather, it’s for when the data is really very valuable so that the cost for redundant HSMs, Oracle, Data Guard etc.pp. is still lower than the value of the data.

OP works for an outfit that typically does outsourcing for these kinds of clients.

It’s all about having more degrees of separation between different functions, so you don’t have to trust the single, Dennis-Nedry-type of admin to not sell the information in the database to the highest bidder.

#11Peter J. Holzer
hjp-pgsql@hjp.at
In reply to: Rainer Duffner (#10)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

On 2022-12-22 09:17:18 +0100, Rainer Duffner wrote:

Am 22.12.2022 um 00:57 schrieb Benedict Holland <
benedict.m.holland@gmail.com>:

If someone has root, I don't know how they also don't have your
encryption keys.

They are not on the same box. They are in a HSM. A dedicated piece of
tamper-proof hardware that stores secrets (keys).
The Oracle-server needs to talk to the HSM to get the keys.

If the hacker has root access: What prevents them from talking to the
HSM?

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

#12Rainer Duffner
rainer@ultra-secure.de
In reply to: Peter J. Holzer (#11)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

Am 22.12.2022 um 10:46 schrieb Peter J. Holzer <hjp-pgsql@hjp.at>:

If the hacker has root access: What prevents them from talking to the
HSM?

I wasn’t involved in setting it up here, but AFAIK you need to „enroll“ the client to the HSM.

That is a one-time process that requires HSM credentials (via certificates and pass-phrases).

Then, that client can talk to the HSM.

The HSM-client is (or should be) engineered in such a way that you can’t extract the encryption-secret easily.

I am not sure, but IIRC, you should not even be able to clone the VM without the HSM noticing or the clone not working at all to begin with (for lack of enrollment). Though most production databases are too large to just „clone“.

Maybe someone who knows more about this subject can chime in before I make a fool of myself?
;-)

Rainer

#13Peter J. Holzer
hjp-pgsql@hjp.at
In reply to: Rainer Duffner (#12)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

On 2022-12-22 11:15:57 +0100, Rainer Duffner wrote:

Am 22.12.2022 um 10:46 schrieb Peter J. Holzer <hjp-pgsql@hjp.at>:

If the hacker has root access: What prevents them from talking to the
HSM?

I wasn’t involved in setting it up here, but AFAIK you need to „enroll“ the
client to the HSM.

That is a one-time process that requires HSM credentials (via certificates and
pass-phrases).

Then, that client can talk to the HSM.

Which means that some sort of access-token is stored on the client.

So what prevents a hacker from using that access token?

The HSM-client is (or should be) engineered in such a way that you can’t
extract the encryption-secret easily.

Security by obscurity? Just hope that nobody figures out how that access
token is stored? That doesn't seem like a good strategy against
high-level threats.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

#14Chetan Kosanam
chetan.kosanam@tcs.com
In reply to: Chetan Kosanam (#1)
Regd. the Query w.r.t Alternative functionalities from Oracle  PostgreSQL (Oracle to PostgreSQL database migration)

TCS Confidential

Hi Support@ PostgreSQL Team,

Greetings !!

We are operating within one of the AWS business units of TCS. Our team is working on the Database migration from Oracle(on Amazon EC2) to PostgreSQL. The reason for this e-mailer is to seek your earnest required support from you on the Alternative functionalities from Oracle --> PostgreSQL while migrating the Oracle database to PostgreSQL.

S. No.
Oracle functionalities
PostgreSQL Equivalent
1
dbms_lob . --> ( createtemporary , OPEN , lob_readwrite , getlength , writeappend , SUBSTR )
Need the respective equivalent for the Oracle functionalities present in the adjoining column
2
dbms_sql
3
dbms_utility
4
utl_http.begin_request
5
DBMS_LDAP
6
UTL_RAW . --> ( cast_to_varchar2 , LENGTH , cast_to_raw )

In case we don’t have any exact equivalent, please advise on the methodology to get the needful done.
Thanks & Regards,
Chetan Kosanam
TCS, HYDERABAD
Contact : 9502753544
Mailto : chetan.kosanam@tcs.com

TCS Confidential
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

#15Adrian Klaver
adrian.klaver@aklaver.com
In reply to: Chetan Kosanam (#14)
Re: Regd. the Query w.r.t Alternative functionalities from Oracle  PostgreSQL (Oracle to PostgreSQL database migration)

On 12/23/22 01:37, Chetan Kosanam wrote:

TCS Confidential

Hi *Support*@ *PostgreSQL* Team,

*Greetings* *!!*

**

**We are operating within one of the /AWS business/ units of *TCS*. Our
team is working on the *Database migration from Oracle(on Amazon EC2) to
PostgreSQL*. The reason for this e-mailer is to seek your earnest
required support from you on the *Alternative functionalities from
Oracle **à PostgreSQL* while migrating the Oracle database to PostgreSQL.

See here:

https://www.postgresql.org/support/professional_support/

--
Adrian Klaver
adrian.klaver@aklaver.com

#16rob stone
floriparob@tpg.com.au
In reply to: Adrian Klaver (#15)
Re: Regd. the Query w.r.t Alternative functionalities from Oracle  PostgreSQL (Oracle to PostgreSQL database migration)

On Wed, 2022-12-28 at 09:45 -0800, Adrian Klaver wrote:

On 12/23/22 01:37, Chetan Kosanam wrote:

TCS Confidential

See here:

https://www.postgresql.org/support/professional_support/

Also there is ora2pg. See https://ora2pg.darold.net/

#17Ron
ronljohnsonjr@gmail.com
In reply to: rob stone (#16)
Re: Regd. the Query w.r.t Alternative functionalities from Oracle  PostgreSQL (Oracle to PostgreSQL database migration)

On 12/28/22 20:15, rob stone wrote:

On Wed, 2022-12-28 at 09:45 -0800, Adrian Klaver wrote:

On 12/23/22 01:37, Chetan Kosanam wrote:

TCS Confidential

See here:

https://www.postgresql.org/support/professional_support/

Also there is ora2pg. See https://ora2pg.darold.net/

That does a great job at data conversion.  Not sure about functionality
conversion.

--
Born in Arizona, moved to Babylonia.

#18Bruce Momjian
bruce@momjian.us
In reply to: Rainer Duffner (#12)
Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

On Thu, Dec 22, 2022 at 11:15:57AM +0100, Rainer Duffner wrote:

I wasn’t involved in setting it up here, but AFAIK you need to „enroll“ the
client to the HSM.

That is a one-time process that requires HSM credentials (via certificates and
pass-phrases).

Then, that client can talk to the HSM.

The HSM-client is (or should be) engineered in such a way that you can’t
extract the encryption-secret easily.

I am not sure, but IIRC, you should not even be able to clone the VM without
the HSM noticing or the clone not working at all to begin with (for lack of
enrollment). Though most production databases are too large to just „clone“.

Maybe someone who knows more about this subject can chime in before I make a
fool of myself?

This wiki should help:

https://wiki.postgresql.org/wiki/Transparent_Data_Encryption

Also, the first two patches in this email are doc patches which explain
the benefits:

/messages/by-id/20210625212204.GA7256@momjian.us

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Embrace your flaws. They make you human, rather than perfect,
which you will never be.