اهدای مجوز به فانکشن، پکیج و پروسیجر

زمانی که یک program unit(فانکشن، پکیج، پروسیجر) به صورت invoker right ایجاد می شود، کاربر صدا زننده برنامه، با مجوز خودش این برنامه را اجرا خواهد کرد بنابرین اگر جدولی در برنامه موجود باشد که این کاربر به آن دسترسی نداشته باشد، کارش با خطا متوقف خواهد شد(بررسی Invoker’s Rights و Definer’s Rights). برای مثال، تابع زیر را در نظر بگیرید:

SQL> CREATE FUNCTION sys.Tabe(name_malek in varchar2,name_jadval in varchar2)
   RETURN VARCHAR2
   AUTHID CURRENT_USER
AS
V_bytes varchar2(1000);
BEGIN
  select bytes into V_bytes from dba_segments where owner=name_malek and segment_name=name_jadval;
   RETURN V_bytes;
END;
/
Function created.

این تابع که با یوزر sys ایجاد شده، قرار است نام segment را دریافت و حجم آن را بر اساس بایت برگرداند. عبارت AUTHID CURRENT_USER بیانگر invoker right است.

کاربری با نام vahid را با حداقل دسترسی ایجاد کرده و بررسی می کنیم که آیا این کاربر می تواند تابع فوق را اجرا کند؟

SQL> create user vahid  identified by a;
User created.
SQL> grant create session to vahid; 
Grant succeeded.

(بیشتر…)

ردیابی اهدای مجوزها در اوراکل از طریق ویوی ALL_TAB_PRIVS_MADE و USER_TAB_PRIVS_RECD

اگر کاربری مجوزی را به کاربر دیگر اهدا کند، این عملیات از طریق ویوی ALL_TAB_PRIVS_MADE قابل ردیابی است(البته با رعایت شرایطی!) و این ویو در کنار ویوی USER_TAB_PRIVS_RECD مشخص می کند که مجوز توسط کدام کاربر به کاربر دیگر اهدا شده است.

برای مثال در قسمت زیر، کاربر usef مجوز select on ali.tbl1 را به کاربر vahid اهدا می کند:

SQL> create user usef identified by a;
User created.
SQL> create user vahid identified by a;
User created.
SQL> grant create session to vahid,usef;
Grant succeeded.
SQL> grant select on ali.tbl1 to usef with grant option;
Grant succeeded.
SQL> conn usef/a
Connected.
SQL> show user
User is "USEF"
SQL> grant select on ali.tbl1 to vahid;
Grant succeeded.
SQL> conn ali/a
Connected.
SQL> select grantee, grantor,privilege, table_name from user_tab_privs_made where GRANTEE='VAHID';
GRANTEE     GRANTOR    PRIVILEGE  TABLE_NAME
----------- ---------- ---------- ----------
VAHID       USEF       SELECT     TBL1

همانطور که می بینید، با اجرای پرس و جوی فوق توسط کاربر ali، خواهیم دید که مجوز select on ali.tbl1 توسط کاربر usef به کاربر VAHID اختصاص داده شده است. البته با اجرای ویوی USER_TAB_PRIVS_RECD هم به این نتیجه خواهیم رسید:

SQL> conn vahid/a
Connected.
SQL> select owner,table_name,grantor,privilege,type from USER_TAB_PRIVS_RECD;
OWNER      TABLE_NAME GRANTOR    PRIVILEGE  TYPE
---------- ---------- ---------- ---------- ------------
ALI        TBL1       USEF       SELECT     TABLE

در این شرایط با حذف کاربر usef، دسترسی داده شده به کاربر vahid از بین خواهد رفت و به تبع آن، این دو ویو هم اطلاعاتی را در این زمینه بر نمی گردانند:

SQL> drop user usef;
User dropped.
SQL> conn ali/a
Connected.
SQL> select owner,table_name,grantor,privilege,type from USER_TAB_PRIVS_RECD;
no rows selected
SQL> select * from ALI.TBL1;
ORA-00942: table or view does not exist

با اندکی تغییر در سناریوی قبلی، نقش dba را به کاربر usef اختصاص می دهیم و بعد از ان کاربر usef، دسترسی select on ali.tbl1 را به کاربر vahid اهدا می کند، با این تغییر، دو ویوی فوق، کاربر ALI را به عنوان grantor معرفی خواهند کرد:

SQL> create user usef identified by a;
User created.
SQL> grant dba to usef;
Grant succeeded.
SQL>  conn usef/a
Connected.
SQL> grant select on ali.tbl1 to vahid;
Grant succeeded.
SQL> conn vahid/a
Connected.
SQL> select owner,table_name,grantor,privilege,type from USER_TAB_PRIVS_RECD;
OWNER      TABLE_NAME GRANTOR    PRIVILEGE  TYPE
---------- ---------- ---------- ---------- ------------------------
ALI        TBL1       ALI        SELECT     TABLE
SQL> conn ali/a
Connected.
SQL> select grantee, grantor, table_name from user_tab_privs_made where GRANTEE='VAHID';
GRANTEE     GRANTOR    TABLE_NAME
----------- ---------- ----------
VAHID       ALI        TBL1

 

نکته ای در مورد 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) سیاستهایی را اعمال کرد.

(بیشتر…)