ציות SOC 2 לגוגל וורקספייס: מה צריך לדעת

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

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

התמצאות מהירה ב-SOC 2

SOC 2 מעריך את בקרות הארגון מול קריטריוני שירותי האמון (TSC): אבטחה (תמיד נכללת, ומכונה לרוב הקריטריונים המשותפים), ובאופן אופציונלי זמינות, שלמות עיבוד, סודיות ופרטיות. קריטריוני האבטחה — סדרת ה-CC — הם המקום שבו גוגל וורקספייס מופיעה הכי הרבה.

דוח סוג 1 מעריך האם הבקרות *מתוכננות* כראוי בנקודת זמן. דוח סוג 2 מעריך האם הן *פעלו באפקטיביות* לאורך תקופה (בדרך כלל 3–12 חודשים). סוג 2 הוא מה שלקוחות בדרך כלל רוצים, ויש לו השלכה חשובה: אתם צריכים בקרות שעובדות, וראיות לכך שעבדו, לכל אורך החלון — לא רק ביום הביקורת.

היכן גוגל וורקספייס ממופה אל הקריטריונים

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

• CC6.1 — בקרות גישה לוגיות. מי יכול להגיע למידע מוגן, ואיך הגישה מוגבלת למשתמשים מורשים. במונחי וורקספייס: הקצאת חשבונות, אכיפת אימות רב-שלבי, בקרות שיתוף, והגישה שמחזיקה כל זהות, כולל חשבונות חיצוניים וחשבונות שירות.
• CC6.2 — רישום והרשאה. משתמשים חדשים נרשמים ומורשים לפני שמוענקת גישה; גישה מוסרת כשאינה נחוצה עוד. היגיינת קליטה/מעבר/עזיבה חיה כאן.
• CC6.3 — הרשאה מזערית והפרדת תפקידים. הגישה מבוססת תפקידים ונשמרת במינימום הנחוץ. גישה בהרשאות-יתר והתרחבות מנהלים הן ממצאים מול הקריטריון הזה.
• CC6.6 — הגנה מאיומים חיצוניים. המשטח הנגיש חיצונית: קישורים ציבוריים, שיתופים חיצוניים וגישה שהוענקה לזהויות מחוץ לארגון.
• CC7.x — ניטור ותגובה לתקריות. זיהוי חריגות ותגובה לאירועי אבטחה. לדעת מתי שיתוף או גישה משתנים, ולהיות מסוגלים לחקור — אלה תומכים כאן.

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

מה מבקרים בפועל מבקשים

מבקרים אינם רוצים הבטחות; הם רוצים ראיות. לבקרות הקשורות בוורקספייס, צפו לבקשות כמו:

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

הנושא החוזר הוא תהליך מתועד וחוזר עם שובל ביקורת. בקרה שקיימת אך אינה מותירה עקבות קשה לאשש. בקרה שרצה ברציפות ומתעדת את מה שמצאה — קלה.

איך מכינים את צד הוורקספייס

1. קבעו קו בסיס תצורתי. תעדו את המצב הרצוי של הגדרות הניהול — שיתוף, אימות דו-שלבי, מגבלות מרקטפלייס, אימות דוא״ל — ובדקו את המציאות מולו בלוח זמנים. סחף הוא האויב של ביקורת נקייה.
2. הריצו סקירות גישה שאפשר להוכיח. סקרו תקופתית מי יכול להגיע לנתונים רגישים, כולל זהויות חיצוניות ולא-אנושיות, ושמרו את התוצר. ״סקרנו גישה רבעונית, הנה הרשומות״ — זה בדיוק מה ש-CC6.3 רוצה.
3. הדקו ותעדו שיתוף. מפו אל CC6.1 ו-CC6.6 בבקרת שיתוף ציבורי וחיצוני וביכולת להראות את המצב הנוכחי.
4. נהלו ממצאים עד פתרון. כשאתם מוצאים חשיפה, רשמו אותה, תקנו אותה ושמרו את השובל. זה תומך בקריטריוני הניטור והטיפול.
5. החזיקו יומן ביקורת. תיעוד חתום-זמן של פעולות רלוונטיות לאבטחה הופך את שאלות ״מי עשה מה ומתי״ לטריוויאליות.

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

ראיות רציפות מנצחות את בהלת הביקורת

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

האלטרנטיבה רציפה: שלטו בעמדה כל השנה, הפיקו את הראיות כתוצר לוואי, והיכנסו לביקורת כשהשובל כבר מורכב. כלי עמדה שממפה ממצאים לקריטריוני SOC 2 ומפיק ראיות מוכנות-מבקר הופך את הבהלה לייצוא.

מלכודות נפוצות בחלק הוורקספייס של ביקורת

כמה טעויות חוזרות שוב ושוב ושווה לחסום מראש:

• בלבול בין ״מוגדר״ ל״נאכף״. הפעלת מדיניות אימות דו-שלבי אינה זהה להחלתה על כל חשבון. מבקרים בודקים את השני. ודאו שהאכיפה מחזיקה בכל הארגון — ראו את המדריך שלנו לאכיפת אימות רב-שלבי בגוגל וורקספייס.
• התייחסות לסקירות גישה כאל תיבת סימון. ״אנחנו סוקרים גישה״ בלי רשומות, תחולה או המשך טיפול — אינו ראיה. שמרו את התוצר והראו שממצאים טופלו.
• שכחת זהויות לא-אנושיות. גם חשבונות שירות וסוכני בינה מלאכותית מחזיקים גישה, ומבקר שבוחן הרשאה מזערית (CC6.3) לא יקבל ״סקרנו רק אנשים.״ משלו בהם — ראו זיהוי סוכני בינה מלאכותית מסוכנים.
• מתן לתצורה להיסחף בין ביקורות. קו בסיס שהיה נקי בינואר ונסחף עד יוני מפיק ממצא בדוח סוג 2. בדיקה רציפה, לא תמונת מצב שנתית, היא מה שמחזיק את הקו.

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

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

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

8200.dev ממפה את עמדת הגוגל וורקספייס שלכם למשפחות הבקרה של SOC 2, ISO 27001 ו-GDPR ומפיקה חבילות ראיות שאפשר למסור למבקר — כנות, תחומות למה שאנחנו באמת רואים, לעולם לא טענת ציות שלא הורווחה. קראו עוד על איך זה עובד או על נוהלי האבטחה שלנו.

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