שיקולי אבטחה

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

שיקולי אבטחה ברשתות

‫Google Cloud NetApp Volumes מספק מסגרת ארכיטקטונית מוגנת עם שכבות האבטחה המבודדות הבאות:

  • אבטחה ברמת הפרויקט: שכבת האבטחה האדמיניסטרטיבית שאדמינים משתמשים בה כדי לנהל משאבים של NetApp Volumes כמו מאגרי אחסון או נפחים באמצעות מסוף Google Cloud , Google Cloud SDK או ממשקי API. תפקידים והרשאות של IAM מגנים על השכבה הזו. מידע נוסף על אבטחה ברמת הפרויקט זמין במאמר הגדרת הרשאות ב-IAM.

  • אבטחה ברמת הרשת: שכבת הרשת שמשמשת לגישה לנפחי נתונים באמצעות פרוטוקולים של אחסון ברשת (NAS) (פרוטוקול SMB‏ (SMB) ומערכת קובצי רשת (NFS)).

    אפשר לגשת לנתונים בתוך נפחים באמצעות פרוטוקולי NAS דרך רשת של ענן וירטואלי פרטי (VPC). כל הגישה לנתונים ב-NetApp Volumes אפשרית רק דרך ה-VPC שלכם, אלא אם אתם משתמשים במפורש בפתרון של צד שלישי כדי להחליף את הניתוב של VPC peering ל-VPC שלכם.

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

כללי חומת אש לגישה לנפחים

כללי חומת אש מגנים על Google Cloud VPC. כדי לאפשר גישה של לקוחות ל-NetApp Volumes, צריך לאפשר תנועת רשת ספציפית.

למידע נוסף על כללים של חומת אש לגישה לנפחי NFS,‏ SMB ו-iSCSI, אפשר לעיין בסעיפים הבאים:

כללי חומת אש לגישה ל-Active Directory

ל-NetApp Volumes נדרשת גישה ליציאות הבאות בשרתי ה-DNS שהוגדרו במדיניות Active Directory כדי לזהות בקרי דומיין של Active Directory. ב-NetApp Volumes נעשה שימוש בשאילתות DNS כדי לגלות את בקר הדומיין של Active Directory.

  • ICMPV4

  • DNS 53 TCP

  • DNS 53 UDP

צריך לפתוח את הפורטים הבאים בכל בקרי הדומיין של Active Directory כדי לאפשר תנועה שמקורה בטווח ה-CIDR של NetApp Volumes:

  • ICMPV4

  • LDAP 389 TCP

  • SMB over IP 445 TCP

  • Secure LDAP 636 TCP

  • Kerberos 464 TCP

  • Kerberos 464 UDP

  • Kerberos 88 TCP

  • Kerberos 88 UDP

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

צירוף תג חומת אש לשרתים של Active Directory

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

  1. מצרפים את כלל חומת האש לשרתי ה-DNS של Active Directory:

    gcloud compute firewall-rules create netappvolumes-to-dns \
  --allow=icmp,TCP:53,UDP:53 \
  --direction=ingress \
  --target-tags=allow-netappvolumes-to-dns \
  --source-ranges=NETAPP_VOLUMES_CIDR \
  --network=VPC_NAME

  2. מצרפים את כלל חומת האש לבקרי הדומיין של Active Directory:

    gcloud compute firewall-rules create netappvolumes-to-activedirectory \
  --allow=icmp,TCP:88,UDP:88,TCP:389,TCP:445,TCP:464,UDP:464,TCP:636 \
  --direction=ingress \
  --target-tags=allow-netappvolumes-to-activedirectory \
  --source-ranges=NETAPP_VOLUMES_CIDR \
  --network=VPC_NAME

    מחליפים את המידע הבא:

    • ‫NETAPP_VOLUMES_CIDR: ה-CIDR של NetApp Volumes

    • ‫VPC_NAME: השם של ה-VPC

  3. מצרפים את התג הבא לשרתי ה-DNS:

    allow-netappvolumes-to-dns

  4. מצרפים את התג הבא לבקרי הדומיין:

    allow-netappvolumes-to-activedirectory

אמצעי בקרה לגישה לנפח אחסון לפרוטוקולי NFS

