הגנה על בסיסי נתונים (Azure Database Security)

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

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

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

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

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

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

אז איך מבצעים הגנה על בסיסי הנתונים? מצמצים חשיפה? ויוצרים חיכוך ממשי עם התוקף?

גישה בהגנה על נתונים

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

גישה מוכרת בהגנה על המידע היא גישת Traffic Light Protocol או בקצרה TLP , ובפירושה הפחות פופולרי גישת הרמזור.

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

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

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

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

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

אדום הוא מידע שהשיתוף בו מצומצם להפצה על בסיס אישי בלבד

התרשים הבא מרכז את שיטת TLP להגנה על מידע לפי מספר נקודות עיקריות 👇

מידע נוסף לגבי TLP בקישור הבא Traffic Light Protocol (TLP) Definitions and Usage | CISA

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

מימוש של גישת TLP או גל גישה אחרת יכול להיעשות ע”י כלי אבטחה שונים, ואם נקח לדוגמה את מודל ההגנה המוכר של Zero-Trust נוכל לראות כי אחד מתוך ששת הפילארים (סיגנלים) הוא Data.

במודל Zero-Trust הנתונים הם חלק נכבד מכל אותם חוקים ותנאים שאיתם אנו עובדים, ובהתאם למודל Zero-Trust אנו אוכפים מדיניות גישה אשר מורכבת מכללים ותנאים מוגדרים מראש, וכאלה שאינם מאפשרים גישה לכל דורש.

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

במערך הגנה על המידע אנו נדרשים לעבוד עם גישה ומתודלוגיה מסוימת בגלל מספר סיבות עיקריות שהפכו את הנתונים למשהו דינמי, אלה הם הסיבות העיקריות:

מידע סטטי הוא מידע שנשאר בנרחב הארגוני בלבד ואינו משותף לגורם חיצוני

מידע בתנועה הוא מידע שנחלק למספר סוגים:

• מידע אשר משותף מתוך המרחב הארגוני ומתוך בסיס נתונים
• מידע ברמת שרת/אחסון ארגוני לגורם חיצוני ומתבסס על קבצים רגילים
• נתונים ברמת משתמש אשר משותפים מתוך אתר ארגוני או אחסון אישי, כדוגמת, SharePoint Online או ODfB.

סיבות נוספות וחשובות בהגנה על המידע הם:

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

מחזור חיים של קבצים ופעולות ברמת הקובץ הפכו להיות קלות תפעול

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

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

אחרי שמבינים היכן נמצא המידע בטבלה של TLP ומהו המודל והכלים שאיתם נעבוד אנו עוברים לדבר הבא והוא אימוץ הגישה לפי מודל הגנה על נתונים מתוך המודל של Defense-in-Depth שבו אנו צריכים להבין שהגנה על המידע היא בנויה על גבי מספר שכבות הגנה שונות וצריכה להיות חלק אינהרנטי ביומיום שלנו.

הגנה בשכבת בסיסי נתונים (Database Security)

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

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

הגנה על המידע נחלקת לנקודות רבות, בהן אפשר למצוא בין היתר את הנקודות הבאות: (נקודות עיקריות)

גישה מבוססת הרשאות וגישת מורשים בלבד אל מול בסיסי נתונים

גישה אפליקטיבית ומורשית בלבד לפי מאפיינים מסוימים, כגון, Row-Level

הצפנה, סיווג ותיוג המידע על נתונים במנוחה או בתנועה

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

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

מניעת דליפת מידע לפי מנגנונים שונים, כגון, ערפול נתונים, מניעת זליגת מידע וכו’

אז איך בונים פרופיל הגנה לבסיסי נתונים?האם אפשרי? בהמשך

שכבות בהגנה על Azure SQL

בסיסי נתונים בשירות Azure יכולים להתבסס על תצורות שונות, כגון תצורות Azure Synapse או SQL Managed וכו’. ולכן בכל צורה שהיא אנו צריכים לממש מודל אבטחה אשר בנוי על מספר מאפיינים: הגנת רשת, ניהול גישה, הגנה מפני איומים וסיכונים והגנה ממשית על הנתונים.

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

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

הדיאגרמה הבאה ממחישה את מודל N-TIER האפליקטיבי שמחולק לפי אזור מפורז (DMZ), שכבה וובית, שכבה עסקית ושכבת הנתונים.

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

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

מידע נוסף Windows N-tier application on Azure – Azure Architecture Center | Microsoft Docs

הגנה על בסיסי נתונים חייבת להיות פעולה קוהרנטית וחלק אינהרנטי בתהליך  אשר בנוי על מודל N-TIER, בגישת TLP וכן במודל Zero-Trust שכן אנו לא רוצים להגיע למצב שבו ייצא שכרנו בהפסדנו.

בהגנה על הרשת אנו חייבים להגן על נתונים שנמצאים בבסיסי הנתונים באמצעות מערכות וכלים כמו Firewall ברמת הרשת שיבצע מניעת גישה לשירות או לשרת על סמך כתובות IP או תעבורת רשת מורשית מראש.(לא מדובר על NSG).

