نکته ای در مورد Role و Privilege در اوراکل

زمانی که مجوزی از نوع object privilege و یا system privilege به کاربری داده می شود(و یا از کاربر گرفته(revoke) می شود)، بلافاصله sessionهای ان user که به دیتابیس متصل هستند، از این مجوزها بهره مند خواهند شد:

–session 1:

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Sep 16 19:48:16 2021
Version 19.11.0.0.0
SQL> show user
USER is "ALI"
SQL> select * from session_privs;
PRIVILEGE
----------------------------------------
CREATE SESSION

–session 2:

SQL> show user
USER is "USEF"
SQL> grant select any table to ALI;
Grant succeeded.

–session 1:

SQL> select * from session_privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
SELECT ANY TABLE

اما این مسئله برای role صادق نیست و در صورت grant یا revoke کردن یک roleء، sessionهای جاری متاثر نخواهند شد مگر آنکه از دستور SET ROLE استفاده کنند:

(بیشتر…)

تابع checksum در اوراکل 21c

در نسخه 12c، اوراکل با ارائه تابع STANDARD_HASH، امکان محاسبه hash value را برای یک فیلد و یا عبارت فراهم کرده است:

SQL> select id,salary,substr(STANDARD_HASH(id||salary),1,20) hash_id_sal from tbl1;
        ID     SALARY HASH_ID_SAL
---------- ---------- ----------------------
         1         10 5E796E48332AF4142B10
         2         12 E2154FEA5DA2DD0D1732
         3         17 F44A286F486D11990238
         4         18 93AC1946CB917ABC4735

با این روش می توانیم از تغییر مقدار سطرهای جدول باخبر شویم. البته در نسخه های قبل از 12c هم می توانستیم از توابع دیگری نظیر ora_hash بدین منظور استفاده کنیم:

SQL> select id,salary,ora_hash(id||salary)  hash_id_sal from tbl1;

        ID     SALARY HASH_ID_SAL
---------- ---------- -----------
         1         10  3316966336
         2         12  1402677848
         3         17  3795753203
         4         18   936769390

در نسخه 21c هم قابلیت جدیدی در این زمینه ارائه شد و اوراکل با معرفی تابع checksum، امکان شناسایی تغییر دیتا را در سطح ستون فراهم کرده است.

(بیشتر…)

اوراکل 21c – انجام auditing بر اساس current user

ستونهای DBUSERNAME و CURRENT_USER در ویوی unified_audit_trail شباهت زیادی به هم دارند و در بسیاری از مواقع، این دو ستون حاوی اطلاعات یکسانی هستند. معمولا در این ستونها نام کاربری که به دیتابیس لاگین کرده و دستور را اجرا نموده است ، ذخیره می شود.

مگر آنکه کاربر متصل به دیتابیس با حقوق definer(یا همان definer right)، دستوری را اجرا کند، که در این صورت، نام کاربر متصل به دیتابیس در ستون DBUSERNAME ثبت می شود و نام کاربر definer که مجری واقعی دستور بوده در ستون CURRENT_USER ذخیره می شود.

*برای آشنایی بیشتر با مفهوم definer right و  invoker right پیشنهاد می شود مطلب بررسی Invoker’s Rights و Definer’s Rights را مطالعه کنید.

برای مثال، کاربر A پروسیجر زیر را به صورت definer right تعریف کرده است:

create or replace procedure prc1 authid definer as
  id_var number;
begin
  select object_id into id_var from usef.tbl1 where object_name = ‘TB’;
end;
/

(بیشتر…)

اوراکل 21c-حذف پارامتر IGNORECASE و SEC_CASE_SENSITIVE_LOGON

از اوراکل 21c، همه پسوردها در پسوردفایل به صورت case-sensitive ذخیره می شوند در صورتی که تا قبل از این نسخه می توانستیم با کمک پارامتر IGNORECASE در دستور orapwd، این ویژگی را غیرفعال کنیم.

اوراكل 19c:

[oracle@linux7 dbs]$ orapwd file=/oracle19c/home/dbs/orapwtajmifullssd sys=Y force=Y format=12 ignorecase=Y password=EST_est_123

[oracle@linux7 dbs]$ sqlplus “sys/est_est_123@linux7:1521/pdb1 as sysdba”