‫NetApp Volumes מגן על הגישה באמצעות פרוטוקולי NFS עם מדיניות ייצוא יחידה שכוללת עד 20 כללי ייצוא. כללי הייצוא הם רשימות של כתובות IPv4 ו-CIDR של IPv4, מופרדות בפסיקים, שמציינות לאילו לקוחות יש הרשאה לטעון נפחים. מערכת NetApp Volumes מעריכה את כללי הייצוא בסדר עוקב ומפסיקה אחרי ההתאמה הראשונה. כדי לקבל את התוצאות הטובות ביותר, מומלץ לסדר את כללי הייצוא מהספציפי ביותר לכללי ביותר. מידע נוסף על כללי ייצוא זמין במאמר בקרת גישה לנפח באמצעות מדיניות ייצוא.

אמצעי בקרה לגישה לעוצמת הקול בפרוטוקול SMB

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

כרכים נוצרים עם הרשאות ברמת השיתוף לכולם וגישה מלאה. אפשר לשנות את ההרשאות ברמת השיתוף באמצעות מסוף Windows או CLI של Windows.

כדי לשנות את ההרשאות ברמת שיתוף ה-SMB באמצעות מסוף Windows או CLI של Windows, פועלים לפי ההוראות הבאות:

מסוף Windows

  1. לוחצים לחיצה ימנית על הסמל Windows start ובוחרים באפשרות Computer Management (ניהול המחשב).

  2. אחרי שמסוף Computer Management (ניהול המחשב) נפתח, לוחצים על Action (פעולה) > Connect to another computer (התחברות למחשב אחר).

  3. בתיבת הדו-שיח Select Computer, מזינים את שם ה-NetBIOS של שיתוף ה-SMB ולוחצים על OK.

  4. אחרי שמתחברים לשיתוף הקבצים, עוברים אל System Tools (כלי מערכת) > Shared Folders (תיקיות משותפות) > Shares (שיתופים) כדי לחפש את השיתוף שלכם.

  5. לוחצים לחיצה כפולה על Share Name (שם השיתוף) ובוחרים בכרטיסייה Share Permissions (הרשאות שיתוף) כדי לשלוט בהרשאות של השיתוף.

Windows CLI

  1. פותחים שורת פקודה של Windows.

  2. מתחברים לשיתוף הקבצים.

    fsmgmt.msc /computer=<netbios_name_of_share>

  3. אחרי שמתחברים לשיתוף הקבצים, עוברים אל System Tools (כלי מערכת) > Shared Folders (תיקיות משותפות) > Shares (שיתופים) כדי לחפש את השיתוף שלכם.

  4. לוחצים לחיצה כפולה על Share Name (שם השיתוף) ובוחרים בכרטיסייה Share Permissions (הרשאות שיתוף) כדי לשלוט בהרשאות של השיתוף.

אמצעי בקרה לגישה לעוצמת הקול בפרוטוקול iSCSI

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

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

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

  • שליטה בהרשאות צפייה: קבוצות המארחים מגבילות את הלקוחות של iSCSI שיכולים לראות ולגשת לנפחי אחסון ספציפיים. אם המארח לא שייך לקבוצת מארחים, הוא לא יכול לגלות את ה-LUN או להתחבר אליו.

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

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

הרשאות מערכת קבצים שמבוססות על מארח

אחרי שממפים LUN למארח, מערכת ההפעלה של המארח אחראית לניהול ההרשאות של מערכת הקבצים ובקרות הגישה. לדוגמה, מארחי Windows משתמשים בהרשאות NTFS וברשימות ACL, ומארחי Linux ו-UNIX משתמשים בהרשאות קבצים סטנדרטיות של UNIX, ואופציונלית ברשימות ACL, כדי להגן על קבצים וספריות.

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

בקרת גישה לקבצים

בקטעים הבאים מפורטות בקרות הגישה ברמת הקובץ של NetApp Volumes.

סגנון אבטחה של נפח אחסון

‫NetApp Volumes מציע שני סגנונות אבטחה לנפחי אחסון, UNIX ו-NTFS, כדי להתאים לקבוצות ההרשאות השונות של פלטפורמות Linux ו-Windows.

  • ‫UNIX: אמצעי בקרת הגישה לקבצים בכרכים שמוגדרים עם סגנון האבטחה UNIX מבוססים על ביטים של מצב UNIX ועל רשימות של בקרת גישה (ACL) של NFSv4.

  • ‫NTFS: אמצעי אחסון שהוגדרו עם סגנון אבטחה של NTFS משתמשים ברשימות ACL של NTFS כדי לשלוט בגישה לקבצים.

סגנון האבטחה של הווליום תלוי בבחירת הפרוטוקול של הווליום:

סוג הפרוטוקול סגנון אבטחה של נפח אחסון
NFSv3 UNIX
NFSv4.1 UNIX
שניהם (NFSv3 ו-NFSv4.1) UNIX
SMB NTFS
כפול (SMB ו-NFSv3) UNIX או NTFS
כפול (SMB ו-NFSv4.1) UNIX או NTFS

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

בקרת גישה ברמת הקובץ ב-NFS לנפחים בסגנון UNIX

אחרי שלקוח מתקין נפח אחסון בהצלחה, NetApp Volumes בודק את הרשאות הגישה לקבצים ולספריות באמצעות מודל ההרשאות הסטנדרטי של UNIX שנקרא mode bits. אפשר להגדיר ולשנות הרשאות באמצעות chmod.

בנוסף, אפשר להשתמש ברשימות של בקרת גישה (ACL) ב-NFSv4. אם לקובץ או לספרייה יש גם ביטים של מצב וגם רשימת ACL של NFSv4, המערכת משתמשת ברשימת ה-ACL כדי לבדוק את ההרשאות. אותו עיקרון חל על נפחים שמשתמשים גם ב-NFSv3 וגם ב-NFSv4.1. אפשר להגדיר ולשנות רשימות ACL של NFSv4 באמצעות nfs4_getfacl ו-nfs4_setfacl.

כשיוצרים נפח חדש בסגנון UNIX, ל-root:root יש בעלות על צומת השורש (root inode) והרשאות 0770. בגלל ההגדרה הזו של הבעלות וההרשאות, משתמש שאינו root מקבל שגיאה permission denied בזמן הגישה לנפח אחרי ההרכבה. כדי לאפשר למשתמשים שאינם משתמשי root לגשת לנפח, משתמש root צריך לשנות את הבעלות על צומת ה-inode של ה-root באמצעות chown ולשנות את הרשאות הקובץ באמצעות chmod.

בקרת גישה לקבצים ב-SMB לנפחי אחסון בסגנון NTFS

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

מיפוי משתמשים בכמה פרוטוקולים

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

כשיוצרים נפח אחסון עם פרוטוקול כפול של SMB ו-NFS, מומלץ מאוד ש-Active Directory יכיל משתמש ברירת מחדל. משתמש ברירת המחדל משמש כשלקוח NFS שולח קריאה ל-NFS עם מזהה משתמש שלא זמין ב-Active Directory. לאחר מכן, המערכת של NetApp Volumes מנסה לחפש משתמש בשם pcuser, שמוגדר כמשתמש ברירת מחדל ב-UNIX. אם המשתמש לא נמצא, הגישה לשיחת ה-NFS נדחית.

מומלץ ליצור משתמש ברירת מחדל ב-Active Directory עם המאפיינים הבאים:

  • ‫uid = pcuser

  • ‫uidnumber = 65534

  • ‫cn = pcuser

  • ‫gidNumber = 65534

  • ‫objectClass = user

בהתאם לפרוטוקול שבו משתמש הלקוח (NFS או SMB) ולסגנון האבטחה של אמצעי האחסון (UNIX או NTFS), אפשר לבדוק ישירות את הרשאות הגישה של המשתמש ב-NetApp Volumes, או שצריך למפות קודם את המשתמש לזהות בפלטפורמה השנייה.

פרוטוקול גישה סגנון אבטחה הזהות שמשמשת את הפרוטוקול מיפוי נדרש
NFSv3 UNIX מזהה משתמש ומזהה קבוצה לא רלוונטי
NFSv3 NTFS מזהה משתמש ומזהה קבוצה מזהה משתמש לשם משתמש למזהה אבטחה
SMB UNIX מזהה אבטחה מזהה אבטחה לשם משתמש למזהה משתמש
SMB NTFS מזהה אבטחה לא רלוונטי

כשמיפוי נדרש, NetApp Volumes מסתמך על נתונים שמאוחסנים ב-Active Directory LDAP. מידע נוסף זמין במאמר בנושא תרחישים לדוגמה לשימוש ב-Active Directory.

תרחיש של מיפוי משתמשים מרובה פרוטוקולים: גישת SMB לנפח UNIX

המדען צ'ארלי אי. ‫(charliee) רוצה לגשת לנפח של NetApp Volumes באמצעות SMB מלקוח Windows. מכיוון שהנפח מכיל תוצאות שנוצרו על ידי מכונה שסופקו על ידי אשכול מחשוב של Linux, הנפח מוגדר לאחסון הרשאות UNIX.

