תגית: WORM

חדשות לא חדשות בעולם ה SMB/NAS

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

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

אז למי שלא מכיר, היו שני עדכונים בפרוטוקול SMB עצמו שמאד עוזרים בנושאים האלו. כשאר יצא SMB2 יצאה גם תמיכה ב Durable Handles מה שאיפשר העברה חלקה יותר של הסשן במקרה של תחזוקה יזומה והקל על כולנו את נושא השדרוגים. הקליינט יודע פשוט להקים את הסשן מחדש באופן אוטומטי בתום time out קבוע מראש.
השדרוג השני הרלוונטי יצא עם SMB3 שכלל Transparent Failover שידוע גם בשם Continuous Availability שבעצם מאפשר את אותו הדבר גם במקרה של כשל בלתי מתוכנן. אם נפל בקר או שרת הקליינט מתחבר אוטומטי לבקר או השרת החבר בקלסטר והשירות נמשך.

התמיכה ב Durable Handles אוטומטית בשירותי הקבצים של Nutanix אבל את Continuous Availability צריך להפעיל ברמת ה Share. כמובן שצריך גם שהקליינט או האפליקציה יתמכו וידברו בגרסת הפרוטוקול המתאים ואם אתם עובדים על מעבדה שמוגדר בה שרת קבצים יחיד האופציה לא תהיה זמינה להפעלה ואין טעם לפנות להנדסה בשאלות כמו אנשים אחרים שאתה מכירים שיש להם בלוג.

החידוש השני שאני רוצה לספר לכם עליו, גם הוא לא מאד מאד חדש אבל גם אותו לא כולם מכירים, הוא file base WORM או Write Once Read Many, היכולת להכיל מנגנון נעילה להגנה על קבצים מפני שינוי או מחיקה.

לקוחות רבים, בעיקר לקוחות פיננסים שעובדים מול הרגולטורים האמריקאים אבל לא רק, מכירים את דרישות SEC17 (כן כן אני יודע SEC17a-4(F)), להוכיח יכולת להגנה על מידע פיננסי למשך פרק זמן קבוע אז זו אחת הדרכים ליישם הגנה כזו. אנחנו מגדירים ברמת ה share שאנחנו רוצים שקבצים ינעלו מפני שינוי או מחיקה למשך פרק הזמן המתאים ושימו לב שאנחנו יכולים גם להגדיר משך "צינון" כלומר שהנעילה תתחיל רק אחרי פרק זמן שחלף בלי שנגעו בקובץ ככה לא ננעל קובץ שעדיין יוצרים אותו כמו הפוסט הזה שלקח לי שלושה ימים לכתוב.

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

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

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

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

בברכת בשורות טובות,

שישובו כל החטופים והחטופות במהרה אמן וכל החיילים והחיילות בריאים ושלמים!

שלכם כרגיל,

ניר מליק

Spoiler! Dune, Ogres, Onions and Cyber-Sec

זהירות ספוילרים!

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

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

מנחשים כבר איזה סרט זה היה?

ובכן, ראינו את Dune: part one ולא היה לנו מושג שזה רק part one!

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

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

כאן מתחיל הספויילר, זהירות!!!

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

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

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

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

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

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

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

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

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

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

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

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

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

שלכם כמו תמיד,

ניר מליק