- מדיניות אבטחה וגישה לענן קובעת כיצד נתוני ושירותי ענן משמשים, מוגנים ומבוקרים בתוך הארגון.
- מדיניות טובה משלבת סיווג נתונים, בקרת גישה (RBAC/ABAC), הצפנה, תגובה לאירועים ודרישות תאימות.
- ניהול יעיל בסביבות היברידיות ורב-עננים דורש בקרות מאוחדות, אוטומציה, מדדים וסקירת מדיניות מתמשכת.
אם אתם מודאגים שכישלון בענן יעלה לכותרות, אתם צודקים בדאגה. פרצת נתונים בודדת יכולה לעלות מיליונים, להרוס את המוניטין של מותג ולנפץ את אמון הלקוחות והשותפים . החדשות הטובות הן שניתן למתן חלק ניכר מהסיכון הזה באמצעות מדיניות אבטחה וגישה לענן מתוכננות היטב, ומעל הכל, מיושמות היטב.
מדיניות אבטחה וגישה לענן, רחוקה מלהיות מסמך דקורטיבי, היא מפת הדרכים המכתיבה כיצד נעשה שימוש בשירותי ענן, למי יש גישה למה, אילו בקרות קיימות וכיצד להגיב כאשר משהו משתבש . במאמר זה, נפרט, בגישה מעשית מאוד, את כל מה שצריך לדעת כדי לעצב מדיניות זו, להבדיל אותה מהרגולציות, ליישם אותה בסביבות היברידיות ורב-עננים ולשמור עליה מעודכנת לנוכח נוף איומים המשתנה ללא הרף.
מהן מדיניות אבטחה וגישה לענן?
כשאנחנו מדברים על מדיניות אבטחת ענן, אנחנו מתייחסים לקבוצה של הנחיות פנימיות המגדירות כיצד ארגון צריך לפעול בשירותי ענן, מה מותר ומה אסור . הן מהוות את הבסיס להחלטות אבטחה הקשורות ליישומי SaaS, פלטפורמות PaaS ותשתיות IaaS.
מדיניות זו מסבירות כיצד נעשה שימוש וניהול של שירותי ענן, כיצד מוגנים נתונים, אילו בקרות גישה קיימות ומהן תחומי האחריות של כל תפקיד (החל מצוות ה-IT ועד למשתמשים עסקיים). הן אינן רק בדיקת תאימות: הן מעצבות את האופן שבו אנו מעצבים את הארכיטקטורה, מבצעים אוטומציה של פריסות ופותרים אירועים.
יתר על כן, מדיניות חזקה משלבת בקרת גישה לוגית בענן: כללים הקובעים מי מבצע אימות, כיצד כל בקשה מאושרת, ובאילו תנאים הקשריים (זמן, כתובת IP, מכשיר, מיקום) . זה מתחבר ישירות לניהול זהויות וגישה (IAM) ולמודלים כמו RBAC או ABAC.
מדוע מדיניות אבטחת ענן כה חשובה?
האימוץ הנרחב של מחשוב ענן, עבודה מרחוק וסביבות מרובות עננים הגדיל משמעותית את שטח התקיפה . מתקפות סייבר על פלטפורמות ענן זינקו בשנים האחרונות, כאשר קמפיינים של פישינג, תוכנות כופר וניצול תצורות שגויות משחקים תפקיד בולט במיוחד.
בהקשר זה, מדיניות אבטחת ענן משמשת לארגון וניסוח פורמלי של אסטרטגיית ההגנה : היא מזהה איומים, מגדירה את תנוחת האבטחה של הארגון וקובעת את הבקרות המינימליות שיש לעמוד בהן בכל הסביבות, בין אם הן על AWS, Azure, Google Cloud או ענן פרטי.
יש להם גם מרכיב תאימות מרכזי. מסגרות כגון GDPR, HIPAA, PCI DSS, ISO 27001, NIST או ISO/IEC 27017 דורשות בקרות אבטחה וגישה ספציפיות , וביקורות רבות דורשות במפורש מדיניות אבטחה בענן מתועדת ואפילו מדיניות גישה ספציפית.
לבסוף, מדיניות טובה יוצרת יישור קו פנימי: היא מספקת מסגרת ברורה לצוותי IT, אבטחה, עסקים ומשפטיים לקבלת החלטות עקביות (לדוגמה, אילו שירותי ענן ניתן להתקשר בחוזה, כיצד יש להגדיר אותם או אילו נתונים ניתן לאחסן בכל אחד מהם).
הבדלים בין מדיניות פנימית לתקני אבטחת ענן
חשוב להבחין בין שני מושגים שלעתים קרובות מתבלבלים ביניהם: מדיניות אבטחת הענן שנכתבת על ידי כל חברה וכללי או סטנדרטים של אבטחה שנוצרו על ידי ארגונים חיצוניים.
תקנים (למשל, CIS Benchmarks, NIST, ISO 27001, ISO/IEC 27017, ISO 27018, GDPR, PCI DSS או HIPAA ) הם מסגרות ודרישות שהונפקו על ידי גופים מוכרים, רגולטורים או איגודי תעשייה. הם אינם מותאמים לחברה ספציפית ובדרך כלל קובעים בקרות מינימליות, שיטות עבודה מומלצות וחובות משפטיות.
מדיניות פנימית, לעומת זאת, היא מסמכים שנוצרו על ידי הארגון עצמו, מותאמים לנסיבותיו הספציפיות, אשר מתרגמים את הכללים הכלליים הללו להנחיות תפעוליות קונקרטיות : כיצד מסווגים נתונים, כיצד ניתנות הרשאות, איזו הצפנה נדרשת, אילו יומני רישום נאספים וכו'. בעוד שכללים אינם גמישים, המדיניות ניתנת להתאמה אישית ויכולה להתפתח עם העסק.
הבדל מרכזי נוסף טמון בתחולה: אי עמידה בתקן רגולטורי עלולה להוביל לסנקציות משפטיות או כישלון בהסמכות , בעוד שאי עמידה במדיניות פנימית בדרך כלל אינה כרוכה בקנסות חיצוניים, אך היא כרוכה בסיכוני אבטחה ויכולה להוביל לנקיטת צעדים משמעתיים ותוכניות שיפור פנימיות.
רכיבים חיוניים של מדיניות אבטחת ענן
מדיניות מקיפה אינה רק רשימה של כוונות טובות. היא חייבת להיות מובנית בסעיפים ברורים המכסים את כל מחזור החיים של שירותי ענן , החל מזיהוי נתונים ועד לתגובה לאירועים. הסעיפים הנפוצים ביותר הם כדלקמן.
1. מטרה והיקף
המטרה מסבירה מה המדיניות שואפת להשיג: להגן על הסודיות, השלמות והזמינות של נתונים ושירותים בענן ולהבטיח עמידה בתקנות . הצהרה זו משמשת כמדריך לבחירת בקרות וקביעת סדרי עדיפויות למאמצים.
ההיקף מפרט אילו מערכות, נתונים, שירותי ענן, משתמשים ומיקומים חלים עליהם המדיניות . הוא כולל בדרך כלל שירותי SaaS, PaaS ו-IaaS, שרתי ענן ומסדי נתונים, תחנות עבודה הניגשות לענן, כמו גם עובדים, קבלנים וספקים חיצוניים המשתמשים בשירותים אלה.
2. תפקידים, בעלות ואחריות
ללא חלוקת אחריות ברורה, אפילו המדיניות הטובה ביותר חסרת ערך. חיוני להגדיר אילו צוותים משתמשים בענן, מי מגדיר את תצורת האבטחה, מי מבטיח תאימות ומי מקבל החלטות ארכיטקטוניות.
תפקידים אופייניים כוללים: מנהל אבטחת מידע ראשי (CISO), מנהל אבטחת ענן, בעלי נתונים, מנהלי מערכות ומשתמשי קצה . לכל תפקיד צריך להיות אחריות מוגדרת בבירור, במיוחד בנוגע לבקרת גישה, סיווג נתונים, ניהול אירועים ויחסים עם ספקי ענן.
3. סיווג מידע ובקרת גישה
עמוד יסודי הוא סיווג נתונים. על המדיניות להבחין בבירור בין נתונים ציבוריים, פנימיים, סודיים או רגישים, כמו גם סוגים ספציפיים אחרים כגון נתונים פיננסיים, בריאותיים או זהותיים . סיווג זה יקבע את רמת ההגנה הנדרשת עבור כל קבוצת מידע.
סעיף זה מפרט גם מנגנוני בקרת גישה: מודלים כגון MAC, DAC, RBAC ו-ABAC, כמו גם סיומות מבוססות כללים (זמן, כתובת IP, סוג מכשיר, מיקום) . עקרון ההרשאות הנמוכות ביותר ועקרון הצורך לדעת צריכים להיות חובה עבור כל מערכות הענן.
זה מיושם בפועל באמצעות בקרות גישה מבוססות תפקידים (RBAC) בקונסולות של ספקי ענן, מדיניות IAM, רשימות בקרת גישה (ACL), אימות רב-גורמי (MFA) ואינטגרציה עם ספריות כגון LDAP או Active Directory . מדיניות העברת נתונים כלולות גם כן כדי להבטיח הגנה על נתונים במעבר ובמנוחה.
4. הצפנת נתונים
הצפנה היא דרישה קריטית נוספת. המדיניות חייבת לציין את תקני ההצפנה המינימליים המקובלים (למשל, AES-256 במנוחה, TLS עבור נתונים במעבר) , כמו גם את מודל ניהול המפתחות (שימוש בשירותי ניהול מפתחות של ספק או PKI קנייני).
יתר על כן, יש להתייחס לאופן שבו נתונים מוצפנים מטופלים בגיבויים, תהליכי שחזור, ייצוא נתונים ותרחישי פרצות אבטחה . חשוב לכלול המלצות לגבי פסאודו-נימיזציה והצפנה חזקה עבור נתונים רגישים במיוחד, כגון מידע רפואי או פיננסי.
5. תכנון תגובה לאירועים
במוקדם או במאוחר, אירועים יקרו; ההבדל טמון באופן שבו הם מנוהלים. המדיניות חייבת להגדיר בבירור את התהליך לגילוי, דיווח, ניתוח, בלימה, מיגור והתאוששות מאירועים המשפיעים על שירותי ענן.
בדרך כלל מוקם צוות תגובה לאירועים (IRT), עם איש קשר ייעודי, ערוצי תקשורת, הליכי הסלמה ותיאום עם יועצים משפטיים, רשויות אכיפת החוק ומומחים חיצוניים . דרישות הודעה לרשויות הגנת המידע מתוארות גם כן, כולל מועדים אחרונים כגון תקופת 72 השעות שנקבעה בתקנת ה-GDPR, במידת הצורך.
6. ציות, ביקורת והערכת בקרות
על המדיניות לציין בבירור אילו מסגרות תאימות רלוונטיות (GDPR, HIPAA, PCI DSS, NIST, ISO 27001, ISO 27017 וכו') ובאיזו תדירות יבוצעו ביקורות פנימיות וחיצוניות על שירותי ענן.
במקביל, מומלץ לכלול לוח זמנים להערכת בקרת אבטחה: סקירה תקופתית של כללי חומת אש, תצורות IAM, מדיניות הצפנה, יומני רישום ומנגנוני גילוי חדירות . ארגונים רבים עורכים סקירות אלו מדי רבעון וגם מזמינים הערכות חיצוניות מעת לעת.
הסוגים הנפוצים ביותר של אבטחת ענן ומדיניות גישה
בהתבסס על מבנה כללי זה, ארגונים בדרך כלל מפתחים מערכי מדיניות ספציפיים המתמקדים בתחומים שונים של אבטחת ענן . כמה מהנפוצים ביותר הם הבאים.
מצד אחד, יש לנו את מדיניות הגנת הנתונים בענן , אשר מגדירה כיצד מסווגים, מאוחסנים ומוגנים נתונים רגישים, איזו הצפנה מיושמת, כיצד מנוהלים מפתחות וכמה זמן נשמרים הנתונים. זה חיוני לעמידה במסגרות כמו ה-GDPR וחוקים ספציפיים לתעשייה.
שנית, ישנה מדיניות בקרת גישה , הקובעת מי יכול לגשת לאילו משאבי ענן, תחת איזה תפקיד ובאילו תנאים. מדיניות זו מכסה נושאים כגון MFA חובה, יישום קפדני של עקרון ההרשאות הנמוכות ביותר, גישה מותנית המבוססת על כתובת IP או מיקום גיאוגרפי, וכללים להוספה, הסרה ושינוי הרשאות.
מרכיב מפתח נוסף הוא מדיניות התגובה לאירועים , אשר מעמיקה הרבה יותר בגילוי, בלימה והתאוששות מפריצות אבטחה, כמו גם החובה לתעד אירועים, לנתח את הסיבות שלהם וליישם אמצעי מניעה כדי למנוע את הישנותם.
אסור לנו לשכוח מדיניות זהות ואימות , המתמקדת באופן שבו משתמשים, מכשירים ומערכות מאומתים (SSO, MFA, אישורים, אסימוני חומרה, מפתחות SSH וכו'), וגם לא מדיניות אבטחת רשתות ענן , המכסות חומות אש, פילוח, VPN, מיקרו-היקפים, הגנת DNS, הפחתת נזקי DDoS וניטור תעבורה, כולל תעבורה מוצפנת.
לבסוף, לארגונים רבים יש מדיניות התאוששות מאסון והמשכיות עסקית המתמקדת בהבטחת ששירותי ענן יוכלו להתחדש במהירות במקרה של אסונות טבע, התקפות כופר, הפסקות חשמל נרחבות של ספקים או כשלים חמורים בתשתית.
בקרת גישה מבוססת ענן: מודלים ותפעול
בקרת גישה לענן נשענת על שני עמודי תווך: זיהוי ואימות משתמשים (ידיעה מי המשתמש) והרשאה (הגדרת למה הוא יכול לגשת ובאילו תנאים) . זה מושג באמצעות שירותי ספריות ופרוטוקולים כגון LDAP או SAML, בנוסף לפתרונות IAM ספציפיים.
בפועל, משולבים מספר מודלים של בקרת גישה: בקרת גישה חובה (MAC) , שבה המערכת המרכזית קובעת הרשאות (נמצאת בשימוש נרחב בסביבות ממשלתיות); בקרת גישה דיסקרטיונית (DAC) , שבה בעלי משאבים מקצים הרשאות; ובקרת גישה מבוססת תפקידים (RBAC) , המקשרת הרשאות לתפקידים מוגדרים מראש כגון "מנהל", "משאבי אנוש" או "תמיכה".
בנוסף לאלה, קיימת בקרת גישה מבוססת תכונות (ABAC) , אשר מעניקה או שוללת גישה על סמך תכונות משתמש (תפקיד, מיקום, מכשיר), תכונות משאב או תכונות הקשר (זמן, סוג חיבור, מדינה). היא שימושית במיוחד בסביבות ענן מורכבות עם יישומים רבים ודפוסי גישה משתנים.
כדי שכל זה יעבוד, כלי IAM מרכזים את ניהול הזהויות, מתחברים לספריות (LDAP, Active Directory), מאפשרים כניסה יחידה (SSO) ואוכפים MFA במידת הצורך . הם גם מאפשרים הקצאה וביטול הקצאה אוטומטיות של חשבונות, דבר קריטי למניעת חשבונות יתומים או הרשאות מוגזמות.
כיצד ליישם ביעילות מדיניות אבטחה וגישה בענן
המעבר מתיאוריה למעשה דורש גישה מובנית. הצעד הראשון הוא להבין לעומק את מעמד הארגון בתחומו, את רמת הסיכון המקובלת שלו ואת דרישות הרגולציה שלו . משם, מוגדרות יעדי המדיניות, ומתקבלת החלטה האם להתחיל מאפס או לעדכן תיעוד קיים.
בשלב הבא, חשוב לזהות אילו כללי ותקני תאימות חלים על הארגון (למשל, GDPR באירופה, HIPAA בתחום הבריאות, PCI DSS לתשלומי כרטיסי אשראי, NIST CSF, ISO/IEC 27017 לבקרות ענן ספציפיות וכו') ולהבטיח שהמדיניות הפנימית תואמת אותם.
מומלץ לתכנן אסטרטגיית ניסוח ואישור ברורה : מי מנסח את המדיניות, אילו מחלקות בודקות אותה (אבטחה, משפט, משאבי אנוש, עסקים), כיצד מתועדים השינויים, ולוחות הזמנים לאישור ויישום המדיניות. הבטחת תמיכת ההנהלה הבכירה כבר מההתחלה מפחיתה את ההתנגדות הארגונית.
היבט חיוני נוסף הוא ניתוח יסודי של ספקי שירותי ענן : אילו אישורים יש להם (ISO 27001, 27017, 27018 וכו'), באילו מדינות מאוחסנים הנתונים, אילו כלי אבטחה מקוריים הם מציעים (PKI, חומות אש, SIEM, סריקת פגיעויות, יומני ביקורת וכו') וכיצד הם משתלבים עם הארכיטקטורה הקיימת.
לאחר הבנת הסביבה, יש צורך לתעד את סוגי הנתונים המעובדים בענן (לקוחות, עובדים, פיננסיים, תפעוליים, בריאותיים וכו'), לקבץ אותם לפי רגישות ולפרט את הסיכונים הנלווים . זה יאפשר לתעדף בקרות ולקבוע בצורה מדויקת יותר כללי גישה והצפנה.
לבסוף, הפצה והכשרה חשובות לא פחות מהמסמך עצמו . יש להנגיש את המדיניות לכל המשתמשים הרלוונטיים, להסביר אותה בצורה ברורה, לשלב אותה בתהליכי הקליטה וללוות אותה בתוכניות מודעות קבועות. אם צוותים לא מבינים אותה או רואים בה מכשול בירוקרטי, הם יתעלמו ממנה.
עדכון ובדיקה שוטפים של המדיניות
מדיניות אבטחת ענן לא יכולה להיות מסמך סטטי. נוף האיומים מתפתח, ספקים משחררים תכונות חדשות והארגון משתנה ; אם המדיניות לא מסתגלת, היא מיושנת תוך מספר חודשים.
זו הסיבה שחשוב לבצע ביקורת תקופתית על המדיניות הקיימת כדי לראות מה עדיין עובד, מה הפך מיושן, ואילו איומים חדשים מתעלמים מהם. זה כרוך בעבודה צמודה עם ספקי ה-IT, האבטחה, התאימות וספקי הענן עצמם.
על הסקירות להתאים את המדיניות לגרסאות העדכניות ביותר של מסגרות כגון NIST CSF 2.0 או ISO/IEC 27017, ולשלב וקטורי תקיפה חדשים: תוכנות כופר מתוחכמות יותר, התקפות על פלטפורמות קונטיינרים ותזמור, ניצול API, ימי אפס בנקודות קצה וכו'.
מומלץ מאוד לשלב מקורות מודיעין איומים בזמן אמת, כך ששינויים ב-TTP של התוקפים יוכלו לבוא לידי ביטוי במהירות בכללי גישה, זיהוי ותגובה מבוססי ענן.
כדי לאמת שהעדכונים הגיוניים, אישור המסמך אינו מספיק: יש לבחון את המדיניות באמצעות סימולציות, תרגילי שולחן ומבחני חדירה מבוקרים . זה מאמת האם הצוותים יודעים כיצד להגיב למתקפה אמיתית.
סביבות היברידיות וסביבות מרובות עננים: אתגרים ספציפיים
רוב הארגונים כבר לא מסתמכים על ספק יחיד. מקובל לשלב AWS, Azure, Google Cloud וענן פרטי או מקומי , ולתאם עומסי עבודה הנעים בין סביבות בהתבסס על עלות, ביצועים או דרישות משפטיות.
בהקשר זה, על המדיניות להגדיר בקרות בסיסיות שאינן תלויות בספק : סיווג נתונים מאוחד, סטנדרטים מינימליים של הצפנה, דרישות רישום וביקורת, עקרונות בקרת גישה, פילוח רשת וכללי ניטור.
פריסות היברידיות דורשות סנכרון פרוטוקולי אבטחה בין סביבות מקומיות לענן , תוך הבטחה שאין פערים בנראות או "איים" שבהם איש אינו מנטר או אוכף מדיניות. פילוח, מיקרו-היקפי רשת ונהלי רישום מאוחדים הם חיוניים. יתר על כן, כאשר עומסי עבודה עוברים בין סביבות, מומלץ להגדיר כללי העברה ובקרה ברורים.
ארכיטקטורת אבטחה מקוטעת, המבוססת על פתרונות רבים ספציפיים לספקים, נוטה ליצור פערים ועייפות התראות . ניהול קונסולות, כלים ולוחות מחוונים מרובים מאלץ אנליסטים להחליף כל הזמן הקשרים, מה שמאט את תגובת האירועים ומקל על התראות קריטיות לחמוק מעיניהם.
לכן, יותר ויותר ארגונים מחפשים פלטפורמות ניהול סיכונים ומדיניות מאוחדות בענן, עם מנועי הקשר שנותנים עדיפות להתראות על סמך חשיפה בפועל, נתיבי תקיפה פוטנציאליים, הרשאות אפקטיביות וקריטיות הנכס . גישה זו מסייעת להפחית את שטח התקיפה ולהתמקד במה שחשוב באמת.
שיטות עבודה מומלצות לתכנון ויישום של מדיניות אבטחת ענן
בעת ניסוח ויישום מדיניות, כדאי לפעול לפי סדרה של שיטות עבודה מומלצות. הראשונה היא לתת עדיפות לבהירות ופשטות השפה : מסמכים כתובים כמו חוזים משפטיים נוטים להתעלם או להתפרש בצורה שגויה.
עדיף להשתמש בשפה מובנת לכל עובד, תוך הסבר ה"מדוע" של כל דרישה (לדוגמה, מדוע הסכם שיתוף קבצים (MFA) הוא חובה או מדוע כלי שיתוף קבצים מסוימים אסורים) ולשמור את הפרטים הטכניים יותר לנספחים ספציפיים.
נוהג טוב נוסף הוא לקבץ מדיניות תחת כותרות ברורות וקוהרנטיות : בקרת גישה, סיווג נתונים, אבטחת רשת, תגובה לאירועים, תאימות, יחסי ספקים וכו'. זה מקל על כל צוות למצוא במהירות את הסעיף המשפיע עליו.
כמו כן, שימושי מאוד לקשר מדיניות למדדים מדידים : מספר הגשות הלא מורשות שזוהו ונחסמו בחודש, אחוז המאגרים המוצפנים, זמן ביטול גישה ממוצע כאשר משתמש מוסר, מספר אירועים שדווחו לעומת אירועים שהתגלו וכו'.
לבסוף, חשוב להכיר בכך שמדיניות היא מסמכים חיים . יש לבחון אותה, להעשיר אותה בלקחים שנלמדו מאירועים מהעולם האמיתי, ולהתאימה לטכנולוגיות חדשות ככל שהן מיושמות (מכולות, שרתים ללא שרת, פתרונות SaaS חדשים, כלי שיתוף פעולה וכו').
דוגמאות מעשיות לאבטחת ענן ומדיניות גישה
כדי להמחיש את האמור לעיל, הבה נדמיין כמה תרחישים. חברת שירותים פיננסיים בגודל בינוני עשויה להגדיר שכל הרשומות הפיננסיות של הלקוחות המאוחסנות בדלי אחסון בענן חייבות להיות מוצפנות, לכל הפחות, באמצעות AES-256, ושהן חייבות להיות נגישות רק מכתובות IP של החברה ודרך חשבונות עם MFA חובה.
במגזר הבריאות, ספק שירותי בריאות עשוי לדרוש, באמצעות מדיניותו, שכל מידע הבריאות המוגן יאוחסן באזורי ענן ספציפיים העומדים בדרישות רגולטוריות מסוימות . יתר על כן, תעבורה נכנסת ויוצאת למערכות אלו מוגבלת לקבוצה קטנה של כתובות IP ומנוטרת בקפידה.
בחברת טכנולוגיה המציעה שירותי ענן, המדיניות עשויה לכלול אמצעים טכניים וארגוניים ספציפיים מאוד: מלאי נכסים, אנטי-וירוס מעודכן, חומת אש דו-שכבתית, סריקות תקופתיות של פגיעויות, בדיקות חדירה שנתיות, SIEM לאיסוף וקורלציה של יומני רישום, הפחתת נזקי DDoS ונהלי תגובה למתקפות סייבר.
מנקודת מבט של הגנת מידע, מקובל גם לתעד עמידה בתקנות הפרטיות, מינוי קצין הגנת מידע, התחייבות לסודיות של הצוות, פסאודו-נימיזציה של מידע רגיש, הגבלת אחסון ותנאי הקשר עם ספקים (כולל מחיקת נתונים מאובטחת עם סיום השירות ודרישה להסמכות כגון ISO 27001 או 27018).
אפילו פרטים שנראים קלים לכאורה, כגון החלפת סיסמאות באימות מבוסס מפתח (PKI), שימוש במכשירי מפתח אבטחה פיזיים או איסור אחסון מפתחות פרטיים במחשבים אישיים , יכולים להיכלל במדיניות הגישה כדי להפחית באופן דרסטי את הסיכון לגניבת אישורים.
בסך הכל, מדיניות אבטחה וגישה בענן המתוכננת היטב, התואמת את התקנות ומחוזקת על ידי בקרות טכניות, אוטומציה והדרכה מתמשכת, מאפשרת לארגונים למנף את יתרונות הענן מבלי להשאיר את עצמם פגיעים לאירוע החמור הבא . בניית מדיניות זו דורשת עבודה, אך היא משתלמת ביותר כאשר גל ההתקפות הבא נתקל בסביבה מוכנה עם תפקידים ברורים, בקרות יעילות ותוכנית תגובה משופרת.
