تحقیق درباره بررسی امنیت در پایگاه داده

فرمت فایل : word (قابل ویرایش) تعداد صفحات : 22 صفحه

تعریف :

سیستم مدیریت پایگاه اطلاعاتی (DBMS)

Database Management System: برنامه ای که بمنظور ساخت پایگاههای اطلاعاتی بکار می رود و عملیات دروندهی داده ها در پایگاههای اطلاعاتی و سپس پردازش داده ها را انجام می دهد.مهمترین نرم افزاری در سیستم پایگاه داده است که به عنوان رابط بین پایگاه داده و کاربر و برنامه های کاربردی عمل می نماید.برنامه رایانه‌ای که برای مدیریت و پرسش و پاسخ بین پایگاه‌های داده‌ای استفاده می‌شود.این سیستم، کنترل امنیت و صحت پایگاه دادهها را نیز بر عهده دارد.

وظایف DBMS ها

زبان تعریف داده ها - DDL - Data Definition Languageزبان پردازش و مدیریت داده ها - DML - Data Manipulation Languageدیکشنری داده ها - Data Dictionary

فهرستی ازDBMS  ها

OracleMicrosoft SQL ServerMySQLPostregSQLDB2Microsoft Access

مجوزهای دسترسی درDBMS

ﺷﺎﯾﻊ ﺗﺮﯾﻦ ﺁﺳﻴﺐ ﭘﺬﯾﺮﯼ های ﭘﺎﯾﮕﺎﻩ داده

نزدیک به نیمی از ضعف های امنیتی به طور مستقیم یا غیر مستقیم مربوط به سهل انگاری در شیوه های مدیریت وصله ها می باشد. محافظت از دیتابیس جزء کارهای آسان و سهل الوصول در نظر گرفته می شود، اما اغلب این حملات هستند که از ساده ترین آسیب پذیری ها موفق به عجیب ترین رخنه های امنیتی شده و خسارات زیادی به بار می اورند. در این بین شرکت هایی که به رعایت اصول اولیه امنیت داده ها و فناوری اطلاعات پایبند هستند بیشترین تلاش ها را برای محافظت از امنیت پایگاه داده خود معطوف می کنند.

بر اساس صحبت های آقای الکس روثَکر (Alex Rothacker)، سرپرست تیم امنیت نرم افزاری شرکت SHATTER ( حروف مخفف ابتکارات امنیتی در زمینه تکنولوژی تست نرم افزار برای تحقیقات پیشرفته) ، تیم او در حین کارهای مختلف خود توانسته 10 مورد از آسیب پذیری های مشترک پایگاه داده را شناسایی کنند که سبب رخنه هکر ها و وارد آمدن خسارات سنگین به ادارات و سازمان ها برای بارها و بارها شده اند. در این مقاله قصد پرداختن به این موارد را داریم.

پیام مشترکی که در این لیست با آن مواجه می شوید این است که به ندرت می توان پایگاه داده ها را در زمانی، بی نقص و غیر قابل نفوذ از نظر امنیتی به حساب اورد، و هرگز نباید خوش باورانه تصور کرد که یک بار پیکربندی امنیتی آن، حتی با پیچیده ترین شیوه های امنیتی، می تواند سبب شود تا مدت ها مدیران نیازی به نگرانی در مورد ان نداشته و در عمل امنیت پایگاه داده را فراموش کنند.

پروژه کامل ارشد با موضوع ارزیابی تریگر های فازی در پایگاه داده فعال

فرمت فایل : word (قابل ویرایش) تعداد صفحات : 113 صفحه

فهرست مطالب

بخش اول: مفاهیم و تعاریف، کارهای انجام شده 1

فصل اول: کلیات.. 2

1-1 مقدمه. 2

1-2 مروری بر فصول پایان‌نامه. 5

فصل دوم: پایگاه داده فعال. 6

2-1 مدیریت داده 6

2-2 مدیریت قوانین.. 7

2-2-1 تعریف قانون. 7

رویداد 8شرط.. 12واکنش... 13

2-2-2 مدل اجرایی.. 14

اولویت اجرایی در قوانین.. 16معماری پایگاه دادة فعال. 17آشکارساز رویداد 18ارزیابی شرط.. 19زمانبندی.. 20اجرا 20

2-3 نمونه‌های پیاده‌سازی شده 21

2-3-1 Starburst 21

2-3-2 Ariel 22

2-3-3 NAOS.. 23

2-4 نتیجه. 24

فصل سوم: مفاهیم فازی.. 25

3-1 مجموعه‌های فازی.. 26

3-2 عملگرهای فازی.. 28