לקוח Windows שולח קריאת SMB לנפח. הקריאה ל-SMB מכילה את זהות המשתמש כמזהה אבטחה. מזהה האבטחה לא ניתן להשוואה להרשאות הקבצים של מזהה המשתמש ומזהה הקבוצה, ונדרש מיפוי.

כדי להשלים את המיפוי הנדרש, NetApp Volumes מבצע את השלבים הבאים:

  1. ‫NetApp Volumes מבקש מ-Active Directory לפתור את מזהה האבטחה לשם משתמש, לדוגמה, S-1-5-21-2761044393-2226150802-3019316526-1224 ל-charliee.

  2. ‫NetApp Volumes מבקש מ-Active Directory להחזיר את מזהה המשתמש ואת מזהה הקבוצה של charliee.

  3. ‫NetApp Volumes בודק את הגישה בהשוואה למזהה המשתמש ולמזהה הקבוצה של הקובץ באמצעות מזהה המשתמש ומזהה הקבוצה שמוחזרים.

תרחיש של מיפוי משתמשים עם ריבוי פרוטוקולים: גישת NFS לנפח NTFS

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

לקוח Linux שולח קריאת NFS ל-NetApp Volumes. הקריאה ל-NFS מכילה מזהים של מזהה משתמש ומזהה קבוצה שלא ניתן להתאים למזהה אבטחה בלי מיפוי.

כדי להשלים את המיפוי הנדרש, NetApp Volumes מבקש מ-Active Directory את שם המשתמש של מזהה המשתמש, ומבקש להחזיר את מזהה האבטחה של שם המשתמש. לאחר מכן, הוא בודק את הגישה מול מזהה האבטחה של הבעלים של הקובץ שאליו ניגשים באמצעות מזהה האבטחה שהוחזר.

הצפנה בזמן ההעברה

הצפנה בהעברה מגנה על הנתונים מפני יירוט ברשת. תעבורת הנתונים של שכפול נפחים, גיבוי משולב והעברת נפחים מוצפנת כברירת מחדל באמצעות TLS 1.2. כדי להוסיף הגנה, אפשר להגדיר הגדרות הצפנה ספציפיות לפרוטוקול עבור תנועה של NFS ו-SMB.

NFS

לנפחי NFS, מומלץ להשתמש ב-NFSv4.1 עם הצפנת Kerberos krb5p מופעלת כדי להשיג אבטחה מקסימלית.

SMB

לנפחי SMB, מומלץ להפעיל הצפנת AES במדיניות Active Directory והצפנת SMB בנפח כדי להשיג אבטחה מקסימלית.

שכפול נפח אחסון

אפשר ליצור רפליקה של נפחים ב-NetApp Volumes בין Google Cloud אזורים כדי לספק הגנה על הנתונים. מכיוון שהתנועה נמצאת ב Google Cloud, תשתית הרשת של Google מגנה על תהליך ההעברה, והגישה אליה מוגבלת כדי למנוע יירוט לא מורשה. בנוסף, תעבורת השכפול מוצפנת באמצעות תקני TLS 1.2 שתואמים ל-FIPS 140-2.

גיבוי משולב

גיבוי משולב יוצר גיבויים של NetApp Volumes בתוך השירות. תעבורת הנתונים של הגיבוי נשארת בתשתית הרשת של Google ומוצפנת באמצעות תקן TLS 1.2 שתואם ל-FIPS 140-2. בכספות הגיבוי אפשר לאחסן את הגיבויים האלה באמצעות Google-managed encryption key כברירת מחדל או באמצעות מפתח הצפנה בניהול הלקוח (CMEK) כדי להוסיף אבטחה.

העברת נפח

העברת נפחים שולחת נתונים ממערכת המקור ONTAP או Cloud Volumes ONTAP אל NetApp Volumes. התקשורת בין מערכת המקור לבין NetApp Volumes מוצפנת באמצעות תקני TLS 1.2 שתואמים ל-FIPS 140-2.

‫NetApp Volumes מתחיל את ההעברה ומשתמש בפרוטוקולים ובפורטים הבאים:

  • ICMP

  • ‫10000/TCP

  • 11104/TCP

  • 11105/TCP

מוודאים שחומת אש בין הממשק הלוגי (LIF) של מערכת ONTAP לבין כתובת ה-IP של ההעברה של NetApp Volumes מאפשרת את הפורטים האלה.

המאמרים הבאים

הגנה על NetApp Volumes באמצעות גבולות גזרה לשירות.