……..آموزش، مشاوره و پشتیبانی…….
پرسش: اگر با دستور orapwd پسوردفایل جدیدی ایجاد شود(همراه با پسوردی جدید برای کاربر sys) ، اطلاعات مربوط به پسورد کاربر sys در جداول data dictionary هم تغییر خواهد کرد؟
پاسخ: خیر، ایجاد و یا تغییر رمز sys در پسورد فایل، تغییری را در رمز کاربر sys در جداول data dictionary نخواهد گذاشت همچنین برای اتصال از راه دور(tns و sysdba) به بانک اطلاعاتی، ملاک همان پسوردفایل خواهد بود. مثال زیر را ببینید.
پرسش: کاربر A قصد اجرای پروسیجری از کاربر B را دارد، برای انجام این کار، به کاربر A مجوز execute بر روی این پروسیجر داده شده است. در قسمتی از متن این پروسیجر، پسورد کاربر B هم تغییر خواهد کرد در صورتی که کاربر A، مجوز alter user را ندارد. با در نظر گرفتن این مسئله، کاربر A، امکان اجرای این پروسیجر را دارد؟
در زمان ساخت پسوردفایل در نسخه 12cR2، باید برای تعیین پسورد، پیچیدگی هایی را لحاظ کرد تا پسوردفایل قابل ایجاد باشد. برای نمونه پسورد باید حداقل شامل 8 کارکتر باشد که در این هشت کارکتر حداقل یک حرف، یک رقم و یک کارکتر خاص(شبیه _,# و ….) موجود باشد همچنین این کارکتر نباید مشابه نام کاربری باشد و …. در غیر این صورت ایجاد پسوردفایل با خطا متوقف خواهد شد:
در اوراکل 11g با تغییر پسورد sys باید مجددا پسوردفایل به محیط data guard منتقل شود(برخلاف نسخه 12c). حال اگر یکی از برنامه های دوره ای تیم امنیت، تغییر پسورد کاربر sys باشد، این مسئله می تواند برای پشتیبان بانک ایجاد مزاحمت کند همچنین در صورت انتقال اطلاعات با دسترسی sysdba، به لحاظ امنیتی هم شاید بستر نفوذی بین این دو سرور ایجاد باشد.
در ادامه مطلب “Transparent Data Encryption در اوراکل 11g“، قصد داریم تغییرات وهمچنین نحوه پیاده سازی این قابلیت را در اوراکل نسخه 12c مورد بررسی قرار دهیم.
(بیشتر…)در نوشتاری که چندی قبل برای مبحث database vault ارائه شد، چگونگی جلوگیری از دسترسی و یا اصلاح اطلاعات خاص توسط مدیران بانکهای اطلاعاتی و یا افرادی که در سطوح بالایی به بانک اطلاعاتی دسترسی دارند، مورد بررسی قرار گرفته شد همانطور که در ان مطلب بیان کردیم، database vault تنها برای کنترل دسترسی در سطح بانک اطلاعاتی کاربرد دارد و برای جلوگیری از دسترسی غیر ایمن به اطلاعات در لایه سیستم عامل، باید از روشهای دیگری چون TDE استفاده کرد که در این نوشتار به این مهم خواهیم پرداخت.
(بیشتر…)با نصب کلاستر به صورت standard ASM(روش رایج در نسخه 11g)، هر نود شامل یک ASM instance و یک db instance خواهد بود که با افتادن ASM instance در یک نود، db instance موجود در ان نود هم به خطا برخواهد خورد و امکان استفاده از ASM instanceهای دیگر برای این db instance ممکن نخواهد بود به عبارت دیگر، هر db instance تنها به ASM instance موجود در سرورش متکی می باشد. در اوراکل 12c ویژگی ای ارائه شد که می تواند این نقصان را برطرف کند، این ویژگی FLEX ASM نام دارد و می توان به کمک ان، همه نودهای موجود در فضای کلاستر را تنها به اعتبار یک ASM instance سرپا نگه داشت البته این ویژگی مزیتهای دیگری هم به همراه دارد که به تعدادی از انها در این نوشتار خواهیم پرداخت.
همانطور که می دانید، در هر asm disk علاوه بر داده های بانک اطلاعاتی، نوع دیگری از داده هم ذخیره می شود که فراداده مربوط به ان دیسک می باشد و این نوع از داده ها معمولا در قسمت ابتدایی دیسک و به عبارتی در بلاک صفر ذخیره می شوند و کپی ای از ان هم در بلاک 510 برای مسائل امنیتی ذخیره می شود(2088960 bytes / 4096 = 510) البته قسمتی از فراداده داده ذخیره شده در این بلاکها، مربوط به خود دیسک نمی باشد بلکه اطلاعاتی در مورد دیسک گروهی هست که دیسک عضو ان می باشد.
همانطور که می دانید برای مدیریت فایلهای موجود در محیط asm، نمی توان از دستورات سیستم عاملی استفاده کرد(البته در محیط acfs که بر روی asm پیاده می شود، این نقصان برطرف شده است).
برای مثال نمی توان با دستوراتی چون cp ،mv و… در سطح لینوکس، بر روی فایلهای موجود در فضای asm اعمال مدیریت کرد در صورتی که ممکن است برای یک مدیر بانک اطلاعاتی، انجام چنین کاری بسیار ضروری باشد(انتقال فایل به محیط بیرون، اصلاح و ….).
یکی از این عملیاتهای پرکاربرد، انتقال فایل بین دو محیط سیستم عامل و asm می باشد که در ادامه با ارائه سه روش، به شیوه انجام آن خواهیم پرداخت.
(بیشتر…)