3-3 استنتاج فازی.. 29

3-4 ابهام‌زدایی.. 29

3-5 نتیجه. 30

فصل چهارم : پایگاه دادة فعال فازی  31

4-1 تعریف فازی قوانین  32

4-1-1 رویداد فازی 33

رویدادهای مرکب 35انتخاب فازی اجزاء رویدادهای مرکب 37

4-1-2 شرط فازی  37

4-1-3 واکنش فازی  39....

4-1-4 تعیین فازی موقعیت زمانبندی 40

4-2 معماری و مدل اجرایی قوانین 42

4-2-1 آشکارساز رویداد 43

4-2-2 بررسی شرط 44

4-2-3 اجرا  44

4-2-4 زمانبندی  44

4-3 نتیجه  46

بخش دوم: کاربردی جدید از تریگر فازی، رونوشت برداری فازی، نتایج آزمایشات ...... 47

فصل پنجم: رونوشت برداری فازی 48

5-1 رونوشت برداری  49

5-1-1 رونوشت برداری همگام 49

5-1-2 رونوشت برداری ناهمگام 50

5-1-3 ماشین پایه رونوشت برداری داده51

5-1-4 مقایسه دو روش همگام و ناهمگام52

5-2 رونوشت برداری فازی 55

5-2-1 استفاده از تریگرها برای فازی نمودن رونوشت برداری 56

5-3 کمیت سنج های فازی 58

5-3-1 روش محاسبه کمیت سنج های فازی59

5-3-2 کمیت سنج عمومی60

5-3-3 کمیت سنج جزئی63

5-3-4 کمیت سنج جزئی توسعه یافته66

5-4 روش جدید محاسبه حد آستانه در تریگرهای فازی برای رونوشت برداری فازی68

5-5 معماری ماشین رونوشت بردار فازی70

5-6 مثال 72

5-7 کارایی 76

5-7-1 ترافیک در رونوشت برداری مشتاق78

5-7-2 ترافیک در رونوشت برداری تنبل79

5-7-3 ترافیک در رونوشت برداری فازی79

5-7-4 مقایسه تئوری هزینه رونوشت برداری فازی و تنبل 80

5-8 جمع بندی 82

فصل ششم: پیاده سازی  83

6-1 Fuzzy SQL Server 83

6-2 عملکرد اجزای Fuzzy SQL Server84

6-3 پیاده سازی تریگرهای فازی در پایگاه داده غیر فازی85

6-4 اجزاء تریگر فازی در پایگاه داده غیر فازی86

6-5 جداول سیستمی مورد نیاز86

6-6 مثال 88

6-7 کارهای آتی 93

مراجع و منابع  94

واژه نامه لاتین  96

واژه نامه فارسی  98

فصل اول: کلیات 1-1 مقدمه

با ایجاد سیستم‌های مدیریت پایگاه داده عمده مشکلات ساختار، پشتیبانی و مدیریت داده‌های حجیم در سیستم‌های فایلی برطرف شد اما توجهی به جنبه‌های رفتاری پایگاه داده نشد. به این معنا که با استفاده از قیود جامعیت[1]  شاید بتوان از منفی شدن مبلغ حقوق کارمندان جلوگیری نمود اما نمی‌توان مانع از بیشتر شدن حقوق آن‌ها از مدیرانشان شد. در چنین مواردی کاربران پایگاه داده با اجرای یک پرس و جو[2]  موارد نقض محدودیت‌هایی از این قبیل را پیدا نموده و خود اقدام به اصلاح آن‌ها می‌نمایند.

مواردی این چنین و نیز گزارشات مدیریتی در آغاز ماه از جمله کارهای مشخص و دارای ضابطه‌ای می‌باشند که انجام آن‌ها تکراری و قابل تفویض به سیستم است.

کاربران غیرمجاز با استفاده از یک سری گزارشات، غیرمستقیم به اطلاعات کلیدی دست یافته و اقدام به تغییر آن‌ها می‌نمایند. پیدا نمودن چنین تغییراتی که معمولاً بعد از گزارشات اتفاق می‌افتند، به راحتی امکان‌پذیر نیست. همانطور که مشاهده می‌شود در یک پایگاه داده معمولی ردیابی رویدادهایی که در سیستم اتفاق افتاده‌اند (رخدادها) نیز ممکن نبوده و نیاز به یک سیستم با پشتیبانی جنبه‌های رفتاری می‌باشد.

یک پایگاه داده فعال نظیر Oracle قادر به تشخیص رویدادهای نظیر اضافه، حذف و تغییر مقادیر در پایگاه داده می‌باشد. به عبارت دیگر این سیستم‌ها با ایجاد تغییر در یک قلم داده عکس‌العمل نشان می‌دهند.

پایگاه دادة فعال با افزودن قوانین به پایگاه‌های داده امکان تعامل (کنش و واکنش) بین سیستم و پایگاه داده را ایجاد نمود. این نوع پایگاه داده دارای دو بخش مدیریت داده و مدیریت قوانین می‌باشد. بخش مدیریت داده مسئول حفظ خواص پایگاه داده در سیستم‌های کاربردی بوده و بخش دوم با مدیریت قوانین مسئول واکنش به رویدادهای سیستم می‌باشد. در این نوع پایگاه داده طراحان سیستم قادرند با تعریف قوانین که نزدیکترین بیان به زبان طبیعی می‌باشد، سیستم را وادار به عکس‌العمل مناسب در مقابل رویدادهای مهم نمایند [13].

پایگاه داده فعال با استفاده از قوانین قادر به «پشتیبانی گسترده‌تر قیود جامعیت و سازگاری داده‌ها، واکنش در مقابل رخدادهای سیستم کاربردی، عدم اجرای تقاضاهای مشکوک، ردیابی رویدادها، گزارشات ماهانه و...» می‌باشد.

همانطور که گفته شد آنچه که به طور معمول باعث می‌شود یک پایگاه داده را فعال بدانیم، عکس‌العمل سیستم در مقابل وضعیت‌هایی است که در پایگاه داده و یا حتی خارج از آن به وجود می‌آید. این وضعیت‌ها می‌تواند شامل یک حذف غیرمجاز و یا تغییر وضعیت پایگاه داده باشد. باید توجه داشت که داشتن تعامل برای یک پایگاه داده لازم اما کافی نیست. بسیاری از سیستم‌های پایگاه داده با رعایت اصول پایه‌ای که در زیر به آن اشاره می‌شود به طور عام پایگاه دادة فعال نامیده می شوند [14].

اینگونه سیستم‌ها باید یک پایگاه داده باشند، یعنی در صورتی که کاربر فراموش کرد، سیستم مورد نظر پایگاه دادة فعال است بتواند از آن به عنوان یک پایگاه داده معمولی استفاده نماید (در صورت لزوم بتوان به عنوان یک پایگاه دادة معمولی از آن استفاده نمود).

در اینگونه سیستم‌ها باید امکان تعریف و مدیریت قوانین وجود داشته باشد. این قوانین در پایگاه داده فعال دارای سه جزء رویداد[3]، شرط[4] و واکنش[5] می‌باشند.

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

علاوه بر موارد فوق، بهتر است در این سیستم‌ها محیط مناسبی برای تعریف و امکان کامپایل کردن قوانین فراهم شود که به کاربر در تعریف قوانین کمک کند.

فازی‌سازی پایگاه‌های داده فعال با هدف نزدیکتر نمودن زبان بیان قوانین به زبان طبیعی طراحان مطرح شد. اغلب تقاضاهای کاربران پایگاه داده فعال، فازی می‌باشد. به عنوان نمونه در تقاضاهایی نظیر عدم تعلق پاداش به کارمندان «کم‌کار»، «افزایش» فشارخون، محاسبة حقوق کارمندان در «پایان» هر ماه و... از کلمات فازی استفاده شده است که عدم پشتیبانی مفاهیم فازی و به کار بردن مقادیر دقیق منجر به حصول نتایج نامطلوب در برخی سیستم‌های کاربردی می‌شود.

تفاوت اصلی در فازی‌سازی پایگاه دادة فعال با سایر سیستم‌های فازی، در نوع تعریف قوانین می‌باشد. به این ترتیب که در تعریف قوانین در اینجا از سه جزء اصلی رویداد، شرط و واکنش استفاده می‌شود در صورتی که سیستم‌های مبتنی بر قانون عموماً از دو جزء شرط و واکنش تشکیل شده‌اند اما فازی نمودن شرط و واکنش قوانین در پایگاه‌های داده فعال تفاوت چندانی با شرط و واکنش فازی در سیستم‌های مبتنی بر قانون ندارد و در فازی نمودن رویداد نیز می‌توان از همان سیاق رویدادهای فازی استفاده نمود این بحث توسط ولسکی و بوازیز در [7] مطرح شده است.

در این پایان‌نامه سعی شده است بحث‌های مطرح شده در پایگاه‌های داده فعال فازی بطور خلاصه بررسی شود. همچنین در ادامه با معرفی عمل رونوشت برداری و بکارگیری قوانین فازی(تریگرهای فازی) در عمل رونوشت برداری روش بهبود یافته جدیدی معرفی می شود.

 

