جداول Immutable در اوراکل 19.11 و 21c

نویسنده مطلب: وحید یوسف زاده 3 Comments

جداول از نوع Immutable که اصطلاحا insert-only table هم نامیده می شوند، برای محافظت اطلاعات جدول از هرگونه دستکاری کاربرد دارند. در این نوع از جداول، درج اطلاعات جدید امکان پذیر است اما قابلیت بروزرسانی و اصلاح وجود ندارد و حداقل برای مدت زمان مشخصی، از حذف جدول و یا حذف اطلاعات آن ممانعت خواهند شد. این دسته از جداول در اوراکل 21.3 ارائه شدند و در نسخه 19.11 هم قابل استفاده هستند.

جداول Immutable را می توان از طریق دستور CREATE IMMUTABLE TABLE ایجاد کرد همچنین در زمان ایجاد این نوع از جداول، می توان در مورد حذف جدول(DROP) و حذف رکوردهای جدول(DELETE) سیاستهایی را اعمال کرد.

(بیشتر…)

اوراکل 19c – دو بهبود جزیی در TDE

نویسنده مطلب: وحید یوسف زاده Leave a comment

بهبود اول: از اوراکل 12cR2 می توان tablespaceهای سیستمی نظیر SYSTEM، SYSAUX، UNDO و حتی TEMP را در حالت encrypt قرار داد:

SQL> alter system set db_create_file_dest=’/oracle/mydata/’;

System altered.

SQL> alter tablespace system encryption online encrypt;

Tablespace altered.

پس از قرار دادن system tbs در حالت encrypt، اگر بخواهیم فایل wallet را در حالت close قرار دهیم، دستور با خطای زیر متوقف خواهد شد:

Version 18.3.0.0.0

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY  p;

ORA-28439: cannot close wallet when SYSTEM, SYSAUX, UNDO, or TEMP tablespaces are encrypted

(بیشتر…)

پیکربندی TDE در اوراکل 19c و 18c

نویسنده مطلب: وحید یوسف زاده Leave a comment

نحوه پیکربندی TDE در اوراکل نسخه 11g و 12c را قبلا مورد بررسی قرار دادیم و در این متن قصد داریم به پیکربندی TDE در اوراکل 18c و 19c بپردازیم.

