اوراکل 23ai- افزایش حداکثر اندازه پسورد از 30 بایت به 1024 بایت

تا قبل از نسخه 23ai، پسورد کاربران و roleها حداکثر می توانست 30 بایت باشد:

SQL> create user u1 identified by a123456789012345678901234567890;
ORA-00972: identifier is too long
SQL> create role r1 identified by a123456789012345678901234567890;
ORA-00972: identifier is too long

در اوراکل 23ai این محدودیت به 1024 بایت تغییر کرده است:

SQL> create user u1 identified by a123456789012345678901234567890;
User created.
SQL> create role r1 identified by a123456789012345678901234567890;
Role created.

اوراکل 23ai- قابلیت Dictionary Protection

زمانی که یکی از مجوزهای system “ANY” privilege نظیر select any table، drop any table و … را به کاربری می دهیم، آن کاربر امکان دسترسی به objectهای شمای sys و جداول Data Dictionary را ندارد:

SQL*Plus: Release 10.1.0.4.2 - Production on Tue Jan 9 10:38:31 2024
SQL> show user
USER is "SYS"
SQL> create table sys.tb as select * from dual;
Table created.
SQL> create user usef identified by a;
User created.
SQL> grant create session,select any table to usef;
Grant succeeded.
SQL> conn usef/a
Connected.
SQL> select * from sys.tb;
ORA-00942: table or view does not exist
SQL> select * from v$datafile;
ORA-00942: table or view does not exist

اگر تصمیم داریم این محدودیت را حداقل در مورد مجوز select any table برای یک کاربر برداریم، می توانیم مجوز SELECT ANY DICTIONARY را به آن کاربر اعطا کنیم:

SQL> grant SELECT ANY DICTIONARY to usef;
Grant succeeded.
SQL> conn usef/a
Connected.
SQL> select * from sys.tb;
D
-
X
SQL> select file# from v$datafile where rownum=1;
     FILE#
----------
         1

البته از اوراکل 12c، دسترسی به بعضی از جداول Data Dictionary حتی با داشتن مجوز  SELECT ANY DICTIONARY  هم امکان پذیر نیست. لیست بعضی از این جداول را در قسمت زیر می بینید:

USER$, ENC$ , DEFAULT_PWD$, LINK$, USER_HISTORY$, CDB_LOCAL_ADMINAUTH$, XS$VERIFIERS

(بیشتر…)

قابلیتهای جدید اوراکل 23ai برای جداول Blockchain و Immutable

در این مطلب سعی داریم تعدادی از قابلیتهای جدید اوراکل 23c در زمینه جداول Blockchain و Immutable را مرور کنیم.

امکان حذف  و اضافه کردن ستون به جداول Blockchain و Immutable

در نسخه 23c می توان به جداول Blockchain ستونی را اضافه کرد(البته در version v2 این نوع از جداول):

SQL> create blockchain table blockchaintb1 (
  id    number(10),
  desc1 varchar2(100)
)
no drop until 20 days idle
no delete until 20 days after insert
hashing using "SHA2_512" version "v2";  
Table created.
SQL> alter table blockchaintb1 add (desc2 varchar2(1000));
Table altered.

حذف ستون هم در این نسخه امکان پذیر است:

SQL>  alter table blockchaintb1 drop column desc2;
Table altered.

در صورت درج اطلاعات در این نوع از جداول، باز هم می توان عملیات فوق را تکرار کرد:

(بیشتر…)

قابلیت SQL Firewall در اوراکل 23ai

SQL Firewall یکی دیگر از قابلیتهای جدید اوراکل در نسخه 23c است بر اساس این قابلیت می توانیم مجموعه ای از دستورات را به عنوان دستورات مجاز برای دیتابیس تعریف کنیم در این صورت کاربر نمی تواند دستور دیگری خارج از این مجموعه را اجرا کند حتی اگر این کاربر مجوز اجرای آن دستورات را داشته باشد.

قصد داریم اقدامات کاربر Usef را تحت نظر بگیریم و تمامی دستورات اجرا شده توسط این کاربر را capture کنیم سپس با تنظیم SQL Firewall، به این کاربر اجازه ندهیم خارج از دستوراتی که capture شده اند، دستور جدیدی را اجرا کند.

(بیشتر…)

فعالسازی مجدد Traditional Audit در اوراکل 23ai

قبلا در مطلبی توضیح دادیم که Traditional Audit در نسخه 23c پشتیبانی نمی شود به این معنی که auditهای قدیمی امکان اعمال شدن دارند ولی نمی توان audit جدیدی را ایجاد کرد.

برای مثال می توانیم auditای که از قبل تنظیم شده را noaudit کنیم:

SQL>  noaudit all on DVSYS."REALM_AUTH$";
Noaudit succeeded.

ولی امکان تنظیم مجدد این audit و یا auditهای دیگر وجود ندارد و در صورت تلاش برای این کار با خطای ORA-46401 مواجه خواهیم شد:

SQL> audit all on DVSYS."REALM_AUTH$";
ORA-46401: No new traditional AUDIT configuration is allowed. Traditional
auditing is desupported, and you should use unified auditing in its place.

آقای Pete Finnigan که در موضوع oracle security مطالب خوبی دارند، پارامتر مخفی ای(Hidden Parameter)  را معرفی کردند که امکان فعالسازی مجدد Traditional Audit را در این نسخه فراهم می کند:

SQL> alter system set "_allow_traditional_audit_configuration"=true;
System altered.

پس از تنظیم این پارامتر به مقدار TRUE، مجددا دستور audit فوق را اجرا می کنیم:

SQL> audit all on DVSYS."REALM_AUTH$";
Audit succeeded.

این نوع از  audit بدون هیچ محدودیتی، در سطوح دیگر هم قابل انجام است:

SQL> audit drop any table;
Audit succeeded.
SQL> audit all statements;
Audit succeeded.

 

معرفی Role جدید برای Developerها در اوراکل 23ai

زمانی که ادمین دیتابیس، User جدیدی را برای Developerها ایجاد می کند شاید در تردید باشد که چه مجوزهایی را به این User اهدا کند تا Developer حداقل دسترسی لازم برای تولید Application را در نقطه شروع داشته باشد.

شاید بسیاری از ادمینها، Roleهای Connect و Resource را به این User اهدا می کنند تا Developer بتواند از طریق این User به دیتابیس وصل شده و در صورت لزوم اقداماتی را نظیر ساخت Table، View، Trigger و … انجام دهد.

این دو Role شامل system privilegeهای زیر هستند:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL> create user usef identified by a;
User created.
SQL> grant connect,resource to usef;
Grant succeeded.
SQL> conn usef/a@target:1521/PDBTARGET
Connected.
SQL> select * from session_privs;
CREATE SESSION
CREATE TABLE
CREATE CLUSTER
CREATE SEQUENCE
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE
SET CONTAINER
10 rows selected.  

(بیشتر…)

اوراکل 23ai- قابلیت Read Only User

Read Only User یکی از قابلیتهای جدید اوراکل در نسخه 23c است که اوراکل در مستندات مربوط به نسخه 23c حرفی در مورد آن نزده و ظاهرا اولین مستند آن مربوط به آقای Pete Finnigan است.

از طریق این قابلیت می توانیم امکان هرگونه تغییر داده را از یک کاربر بگیریم به طوری که کاربر با داشتن مجوز لازم برای insert، delete و update نتواند این دستورات را اجرا کند و یا با داشتن مجوز ساخت جدول، ویو، پروسیجر و … قابلیت ایجاد این اشیا را نداشته باشد چرا که ایجاد یک شی نیازمند تغییر داده در جداول Data Dictionary است.

بنابرین در صورتی که کاربر در حالت read only قرار بگیرد صرفا می تواند به دیتابیس وصل شده و اطلاعات جداول را ببیند و یا پروسیجر، فانکشن و پکیجی که تغییری را ایجاد نمی کنند اجرا کند.

در زمان ساخت یک user می توان آن را در حالت read only قرار داد:

SQL> create user USEF identified by abc read only;
User created.

(بیشتر…)

اوراکل 23ai- قابلیت Traditional Auditing دیگر پشتیبانی نمی شود!

از اوراکل 23c قابلیت Traditional Auditing(یا همان Standard Auditing) دیگر پشتیبانی نمی شود! و قابلیت Unified Auditing در این نسخه از اوراکل به صورت پیش فرض فعال است:

SQL*Plus: Release 23.0.0.0.0 - Developer-Release on Wed Jun 14 18:26:42 2023
SQL> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';
VALUE
-------------
TRUE

البته پارامترها و جداول مربوط به Traditional Auditing کماکان وجود دارند:

SQL> select count(*) from dba_audit_trail;
  COUNT(*)
----------
         0
SQL> show parameter audit_trail
NAME         TYPE        VALUE
------------ ----------- --------
audit_trail  string      DB

همچنین امکان تغییر مقدار پارامتر audit_trail هم وجود دارد هر چند که در حالت عادی تغییر آن اثری ندارد:

SQL> alter system set audit_trail='db,extended' scope=spfile;
System altered.

(بیشتر…)

Schema Privilege در اوراکل 23ai

تا قبل از اوراکل23cء، privilegeها به سه نوع object، system و administrative قابل تقسیم بودند و برای آنکه کاربری صرفا به اشیاء یک اسکیما دسترسی داشته باشد به ناچار می بایست از object privilegeها استفاده کرد که این محدودیت را قبلا در مستندی شرح داده ایم.

رجوع شود به : اهدای مجوز در سطح اسکیما در اوراکل و پستگرس

در نسخه 23c قابلیت جدیدی در این زمینه ایجاد شد و اوراکل نوع دیگری از privilege به نام schema privilege را ارائه کرد که بر اساس آن می توان دسترسی به تمامی اشیاء{موجود و آینده} یک اسکیما را صرفا با اجرای یک دستور به یک کاربر(و یا role) اهدا کرد و یا به کاربر این امکان را داد تا برای اسکیما شی جدیدی بسازد.

schema privilege با کمک system privilegeها کار می کند مثلا می توانیم دسترسی select any table که یک system Privilege محسوب می شود را بر روی یک اسکیما به یک کاربر اهدا کنیم. بدیهی است که schema privilege به نسبت system privilege از دادن دسترسی های اضافه جلوگیری خواهد.

(بیشتر…)

Auditing در سطح ستون – اوراکل 23ai

Unified Auditing در نسخه 23c به صورت پیش فرض فعال است و در این نسخه به آن قابلیتهای جدیدی هم اضافه شده است. یکی از این قابلیتها، امکان Auditing در سطح Column است با کمک این فیچر می توانیم صرفا ستون(یا ستونهای) به خصوصی از یک Table یا View را Audit کنیم.

برای مثال قصد داریم هر selectای بر روی ستون mobile را Audit کنیم، برای این کار Audit Policy زیر را ایجاد می کنیم:

SQL> CREATE AUDIT POLICY Col_pol_Mobile ACTIONS select(mobile) ON usef.person;
Audit policy created.

Policy ایجاد شده را فعال می کنیم:

SQL> AUDIT POLICY Col_Pol_Mobile;
Audit succeeded.

(بیشتر…)