Data Masking از طریق Data Pump

در زمان انتقال اطلاعات از یک بانک عملیاتی به یک بانک تستی، ممکن است نیاز باشد تا اطلاعات حساس به طور شفاف به بانک مقصد منتقل نشوند در این صورت اگر از data pump برای جابجایی دیتا استفاده می کنیم، می توانیم در زمان برگرداندن دیتا با دستور impdp، داده های حساس را دستکاری کنیم. این کار، از طریق پارامتر REMAP_DATA و یک function(که از قبل در بانک تستی موجود است)، قابل انجام خواهد بود.

REMAP_DATA=[schema.]tablename.column_name:[schema.]pkg.function

(بیشتر…)

دست گرمی با پسوردفایل

همانطور که می دانید، برای لاگین از راه دور به بانک اطلاعاتی، آن هم از طریق administrative privilegeها(از قبیل sysdba و sysoper)، ناگزیر باید password file را برای بانک ایجاد کرده باشیم در غیر این صورت، با خطا مواجه خواهیم شد:

[oracle@myhost ~]$ sqlplus “sys/a@mydb1 as sysdba”

SQL*Plus: Release 18.0.0.0.0 – Production on Sat Aban 26 12:27:51 1397

Version 18.3.0.0.0

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

ERROR:

ORA-01017: invalid username/password; logon denied

Enter user-name:

(بیشتر…)

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، امکان اجرای این پروسیجر را دارد؟

(بیشتر…)