4 ms·

From the comments, Oracle told them to enable encryption to solve a problem with backups. They did, and they kept the master key to the Oracle wallet. The Oracl

From the comments, Oracle told them to enable encryption to solve a problem with backups. They did, and they kept the master key to the Oracle wallet. The Oracle wallet is read only, they could never put something in it or fail to put something in it. The encryption system could and should have put encryption keys in it, but didn't. That's the Oracle failure. "Enabling Oracle encryption according to their instructions, failed to do what it should, and we lost access to all our servers and all our backups because of it". There's also a separate failure of administration on the client side of not practising working with encryption before using it in production, and not testing recovery and noticing the wallet was empty and the backups were unusable before it became a disaster, but the fact that it did become a disaster is a failure of Oracle's system.

gregd 8y ago
I'm not so sure why everyone is on-board with blaming Oracle out of the gate. From one of the OP's comments, "Oracle support told him, step by step, to encrypt the database, which happened ages ago and is the root of all of this." That wallet is the responsibility of whomever created it. Just because it's empty now, doesn't mean it's always been empty. In addition to that, what if the person who initially encrypted everything with TDE, used a local only wallet? This would explain why the ewallet.p12 file is empty. Oracle recommends that you store your master key in the ewallet.p12 file and not the cwallet.sso file, which is the auto-open file, but only on the workstation it was created on. There could have been multiple failures here with multiple parties and not just Oracle.
hotsauceror 8y ago
I'd be very curious to know what drove that decision to recommend enabling encryption in the first place. That seems like an odd way to "solve a problem with backups", particularly given the huge risks inherent to irresponsible key management. It almost sounds like their original support engineer proposed this as a fix during a ticket. Normally something like this is something you'd plan out, test, and do risk analysis with the business rather than have your on-call deploy it in the middle of the night because John Q. Engineer said you should.

gregd 8y ago

I'm not so sure why everyone is on-board with blaming Oracle out of the gate. From one of the OP's comments, "Oracle support told him, step by step, to encrypt the database, which happened ages ago and is the root of all of this." That wallet is the responsibility of whomever created it. Just because it's empty now, doesn't mean it's always been empty. In addition to that, what if the person who initially encrypted everything with TDE, used a local only wallet? This would explain why the ewallet.p12 file is empty. Oracle recommends that you store your master key in the ewallet.p12 file and not the cwallet.sso file, which is the auto-open file, but only on the workstation it was created on. There could have been multiple failures here with multiple parties and not just Oracle.

hotsauceror 8y ago

I'd be very curious to know what drove that decision to recommend enabling encryption in the first place. That seems like an odd way to "solve a problem with backups", particularly given the huge risks inherent to irresponsible key management. It almost sounds like their original support engineer proposed this as a fix during a ticket. Normally something like this is something you'd plan out, test, and do risk analysis with the business rather than have your on-call deploy it in the middle of the night because John Q. Engineer said you should.