Transparent Data Encryption

در نوشتاری که چندی قبل برای مبحث 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) کند(در لایه ذخیره سازی صرفا منظور است!!) همچنین این رمزنگاری اثری در برنامه کاربردی نخواهد گذاشت و بدون هیچ تغییری در کد برنامه قابل انجام می باشد.

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

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

مدیریت کلید

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

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

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

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

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

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

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

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:    

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

$ 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 oracle که شامل کلید رمز می باشد، باید در حالت 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=ALL ENCRYPTION_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 نسخه پشتیبان تهیه می شود(به صورت backup set)، اطلاعات encrypt شده ان دیگر در حالت رمزشده باقی نخواهند ماند و به صورت clear text در فایل قابل رویت می باشند و برای رمزنگاری در این سطح باید به طور جداگانه در rman تنظیماتی را اعمال کرد تا بکاپهای خروجی rman، به صورت encrypt ایجاد شوند.

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

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

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 خواهد بود:

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 شده، بسیار کندتر انجام می شود.

TDE و 12c

در این قسمت مطالبی در مورد ویژگی های جدید نسخه 12c در زمینه TDE اورده شده و نحوه پیاده سازی TDE در اوراکل 12c مورد بررسی قرار گرفته است همچنین تغییرات ساختاری دستورات و نیز نحوه استفاده از انها در CDB و data guard هم دیگر مطالبی هستند که به ان خواهیم پرداخت.

توجه! در نسخه 12c، بعضا از عبارت keystore هم به جای wallet استفاده می شود.

ایجاد و مدیریت keystore در 12c

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

مرحله اول: ابتدا باید wallet یا به عبارت دیگر keystore را ایجاد کرد که برای این کار باید مجوز ADMINISTER KEY MANAGEMENT و یا SYSKM را دارا بود و ضمنا دستور ایجاد oracle wallet در این نسخه به صورت زیر می باشد:

فرم کلی:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE ‘keystore_location’ IDENTIFIED BY software_keystore_password;

مثال:

SQL> administer key management create keystore ‘+DATA/wallet’ identified by “pass_usef” ;

keystore altered

نکته: اگر بانک مورد نظر از نوع CDB باشد، keystore باید در CDB$ROOT ایجاد شود و می توان ان را بین همه pdbها به اشتراک گذاشت.

مرحله دوم: در صورتی که keystore به صورت AUTO_LOGIN ایجاد نشده باشد، باید با هر بار راه اندازی مجدد بانک، به صورتی دستی در وضیعت open قرار بگیرد:

SQL>  ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY  “pass_usef”;

keystore altered.

البته برای فعال کردن ویژگی AUTO_LOGIN، می توان از دستور زیر استفاده کرد:

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE ‘+DATA/wallet’ IDENTIFIED BY “pass_usef”;

keystore altered.

بعد از اجرای این دستور، فایلی با عنوان cwallet.sso ایجاد خواهد شد و فیلد WALLET_TYPE در ویوی v$encryption_wallet برابر با AUTO LOGIN خواهد شد.

برای مشاهده وضیعت و مسیر فعلی wallet، می توان از ویوی V$ENCRYPTION_WALLET استفاده کرد که اگر مقدار فیلد status ان برابر با NOT_AVAILABLE باشد، به معنی ان است که wallet در این مسیر ایجاد نشده است.

col WRL_PARAMETER format a40

col STATUS  format a10

col  WALLET_TYPE format a10

select WRL_PARAMETER,STATUS,WALLET_TYPE  from v$encryption_wallet;

WRL_PARAMETER                            STATUS     WALLET_TYP

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

+DATA/wallet/                            OPEN       PASSWORD

نکته: در بانک CDB، برای اینکه در همه pdbها این فایل باز و قابل استفاده باشد، می توان از دستور زیر استفاده کرد(عبارت container=all):

SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY  IDENTIFIED BY pass_usef WITH BACKUP container=all;

keystore altered.

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

شکل کلی:

ADMINISTER KEY MANAGEMENT SET KEY [USING TAG ‘tag’] IDENTIFIED BY password [WITH BACKUP [USING ‘backup_identifier’]] [CONTAINER = ALL | CURRENT];

مثال:

SQL>administer key management set key  identified by pass_usef with backup ;

برای مشاهده encrypt key ایجاد شده، می توان از ویوی v$encryption_keys استفاده کرد:

select key_id from v$encryption_keys;

Aft2vgHukE/Mvy2S3fBTS3EAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

توجه! در محیط CDB، نیاز است تا این دستور تنها در cdb#root اجرا کرد:

SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY  IDENTIFIED BY pass_usef WITH BACKUP container=all;