مقاله کامل در مورد حافظة اصلی پایگاه داده ها

لینک پرداخت و دانلود *پایین مطلب*
فرمت فایل:Word (قابل ویرایش و آماده پرینت)
تعداد صفحه: 54

مقدمه

در اواسط دهه 1980، با نزول قیمت DRAM، این ایده مطرح شد که کامپیوترهای آتی با داشتن حافظه اصلی با ظرفیت بالا، می توانند بسیاری از پایگاه داده ها را درحافظه اصلی داشته باشند. در این شرایط می توان همه I/O ها (که بسیار هزینه بر می باشند) را از پردازش DBMS حذف نمود. بنابراین معماری DBMS دستخوش تغییرات جدی می شود و در یک MAIN MEMORY DBMS(MMDBMS)، مدیریت I/O دیگر نقشی نخواهد داشت.

نکته مهم در یک MMDB، چگونگی انجام تراکنشها و recovery بصورت کارا است. برخی از الگوریتمهای پیشنهادی براساس این فرض عمل می کنند که قسمت کوچکی از حافظه اصلی بصورت ماندگار وجود دارد که اطلاعاتش توسط باطری در صورت قطع برق از بین نخواهد رفت. این قسمت از حافظه اصلی برای نگهداری redo log ها استفاده می شود.

تعداد دیگری از الگوریتمهای پیشنهادی پیش فرض حافظه ماندگار را ندارند و همچنان از عملیات I/O برای نوشتن اطلاعات تراکنش در حافظه ماندگار استفاده می کنند. بنابراین در این الگوریتمها عملیات I/O بطور کامل حذف نمی شود، بلکه تعدادشان بسیار کمتر می شود زیرا  I/Oمربوط به نوشتن اطلاعات صفحات buffer ها، حذف خواهد شد.

در یک MMDBMS، ساختارداده های ساده مانند T-Tree و همچنین bucket-chained hash جایگزین ساختارداده هایی چون B-Tree و linear hash در DBMS های مبتنی بر دیسک می شوند. بنابراین سرعت اجرای پرس و جو(پرس و جو) و بهنگام سازی بسیار افزایش می یابد و هزینه index lookup و نگهداری ،فقط مربوط به  پردازنده و دسترسی به حافظه اصلی خواهد شد.

یکی از مشکلات اصلی در MMDBMS ها بهینه کردن درخواستهاست. عدم وجود I/O به عنوان فاکتور اصلی در هزینه ها به معنای پیچیدگی بیشتر مدل کردن هزینه در یک MMDBMS است زیرا در اینجا یکسری فاکتورهای فازی از قبیل هزینه اجرای  پردازنده ، باید در نظر گرفته شوند. در این حالت باید با استفاده از تعامل روش coding، عوامل سخت افزاری مانند  پردازنده و معماری حافظه و پارامترهای پرس و جو، به یک مدل قابل اطمینان از هزینه اجرا در حافظه اصلی رسید.

در دهه 1990، MMDBMS ها با افزایش سایز دیسکها و سایز مسائل همراه با افزایش ظرفیت DRAM ها، به اوج محبوبیت خود رسیدند. MMDBMS ها اغلب برای برنامه هایی که به پایگاه داده Real Time نیاز دارند (مانند سیستمهای embedded سوئیجهای تلفن) ، استفاده می شود. از آنجایط که سایز حافظه اصلی در کامپیوترها روز به روز در حال افزایش است، این امید وجود دارد که برای بسیاری از پایگاه داده هایی که امروزه امکان قرارگفتن آنها بصورت کامل در حافظه اصلی وجود ندارد، این شرایط مهیا شود.

مدلهای هزینه حافظه اصلی

متاسفانه تا کنون تلاشهای اندکی جهت مدل کردن هزینه کارایی MMDBMSها صورت گرفته است. تحقیقات اولیه روی طراحی ماشینهای پایگاه داده ها، بیشتر در زمینه وابستگیهای میان الگوریتمها و دسترسی حافظه صورت می گرفت.در صورتیکه امروزه به دلیل محدود شدن استفاده از MMDBMS ها به کاربرد در پایگاه داده های Real Time(به صورت پرس وجوهای ساده، مانند یک hash lookup در یک جدول)، اینگونه تحقیقات از اهمیت کمتری برخوردارند.

در تحقیقات اخیر در زمینه MMDBMS ها دو نمونه تحقیقاتی Office-By-Example (OBE) مربوط به شرکت IBM و Smallbase مربوط به شرکت HP مسائل ارزشمندی را درمورد بهینه سازی پرس وجو ها و مدلسازی هزینه حافظه اصلی مطرح کرده اند که در ادامه به بررسی این دو نمونه می پردازیم.

