در نوشتاری که چندی قبل برای مبحث database vault ارائه شد، چگونگی جلوگیری از دسترسی و یا اصلاح اطلاعات خاص توسط مدیران بانکهای اطلاعاتی و یا افرادی که در سطوح بالایی به بانک اطلاعاتی دسترسی دارند، مورد بررسی قرار گرفته شد همانطور که در ان مطلب بیان کردیم، database vault تنها برای کنترل دسترسی در سطح بانک اطلاعاتی کاربرد دارد و برای جلوگیری از دسترسی غیر ایمن به اطلاعات در لایه سیستم عامل، باید از روشهای دیگری چون TDE استفاده کرد که در این نوشتار به این مهم خواهیم پرداخت.

زمانی که اطلاعاتی در بانک اطلاعاتی درج می شود، این اطلاعات بعد از انتقال از حافظه به دیتافایل، در لایه os قابل مشاهده می باشد(البته با کمک ابزار و یا دستور) و هر فردی که در سطح سیستم عامل دسترسی بالایی داشته باشد، خواهد توانست این اطلاعات را به صورت هر چند ناخوانا مشاهده کند. مثال زیر را ببینید:

مثال: tablespaceای را بدون هیچگونه تنظیمات رمزنگاری ایجاد می کنیم:

SQL> create tablespace non_tde datafile ‘/oracle/oradata/db11g/non_tde1.dbf’ size 100m;

Tablespace created.

جدولی را به این tablespace اضافه می کنیم:

SQL> create table usef.test_table (desc1 varchar2(99)) tablespace non_tde;

Table created.

اطلاعاتی را در جدول درج می کنیم:

SQL> insert into usef.test_table values(‘I AM A DBA’);

1 row created.

SQL> commit;

Commit complete.

برای انکه از ثبت این اطلاعات از حافظه به دیتافایل مطمئن شویم، از دستور زیر استفاده می کنیم:

SQL> alter system flush buffer_cache;

System altered.

با جستجویی در دیتافایل(در سطح سیستم عامل)، اطلاعات ثبت شده را مشاهده خواهیم کرد:

strings  /oracle/oradata/db11g/non_tde1.dbf |grep “I AM A DBA”

I AM A DBA

همانطور که مشاهده می کنید، اطلاعات درج شده در جدول test_table با کمک دستور strings قابل رویت می باشد. در ادامه با معرفی ویژگی TDE، نشان خواهیم داد که چگونه می توان از نمایش این اطلاعات در لایه سیستم عامل جلوگیری کرد و به عبارتی دیگر، چگونه می توان این اطلاعات را رمزنگاری کرد.

رمزنگاری با کمک TDE

این ویژگی که از اوراکل 10g ارائه شد، قادر است اطلاعات مورد نظر را در تمامی سطوح از قبیل datafile،  archive log، redo log و … رمزنگاری(encrypt) کند(صرفا در لایه storage) همچنین این نوع از رمزنگاری، اثری بر روی applicationها نخواهد گذاشت و بدون هیچ تغییری در کد برنامه، قابل انجام می باشد.

نکته: باید توجه داشت که این ویژگی در لایه شبکه اثرگذار نخواهد بود و به طور پیش فرض، اطلاعات در لایه network به صورت clear text دیده خواهند شد.

رمزنگاری با ویژگی TDE با کمک دو کلید و یک الگوریتم انجام می شود که در ادامه به طور مختصر مطالبی را در مورد هر کدام از انها ارائه خواهیم کرد.

مدیریت کلید

TDE در دولایه master key و table key(یا tablespace key) از کلید استفاده می کند به طوری که به ازای هر بانک، تنها از یک کلید به عنوان master key استفاده خواهد شد و به ازای هر جدول و یا هر tablespace هم به صورت جداگانه از یک کلید استفاده می شود.

master key کلیدی است که در بیرون از بانک اطلاعاتی ذخیره می شود و به دو نوع سخت افزاری( Hardware Security Module (HSM و نرم افزاری(wallet) قابلیت نگهداری دارد که در این نوشتار تنها به نوع نرم افزاری ان که wallet می باشد خواهیم پرداخت.

در مورد table key، در زمان شرح چگونگی پیاده سازی TDE مطالبی را ارائه خواهیم کرد و در این قسمت صرفا به بررسی کیفیت و مدیریت oracle wallet خواهیم پرداخت.

ایجاد و مدیریت wallet

همانطور که در قسمت قبل بیان شد، Oracle wallet فایلی است که کلید اصلی(MASTER KEY) کنونی و گذشته بانک در ان قرار خواهد گرفت و در صورت حذف این فایل، اطلاعات رمزنگاری شده، قابل استفاده نخواهند بود پس برای هر گونه استفاده از ویژگی TDE، این فایل باید موجود و در حالت open قرار داشته باشد.

ایجاد و مدیریت فایل wallet در سه مرحله قابل انجام است:

مرحله اول: ابتدا باید مسیری که قرار است این فایل در ان ایجاد شود را در فایل sqlnet.ora تعیین کرد و سپس فایل WALLET را ایجاد نمود:

mkdir -p /oracle/11g/network/admin/wallet_tde

vi /oracle/11g/network/admin/sqlnet.ora

ENCRYPTION_WALLET_LOCATION =(SOURCE=(METHOD=file)(METHOD_DATA= (DIRECTORY=/oracle/11g/network/admin/wallet_tde)))

نکته 1: در صورت عدم تنظیم فایل sqlnet.ora، مسیر پیش فرض فایل wallet، به صورت زیر می باشد:

$ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet

نکته 2: اگر چندین بانک اطلاعاتی به صورت همزمان از یک فایل sqlnet.ora استفاده می کنند، می توان محتوای فایل sqlnet.ora را به صورت زیر تغییر داد:

(DIRECTORY=/etc/ORACLE/WALLETS/$ORACLE_SID/)

نکته 3: برای ایجاد و مدیریت فایل wallet، علاوه بر sqlplus، می توان از ابزارهای دیگری چون owm و orapki هم استفاده کرد که در اینجا بیشتر از ابزار sqlplus استفاده می کنیم.

برای ایجاد فایل wallet در مسیر تعیین شده، ابتدا باید به بانک متصل شد و پس از آن، دستور زیر را وارد کرد:

sqlplus “/as sysdba”

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY “usef_pass”;

System altered.

البته این کار با استفاده از دستور orapki هم به صورت زیر قابل انجام است:

[oracle@hkm6 ~]$ orapki wallet create -wallet /oracle/11g/network/admin/wallet_tde

Oracle PKI Tool : Version 11.2.0.4.0 – Production

Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.

Enter password:          

Enter password again:    

بعد از اجرای دستور orapki، با رجوع به مسیر تعیین شده، خواهیم دید که فایل جدیدی در این مسیر ایجاد شده است:

$ cd /oracle/11g/network/admin/wallet_tde

$ ls -l

-rw-r–r– 1 oracle oinstall 2845 Dec 24 13:35 ewallet.p12

همچنین با این دستور، فایل walletای با پسورد usef_pass ایجاد خواهد شد که این پسورد را می توان به دو روش زیر تغییر داد.

روش اول: با کمک sqlplus:

ALTER SYSTEM SET ENCRYPTION KEY “new password” IDENTIFIED BY “old password”;

روش دوم: با کمک orapki:

 [oracle@hkm6 ~]$ orapki wallet change_pwd -wallet /oracle/11g/network/admin/wallet_tde

Oracle PKI Tool : Version 11.2.0.4.0 – Production

Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:          

New password:

Enter wallet password:          

مرحله دوم: برای استفاده از wallet باید ان را در حالت open قرار داد:

ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY “usef”;

System altered.

همچنین برای تعیین نوع wallet، وضیعت فعلی و مسیر آن، می توان از ویوی V$ENCRYPTION_WALLET کمک گرفت:

col WRL_PARAMETER format a40

col WRL_TYPE format a9

col STATUS  format a6

SELECT * FROM V$ENCRYPTION_WALLET;

WRL_TYPE  WRL_PARAMETER                            STATUS

——— —————————————- ——

file      /oracle/11g/network/admin/wallet_tde     OPEN

در حالت عادی، وضیعت این فایل بصورت open باقی خواهد ماند و با هر بار افتادن بانک، این وضیعت در حالت close قرار خواهد گرفت همچنین دستور زیر هم سبب خواهد شد وضیعت این فایل به حالت close تغییر کند:

ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;

مجدد باید تاکید کرد که برای هرگونه استفاده از ویژگی TDE، باید این فایل در حالت open قرار داشته باشد پس باید به فکر چاره ای بود تا بعد از هر بار افتادن بانک، نیازی به اجرای دستی دستوری نباشد به همین جهت در صورتی که قصد داشته باشیم wallet به طور خودکار open شود، می توانیم از دستور orapki استفاده کنیم. دستور زیر سبب می شود تا فایل wallet ایجاد شده، بعد از هر راه اندازی(reset) بانک، به صورت auto login اجرا شود(در زمانی که بانک در وضیعت mount قرار دارد):

orapki wallet create -wallet /oracle/11g/network/admin/wallet_tde -auto_login

بعد از اجرای این دستور، فایلی با نام cwallet.sso در کنار فایل wallet ایجاد خواهد شد که بعد از هر بار راه اندازی مجدد بانک، مقدار ان تغییر می کند.

البته auto login نبودن فایل wallet می تواند بعضا به لحاظ امنیتی مفید باشد به این دلیل که بدون اطلاع از پسورد، این فایل قابل باز شدن نخواهد بود.

مرحله سوم: برای (rekey(Regenerating key کردن oracle wallet، می توان از دستور زیر استفاده کرد:

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY “pass_usef”;

با این کار، کلیدهای قبلی موجود در فایل کماکان حفظ خواهند شد و بالطبع استفاده از نسخه قدیمی این فایل برای کار با داده های encrypt شده فعلی، ممکن نخواهد بود. همچنین به اندازه ای که محدودیت فایل سیستم  به ما اجازه دهد، می توانیم wallet را rekey کنیم.

برای جلوگیری از پاک شدن oracle wallet در محیط لینوکس، می توان از دستور chattr استفاده کرد:

chattr +i ewallet.p12

البته برای عملیاتی چون rekey، باید قبلا این ویژگی را به صورت موقت غیرفعال کرد:

chattr -i ewallet.p12

چگونگی پیاده سازی TDE

رمزنگاری با کمک TDE، در سطح ستونهای یک جدول و نیز در سطحtablespace  قابل انجام می باشد که در ادامه در مورد کیفیت هر کدام از انها، مطالبی را اورده ایم.

TDE در سطح ستون

این سطح از رمزنگاری که از اوراکل 10gR2 در دسترس بود، قابلیت رمزنگاری را در سطح یک یا چند ستون از ستونهای یک جدول فراهم می کند به این صورت که داده بعد از insert، به حالت رمز درخواهد امد(encrypt) تا در دیسک به صورت رمزشده نگهداشته شود و در هنگام select هم از رمز خارج خواهد شد(decrypt) و به صورت clear text به کاربر نشان داده می شود(از همین نکته می توان نتیجه گرفت که این ویژگی در لایه شبکه بی اثر خواهد بود).

برای رمزنگاری در سطح ستون، برای هر جدول تنها یک کلید و یک الگوریتم خواهیم داشت که کلیدهای مربوط به هر جدول، در data dictionary ذخیره می شود و همچنین اسامی الگوریتمهای قابل استفاده در این زمینه به نامهای 3DES168، AES128، AES192 و AES256 می باشد که از این بین AES192 الگوریتم پیش فرض می باشد.

البته لازم به ذکر است که وجود master key برای استفاده از قابلیت TDE لازم و ضروری می باشد و به دلیل انکه در قسمت قبلی شاید به اندازه کافی مورد بررسی قرار گرفته است، مجدد به ان نمی پردازیم.

قبل از شروع رمزنگاری، مجددا باید تکرار کرد که wallet که شامل کلید رمز می باشد، باید در حالت open قرار داشته باشد:

SQL>  SELECT * FROM V$ENCRYPTION_WALLET;

WRL_TYPE  WRL_PARAMETER                            STATUS

——— —————————————- ——

file      /oracle/11g/network/admin/wallet_tde     OPEN

رمزنگاری در این سطح هم در زمان ساخت جدول و هم برای جداول موجود در بانک ممکن می باشد. دستور زیر، جدول test_table را به صورت encrypt شده و با الگوریتم 3DES168 ایجاد می کند:

SQL> create table usef.test_table (desc1 varchar2(99) encrypt using ‘3DES168’) tablespace tde;

در هنگام ساخت این جدول می توان برای جلوگیری از تکرار مقدار hash تولید شده برای فیلد desc1(در صورتی که مقدار ورودی برای این فیلد یکسان باشد)، از الگوریتم salt استفاده کرد که در صورت بکارگیری این الگوریتم، قبل از ایجاد مقدار hash، بصورت تصادفی عددی به مقدار ورودی اضافه خواهد شد و بعد از ان عدد hash تولید می شود از عوارض این الگوریتم، افزایش فضای مصرفی به اندازه 16 بایت و نیز کند شدن روند رمزنگاری خواهد بود.

در صورتی که بخواهیم باز بر پیچیدگی مقدار encrypt بیفزاییم، می توانیم از الگوریتم دیگری به نام mac هم استفاده کنیم که استفاده از ان هم باعث افزایش فضای مصرفی به اندازه 20 بایت خواهد شد.

همچنین در زمان ساخت جدول باید توجه داشت که برای ستونها مختلف یک جدول نمی توان از الگوریتمهای مختلفی استفاده کرد بلکه باید به ازای یک جدول، تنها از یک الگوریتم استفاده شود در غیر این صورت، با خطای زیر مواجه خواهیم شد:

ORA-28340: a different encryption algorithm has been chosen for the table

در ادامه سناریوی تست، برای بررسی اثر رمزنگاری بر روی ستون desc1، اطلاعاتی را در این جدول درج می کنیم:

SQL> insert into usef.test_table values(‘I AM A DBA’);

SQL> commit;

SQL> alter system flush buffer_cache;

مجدد با کمک دستور strings، محتوای دیتافایل را بررسی می کنیم که خروجی این بررسی نشان خواهد داد اطلاعات ثبت شده به صورت clear text در دیتافایل ذخیره نشده اند:

strings  /oracle/oradata/db11g/tde2.dbf

}|{z

DB11G

j52p;

K’Wi

?7qs

البته در خروجی دستور قبلی، اطلاعات clear text مربوط به tablespace می باشند و به این جدول مربوط نیستند!!!

در صورتی که قصد داشته باشیم اطلاعات یک ستون از جدولی که فعلا در بانک اطلاعاتی موجود است را به حالت رمز دراوریم(در سطح دیسک!!!!)، می توانیم از چنین دستوری استفاده کنیم:

alter table usef.tbl_tde MODIFY name encrypt no salt;

قبل از انجام این کار، باید در نظر داشت که اندازه مقدار انکریپت شده از اندازه نوع داده ستون بزرگ تر نشود. همچنین اطلاعات قبلی برای این ستون کماکان در حالت clear text دیده خواهند شد(در دیتافایل) تا زمانی که بلاکهای مربوطه بازنویسی شوند. برای برگرداندن وضیعت این فیلد از encrypt به non-encrypt، می توان از دستور زیر استفاده کرد:

ALTER TABLE usef.test_table MODIFY desc1 DECRYPT;

ویوی dba_encrypted_columns برای نمایش لیست جداولی که ستونهای encrypt شده دارند، قابل استفاده می باشد:

select  * from dba_encrypted_columns;

OWNER	TABLE_NAME	COLUMN_NAME	ENCRYPTION_ALG	SALT	INTEGRITY_ALG
USEF	TEST_TABLE	DESC1	3 Key Triple DES 168 bits key	YES	SHA-1

همچنین برای مشاهده لیست کلیدهای مربوط به جداول، باید به جدول سیستمی enc$ رجوع کرد:

select obj#,mkeyid,colklc  from sys.enc$ ;

OBJ#	MKEYID	COLKLC
73179	AQ8EkCxifk8Kv788OBUljEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA	4177414141414141414141414141414141414141414143646D4B37597333642B76316C686D376C7373774E5036415A70383663736B3358535534434F51417533716A316C4D342B35557A487554326162454A752B3272453D
73185	AQ8EkCxifk8Kv788OBUljEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA	4177414141414141414141414141414141414141414144377865526A394B49674455797041626C756E42726C6A3576504345496F6750426E797758534F634D326552314542694C75414A4A554F44754D76645A4E4D326F3D
73775	AQ8EkCxifk8Kv788OBUljEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA	417741414141414141414141414141414141414141414377462F55434E2B79432F333378594648643768666F3572785A67435658303333662B4B4F527A6964456E694C4A2B625446305877692F2F5969765877436334413D

به عنوان یک امتیاز این امکان برای dba وجود دارد تا هر چند وقت یکبار، این کلیدها را rekey کند در حین انجام این کار، امکان تغییر الگوریتم استفاده شده برای این ستون هم ممکن خواهد بود:

ALTER TABLE tbl_usef REKEY USING ‘3DES168’;

همچنین در حین انجام عملیات rekey می توان در مورد الگوریتم mac یا nomac و salt یا no salt هم نظر داد:

ALTER TABLE EMPLOYEE REKEY USING ‘3DES168’ ‘NOMAC’;

رمزنگاری در سطح ستون، محدودیتهایی را هم به همراه دارد که در ادامه نمونه ای از انها را ملاحظه خواهید کرد.

محدودیت اول: کاربر sys نباید مالک جدول باشد:

SQL> create table sys.test_table (desc1 varchar2(99) encrypt using ‘3DES168’) tablespace NON_TDE;

ORA-28336: cannot encrypt SYS owned objects

محدودیت دوم: ایندکسهای موجود بر روی این نوع از ستونها نمی توانند بصورت range scan  indexمورد دستیابی قرار بگیرند. البته این مشکل در حالت tablespace encryption وجود ندارد. برای مثال دو plan زیر را ببینید:

Plan اول نشان می دهد که به دلیل عدم استفاده از این ویژگی در جدول(رمزنگاری در سطح ستون)، اجرای پرس و جو با کمک index range scan انجام می شود:

create index usef.idx1 on usef.tbl_tde(name);

select * from usef.tbl_tde where name like ‘C%’

Id	Operation	Name	Rows	Bytes	Cost	Time
0	SELECT STATEMENT		9269	12021893	7695	00:01:33
1	. TABLE ACCESS BY INDEX ROWID	TBL_TDE	9269	12021893	7695	00:01:33
* 2	.. INDEX RANGE SCAN	IDX1	9269		52	00:00:01

در صورتی که plan دوم عکس این موضوع را نشان می دهد:

alter table usef.tbl_tde MODIFY name encrypt no salt;

select * from usef.tbl_tde where name like ‘C%’

Id	Operation	Name	Rows	Bytes	Cost	Time
0	SELECT STATEMENT		5462	7269922	11701	00:02:21
* 1	. TABLE ACCESS FULL	TBL_TDE	5462	7269922	11701	00:02:21

محدودیت سوم: تنها ایندکسهای B-tree توسط این نوع از ستونها پشتیبانی می شوند:

SQL> create BITMAP index usef.idx1 on usef.test_table(desc1);

ORA-28337: the specified index may not be defined on an encrypted column

محدودیت چهارم: یکی دیگر از محدودیتها در مورد کلید خارجی مطرح می شود:

create table usef.parent(a number primary key ,b number encrypt no salt unique );

create table usef.child(c number,b_fk ,CONSTRAINT b FOREIGN KEY (b_fk) REFERENCES usef.parent(b) ON DELETE CASCADE);

ORA-28335: referenced or referencing FK constraint column cannot be encrypted

محدودیت پنجم: BFILE(External large objects): همانطور که می دانید، این نوع از اطلاعات در بیرون از بانک اطلاعاتی و در لایه سیستم عامل ذخیره می شوند و رمزنگاری ان در سطح بانک، توجیهی ندارد.

پنج محدودیت ذکر شده، تنها نمونه هایی از محدودیتهای رمزنگاری در سطح ستون بودند و محدودیتها دیگر، از قبیل exp/imp، transport tablespace و … هم برای رمزنگاری در این سطح وجود دارند.

TDE در سطح tablespace

برای انکه اطلاعات تمامی دیتافایلهای یک tablespace به صورت رمز شده نگهداری شوند، نیاز است تا از ویژگی TDE در سطحtablespace  استفاده کرد. در زیر نمونه ای از ساخت tablespace با کمک ویژگی TDE اورده شده است:

CREATE TABLESPACE tde_tbs datafile ‘/oracle/oradata/db11g/tde_tbs1’ size 10m ENCRYPTION USING ‘3DES168’ DEFAULT STORAGE (ENCRYPT);

با ساخت tablespace به کمک این ویژگی، دیگر اطلاعات به صورت clear text قابل مشاهده نخواهند بود:

strings /oracle/oradata/db11g/tde_tbs1

JEIi6

l!^.

&x;|

N21sE

البته استفاده از این ویژگی تنها در زمان ساخت tablespace ممکن می باشد و نمی توان tablespace را بعد از ایجاد، به حالت رمزشده منتقل کرد(در اوراکل 11g):

SQL> alter tablespace SYSAUX ENCRYPTION ONLINE ENCRYPT;

ORA-02142: missing or invalid ALTER TABLESPACE option

برای مشاهده لیست tablespaceهای encrypt شده، می توان از ویوی dba_tablespaces استفاده کرد:

SQL>  SELECT tablespace_name, encrypted, status FROM dba_tablespaces where encrypted =’YES’;

TABLESPACE_NAME     ENC STATUS

—————————— — ———

TDE_TBS                  YES   ONLINE

همچنین با کمک دستور زیر، اسامی tablespaceهای رمزنگاری شده به همراه الگوریتم رمزنگاری آنها، نمایش داده می شود:

SELECT t.name , e.encryptionalg , e.encryptedts FROM v$tablespace t , v$encrypted_tablespaces e WHERE t.ts# = e.ts#;

NAME                           ENCRYPT ENC

—————————— ——- —

TDE_TBS                        3DES168 YES

برخلاف رمزنگاری بر اساس ستون، در این نوع از رمزنگاری، کلید در هدر دیتافایلهای tablespace مربوطه ذخیره می شود و همچنین امکان rekey کردن ان وجود ندارد(در اوراکل 11g).

رمزنگاری در این سطح بسیاری از محدودیتهایی که رمزنگاری در سطح ستون وجود داشت را به همراه ندارد و حتی همه انواع داده را پشتیبانی می کند(البته جز bfile) ولی باز محدودیتهای در این سطح وجود دارد از قبیل موارد زیر(البته در اوراکل 11g):

1.امکان استفاده از این ویژگی برای temp tablespace و undo tablespace وجود ندارد.

2.tablespaceها سیستمی قابلیت رمزدار شدن ندارند.

3.استفاده از این ویژگی تنها در زمان ساخت tablespace کاربرد دارد و برای tablespaceهای موجود مفید نمی باشد.

4.همانطور که بیان شد، امکان rekey کردن در این سطح وجود ندارد.

5.و همچنین بسیار بدیهی و روشن است که نمی توان BFILE و external table را با این روش به حالت encrypt برد.

Export و Encryption

در صورتی که از داده encrypt شده دامپی تهیه کرده باشیم(از طریق expdp)، محتویات مربوط به این اطلاعات در دامپ بصورت clear text قابل رویت خواهند بود:

expdp directory=dir_enc dumpfile=enc_data.dmp tables=usef.test_table

Estimate in progress using BLOCKS method…

Processing object type TABLE_EXPORT/TABLE/TABLE_DATA

Total estimation using BLOCKS method: 64 KB

Processing object type TABLE_EXPORT/TABLE/TABLE

. . exported “USEF”.”TEST_TABLE”                         5.070 KB       4 rows

ORA-39173: Encrypted data has been stored unencrypted in dump file set.

Master table “SYS”.”SYS_EXPORT_TABLE_01″ successfully loaded/unloaded

******************************************************************************

Dump file set for SYS.SYS_EXPORT_TABLE_01 is:

  /oracle/enc_data.dmp

Job “SYS”.”SYS_EXPORT_TABLE_01″ completed with 1 error(s) at Sun Jan 7 13:04:19 2018 elapsed 0 00:00:10

همانطور که می بینید، تهیه دامپ با خطایی که به encryption مربوط می باشد، به اتمام رسیده است:

ORA-39173: Encrypted data has been stored unencrypted in dump file set.

دستور strings نشان می دهد که اطلاعات به صورت clear text در این دامپ ذخیره شده اند:

strings /oracle/enc_data.dmp|grep DBA

I AM A DBA

نکته: با اینکه اطلاعات به صورت encrypt شده در dump file ذخیره نشده اند، در هنگام import این جدول در بانکی دیگر، کماکان قرار است ستون رمزنگاری شده این جدول به صورت رمز شده باقی بماند، این نکته با مشاهده sqlfile مربوط به این دامپ، قابل مشاهده می باشد پس بالطبع باید در هنگام impdp، مراقب وضیعت wallet در بانک مقصد بود:

impdp directory=dir_enc dumpfile=enc_data.dmp full=y sqlfile=sssql.txt

— new object type path: TABLE_EXPORT/TABLE/TABLE

CREATE TABLE “USEF”.”TEST_TABLE”

   (                “DESC1” VARCHAR2(99 BYTE) ENCRYPT USING ‘3DES168’ ‘SHA-1’

   ) SEGMENT CREATION IMMEDIATE

…..

برای انکه اطلاعات(صرف نظر از وضیعت فعلی انها) در فایل دامپ بصورت encrypt شده ذخیره شوند، می توان از پارامترهای زیر در هنگام اجرای دستور expdp کمک گرفت:

ENCRYPTION: در چه سطحی encryption انجام شود؟ سطوح زیر قابل تعیین می باشند:

ALL, DATA_ONLY, ENCRYPTED_COLUMNS_ONLY, METADATA_ONLY , NONE

ENCRYPTION_ALGORITHM: الگوریتمی که برای encryption استفاده می شود، کدام یک از الگوریتمهای زیر باشد:

AES128, AES192 , AES256

AES128 الگوریتم پیش فرض می باشد.

ENCRYPTION_MODE: به دو حالت می توان دامپی را بصورت encryptشده ایجاد کرد که یکی با استفاده از روش پسورد می باشد و دیگری استفاده توامان پسورد و wallet خواهد بود که به این حالت دوم، dual گفته می شود.

ENCRYPTION_PASSWORD: پسوردی که برای این دامپ فایل تنظیم می شود.

expdp directory=dir_enc dumpfile=enc_data.dmp tables=usef.test_table ENCRYPTION=ALLENCRYPTION_ALGORITHM=AES192 ENCRYPTION_MODE=PASSWORD ENCRYPTION_PASSWORD=usef

Estimate in progress using BLOCKS method…

Processing object type TABLE_EXPORT/TABLE/TABLE_DATA

Total estimation using BLOCKS method: 64 KB

Processing object type TABLE_EXPORT/TABLE/TABLE

. . exported “USEF”.”TEST_TABLE”                         5.078 KB       4 rows

Master table “SYS”.”SYS_EXPORT_TABLE_01″ successfully loaded/unloaded

******************************************************************************

Dump file set for SYS.SYS_EXPORT_TABLE_01 is:

  /oracle/enc_data.dmp

Job “SYS”.”SYS_EXPORT_TABLE_01″ successfully completed at Sun Jan 7 13:21:18 2018 elapsed 0 00:00:03

 نکته: export سنتی قابلیت گرفتن دامپ از جداول encrypt شده را ندارد(exp/imp):

exp file=’/oracle/enc_data_org.dmp’ tables=usef.test_table

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Export done in US7ASCII character set and AL16UTF16 NCHAR character set

server uses WE8MSWIN1252 character set (possible charset conversion)

About to export specified tables via Conventional Path …

Current user changed to USEF

EXP-00107: Feature (COLUMN ENCRYPTION) of column DESC1 in table USEF.TEST_TABLE is not supported. The table will not be exported.

Export terminated successfully with warnings.

RMAN-Encrypted Backup

در زمان بکاپ گیری با ابزار RMAN، اطلاعاتی که به صورت encrypt شده در دیسک ذخیره شده اند، به صورت clear text در فایل بکاپ قرار خواهند گرفت و برای رمزنگاری اطلاعات در این سطح، مجددا باید تنظیماتی را در محیط RMAN اعمال کرد.

تهیه بکاپ امن در محیط RMAN، با کمک پسورد، wallet و یا هر دو آنها قابل انجام است که در این نوشته، صرفا روش انجام کار را با کمک پسورد نشان خواهیم داد البته روش استفاده از wallet هم نکته خاصی در این زمینه ندارد و صرفا با فعال کردن encryption و باز بودن wallet، به راحتی قابل انجام است.

برای بکاپ گیری امن با کمک پسورد، ابتدا باید وارد محیط rman شده و سپس encryption را به همراه تنظیم پسورد برای بانک فعال کنیم:

rman target /

Recovery Manager: Release 12.2.0.1.0 – Production on Mon Jan 15 17:02:38 2018

Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.

connected to target database: DB (DBID=1728771000)

– دستور زیر برای زمانی که بخواهیم از wallet کمک بگیریم، هم مفید خواهد بود:

RMAN>  CONFIGURE ENCRYPTION FOR DATABASE ON;

using target database control file instead of recovery catalog

new RMAN configuration parameters:

CONFIGURE ENCRYPTION FOR DATABASE ON;

new RMAN configuration parameters are successfully stored

-به عنوان مرحله دوم، پسورد مورد نظر را مشخص می کنیم:

RMAN> SET ENCRYPTION ON IDENTIFIED BY “usef_pass” only;

executing command: SET encryption

تعیین کلمه only در دستور بالا سبب خواهد شد تا بکاپ صرفا با کمک پسورد قابل انجام باشد.

نکته: تنظیمات تعیین شده با دستور configure، در سطح تمامی sessionها اعمال می شوند و دستور set هم صرفا در سطح session این تنظیمات را اعمال خواهد کرد البته دستور set، اولویت بالاتری نسبت به دستور configure دارد. به طور مثال اگر دو دستور زیر را در یک session اجرا کنیم، اولویت با دستور set خواهد بود:

RMAN> CONFIGURE ENCRYPTION FOR DATABASE OFF;

RMAN> SET ENCRYPTION ON;

در مرحله بعد در صورت نیاز، الگوریتم مورد نظر را تنظیم می کنیم:

RMAN>  SET ENCRYPTION ALGORITHM ‘AES128’;

executing command: SET encryption

RMAN> SHOW ENCRYPTION ALGORITHM;

RMAN configuration parameters for database with db_unique_name DB are:

CONFIGURE ENCRYPTION ALGORITHM ‘AES128’; # default

همچنین می توان با دستور زیر، حکم کرد تا بکاپ برای tablespace مشخصی بصورت امن و encrypt شده تهیه شود:

RMAN> CONFIGURE ENCRYPTION FOR TABLESPACE tde_tbs ON;

Tablespace TDE_TBS will be encrypted in future backup sets

new RMAN configuration parameters are successfully stored

و یا یک tablespace خاص را از بکاپ گیری امن، استثنا کرد:

RMAN> configure encryption for tablespace users off;

همچنین می توان با دستور زیر، بالجبار هرگونه بکاپ گیری را بصورت امن انجام داد:

RMAN> configure encryption for database on;

به عنوان مثال، از یکی از tablespaceها، بکاپ می گیریم:

RMAN> backup tablespace tde_tbs;

Starting backup at 15-JAN-18

using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00017 name=/oracle/oradata/DB/tde1.dbf

channel ORA_DISK_1: starting piece 1 at 15-JAN-18

channel ORA_DISK_1: finished piece 1 at 15-JAN-18

piece handle=/oracle/12c/dbs/0isoomn0_1_1 tag=TAG20180115T181535 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 15-JAN-18

برای بازگرداند این بکاپ باید قبل از دستور restore tablespace، پسورد آن را تنظیم کرد:

RMAN> SET DECRYPTION IDENTIFIED BY “usef_pass”

RMAN> restore tablespace users;

Starting restore at 15-JAN-18

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00007 to /oracle/oradata/DB/datafile/o1_mf_users_f58w70rg_.dbf

channel ORA_DISK_1: reading from backup piece /oracle/12c/dbs/0isoomn0_1_1

channel ORA_DISK_1: piece handle=/oracle/12c/dbs/0isoomn0_1_1 tag= TAG20180115T181535

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

Finished restore at 15-JAN-18

TDE و performance

همانطور که می دانید طبق معمول، هر مسئله امنیتی می تواند بر روی کارایی سرویس دهی اثر منفی و مخرب داشته باشد و TDE هم از این قائده مستثنی نیست.تکه کد زیر مقایسه ای را بین سرعت عملیات insert و select در دو حالت encrypt و non-encrypt را نشان میدهد.

CREATE TABLE usef.non_tde_tbl (

  id    NUMBER(10),

  name  VARCHAR2(80)

);

CREATE TABLE usef.tbl_tde (

  id    NUMBER(10),

  name  VARCHAR2(80) ENCRYPT

);

DECLARE

  l_loops  NUMBER := 100000;

  l_name   VARCHAR2(80);

  l_start  NUMBER;

BEGIN

  EXECUTE IMMEDIATE ‘TRUNCATE TABLE non_tde_tbl’;

  EXECUTE IMMEDIATE ‘TRUNCATE TABLE tbl_tde’;

  l_start := DBMS_UTILITY.get_time;

  FOR i IN 1 .. l_loops LOOP

    INSERT INTO non_tde_tbl (id, name)

    VALUES (i, ‘name for ‘ || i);

  END LOOP;

  DBMS_OUTPUT.put_line(‘Normal Insert   : ‘ || (DBMS_UTILITY.get_time – l_start));

  l_start := DBMS_UTILITY.get_time;

  FOR i IN 1 .. l_loops LOOP

    INSERT INTO tbl_tde (id, name)

    VALUES (i, ‘name for ‘ || i);

  END LOOP;

  DBMS_OUTPUT.put_line(‘Encrypted Insert: ‘ || (DBMS_UTILITY.get_time – l_start));

  l_start := DBMS_UTILITY.get_time;

  FOR i IN 1 .. l_loops LOOP

    SELECT name

    INTO   l_name

    FROM   non_tde_tbl

    WHERE  id = i;

  END LOOP;

  DBMS_OUTPUT.put_line(‘Normal Query    : ‘ || (DBMS_UTILITY.get_time – l_start));

  l_start := DBMS_UTILITY.get_time;

  FOR i IN 1 .. l_loops LOOP

    SELECT name

    INTO   l_name

    FROM   tbl_tde

    WHERE  id = i;

  END LOOP;

  DBMS_OUTPUT.put_line(‘Decrypted Query : ‘ || (DBMS_UTILITY.get_time – l_start));

END;

/

زمان و سرعت اجرای این قطعه کد، به متغیرهای زیادی وابسته است(از قبیل منابع سخت افزاری ، بارکاری سیستم و …) با در نظر داشتن این نکته، نتیجه اجرای این قطعه کد در یک محیط تستی خاص، به صورت زیر بوده است:

Normal Insert   : 271

Encrypted Insert: 481

Normal Query    : 17256

Decrypted Query : 22467

همانطور که خروجی نشان می دهد، سرعت select و insert برای داده های encrypt شده، بسیار کندتر انجام می شود.