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(at)gmail(dot)com> wrote:

> 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(at)ultra-secure(dot)de>
> wrote:
>
>>
>>
>> Am 21.12.2022 um 22:34 schrieb Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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.
>