סוג ניתוח מערכת מיגון קביעת גישה מכריח בעבור אורקל DBMS






833



סיכום:

עמוד הגיע מוקדש לניתוח ערכת מיגון חובת תיחום גישה בעבור אורקל DBMS. כתוצאה מכך מתגלים 10 ערוצי דליפה.





מילות מפתח:


בקרת גישה, אבטחת מסדי פרמטרים, גישה מחייב, אורקל DBMS, מודל גישה מחייב, אבטחת תווית על ידי אורקל






גוף המאמר:

מאמר הגיע מוקדש לניתוח רשת חובת הגבלה של גישה בשביל אורקל DBMS. בגלל מכך מתגלים 10 ערוצי דליפה.



בעבור מערכות מידע רבות המבוססות הכול על DBMS לעיתים קרובות תקלה ליישם הגבלה של גישה, אשר מבקש בחשבון רק את משמעות הידע. הגיע לרוב כדאי למערכות מידע רחבות איזור של ממשל או גם תאגיד (כלומר מוצרים תכנון גיאוגרפיות או אולי ציוד האורטופדי ניהול מסמכים). רשת כזאת מרמזת ברוב המקרים המתארת את מודל גישה חובה. זכוכית שבירה התכונות של המודל המחייב מהווה מניעה על ידי ירידה מכוונת או אולי מקרית בקרב חיוניות החומר הודות ל בקרת כניסת הידע. מודל גישה חובה מיושם על ידי תיוג יותר מידי המאפיינים והחפצים השייכים למערכת הגבלת הגישה.



אורקל DBMS היא בעצם בימים אלו אחד מה- DBMS התעשייתי החזק והפופולרי מאוד. כבר החל מגרסת Oracle9i, פקטור Oracle Label Security (OLS) נעשה, הנושא הנותן אפשרות לרכוש גישה מכריח לנתונים המאוחסנים. OLS הוא ערכה ל נהלים ומגבלות המובנים בליבת מסד הנתונים, המחברים יישום של בקרת גישה באיכות הרשומה. על מנת לתת סיוע OLS עליכם לעצב מדיניות אבטחה הכוללת קבוצת תוויות. לכל פעם שנוצרת מדיניות זאת יש להחיל את אותה אודות טבלאות מוגנות ועל גבי שברשותכם להשיב זכויות על תוויות שוות.

תהליך כירורגי בשביל ערוצי זליגה אפשריים בידי רעיון סודות נראה מרשים בשביל המערכת שנבדקה.

כולנו מספקים את אותו אלגוריתם הניתוח הנפוץ השני של מודל הגישה החובה המיושם.

1) סוגי אובייקטים על ידי גישה נקבעים לפי התיעוד שנחשף וחקירת ה- DBMS (למשל, טבלאות, מחרוזות או לחילופין עמודות).

2) פקודות בידי SQL מנותחות במונחים בידי האופן ובו משתמשים זכאים להשתנות אובייקטי גישה.

3) נוצרים מספר אובייקטים במחיר סוגים סודיות משתנות עבור כל סגנון אובייקט גישה.

4) חמש חשבונות משתמשים (נושא גישה) נוצרים בנות זכויות גישה מחייב משתנות.

5) מיועד רצף של שאילתות SQL שמבוצעות בעלויות זכויות הגדרת גישה משתנות וחובה עם אובייקטים שיש להן כמות סודיות שונה. על פי תהליך ניתוחי ההפקה על ידי שאילתות מסוג זה אפשר לבנות מודל גישה ולקבוע מסקנה והיה אם מושם למערכת פגיעויות העלולות לגרום לדליפה אם ההשחתה אצל מידע סודי.

למה שלא יש אובייקטי גישה ב- OLS. הנ"ל רישומי רשימה, בעלויות תוויות מעטות. בדרך כלל משתמע שכן טבלאות הנישות אובייקט גישה ב- OLS מכיוון שמדיניות האבטחה מוחלת על אודות טבלאות. יחד עם זה, בטבלאות אין תוויות עצמן; הינם דבר שבשגרה הוא כוללים שורות שכותרתו.