SQL*Plus: Release 19.0.0.0.0 – Production on Thu Nov 11 08:59:55 2021

Version 19.11.0.0.0

Copyright (c) 1982, 2020, Oracle.  All rights reserved.

Connected to:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production

Version 19.11.0.0.0

SQL>

(بیشتر…)

Mandatory Profile در اوراکل 21c

همانطور که می دانید از طریق پروفایل می توان برای هر کاربر در دو سطح مصرف منابع و password complexity محدودیتهایی را اعمال کرد. پروفایلها در سطح کاربر قابل تنظیم هستند و هر کاربر می تواند تنها یک پرفایل داشته باشد.

در اوراکل 21c نوع جدیدی از پروفایل تحت عنوان Mandatory Profile ارائه شد که در سطح root container قابل ایجاد است و می توان این دسته از پروفایلها را برای یک یا چند pdb تنظیم کرد که در این صورت، پالیسی مربوط به این پروفایل، برای همه کاربران موجود در آن pdb اعمال خواهد شد.

Mandatory Profile صرفا قرار است در زمینه تنظیم پسورد برای کاربران محدودیت ایجاد کند به این صورت که مثلا پسورد کاربر حداقل n کارکتر داشته باشد. این قبیل محدودیتها از طریق ایجاد یک FUNCTION و تنظیم پارامتر PASSWORD_VERIFY_FUNCTION(در پروفایل) قابل اعمال هستند.

(بیشتر…)

اوراکل 21c – اعمال فوری تغییرات در Unified Audit Policy

تا قبل از اوراکل نسخه 21c، هرگونه تغییر در یک Unified Audit Policy، برای sessionهای متصل به دیتابیس اعمال نمی شد و برای اثرپذیری فوری تغییرات audit policy، باید کاربران متصل به دیتابیس را مجبور به log out کرد تا بعد از اتصال مجدد به دیتابیس، مطابق با قوانین جدید audit شوند. این محدودیت را در سناریوی زیر توضیح دادیم.

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production

–session 1:

SQL> create user vahid identified by a;

User created.

SQL> grant create session to vahid;

Grant succeeded.

SQL> grant select on usef.tbl1 to vahid;

Grant succeeded.

SQL> create audit policy audpolselect actions select on usef.tbl1;

Audit policy created.

–session 2:

SQL> conn vahid/a@192.168.56.22:1521/pdb1

Connected.

–session 1:

SQL> audit policy audpolselect by vahid;

Audit succeeded

–session 2:

SQL> show user

USER is “VAHID”

SQL> select count(*) from usef.tbl1;

  COUNT(*)

———-

         3

فعال شدن audit policy قبل از اجرای دستور select، منجر به audit کاربر vahid نخواهد شد:

SQL> select dbusername,action_name,unified_audit_policies from unified_audit_trail where unified_audit_policies like ‘%AUDPOLSELECT%’;

no rows selected

(بیشتر…)

تنظیم دو پسورد برای یک کاربر در اوراکل 21c و 19.12

در اوراکل نسخه 21c(و همچنین بعدا در اوراکل 19.12)، قابلیتی با عنوان “Gradual Database Password Rollover” ارائه شد که با تنظیم پسورد جدید برای یک کاربر، پسورد قبلی برای مدت زمان محدودی معتبر باقی می ماند که در این شرایط، یک کاربر هر چند برای مدت زمان کوتاهی، دو پسورد خواهد داشت.

 

کاربرد!

با استفاده از این ویژگی می توان عملیات تغییر پسورد یوزری که application از طریق آن به دیتابیس وصل می شود را بهتر مدیریت کرد چرا که در این شیوه، ابتدا پسورد جدید برای کاربر تنظیم شده و در زمان مناسب پسورد جدید کاربر در applicationها اعمال خواهد شد.

این ویژگی سبب خواهد شد تا در applicationهایی که برای تغییر پسورد نیازی به restart شدن ندارند، downtimeی هم نداشته باشیم(در زمان تغییر پسورد کاربر).

(بیشتر…)

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

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

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

(بیشتر…)

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

بهبود اول: از اوراکل 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

نحوه پیکربندی 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 کرده است.

(بیشتر…)