Re: TDE for data previously unencrypted
From: Hemant K Chitale <hemantkchitale_at_gmail.com>
Date: Fri, 8 Mar 2013 02:19:13 +0800
Message-ID: <CAMNBsZsPDDPA0c6X5EpVbEX-y43jRBKSW7Z2OYbLri9kHETQdA_at_mail.gmail.com>
Since a MOVE (or a DROP or TRUNCATE) doesn't actually scrub the data; only marking the extents as "free".
You would have to actually create one or more tables and populate them with dummy data in an attempt to overwrite those blocks --- you still cannot control which blocks your new table(s) do overwrite. OR drop the old tablespace and datafile -- then you have to create new OS or datafiles(s) in an attempt to overwrite the blocks (whether filesystem or raw) at the OS level !
On Mar 8, 2013 2:10 AM, "Kevin Lidh" <kevin.lidh_at_gmail.com> wrote:
> I was researching TDE and set up a test in a small Oracle 11.2.0.3 database
> on RHEL. I created a table with two rows of "sensitive" unencrypted
> information. I opened up my datafile in a hex editor and found my data. I
> then created an encrypted tablespace and "alter table move" the table to
> the
> new tablespace and when I open that datafile, I can't find my data. But
> when I open the original datafile, I can still see sensitive information.
> I
> verified there were no extents remaining from that table. I understand how
> it happened but I'm wondering if there's another way to either move the
> data
> out which clears it or if there's a way to clear it after the fact. I did
> a
> coalesce for fun and now my two sensitive pieces are right next to each
> other in the unencrypted datafile.
>
> In our real world environment, the only method that comes to mind is to
> move
> all the remaining and unencrypted data to yet another tablespace and drop
> the original but that wouldn't be practical for some of our databases.
>
> Any ideas are surely welcome.
>
> Kevin
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
Date: Fri, 8 Mar 2013 02:19:13 +0800
Message-ID: <CAMNBsZsPDDPA0c6X5EpVbEX-y43jRBKSW7Z2OYbLri9kHETQdA_at_mail.gmail.com>
Since a MOVE (or a DROP or TRUNCATE) doesn't actually scrub the data; only marking the extents as "free".
You would have to actually create one or more tables and populate them with dummy data in an attempt to overwrite those blocks --- you still cannot control which blocks your new table(s) do overwrite. OR drop the old tablespace and datafile -- then you have to create new OS or datafiles(s) in an attempt to overwrite the blocks (whether filesystem or raw) at the OS level !
On Mar 8, 2013 2:10 AM, "Kevin Lidh" <kevin.lidh_at_gmail.com> wrote:
> I was researching TDE and set up a test in a small Oracle 11.2.0.3 database
> on RHEL. I created a table with two rows of "sensitive" unencrypted
> information. I opened up my datafile in a hex editor and found my data. I
> then created an encrypted tablespace and "alter table move" the table to
> the
> new tablespace and when I open that datafile, I can't find my data. But
> when I open the original datafile, I can still see sensitive information.
> I
> verified there were no extents remaining from that table. I understand how
> it happened but I'm wondering if there's another way to either move the
> data
> out which clears it or if there's a way to clear it after the fact. I did
> a
> coalesce for fun and now my two sensitive pieces are right next to each
> other in the unencrypted datafile.
>
> In our real world environment, the only method that comes to mind is to
> move
> all the remaining and unencrypted data to yet another tablespace and drop
> the original but that wouldn't be practical for some of our databases.
>
> Any ideas are surely welcome.
>
> Kevin
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Mar 07 2013 - 19:19:13 CET