מעשים ה- SQL הבסיסיות הבאות מטפלות ברשומות בודדות:

- צור הפקת תקליט חדש;

- בחר קריאה על ידי רשומה קיימת;


- כתיבה של אצל שיא קיים;

מחיקת מחיקת רשומה.

הניסויים שלך כללו רצפי שאילתות שנקראו על ידי משתמשים עם זכויות גישה מחייב משתנות לאובייקטים ברמות סודיות שונות. ניסויים אלו אפשרו להרכיב רק את מודל הגישה החובה של OLS לרשומות. כולנו מגדירים נלווה משתנים: I ו- J. I הוא נחיצות בקרב תווית אובייקטים. ערכים זעומים שנתיים אצל I מצביעים הכול על איכות סודיות משמעותית יותר (הערך 0 תואם סודי ביותר). J הינה תשומת לב על ידי רמת הגישה בקרב הנבדקים.

אפשר להראות את המודל בתצוגה הרשמית הבאה:





1. CREATE \ SELECT \ UPDATE \ DELETE, j = i

2. בחר, j i



מודל גישה מחייב שכזו ברמת שיא הינה די מתאים ואותו אחד שדיברנו עשוי בקריטריונים בקרב מודל האבטחה בקרב בל-לה פדולה. אם כן OLS עובד הולם ברמה רישומי הטבלה.

עם זאת, לצד מספרי כייצוג על ידי נתונים מאוחסנים, משתמשים בעלי זכאות לתקשר אלו שיש להן חסות תוספים אחר, לא תלויים ממדיניות הגישה החובה. שולחנות הם דוגמה לאובייקטים אלו. פרטים מאוד הינו יכולים להשתנות את אותן סדר הטבלאות, בקיצור להתקין שדות מתחילים, להשתנות את כל שמם ולשנות את סוגי הפרטים. OLS מאבדת את אותם יכולתה לפעול כראוי באיכות השולחן.

שירותי תמלול והקלדה , למשתמש עם זכויות מחייב גבוהות מאוד 2 שנים מתופעל דרך לתכנן שדה חדש בטבלה. שם טוב השדה עומד לקחת חסוי לבדו, ומנגנון OLS לא מונע מלאכה הינה. למשתמש שיש להן זכויות גישה לא יקרות בהכרח שאפשרי לשאול שמות בקרב בכל השדות.

לדוגמא, נועד שדה אידיאלי אשר נקרא new_password_xxx (כאשר xxx היא עיצוב סודות ביותר) אלו שיש להן שאילתת ה- SQL הבאה:

שנה אחת אחר הטבלה user1.test_table ADD (new_password VARCHAR2 (30));

והיה אם נעזר אחר שאין בו לו זכויות מכריח תאריך את אותה השאילתה האמורה (SELECT * FROM user1.test_table;), הנו לוקח מערכת מיגון דגשים ריקה, אמנם יותר מידי שמות השדות ofuser1.test_table נחשפים בפניו. כמו שהוצג כאן, שם העמודה מסוגל להכיל ארגון מסווג.

פעולות המוצגות בדוגמה יוצרות ערוצי דופלקס של חילופי אלמנטים בין נושאים המחזיקים זכויות גישה חריגות ונמוכות יותר, ומשום כך הינם יכולים ולהעניק לדליפה על ידי תכנון מסווג.

בסוגיית הנאום מתחילה, מודל הגישה החובה המיושם באורקל כלל מדהים, ועובדה זו מעניקה להחליף מידע מסווג ללא כל שליטה בצנרת הגישה החובה, הביקוש שמקטין את חשיבות הידע הנדרש.

כמו כן, אפשר לקרוא על אודות הטכניקות למעשה לאימות חתימת מקלדת ביומטרית מאתרנו: http://www.allmysoft.com/biometric-keyboard-signature-authentication.html