با این دستور، وضیعت keystore در pdbها هم به صورت open در خواهد امد و از ان پس، قابلیت TDE در تمامی pdbها قابل استفاده می باشد:

sqlplus “sys/sys@pdb as sysdba”

SET LINESIZE 200

COLUMN wrl_parameter FORMAT A20

SELECT * FROM v$encryption_wallet;

WRL_TYPE             WRL_PARAMETER        STATUS          WALLET_TYPE  WALLET_OR FULLY_BAC     CON_ID

——————– ——————– —————————— ——————– ———                        ———  ———-

ASM                                       OPEN                           PASSWORD             SINGLE                                         NO         3

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

SELECT con_id, key_id FROM v$encryption_keys;

    CON_ID KEY_ID

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

         1 AYcr27IIV09Ov8pZCde2H9QAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

         3 AQ8EkCxifk8Kv788OBUljEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

توجه!: در صورت مواجه با خطای ORA-28374 می توان از پارامتر مخفی زیر استفاده نمود:

SQL> alter system set  “_db_discard_lost_masterkey”=true;

نکته 1: برای تغییر پسورد keystore می توان از دستور زیر استفاده کرد:

SQL>ADMINISTER KEY MANAGEMENT ALTER KEYSTORE PASSWORD IDENTIFIED BY “pass_usef” set “pass_usef2” WITH BACKUP ;

نکته 2: بستن keystore با دستور زیر قابل انجام می باشد:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY “pass_usef”;

نکته 3: برای تهیه بکاپ هم دستور زیر مفید می باشد:

ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING ‘bkp_keystore’ IDENTIFIED BY “pass_usef” to ‘/oracle’;

نکته 4: برای rekey کردن keystore، باید از دستور زیر کمک گرفت:

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY  IDENTIFIED BY pass_usef WITH BACKUP;

رمزنگاری انلاین tablespace در 12c

در قسمتهای قبلی مشاهده شد که در اوراکل 11g قابلیت رمزنگاری برای tablespaceهای موجود ممکن نمی باشد و در صورت لزوم می بایست ابتدا tablespaceای با این قابلیت را ایجاد کرد و سپس اطلاعات مورد نظر را به ان انتقال داد با ارائه اوراکل 12c، این قابلیت هم بوجود امد تا بدون سازماندهی مجدد، بتوان بصورت انلاین tablespace را به حالت encrypt منتقل کرد. این کار به سادگی و با کمک دستور زیر قابل انجام می باشد(به صورت انلاین):

SQL> alter tablespace non_tde encryption online using ‘aes192’ encrypt;

Tablespace altered.

پس از اجرای این دستور، خواهیم دید که دیتافایلهای جدیدی ایجاد می شوند و اطلاعات از دیتافایل قبلی به این دیتافایلهای منتقل می شوند و دیگر اطلاعات clear textای هم در انها قابل رویت نیست:

[root@hkm4 ~]#  strings /oracle/oradata/DB12/datafile/o1_mf_non_tde_f56nor3o_.dbf|grep USEF

[root@hkm4 ~]#

نکته: در اوراکل 12c می توان در سطح tablespace، هم rekey را انجام داد در صورتی که این قابلیت در اوراکل 11g وجود نداشت:

alter tablespace non_tde encryption online using ‘aes192’ REKEY;

رمزنگاری انلاین system tablespaceها

از دیگر ویژگی اوراکل 12c در زمینه TDE، امکان رمزنگاری انلاین tablespaceهای سیستمی ای چون system، sysaux و undo می باشد. دستور زیر، به صورت انلاین system tbs را به حالت encrypt خواهد برد:

SQL> alter tablespace SYSTEM ENCRYPTION ONLINE ENCRYPT;

Tablespace altered.

با رجوع به alert مربوط به این بانک، عملیات انجام شده را به صورت روشن تری خواهیم دید:

2018-01-08T16:30:55.918958+03:30

alter tablespace system  ENCRYPTION ONLINE encrypt

2018-01-08T16:30:55.920447+03:30

About to encrypt tablespace SYSTEM (tsn 0/0)

Rekeying datafile /oracle/oradata/DB12/datafile/o1_mf_system_f56tv3p5_.dbf (1) to /oracle/oradata/DB12/datafile/o1_mf_system_%u_.dbf

2018-01-08T16:31:04.175714+03:30

Rekey operation committed for file /oracle/oradata/DB12/datafile/o1_mf_system_f56tw7xg_.dbf

2018-01-08T16:31:06.181181+03:30

About to zero out original file “/oracle/oradata/DB12/datafile/o1_mf_system_f56tv3p5_.dbf”

2018-01-08T16:31:08.685585+03:30

Successfully zero’ed out original file “/oracle/oradata/DB12/datafile/o1_mf_system_f56tv3p5_.dbf”

