Re: TDE for data previously unencrypted

  • From: Hemant K Chitale <hemantkchitale@xxxxxxxxx>
  • To: kevin.lidh@xxxxxxxxx
  • Date: Fri, 8 Mar 2013 02:19:13 +0800

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@xxxxxxxxx> 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
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>


--
//www.freelists.org/webpage/oracle-l


Other related posts: