מדוע נתוני שחקנים שלא מוחקים הפכו לנטל אסטרטגי
נתוני שחקנים שלא מוחקים בזמן הופכים במהרה לחוב אבטחה, פרטיות ורגולציה עבור הסטודיו שלכם. כאשר טלמטריה, יומני צ'אט והיסטוריית תמיכה אף פעם לא באמת נעלמים, כל פרצה או בירור גוררים יותר מערכות, יותר ראיות ויותר עבודה מהנדרש. התייחסות לנתונים בסוף החיים כסיכון מנוהל מאפשרת לכם לצמצם את השפעת האירועים, לפשט חקירות ולהפחית את כמות המידע שעלולה להיות מנוצלת לרעה.
נתוני שחקנים נמצאים כעת בצומת דרכים של הכנסות, רגולציה ומוניטין, כך ששמירה לא מנוהלת מגדילה בשקט את החשיפה שלכם. נספח A.8.10 של תקן ISO 27001:2022 קובע במפורש כי יש למחוק מידע כאשר הוא אינו נדרש עוד, באופן המונע שחזור ומכבד דרישות משפטיות, רגולטוריות, חוזיות ופנימיות. ניסוח זה מדבר רבות על ציפיות לפרטיות והגנת נתונים כמו על אבטחת מידע קלאסית.
רוב האולפנים כבר יודעים כיצד להגן על מערכות חיות; הרבה פחות יכולים להראות, בביטחון, מה קורה לנתונים כשהם "אינם נדרשים עוד". פער זה הוא בדיוק המקום שבו נמצא תקן A.8.10. הוא מבקש מכם להפסיק להתייחס לנתוני שחקנים ישנים וליומני רישום כאל ארכיונים מזיקים, ולהתחיל להתייחס אליהם כנכסים שיש להוציאם משימוש במכוון. בין אם אתם מיישמים את ISO 27001 בפעם הראשונה או מחזקים מערכת ISMS בוגרת, בקרה זו היא המקום שבו לוחות זמנים לשמירה פוגשים מחיקה אמיתית.
נתונים שמעולם לא אספת, או שמחקת בזמן, לעולם לא ייגנבו, יידרשו לצו בית משפט או ישמשו נגדך.
העלות הנסתרת של אגירת נתוני שחקנים
נתוני שחקנים אגורים מסתתרים ביותר מקומות ממה שרוב הקבוצות מצפות, החל מצינורות טלמטריה ישנים ועד למסדי נתונים נשכחים של בדיקות. כל עותק נוסף מרחיב את רדיוס הפיצוץ אם אתם סובלים מפריצה או מתמודדים עם שאלות לגבי משך הזמן שבו הנתונים נשמרים, מכיוון שיש לכם יותר מערכות בהיקף ויותר ראיות לבדיקה ממה שתכננתם.
אם תהיו כנים לגבי המקום שבו נמצאים נתוני השחקנים, בדרך כלל תמצאו הרבה יותר מטבלאות חשבונות ורישומי תשלומים. דוגמאות אופייניות כוללות:
- צינורות טלמטריה מדור קודם שעדיין מקבלים אירועים למרות שלוחות מחוונים אינם בשימוש.
- קבצי Dump ישנים של קריסות עם מזהי מכשירים גולמיים ומעקבי stack.
- ארכיוני הצ'אט נשמרו "ליתר ביטחון" לצורך ניהול, אך מעולם לא נבדקו.
- עותקים של מסדי נתונים של ייצור בסביבות בדיקה ובארגזי חול.
כל אחד מהעותקים האלה מרחיב את היקף השמירה במקרה שמשהו משתבש. אם תוקף נוחת באשכול האנליטיקה שלך, או רגולטור שואל לגבי שמירת נתוני קטינים, אינך יכול פשוט להצביע על מסד הנתונים הראשי של החשבון שלך ולומר שזה גמור. עליך לקחת בחשבון את כל המקומות שאליהם הנתונים נסחפו במהלך שנים של השקות, עדכונים וניסויים.
זה לא רק עניין של אבטחה. שמירת יתר פוגעת גם בחשיבות שאתם מספרים על מזעור נתונים בהערכות השפעה על הפרטיות, שאלוני שותפים וסקירות פלטפורמות. אם המדיניות אומרת שאתם שומרים יומני רישום למשך שנה אחת, אבל המערכות שומרות בשקט חמש, יש לכם בעיית אמינות עוד לפני שמשהו משתבש. עבור צוותים שמנסים למסד את מערכות ה-ISMS שלהם, הפיכת המלאי הזה לגלוי היא לעתים קרובות הצעד הגדול ביותר בהפחתת הסיכון.
כיצד יומנים שלא נמחקו מחמירים אירועים
יומני רישום שלא נמחקו הופכים אירועים לאיטיים יותר, יקרים יותר וקשים יותר להסבר, משום שהם מגדילים את מאגר הנתונים שעלולים להיות חשופים ומגבירים את המאמץ הנדרש כדי לאמוד את ההשפעה. כאשר השמירה אינה מפולחת לפי מטרה, בסופו של דבר מידע רגיש הרבה יותר זמן רב ממה שהסיכון באמת מצדיק.
כשמגיבים לפריצה, שני דברים חשובים באופן מיידי: כמה מהר ניתן לבחון את מה שנחשף, וכמה בביטחון ניתן להסביר את ההיקף הזה למנהלים, לשותפים ולרגולטורים. יומני רישום וטכנולוגיות טלמטריה ארוכות טווח ומנוהלות בצורה גרועה פוגעות בשתי המטרות, משום שהם מערבבים עקבות שגרתיות עם מידע רגיש ביותר ושומרים הכל במשך שנים.
זה עוזר להבחין בין סוגי היומנים השונים שאתה מחזיק:
- יומני תפעול: – לביצועים, יציבות וניפוי שגיאות
- יומני אבטחה: – לבקרת גישה, זיהוי אנומליות ותגובה לאירועים.
- יומני הונאה ונגד רמאויות: – לניתוח דפוסים ואכיפה ארוכי טווח.
צוותי אבטחה, מניעת רמאויות והונאות טוענים לעתים קרובות לשמירה ממושכת, ובמקרים מסוימים הם צודקים. הבעיה היא שהשמירה כמעט ולא מחולקת לפלחים. יומני אימות שגרתיים ומדדי טבעות הונאה רגישים ביותר בסופו של דבר מטופלים באותו אופן, ושניהם נשמרים ללא הגבלת זמן.
בפועל, משמעות הדבר היא שצוותי זיהוי פלילי חייבים לעבור על כמויות עצומות של נתונים כדי להבין מה נגעו בו, צוותים משפטיים חייבים לשקול האם רשומות ישנות מאוד נמצאות כעת בטווח החשיפה, וצוותים תפעוליים חייבים להתמודד עם ההשפעה על הביצועים של מאגרי יומנים מנופחים. תקן ISO 27001 A.8.10 מאלץ אותך להכניס משמעת להתפשטות זו באמצעות מגבלות מפורשות, אוטומציה וניטור.
מדוע אולפני משחקים חשופים באופן ייחודי
אולפני משחקים חשופים באופן יוצא דופן משום שהם אוספים נתונים התנהגותיים מעמיקים על האופן שבו אנשים משחקים, מוציאים כסף ומקיימים אינטראקציה, ולעתים קרובות כוללים קטינים ושחקנים פגיעים. כאשר מידע זה נשמר זמן רב מהנדרש, הוא הופך לנטל רגיש במקום לנכס שימושי ומקשה הרבה יותר על הטיפול בכל אירוע או ביקורת.
חברות משחקים אוספות חלק מנתוני ההתנהגות העשירים ביותר בכל תעשיית הצריכה. לעתים קרובות אתם עוקבים לא רק אחר אירועי הוצאות והתחברות, אלא גם אחר משחק, צ'אט, גרפים חברתיים, פרופילי מכשירים, רמזים למיקום ואותות נגד רמאויות, שנייה אחר שנייה. אתם עשויים גם לטפל בנתוני קטינים, שחקנים שהרחיקו את עצמם או אנשים פרטיים בטריטוריות עם כללי פרטיות מחמירים.
כל זה הופך נתונים שלא נמחקו לרגישים יותר:
- היסטוריית משחקים ויומני צ'אט יכולים לחשוף דפוסי משחק, מערכות יחסים ובמקרים מסוימים, לחץ בריאותי או כלכלי.
- נתוני מונטיזציה סביב תיבות לוט ומיקרו-עסקאות נמצאים קרוב לדיונים חיים על הגנת הצרכן.
- מערכות נגד רמאות והונאה עשויות להסיק או לאחסן פרופילי סיכון רגישים אודות אנשים.
קחו לדוגמה דוגמה פשוטה הכוללת קטינים. נער משחק בהסכמת הורים, משוחח על בית הספר והמשפחה, מוציא כסף דרך כרטיס ההורים, ואז סוגר את החשבון שלו. שנים לאחר מכן, אם עדיין קיימים יומני משחקים וצ'אט מפורטים, אתם מחזיקים בהיסטוריה התנהגותית מיותרת ורגישה ביותר עבור מישהו שכעת הוא מבוגר, ללא מטרה ברורה. אותו הדבר חל על שחקנים שהרחיקו את עצמם או פגיעים שאתם מחויבים לטפל בנתונים שלהם בזהירות.
כאשר רשומות אלו שורדות זמן רב לאחר שהן נחוצות, אתם נושאים בסיכון מיותר לפרטיות ולמוניטין. התאמה ל-A.8.10 מאפשרת לכם לצמצם את הסיכון הזה בצורה מבוקרת, במקום לחכות לפריצה, לתלונה או לרגולטור שיכפו את הבעיה. פלטפורמה כמו ISMS.online יכולה לעזור לכם לראות את התמונה הזו בבירור על ידי איחוד מדיניות, מלאי נתונים ובקרות לתצוגה אחת, כך שתוכלו להחליט מה באמת צריך להישאר, מה צריך להיות אנונימי, ומה חייב להימחק בסופו של דבר, ולאחר מכן להראות למבקרים כיצד נאכפות החלטות אלו.
הזמן הדגמהמה באמת דורש תקן ISO 27001:2022 A.8.10 מאולפני משחקים
נספח A.8.10 לתקן ISO 27001:2022 מצפה ממך להתייחס למחיקה כחלק רגיל ממחזור החיים של נתוני השחקן, ולא כמעין מחשבה שלאחר מעשה. אתה מחליט מתי כל סוג של מידע אינו נדרש עוד, בוחר שיטת מחיקה או אנונימיזציה מתאימה ולאחר מכן מוכיח ששיטות אלו פועלות בפועל במערכות המחזיקות בנתונים אלה.
על הנייר, A.8.10 נראה קצר, אך יש לו השלכות עמוקות. הוא דורש ממך למחוק מידע כאשר הוא אינו נחוץ עוד, באופן שמונע שחזור ויתאים לדרישות משפטיות, רגולטוריות, חוזיות ופנימיות. עבור עסק משחקים, פירוש הדבר הוא תכנון מחיקה כפעילות מובנית, ולא כתסריט חד פעמי כאשר מישהו זוכר.
במונחים מעשיים, אתם מתבקשים להחליט מתי מפסיקים להידרש כל סוג של נתוני שחקן ויומן, לבחור שיטות מחיקה או אנונימיזציה המתאימות לסיכון, ולהיות מסוגלים להוכיח ששיטות אלו אכן פועלות. סעיף A.8.10 פועל לצד נספח A.5.32 בנוגע לשמירה ותהליך טיפול הסיכונים לפי סעיף 6: אתם מחליטים מה לשמור, לכמה זמן, ואילו איומים מחיקה מאובטחת עוזרת לכם לנהל.
מבט פשוט על נספח A.8.10
ניתן להבין את A.8.10 על ידי התייחסות אליו כאל חמש שאלות פשוטות בנוגע לנתונים ולהחלטות שלכם. שאלות אלה אינן עוסקות בתיאור מוצרים ספציפיים; הן עוסקות ביכולת להסביר, במילים פשוטות, מה אתם שומרים, מדוע אתם שומרים את זה ומה אתם עושים כאשר זה כבר לא נחוץ.
ניתן לחשוב על A.8.10 ככזו הבנויה על חמש שאלות:
-
על איזה מידע אתה מדבר?
לא רק "נתונים אישיים" במובן של פרטיות, אלא כל מידע במערכות, מכשירים או מדיה: טבלאות חשבונות, אירועי משחק, יומני הונאה, טלמטריה, גיבויים, ייצוא ועוד. -
מתי זה כבר לא נדרש?
כאן עומד סעיף A.8.10 בסעיף A.5.32 בנוגע לשמירה וחובותיך המשפטיות. "לא נדרש עוד" חייב להיות מבוסס על מטרה וחוק, ולא רק על נוחות. -
איך תמחק או תהפוך את זה לאנונימי?
מחיקות לוגיות, מחיקה קריפטוגרפית, ניקוי אחסון, צבירה ואנונימיזציה - כולן יכולות להיות תקפות, אך יש לבחור אותן במכוון. -
מי אחראי?
על המדיניות והנהלים להקצות אחריות להגדרת כללים, להפעלת מנגנוני מחיקה ולבדיקת פעולתם. -
איך מוכיחים את זה?
אתם צריכים ראיות: תצורה, יומני רישום, כרטיסים ותוצאות ביקורת פנימית שמראות שמחיקה או אנונימיזציה אכן מתרחשות.
אם נסתכל על כך, A.8.10 הוא פחות בקרה "טכנולוגית" ויותר גשר בין ניהול המידע שלכם - מה אתם שומרים ומדוע - לבין היישום הטכני שלכם - כיצד אתם גורמים לנתונים להיעלם או להפוך למזיקים.
כיצד A.8.10 משתלב במערכת ה-ISMS שלכם
סעיף A.8.10 עובד רק אם הוא משולב בשאר מערכת ניהול אבטחת המידע שלכם. הוא מסתמך על הערכות הסיכונים והחלטות השמירה שלכם, והוא מספק בקרות קונקרטיות שתוכלו להצביע עליהן כשאתם מתארים כיצד אתם מפחיתים את ההשפעה של אירועים, ביקורות ותלונות פרטיות.
אם כבר יש לכם מערכת ניהול אבטחת מידע, A.8.10 לא אמור להיות בבידוד. הוא מתחבר ל:
- A.5.32 – שמירה: שאומר שעליך להגדיר כמה זמן נשמר המידע. A.8.10 היא זרוע הביצוע: מה קורה בסוף זמן זה.
- סעיף 6 – טיפול בסיכונים: שבו אתם מחליטים אילו איומים מופחתים באמצעות מחיקה מאובטחת, אנונימיזציה או מזעור.
- בקרות על רישום וניטור: מכיוון שכללי שמירת יומנים ומשימות מחיקה צריכים להתאים לצורכי אבטחה, הונאה ופרטיות.
- בקרות ענן וספקים: מכיוון שאחסון המחיקה שלך חייב לכסות תשתיות ושירותים שאינך מפעיל ישירות.
- בקרת גישה והצפנה: מכיוון שמחיקה יעילה קלה יותר אם נתונים רגישים מופרדים ומוצפנים באמצעות מפתחות מנוהלים היטב.
כאשר אתם מתעדים את הבקרות שלכם, כדאי להראות את הקשר הזה במפורש: לדוגמה, על ידי התייחסות לכללי שמירה בהליכי המחיקה שלכם, ועל ידי רישום בתוכנית הטיפול בסיכונים שלכם כיצד A.8.10 ממתן איומים ספציפיים כגון שמירת נתונים או שמירת יתר.
ההבדל בין התעלמות ממחיקה לבין יישור עם A.8.10 הוא לעתים קרובות בולט:
| ללא משמעת לשמירה ומחיקה | מיושר עם A.8.10 |
|---|---|
| קשה להגדיר את היקף האירוע | היקף המבוסס על מאגרי נתונים ידועים וממופים |
| ביקורות הן תגובתיות וכואבות | ביקורות עוקבות אחר מחזור חיים מתועד |
| קומת הפרטיות מרגישה לא עקבית | כללי השמירה והתנהגות המערכת תואמים בבירור |
| אמון השחקנים והשותפים שביר | ניתן להוכיח מגבלות מזעור ושמירה |
פלטפורמת ISMS כגון ISMS.online הופכת את הקישורים הללו לקלים יותר בכך שהיא מאפשרת לך לקשר בין מדיניות, סיכונים, בקרות וראיות, כך שרואה חשבון - וההנהגה שלך - יכולים לעקוב אחר קו ישר מהדרישה ברמה הגבוהה ועד לפעולות קונקרטיות במערכות שלך.
מה באמת מחפשים רואי חשבון
למבקרים אכפת כיצד אתם מתכננים, מיישמים ומפעילים מחיקה, לא רק ממשפט מדיניות, כי הם צריכים לסמוך על כך שההבטחות שלכם תואמות את המציאות. הם רוצים לראות שקיימים כללי שמירת נתונים, נאכפים טכנית ומנוטרים כאשר משהו נכשל, כך שיוכלו לסמוך על ההצהרות שלכם לגבי נתוני שחקנים ויומני רישום.
רואי חשבון לעולם לא יסתפקו במשפט מדיניות אחד שאומר "אנו מוחקים נתונים כאשר הם אינם נחוצים עוד". הם בדרך כלל מחפשים שלוש שכבות של ראיות:
- עיצוב: – מדיניות, סטנדרטים ונהלים מתועדים המגדירים תקופות שמירה, שיטות מחיקה ואחריות עבור סוגי נתונים שונים.
- יישום: – תצורות מערכת, עבודות אוטומציה וארטיפקטים של תהליכים כגון משימות מתוזמנות, כללי מחזור חיים של אחסון אובייקטים או שגרות מסד נתונים התואמות את מה שהמסמכים מבטיחים.
- תפעול ובקרה: – יומני רישום, כרטיסים ובדיקות ביקורת פנימית המראים כי מחיקה או אנונימיזציה אכן התרחשו, כי כשלים זוהו ותוקנו, וכי חריגים נרשמים ונבדקים.
עבור נתוני ויומני שחקנים, ייתכן שזה אומר להציג אותם:
- מטריצת שמירה ומחיקה עבור קטגוריות הנתונים העיקריות.
- נוהל לטיפול בבקשות מחיקת שחקנים.
- מסכים או ייצואים ממערכות מסד נתונים, רישום ואחסון שבהן מוגדרות שמירה ומחיקה.
- דוגמה של יומני מחיקה וממצאי ביקורת פנימית.
אם תוכלו לענות על שאלות פשוטות כמו "לאן אלך כדי לוודא שיומני צ'אט בני יותר משמונה עשר חודשים מוסרים או הופכים לאנונימיים?" מבלי להתאמץ, כבר התקדמתם בדרך לעמוד בדרישות A.8.10 ולהפוך את הביקורת הבאה שלכם להרבה פחות כואבת.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
מ"הזכות להישכח" ועד לוחות זמנים לשמירה: התאמת A.8.10 ל-GDPR ולפרטיות עולמית
מחיקה מאובטחת אינה רק נושא אבטחה; זוהי גם האופן שבו אתם מוכיחים לשחקנים ולרגולטורים שאתם מכבדים את זכויות הפרטיות. חוקי פרטיות כמו התקנה הכללית להגנה על נתונים מצפים מכם למזער את מה שאתם מחזיקים, למחוק נתונים שאינם נחוצים עוד ולכבד זכויות כגון מזעור נתונים, הגבלת אחסון והזכות למחיקה. עקרונות אלה תואמים קשר הדוק עם A.8.10, המעניק לכם את המנופים המעשיים והתפעוליים לאכיפת ציפיות אלה במערכות אמיתיות.
אינך צריך להיות עורך דין לפרטיות כדי לתכנן בקרות מחיקה טובות, אך עליך להבין כיצד חובות משפטיות מתורגמות לכללי שמירה ולהתנהגות טכנית במערכות שלך.
עקרונות פרטיות מרכזיים שעליכם לבנות עליהם
שלושה רעיונות מוכרים קובעים כמה זמן מותר לשמור נתוני שחקנים ומה עליך לעשות איתם. הם מופיעים במסגרות פרטיות רבות ומהווים נקודות התייחסות נפוצות עבור רגולטורים כאשר הם מעריכים את נוהליך.
שלושת הרעיונות הללו הם:
- מזעור נתונים: – לאסוף ולעבד רק את מה שמתאים, רלוונטי והכרחי למטרותיך. אם אינך באמת זקוק לטלמטריה מפורטת ברמת השחקן, שקול במקום זאת דיווח מצרפי.
- הגבלת אחסון: – לשמור מידע אישי בצורה ניתנת לזיהוי רק כל עוד זה נחוץ למטרות אלה. "אולי נרצה זאת יום אחד" אינה מטרה חוקית.
- זכות למחיקה: – בנסיבות רבות, שחקנים יכולים לבקש ממך למחוק את הנתונים האישיים שלהם, במיוחד כאשר הם חוזרים בהסכמתם או כאשר המטרה המקורית אינה רלוונטית עוד.
עבור חברת משחקים, עקרונות אלה חלים על:
- נתוני חשבון ופרופיל.
- רישומי תשלום ועסקאות.
- צ'אט ונתונים חברתיים.
- טלמטריה ואנליטיקה.
- יומני נגד רמאויות והונאות.
- פניות תמיכה והיסטוריית מחלוקות.
כל אחת מהקטגוריות הללו דורשת החלטות מפורשות: כמה זמן אתם שומרים נתונים מזהים, מתי אתם עוברים לטפסים אנונימיים או מצרפיים, וכיצד אתם מכבדים בקשות מחיקה תקפות. חוקי מס וחשבונאות לרוב יושבים לצד עקרונות פרטיות אלה ויכולים לעקוף את בקשת המחיקה של שחקן עבור רשומות ספציפיות, לכן עליכם להיות מסוגלים להסביר את האינטראקציות הללו בבירור.
מידע זה הינו כללי ואינו מהווה ייעוץ משפטי. עליך תמיד לקבל הנחיות משפטיות ספציפיות לתחומי השיפוט ולמגוון המוצרים שלך.
הפיכת עקרונות וזכויות לכללי שמירה קונקרטיים
הפיכת זכויות פרטיות מופשטות לכללים ברורים היא חיונית אם אתם רוצים שמהנדסים וצוותי תפעול יפעלו באופן עקבי. עליהם לדעת, עבור כל קטגוריית נתונים, מהי המטרה, כמה זמן אתם שומרים אותה ומה קורה בסוף תקופה זו, כדי שיוכלו ליישם את ההתנהגויות הנכונות.
צוותי פרטיות ואבטחה מסכימים לעתים קרובות על העקרונות, אך חיכוכים נוצרים כאשר מהנדסים מבקשים פרטים ספציפיים. הם זקוקים למספרים והתנהגויות, לא לביטויים מופשטים. גישה מעשית היא לבנות לוח זמנים לשמירה ומחיקה אשר, עבור כל קטגוריה של נתוני שחקנים, מפרט:
- מטרה: – מדוע אתם מחזיקים בו, כגון אספקת המשחק, מניעת הונאה או עמידה בחוקי המס.
- בסיס או חובה משפטית: – הסכמה, חוזה, עניין לגיטימי, דרישה חוקית.
- תקופת שמירה סטנדרטית: – כמה זמן אתם שומרים נתונים מזהים בנסיבות רגילות.
- חריגים: – מצבים שבהם עליך לשמור נתונים למשך זמן רב יותר, כגון סכסוכים פתוחים או החזקות משפטיות.
- מצב סיום: – האם תמחק, הפכת את הנתונים לאנונימיים או תצבר אותם בסוף התקופה.
- שיטת מחיקה: – הגישה הטכנית בה אתם משתמשים, כגון מחיקת שורות, השמדת מפתחות או אנונימיזציה.
כאשר שחקן מפעיל את זכותו למחיקה, ניתן להסיק באופן שיטתי:
- אילו קטגוריות נכללות בבקשה?
- האם ישנן חובות חוקיות המחייבות אותך לשמור רישומים מסוימים, למשל חוקי מס או חוקי איסור הלבנת הון?
- באילו מערכות נמצאים הנתונים הרלוונטיים?
- אילו בקרות טכניות אתם מפעילים כדי למחוק או להפוך אותו לאנונימי היכן שמותר?
תיעוד ה-ISO 27001 שלכם והערכות ההשפעה על הפרטיות שלכם צריכים להצביע על אותו לוח זמנים, כך שלא תנסו לשמור על קבוצות מקבילות של כללים שנסחפות באופן בלתי נמנע והופכות קשות יותר להגנה.
טיפול בקטגוריות מסובכות: הונאה, קטינים וסכסוכים
חלק מהשאלות הקשות ביותר עולות סביב נתונים שבהם אתם משתמשים כדי להגן על העסק ועל שחקנים אחרים, משום שקטגוריות אלו מעלות שאלות של פרטיות והגינות, גם כשהן מצדיקות שמירה ממושכת יותר. ייתכן שתזדקקו לשמירה ממושכת לצורך הונאה והגנה מפני רמאויות, או כדי להגן על תביעות משפטיות, אך אתם גם רוצים למזער את מה שאתם מחזיקים על אנשים פרטיים לאורך זמן.
חלק מהשאלות הקשות ביותר עולות סביב הנתונים שבהם אתם משתמשים כדי להגן על העסק שלכם ועל שחקנים אחרים:
- יומני הונאה ונגד רמאויות: – ייתכן שתזדקק לשמירה ארוכה יותר כדי לזהות דפוסים ולהגן על שלמות המשחק.
- נתוני תשלום ומס: – חוקים פיננסיים דורשים לעתים קרובות לשמור רשומות מסוימות למשך מספר קבוע של שנים.
- יומני סכסוכים ותמיכה: – ייתכן שתזדקק לתיעוד עד שיפוגו תקופת ההתיישנות לתביעות משפטיות.
- נתוני קטינים ושחקנים שהוחרגו מעצמם: – ייתכן שיש לך התחייבויות נוספות להגן על קבוצות פגיעות או להגביל עיבוד מסוים.
דפוס הגיוני הוא לקבוע כללים ברורים ומתועדים עבור מקרים אלה במקום לאפשר החלטות אד-הוק. לאחר מכן ניתן לתכנן בקרות שמכירות הן במטרת ההגנה והן בסיכון הפרטיות.
שלב 1 – תיעוד המתח
רשמו מדוע אתם זקוקים לשמירה ממושכת בתחומים ספציפיים, כולל התייחסויות לציפיות משפטיות, רגולטוריות או פלטפורמתיות, כך שהפשרה תהיה שקופה.
שלב 2 – הפרדת נתונים בסיכון גבוה
שמרו יומני רישום ופרופילים בסיכון גבוה במקומות ברורים ומוגבלים עם בקרות גישה חזקות וכללי שמירה ברורים כדי שלא יתמזגו עם מערכות כלליות.
שלב 3 – צמצום הזיהוי לאורך זמן
עברו מזיהוי מלא לשמות בדויים, ומשמות בדויים לנתונים מצטברים או אנונימיים לחלוטין בהקדם האפשרי, תוך עמידה בצורכי ההגנה שלכם.
שלב 4 – סקירת שמירה ממושכת באופן קבוע
שלבו סקירה תקופתית של מקרים מיוחדים אלה בתוך הממשל, כך ששמירה "זמנית" לא תהפוך לקבועה עקב הזנחה או נוחות.
דוגמאות קונקרטיות מקלות על הפעולה על רעיונות אלה. יומני הונאה עשויים להיות מאוחסנים במסד נתונים ייעודי שבו נשמרים רק מזהים מגובבים לאחר גיל מסוים, מה ששומר על דפוסים גלויים אך אנשים פחות חשופים. נתוני תשלום עשויים להיות מפוצלים כך שרק מספרי העסקאות והסכומים המינימליים הנדרשים לחוקי המס יישמרו במערכת פיננסית, בנפרד מפרופילי משחק. חשבונות של קטינים ושחקנים שהוחרגו מעצמם עשויים להיות מסומנים כך שחלק מהרשומות הקשורות לבטיחות יישמרו לתקופות מוגדרות, בעוד שנתוני טלמטריה ופרופילציה של שיווק ינותקו מוקדם הרבה יותר.
סעיף A.8.10 אינו גובר על חובותיך המשפטיות, וחוק הפרטיות אינו מונע ממך לשמור נתונים שאתה באמת זקוק להם לצורך הגנה משפטית או ציות. הנקודה היא שכל שמירה ממושכת חייבת להיות מוצדקת, מתועדת ולאכופה טכנית, ולא רק מתקבלת בהנחה, כך שרגולטורים ושחקנים יוכלו לראות שאתה פועל בצורה הוגנת.
מיפוי נתוני השחקן ומחזור החיים של יומן הלוג ל-A.8.10
כדי ש-A.8.10 יעבוד בפועל, צריך לחשוב במונחים של מחזור חיים. נתוני שחקנים לא פשוט מופיעים ונעלמים; הם עוברים מאיסוף לשימוש פעיל, ואז לשכבות אחסון שונות לפני שהם נמחקים או הופכים לאנונימיים לבסוף, ו-A.8.10 מצרף בקרות לכל שלב במסע הזה. מחיקה מאובטחת הופכת להרבה יותר קלה כאשר יודעים, עבור כל שלב, היכן נמצאים הנתונים ומה אמור לקרות בהמשך, וכאשר כולם באבטחה, פרטיות, הנדסה ו-LiveOps חולקים את אותה מפה.
לאולפנים רבים יש מודלים מנטליים בלתי פורמליים של זרימה זו, אך מעטים שרטטים אותה באופן שצוותים שונים יכולים להסתמך עליו כשהם מעצבים מערכות, תכונות ותהליכים תפעוליים.
ויזואלי: דיאגרמת מחזור חיים פשוטה מאוסף → שימוש פעיל → ארכיון חם → ארכיון קר → מחיקה/אנונימיזציה.
מחזור חיים טיפוסי במשחקים מודרניים
רוב ערימות המשחקים המודרניות עוקבות אחר דפוס דומה, גם אם התוויות שונות, מכיוון ששחקנים יוצרים אירועים, אתם מעבדים אירועים אלה כדי לספק חוויות ואז אתם מעבירים לאט לאט נתונים ישנים יותר למאגרי נתונים קרים, זולים או מוגבלים יותר. החלטות מחיקה ואנונימיזציה עובדות רק אם הן מכבדות את הזרימה האמיתית הזו במקום להעמיד פנים שכל הנתונים נמצאים במסד נתונים מסודר אחד.
למרות שכל כותרת שונה, השלבים הכלליים מוכרים:
- איסוף ובליעה: – שחקנים נרשמים, מאמתים, משחקים משחקים, משוחחים, מוציאים כסף, ואתם מטמיעים אירועים לתוך מערכות תמיכה, יומנים וניתוחים.
- שימוש פעיל: – הנתונים משמשים לאספקת המשחק, להפעלת LiveOps, לביצוע שידוכים, לניהול מלאי ולמתן תמיכת לקוחות.
- ארכיון חם: – נתונים ישנים יותר עוברים לאחסון זול יותר או לטבלאות בעלות עדיפות נמוכה יותר, אך נשארים ניתנים לזיהוי למשך זמן מה, למשל לצורך שחזור חשבון או חקירות ארוכות טווח.
- ארכיון קר: – נתונים נשמרים רק לצורך התחייבויות כגון חקירות מס, רגולציה או הונאה חמורה, לרוב במערכות מוגבלות יותר.
- מחיקה או אנונימיזציה: – נתונים מוסרים או משנים כך שאינם קשורים עוד לשחקן בר-זיהוי.
מחזור חיים זה חל לא רק על טבלאות חשבונות, אלא גם על יומני תצפית ואבטחה, טלמטריה ואגמי נתונים, מערכות נגד רמאויות וניקוד סיכונים, כלי תמיכה ומתיחות, ואינטגרציות וייצוא של צד שלישי. ככל שתוכלו להראות בצורה ברורה יותר אילו מערכות ומערכי נתונים נמצאים בכל שלב, כך יהיה קל יותר להקצות בקרות A.8.10 ולהסביר אותן לרואה חשבון או לבעלי עניין ספקנים.
חיבור בקרות A.8.10 לכל שלב
צירוף סעיף A.8.10 למחזור החיים פירושו להגדיר מה חייב להיות נכון בכל פעם שנתונים חוצים גבול, משום שאותם גבולות הם המקומות שבהם הסיכון משתנה. אתם אוספים נתונים חדשים, מעבירים אותם לאחסון חדש או מחליטים שהם אינם נחוצים עוד, וכל מעבר הוא הזדמנות לאכוף מחיקה, מזעור או אנונימיזציה.
דרך שימושית אחת לחשוב על כך היא להתייחס ל-A.8.10 כרשימת תיוג שמופעלת בכל גבול שלב.
כאשר נתונים עוברים מ אוסף לשימוש פעיל:
בדוק מה אתה אוסף
ודא שהשדות מוגבלים למה שדרוש למשחק, פעולות וחובות, ולא רק למה שאתה יכול ללכוד לשם עניין.
הפרדת מזהים מתוכן
בנו סכמות כך שניתן יהיה להסיר או להחליף מזהי שחקנים מבלי להרוס את כל התוכן האנליטי או המדדים העסקיים השימושיים.
כאשר נתונים עוברים מ שימוש פעיל לחימום ארכיוני:
אשר את טריגר השמירה
קבעו זמן או אירוע ברור שאחריו הנתונים יוצאים ממאגרי נתונים פעילים, ותעדו כיצד טריגר זה מיושם בצינורות או בשירותים הרלוונטיים.
צמצום גישה והתאמת בקרות
הדקו את הגישה לנתונים המאוחסנים בארכיון והגדירו מגבלות שמירה בהתאם ללוח הזמנים שלכם, כך שרשומות ישנות יותר לא יצטברו בשקט.
כאשר נתונים עוברים מ ארכיון מחם לקר:
להצדיק את מה שנותר
יש לוודא שרק נתונים הדרושים באמת למטרות משפטיות, רגולטוריות או ביטחוניות מועברים לאחסון בקירור, ושהצדקה זו מתועדת.
יש להחיל אמצעי הגנה חזקים יותר
יש להחיל בקרות גישה מחמירות יותר, ניטור, ובמידת הצורך, הצפנה עבור ארכיונים קרים, כך שנתונים שכמעט ולא נהוגים בהם לא יהפכו למטרה קלה.
כאשר נתונים עוברים מ מארכיון קר למחיקה או אנונימיזציה:
אוטומציה של מצב הסיום
הגדירו משימה או תהליך אוטומטיים שמוחקים או מאנונימיים נתונים כאשר תוקף השמירה פג, במקום להסתמך על ניקויים אד-הוק.
לכידת ראיות וכשלונות
רשום ריצות מוצלחות וחריגים כדי שתוכל להוכיח שהבקרה פועלת, לחקור כשלים ולשפר את הגישה שלך לאורך זמן.
בכל גבול, עליכם להיות מסוגלים לענות: "אם אנו אומרים שהנתונים עוברים לשלב זה לאחר X, כיצד אנו יודעים שזה אכן קרה, ומה קורה לאחר מכן?" תשובות אלו הופכות לעמוד השדרה של בקרות A.8.10 שלכם ועוזרות לכם להראות לרגולטורים ולשותפים שאתם מתייחסים ברצינות למחזור החיים המלא.
כולל גיבויים, נתוני בדיקה ופינות אפלות
גיבויים, סביבות בדיקה וייצוא לרוב נמצאים מחוץ לחשיבה היומיומית על מחזור החיים, אך הם מכילים כמויות גדולות של נתוני שחקנים שיכולים לפגוע בשקט במאגרי המחיקה שלכם. אינכם צריכים לנסח מחדש את כל עיצוב הגיבוי שלכם כאן, אך עליכם לשלב את האזורים הללו באותה מפה ולאחר מכן להסתמך על הסטנדרטים הטכניים שלכם כדי לכסות כיצד מחיקה מתרחשת בפועל.
קל להתמקד במערכות העיקריות ולשכוח היכן הנתונים נשארים. גיבויים ועותקים משוכפלים ראויים לתוכנית משלהם. אם אתם משתמשים בגיבויים ארוכי טווח, ייתכן שלא תוכלו למחוק באופן כירורגי נתונים של שחקנים בודדים. במקרה כזה, עליכם:
- הצפנ גיבויים באמצעות מפתחות חזקים ומנוהלים היטב.
- קבעו תקופות שמירה וודאו כי ערכות שפג תוקפן מוסרות.
- ודא שגיבויים ישנים פג תוקפם או הופכים לבלתי ניתנים לשחזור, לדוגמה על ידי השמדת מפתחות או ניקוי מדיה.
סביבות בדיקה ותהליכי ביניים יכולות להכיל כמויות גדולות של נתוני ייצור. אם אתם זורעים אותן עם רשומות חיות, הן חייבות להיות בטווח של כללי מחזור החיים והמחיקה שלכם, או שעליכם להפוך את הנתונים לאנונימיים לפני השימוש כדי שמפתחים יעבדו עם מידע ריאליסטי אך לא ניתן לזיהוי.
יש להסדיר או להימנע משימוש בייצוא ודוחות – קבצי CSV, תמציות נתונים וצילומי מסך המשמשים לניתוח או דיווח. במקומות בהם ייצוא הכרחי, יש לאחסן אותו במיקומים מבוקרים עם כללי שמירה ברורים, ולהעדיף דיווח או לוחות מחוונים מרכזיים במידת האפשר.
טבלה פשוטה יכולה לעזור, עם עמודות כגון "אחסון או מערכת", "שלב מחזור חיים" ו"התנהגות שמירה ומחיקה", ולא יותר מקומץ שורות לכל כותרת. לאחר שמיפוי זה קיים, ניתן ליישר אליו כלים ופלטפורמות. פתרון ISMS משולב כגון ISMS.online מספק לכם מקום אחד לאחסון מחזור החיים, המדיניות המתייחסת אליו והראיות המראות שהוא מיושם, כך שתוכלו לנהל פינות אפלות באופן מכוון כמו מערכות ראשוניות.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
דפוסים טכניים למחיקה מאובטחת במסדי נתונים, יומנים, גיבויים וטלמטריה
מחיקה מאובטחת עובדת רק אם הארכיטקטורה הבסיסית הופכת את היישום לפרקטי ובטוח עבור הצוותים שלכם. אתם זקוקים לקבוצה קטנה של דפוסים סטנדרטיים שמהנדסים מבינים, זולים לתפעול ושמבקרים יכולים לעקוב אחריהם, כך שלא תצטרכו להמציא מחדש את המחיקה עבור כל משחק ושירות.
אפילו המדיניות הטובה ביותר משמעותית מעט אם הארכיטקטורה שלכם הופכת את המחיקה לקשה או מסוכנת. החדשות הטובות הן שיש דפוסים חוזרים שניתן ליישם על פני טכנולוגיות רבות. המטרה אינה שלמות מהיום הראשון, אלא קבוצה קטנה של גישות סטנדרטיות שמהנדסים מבינים, שמתאימות לשינויים שלכם ושמבקרים יכולים לעקוב אחריהן.
מטרת תכנון מרכזית היא להפוך את המחיקה לבטוחה וזולה יותר מאשר התעלמות מהבעיה. משמעות הדבר בדרך כלל היא תכנון המחיקה ברמת הסכימה והצנרת במקום לנסות לחזק אותה מאוחר יותר.
מחיקה מאובטחת במסדי נתונים ושירותים של ייצור
מחיקה מאובטחת במסדי נתונים חיים פירושה הסרה או ביטול זיהוי של נתוני שחקנים מבלי לפגוע בפונקציונליות המשחק, תוך מתן ביטחון שהרשומות אינן מתעכבות בשקט בטבלאות נשכחות. יש לכם כמה דפוסים עיקריים לבחירה, ועליכם לתקנן את אלה התואמים את תיאבון הסיכון והבגרות התפעולית שלכם.
עבור מסדי נתונים המכילים חשבונות שחקנים, פרופילים, מלאי ונתוני ליבה אחרים, עומדות בפניך מספר אפשרויות:
- מחיקת שורה פיזית: – פעולות מחיקה פשוטות עם פעולות מדורגות מתאימות, ולאחר מכן משימות תחזוקה כגון שאיבת אבק או דחיסה כדי להחזיר נפח אחסון במידת הצורך.
- מחיקה רכה ומחיקה קשה תקופתית: – סימון רשומות כמחוקות לתקופה קצרה כדי לתמוך בשחזור חשבון או בבטיחות תפעולית, ולאחר מכן מחיקה מלאה לאחר מרווח זמן מוגדר.
- חלוקה לפי זמן או דייר: – מבנה טבלאות או אוספים כך שניתן יהיה להסיר או לאחסן כמויות גדולות של נתונים ישנים בבת אחת.
לא משנה איזה דגם תבחרו, עליכם:
- הפרד מזהים מתוכן פחות רגיש במידת האפשר, כך שמחיקת טבלת צירוף קטנה תוכל למעשה לבטל את הזיהוי של גופים גדולים של נתוני משחק.
- ודא שלוגיקת האפליקציה לא "מחזירה לתחייה" נתונים שנמחקו ממטמונים, מדדי חיפוש או ממאגרי זיכרון נגזרים.
- יש ליישם שגרות מחיקה אידמפוטנטיות כך שניסיון חוזר של משימה שנכשלה לא יפגע בשלמות או ישאיר אותה במצב חלקי.
- בדקו ביסודיות את התנהגות המחיקה המדורגת ושלמות ההפניות בסביבות שאינן סביבת ייצור, כך שמנהלי מסדי נתונים זהירים יוכלו לראות את ההשפעה לפני שתיגעו בנתונים חיים.
תעדו דפוסים אלה כחלק מהסטנדרטים הטכניים שלכם עבור A.8.10, וקשרו אותם בחזרה לכללי השמירה בלוח הזמנים שלכם. בדרך זו, כאשר משחק או פיצ'ר חדש מושקים, מהנדסים יודעים איזה דפוס ליישם וכיצד להוכיח שהוא עובד.
תכנון יומני רישום וטלמטריה רגישים לשמירה
יומני רישום וטלמטריה חיוניים להפעלת משחקים ולשיפורם, אך הם גם אחד המקורות הרועשים ביותר של נתונים אישיים ומקור נפוץ לשמירת יתר שמגדיל בשקט את הסיכון. המטרה אינה להפסיק את הרישום או לכבות מערכות, אלא ללכוד רק את מה שאתה צריך, לשמור אותו כל עוד הוא שימושי ואז למחוק אותו או להסיר קישורים ישירים לאנשים, תוך תכנון השמירה והמחיקה מראש.
עקרונות שימושיים כוללים:
- סווג יומני רישום לפי מטרה: – אבטחה, הונאה, ניתוח משחקיות ואבחון קריסות עשויים כל אחד להצדיק חלונות שמירה שונים.
- הימנעו מרישום יותר ממה שאתם צריכים: – אין לכלול מזהים מלאים או מטענים אם גיבוב (hashes), טוקנים או מדדים מצטברים יספיקו.
- השתמש בבקרות שמירה מובנות: – רוב פלטפורמות הרישום והטלמטריה מאפשרות לך להגדיר שמירה מבוססת זמן ומחיקה אוטומטית; הגדר זאת בהתאם ללוח הזמנים שלך.
- שקלו אנונימיזציה: – עבור נתונים ישנים יותר המשמשים רק בניתוח מצרפי, יש להחליף מזהים באסימונים או להסיר אותם לחלוטין לאחר תקופה מסוימת.
בפועל, זה יכול להתבטא בשמירת יומני אבטחה מפורטים לתקופה מוגדרת, ולאחר מכן שמירה של נתונים גסים בלבד לצורך ניתוח מגמות, או שמירה של אירועי משחק מפורטים ברמת השחקן לתקופה קצרה כדי לכוונן תכונות, ולאחר מכן איגודם לקבוצות אנונימיות. המפתח הוא שהתנהגויות אלו מוגדרות באופן מרכזי וניתן לאמת אותן, ולא להשאיר אותן לצוותים בודדים להחליט עליהן אד-הוק.
גיבויים, ארכיונים ומחיקה קריפטוגרפית
גיבויים וארכיונים בנויים כדי לשמר נתונים, כך שמחיקה מאובטחת כאן עוסקת בניהול מערכי גיבוי שלמים במקום בניסיון למחוק שחקנים בודדים, ועדיין לספק לכם סיפור אמין על מה שקורה כאשר השמירה פגה. אתם מסתמכים על הצפנה, שמירה מוגבלת בזמן והשמדה מבוקרת של מפתחות או מדיה כדי להראות שנתונים שפג תוקפם אינם נגישים עוד בפועל.
גיבויים מציבים אתגר מיוחד משום שהם מתוכננים במיוחד לשמר נתונים, ולעתים קרובות בגוונים גדולים ואטומים. לעיתים רחוקות יש לך את היכולת למחוק נתונים של שחקן אחד מעשור של גיבויים מלאים. במקום זאת, אתה מנהל את המחיקה ברמת קבוצות הגיבוי.
שלבים מעשיים כוללים:
- הצפנת גיבויים וארכיונים: עם מפתחות חזקים המנוהלים בנפרד מהנתונים.
- הגדר תקופות שמירת גיבוי: שמתאימות לתיאבון הסיכון ולחובות המשפטיות שלך, ונמנעות משמירה של גיבויים ללא הגבלת זמן.
- ודא שגיבויים ישנים הופכים לבלתי ניתנים לשחזור: על ידי השמדת המפתחות או המדיה הרלוונטיים באופן מבוקר ומתועד כאשר תוקף השמירה פג.
- הימנעו משימוש בגיבויים כארכיונים: על ידי שמירת רשומות ארוכות טווח במאחסנים ייעודיים ומבוקר גישה, עם שמירה ברורה במקום גיבויים שחזור כלליים.
מחיקה קריפטוגרפית - הפיכת נתונים לבלתי קריאים על ידי מחיקה או ביטול מפתחות - היא לעתים קרובות הדרך המעשית היחידה לעמוד בדרישות A.8.10 עבור גיבויים בקנה מידה גדול ומאגרי אובייקטים מבוזרים. זה תלוי בניהול מפתחות חזק; אם המפתחות נמצאים בשימוש חוזר על פני מערכי נתונים רבים או מוגנים בצורה גרועה, ההבטחות שלכם חלשות יותר. עם זאת, בפריסה זהירה, מחיקה קריפטוגרפית מאפשרת לכם לשלב חוסן תפעולי עם הבטחות חזקות שנתונים שפג תוקפם באמת נעלמו, מה שמגן הן על השחקנים והן על הסטודיו שלכם כאשר מתרחשות תקריות.
ממשל, תפקידים וחריגים: לגרום למחיקה לעבוד בעסקי משחקים חיים
מחיקה מאובטחת נשארת רק כאשר כולם יודעים מי מחליט מה, מי עושה את העבודה ואיך מטפלים בחריגים, כי אחרת נתוני שחקנים ישנים מצטברים בשקט כאשר שיחות קשות נדחות. ממשל ברור הופך את A.8.10 מפרויקט צדדי לחלק נורמלי מאופן הפעלת המשחקים והשירותים שלך.
מחיקה אינה משימה של צוות אחד. אבטחה לא יכולה לעשות זאת לבד, הנדסה לא יכולה לעשות זאת לבד, וגם לא פרטיות או LiveOps. כדי לגרום ל-A.8.10 לעבוד ללא חיכוכים מתמידים, צריך ממשל ברור: מי מקבל אילו החלטות, מי מיישם אותן, מי בודק שהן עובדות וכיצד מטופלים חריגים.
בלי הבהירות הזו, מחיקה הופכת לסדרה של שיחות לא נוחות ופניות תקועות, מה שבתורו מעודד אנשים להימנע מהעלאת הנושא כלל. עבור צוותים שרק מתחילים את המסע שלהם לתקן ISO 27001, העלאת האחריות הזו על הכתב מוקדם מונעת מאדם או שניים לספוג בשקט את כל העבודה.
הגדרת מי הבעלים של מה
הגדרת בעלות על החלטות שמירה ומחיקה מונעת בלבול והאשמות, משום שכולם יכולים לראות מי אחראי ומי אחראי. מטריצת RACI פשוטה שממנה מי אחראי, אחראי, מי מתייעץ ומעודכן מבהירה מי חייב לאשר את הכללים ומי חייב לשמור על הבקרות הטכניות פועלות.
מטריצת RACI פשוטה (אחראי, אחראי, מתייעץ, מודע) למחיקה יכולה למנוע בלבול רב. דפוסים אופייניים כוללים:
- אבטחה או פונקציית CISO: – אחראי על הבטחת יישום A.8.10 כחלק ממערכת ה-ISMS; מתייעץ בנוגע להשפעות הסיכונים.
- פרטיות או ה-DPO: – אחראי לוודא שהשמירה והמחיקה תואמות את החוקים וזכויות השחקנים.
- הנדסת נתונים ופלטפורמות: – אחראי על יישום ותפעול של מחיקה טכנית או אנונימיזציה.
- LiveOps ומוצר: – התייעץ בנוגע להשפעת השמירה והמחיקה על תפעול וניתוח נתונים של משחקים.
- צוותי תמיכה בשחקנים וקהילתיים: – אחראי על טיפול בתקשורת מול שחקנים וניתוב מקרים מורכבים.
לאחר שתפקידים אלה מוסכמים, ניתן לשלב אותם במקטעי בעלות על מדיניות, תהליכי עבודה של ניהול שינויים וקליטתם של מערכות וספקים חדשים. בדרך זו, כאשר מישהו שואל "מי מחליט כמה זמן לשמור יומני צ'אט?", תהיה תשובה אחרת מלבד "תלוי עם מי מדברים", והחלטות מחיקה יכולות להתקדם באותו קצב כמו פיתוח המשחק.
תכנון חריגים מבלי לאבד שליטה
כמעט כל סטודיו יזדקק לחריגים לכללי השמירה הסטנדרטיים שלו מסיבות של הונאה, בטיחות או משפט, אך הסכנה היא שחריגים אלה יהפכו לקבועים מתוך הרגל. תהליך חריגים קל אך ממושמע מאפשר לך לשמור על נתונים חשובים כשאתה חייב, למשל במהלך חקירות רמאות או בירורים רגולטוריים, מבלי לערער בשקט את כל אסטרטגיית המחיקה שלך.
כמעט כל סטודיו יזדקק לחריגים לכללי השמירה הסטנדרטיים שלו. הונאה, רמאות, אירועי בטיחות חמורים וחקירות רגולטוריות - כל אלה דורשים לפעמים שמירת נתונים למשך זמן רב מהרגיל. הסיכון הוא שחריגים מצטברים באופן לא רשמי ואף אחד לא יבקר בהם שוב.
גישה איתנה היא:
- לדרוש הצדקה מתועדת לכל שמירה מורחבת, כולל הפניות משפטיות או רגולטוריות במידת הצורך.
- קבע תאריך או תנאי לבדיקה לכל חריג, כגון "עד לסגירת חקירה X ועוד שנתיים".
- הגבל את הגישה למאגר השמירה המורחבת לקבוצה הקטנה ביותר שבאמת זקוקה לכך.
- סקירת חריגים פתוחים בפורום ממשל קבוע וסגירתם כאשר אינם נחוצים עוד.
רישום חריגים טוב עשוי להיראות כך: "תיק הונאה F-123 - שמור יומני עסקאות, מכשירים ורשת רלוונטיים עד 31 בדצמבר 2028; בעלים: ראש מחלקת הונאה; סקירה רבעונית של ועדת הסיכון". רמת ספציפיות זו שומרת על כולם מתואמים ומספקת לך נתיב ביקורת ברור, התומך הן בביקורות ISO 27001 והן בבדיקה רגולטורית.
הכשרת צוותי קו ראשון ויישור בין פעולות LiveOps
צוותי חזית מתרגמים את מדיניות המחיקה שלכם להבטחות הפונות לשחקנים, כך שאם צוותי תמיכה וקהילה מתארים "מחיקת חשבון" בצורה שונה מהאופן שבו המערכות שלכם מתנהגות, אתם יוצרים בעיות אמון ותאימות. יישור הדרכה, סקריפטים ותכנון LiveOps עם בקרות A.8.10 שלכם מונע פערים אלה.
שחקנים, הורים ואפילו שותפים לעיתים קרובות יפעלו תחילה עם צוותי קו החזית: תמיכה, מנהלי קהילות, LiveOps. אם צוותים אלה אינם יכולים להסביר בבירור מה המשמעות של "מחיקת חשבון", או גרוע מכך, להבטיח דברים שאינם נכונים מבחינה טכנית, אתם יוצרים בעיות אמון ובעיות תאימות.
לכן עליך:
- ספקו הסברים פשוטים ושאלות נפוצות פנימיות המתארות, בשפה פשוטה, מה נמחק, מה ניתן לשמור מסיבות משפטיות ובמשך אילו לוחות זמנים.
- הכשרת הצוות לזהות מתי בקשה עלולה להוביל לעצירות משפטיות או חריגים מורכבים, וכיצד להסלים את הליך הפעולה בצורה הולמת.
- התאם את תכנון ה-LiveOps לשינויים עתידיים בשמירה או מחיקה, כך שאסטרטגיות טלמטריה או פילוח יותאמו בזמן.
כאשר כולם מבינים שמחיקה מאובטחת נועדה להגן על השחקנים ועל האולפן, לא לחסום רעיונות טובים, מקבלים פחות מאבקים של הרגע האחרון בין המוצר לתאימות - ועיצובים מתחשבים יותר התומכים בשניהם. זה, בתורו, מפחית את עלויות התקריות, מגביל את החשיפה הרגולטורית ובונה אמון שחקנים לטווח ארוך.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
ענן, ספקים ואחריות משותפת למחיקה
משחקים מודרניים מסתמכים במידה רבה על ספקי ענן ותוכנה כשירות, אך אתם עדיין נשארים אחראים לאופן שבו נתוני השחקנים מאוחסנים ונמחקים ברחבי המערכות שלכם. לכן, A.8.10 חייב להתרחב מעבר למערכות שלכם, כולל חוזים, תצורות והערכות סיכונים של ספקים, כך שנתונים לא יישמרו זמן רב מהנדרש רק משום שהם נמצאים בפלטפורמה של מישהו אחר.
מעט מאוד מחסנית משחקים מודרנית נמצאת אך ורק במרכז הנתונים שלך. זהות, תשלומים, ניתוח נתונים, שיווק, קהילה, תמיכה ואפילו מערכות צד-על מרכזיות - כולם עשויים להסתמך על ספקי ענן ותוכנה כשירות. תקן ISO 27001 A.8.10 עדיין חל; זה רק אומר שסטורי המחיקה שלך חייב לכלול גם את הספקים הללו.
אי אפשר פשוט לסמוך על כך ש"הספק מטפל בזה". עליכם להבין, לתעד, ובמידת הצורך, להגדיר חוזית מי מוחק מה, היכן ומתי. זה חשוב במיוחד כאשר ספקים מצביעים על האישורים שלהם; התאמה למסגרת אחת אינה מבטיחה שלוחות הזמנים של שמירת המידע שלהם תואמים את שלכם או שהם תומכים בלוחות הזמנים של המחיקה שלכם.
הבנת מודל האחריות המשותפת
הבנת מודל האחריות המשותפת עוזרת לך לראות אילו מנופי מחיקה אתה שולט בהם ואילו נמצאים בידי הספק, כך שתוכל לתכנן בקרות ריאליות ולא הנחות. אתה מחליט אילו נתוני שחקנים זורמים לשירות, כמה זמן הם נשארים ומתי אתה מבקש הסרה, בעוד שהספק אחראי על האופן שבו התשתית שלו נמחקת או ממוחזרת.
ספקי ענן מדברים בדרך כלל על אחריות משותפת: הם מאבטחים את התשתית, אתם מאבטחים את האופן שבו אתם משתמשים בה. לגבי מחיקה, זה מתחלק לרוב בערך כך:
- תשתית כשירות: – אתם שולטים במערכות הפעלה, מסדי נתונים ונתוני יישומים; הספק שולט במדיה פיזית ובחיטוי ברמה נמוכה.
- פלטפורמה כשירות: – אתם שולטים בנתונים ובתצורות שלכם בתוך שירותים מנוהלים; הספק מטפל בגיבויים ובמערכות הבסיסיות.
- תוכנה כשירות: – בדרך כלל אתה שולט בתצורה ובדפוסי השימוש; הספק שולט כמעט בכל השאר.
עבור כל שירות משמעותי, עליך להיות מסוגל לענות על:
- אילו נתונים על השחקנים שלך מאוחסנים כאן?
- מי יכול להגדיר שמירה ומחיקה?
- מה קורה לנתונים כשמוחקים חשבון או רשומה?
- כיצד הספק מטפל בגיבויים ובהחזרה או השמדה של נתונים בסוף חוזה?
תיעוד תשובות אלו מהווה חלק מתקן A.8.10 ומבקרות ISO 27001 אחרות סביב השימוש בענן, והוא מספק לכם בסיס ברור יותר לבחירת ספקים ולמשא ומתן.
הפיכת המחיקה לחוזה
מחיקה אמינה הרבה יותר כאשר היא כתובה בחוזים במקום מטופלת באופן לא רשמי, מכיוון שיש לכם בסיס ברור לטעון את הציפיות שלכם. הסכמי עיבוד הנתונים ולוחות הזמנים של האבטחה שלכם צריכים לפרט מגבלות שמירה, תמיכה בבקשות מחיקה וכיצד יטופלו הנתונים בסוף הקשר.
מדיניות וכוונות טובות אינן מספיקות כאשר ארגונים אחרים מחזיקים בנתונים שלכם. החוזים, הסכמי עיבוד הנתונים ולוחות הזמנים של האבטחה שלכם צריכים להתייחס ל:
- תקופות שמירה מקסימליות לנתונים לאחר שהם עוזבים את המערכות שלך.
- התחייבויות לסייע בבקשות מחיקת נתונים של שחקנים במסגרת לוחות זמנים מוסכמים.
- כיצד מטופלים גיבויים, יומנים וארכיונים בסוף תקופת השמירה או בסיום החוזה.
- אילו ראיות הספק יספק לך, כגון יומני מחיקה או אישורים, ובאילו נסיבות.
כמו כן, עליכם לוודא שהערכות הסיכונים של הספק שלכם מכסות מחיקה במפורש. אם ספק אינו יכול לתאר את מחזור חיי הנתונים שלו ואת נוהלי המחיקה שלו, או אם הוא מסתמך אך ורק על אישורים גנריים ללא פירוט שמירה, זהו סימן חשוב להתייחס אליו בזהירות או לנהל משא ומתן על תנאים מחמירים יותר. ציפיות התעשייה מעדיפות יותר ויותר התחייבויות ברורות ובכתב למחיקה בחוזים.
שמירה על שליטה על יצוא של צד שלישי
ייצוא של צד שלישי יוצר לעתים קרובות עותקים לא מנוהלים של נתוני שחקנים החורגים מבקרות רגילות, מה שיכול לערער בשקט אפילו אסטרטגיית מחיקה מעוצבת היטב. לוחות מחוונים, ייצוא CSV ומערכי נתונים מסונכרנים הם נוחים, אך אם לא נותנים להם כללי שמירה מפורשים, הם עלולים להישאר מבלי שיבחינו בהם במשך שנים.
אפילו כאשר שירותי ליבה מתנהגים כראוי, נתונים יכולים לדלוף לפינות לא מנוהלות באמצעות:
- ייצוא ידני מלוחות מחוונים לגליונות אלקטרוניים.
- סנכרון נתונים לתוך כלי בינה עסקית.
- קבצים מצורפים וקבצים במערכות כרטוס או שיתוף פעולה.
קל לשכוח עותקים אלה וקשה למחוק אותם בצורה ממוקדת. כדי להפחית את הסיכון:
- מזער ייצוא אד-הוק במידת האפשר והעדיף כלי ניתוח במקום.
- במקומות בהם ייצוא נחוץ, יש לאחסן אותו במקומות מוסדרים עם מגבלות שמירה.
- כללו דפוסים אלה במיפוי מחזור החיים שלכם ובהכשרת הצוות שלכם כדי שלא יתעלמו מהם.
באולפנים רבים, עצם הגברתם של הצוותים מהסיכון ומתן אלטרנטיבה טובה יותר - כגון דוחות או לוחות מחוונים מרכזיים - מפחיתים משמעותית את הבעיה. זה, בתורו, מפחית את הסיכוי שחקירה או פרצה יחשפו נתונים שאף אחד לא ידע שעדיין קיימים.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזר לך להפוך את תקן ISO 27001 A.8.10 מכלל מחיקה מעורפל למערכת בקרות ברורה וניתנת לביקורת, אשר מפחיתה את הסיכון מנתוני שחקנים שלא נמחקו ויומני שמירה רגישים לשמירה בכותרים ובשירותים שלך. על ידי ריכוז המדיניות, מלאי הנתונים, לוחות הזמנים של השמירה, הסטנדרטים הטכניים והראיות שלך, הפלטפורמה מעניקה לך תמונה אחת ואמינה של אופן ניהול המידע בין אולפנים וספקים.
ראה את קומת A.8.10 שלך במקום אחד
כאשר אתם מנהלים את עבודתכם בתקן ISO 27001 בסביבה ייעודית כמו ISMS.online, אתם נהנים ממספר יתרונות:
- מטריצות השמירה והמחיקה שלך יושבות לצד הערכות סיכונים והצהרות תחולה, כך שתוכל להראות בדיוק כיצד A.8.10 ו-A.5.32 פועלים יחד כדי להפחית סיכונים שזוהו.
- דיאגרמות מחזור חיים, מלאי מערכת ורישומי ספקים הופכים לחפצים חיים, המתעדכנים ככל שהמשחקים והערימה שלכם מתפתחים במקום להיות נעולים בחפיסות שקופיות נשכחות.
- ראיות למחיקה - החל מייצוא תצורה ועד הערות ביקורת פנימית - ניתנות לקישור ישירות לבקרות שהן תומכות בהן, מה שהופך את הביקורות לפחות לבלבול של הרגע האחרון.
עבור צוותים המתאמים בין נושאים כמו אבטחה, פרטיות, נתונים, הנדסה ו-LiveOps, תצוגה משותפת זו הופכת את המחיקה מרעיון מעורפל לתוכנית עבודה קונקרטית וניתנת למעקב. זה גם נותן לאולפנים פחות מנוסים מבנה לעקוב אחריו כשהם מיישמים בקרות פורמליות בפעם הראשונה. פלטפורמת ISMS יכולה גם לאחסן את מפות מחזור החיים, לוחות הזמנים של השמירה ורישומי הספקים שלכם במקום אחד, כך שלא תנסו לחבר את קומת A.8.10 ממסמכים מפוזרים וזיכרונות בודדים.
הצעדים הבאים עבור הסטודיו שלך
אם אתם מזהים את הסביבה שלכם באתגרים שתוארו לעיל, שיחה קצרה וממוקדת יכולה להספיק כדי לראות איך משהו טוב יותר יכול להיראות. אתם יכולים לבחור:
- סקור את מחזור החיים של נתוני השחקן של אחד המשחקים ובדוק היכן בקרות המחיקה והשמירה הנוכחיות לוקות בחסר.
- סקור כיצד ניתן לעשות שימוש חוזר בתיעוד ISO 27001 הקיים שלך ולחזק אותו כדי לכסות את A.8.10 בצורה מעמיקה יותר.
- גלו כיצד זרימות עבודה, הקצאות משימות ולוחות מחוונים יכולים לשמור על תיאום בין צוותים שונים לגבי מי צריך לעשות מה ומתי, כדי לשמור על המחיקה במסלול הנכון.
הזמינו הדגמה עם ISMS.online ותראו כיצד ניתן לאחד את כל החלקים הנעים של נספח A.8.10 - החל ממגבלות שמירה חוקיות ומיפוי מחזור חיים ועד דפוסי מחיקה טכניים וראיות ביקורת - במערכת אחת וניתנת לניהול. זה, בתורו, מאפשר לכם לכבד את נתוני השחקנים, להפחית את ההשפעה של אירועים, לספק את מבקרים ורגולטורים ולהמשיך לספק משחקים נהדרים בביטחון.
הזמן הדגמהשאלות נפוצות
כיצד סטודיו למשחקים צריך לחשוב מחדש על מחיקת נתוני שחקנים תחת תקן ISO 27001 A.8.10?
עליך להתייחס למחיקת נתוני השחקן כאל שלב מתוכנן ומוכח במחזור החיים, לא טובה אד-הוק שאתה מבצע באמצעות פניות תמיכה.
כיצד משנה סעיף A.8.10 הנחות יומיומיות לגבי "מחיקה"?
תחת תקן ISO 27001 A.8.10, "אנו מוחקים חשבונות כאשר שחקנים מבקשים" הופך למינימום ההכרחי, ולא למודל התפעולי. הסעיף מצפה ממך:
- התייחסו לכל קטגוריית נתוני שחקן (חשבונות, תשלומים, צ'אט, טלמטריה, אנטי-צ'יט, תמיכה) כאל... נכס מנוהל עם מטרה, בעלים ומצב סיום מוגדר.
- החליטו מראש מתי כל קטגוריה עוברת מ שימוש פעיל (נדרש כדי להריץ או להגן על המשחק) ל שמירה מוצדקת (מס, סכסוכים, הונאה, בטיחות) ולבסוף ל הסרה או אנונימיזציה.
- הפכו את ההחלטות הללו ל דפוסים טכניים חוזריםתוקנו חלונות מחיקה רכה, מחיקות קשות מתוזמנות, משימות אנונימיזציה וכללי מחזור חיים בפלטפורמות אחסון ויומן.
- ללכוד ראיות לכך שדפוסים אלה פועליםיומני משימות, רישומי שינויים, ייצוא תצורה ובדיקות לדוגמה שמערכת ה-ISMS שלך יכולה לשמור לצד בקרת A.8.10.
המעבר האמיתי הוא מאלתור ל יכולת חיזוילאולפן שיודע בדיוק היכן עדיין קיימים שחקנים מזוהים, היכן נותרו רק קבוצות אנונימיות, ומה שהתיישן לחלוטין, יש רדיוס פיצוץ קטן יותר כשמשהו משתבש, וסיפור נקי יותר כשהוא מסביר את עצמו למבקרים או לפלטפורמות.
כיצד ISMS הופך את החשיבה הזו למעשית?
מערכת ניהול אבטחת מידע מעניקה לכם מקום אחד לקישור מדיניות, סיכונים ויישום:
- אתם שומרים מלאי של קטגוריות נתונים, כללי שמירה ותקני מחיקה בסביבת עבודה אחת.
- כל בקרה לפי A.8.10 מקושרת לסיכונים, מערכות ונהלי תפעול ספציפיים במקום להיות ניסוח מופשט.
- ביקורות פנימיות, אישורי שינויים וסקירות אירועים יכולים כולם להתייחס לאותם ארטיפקטים, כך שמחיקה הופכת איך אתם בונים ומפעילים משחקים, לא ניקיון חד פעמי לפני הסמכה.
כאשר אתם יכולים ללוות את מבקר החשבון ברוגע מרישום סיכונים → כללי שמירה → דפוסים טכניים → ראיות, נראה שהסטודיו שלכם מבין את אמון השחקנים לטווח ארוך, ולא רק אספקת תכונות לטווח קצר. ISMS כמו ISMS.online הופך את ההדרכה הזו להרבה יותר קלה על ידי שמירה על קשר הדוק בין בקרות, רשומות ואחריות ותמיד מעודכנת.
כיצד נוכל לתכנן לוחות זמנים לשמירת נתוני שחקנים המגנים על הונאה, אבטחה וערך אנליטי?
אתה מעצב את השמירה סביב מדוע אתם מחזיקים בכל קטגוריה ואיזה חוק או חוזה מאפשרים זאת, לא סביב מסד הנתונים או לוח המחוונים שמרגישים הכי חשובים.
כיצד בונים מטריצת שימור נתונים שתעבוד על פני כל נכס המשחקים?
רוב האולפנים נהנים מיחידה מטריצת שימור שמכסה את מלוא טווח סוגי נתוני השחקנים:
- חשבון וזהות (כניסות, פרטי קשר, סימני גיל)
- רישומי תשלומים וחיוב
- צ'אט ואינטראקציות חברתיות
- יומני אבטחה ותשתית
- אינדיקטורים נגד רמאות והונאה
- טלמטריה של משחקיות ואנליטיקה של חוויית משתמש
- כרטיסי תמיכה ותמיכה קהילתית
עבור כל שורה אתה מציין ארבעה דברים:
- מטרה: – מדוע אתם אוספים אותו (להפעיל את המשחק, לחייב שחקנים, לשמור על בטיחות, להילחם בהונאות, לשפר את העיצוב).
- בסיס משפטי / חוזי: – דיני צרכנות, כללי מס, PCI DSS, תנאי פלטפורמה, דיני פרטיות וכן הלאה.
- שמירה מינימלית: – מה שעליכם לשמור כדי להישאר תאימים (לדוגמה, רישומי מס או חלונות לביטול חיובים.
- שמירה מקסימלית של נתונים ניתנים לזיהוי: – הנקודה שבה אתם מוחקים או הופכים אנשים לאנונימיים, גם אם אתם שומרים דפוסים מצטברים.
הונאה ואבטחה הן הגורמים שבהם צוותים נוטים לגלוש ל"לשמור הכל, לנצח". A.8.10 אינו מונע חלונות זמן ארוכים יותר כאשר הסיכון באמת מצדיק זאת, אך הוא מצפה מכם:
- תן את הקטגוריות האלה משכי זמן מפורשים ומנומקים (לדוגמה, תקופת מחלוקת בתוספת חיץ מוגדר).
- הפרד רשומות גולמיות שניתן לזהותן מ אותות נגזרים (ציוני סיכון, מזהים מגובבים, קבוצות קוהורט אנונימיות), כך שתוכלו לשמור אותות למשך זמן רב יותר מאשר זהות.
- התייחסו לחקירות חריגות כאל חריגים המוגדרים בזמן, לכל אחד מהם יש תאריך בעלים ותאריך סקירה, במקום החרגות קבועות שלא צוינו.
בצד האנליטיקה, רוב החלטות העיצוב תלויות ב דפוסים ולא שחקנים ספציפייםזה מאפשר לך לקצר את השמירה עבור טלמטריה בנאמנות מלאה ולהעביר נתונים ישנים יותר אל צפיות מצטברות או אנונימיות שצוותי מוצר ונתונים עדיין יכולים לבצע שאילתות. זה גם מאלץ אותך להביא את הייצוא (חילוצי BI, קבצי CSV, מערכי נתונים של ארגז חול) לאותו מחזור חיים במקום להשאיר אותם כעותקים בלתי נראים לטווח ארוך.
היכן צריכים להיות הכללים האלה כדי שיישארו אמיתיים?
כללי שמירה מתפרקים במהירות אם הם מסתתרים בשרשורי דוא"ל או בגיליונות אלקטרוניים מבודדים. כשמנהלים אותם במערכת ניהול מידע (ISMS):
- פרטיות, אבטחה, ניתוח והנדסה - כולם יכולים לאשר מטריצה אחת ומשותפת.
- ניתן לקשר סקירות למרשם הסיכונים שלך ולמחזור סקירת ההנהלה.
- ראיות כמו צילומי מסך של תצורה, אישורי מדיניות ותוצאות בדיקות נקודתיות נמצאות לצד הכללים, כך שתוכלו להראות למבקרים גם ההחלטה וכיצד היא מתקיימת בפועל.
אם אתם רוצים להפוך את A.8.10 מדאגה לכלי עיצוב, ריכוז המטריצה הזו בפלטפורמה כמו ISMS.online עושה הבדל גדול. אתם מקבלים נקודת מבט אחת על שימור נתונים שתואמת את ISO 27001, את חובות הפרטיות ואת המציאות שלכם.
מה בעצם כרוכה מחיקה מאובטחת עבור מסדי נתונים, יומני רישום, טלמטריה וגיבויים של משחקים?
מחיקה מאובטחת פירושה שברגע שהנתונים מגיעים לסוף חייה המוגדרים, הם כבר לא ניתן לשחזר באופן מעשי במאמץ סביר, על פני מערכות חיות, ערימות אנליטיקה וגיבויים.
כיצד עלינו להתמודד עם שירותים חיים ומסדי נתונים?
עבור שירותי ליבה המחזיקים חשבונות, זכאויות, מלאי ורישומי שחקנים דומים, מחיקה מאובטחת משלבת בדרך כלל:
- פעולות ברמת היישום: , כגון מחיקה או אנונימיזציה של רשומות ברמת השורה לאחר עמידה בכלל שמירה או אימות בקשת מחיקה.
- חלוקה מבוססת זמן: , כך שניתן להסיר מחיצות או שברים שלמים בטבלה (לדוגמה, לפי חודש או עונה), ובכך להימנע מניקויים יקרים שורה אחר שורה.
- תחזוקת אחסון שוטפת - דחיסה או שאיבת אבק - כדי שרשומות "נמחקו" לא יישארו ללא הגבלת זמן בשטח לא מוקצה.
המפתח הוא לבטא את אלה כ דפוסי בית, לא בחירות של מפתחים אינדיבידואליים. תקן פנימי פשוט כמו "חשבונות משתמשים בדפוס א'; היסטוריית עסקאות משתמשת בדפוס ב'; מלאי משתמש בדפוס ג'" הופך את ההתנהגות לחיזוי בין כותרים וקלה הרבה יותר לתיעוד מול A.8.10.
מה לגבי יומנים, טלמטריה ואחסון לטווח ארוך?
זרמי יומן וטלמטריה מכילים לעתים קרובות הקשר עשיר יותר של השחקנים מאשר מסד הנתונים הראשי של המשחק. במערכות אלו, מחיקה מאובטחת נשענת במידה רבה על תצורה:
- מובנה בקרות שמירה וסיבוב בכלי רישום ותצפית, מכוונים בצורה שונה לזרמי משחק, ביצועים ואבטחה.
- מזעור מוקדם – גיבוב, קיצוץ או טוקניזציה של מזהים ליד המקור – כך שלא כל שורת יומן חושפת זהות מלאה, ולאחר מכן אנונימיזציה או דגימה מופחתת ככל שהנתונים מזדקנים.
- כללי מחזור חיים באחסון אובייקטים או באגמי נתונים שפג תוקפם או מאחסנים מערכי נתונים ומתואמים איתם ניהול מפתח, המאפשר לך להוציא משימוש מפתחות הצפנה כאשר הנתונים אמורים להיעלם למעשה.
גיבויים הם המקומות שבהם מחיקה פיזית של כל עותק מפסיקה להיות מציאותית. אולפנים בוגרים רבים מאמצים מחיקה קריפטוגרפית במקום זאת: להצפין מערכי נתונים נפרדים עם מפתחות מוגדרים ולהתייחס לפרישת מפתחות מתוזמנת כאל אירוע מחיקה. בשילוב עם מדיניות מחזור חיים ויומני ניהול מפתחות, זה מקובל באופן נרחב על ידי מבקרים ורגולטורים כדרך מעשית להפסיק לשמור היסטוריה קריאה.
מבחן העבודה הוא פשוט: עבור כל מאגר נתוני שחקן עיקרי ניתן לענות על שלוש שאלות - מה קורה כאשר השמירה מסתיימת, מי מפעיל אותה ואיך מוכיחים זאתמערכת ניהול מידע (ISMS) כמו ISMS.online עוזרת לך לשמור על עקביות ומוכחות בתשובות על פני מסדי נתונים, פלטפורמות יומן ומשטרי גיבוי.
כיצד אולפן משחקים יכול למפות את מחזור החיים של נתוני השחקן כך שתקן ISO 27001 A.8.10 יהיה הגיוני לכולם?
אתה ממפה את מחזור החיים כך שאנשים רואים את A.8.10 כ- תמונה משותפת של אופן זרימת נתוני השחקנים, לא כפסקה בתקן.
כיצד צריכה להיראות מפת מחזור חיים מעשית?
עבור כותר דגל אחד, מפת מחזור חיים שבאמת עוזרת לאנשים עשויה:
- התחל במקום שבו מופיעים הנתונים: יצירת חשבון, כניסה, רכישות, אירועי משחק, צ'אט, בדיקות נגד צ'יטים, אנשי קשר לתמיכה, נקודות כניסה לשיווק.
- הציגו לאן הנתונים יגיעו בהמשך: שירות חשבונות, שידוכים, אמצעי אנטי-רמאות, אוספי טלמטריה, מחסן נתונים, פלטפורמות יומן, ניהול קשרי לקוחות וכלי עבודה קהילתיים.
- להפריד מערכות פעילות, אחסון חם, ארכיון ו מחיקה/אנונימיזציה שלבים.
- סמנו את האירועים שמפעילים את שעוני השמירה (פעילות אחרונה, סוף מנוי, סוף חלון חיוב חוזר) ואת ה תהליכים או משימות שפועלים כאשר מגיעים לנקודות אלה.
- כלול צללים פחות ברורים: סביבות בימוי (staging) המאוכלסות מייצור, ארגזי חול של מדעי הנתונים, ייצוא CSV ועותקים מקומיים של מפתחים.
ברגע שהתצוגה הזו קיימת עבור משחק אחד, ניתן לתקנן את הדפוס ולהתאים אותו למשחקים אחרים במקום לעצב שמירה מאפס בכל פעם. מערכות או ספקים חדשים צריכים להצהיר על כך. היכן הם נמצאים במחזור החיים וכיצד הם מכבדים את אותם מעברים.
איך זה מתחבר חזרה ל-A.8.10 ול-ISMS שלך?
בעזרת ארטיפקט מחזור החיים שאליו מתייחסים במערכת ה-ISMS שלך, תוכל:
- קישור A.8.10 ישירות אל נקודות מעבר בעלות שם: היכן הנתונים עוזבים את השימוש הפעיל, מתי מתחילים טיימרים, והיכן חלות מחיקה או אנונימיזציה.
- הקצו אחריות בכל נקודה כך שיהיה ברור מי מגדיר את שימור הצוות, מי מנהל את המשימות ומי בודק את הראיות.
- שימוש חוזר במפה ב ביקורות עיצוב, אישורי שינויים והערכות ספקים, כך שצוותי אבטחה, פרטיות והנדסה טוענים על סמך אותה תרשים במקום על סמך הנחות מתחרות.
שמירת המפה הזו, הכללים התומכים בה והנהלים הקשורים ב-ISMS.online משמעותה שחשיבה על מחזור החיים הופכת לחלק מהממשל הרגיל שלכם. סקירות ניהוליות וביקורות פנימיות יכולות לשאול "היכן היו הנתונים האלה במחזור החיים שלהם?" לאחר אירועים, וזו בדיוק הדרך שבה A.8.10 מתחיל להרגיש כחלק מעיצוב משחקים טוב ולא סתם תיבת סימון.
מי צריך להיות אחראי על החלטות שמירה ומחיקה בעסקי משחקים חיים, וכיצד נוכל למנוע התפשטות חריגים?
שמירה ומחיקה הופכות לאמינות כאשר הן בעלות ברורה, לולאת החלטות פשוטה ומעקב גלוי אחר חריגים.
איך מחלקים תפקידים בלי ליצור בירוקרטיה?
בפועל, רוב אולפני ההופעות מסתפקים בחלוקה קלה בסגנון RACI:
- פונקציית אבטחה או CISO היא אחראי לעמידה ב-A.8.10 בין כותרים ושירותים משותפים.
- תפקיד פרטיות או משפטי הוא אחראי כדי להבטיח ששמירה ומחיקה תואמות את החוק, חובות הפלטפורמה ומה שאתם אומרים לשחקנים.
- צוותי הנדסת נתונים ופלטפורמות הם אחראי ליישום ותפעול של דפוסי מחיקה ואנונימיזציה בקוד, תשתית וצנרת נתונים.
- LiveOps, מוצר ואנליטיקה הם התייעץ כך שחלונות שימור לא יפגעו בשקט בבקרות הונאות, בתכנון הניסוי או בחוויית השחקן.
- צוותי תמיכה וקהילה הם אחראי לטיפול בבקשות שחקנים, ניהול ציפיות וסימן מקרים חריגים שעשויים להוביל להארכות זמניות.
כדי למנוע מחריגים לשחוק באיטיות את המודל שלך, אתה מוסיף לולאת ממשל קלה במקום ועדה חדשה:
- כל שמירה ממושכת לצורך חקירות, מקרי הונאה או מסיבות בטיחותיות נרשמת עם סיבה, בעלים ותאריך סקירה.
- רשומות אלו נבדקות באותו קצב כמו נושאי הסיכון והתאימות האחרים שלך - לדוגמה, בסקירות ניהול ISMS רבעוניות.
- קבוצה קטנה של מדדים A.8.10 – כגון השלמת בקשות מחיקה בזמן, מספר של חריגים באיחור, ו מערכות עדיין חסרות כללים מוגדרים – מופיע בדיווחים הרגילים.
כאשר מנהלים זאת בפלטפורמת ISMS כמו ISMS.online, אותם זרימות עבודה המטפלות באירועים, שינויים וסיכונים יכולים לשאת החלטות בנוגע לשמירה ומחיקה. זה שומר על הביצועים בפועל עם נתוני השחקנים בקו אחד עם מה שאתם אומרים לשחקנים, לשותפים ולרגולטורים, גם כאשר האולפן נמצא במצב השקה או כיבוי אש.
כיצד שירותי ענן וספקים משנים את הגישה שלנו ל-A.8.10, ומה עלינו לשלב בחוזים ובתצורות?
שינוי בשירותי ענן ו-SaaS איפה ואיך נתוני השחקנים מאוחסנים ונמחקים, אך הם אינם משנים את המציאות שבה הסטודיו שלך עדיין אחראי כדי להחליט מה נשמר, לכמה זמן ומתי יש להסירו או להפוך אותו לאנונימי.
מה עלינו ללכוד עבור כל שירות שנוגע בנתוני שחקנים?
עבור כל ספק המחזיק בזיהוי שחקנים או נתוני התנהגות, רשומות ה-ISMS שלך צריכות לפרט:
- איזה קטגוריות נתוני שחקנים הוא מאחסן (מזהים, פרטי קשר, אסימוני תשלום, יומני צ'אט, טלמטריה, רשומות תמיכה) ועבור אילו כותרים, אזורים או פלטפורמות.
- איזה אפשרויות שמירה ומחיקה באפשרותך לשלוט ב: מחווני שמירת יומנים, כללי מחזור חיים של אחסון אובייקטים, כלי מחיקה מובנים, התנהגות סגירת חשבון.
- כיצד מחיקה מופעלת בפועל – על ידי תצורה, תהליכים מתוזמנים, קריאות API או כרטיסי תמיכה – ומה המשמעות של זה עבור גיבויים, עותקים עותקים וצמצום אנליטיקה.
- מה עדות ניתן לאסוף ולשמור: ייצוא תצורה, יומני ביקורת, דוחות SOC 2 או ISO 27001, הצהרות ספקים על טיפול בגיבויים וחיטוי מדיה בסוף חוזה.
פרטים אלה מעצבים שני חפצים מרכזיים:
- הפנימי שלך מטריצת מחזור חיים ושימור, שבו מופיעות חנויות של צד שלישי לצד מסדי נתונים פנימיים ופלטפורמות יומן.
- חוזים והסכמי עיבוד נתונים, אשר אמור לקבוע ציפיות לשימור מקסימלי, תמיכה במחיקה, טיפול בגיבוי והתנהגות בעת סיום או הגירה.
הערכות סיכונים של ספקים צריכות להתייחס למחיקה ושמירה כשאלות באותה רמה כמו הצפנה ובקרת גישה. אם ספק אינו יכול לעמוד במחזור החיים שהגדרתם עבור נתוני השחקנים שלכם, זוהי החלטה מודעת לסיכון עבור לידים של אבטחה ופרטיות, ולא לפשרה מקרית תחת לחץ שחרור.
כאשר אתם מנהלים את הציפיות, התצורות והראיות הללו בתוך ISMS.online, אתם שומרים על רמת A.8.10 עקבית גם כאשר תמהיל הספקים שלכם מתפתח. אתם יכולים להראות אילו שירותים מחזיקים באילו קטגוריות של נתוני שחקנים, כמה זמן הם שומרים אותם, כיצד אתם מפעילים מחיקה או אנונימיזציה, והיכן אתם מאחסנים הוכחות שזה קורה - בדיוק הבהירות שפלטפורמות, רגולטורים ושחקנים מחפשים כשהם מחליטים אם לסמוך על אולפן משחקים לטווח ארוך.