Successfully deleted original file “/oracle/oradata/DB12/datafile/o1_mf_system_f56tv3p5_.dbf”

Completed rekey for tablespace SYSTEM (tsn 0/0) from key version 3 to 4.

Completed: alter tablespace system  ENCRYPTION ONLINE encrypt

همچنین می توان SYSAUX و UNDO را نیز بدین شکل encrypt کرد:

SQL> alter tablespace SYSAUX ENCRYPTION ONLINE ENCRYPT;

Tablespace altered.

SQL> alter tablespace UNDOTBS1 ENCRYPTION ONLINE ENCRYPT;

Tablespace altered.

البته این قاعده برای temp tablespace مستثنی می باشد و برای encrypt کردن ان باید، ابتدا ان را حذف کرد و مجددا ایجاد نمود.

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

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

mv /oracle/12c/network/admin/wallet  /oracle/12c/network/admin/wallet2

SQL> startup force;

ORACLE instance started.

Total System Global Area 3791650816 bytes

Fixed Size                  8627488 bytes

Variable Size             939526880 bytes

Database Buffers         2835349504 bytes

Redo Buffers                8146944 bytes

Database mounted.

ORA-28365: wallet is not open

همانطور که می بینید، بانک با خطای ORA-28365 متوقف شده و امکان باز شدن ان بدون فایل wallet ممکن نخواهد بود. همچنین در فایل alert، خطای مربوطه قابل مشاهده می باشد:

tail -f /oracle/diag/rdbms/db12/db12/trace/alert_db12.log

Slave encountered ORA-10388 exception during crash recovery

2018-01-08T16:17:14.762059+03:30

Aborting crash recovery due to error 28365

2018-01-08T16:17:14.762266+03:30

Errors in file /oracle/diag/rdbms/db12/db12/trace/db12_ora_32043.trc:

ORA-28365: wallet is not open

2018-01-08T16:17:14.762966+03:30

Errors in file /oracle/diag/rdbms/db12/db12/trace/db12_ora_32043.trc:

ORA-28365: wallet is not open

ORA-28365 signalled during: ALTER DATABASE OPEN…

نتیجه انکه، باید در تهیه بکاپ از فایل wallet بسیار کوشا بود! هر چند برای رمزنگاری system tbsها توجیه چندانی وجود ندارد!!!

keystore و data guard

راه اندازی دیتاگارد برای بانکی که از فضای ASM برای ذخیره سازی keystore استفاده می کند نیاز به مراحل اضافه ای دارد که در این قسمت توضیح داده شده است.

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

orapki wallet create -wallet /oracle/

Oracle PKI Tool : Version 12.2.0.1.0

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

Enter password:  

Enter password again:  

Operation is successfully completed.

سپس با دستور زیر، این فایل را با keystore مربوط به بانک اصلی ادغام می کنیم تا محتوای keystore اصلی بانک، در این keystore موقت قرار بگیرد:

SQL>administer key management merge keystore ‘+DATA/wallet/’ identified by “pass_usef” INTO existing keystore ‘/oracle/’ identified by “pass_usef” with backup;

keystore altered.

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

orapki wallet display -wallet /oracle/ewallet.p12

Oracle PKI Tool : Version 12.2.0.1.0

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

Enter wallet password:  

Requested Certificates:

User Certificates:

Oracle Secret Store entries:

ORACLE.SECURITY.DB.ENCRYPTION.AQ8EkCxifk8Kv788OBUljEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

ORACLE.SECURITY.DB.ENCRYPTION.AYcr27IIV09Ov8pZCde2H9QAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY

ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY.62540D8EB366704FE0530488200A04D0

ORACLE.SECURITY.ID.ENCRYPTION.

ORACLE.SECURITY.KB.ENCRYPTION.

ORACLE.SECURITY.KM.ENCRYPTION.AQ8EkCxifk8Kv788OBUljEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

ORACLE.SECURITY.KM.ENCRYPTION.AYcr27IIV09Ov8pZCde2H9QAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Trusted Certificates:

این فایل را به سرور stb منتقل می کنیم و سپس با اتصال به بانک stb، walletای را ایجاد می کنیم:

SQL> administer key management create keystore ‘+DATA/stbwallet’ identified by “pass_usef” ;

keystore altered.

وضیعت این keystore را در حالت open قرار می دهیم:

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY  “pass_usef” container=all;

keystore altered.

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

SQL> administer key management merge keystore ‘/oracle’ identified by “pass_usef” INTO existing keystore ‘+DATA/stbwallet’ identified by “pass_usef” with backup;

keystore altered.

با انجام این مراحل، می توان از داده های encrypt شده در سمت دیتاگارد هم بهره گرفت.

 

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد.