Unified Auditing

همانطور که می دانید، ثبت وقایع برای نسخه های قبل از اوراکل 12c، از طریق standard auditing امکان پذیر است. با کمک این شیوه از auditing، می توان تمامی عملیات کاربران حاضر در بانک اطلاعاتی را مانیتور نمود (البته به غیر از کاربرانی که با مجوز sysdba به بانک لاگین کرده اند.) این شیوه از auditing در کنار مزیتهای فراوانی که به همراه دارد، با محدودیتهایی هم روبروست، محدودیتهایی نظیر:

1.امکان دستکاری راحت audit record توسط کاربر sys

2.عدم ثبت وقایع کاربر sys در جدولی از بانک

3.عدم امکان auditing بر اساس role کاربران

4.عدم پارتیشن بندی پیش فرض جدول $aud و مشقتهای حذف بازه ای اطلاعات آن(delete + HWM)

5.عدم امکان auditing بر اساس مولفه هایی چون rman، datapump، sqlldr و …

6.عدم امکان auditing بر مبنای host name، ip address و …

و …

(بیشتر…)

INHERIT PRIVILEGE

قبلا در مورد invoker right و definer right مطلبی را ارائه کردیم(ادرس مطلب) و نشان دادیم که استفاده از عبارت AUTHID CURRENT_USER چه مزیت امنیتی ای را به همراه دارد اما استفاده از invoker right در زمانی که مجوزهای invoker از definer بیشتر باشد، نقایصی را هم به لحاظ امنیتی در برخواهد داشت که در ادامه با ارائه مثالی، به این نقصان خواهیم پرداخت.

(بیشتر…)

مجوز alter user در اوراکل 12c

با اهدای مجوز alter user به یک کاربر در اوراکل 11g، ان کاربر می تواند تغییراتی چون تغییر پسورد را برای کاربر sys اعمال کند. مثال زیر را ببینید:

SQL*Plus: Release 11.2.0.3.0 Production on Tue Jun 12 12:57:22 2018

SQL> create user usef identified by a;

User created.

SQL> grant connect,resource to usef;

Grant succeeded.

SQL> grant alter user to usef;

Grant succeeded.

SQL> conn usef/a

Connected.

SQL> alter user sys identified by a;

User altered.

در اوراکل 12c، این امکان برای کاربر usef از بین خواهد رفت:

SQL*Plus: Release 12.2.0.1.0 Production on Tue Jun 12 13:29:04 2018

SQL> alter user vahid identified by a;

User altered.

SQL>  alter user sys  identified by a;

ORA-01031: insufficient privileges

پسورد کاربر sys و پسوردفایل

پرسش: اگر با دستور orapwd پسوردفایل جدیدی ایجاد شود(همراه با پسوردی جدید برای کاربر sys) ، اطلاعات مربوط به پسورد کاربر sys در جداول data dictionary هم تغییر خواهد کرد؟

پاسخ: خیر، ایجاد و یا تغییر رمز sys در پسورد فایل، تغییری را در رمز کاربر sys در جداول data dictionary نخواهد گذاشت همچنین برای اتصال از راه دور(tns و sysdba) به بانک اطلاعاتی، ملاک همان پسوردفایل خواهد بود. مثال زیر را ببینید.

(بیشتر…)

بررسی Invoker’s Rights و Definer’s Rights

پرسش: کاربر A قصد اجرای پروسیجری از کاربر B را دارد، برای انجام این کار، به کاربر A مجوز execute بر روی این پروسیجر داده شده است. در قسمتی از متن این پروسیجر، پسورد کاربر B هم تغییر خواهد کرد در صورتی که کاربر A، مجوز alter user را ندارد. با در نظر گرفتن این مسئله، کاربر A، امکان اجرای این پروسیجر را دارد؟

(بیشتر…)

تعیین پسورد ساده برای کاربر sys در 12cR2

در زمان ساخت پسوردفایل در نسخه 12cR2، باید برای تعیین پسورد، پیچیدگی هایی را لحاظ کرد تا پسوردفایل قابل ایجاد باشد. برای نمونه پسورد باید حداقل شامل 8 کارکتر باشد که در این هشت کارکتر حداقل یک حرف، یک رقم و یک کارکتر خاص(شبیه _,# و ….) موجود باشد همچنین این کارکتر نباید مشابه نام کاربری باشد و …. در غیر این صورت ایجاد پسوردفایل با خطا متوقف خواهد شد:

(بیشتر…)

TDE در اوراکل نسخه 11g

در نوشتاری که چندی قبل برای مبحث database vault ارائه شد، چگونگی جلوگیری از دسترسی و یا اصلاح اطلاعات خاص توسط مدیران بانکهای اطلاعاتی و یا افرادی که در سطوح بالایی به بانک اطلاعاتی دسترسی دارند، مورد بررسی قرار گرفته شد همانطور که در ان مطلب بیان کردیم، database vault تنها برای کنترل دسترسی در سطح بانک اطلاعاتی کاربرد دارد و برای جلوگیری از دسترسی غیر ایمن به اطلاعات در لایه سیستم عامل، باید از روشهای دیگری چون TDE استفاده کرد که در این نوشتار به این مهم خواهیم پرداخت.

(بیشتر…)