Office-By-Example (OBE)

OBE یک پایگاه داده در حافظه اصلی است که بسیاری از مفاهیمQuery-by-example(QBE)، را گسترش می دهد. برای بهینه سازی پرس و جو، مبتنی بر هزینه، OBE یک مدل کامل از هزینه را ارائه می دهد. باتوجه به این پیش فرض که داده هایی که پردازش می شوند در حافظه اصلی قرار گرفته اند، عامل اصلی هزینه در پایگاه داده های متداول که همان دسترسی I/O است حذف خواهد شد.

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

راه حل پیشنهادی، استفاده از روشهای تجربی و روشهای تحلیلی در کنار یکدیگر است.

در ابتدا، bottleneck های سیستم با استفاده از یک تحلیلگرِ اجرا شناسایی می شوند. در این روش تنها bottleneck ها، برای مدلسازی هزینه پردازنده بکار می روند.

البته در این مرحله، بسیار مهم است که bottleneck ها تا حد ممکن توسط تلاشهای معقول اصلاح شوند.

مرحله بعد پیدا کردن وزن نسبی هریک از bottleneck ها و مشخص سازی واحد هزینه آنها توسط روشهای تجربی است.

برای OBE، bottleneck ها و واحدهای هزینه بصورت زیر مشخص می شوند :

ارزیابی expression هایی که در predicate ها آمده اند. (واحد هزینه = C1)عملیات قیاسی که برای مشخص کردن خروجی نهایی predicate ها لازم است. (واحد هزینه = C2)بازیابی یک tuple از یک رابطه موجود در حافظه اصلی. (واحد هزینه = C3)واحد عملیاتِ ساختن شاخص (index) ( ساختن شاخص روی رابطه ای که n تا tuple دارد، nLog2n برابر واحد هزینه دارد. واحد هزینه = C4)واحد عملیات در مرتب سازی ،که در شرایط شاخصهای چند ستونی(multi-column index) مورد نیاز است. (واحد هزینه = C5)

جالبترین نتیجه بدست آمده از آزمایشات این است که، هزینه ارزیابی expression های سیستم، بیشترین هزینه از میان هزینه های مطرح شده در OBE می باشد.در حالیکه C2 تا C5 تقریبا یکسان می باشند، C1 به میزان قابل توجهی بیشتر از آنهامی باشد.

در ادامه به بررسی نمونه Smallbase می پردازیم.

Smallbase

در smallbase، مدل هزینه حافظه اصلی به سه گروه تقسیم می شود:

Hardware-based  

این مدل بسیار شبیه مدل هزینه مبتنی بر I/O در پایگاه داده های متداول است. به جای شمارش عملیات I/O،  تعداد سیکلهای پردازنده شمارش می شود. علیرغم اینکه این روش بسیار ساده به نظر می رسد، از جهت پیاده سازی مشکلات عمده ای وجود دارد.بعلاوه، portability بسیار محدود خواهد شد زیرا این سیاستها میان معماریهای سخت افزار، متفاوت است. در هر حال این مدل بسیار دقیق و قابل لطمینان می باشد.

Application-based

در این روش هزینه ها بر اساس هزینه bottleneck های سیستم بیان می شود.علیرغم اینکه این روش از جهت پیاده سازی بسیار ساده تر از روش hardware-based است، این نوع مدل از عمومیت کمتری برخوردار است.

Bottleneck ها بسیار وابسته به workload ِمورد استفاده برای شناسایی آنها، دارد و بنابراین نمی توان از این روش برای نمایش هزینه های همه انواع پرس و جو استفاده کرد.

در اصل،این مدل نسبت به مدل hardware-based از portability بالاتری (توسط تولید دوباره پروفیل) برخوردار است. به هر حال، این روش نه تنها باعث تفاوت در واحدهای هزینه می شود بلکه مجموعه bottleneck ها هم متفاوت خواهد شد.در این حالت اگر مدل، دستخوش تغییرات شود، هزینه توابعِ هزینه مربوط به عملیات پایگاه داده، باید دوباره بر اساس bottleneck های جدید فرمولسازی شود.

این فقط قسمتی از متن مقاله است . جهت دریافت کل متن مقاله ، لطفا آن را خریداری نمایید

قسمت اول بخش 12آموزش صفر تا صد sql

آموزش صفر تا صد sql

آموزش آسان نوشتن کوئری

قسمت اول بخش 10 آموزش پایگاه داده sql

آموزش صفر تا صد sql

آموزش آسان نوشتن کوئری