کانفیگ TDE در اوراکل نسخه 19c، تفاوت زیادی با نسخه 12c ندارد و مشابه نسخه های قبلی، مسیر فایل (wallet(keystore را می توان با کمک پارامترENCRYPTION_WALLET_LOCATION  در فایل sqlnet.ora تنظیم کرد.

البته در کنار این پارامتر، اوراکل از نسخه 18c، دو پارامتر با نامهای tde_configuration و wallet_root را هم اضافه کرده و توصیه می کند که به جای استفاده از پارامتر SQLNET.ENCRYPTION_WALLET_LOCATION، از این دو پارامتر استفاده شود و اصطلاحا SQLNET.ENCRYPTION_WALLET_LOCATION را deprecate کرده است.

(بیشتر…)

مشاهده تاریخچه‏ ‏‏تغییرات پسورد کاربران با تنظیم PASSWORD_REUSE_MAX و PASSWORD_REUSE_TIME

نویسنده مطلب: وحید یوسف زاده Leave a comment

اگر پارامترهای PASSWORD_REUSE_MAX و یا PASSWORD_REUSE_TIME را برای پروفایلی تنظیم کنیم، شکل hash شده پسورد کاربرانی که عضو ان پروفایل هستند در جدولی از دیتابیس به نام $user_history ثبت خواهد شد و از این طریق امکان برگرداندن پسورد کاربر به مقدار قبلی هم به وجود خواهد آمد:

SQL> alter profile default limit PASSWORD_REUSE_TIME  10;

Profile altered

SQL> alter user usef identified  by d;

User altered

SQL> select user#,substr(password,1,12) password ,password_date from user_history$;

     USER# PASSWORD     PASSWORD_DATE

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

       120 T:0A20744AD0 09/20/2020 09

       120 T:E5A3AF0A52 09/20/2020 09

       120 T:CBCAAC7888 09/20/2020 09

برای برگرداندن پسورد کاربر به مقدار قبلی، می توان دستور alter user را به همراه عبارت  identified by values اجرا کرد.

alter user user_name identified by values “user_history$.passowrd”;

با تنظیم پارامترهای *_PASSWORD_REUSE به مقدار unlimited، پسورد جدیدی در جدول $user_history  ذخیره نخواهد شد.

 

استفاده از Unified auditing در حالت read only و محیط دیتاگارد

نویسنده مطلب: وحید یوسف زاده Leave a comment

همانطور که می دانید، زمانی که دیتابیس در حالت read only قرار دارد امکان ثبت اطلاعات در جداول دیتادیکشنری از بین خواهد رفت این قاعده برای جداول مربوط به auditing(نظیر aud$unified) هم صادق است از اینرو نمی توان عملیات انجام شده توسط کاربران را در دیتابیس ذخیره کرد.

در این شرایط، در صورت استفاده از قابلیت Unified auditing، اوراکل auditهای انجام شده را در محیط سیستم عامل ثبت خواهد کرد.

عملیات انجام شده توسط کاربران در قالب فایلهای باینری، با پسوند bin. و در مسیر ORACLE_BASE/audit/$ORACLE_SID$ ثبت خواهند شد و امکان مشاهده محتویات این فایلهای باینری از طریق ویوی unified_audit_trail فراهم می شود.

(بیشتر…)

نکاتی در مورد مجوز پکیج در اوراکل

نویسنده مطلب: وحید یوسف زاده 4 Comments

زمانی که user1 مجوز اجرای پروسیجرش را به user2 اهدا می کند، user2 علاوه بر امکان اجرای این پروسیجر، می تواند محتویات پروسیجر را هم مشاهده کند:

SQL> show user

User is “user1”

SQL> create user user2 identified by u;

User created

SQL> grant create session to user2;

Grant succeeded

SQL> grant execute on user1.myproc1 to user2;

Grant succeeded

SQL> conn user2/u

Connected.

SQL> exec user1.myproc1;

PL/SQL procedure successfully completed.

(بیشتر…)

اهدای مجوز insert و update در سطح ستون

نویسنده مطلب: وحید یوسف زاده Leave a comment

مجوزهای insert و update را می توان در سطح ستونهای یک جدول به کاربران اهدا نمود.

دستور grant در مثال زیر، مجوز اجرای دستور update بر روی ستونهای name و last_name از جدول sys.mytbl را به کاربر usef اهدا می کند:

SQL> create table sys.mytbl(id number,name varchar2(9),last_name varchar2(9));

Table created

SQL> insert into sys.mytbl values(1,’vahid’,’usefzadeh’);

1 row inserted

SQL> commit;

Commit complete

SQL> grant update(name,last_name) on mytbl to usef;

Grant succeeded

(بیشتر…)

ارسال unified audit trail به syslog و Event Viewer(اوراکل 18c/19c)

نویسنده مطلب: وحید یوسف زاده 2 Comments

در اوراکل 18c، پارامتری به نام UNIFIED_AUDIT_SYSTEMLOG اضافه شد که امکان نوشتن unified audit trail را در محیط سیستم عامل فراهم می کند با این قابلیت می توان فیلدهای کلیدی unified audit trail را در محیط لینوکس به syslog و در محیط ویندوز به Event Viewer فرستاد.

SQL>  show parameter unified_audit_systemlog

NAME                                   TYPE       VALUE

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

unified_audit_systemlog             string

قصد داریم با طی چند مرحله، این قابلیت را در محیط لینوکس پیکربندی کنیم.

(بیشتر…)

اوراکل 19c- ایجاد کاربران سیستمی به صورت Schema Only Account

نویسنده مطلب: وحید یوسف زاده 1 Comment

با ایجاد دیتابیس اوراکل، به ازای هر component انتخابی، تعدادی user ایجاد خواهند شد. برای نمونه، اسامی تعدادی از componentها به همراه کاربرانی که برای آنها ایجاد می شود را در قسمت زیر می بینید:

Oracle Multimedia: MDSYS,ORDDATA,ORDPLUGINS,SI_INFORMTN_SCHEMA

Oracle Database Vault: DVF,DVSYS

Oracle XML Database: ANONYMOUS

Oracle Text: CTXSYS

تا قبل از اوراکل 19c، برای این نوع از کاربران سیستمی، از روش احراز هویت، PASSWORD استفاده می شد به همین جهت، با ایجاد دیتابیس در این نسخه ها(قبل از 19c)، تعداد زیادی از کاربران، پسورد default داشتند.

(بیشتر…)

اوراکل 19c- ویژگی Audit Only Top-Level SQL Statements

نویسنده مطلب: وحید یوسف زاده 1 Comment

در صورتی که حجم لاگ ایجاد شده توسط قابلیت unified auditing نسبتا زیاد باشد، برای مراجعه و نگهداری اطلاعات audit trail، ممکن است با مشکل پرفورمنس و کمبود استوریج مواجه شویم بنابرین auditing باید طوری پیکربندی شود که حتی المقدور، اطلاعات اضافه ای در جدول مربوطه، ثبت نگردد.

ویژگی جدید اوراکل 19c که Auditing Only Top-Level SQL Statements نام دارد، می تواند در این زمینه موثر واقع شود.

(بیشتر…)