ביישום חוקים על גבי IP Firewall אנו מאפשרים או מונעים גישה לבסיסי הנתונים מול כתובות מקור בכל גישה. כאשר יוצרים שירות SQL כלשהוא בשירות Azure אנו עובדים עם Firewall שניתן ליישום ברמת Database או ברמת Server.

חסימת גישה ברמת Firewall ניתנת לביצוע לפי שני מאפיינים: רמת שירות או רמת בסיס נתונים.

ברמת שרת ניתן ליצור חוקים ברמת שירות המאפשרים גישה לכל בסיסי הנתונים המנוהלים ע”י אותו שירות (או שרת), וכל החוקה נשמרת במיקום Master Database. כלומר, כתובת IP ציבורית המוגדרת מאפשר גישה ללא מגבלה לכל הנתונים.

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

ישנם הבדלים בין הגדרת Firewall ברמת שירות או ברמת בסיס נתונים וכל אחד מהם מתאים לתרחישים ספציפיים.

הנגשה באמצעות Service Endpoint מאפשרת גישה לבסיסי נתונים על סמך אובייקט ספציפי שנקרא Virtual network service endpoints. מטרתו היא לאפשר גישה אל בסיס נתונים מתוך רשת ספציפית ועל סמך זיהוי של רשת מקור ספציפית בלבד.

בכדי לאפשר גישה של Service Endpoint אנו צריכים לממש Service Tag של SQL מול תעברות הרשת של אותו NSG.

היתרון של Service Endpoint הוא שאנו מאפשרים גישה לבסיסי נתונים באופן מאובטל רק מתוך רשת מסוימת עם ניתוב ספציפי שמוגדר מראש כולל מימוש של Private IP.

ניהול גישה הוא עולם מלא של אפשרויות שמאפשר לנו לממש גישה לפי אוטנטיקציה ולפי אוטוריזציה.

גישה ברמת אוטנטיקציה מאפשרת אינטגרציה באמצעות מספר מאפיינים כמו הזדהות מול Azure AD ומימוש מודל Zero-Trust להתניית גישה. האוטנטיקציה יכולה להיעשות ברמת Managed וכן Federated ומול סביבה היברידית מבוסס Azure AD.

לצד אוטנטיקציה ניתן לממש את היכולות הרבות של Azure AD לטובת אוטוריזציה עם Azure AD PIM וכן עם הרחבות של RBAC ואלרח הזדהות ראשונית של משתמש אנו ממדרים את הגישה לפי הצורך של אותו המשתמש ויכולים להגיע עד למצב של גישה ברמת פעולות מסוימות כמו EXECUTE AS. גישת EXECUTE AS היא דוגמה טובה לגישה אפליקטיבית.

גישה והקשחה ברמת שורה באמצעות Row-Level Security או בקצרה RLS. במצב של RLS אנו יכולים לאפשר גישה מצומצמת לפי קונטקסט ידוע מראש ברמת שדות וטבלאות ולפי מאפיינים מסוימים של הגישה, כגון, מדיניות קבוצה, חברות בקבוצה ולפי הקשר ביצוע.

בנוסף לכך ניתן ליישם RLS למצבים שבהם צריך תיוג ספציפי, למשל, לפי פעולות Select + Update או לפי פעולות After השונות. בשני המצבים ניתן לבצע אכיפה כולל חסימת גישה.

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

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

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

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

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

הצפנה בתנועה מאפשרת אכיפת הצפנה באמצעות TLS/SSL לכל הקישוריות מול בסיסי הנתונים ולהבטיח שבכל מעבר וגישה אל הנתונים תתבצע הצפנה.

לפי Best Practices מומלץ ליישם Connection String ברמה האפליקטיבית ולהגדיר חיבור מוצפן ולא להסתמך על תעודה דיגיטלית ברמת השרת. במצב כזה אנו מאלצים את היישום לאמת את אישור השרת ובכך למנוע מהיישום להיות חשוף ופגיע לתוקפים ולתקיפות מסוג  MITM.

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

במימוש של TDE אנו מצפינים אל כל בסיסי הנתונים באמצעות אלגוריתם הצפנה AES, שאינו מחייב אנשי פיתוח לבצע שינויים באפליקציות קיימות.

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

ניהול מפתחות באמצעות AKV מאפשר לנהל את מפתחות ההצפנה באמצעות Azure Key Vault כולל רוטציה של מפתחות, ובמידה והגישה של בסיסי הנתונים מול AKV אינה אפשרית לא ניתן לפענח את המידע של בסיסי הנתונים.

Azure Key Vault מספק פלטפורמה לניהול מפתחות, סיקרטים, תעודות דיגיטלים מימוש מודול אבטחת חומרה (HSM) וכן מאפשרת הפרדת בין ניהול מפתחות לנתונים בכדי לסייע לעמידה בדרישות התאימות לאבטחה.

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

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

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

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

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

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

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

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

מאמרים בנושא אבטחת מידע בענן