הסיכון הנסתר: נתונים רגישים ללא תווית במערכות משחקים
נתונים רגישים ללא תווית זורמים כמעט בכל חלק במחסנית המשחקים שלכם, כך שמידע מסוכן מטופל לעתים קרובות כלא מזיק על ידי אנשים וכלים. כאשר יומני רישום, קבצי dump ומערכי נתונים המכילים זהויות שחקנים, נתוני כרטיסי אשראי, עקבות תשלום או לוגיקת אנטי-צ'יט אינם מסומנים בבירור, מהנדסים, צוותי תמיכה ומערכות אוטומטיות נוהגים להתייחס אליהם כברירת מחדל כרעש טכני שגרתי, והחלטות יומיומיות לגבי העתקה או שמירתם בשקט מגדילות את החשיפה שלכם. ISO 27001 A.5.13 הוא הבקרה שמאלצת אתכם להפוך את הרגישות הזו לגלויה ועקבית, כך שתוכלו להתאים גישה, שמירה וניטור לסיכון אמיתי.
מידע זה הינו כללי ואינו מהווה ייעוץ משפטי, רגולטורי או ייעוץ במסגרת PCI DSS. עליך תמיד לקבל החלטות בנוגע לתאימות לתקן ISO 27001, GDPR או PCI DSS תוך התחשבות בתמיכה מקצועית מתאימה לתחום השיפוט ולפרופיל הסיכון שלך.
אנשים מטפלים בנתונים ברמת הסיכון שהם יכולים לראות.
היכן שמידע רגיש באמת חי במשחק
מידע רגיש במשחק מודרני מפוזר על פני לקוחות, שירותים וכלים שצמחו סביב כל משחק. אתם אוספים מזהים ונתוני מכשירים בלקוח, מעבדים אותם בשרתי משחקים ושרתים, מעבירים נכסים דרך רשתות אספקת תוכן ומשקפים הכל לפלטפורמות ניתוח ותצפית שבהן תוויות חסרות לעתים קרובות. זהויות שחקנים, עקבות תשלום ואותות התנהגותיים מופיעים בלקוחות, שרתים, כלי תמיכה ופלטפורמות ניתוח, לעתים קרובות כתוצרי לוואי של שמירה על משחקים חיים. אם אתם רוצים ש-A.5.13 יעבוד, עליכם לזהות את המיקומים הללו, להחליט אילו סוגי נתונים רגישים ולהבטיח שתוויות עוברות איתן.
רבים מהארטיפקטים הרגישים ביותר הם תוצרי לוואי של פעולות. קבצי Crash dump יכולים ללכוד אזורי זיכרון באמצעות טוקנים או אישורים. יומני ניפוי באגים עשויים לכלול כתובות דוא"ל או קטעי צ'אט. קונסולות תמיכה וכלי משחק חושפים היסטוריית שחקנים מלאה. צילומי מסך המצורפים לכרטיסים חושפים שמות משתמש, תגי גילדה או אפילו מספרי תשלום. אם ארטיפקטים אלה אינם מסומנים בבירור, סביר להניח שהם יועתקו, ישותפו או יישמרו הרבה יותר זמן מהבטוח.
אפילו תשתית הנדסית תורמת לבעיה. סביבות ביניים משתמשות בנתוני ייצור לצורך ריאליזם אך לעיתים רחוקות נעולות באותה הדוק. צינורות בנייה ופריסה מזיזים קבצים בינאריים חתומים, קבצי תצורה ומפתחות. מאגרי בקרת מקור מתייחסים לנקודות קצה פנימיות, תכונות ניסיוניות ולוגיקת אנטי-צ'יט. ללא תוויות ברורות, צוותים מתייחסים למיקומים אלה כאל אינסטלציה שגרתית ולא כאל מאגרי מידע מוגבל.
מדוע נתונים לא מתויגים מהווים סיכון עסקי אמיתי
מידע רגיש ללא תווית הופך לסיכון עסקי ממשי משום שאף אחד לא חולק תפיסה ברורה וניתנת לאכיפה לגבי מה דורש הגנה חזקה יותר. כאשר צוותים אינם יכולים לראות באופן מיידי שיומנים, צילומי מסך או סביבות בדיקה מסוימים מכילים נתוני שחקנים או תשלומים, הם מקבלים החלטות אגבית לגבי העתקה, שיתוף או שמירתם. בחירות אלו פוגעות בהתמדה בבקרות הטכניות שלכם ובהבטחות שאתם נותנים לשחקנים ולשותפים.
ניתוק זה מופיע במהירות בשלושה מקומות: אירועים, ביקורות ותוכניות התרחבות. באירועים, חוקרים מגלים שיומני רישום, צילומי מסך או סביבות בדיקה לא מסומנות הכילו בדיוק את הנתונים שנחשפו, מה שהופך שגיאת תצורה קלה להפרה מדווחת. בביקורות, מעריכים של ISO 27001 מבקשים דוגמאות לאופן שבו סיווגים מיושמים במערכות, לא רק במדיניות, וחושפים תוויות לא עקביות או חסרות. כאשר רוצים להיכנס לשווקים חדשים או לחתום על הסכמי פלטפורמה ותשלום גדולים יותר, שותפים שואלים שאלות נוקבות לגבי היכן נמצאים נתונים רגישים וכיצד הם מפולחים, ותשובות מעורפלות לגבי נתונים פנימיים כבר אינן מספקות.
כאשר תוויות חסרות, בקרות גישה, כללי שמירה ופרופילי הצפנה מפסיקים לפעול כמתוכנן. לא ניתן לאכוף באופן מהימן גישה נדרשת או תקופות שמירה קצרות יותר עבור נתונים מוגבלים אם המערכות שלכם אינן יכולות להבחין בין מוגבל לפנימי. A.5.13 סוגר את הפער הזה על ידי הפיכת סכמת הסיווג שלכם מתיאוריה למעשה, כך שגם בני אדם וגם כלים יוכלו לראות מיד כיצד יש לטפל בפריט מידע נתון.
הזמן הדגמהמהעברת תכונות לניהול נתונים: המציאות החדשה עבור אולפני משחקים
אולפני משחקים מודרניים נשפטים כיום על סמך האופן שבו הם מנהלים נתוני שחקנים ותשלומים, לא רק על סמך מהירות שליחת הפיצ'רים. תקן ISO 27001 A.5.13 הופך את הציפייה הזו לממשית בכך שהוא מבקש מכם לחשוב על האופן שבו אתם מתייגים מידע רגיש במערכות שונות, ולא רק על האופן שבו אתם מעצבים מכניקות. כדי ליישם את A.5.13 בהצלחה, עליכם לעבור מטיפול בנתונים כמעיים מפיתוח פיצ'רים להתייחסות אליהם כמשהו שאתם מנהלים באופן פעיל מטעם שחקנים, שותפים ורגולטורים. אתם עדיין שולחים במהירות, אבל אתם מקבלים החלטות מכוונות לגבי מה שאתם אוספים, עד כמה הוא רגיש וכיצד רגישות זו מאותתת על פני הסטנדרט שלכם ומופיעה בכלים יומיומיים.
שינוי זה אינו רק העדפה של תאימות. חנויות אפליקציות, מפעילי פלטפורמות, מפרסמים ורגולטורים מצפים כעת מחברות משחקים להראות כיצד הן מגנות על נתונים אישיים ונתוני תשלומים. אולפנים שמאמצים אחריות בשלב מוקדם נמצאים בעמדה טובה יותר לענות על שאלוני אבטחה, לבצע בדיקת נאותות ולהרגיע הורים ורגולטורים לגבי אופן הטיפול שלהם בנתוני קטינים.
הציפיות החיצוניות השתנו
הציפיות החיצוניות בנוגע לאבטחה ופרטיות במשחקים התהדקו באופן דרמטי, ורגולטורים רבים מתייחסים כיום לסוגי נתוני משחקים נפוצים כנתונים אישיים כאשר ניתן לקשר אותם לאדם. משמעות הדבר היא שהחלטות התיוג שלך נבדקות יותר ויותר על ידי אנשים מחוץ לסטודיו שלך, ולא רק על ידי בעלי עניין פנימיים. טבלת סיווג פשוטה במדיניות כבר אינה מספיקה; גורמים חיצוניים רוצים להבין כיצד תיוג עובד במערכות אמיתיות.
מספר קבוצות בוחנות כעת מקרוב את האופן שבו אתם מטפלים ומתייגים נתונים:
- רגולטורים: – להתייחס למזהים, טלמטריה וצ'אט כאל נתונים אישיים כאשר ניתן לקשר אותם לאנשים פרטיים.
- בעלי הפלטפורמה: – לשאול שאלות מפורטות לגבי תהליכי אחסון, פילוח ואירועים.
- ספקי תשלום: – התמקדות בסביבות נתוני מחזיקי כרטיסים ובנהלי רישום נתונים מסביב.
- שותפי הוצאה לאור: – רוצים להבטיח שהמותג שלהם לא יהיה קשור לפריצה שטופלה בצורה גרועה.
יחד, בעלי העניין הללו מעצבים את מידת האמינות של דף התוויות שלכם כשאתם מסבירים היכן נמצאים נתונים רגישים וכיצד הם נשלטים.
פלטפורמות קונסולות ומובייל כוללות יותר ויותר שאלות מפורטות בנוגע לאבטחה ופרטיות בתהליכי הקליטה וההסמכה. הן רוצות לדעת היכן אתם מאחסנים נתונים רגישים, כיצד אתם מפלחים אותם וכיצד אתם מגיבים לאירועים. ספקי תשלום מתמקדים בסביבות נתוני בעלי כרטיסים ובנהלי רישום נתונים. שותפי הוצאה לאור גדולים רוצים ביטחון שהמותג שלהם לא יהיה קשור לפריצה שטופלה בצורה גרועה שמקורה ביומנים או ייצוא לא מסומנים.
כאשר אינך יכול להראות לאן נתונים רגישים זורמים וכיצד הם מתויגים, כל אחד מבעלי העניין הללו רואה בך שותף בעל סיכון גבוה יותר. תוכנית תיוג פשוטה ומיושמת היטב נותנת לך קומה קונקרטית: "כך אנו מסווגים ומתייגים נתוני שחקנים, כאן נמצא כל מחלקה, ואלה הבקרות שכל תווית מפעילה".
מהי אחריות בתוך הסטודיו שלך
ניהול נתונים בתוך הסטודיו שלכם פירושו שאתם מתכננים פיצ'רים, אירועים ותהליכי תמיכה תוך התחשבות ברגישות מההתחלה. צוותים שוקלים מה הם אוספים, איזה תווית עליו לשאת וכמה זמן הוא באמת צריך להישמר. גישה זו מאפשרת לכם לאזן בין משחקיות, יעדים מסחריים וחובות רגולטוריות מבלי להסתמך על שיפוטים לא פורמליים או ניקוי של הרגע האחרון.
בפועל, ניהול נתונים פירושו התייחסות מכוונת לזרימות נתונים כמו לתכונות משחק. צוותי מוצר שוקלים אילו נתונים יאסוף מכונאי חדש, לא רק עד כמה הם יהיו מרתקים. מהנדסים מתכננים טלמטריה עם בחירות מכוונות לגבי האם מזהים נחוצים, ואם כן, כיצד יש לתייג ולהגן על האירועים המתקבלים בסביבות שלכם.
פעולות לייב, בדיקות A/B והפצת תוכן מהירה מכפילות את האפקט הזה. ניסויים כוללים לעתים קרובות נתונים עשירים יותר למדידת שימור נתונים, מונטיזציה או הוגנות. ללא תוויות, מערכי נתונים ניסיוניים מצטברים במרחבים משותפים אליהם אנליסטים או קבלנים יכולים לגשת באופן נרחב. בעזרת תוויות, ניתן להתעקש שניסוי הנוגע לנתונים בסיכון גבוה ישתמש באזורי ביניים מוגבלים ובוריאנטים אנונימיים במידת האפשר.
פלטפורמה כמו ISMS.online יכולה לתמוך בשינוי תרבותי זה על ידי אחסון כללי הסיווג והתיוג שלכם במקום אחד, קישורם לסיכונים, בקרות ונכסים. בדרך זו, דיונים על "האם תכונה חדשה זו צריכה לאסוף את התחום הזה?" יתבססו על הגדרות משותפות ותיאבון סיכון גלוי, ולא על שיקולי דעת אישיים. מהנדסים, צוותי אבטחה, תאימות ותמיכה עובדים כולם מאותו ספר חוקים במקום לאלתר את הכללים שלהם.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
מה באמת דורש תקן ISO 27001 A.5.13 בתחום הגיימינג
תקן ISO 27001 A.5.13 מצפה מכם לתרגם את סכמת הסיווג ברמה גבוהה שלכם לכללי תיוג מעשיים המופיעים במערכות ובממצאים אמיתיים. בהקשר של משחקים, פירוש הדבר הוא לעבור מעבר להטבעת "סודי" על מסמכים ולסמן יומני מידע, ייצוא, צילומי מסך, כרטיסים וזרמי נתונים המכילים מידע קריטי לשחקנים או לעסקים. בפועל, הבקרה עוסקת פחות בהמצאת תוויות חדשות ומורכבות ויותר בהוכחה שהסיווג גלוי בכל מקום שהוא חשוב, כך שכאשר אתם אומרים שאתם מתייחסים לנתוני שחקנים כסודיים או מוגבלים, אתם יכולים להראות דוגמאות לתווית זו המופיעה בכלים שלכם ומשפיעה על אופן הטיפול היומיומי בנתונים.
השליטה בשפה פשוטה
בשפה פשוטה, סעיף A.5.13 מצפה מכם להגדיר תוויות התואמות את סכמת הסיווג שלכם, להחליט היכן הן חלות, להקצות אחריות לשימוש בהן ולשמור על עקביות היישום שלהן לאורך זמן. עבור עסק משחקים, פירוש הדבר הוא הפיכת רמות מופשטות לסמנים גלויים על המידע שאנשים וכלים נוגעים בו בפועל, החל מלוחות מחוונים וכרטיסים ועד לייצוא וארכיונים.
מכיוון שהטקסט הסטנדרטי הוא מורשה, אתם עובדים לפי כוונתו ולא לפי מילותיו המדויקות. באופן כללי, סעיף A.5.13 מצפה מכם לעשות ארבעה דברים:
- הגדירו תוויות. החליטו כיצד רמות הסיווג הקיימות שלכם מיוצגות בנכסי מידע אמיתיים.
- החלט היכן תוויות חלות. בחר היכן נדרשות תוויות באופן דיגיטלי, פיזי ועל גבי יציאות המערכת.
- קבעו אחריות וכללים. תעד מי מחיל תוויות, מתי תוויות יכולות להשתנות וכיצד מטפלים בחריגים.
- שמרו על תוויות עקביות. יש ליישם את הכללים באופן עקבי ולסקור אותם ככל שהסביבה והסיכונים שלך מתפתחים.
עבור משחקים, "נכסי מידע" כוללים נתונים במערכות משחק ופלטפורמה, אך גם חפצים כגון קבצי שידור חוזר, ייצוא ניהול, בניית בדיקות ולוחות מחוונים של פיתוח. אינכם נדרשים לתייג הכל באופן ממצה, אך מצופה מכם להצדיק היכן שתיוג נחוץ ולהראות שהכללים שלכם מיושמים במשמעת סבירה.
מה שמבקרים מצפים לראות בחברת משחקים
מבקרים שמעריכים את A.5.13 בחברת משחקים מחפשים קו ברור ממדיניות כתובה לארכיטקטים מתויגים ולאחר מכן לבקרות אמיתיות. הם רוצים לראות שהתוויות שלכם אינן רק שמות על דף אלא סמנים גלויים שמשנים את האופן שבו מערכות מתנהגות ואת האופן שבו אנשים מטפלים במידע. ראיות חשובות יותר מתיאוריה.
בדרך כלל, הם יצפו לסקור מדיניות סיווג ותיוג מידע המתארת את הרמות שלכם, נותנת דוגמאות ומסבירה כיצד תוויות מיושמות על מידע דיגיטלי ופיזי כאחד. לאחר מכן הם ידגמו מערכות וארטיפקטים. זה יכול להיות צפייה בצילום מסך של פלטפורמת הרישום שלכם כדי לראות שדות סיווג בזרמי רישום, בדיקת מוסכמת השמות עבור גיבויים של מסד נתונים, או סקירת האופן שבו מסומנים מסמכים פנימיים וכרטיסים הכוללים נתוני שחקנים.
מבקרים רוצים גם להבין כיצד תוויות מניעות בקרות. אם מערך נתונים מתויג כמוגבל ומכיל נתונים אישיים, הם מצפים לראות בקרת גישה, הצפנה, כללי גיבוי ותקופות שמירה מחמירות יותר בהשוואה לטלמטריה פנימית שבה לא ניתן לזהות אנשים. אם תוויות קיימות אך שום דבר לא משתנה בהתבסס עליהן, הבקרה קיימת מבחינה טכנית אך חלשה באופן מעשי. המטרה היא להפוך את התוויות לגלויות ומשמעותיות כאחד, כך שרואה חשבון, או בודק פנימי, יוכל לראות את הקשר בין תוויות להגנות אמיתיות.
תכנון תוכנית תיוג מוכנה למשחק עבור נתוני שחקנים
תוכנית תיוג מוכנה למשחק משתמשת במספר קטן של רמות ברורות שכולם יכולים לזכור, ולאחר מכן ממפה סוגי נתוני משחקים נפוצים לרמות אלו באופן עקבי. אינך זקוק לטקסונומיה מורכבת כדי לעמוד בתקן A.5.13. אתה זקוק לשלוש או ארבע תוויות מוגדרות היטב, דוגמאות ברורות לכל אחת מהן והבנה משותפת שהתוכנית חלה על פני כותרים, שירותים וכלים, לא רק בתיעוד. תוכנית פשוטה מספיק כדי שמפתחים, אנליסטים וצוות תמיכה יוכלו לזכור אותה, אך מדויקת מספיק כדי לשקף רמות שונות של נזק וחובות רגולטוריות, תשרת אותך טוב יותר ממודל מושלם שאף אחד לא משתמש בו ותחסוך לך שנים של החלטות אד-הוק מאוחר יותר, מכיוון שמשחקים וספקים חדשים יכולים להתחבר לאותו מודל מנטלי במקום להמציא דגלים ומוסכמות משלהם.
תוכנית פשוטה מספיק כדי שמפתחים, אנליסטים וצוות תמיכה יוכלו לזכור אותה, אך מדויקת מספיק כדי לשקף רמות שונות של נזק וחובות רגולטוריות, תשרת אתכם טוב יותר ממודל מושלם שאף אחד לא משתמש בו. חשיבה מדוקדקת על העיצוב הזה פעם אחת תחסוך לכם שנים של החלטות אד-הוק מאוחר יותר, מכיוון שמשחקים וספקים חדשים יכולים להתחבר לאותו מודל מנטלי במקום להמציא דגלים ומוסכמות משלהם.
בחירת רמות סיווג בהן הצוותים ישתמשו בפועל
רמות סיווג עובדות רק אם אנשים יכולים לשמור אותן בראש וליישם אותן ללא היסוס. עבור רוב האולפנים, ארבע רמות כמו ציבוריות, פנימיות, סודיות ומוגבלות מספיקות. המפתח הוא להסכים מה המשמעות של כל רמה עבור נתונים הפונים לשחקנים, נתונים תפעוליים והנדסיים, ולאחר מכן מתן דוגמאות קונקרטיות שהצוותים מזהים מהכלים ומזרימות העבודה שלהם.
ייתכן שתחליטו ש"ציבורי" מכסה מידע שאתם מסכימים שכולם יראו, כגון תוכן שיווקי או תיעוד API שפורסם. "פנימי" יכול לכלול מפות דרכים, מסמכי תהליכים לא רגישים וסטטיסטיקות מצטברות שלא ניתן לקשר לאנשים פרטיים. "סודי" הוא בדרך כלל המקום שבו נמצא רוב המידע הקשור לשחקנים: פרטי חשבון, רישומי תשלום רגילים המוחזקים בהתאם להתחייבויותיכם, טלמטריה התנהגותית שניתן לקשר חזרה למשתמש ונתוני ביצועים פנימיים שגרתיים.
"מוגבל" שמור למידע שעלול לגרום נזק חמור אם ייחשף: נתוני גולמיים של בעלי כרטיסי אשראי במידה וקיימים, מודלים נגד רמאויות, מפתחות הצפנה, תוכן שלא פורסם בעל השפעה מסחרית משמעותית וכל שילוב של נתונים שעלול ליצור בעיות בטיחות או רגולציה חמורות. ככל שתגדירו את הרמות הללו בצורה ברורה יותר, כך יהיה קל יותר לצוותים להחליט כיצד לתייג מערכי נתונים חדשים מבלי לעצור ולדון בכל מקרה.
כוחה של תוכנית זו נובע מהסכמה, בעזרת דוגמאות, מה נמצא היכן. אם "יומני צ'אט הכוללים שיחות של קטינים" מתועדים בבירור כ"מוגבלים", אף אחד לא צריך לאלתר כשהוא רואה תוכן כזה בכלי כרטוס או במסך ייצוא. הם כבר יודעים שהוא נושא את דרישות הטיפול הגבוהות ביותר ויכולים לבדוק מה המשמעות של זה מבחינת אחסון, גישה ושמירה.
מיפוי סוגי נתוני משחקים לתוויות
מיפוי סוגי נתוני משחקים אופייניים לתוויות שלכם הופך סכמה מופשטת לערוץ ייחוס שצוותים יכולים להשתמש בו בעת עיצוב תכונות, בחירת ספקים או תגובה לאירועים. טבלה תמציתית המכסה את הקטגוריות החשובות ביותר מספיקה בדרך כלל. ניתן לפרט עם דוגמאות נרטיביות במידת הצורך, אך המיפוי עצמו צריך להישאר קומפקטי וקל לסריקה.
להלן דרך אחת למפות נתונים מרכזיים הקשורים לשחקנים:
| קטגוריית נתונים | תכולה אופיינית | תווית ברירת מחדל |
|---|---|---|
| תוכן אתר שיווקי | טריילרים, פוסטים בבלוג, הערות תיקון | הציבור |
| נתוני חשבון וזהות | דוא"ל, שם משתמש, מזהי פלטפורמה, מדינה | סוֹדִי |
| נתוני תשלום (טוקנים, היסטוריית תשלום) | נתוני כרטיס אסימון, היסטוריית רכישות, החזרים כספיים | סוֹדִי |
| יומני צ'אט וקול | שיחות, דוחות, הערות ניהול | מוגבל |
| טלמטריה של המשחק (משתמשים מקושרים) | אירועי סשן, רכישות, מזהי מכשירים | סוֹדִי |
טבלה זו עוזרת לקבוצות לראות במבט חטוף שרוב המידע המזהה שחקנים לא צריך להיחשב כמידע פנימי בלבד, גם אם זה מרגיש שגרתי בעבודה היומיומית.
ניתן לטפל בקטגוריות בסיכון גבוה במיוחד בנפרד במידת הצורך:
| קטגוריית נתונים | תכולה אופיינית | תווית ברירת מחדל |
|---|---|---|
| נתוני גולמיים של בעלי כרטיס | מספר חשבון ראשי, תוקף, CVV (אם קיים) | מוגבל |
| נכסים נגד רמאות או משחק חוזר | עקבות התנהגות, קבצי שידור חוזרים, אותות זיהוי | מוגבל |
| מפתחות וחפצי אבטחה | מפתחות הצפנה, מפתחות חתימה, סודות | מוגבל |
טבלה שנייה זו מדגישה אילו סוגי נתונים כמעט תמיד ראויים לטיפול המחמיר ביותר, כך שאף אחד לא יתייעץ איתם בטעות כמידע סודי רגיל.
מיפוי זה אינו מחייב על ידי התקן; אתם מתאימים אותו למשחקים ולתיאבון הסיכון שלכם. הדבר החשוב הוא עקביות פנימית ותיעוד. כאשר אתם מביאים ספק ניתוח חדש או בונים כלי ניהול חדש, אתם משתמשים באותו מקור כדי להחליט אילו תוויות להחיל. פלטפורמה כמו ISMS.online יכולה לאחסן מיפוי זה לצד רישום הסיכונים ומלאי הנכסים שלכם, מה שמקל על שמירת התיעוד, התוויות והבקרות יישור לאורך זמן ולהראות למבקרים כיצד ההחלטות שלכם משתלבות זו בזו.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
יצירת העברת תוויות בין לקוחות, שרתים, CDNs ואנליטיקה
תוויות מגנות עליך רק אם הן עוברות עם הנתונים כשהם זורמים דרך הארכיטקטורה שלך. במחסנית משחקים מבוזרת, משמעות הדבר היא נשיאת סמני רגישות מאירועי לקוח דרך שירותי back-end, תורים, אגמי נתונים ולוחות מחוונים. הגדרת תוויות על נייר היא רק חצי מהעבודה; החצי השני הוא לגרום לתוויות הללו לנוע עם הנתונים ברחבי הארכיטקטורה המבוזרת שלך, כך שברגע שפיסת נתונים מסווגת ומתויגת באיסוף, התווית נשמרת או משתנה באופן עקבי כשהיא עוברת דרך לקוחות, שירותי back-end, זרמי אירועים, אגמי נתונים ולוחות מחוונים. אם תטמיעו תוויות כמטא-נתונים מובנים ותהפכו אותן לחלק מהאוטומציה שלכם, כלים יכולים לאכוף כללי גישה, שמירה ומיסוך באופן אוטומטי, במקום להסתמך על אנשים שיזכרו בכל פעם.
אם הארכיטקטורה שלכם אוטומטית במידה רבה, יש לשלב את התיוג שלכם באוטומציה הזו ולא להשאיר אותו לשיקול דעת ידני. כאשר תוויות הן חלק מהגדרות סכימה, ניהול תצורה ותשתית כקוד, הן יכולות להשפיע על מי יכול לקרוא זרם, כמה זמן הוא מאוחסן והאם ניתן לייצא אותו, מבלי שמישהו יצטרך לסמן תיבות ידנית בכל פעם.
תוויות מרוויחות את מלוא כבודן כאשר כלים יכולים לפעול לפיהן מבלי לבקש.
עיצוב תוויות כמטא-נתונים מהשורה הראשונה
הגישה החזקה ביותר היא להתייחס לתוויות כאל מטא-נתונים מובנים, ולא כהערות אד-הוק. התייחסות לתוויות כאל מטא-נתונים מובנים ולא כאל הערות לא פורמליות היא הדרך האמינה ביותר לגרום להן להישאר. ניתן להוסיף שדות כגון classification, contains_personal_data, contains_payment_data or child_data_possible לסכמות האירועים והיומן שלך. בצד הלקוח, כאשר אתה משדר אירוע, אתה מגדיר שדות אלה בהתבסס על סוג האירוע שאתה שולח. בצד השרת, שירותים ומעבדי זרם קוראים ושומרים שדות אלה במקום להסיר אותם, מה שמאפשר לכלי downstream להבין רגישות מבלי לנחש ומקל הרבה יותר על חיפוש אחר מאגרי מידע בסיכון גבוה וליישם אכיפה עקבית בעת שינוי מדיניות או תגובה לאירוע.
בממשקי API, ניתן לשאת תוויות בכותרות או במעטפות מובנות שעוטפות מטענים. במסדי נתונים ואגמי נתונים, ניתן לאחסן תוויות כמטא-נתונים ברמת טבלה או עמודה, או כתגיות בקטלוג. בתורי הודעות, ניתן להשתמש בתכונות או בכותרות כדי לעקוב אחר רגישות. המפתח הוא שהנוכחות והמשמעות של שדות אלה יהיו סטנדרטיות ברחבי המחסנית שלך, כך שמהנדסים לא יצטרכו להמציא אותם מחדש עבור כל מערכת.
לגישה זו שלושה יתרונות ברורים. היא מספקת מקור יחיד של אמת לגבי רגישות, שכלי ניתוח ותצפית יכולים להשתמש בו כדי לסנן גישה. היא מקלה על החיפוש אחר "כל המאגרים המכילים נתונים מוגבלים" בעת ביצוע הערכות סיכונים או תגובה לאירועים. היא גם מאפשרת לך להגדיר אכיפה - כגון חסימת ייצוא או אכיפת הצפנה מחמירה יותר - המבוססת על תוויות במקום על כללי קידוד קשיחים עבור כל מערכת בנפרד.
אוטומציה של הפצה ובדיקות בצינורות
ברגע שתוויות קיימות כמטא-דאטה, ניתן לשלב אותן בצנרת התהליכים שלכם כך שקוד וסכמות חדשים חייבים לכבד אותן. בדיקות אוטומטיות בזמן הבנייה והטעימה הן הרבה יותר אמינות מאשר לבקש ממפתחים לזכור את כללי התיוג תחת לחץ של דד-ליין, והן נותנות לכם התרעה מוקדמת כאשר משהו חומק לפני שהוא מתפשט.
רישום הסכימה שלך יכול, לדוגמה, לדחות כל סוג אירוע חדש שאינו מציין סיווג. צינור האינטגרציה הרציפה שלך יכול לסמן שינויים שמוסיפים שדות חדשים המכילים מזהים אך שוכחים לעדכן דגלי רגישות. פלטפורמת הנתונים שלך יכולה להחיל כללי שמירה ומיסוך המוגדרים כברירת מחדל על סמך שדות סיווג, כך שמערכות נתונים "מוגבלות" מקבלות באופן אוטומטי טיפול מחמיר יותר מאשר טלמטריה פנימית.
ניטור ובדיקות איכות חשובות לא פחות. משימות מתוזמנות יכולות לסרוק יומני רישום, מאגרי אובייקטים ורשומות קטלוג עבור מערכי נתונים לא מתויגים, או עבור אי התאמות בין תוויות מוצהרות לתוכן שזוהה. אם מערך נתונים כביכול אנונימי עדיין מכיל מזהים ברורים, יש לסמן אותו לבדיקה. כאשר מיקרו-שירות חדש מתחיל לשלוח אירועים ללא מטא-נתונים של סיווג, התראות צריכות להפעיל לפני שדפוס זה מתבסס.
גם דאגות של השהייה וביצועים דורשות תשומת לב. אינכם רוצים לוגיקת תיוג כבדה בנתיב החם של רינדור מסגרות או קוד רשת. במקום זאת, דחפו את רוב החלטות הסיווג לתצורה, זמן בנייה או צינורות בליעה. שדות וכותרות מטא-דאטה קלות משקל מוסיפות תקורה זניחה בהשוואה לגודל המטען וההצפנה, במיוחד כאשר הם מתוכננים בקפידה. התמורה היא מערכת שבה הרגישות עוקבת אחר הנתונים באופן אוטומטי, וניתן לכוונן את האכיפה מבלי לשנות ללא הרף את קוד האפליקציה או להסתמך על ספרינטים של ניקוי ידני.
התאמת תיוג ISO ל-GDPR ול-PCI DSS עבור נתוני שחקנים
תוכנית תיוג מאוחדת יכולה לתמוך בתקן ISO 27001 ובמקביל להקל על ניהול GDPR ו-PCI DSS עבור נתוני משחקים. אם מתייחסים לסיווג אבטחה כבסיס ולאחר מכן מוסיפים היבטי פרטיות ותשלום, נמנעים מלהפעיל שלוש תוכניות נפרדות שמבלבלות צוותים. במקום זאת, משתמשים באוצר מילים יחיד ובקבוצות קטנות של דגלים כדי לתאר מאפיינים משפטיים כמו נתונים אישיים או נתוני בעל כרטיס. יישור זה מפחית כפילויות ואי הבנות, מכיוון שבמקום לשמור על תוכנית אחת לאבטחה, אחת לפרטיות ואחת לתשלומים, שומרים על אוצר מילים מאוחד ומשתמשים בתגים או מאפיינים כדי לבטא האם פיסת מידע היא נתונים אישיים, נתונים בקטגוריה מיוחדת, נתוני בעל כרטיס או מחוץ לתחום, כך שצוותי משפט, אבטחה ותשלום כולם מדברים על אותם מערכי נתונים כאשר הם דנים בסיכונים ובחובות.
יישור זה מפחית כפילויות ואי הבנות. במקום לשמור על תוכנית אחת לאבטחה, אחת לפרטיות ואחת לתשלומים, אתם שומרים על אוצר מילים אחיד ומשתמשים בתגים או במאפיינים כדי לבטא האם פיסת מידע מסוימת היא מידע אישי, מידע בקטגוריה מיוחדת, מידע על בעל כרטיס או מחוץ לתחום. בדרך זו, צוותי המשפט, האבטחה והתשלומים שלכם מדברים על אותם מערכי נתונים כשהם דנים בסיכונים ובחובות.
תמיכה ב-GDPR עם תוויות
ה-GDPR לא אומר לך להשתמש בתוויות, אבל הוא כן דורש ממך לדעת אילו נתונים הם אישיים, אילו רגישים במיוחד, היכן מתרחש עיבוד בסיכון גבוה וכיצד אתה מגן עליהם. ה-GDPR מצפה ממך לדעת אילו נתונים הם אישיים, אילו נתונים הם בסיכון גבוה וכיצד אתה מגן עליהם לאורך כל מחזור החיים שלהם. תוויות מאפשרות לך לקודד את הידע הזה ישירות למערכות על ידי סימון היכן נמצאים נתונים אישיים ונתונים בקטגוריה מיוחדת, מה שמקל על התאמת תהליכי גישה, שמירה וזכויות נושא לחובות המשפטיות שלך, במקום להסתמך על הנחות או זיכרון ספציפיים ליישום.
כאשר מערך נתונים מסומן כמכיל נתונים אישיים, ניתן להגדיר בהתאם את מדיניות הגישה, ההצפנה, הרישום, השמירה ותהליכי הגישה לנושא. ניתן ללכת צעד קדימה על ידי הוספת דגלים לקטגוריות מיוחדות של נתונים (במקרים נדירים שבהם אלה מתעוררות במשחקים, כגון מידע הקשור לבריאות במשחקים מסוימים), נתונים על ילדים או נתונים המשמשים ליצירת פרופילים. זה מאפשר לקצין הגנת המידע שלך להדגים כי נתונים כאלה מטופלים בזהירות יתרה, למשל על ידי הגבלת הקבוצות שיכולות לגשת אליהם, דרישה להצדקה חזקה יותר לייצוא או קיצור תקופות שמירה.
תוויות אלו גם הופכות את רישומי פעילויות העיבוד שלך לאמינים יותר. כאשר בעלי מערכות מקשרים מאגרי נתונים ברשומה לרמות סיווג ספציפיות ולסימני פרטיות, יש לך מפה חיה של היכן נמצאים נתונים אישיים רגישים וכיצד הם מטופלים. במהלך בקשת גישה של נושא מידע או בדיקה רגולטורית, תוכל לחפש בתוויות אלו במקום להסתמך אך ורק על ידע לא פורמלי של הסביבה או זיכרון שביר.
תמיכה ב-PCI DSS ובדרישות תשלום
PCI DSS מתמקד בנתוני כרטיסים, טוקנים וכל סביבה שמאחסנת, מעבדת או מעבירה אותם. תוויות ברורות עוזרות לך לשמור על גבולות ההיקף על ידי הבחנה בין נתוני כרטיס גולמיים, רשומות עם טוקנים ויומני תשלום סמוכים. בהירות זו מפחיתה את הסיכוי שזרם יומן או גיבוי שנשכח נסחף בשקט לסביבת נתוני בעל הכרטיס ומביא איתו חובות ביקורת ובקרה בלתי צפויות.
גם אם אתם מסתמכים במידה רבה על ספקי תשלומים של צד שלישי, ייתכן שעדיין תטפלו באסימונים, נתוני כרטיס חלקיים או יומני רישום המתייחסים לעסקאות. אם אתם מעבדים נתוני בעלי כרטיסים ישירות, החובות שלכם ועומס הביקורת שלכם יגדלו משמעותית. תוכנית תיוג מאוחדת עוזרת לכם לעקוב אחר גבולות אלה מבלי לאלץ צוותים לשנן את טרמינולוגיית PCI.
לדוגמה, ייתכן שתחליט שכל טבלה, זרם יומן או קובץ המכילים מספרי חשבון ראשיים או מקבילות מלאות למספרי PAN מסווגים כ"מוגבלים" ונושאים contains_cardholder_data דגל. רשומות מצטברות או אסימטריות שאינן מכילות מידע גולמי על כרטיס עשויות להישאר חסויות, אך עם דגל ברור המציין שהן קשורות לתשלום אך מחוץ לתחום ה-PCI המחמיר.
הבחנה זו מקלה על הגדרה ותחזוקה של היקף ה-PCI באופן שכל גורמי האבטחה, הפיננסים וההנדסה יוכלו להבין. מערכות המתויגות כמטפלות בנתוני בעלי כרטיסים הופכות לחלק מסביבת נתוני בעלי הכרטיסים וחייבות לעמוד במגוון המלא של דרישות ה-PCI. מערכות שעוסקות רק בנתונים אסומנליים או מצרפיים יכולות להישאר מחוץ לתחום, בתנאי שהן מופרדות כראוי. כאשר אתם מתעדים זאת במערכות ה-ISMS ובדיאגרמות הארכיטקטוניות שלכם, תוכלו להראות הן למבקרים של ISO 27001 והן למעריכי ה-PCI כיצד סיווג ותיוג תומכים בגישת הפילוח שלכם ומפחיתים חשיפה מיותרת.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
יישום תיוג: ניהול, זרימות עבודה וכלים
יישום A.5.13 באופן תפעולי פירושו מתן בעלים ברורים לתיוג, הטמעתו בתהליכי עבודה יומיומיים ולמדוד את מידת הפעולה שלו. אתם רוצים שמפתחים, אנליסטים, צוותי תמיכה וצוותי אבטחה יראו בתוויות חלק מהפרקטיקה הרגילה, ולא כתרגיל תאימות נפרד. אפילו אסטרטגיית עיצוב ומטא-דאטה הטובה ביותר של תיוג ייכשלו אם אף אחד לא יהיה הבעלים שלה או אם היא תישאר מנותקת מהעבודה היומיומית, כך שיישום A.5.13 באופן תפעולי פירושו גם הקצאת אחריות ברורה, שילוב תוויות בתהליכי הפיתוח והתפעול שלכם, הכשרת אנשים בשימוש בהן ומעקב אחר יעילות לאורך זמן בצוותי הנדסה, תהליכים חיים, תמיכה, אבטחה ותאימות. כאשר תחומי האחריות, התהליכים והכלים מיושרים, אתם יכולים להראות למבקרים ולשותפים שתיוג הוא מערכת חיה ולא מסמך סטטי.
המטרה היא להגיע לנקודה שבה סיווג ותיוג יהיו פשוט חלק מהאופן שבו בונים ומפעילים משחקים, ולא פעילות תאימות מקבילה. כאשר מפתחים, אנליסטים וצוות תמיכה רואים באופן עקבי תוויות בכלים שלהם, מבינים את משמעותן ויודעים כיצד לפעול לפיהן, עברתם ממדיניות לפרקטיקה וראיות הביקורת שלכם הופכות לקלות הרבה יותר להפקה.
ממשל ובעלות
ממשל פנימי חזק מבהיר מי קובע הגדרות תוויות, מי מיישם אותן ומי בודק שהן עדיין עובדות ככל שהמשחקים שלכם מתפתחים. בדרך כלל, ראש אבטחת מידע או CISO מחזיק במדיניות, קצין הגנת המידע מעצב כל דבר שקשור למידע אישי, וצוותי משחקים, פלטפורמה ותמיכה מיישמים תוויות בתחומים שלהם. צוותי ביקורת פנימית או סיכונים מאתגרים ובודקים את התמונה הכוללת כדי שלא תסטה ממנה.
ניהול ממשל מתחיל בהחלטה מי מוביל ומי תורם. בדרך כלל, ראש אבטחת המידע או CISO שלכם מחזיקים במדיניות הסיווג והתיוג. לקצין הגנת המידע יש קול חזק בכל פעם שמעורבים נתונים אישיים. צוותי פלטפורמה ומשחק אחראים על יישום תוויות בשירותים ובזרימות העבודה שלהם. צוותי תמיכה ומתיחות מטפלים בייצוא ובהסלמות עם תוויות. צוותי ביקורת פנימית או סיכונים עשויים לנטר את הכיסוי והיעילות ולאתגר נקודות תורפה.
ניתן לסכם את התפקידים העיקריים כך:
- הנהגת אבטחה: – בעל התוכנית ותיאבון הסיכון הכללי.
- קצין הגנת מידע: – מייעץ בנוגע למידע אישי ונתונים בסיכון גבוה.
- קבוצות משחק ופלטפורמה: – ליישם תוויות בקוד ובכלי עבודה.
- תמיכה וניהול: – לטפל בייצוא מתויג והסלמות.
- ביקורת פנימית או סיכון: – בוחן את הכיסוי ומאתגר נקודות תורפה.
מטריצת RACI פשוטה (אחראי, אחראי, מתייעץ, מודע) עבור החלטות תיוג, שינויי מדיניות וחריגים שומרת על כך ברור. לדוגמה, הנדסת פלטפורמה עשויה להיות אחראית על אכיפת שדות סיווג בסכמות, בעוד שהאבטחה נותרת אחראית על הסכימה הכוללת. צוותי משחק עשויים להיות אחראים על תיוג נכון של זרמי הטלמטריה שלהם, להתייעץ לגבי הגדרות תוויות ולקבל מידע על שינויי מדיניות. הנהלת התמיכה עשויה להיות אחראית על אופן הטיפול בייצוא ועל הבטחת שארטיפקטים מוגבלים לא ישותפו באופן אגבי.
בחירות הכלים צריכות לשקף את הממשל הזה. פלטפורמה כמו ISMS.online יכולה לשמש כמקום מרכזי שבו מדיניות, הגדרות תוויות, נכסים, סיכונים ובקרות קשורים יחד. כאשר מישהו מציע שינוי - כמו הכנסת תווית חדשה למכניקת משחק רגישה במיוחד - ניתן ללכוד את הרציונל, האישורים והעדכונים הנובעים מכך בנתיב אחד שניתן לבקרו במקום לפזר החלטות על פני צ'אטים ואתרי ויקי.
הטמעת תוויות בזרימות עבודה, הדרכה ומדידה
הטמעת תוויות בזרימות עבודה פירושה לשאול על סיווג בכל פעם שנוצרים, מטפלים או נחשפים נתונים חדשים, לא רק במהלך סקירות שנתיות. רשימות בדיקה, תבניות וחומרי הדרכה צריכים להפוך את החלטות התוויות לחלק טבעי מהעיצוב, סקירת הקוד והשחרור, כך שצוותים לא יצטרכו לזכור את הכללים מאפס בכל פעם או לחכות להתערבות של מומחה.
רשימות תיוג לסקירת סכמות צריכות לכלול שאלות בנוגע לסיווג ודגלי פרטיות. תבניות סקירת קוד יכולות להזכיר למפתחים לחשוב האם שורת יומן או אירוע חדש מציגים מזהים ולקבוע את התוויות המתאימות. תהליכי ניהול גרסאות יכולים לדרוש אישור שמאגרי נתונים חדשים מסווגים ומתויגים לפני העלייה לאוויר, במיוחד בסביבות staging שאחרת עלולות להתעלם מהן.
אנשים זקוקים גם להכשרה המותאמת לתפקידיהם. מהנדסים ואנליסטים חייבים להבין כיצד לפרש וליישם תוויות במאגרים, צינורות נתונים ולוחות מחוונים. צוותי תמיכה וניהול זקוקים להדרכה מעשית בנוגע לטיפול בייצוא מוגבל, היכן ניתן או לא ניתן לשתף אותו, וכיצד להעלות תוכן חריג כגון נתונים החשודים בקטגוריה מיוחדת. מנהלי מוצר ומנהלי תהליכים חיים צריכים לדעת כיצד תוויות משפיעות על תכנון ניסויים, פריסות A/B והחלטות שימור נתונים, כדי שלא ייצרו בטעות מערכי נתונים בסיכון גבוה ללא תוויות.
לבסוף, התייחסו לתיוג כאל משהו שאתם מודדים. אינדיקטורים שימושיים כוללים את שיעור מאגרי הנתונים הידועים עם תוויות שהוחלו עליהם, מספר אירועי ייצוא לא מורשה או תיוג שגוי, כיסוי של קטגוריות בסיכון גבוה כגון יומני צ'אט או נתוני אנטי-צ'יט ומגמות בחריגים. ביקורות פנימיות ובדיקות לאחר המוות של אירועים צריכות לבדוק האם תוויות היו קיימות והאם הן סייעו או הפריעו לתגובה. תובנות אלו מוזנות חזרה לעדכוני מדיניות, הדרכות, ובמידת הצורך, שינויים בכלים כך שנוהג התיוג שלכם ישתפר עם כל מחזור במקום לסטות מהנוהג.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזר לכם להפוך את תקן ISO 27001 A.5.13 למערכת תיוג מעשית וניתנת לביקורת בכל מערך המשחקים שלכם, כך שתוכלו להגן על שחקנים, לספק את המבקרים ולשמור על מפת הדרכים שלכם בתנועה. על ידי ריכוז תוכנית הסיווג, כללי התיוג, הנכסים, הסיכונים והבקרות, זה נותן לכם תצוגה אחת וקוהרנטית שתוכלו לשתף בביטחון עם מהנדסים, מבקרים, שותפים ובעלי פלטפורמות. הדגמה היא ההזדמנות שלכם לראות כיצד רעיונות אלה חלים על המשחקים, הצינורות והכלים הספציפיים שלכם במקום להתייחס ל-A.5.13 כהנחיה מופשטת, כך שתוכלו לחקור כיצד סיווג, תיוג ובקרות מתאחדים במקום אחד ולהחליט האם גישה זו תפחית את החיכוך עבור הצוותים שלכם.
איך יכול להיראות טייס ממוקד
פיילוט ממוקד מראה כיצד תיוג באמת עובד עבור כותר או זרימה אחת לפני שאתם מרחיבים אותו. על ידי הגבלת ההיקף למשחק, צינור או ערכת כלים ספציפיים, תוכלו להוכיח את הערך של תיוגים טובים יותר במהירות, למצוא פערים בבטחה ולבנות דפוסים שצוותים אחרים יכולים להעתיק. גישה זו מספקת לכם ראיות מוכנות לביקורת מבלי להקפיא את הפיתוח בכל תיק העבודות שלכם.
דרך טובה להתחיל היא עם פיילוט צר ובעל ערך גבוה: לדוגמה, צינור נתוני שחקנים של משחק דגל אחד, או זרימה ספציפית כגון תשלומים או כלי תמיכה. אתם ממפים את מאגרי וזרמי הנתונים המרכזיים, מחליטים אילו רמות סיווג ודגלי פרטיות או תשלום חלים, ומגדירים את התוויות הללו בסביבת ISMS.online שלכם לצד הסיכונים והבקרות הרלוונטיים כך שכולם יוכלו לראות את אותה תמונה.
משם, אתם לוכדים דוגמאות קונקרטיות: כיצד מסומן זרם יומן מסוים ואילו צוותים יכולים לגשת אליו; כיצד ייצוא צ'אט מסומן כ"מוגבל" ומקושר לשמירה מחמירה יותר; כיצד מסווג ומבוקר טבלת אגם נתונים המשלבת טלמטריה ומזהים. אתם גם מקשרים נהלים, רשומות הדרכה ודוחות ניטור לארטיפקטים הללו, כך שכאשר מבקר או שותף שואלים כיצד אתם מיישמים את A.5.13, תוכלו להראות להם דוגמאות ספציפיות במקום לדבר בהכללות.
פיילוט מסוג זה אינו דורש מכם לשנות כל מערכת בן לילה. במקום זאת, הוא נותן לכם תמונה מציאותית של איך נראים תיוג יעיל בסביבה שלכם, מדגיש פערים ומדגים ערך למנהיגות. הוא הופך הנחיות מופשטות לדפוסים ספציפיים שהצוותים שלכם יכולים להעתיק במשחקים ושירותים אחרים, והוא מספק לצוותי אבטחה ותאימות ראיות לכך שתוויות הן למעשה מניעות בקרות.
כיצד הדגמה מתורגמת לראיות מוכנות לביקורת
הדגמה מאפשרת לכם לראות כיצד ISMS.online משלב את A.5.13 בשאר מערכת ניהול אבטחת המידע שלכם, החל ממדיניות ועד לרישומי נכסים, סיכונים, בקרות וביקורות פנימיות. תוכלו לעקוב אחר תווית מהגדרתה ועד לנכסים שהיא מסמנת, הסיכונים שהיא מפחיתה והנהלים וההדרכה התומכים בה. נראות זו מקלה בהרבה על הסבר הגישה שלכם למבקרים, לבעלי פלטפורמות ולשותפי פרסום.
בהדגמה, תוכלו לראות כיצד סיווג ותיוג פועלים לצד עבודת התקן הרחב יותר של ISO 27001 ב-ISMS.online. תוכלו לבחון כיצד שינוי מדיניות בהגדרת "Restricted" זורם לתוך רישומי נכסים, הערכות סיכונים ובקרות. תוכלו לראות כיצד ביקורת פנימית של A.5.13 דוגמת חפצים מתויגים ומתעדת את ממצאיה. תוכלו לבחון כיצד התחייבויות ה-GDPR וה-PCI DSS שלכם קשורות לאותם נכסים מתויגים, תוך הימנעות מכפילויות ובלבול.
והכי חשוב, תוכלו להעריך כיצד זה ירגיש עבור הצוותים שלכם. מהנדסים, צוותי אבטחה ועמיתים לתאימות מקבלים מקור אמת משותף במקום גיליונות אלקטרוניים מקבילים. צוותי משחק יכולים לראות, במבט חטוף, אילו מהמערכות שלהם מטפלות בנתונים מוגבלים ומה המשמעות של זה. צוותי תמיכה ותפעול חי מקבלים הנחיות ברורות יותר מתי הם יכולים לייצא נתונים ומתי עליהם להסלים.
אם אתם רוצים להגן על נתוני השחקנים שלכם, לספק את צרכי הרגולטורים והשותפים שלכם, ולשמור על קצב תנועה מהיר של האולפן שלכם, השקעה בתיוג ברור ועקבי תחת A.5.13 היא אחד הצעדים בעלי המינוף הגבוה ביותר שתוכלו לנקוט. הזמנת הדגמה עם ISMS.online היא דרך פשוטה לבחון כיצד להפוך את הצעד הזה לממשי עבור המשחקים שלכם, הארכיטקטורה שלכם והצוותים שלכם.
הזמן הדגמהשאלות נפוצות
בלוק ה"ביקורת" בהודעה שלך הוא כבר גרסה מצומצמת של הטיוטה, והוא חזק מאוד: ברור, ידידותי לאודיטור, ושימושי לאולפנים. יש רק כמה בעיות קטנות שכדאי לתקן לפני שאתה שולח אותו.
הנה גרסה משוכללת קלות, מוכנה לפרסום, עם עריכות קטנות לשמירה על בהירות, דקדוק ועקביות. שמרתי על המבנה והקול שלך ללא שינוי.
כיצד חברת משחקים צריכה לפרש את תקן ISO 27001 A.5.13 בפועל היומיומי?
תקן ISO 27001 A.5.13 מצפה שסיווג מידע יהיה גלוי וניתן לפעולה בעבודה היומיומית, ולא רק מתואר במסמך מדיניות. עבור חברת משחקים, משמעות הדבר היא ש"סודי" ו"מוגבל" לא יכולים להתקיים רק בגיליון אלקטרוני; הם חייבים להופיע בנכסים שהצוותים שלכם נוגעים בהם מדי יום: יומנים, ייצוא, צילומי מסך, קבצי קריסה, מסדי נתונים, כרטיסים ותצוגות אנליטיקה.
בפועל, אתם שואפים לשלוש תוצאות. ראשית, כולם יוכלו לזהות קבוצה קטנה של רמות סיווג וליישם אותן באופן עקבי על ארטיפקטים אמיתיים בכל מחסנית המשחקים שלכם. שנית, התוויות הללו גלויות בכלים ובזרימות עבודה: החל מצינורות בנייה וקונסולות ניהול ועד לאגמי נתונים ופלטפורמות תמיכה. שלישית, התוויות למעשה מניעות התנהגות: הרשאות גישה, שמירה, מיסוך וכללי ייצוא - כולם תואמים את מה שקובעת המדיניות שלכם.
מבקר יקרא את מדיניות הסיווג שלכם, לאחר מכן יפתח מערכות אמיתיות וישאל, "האם זה תואם?". אם הצ'אט מוגדר כמוגבל, הוא יצפה לראות זאת משתקף בסכמות, במיקומי אחסון, בכלי תמיכה ובקרת גישה. מערכת ניהול אבטחת מידע (ISMS) כגון ISMS.online מסייעת על ידי קשירת מדיניות, מלאי נכסים, תוויות וראיות ביקורת יחד, כך שתוכלו להראות ש-A.5.13 חי בתפעול, לא רק בתיעוד.
איך נראה "מספיק טוב" עבור רוב האולפנים?
יישום ריאלי מורכב מארבעה אלמנטים:
- רמות פשוטות: שנכנסים לעמוד אחד וקל לזכור אותם.
- כללי כיסוי: שאומרים אילו חלקים במחסנית שלך חייבים להיות מתויגים (נתוני שחקנים, תשלומים, צ'אט, טלמטריה, בניות, יומנים, גיבויים).
- בעלות ברורה: מי מתייג מה, מי מאשר חריגים ומי בודק את הכיסוי.
- עֵדוּת: שתוויות משמשות בבקרת גישה, שמירה ומיסוך החלטות, ולא רק מודבקות על כמה קבצים.
אם אתם יכולים להוביל רואה חשבון מטקסט של מדיניות לדוגמה במערכת חיה בפחות מדקה, אתם בדרך הנכונה.
כיצד נוכל לעצב תוכנית תיוג לנתוני שחקנים שבה קבוצות ישתמשו בפועל?
תוכנית תיוג עובדת כאשר אנשים יכולים לזכור אותה וליישם אותה תוך פחות מדקה. עבור נתוני שחקנים, זה בדרך כלל אומר ארבע רמות עם דוגמאות קונקרטיות במקום טקסונומיה חכמה שרק שני אנשים מבינים.
דפוס נפוץ במשחקים הוא:
- ציבורי: – תוכן שאתם מרגישים בנוח לחשוף לכולם: דפי שיווק, הערות תיקון, מסמכי API ציבוריים.
- פנימי: – מידע פנימי בלבד ללא רגישות ישירה לשחקנים: מדדי ביצועים (KPI) פנימיים, מפות דרכים, הערות עיצוב.
- סוֹדִי: – רוב הנתונים שקשורים לשחקן: חשבונות, היסטוריית רכישות, טלמטריה מקושרת, היסטוריית תמיכה רגילה.
- מוגבל: – נתונים שעלולים לגרום נזק חמור אם יטפלו בהם בצורה שגויה: נתוני גולמיים של בעלי כרטיסים, יומני צ'אט של קטינים, מודלים נגד רמאויות, מפתחות הצפנה, הפצת תוכן שלא פורסם, ייצוא חקירות מעמיקות.
משם, אתה יוצר מיפוי קצר עבור קטגוריות נפוצות:
- חשבונות ומזהים (דוא"ל, שם משתמש, מזהה פלטפורמה) → סוֹדִי
- אסימוני תשלום והיסטוריית רכישות → סוֹדִי
- מספרי כרטיס גולמיים או PAN מלא → מוגבל
- יומני צ'אט/קול עשויים לכלול קטינים → מוגבל
- טלמטריה התנהגותית מקושרת לחשבונות → סוֹדִי
- עקבות נגד רמאויות או שידורים חוזרים מפורטים לחקירות → מוגבל
מיפוי זה צריך להיות חלק מתיעוד ה-ISMS וה-A.5.13 שלכם, אך הוא גם צריך להתקיים במקום שבו מתרחשת העבודה: תבניות סכמות, ויקי הנדסי, ספרי תמיכה ותקני פלטפורמת נתונים. פלטפורמות כמו ISMS.online עוזרות לכם לשמור טבלת סיווג אחת וסמכותית ולקשר אותה לנכסים, סיכונים ובקרות כך ששינויים יזרמו באופן עקבי.
כיצד נשמור על התוכנית שימושית ככל שמשחקים, אזורים וספקים משתנים?
השימושיות תלויה בדוגמאות ובמעקות בטיחות:
- לתת דוגמה אחת או שתיים קונקרטיות של כל רמה מהכותרות והכלים הנוכחיים שלך.
- הגדירו מה קורה כאשר מערך נתונים אינו תואם לחלוטין (לדוגמה, ייצוא מחקרים או חקירות ספורט אלקטרוני), כולל מי יכול לאשר החלטה חד פעמית וכיצד היא נרשמת.
- קבעו ציפיות ש יש לסווג סכמות, טבלאות וכלים חדשים לפני השימוש בייצור, והפכו זאת לפריט בדיקה בתהליך השינוי שלכם.
אם מהנדס חדש יכול לסווג טבלה או סוג יומן חדש בצורה נכונה באמצעות מדריך בן עמוד אחד בפחות מ-60 שניות, התוכנית שלך עושה את עבודתה.
כיצד נוכל ליישם תוויות טכנית כך שיעקבו אחר נתונים לאורך מחסנית המשחק?
תוויות יעילות ביותר כאשר הן עוברות עם נתונים כמטא-דאטה פשוטים, במקום לחיות בזיכרון של מישהו או בגיליון אלקטרוני נפרד. במחסנית משחקים מודרנית, זה בדרך כלל אומר הוספת קבוצה קטנה של שדות, תגיות או כותרות שכל מערכת יכולה לקרוא ולשמר.
על צד האירועים והרישום, ניתן להוסיף שדות כגון classification, contains_personal_data, contains_payment_data ו child_data_possible לסכמות שלך. לקוחות ושירותי משחקים מגדירים את השדות הללו בעת פליטת אירועים. תורים, מעבדי זרמים ואגמי נתונים שומרים אותם כך שכלים במורד הזרם - לוחות מחוונים, התראות, צינורות למידת מכונה - יוכלו לקבל החלטות על סמך אותות רגישות ברורים.
In מסדי נתונים ומאגרי אובייקטים, סיווג יכול להתקיים כמטא-נתונים ברמת הטבלה או העמודה. לדוגמה, טבלת תמלול צ'אט עשויה לשאת תגיות classification=Restricted, contains_personal_data=true, child_data_possible=true, תורי הודעות, תוויות יכולות להיות מאפיינים או כותרות; ב קבצים ויצוא, ניתן לקודד אותם בשמות קבצים, נתיבי אחסון וכרטיסים קשורים.
לאחר שהתוויות במקומן, ניתן לחבר אותן לאוטומציה:
- רישומי סכמות יכולים לדחות סכמות חדשות שחסרות להן שדות סיווג נדרשים.
- צינורות CI יכולים לסמן קוד שמציג מזהים מבלי לעדכן דגלי רגישות.
- פלטפורמות נתונים יכולות להחיל כללי ברירת מחדל של מיסוך, הצפנה ושמירה על סמך סיווג.
- בדיקות מתוזמנות יכולות לחפש חנויות לא מתויגות או אי התאמה בין תוויות/תוכן וליצור דוחות.
רוב זה פועל בגבולות התצורה והצנרת, לא בתוך לולאות משחק חמות, כך שההשפעה על הביצועים נשארת זניחה. ISMS מובנה כמו ISMS.online מקל על שמירת היישום הטכני בהתאם למדיניות המתועדת שלכם ועל הוכחת התאמה זו במהלך ביקורות.
כיצד נחליט היכן מטא-דאטה הוא חובה וכמה קפדנית צריכה להיות האוטומציה?
גישה פשוטה היא:
- להכריז על הגדרת מטא-דאטה מינימלית עבור כל מערכת שמאחסנת או מעבדת נתונים המקושרים לשחקנים (סיווג + דגל נתונים אישיים כקו בסיס).
- צור את השדות האלה חובה בהגדרות סכימה וסקריפטים להקצאת משאבים עבור מסדי נתונים, תורים, דליי אחסון ופרויקטים אנליטיים.
- התחל עם אכיפה רכה (אזהרות, לוחות מחוונים של תוויות חסרות) ולעבור לאכיפה קשה (דחיית סכימה, פריסות חסומות) ברגע שהצוותים מרגישים בנוח.
ניתן לתעדף תחילה אזורים בעלי סיכון גבוה - תשלומים, צ'אט, מניעת רמאויות, כלי ניהול - ולאחר מכן להרחיב את הכיסוי ככל שהפרקטיקה מתבגרת.
כיצד תוכנית תיוג ISO 27001 עוזרת לנו להתמודד עם GDPR ו-PCI DSS בבת אחת?
תוכנית תיוג עקבית היא אחת הדרכים היעילות ביותר ליישר קו בין ISO 27001, GDPR ו-PCI DSS מבלי להפעיל שלוש מערכות סיווג שונות. ISO 27001 A.5.13 מספק לכם את המבנה; מספר קטן של דגלים נוספים מאפשר לכם לבטא את ההיקף המשפטי ואת ההיקף התשלום מלמעלה.
בעד GDPR וחוקי פרטיות אחרים, תוויות ודגלים מספקים לך תצוגה חיה של היכן מעובדים נתונים אישיים וקטגוריות בעלות סיכון גבוה יותר. סימון מאגרי נתונים כסודיים או מוגבלים באמצעות contains_personal_data דגל מאפשר לך להתאים תהליכי גישה, שמירה וזכויות נושא למה שקורה בפועל. דגלים נוספים עבור נתוני ילדים אפשריים, נתונים בקטגוריה מיוחדת או פרופילציה עוזרים לך לזהות מתי נדרשת הערכת השפעה על הגנת מידע.
בעד PCI DSS, תיוג ברור מקל הרבה יותר על קביעת היקף סביבת נתוני בעלי הכרטיסים שלך. מערכות המאחסנות או מעבדות מספרי כרטיסים מלאים או נתוני אימות רגישים צריכות להיות מוגבלות ולסמן בבירור ככאלו המטפלות בנתוני בעלי כרטיסים. מערכות שרואות רק אסימונים או מדדי תשלום מצטברים יכולות להישאר חסויות עם סמן אחר. הבחנה זו תומכת בקביעת היקף PCI מדויקת יותר, מאפשרת לך להרחיק מערכות שאינן CDE מההיקף ומדגימה לרוכשים ולמבקרים כי בקרות מיושמות היכן שהן חשובות ביותר.
מכיוון שאתם משתמשים בעמוד שדרה אחד של סיווג, תוכלו להסביר למבקרים, לרוכשים ולרגולטורים כיצד אבטחה, פרטיות ובקרות תשלום מתחילות כולן מאותה תצוגה של הנתונים שלכם. פלטפורמת ISMS התומכת במיפויי ISO 27001, ISO 27701 ו-PCI DSS - כגון ISMS.online - עוזרת לכם לשמור על תצוגה אחת במקום להתעסק עם גיליונות אלקטרוניים מרובים וחופפים.
כיצד נוכל למנוע מצוותים שונים להמציא תוכניות משלהם עבור כל מסגרת?
סטייה מתרחשת כאשר אבטחה, פרטיות ותשלומים מגדירים כל אחד את השפה שלו. כדי למנוע זאת:
- תתחיל עם שלך רמות סיווג אבטחה ולהסכים על סט אחד של היבטי פרטיות ותשלום שכל הקבוצות משתמשות בהן.
- תעדו זאת פעם אחת ב-ISMS שלכם ושיקפו זאת בקטלוג הנתונים ובדיאגרמות הארכיטקטורה שלכם.
- כאשר משחק חדש מושק או מתרחב לאזור חדש, יש להשתמש שוב באותה סכמה ולהוסיף ניואנסים אזוריים ככללים ותצורה, ולא כתוויות נפרדות.
בדרך זו, תקנות ה-GDPR, PCI DSS, NIS 2 ותקנות עתידיות של בינה מלאכותית יוכלו להצביע על אותם נכסים מתויגים, להפחית את המורכבות ולעזור לכם לענות בביטחון על השאלה "היכן הנתונים האלה?".
אילו טעויות אולפנים עושים בדרך כלל עם A.5.13, וכיצד מתקנים אותן?
אולפנים לעתים קרובות משקיעים מאמץ במדיניות סיווג ואז נמנעים ממש לפני שהם משנים את אופן פעולת המערכות והאנשים. התוצאה היא פער בין מה כתוב במסמך ו מה המשחקים והכלים באמת עושים.
דפוסים נפוצים כוללים:
- סיווג לפי פוליסה בלבד: – טבלה מסודרת במערכת ה-ISMS, כמה מסמכים עם החותמת "סודי", אך ללא תוויות על קבצי Dump של קריסות, מסדי נתונים של בימוי, ייצואי אנליטיקה או צילומי מסך של תמיכה.
- יותר מדי רמות או תוויות מסתוריות: – סכמות ארוכות שנראות מתוחכמות אך בלתי אפשרי לזכור, כך שצוותים או מתייגים הכל באותו או מדלגים על תוויות.
- שכחה של תוצרי לוואי "מלכלכים": – גרסאות בדיקה, ייצוא אד-הוק, צילומי מסך של ניהול וחבילות ניפוי באגים שנמצאות מחוץ למלאי אך נושאות בדיוק את סוג הנתונים שמעסיקים רגולטורים ותוקפים.
כדי לתקן זאת, ניתן להתחיל בסקירה פנימית קצרה המתמקדת במקומות שבהם נתונים רגישים באמת נעים: ניפוי באגים, כלי תמיכה, תיקיות של מנהלים, צינורות בנייה ופלטפורמות ספקים. יש להתאים אותם תחילה לתוויות שלכם, ולאחר מכן להרחיב בהדרגה את הכיסוי לאזורים בעלי סיכון נמוך.
ISMS כגון ISMS.online עוזר לך למנוע סחיפה על ידי מתן רישום נכסים מרכזי, סיכונים ובקרות מקושרים ותבניות ביקורת פנימית חוזרות, כך ש-A.5.13 הופך לבקרה מתוחזקת ולא לניקוי חד פעמי.
כיצד נוכל למדוד האם בקרת התיוג שלנו משתפרת?
ניתן להשתמש בקבוצה קטנה של צעדים מעשיים:
- אחוז מאגרי נתונים ידועים וכלים קריטיים בעלי תוויות מעודכנות.
- כיסוי של קטגוריות בסיכון גבוה כגון צ'אט, תשלומים, נתונים נגד רמאויות וקונסולות ניהול.
- מספר אירועים או מקרים של תיוג שגוי לרבעון.
- הזמן הנדרש לזיהוי כל המערכות המושפעות בעת ביצוע תרגיל של אירוע או בקשת גישה לנושא.
אם המספרים הללו משתפרים והביקורות הפנימיות שלכם מוצאות פחות הפתעות, תוכלו להראות להנהלה ולמבקרים החיצוניים ש-A.5.13 מספק הפחתת סיכונים אמיתית במקום להתקיים רק על הנייר.
כיצד נוכל לשלב תיוג ובקרת גישה מבוססת תפקידים כדי להגן על נתוני שחקנים מבלי לחסום עבודה?
תוויות נתונים ותפקידים יעילים ביותר כאשר הם מעוצבים יחד: תוויות מתארות כמה רגיש מערך נתונים הוא; תפקידים מתארים מי רשאי לגעת בו ובאילו תנאיםעבור חברת משחקים, פירוש הדבר שמאגרי נתונים מוגבלים כגון תמלילי צ'אט, עקבות תשלום או נתוני אנטי-צ'יט צריכים להיות זמינים רק לתפקידים מוגדרים בבירור תחת רישום ואישור טובים, ולא לכל מפתח או קבלן.
דפוס פשוט הוא להגדיר תפקידים סטנדרטיים ולמפות אותם במפורש לתוויות במקום לטבלאות או כלים בודדים. לדוגמה, תפקיד תמיכה בנגן עשוי לגשת לחשבונות סודיים ולקטעי צ'אט שעברו עריכה, אך לעולם לא לתמלילים מלאים של "מוגבלים". מעצבי משחקים עשויים לעבוד עם טלמטריה מצטברת שלעולם לא חושפת מזהים. אנליסטים של אבטחה והונאות עשויים לקבל גישה רשומה היטב למערכי נתונים מוגבלים עבור מקרי שימוש מוגדרים בחקירה.
ניתן ליישם מיפוי זה במערכות ניהול זהויות וגישה, פלטפורמות ניתוח נתונים, קונסולות ניהול ומחסני נתונים על ידי התייחסות לתכונות סיווג ורגישות, ולא לרשימות המתוחזקות ידנית. כאשר טבלה, אינדקס יומן או ייצוא חדשים נוצרים ומתויגים, הגישה הנכונה נובעת אוטומטית מהסיווג שלהם ולא מעדכון הרשאות נפרד ומועד לשגיאות.
כיצד גישה זו מפחיתה שימוש לרעה יומיומי תוך שמירה על יעילות הצוותים?
רוב השימוש לרעה הפנימי אינו זדוני; מדובר בנוחות: העתקת חבילות יומן גדולות למחשב נייד לצורך ניפוי באגים, ייצוא מערכי נתונים שלמים לגיליון אלקטרוני, או שיתוף צילומי מסך שחושפים בשקט פרטי שחקנים. כאשר תוויות ותפקידים פועלים יחד, כלים יכולים לעודד קבלת החלטות טובות יותר מבלי לחסום עבודה לחלוטין.
לוחות מחוונים יכולים להסתיר מערכי נתונים מוגבלים מתפקידים כלליים כברירת מחדל. פונקציות ייצוא יכולות להסוות באופן אוטומטי מזהים או לאכוף בדיקות נוספות עבור נתונים המסומנים כמכילים נתונים אישיים או נתונים של תשלום. כלי תמיכה יכולים להתריע כאשר ייצוא מוגבל עומד להישלח חיצונית ולכוון את הצוות לחלופה בטוחה יותר. תפקידים עם מגבלות זמן יכולים להעניק למהנדסים גישה זמנית לנתונים מוגבלים ספציפיים עבור אירוע ולאחר מכן לבטל אותה אוטומטית לאחר השלמת העבודה.
עם הזמן, שילוב זה של תוויות גלויות, הרשאות מודעות לתפקידים וברירות מחדל הגיוניות מקשה הרבה יותר על טיפול שגוי בנתוני שחקנים רגישים, תוך מתן אפשרות למומחים לעשות את מה שהם צריכים לעשות. אם אתם רוצים לארגן את התוויות, התפקידים והאישורים הללו במקום אחד וליצור עמדה ברורה עבור מבקרים, אימוץ פלטפורמת ISMS כמו ISMS.online יעניק לכם בסיס מעשי לבנות עליו.
