כשהמשחק שלך עוזב את הבניין: משטח הסיכון החדש של מיקור חוץ
פיתוח חיצוני עבור ISO 27001 A.8.30 מטופל כאילו מתרחש בתוך הסטודיו שלכם, תחת הכללים והאחריות שלכם. כל צוות חיצוני שנוגע בקוד, בבניות או בכלים מרחיב את משטח ההתקפה שלכם, ואתם נשארים אחראים לאופן שבו הם מגנים על הקניין הרוחני, התשתית ואמון השחקנים שלכם. ראיית צוותים חיצוניים כחלק מהסביבה שלכם, ולא "במקום אחר", היא נקודת המוצא לבקרות שעובדות בהפקה אמיתית. מידע זה הוא כללי ואינו מהווה ייעוץ משפטי או ייעוץ הסמכה.
מיקור חוץ בריא מתחיל כשאתם מניחים שהשותפים חולקים את הסיכונים שלכם, לא רק את עומס העבודה שלכם.
בפיתוח משחקים מודרני, שותפים לשיתוף פעולה, בתי עיצוב, צוותי פורטציה ופרילנסרים כמעט ולא עובדים על קבצים מבודדים. הם בדרך כלל מתחברים למאגרי Git או Perforce משותפים, מערכות בנייה, אחסון ענן לאמנות ואודיו, לוחות מחוונים של טלמטריה ומעקבי בעיות פנימיים. סיסמה חלשה אצל ספק, מחשב נייד לא מנוהל או לקוח VPN מיושן יכולים כעת להספיק כדי לדלוף תוכן של עונה שלמה או לתת לתוקפים נתיב לתוך השרת האחורי שלך.
ההבחנה המעשית בין עבודה "פנימית" לעבודה "חיצונית" היטשטשה. צוותים חיצוניים יושבים לעתים קרובות באותם ערוצי צ'אט, משתמשים באותם תורי כרטיסים ולפעמים אפילו חולקים דייני SSO עבור כלים. אם לא תתכננו במכוון בקרות למציאות זו, מערכות ה-ISMS שלכם ייבנות סביב מודל אולפן שכבר אינו קיים, ויותירו פערים שבסופו של דבר שחקנים, מוציאים לאור ומבקרים יבחינו בהם.
מדוע מיקור חוץ משנה את משטח ההתקפה שלך
מיקור חוץ משנה את משטח ההתקפה שלך מכיוון שהוא מכפיל את מספר הנתיבים אל תוך הקוד, התוכן ומערכות התפעול הלייב-אפס שלך. אתה עדיין אחראי לסיכון בכל אחד מהנתיבים הללו, ללא קשר למקום שבו נמצאים האנשים או החומרה.
פיתוח במיקור חוץ פירושו שהגישה למשחק שלכם אינה מוגבלת עוד לרשתות, למכשירים ולצוות שלכם. אמנים חיצוניים שמושכים טקסטורות, צוותי פיתוח משותפים שמעבירים קוד, ספקי אבטחת איכות שבודקים בניות מוקדמות ושותפי לייב-אפס שמפעילים כלים - כל אלה יוצרים נתיבים חדשים אל ה-IP והתשתית שלכם. אם לא תשלטו בנתיבים אלה עם כללי גישה ברורים, בקרות טכניות ונקודות סקירה, אתם יורשים את כל נוהלי האבטחה שיש - או אין - של אותם שותפים.
באולפנים רבים, שותפים חיצוניים נוגעים כיום בצינורות בנייה, כלי טלמטריה ולוחות מחוונים פנימיים של ניהול, ולא רק בתיקיות נכסים. זה מעצים את ההשפעה של כשלים פשוטים. חשבון משותף שנשאר פעיל לאחר סיום חוזה, מחשב נייד אישי המשמש לבניית בדיקות או מאגר מועתק בשרת לא מנוהל - כל אלה יכולים להפוך לנקודות כניסה לתוקפים או למקורות דליפות שפוגעות בהכנסות, במוניטין ובקשרי הפלטפורמה.
צעדים ראשונים: הפיכת מפת מיקור החוץ הבלתי נראית לגלויה
כדי להפוך את A.8.30 למשמעותי, ראשית עליכם לקבל תמונה ברורה של מי בונה עבורכם מה ואיזו גישה הוא משתמש. מפת פיתוח פשוטה במיקור חוץ הופכת הנחות מעורפלות לעובדות קונקרטיות שתוכלו לנהל, לנטר ולהציג למבקרים כחלק ממערכת ה-ISMS שלכם.
הצעד המעשי הראשון שלכם הוא להפוך את טביעת הרגל שלכם בתחום מיקור החוץ לגלויה באופן שתוכלו לפעול לפיו. משמעות הדבר היא מעבר לרשימת ספקים בתחום הפיננסים ולבנות מפת מיקור חוץ שעונה על שאלות בולטות: מי מעצב, קודן, בודק או מפעיל כל דבר שקשור למשחקים שלכם, ומה בדיוק הם יכולים לראות או לשנות?
התחילו ברישום כל שותף המעורב בפיתוח: אולפני פיתוח משותף, ספקי אמנות ואודיו, צוותי פורטציה, ספקי אבטחת איכות, שותפי לייב-אפס, מומחי כלים וקבלני הרחבת צוות. עבור כל אחד מהם, רשמו את מה שהם יכולים לגשת אליו: מאגרים, סניפים, מחסנים, סביבות, מסדי נתונים, לוחות מחוונים או כלים ספציפיים. אתם מנסים להחליף את "אנחנו חושבים שהם רואים רק אמנות" כאשר השותף הזה יכול למשוך את שלושת המחסנים האלה ולהפעיל את שני לוחות המחוונים האלה.
לאחר מכן, סווגו כל קשר לפי השפעה. חנות אמנות קונספט קטנה שמקבלת רק הפניות לתמונות שטוחות אינה באותה קטגוריה כמו סטודיו לפיתוח משותף עם גישת כתיבה למערכות משחק ולוגיקת התאמה. בית אבטחת איכות שיכול להוריד בניינים כמעט סופיים טומן בחובו סיכונים שונים מסוכנות לוקליזציה שעובדת רק מגיליונות אלקטרוניים. חלוקה פשוטה זו של שכבות נותנת לכם בסיס להחלטה היכן ISO 27001 A.8.30 זקוק לראיות כבדות משקל והיכן מגע קל יותר מקובל.
לבסוף, חברו את המפה הזו לניהול הנוכחי שלכם. שאלו למי שייך כל קשר, מי מאשר גישה, מי בודק אותה ומי ישים לב אם אותו שותף נפגע מחר. לעתים קרובות התשובה הכנה היא שאין אדם אחד, וזה בדיוק הפער ש-A.8.30 נועד לסגור. כאן גם פלטפורמה מובנית כמו ISMS.online יכולה לעזור, על ידי מתן דרך עקבית לתעד בעלות, גישה והחלטות בפרויקטים שונים, כך שלא תסתמכו על זיכרון אישי או מסמכים מפוזרים.
הזמן הדגמהמה באמת דורש תקן ISO 27001 A.8.30 מאולפני משחקים
תקן ISO 27001 A.8.30 מצפה מכם להתייחס לפיתוח חיצוני כאילו הוא מתרחש בתוך הסטודיו שלכם, כאשר אותם כללי אבטחה ואחריות עדיין חלים על עבודה זו, ללא קשר למי שבונה בפועל את מערכות המשחק או התוכן. צוותים חיצוניים חייבים לעמוד בדרישות אבטחת המידע שלכם לפיתוח, ועליכם להיות מסוגלים להראות כיצד אתם מכוונים, מנטרים ובודקים את העבודה לאורך זמן; הסכמי סודיות לבדן אינם מספיקים, משום שאתם זקוקים להוכחה לשליטה אמיתית.
פרשנות פשוטה של A.8.30 עבור אולפני משחקים
במילים פשוטות, סעיף A.8.30 קובע שכאשר מבצעים מיקור חוץ של כל חלק מהפיתוח, עדיין יש לשלוט באופן שבו העבודה מתבצעת. יש לעמוד בדרישות אבטחת המידע שלכם ללא קשר למי שכותב את הקוד או יוצר את הנכסים.
עבור רוב האולפנים, "דרישות אבטחת מידע" כוללות לפחות סודיות של תוכן שלא פורסם וטכנולוגיה קניינית, שלמות הקוד והנכסים וזמינות של מערכות בנייה והפעלה חיה. בהתאם למה שהמשחק שלך מטפל בו, הן עשויות לכלול גם התחייבויות פרטיות לנתוני שחקנים ודרישות רגולטוריות סביב תשלומים או נתוני ילדים. סעיף A.8.30 מצפה שדרישות אלו יעצבו את אופן התכנון והניהול של פיתוח במיקור חוץ, ולא רק את האופן שבו הוא מתואר בשפה המשפטית.
חשוב לציין, שהבקרה אינה נועדה לאלץ כל ספק לאמץ את תקן ISO 27001 באופן כללי. מדובר בהבטחה שהחלקים בעבודתם הנוגעים למשחקים שלכם נעשים באופן שתואם את מערכות ה-ISMS שלכם. משמעות הדבר יכולה להיות מתן סט ברור של מה לעשות ומה לא לעשות, כללי גישה וכלים, תוך ציפייה לאולפני פיתוח משותף בוגרים יותר להפגין נהלים פנימיים חזקים יותר ואבטחה רשמית יותר.
כיצד A.8.30 מקשר לבקרות ספקים ופיתוח
מנקודת מבטו של מבקר, A.8.30 הוא חלק אחד ממערכת משולבת הכוללת ניהול ספקים ופיתוח מאובטח, ולא כלל עצמאי. פיתוח במיקור חוץ צריך לשבת בנוחות לצד בקרות כגון A.5.19-A.5.22, ניהול שינויים וקידוד מאובטח, במקום להתייחס אליו כאל מקרה מיוחד שחי רק במסמכים משפטיים.
בזמן הבחירה, עליך להיות מסוגל להראות כיצד אתה מעריך האם שותף מסוגל לעמוד בציפיות האבטחה שלך. בהסכמים, עליך להראות היכן ציפיות אלו כתובות כהתחייבויות. בעבודה היומיומית, עליך להראות כיצד גישה, סקירת קוד, בדיקות ופריסה מתנהגות באותו אופן עבור תורמים חיצוניים ופנימיים. בניטור, עליך להיות מסוגל להראות יומנים, סקירות ופעולות מתקנות הקשורות ספציפית לעבודה במיקור חוץ.
רואי חשבון בדרך כלל מצפים לארבעה סוגי ראיות עבור A.8.30: מסמכי ניהול, חוזים, בקרות תפעוליות ופעילויות אבטחה. הטבלה שלהלן מציגה מיפוי פשוט שתוכל להשתמש בו כרשימת תיוג לעיצוב עבור הסטודיו שלך.
תמונה מבוא של סוגי ראיות שרואה חשבון מחפש לעתים קרובות:
| אזור | חפצים אופייניים | מה זה מוכיח |
|---|---|---|
| ממשל | נוהל פיתוח חיצוני, הערכת סיכונים | יש לך גישה מובנית |
| חוזים | MSAs, SoWs, לוחות זמנים של אבטחה, סודיות | שותפים מחויבים לדרישות שלך |
| עבודה תפעולית | מטריצות גישה, כללי מאגר, יומני סקירת קוד, בדיקות | בקרות קיימות ונמצאות בשימוש בפועל |
| הבטחה | ביקורות, ממצאים, פעולות ומעקבים של ספקים | אתם עוקבים ומשתפרים עם הזמן |
אתם לא צריכים ליטוש מושלם ביום הראשון, אבל אתם כן צריכים סיפור קוהרנטי: כך אתם מחליטים מי יכול לבנות את המשחק שלכם, כך אתם דורשים ממנו, כך אתם משלבים ובודקים את עבודתם, וכך אתם יודעים שזה עדיין קורה. עם הזמן, סיפור זה הופך לחלק מרכזי באופן שבו אתם מסבירים את מערכות ה-ISMS שלכם למוציאים לאור, לשותפי פלטפורמה ולמבקרים, במיוחד אם אתם יכולים להציג זאת באופן עקבי בפלטפורמה כמו ISMS.online במקום על פני כוננים מפוזרים וערוצי צ'אט.
ISO 27001 בקלות
יתרון של 81% מהיום הראשון
עשינו את העבודה הקשה בשבילך, ונתנו לך התחלה של 81% מרגע הכניסה. כל שעליכם לעשות הוא להשלים את החסר.
מעסקאות אד-הוק למסגרת מיקור חוץ מבוקרת
מנקודת מבט של תקן ISO 27001 A.8.30, הקפיצה האמיתית היא המעבר מהחלטות מיקור חוץ חד פעמיות למסגרת מיקור חוץ עקבית, כך שכל פרויקט יעקוב אחר אותו עמוד שדרה של בדיקות ובקרות, ועדיין נותן ליצרנים ולמנהיגי טכנולוגיה מספיק חופש לעבוד בקצב הייצור ולעמוד ביעדים היצירתיים. כדי לעמוד בתקן A.8.30 מבלי לשתק את הייצור, אתם זקוקים למסגרת מיקור חוץ פשוטה וחוזרת שכל פרויקט יכול לעקוב אחריה, שתחליף רשימות בדיקה מאולתרות ומאמץ אישי הרואי במחזור חיים שמרגיש טבעי בשימוש יומיומי, כך שהאבטחה תהפוך לחלק שגרתי מאופן העבודה עם שותפים, ולא לחסימה בשלב מאוחר שמופיעה רגע לפני נעילת בנייה.
תכנון מחזור חיים של פיתוח במיקור חוץ שמתאים לייצור
A.8.30 נוחת בצורה הנקייה ביותר כאשר מחזור החיים של פיתוח במיקור חוץ משקף את שערי הייצור הקיימים שלך; הרעיון המרכזי הוא פשוט: לשלב בדיקות אבטחה וספקים באבני דרך שכבר נמצאים בשימוש, כך שצוותים לא ירגישו שהם עובדים בתהליך שני ומקביל שקיים רק עבור מבקרים. מחזור חיים מעשי של פיתוח במיקור חוץ עבור סטודיו משקף אפוא את האופן שבו אתם כבר מעבירים משחקים דרך אבני דרך וביקורות אור ירוק, תוך הוספת שערים רלוונטיים לאבטחה ברגעים שכבר קיימים במקום להמציא פגישות ומסמכים חדשים לשמם, והפיכת שערים אלה לגלויים כחלק ממערכת ה-ISMS שלכם.
ויזואלי: דיאגרמת מחזור חיים פשוטה המציגה קליטה דרך יציאה מהארון עבור שותפים במיקור חוץ.
מחזור חיים טיפוסי כולל שבעה שלבים:
שלב 1 – קליטה
החליטו האם אתם זקוקים לשותף חיצוני, מה הוא יספק ואיזו גישה הוא יידרש כדי לבצע את העבודה בבטחה.
שלב 2 – בדיקת נאותות
בדקו האם השותף המועמד יכול לעמוד בציפיות הבסיסיות שלכם בנוגע לאבטחה ופרטיות, באמצעות שאלונים פרופורציונליים, ובמידת הצורך, באמצעות אישורים קיימים.
שלב 3 – התקשרות
תרגמו את ציפיות האבטחה למונחים מחייבים, כולל התחייבויות ברורות, אחריות, דיווח על אירועים וכל זכות ביקורת או הערכה הנדרשת לכם.
שלב 4 – קליטה
הפכו הסכמים לגישה קונקרטית, כלים, הדרכה והכשרה ראשונית עבור השותף, עם אישורים ותיעוד שתוכלו להציג מאוחר יותר למבקרים.
שלב 5 – משלוח
תנו לשותף לבצע את העבודה באמצעות כלים, ענפים וסביבות מוסכמים תחת בקרות מוגדרות, כאשר סקירת קוד, בדיקות ופריסה מתנהגים כפי שהם מתנהגים עבור צוותים פנימיים.
שלב 6 – ניטור
סקור את הפעילות, הגישה והתוצרים באופן קבוע, תוך הסלמה של בעיות, רישום החלטות והטמעת ממצאים בתהליכי סקירת הספקים וניהול הסיכונים שלך.
שלב 7 – יציאה מהמשחק
הסרת גישה, אחזור או מחיקה מאובטחת של נתונים והשלמת משימות סגירה עם סיום העבודה, כולל עדכון מפת מיקור החוץ ומרשם הסיכונים של הספקים.
המפתח הוא לשלב את השלבים הללו בניהול הפרויקט הקיים שלכם. לדוגמה, ייתכן שתדרשו שאף שותף לא יצטרף לפני ששאלון בדיקת נאותות מינימלי ימולא ואושר, ושמשימות יציאה מהפרויקט יהיו חלק מרשימת הבדיקה לסגירת הפרויקט. זה מאפשר לכם להגדיל את השליטה מבלי להמציא ביורוקרטיה מקבילה או להאט את הייצור שלא לצורך.
שימוש ברמות ספקים ובכלים משותפים במקום תהליכים חד פעמיים
עבור ISO 27001, מידתיות חשובה: לא כל קשר במיקור חוץ מצדיק תהליך מורכב. חלוקה ברמות ספקים ותבניות משותפות מאפשרים לכם להרחיב את A.8.30 בצורה הגיונית בין שותפי פיתוח משותף, אבטחת איכות, אמנות וייעוץ, מבלי להמציא מחדש מסמכים עבור כל עסקה או לשרוף מוניטין עם ספקים בעלי סיכון נמוך.
לא כל קשר עם מיקור חוץ מצדיק את אותה עומק של בדיקה. שותף המוטמע בבסיס הקוד ובערמת ה-Live-Ops שלכם מצדיק בדיקות רבות יותר מאשר אולפן בוטיק המספק נכסי אודיו עצמאיים. חלוקה לרמות ספקים מאפשרת לכם ללכוד את הניואנסים הללו בצורה מובנית ולהסביר אותם בבירור למבקרים ולמוציאים לאור.
לכל הפחות, רוב האולפנים נהנים משלוש שכבות:
- רמה ראשונה: שותפים עם גישה מועדפת או עמוקה, כגון אולפני פיתוח משותף וספקי קצה אחורי או אנטי-צ'יט.
- רמה שתיים: שותפים עם גישה משמעותית אך מוגבלת, כגון בתי פורט או צוותי QA שרואים בניות פנימיות.
- רמה שלישית: שותפים בעלי תפקידי תוכן בלבד או ייעוץ וללא גישה ישירה לקוד או לסביבות פעילות.
עבור כל רמה, אתם מגדירים אילו שאלונים, סעיפי חוזים, קווי בסיס ביטחוניים ותדירות סקירה חלים. שותפים בסיכון גבוה רואים דרישות מחמירות יותר ואבטחה תכופה יותר, בעוד ששותפים בסיכון נמוך חווים מגע קל יותר אך עדיין עקבי.
כלים משותפים הופכים את זה למציאותי. במקום שכל יצרן יבנה גיליונות אלקטרוניים ושרשורי דוא"ל משלו, אתם מספקים חבילת התחלה סטנדרטית: תבנית להערכת סיכונים, נספח אבטחה, טופס בקשת גישה ורשימת תיוג פשוטה לקליטה ולסגירה. כאשר פרויקט יוצר קשר חדש עם ספק, הוא מתחיל מאותם דפוסים ומתאים את עצמו רק במקומות בהם הדבר מוצדק. עם הזמן, ככל שאתם לומדים מה עובד ומה מאט אתכם, אתם משכללים את התבניות - ולא חמישים וריאציות מפוזרות. פלטפורמה כמו ISMS.online יכולה לעזור לכם לשמור על תבניות והחלטות אלו תואמות בין כותרות.
איומים ספציפיים למשחק: דליפות, מנועי משחק, אנטי-צ'יטים ופעולות לייב-אופ
מנקודת מבט של תעשיית המשחקים, A.8.30 חייב לכסות איומים שהנחיות תאגידיות כלליות מתעלמות מהם לעתים קרובות. ספוילרים גדולים, רכיבים פנימיים של מנועי משחקים, מערכות נגד צ'יטים וכלים לניהול שידורי לייב יוצרים סיכונים שונים מאוד מיישום עסקי סטנדרטי, במיוחד כאשר אולפנים חיצוניים ממלאים תפקיד ישיר בבנייה ותפעול התוכן שלכם.
פיתוח משחקים מביא עמו דפוסי איום שהנחיות ISO הגנריות נוטות לטשטש: תוכן סיפורי עמוס בספוילר, מנועי הגנה קנייניים, לוגיקת אנטי-צ'יטים, כלכלות חיות ואירועים עונתיים. פיתוח במיקור חוץ נוגע לרבים מאלה ישירות. אם תתעלמו מהפרטים הספציפיים הללו, אתם מסתכנים בתכנון בקרות שהן מסודרות מבחינה פורמלית אך עיוורות לאופן שבו תוקפים, מדליפים ומפתחי צ'יטים אמיתיים מתנהגים.
מיפוי מאיפה הנזק האמיתי עלול לנבוע
כדי להתאים את עצמכם ל-A.8.30, עליכם להיות ברורים לגבי אילו נכסים ומערכות יפגעו בכם בפועל אם ידלפו או ייפגעו; ברגע ש"תכשיטי הכתר" הללו ידועים, תוכלו לעקוב אחר אילו שותפים חיצוניים נוגעים בהם ולהדק את הבקרות בהתאם במקום לנסות להגן על הכל באופן שווה. מידול איומים ספציפי למשחק מתחיל בשאלה מה יפגע בכם בפועל אם הוא ייחמק או יטופל: עבור משחק מונחה-עלילה, זה כנראה אומר עלילה, קולנוע ועיצוב מרכזי; עבור משחק מקוון תחרותי, סביר להניח שמדובר ברוטינות נגד רמאויות, לוגיקה בצד השרת ובקרות כלכליות; ועבור נכס ספורט או סרטים מורשה, ייתכן שמדובר בעיצובי דמויות ונכסי דמיון המכוסים על ידי התחייבויות שיווק ומשפטיות מחמירות.
קטגוריות נכסים אופייניות בעלות השפעה גבוהה כוללות:
- תוכן קומי כגון תסריטים, קטעי וידאו ועיצוב גרפי מרכזי לדמויות או מיקומים שלא הוכרזו.
- נכסים טכניים כמו מודולי מנוע, ווים נגד צ'יטים, לוגיקת שרת וצנרת בנייה או חתימה.
- נתונים רגישים מבחינה מסחרית, כולל פרמטרים כלכליים, אירועי קידום מכירות ועיצובים ברישיון של נכסים.
לאחר שתדעו אילו נכסים חשובים ביותר, עקבו אחר אילו שותפים חיצוניים רואים אותם אי פעם. האם אולפן הפיתוח המשותף שלכם קומפילציה של מודולי אנטי-צ'יט באופן מקומי? האם בית פורט מטפל בבניית קונסולות ולכן חותם על מפתחות? האם ספק לייב-אפס מנהל לוחות מחוונים שיכולים לשנות מחירים או תגמולים במשחק? האם צוות QA מוריד באופן קבוע בנייות קריטיות למשרדים ביתיים? כל "כן" הוא אות לכך שבקרות ה-A.8.30 שלכם חייבות לעשות יותר מאשר לקבוע באופן כללי "פיתוח מאובטח".
כדאי לשים לב גם לאזורים אפורים. ספוילרים שנראים מהנים עבור חלק מהשחקנים עשויים להיות רגישים מבחינה חוזית עבור נותני רישיונות או עלולים לפגוע בקצבי שיווק מתוזמנים בקפידה. באופן דומה, נתוני ניפוי באגים שנראים לא מזיקים למהנדסים עשויים להכיל מזהים או יומני רישום עם השלכות על פרטיות או סיכון להונאה. סיווג קטגוריות גבוליות אלו במפורש עוזר לכם להצדיק מדוע שותפים מסוימים מתמודדים עם בקרות מחמירות יותר מאחרים ועוזר לכם להסביר את ההיגיון הזה למבקרים ולמוציאים לאור.
טיפול מיוחד למנועים, מערכות אנטי-צ'יט ופעולות חיות
מנועי הפעלה, מערכות נגד רמאויות וכלים לביצועי פעולות חיים נמצאים בצומת שבין מורכבות טכנית לסיכון עסקי, ו-A.8.30 מספק בסיס איתן להתייחס לתחומים אלה כמקרים מיוחדים בכל פעם שהם נוגעים בהם על ידי צוותים חיצוניים, עם בקרות מחמירות יותר וראיות ברורות יותר מאשר עבור עבודה בעלת השפעה נמוכה יותר. שלושה תחומים טכניים ראויים במיוחד לטיפול זה בתרחישים של מיקור חוץ - מנועי הפעלה וטכנולוגיית ליבה, מערכות נגד רמאויות וכלים לביצועי פעולות חיים - משום שכל אחד מהם משלב מורכבות טכנית עמוקה עם השפעה גבוהה אם הוא פגום או נחשף, וכל אחד מהם הוא תחום שבו מו"לים ופלטפורמות שואלים כעת שאלות מפורטות.
מנועי טכנולוגיה וטכנולוגיית ליבה מייצגים לעתים קרובות שנים של השקעה ומהווים גורמים מבדילים מבחינת איכות ויזואלית, ביצועים או זרימות עבודה של כלים. מתן אפשרות לגישה לא מקוטעת, לא מפולחת, של סטודיו חיצוני לקוד המנוע עשוי להיות הכרחי בקשרים גדולים עם פיתוח משותף, אך זה לא צריך להיות ברירת המחדל עבור כל ספק. במידת האפשר, יש לבודד רכיבי מנוע לשימוש חוזר מלוגיקה ספציפית למשחק ולהגביל את מי שיכול לראות או לשנות את הראשונים, באמצעות מאגרים, ענפים וסביבות נפרדות.
מערכות אנטי-צ'יט רגישות במיוחד. החצנת פיתוח כאן יכולה להיות הגיונית עבור מומחיות מיוחדת, אך היא מגדילה את הסיכון שפרטי יישום ידלפו לקהילות פיתוח צ'יטים או שקוד זדוני יוכנס ללקוחות. אם אתם מערבים שותפים ברמה זו, פילוח קפדני של מאגרים, סקירת קוד חובה על ידי צוות פנימי מהימן וסביבות בנייה מבוקרות היטב הם חיוניים. עליכם גם להיות מסוגלים להראות לרואה חשבון אילו חשבונות נגעו אי פעם בקוד אנטי-צ'יט וכיצד נבדקו שינויים אלה.
כלי עבודה בשידור חי, החל מלוחות מחוונים של ניהול ועד בקרי כלכלה, הם מטרה נפוצה נוספת למיקור חוץ. חשבון יחיד שנפרץ כאן יכול לשבש אירועים, להזריק פריטים הונאה או לגנוב כסף. כל צוות חיצוני שבונה או מפעיל כלים אלה צריך להיחשב כחלק מעמוד השדרה התפעולי שלכם, עם אימות חזק, בקרות רשת, ניטור ונתיבי הסלמה ברורים לאירועים. A.8.30 מספק את ההצדקה להתעקש על רמת זהירות זו גם כאשר לחץ האספקה לטווח קצר גבוה, ורישומי סקירת הספקים שלכם יכולים להראות כיצד אתם שומרים על סטנדרט זה לאורך עונות ותארים.
שחררו את עצמכם מהר של גיליונות אלקטרוניים
הטמע, הרחב והרחיב את תאימותך, ללא כל בלגן. IO מעניק לך את החוסן והביטחון לצמוח בצורה מאובטחת.
עיצוב חוזים מאובטחים והסכמי רמת שירות (SLA) עם בתי פיתוח חיצוניים
מנקודת מבטו של רואה חשבון, חוזים והסכמי רמת שירות הם המקום שבו A.8.30 מפסיק להיות רעיון והופך לחובה ניתנת לאכיפה, ועבור הסטודיו שלכם, הם גם הדרך שבה אתם הופכים את "פיתוח חיצוני מאובטח" למוחשי עבור שותפים מבלי להאט כל משא ומתן עד כדי סחף או להפוך את תיבות הדואר הנכנס של היצרנים לצוואר בקבוק. חוזים והסכמי רמת שירות הם המקום שבו אתם הופכים את כוונות A.8.30 שלכם למשהו מדיד: אם הן נעשות בצורה גרועה, הן מסמכים צפופים שאף אחד לא קורא עד שמשהו משתבש; אם הן נעשות היטב, הן נותנות לשני הצדדים בהירות לגבי מה המשמעות של "פיתוח חיצוני מאובטח" בפועל ומקלות בהרבה על הדגמת תאימות לתקן ISO 27001 ועל מענה לשאלונים של מפרסמים בביטחון.
בניית מחסנית חוזים של אבטחה לפי עיצוב
חבילת חוזים מבוססת אבטחה מובנית משלבת חשיבה של אבטחת מידע בהסכם האב, בהסכמי סודיות, בהצהרות עבודה ובלוחות זמנים כבר מההתחלה. בדרך זו, כל פרויקט במיקור חוץ מתחיל עם בסיס עקבי שכבר משקף את ציפיות ISO 27001 ואת בקרות הספק.
חבילת חוזים חזקה לפיתוח במיקור חוץ כוללת בדרך כלל ארבע שכבות: הסכם שירותים ראשי, הסכם סודיות אחד או יותר, הצהרות עבודה ולוחות זמנים תומכים כגון הסכמי רמת שירות ונספחים לאבטחה. במקום להתייחס לאבטחה כתוספת, משלבים חשיבה על אבטחת מידע בכל שכבות אלו, כך שיצרנים לא ייאלצו להמציא מחדש מונחים תחת לחץ זמן.
הסכם השירותים הראשי מגדיר את מערכת היחסים הכוללת. עליו לקבוע ציפיות בסיסיות בנוגע לאבטחת מידע, סודיות, קניין רוחני, הגנת נתונים, דיווח על אירועים, זכויות ביקורת וקבלנות משנה. לאחר מכן, הסכמי סודיות מתמקדים במה שנחשב סודי - קוד מנוע, כלים, גרסאות גרפי שלא פורסמו, מסמכי עיצוב, דוגמאות טלמטריה - ולהבהיר כי השותף אינו יכול לעשות בהם שימוש חוזר או לחשוף אותם מחוץ להיקף המוסכם.
הצהרות עבודה מקשרות פרויקטים או כותרות ספציפיים להסכם האב. כאן אתם מתארים מה השותף יעשה, למה הוא צריך לגשת, אילו תוצרים הוא יפיק ואילו סביבות הוא ישתמש. לוחות זמנים של אבטחה והסכמי רמת שירות המצורפים לכל הצהרה מפרטים התחייבויות קונקרטיות יותר: שימוש באימות רב-גורמי, הגבלות על עבודה מהבית, סטנדרטים מינימליים לתיקון פרויקטים, יעדי זמן פעולה עבור כלים מתארחים ולוחות זמנים לדיווח ותיקון פגיעויות.
כאשר אלמנטים אלה עוברים סטנדרטיזציה, יצרנים וצוותים משפטיים אינם צריכים לגלות מחדש תנאי אבטחה מאפס. הם עובדים מתבניות מאומתות שכבר משקפות את A.8.30 ואת בקרות הספק, ומתאימים אותן רק במקרים בהם התקשרות מסוימת שונה באמת. מערכת כמו ISMS.online יכולה לעזור לכם לקשר את התנאים הללו ישירות לבקרות ולסיכונים ב-ISMS שלכם, כך שחוזים יהפכו לחפצים חיים ולא לקבצים סטטיים.
הפיכת ציפיות אבטחה לחובות מדידות
A.8.30 מעודד אותך להפוך ציפיות אבטחה ברמה גבוהה לחובות שניתן למדוד, לבדוק ולשפר. דרישות ברורות וניתנות לבדיקה גם מקלות על התאמת מסמכים משפטיים לבקרות התפעוליות שאתה מפעיל במאגרים ובסביבות, כך שעורכי הדין והמהנדסים שלך מדברים למעשה על אותם דברים.
עבור סעיף A.8.30, לא מספיק לציין "הספק ישמור על אבטחת הדברים". אתם זקוקים לדרישות שניתן לבדוק בעבודה היומיומית ובזמן הביקורת. כאן התחייבויות ברורות ומדידות בחוזים ובהסכמי רמת שירות עושות הבדל מעשי הן עבור הסטודיו שלכם והן עבור השותפים שלכם.
לדוגמה, התחייבויות בקרת גישה יכולות לקבוע שכל צוות הספקים עם גישה למאגרים ולסביבות שלך חייב להשתמש בחשבונות בעלי שם, אימות רב-גורמי ומכשירים מאושרים. התחייבויות פיתוח מאובטח יכולות לדרוש עמידה בהנחיות הקידוד שלך, סקירת קוד חובה והשתתפות בפעילויות בדיקות אבטחה ספציפיות. התחייבויות אירועים עשויות לציין זמנים מקסימליים להודיע לך על חשדות להפרות, את הפורמט של דוחות ראשוניים וציפיות לשיתוף פעולה בחקירות.
בצד התפעולי, אם ספק מארח עבורכם תשתית בנייה או כלי עבודה חיים, הסכמי רמת שירות צריכים לכלול יעדי זמינות, יעדי זמן התאוששות ונקודת התאוששות, חלונות תחזוקה והתחייבויות לשמירת נתונים. נספחים להגנה על נתונים צריכים להבהיר האם הספק הוא מעבד או מעבד משנה עבור נתונים אישיים כלשהם ואילו אמצעי הגנה על הפרטיות חלים, במיוחד כאשר אתם מטפלים בתשלומים או בנתוני ילדים.
כאשר תצטרכו מאוחר יותר להראות לרואה חשבון כיצד יישמתם את A.8.30, היכולת להצביע על סעיפים ספציפיים בחוזים והסכמי רמת שירות הופכת את החיים להרבה יותר קלים מאשר להסתמך על הצהרות כוונות כלליות. קישור התחייבויות אלו לבקרות, סיכונים ופריטי ראיות ב-ISMS.online מראה שאלו לא רק מילים על נייר, אלא חלקים מנוהלים באופן פעיל של ה-ISMS שלכם.
בקרות טכניות: מאגרים, סביבות ו-CI/CD לפיתוח במיקור חוץ
מנקודת מבט של עיצוב בקרה, A.8.30 הוא הקל ביותר להוכחה כאשר בקרת המקור, הסביבות והצנרת אוכפים את אותם הכללים עבור מפתחים פנימיים וחיצוניים. בקרות טכניות מתוכננות היטב מראות שהתנהגויות מאובטחות הן ברירת המחדל, לא משהו שאתם סומכים עליו שאנשים יזכרו תחת לחץ או בזמן משבר.
חוזים מתארים מה אמור לקרות; בקרות טכניות עוזרות להבטיח שזה אכן יקרה. עבור פיתוח במיקור חוץ, רוב הבקרות הללו נמצאות בשלושה מקומות: מערכות בקרת מקור, סביבות וצנרת בנייה ופריסה. אם עושים זאת נכון, חלק ניכר מהכוונה של A.8.30 נאכף באופן אוטומטי וניתן להדגים זאת באמצעות תצורה ויומני רישום.
ויזואלי: דיאגרמת צינור CI/CD המציגה בדיקות, סקירות ושערי פריסה עבור תרומות שותפים.
עיצוב גישה וסביבות עבור צוותים חיצוניים
ראיות טובות לתקן A.8.30 מתחילות לעתים קרובות במודלי גישה ברורים ובהפרדת סביבות עבור תורמים חיצוניים, משום שאם ניתן להראות שלשותפים יש תפקידים מוגדרים, חלונות גישה מוגבלים ויציאה נקייה מהמערכת, קומת הפיתוח החיצוני שלכם הופכת משכנעת הרבה יותר עבור מבקרים ושותפי פלטפורמה. העיקרון הראשון מאחורי מודלים אלה הוא מינימום הרשאות: אל תתנו למפתחים חיצוניים גישה רבה יותר ממה שהם באמת צריכים, ולא יותר ממה שהם באמת צריכים אותה, מה שבפועל מתחיל בבקרת גישה מבוססת תפקידים בפלטפורמות המאגר והכלים שלכם, שבהן מגדירים תפקידים עבור מתכנתי משחקים חיצוניים, מהנדסי כלים, אמנים, בודקי QA או מהנדסי בנייה, כל אחד קשור לקבוצה מוגדרת של מאגרי מידע, סניפים, פרויקטים ותורי בעיות.
העיקרון הראשון הוא מינימום הרשאות: אל תתנו למפתחים חיצוניים גישה רבה יותר ממה שהם באמת צריכים, ולא למשך זמן ארוך יותר ממה שהם באמת צריכים. בפועל, זה מתחיל בבקרת גישה מבוססת תפקידים במאגר ובפלטפורמות הכלים שלכם. אתם מגדירים תפקידים עבור מתכנתי משחקים חיצוניים, מהנדסי כלים, אמנים, בודקי QA או מהנדסי בנייה, כל אחד קשור לקבוצה מוגדרת של מאגרי נתונים, ענפים, פרויקטים ותורי בעיות.
משם, אתם מעצבים את המאגרים והסביבות שלכם כך שיכבדו את התפקידים הללו. רכיבים רגישים כמו מודולים נגד רמאויות, מפתחות חתימה או שכבות אינטגרציה של פלטפורמה צריכים להיות ממוקמים באזורים מוגבלים יותר, עם גישה מוגבלת לקבוצות פנימיות קטנות ומהימנות. אזורי לוגיקת משחק או תוכן משותפים יכולים להיחשף באופן רחב יותר לשותפים. כללי הגנה על ענפים יכולים למנוע דחיפות ישירות לענפים ראשיים או ענפים מהדורה, מה שמחייב בקשות מיזוג, סקירת קוד ובדיקות אוטומטיות מוצלחות במקום זאת.
הפרדת סביבות חשובה לא פחות. שותפים חיצוניים צריכים לעבוד בדרך כלל בסביבות פיתוח או בדיקה ייעודיות, ולא בייצור. פילוח רשת, אישורים נפרדים וסודות נפרדים מפחיתים את הסיכוי שפגיעה באזור אחד תגלוש לאחרים. עבור נכסים או כלים המתארחים בענן, ניתן להשתמש בחשבונות או בקבוצות משאבים נפרדות לעבודת שותפים, עם תפקידים מוגדרים בקפידה ורישום כדי להראות כיצד אזורים אלה משמשים.
חשוב לציין, שבונים תהליכים של מצטרף-עובר-עוזר סביב בקרות אלו. כאשר מישהו אצל ספק מצטרף או עוזב פרויקט, צריך להיות נתיב ברור למתן והסרה של גישה, עם אישורים ורישומים. בלי זה, אפילו התכנון הטכני הטוב ביותר יצבור חשבונות מיושנים ומסוכנים שקשה להסביר במהלך ביקורת.
שימוש ב-CI/CD ואוטומציה לאכיפת A.8.30 בפועל
צינורות CI/CD הם בעלי ברית חזקים עבור A.8.30 מכיוון שהם יכולים להחיל את אותן בדיקות על כל שינוי, ללא קשר למי שכתב אותו, וכאשר צינורות אלה אוכפים כללי בדיקה, סקירה וחתימה, ניתן להוכיח שקוד, נכסים ותצורה במיקור חוץ עוקבים אחר אותו נתיב איכות ואבטחה כמו עבודה פנימית. צינורות מודרניים יעילים דווקא משום שלא אכפת להם מאיפה הגיע commit; אכפת להם רק אם הוא עובר את השערים שקבעתם, כך שכל תרומה שמגיעה ל-builds שלכם עברה בדיקות איכות ואבטחה עקביות התואמות ל-ISMS שלכם.
צינורות מודרניים הם חזקים משום שלא אכפת להם מאיפה הגיע ה-commit; אכפת להם רק אם הוא עובר את השערים שקבעתם. המטרה היא שכל תרומה שמגיעה ל-builds שלכם תעבור בדיקות איכות ואבטחה עקביות, בהתאם ל-ISMS שלכם.
אמצעים אופייניים כוללים דרישה שכל השינויים משותפים יגיעו באמצעות בקשות משיכה או מיזוג, לעולם לא באמצעות בקשות דחיפה ישירות. בקשות אלו חייבות להיבדק ולאושר על ידי מישהו בעל הסמכות המתאימה - לעתים קרובות מתחזק פנימי של רכיבים קריטיים. לאחר מכן, בדיקות אוטומטיות מופעלות על כל בקשה: בדיקות יחידה, בדיקות אינטגרציה, ניתוח סטטי, סריקות פגיעויות תלויות, בודקי סגנון וכל בדיקות אבטחה מותאמות אישית שאתם מסתמכים עליהן עבור המשחק שלכם.
עבור מערכות גיבוי (builds), ניתן לדרוש שרק תשתית ה-CI הנשלטת שלכם תייצר ארטיפקטים שעוברים לבדיקה או לייצור, כאשר מערכות גיבוי חתומות וניתנות למעקב אחר בקשות גיבוי ובקשות מיזוג ספציפיות. שותפים עשויים להריץ מערכות גיבוי משלהם לבדיקה מקומית, אך רק גרסאות הצינור שלכם מייצרות גרסאות המופצות באופן נרחב יותר לשחקנים, מפרסמים או בעלי פלטפורמות.
ניהול סודות וגישה בזמן אמת משלימים זאת. במקום לאפות סודות בקבצי תצורה ששותפים יכולים לראות, אתם מאחסנים אותם בכספת מרכזית ומכניסים אותם לצינורות או לסביבות שלכם בזמן ריצה. עבור משימות שבהן שותפים באמת זקוקים לגישה ישירה למערכות רגישות, אתם יכולים לספק אישורים מוגבלים בזמן או גישה מבוססת אישור במקום גישה קבועה בלתי מוגבלת.
כאשר מבצעים אותם היטב, הם עומדים בכמה ציפיות של תקן ISO 27001 בו זמנית: פיתוח מאובטח, שינויים מבוקרים, עקיבות ועקביות בין עבודה פנימית וחיצונית. הם גם הופכים את שיתוף הפעולה לחלק יותר, משום שמפתחים - בכל מקום בו הם יושבים - עובדים עם מודלים ברורים של הסתעפות, סוקרים כללים ומקבלים משוב מכלים אוטומטיים. זה בתורו מפחית חיכוכים כאשר מאוחר יותר תצטרכו להוכיח תאימות לרואה חשבון או לענות על שאלות בדיקת נאותות טכנית של מפרסם.
ניהול כל דרישות התאימות, הכל במקום אחד
ISMS.online תומך ביותר מ-100 תקנים ותקנות, ומעניק לך פלטפורמה אחת לכל צרכי התאימות שלך.
אבטחה מתמשכת: ניטור שותפים מול A.8.30 ו-A.5.19-A.5.22
ISO 27001 מניח שסיכון הספק משתנה עם הזמן, ו-A.8.30 אינו יוצא מן הכלל. אבטחה מתמשכת מראה שאתם עושים יותר מכתיבת חוזים חזקים - אתם למעשה צופים כיצד פיתוח במיקור חוץ מתנהג ומתאימים את עצמכם כאשר המציאות סוטה מהתוכניות, במקום לחכות לאירוע הגדול הבא או למחזור ההסמכה.
אפילו חוזים ובקרות חזקים הם רק תמונת מצב של כוונה. סעיף A.8.30 ובקרות הספקים מניחים שקשרים וסיכונים מתפתחים עם הזמן. אבטחה מתמשכת היא השכבה ששומרת על הבנתכם מעודכנת ומראה שאתם שמים לב בין ביקורות, לא רק בתחילת חוזה או כאשר מפרסם שואל שאלות מביכות.
הגדרת קצב סקירה וניטור בגודל הנכון
ביקורות בגודל הנכון משלבות בדיקות תקופתיות עם טלמטריה מתמשכת כדי שתוכלו לראות האם השותפים עדיין עומדים בציפיות שלכם; A.5.19-A.5.22 מספקים את המסגרת, ורמות הספק שלכם עוזרות לכם לבחור את העומק והתדירות הנכונים עבור כל שותף, כך שלא תעמיסו על יצרנים או צוותי אבטחה בניירת מיותרת. אבטחה מתמשכת מתחילה בהחלטה באיזו תדירות לבדוק שוב כל שותף ומה לבדוק, כאשר שותפים בסיכון גבוה - כאלה עם קוד עמוק וגישה לפעילות חיה - אולי מצדיקים ביקורות שנתיות או אפילו תכופות יותר, ושותפים בסיכון נמוך הזקוקים לבדיקה קלה בלבד כל כמה שנים, אלא אם כן משהו משמעותי משתנה בסביבה שלהם או במשחקים שלכם.
סקירה משלבת בדרך כלל מספר אלמנטים. ייתכן שתשלחו שאלון אבטחה מובנה כדי לאשר שמדיניות מרכזית, בקרות טכניות והסמכות עדיין קיימות. ייתכן שתבקשו ראיות כגון צילומי מסך של תצורות, סיכומים של מבחני חדירה אחרונים או דוחות על פגיעויות שתטופלו. עבור חלק מהשותפים, ייתכן שתפעילו או תזמינו הערכות משלכם. עבור אחרים, אתם מסתמכים יותר על אישורים ואותות תפעוליים.
לצד נקודות ביקורת פורמליות אלו, הטלמטריה התפעולית שלכם צריכה להזין את התמונה. רישום מרכזי של פעילות מאגרים, צינורות בנייה ופריסה, גישה לסביבה ופעולות ניהוליות מאפשר לכם לראות כיצד חשבונות שותפים מתנהגים בפועל. דפוסים חריגים - כגון פרצי גישה גדולים ממיקומים בלתי צפויים, פריסות מחוץ לשעות הפעילות או כניסות כושלות תכופות - יכולים לעורר שיחות ממוקדות או בדיקות מעמיקות יותר.
כאשר סקירות או ניטור מגלים בעיות, אתם רושמים אותן במרשם סיכונים של ספקים, יחד עם החלטות ופעולות. מרשם זה הוא מה שתציגו מאוחר יותר למבקר כדי להדגים שסיכוני הספקים, כולל פיתוח במיקור חוץ, מזוהים, עוקבים ומטופלים - ולא רק צוינים פעם אחת ונשכחים. כלים כמו ISMS.online יכולים לעזור לכם לשמור על מרשם זה מעודכן ולקשר כל סיכון לבקרות וראיות.
שילוב שותפים במעגל השיפור שלכם
A.8.30 עובד בצורה הטובה ביותר כאשר שותפים רואים באבטחה אחריות משותפת, לא מטלת ביקורת, ובניית לולאת שיפור עם ספקים מרכזיים מחזקת את שרשרת האספקה שלכם ומספקת לכם סיפורים אמינים על התקדמות משותפת כאשר מבקרים, מוציאים לאור או בעלי פלטפורמות מתחילים לשאול שאלות קשות לגבי אופן ניהול העבודה במיקור חוץ. אבטחה מתמשכת יעילה ביותר כאשר זה לא רק משהו שאתם עושים לשותפים אלא משהו שאתם עושים איתם, הכולל תקשורת ברורה, ציפיות פרופורציונליות ונכונות לחלוק לקחים בשני הכיוונים.
עבור שותפים חשובים, יכול להיות מועיל לקיים מפגשים משותפים תקופתיים שבהם תסקרו אירועי אבטחה, כמעט-הפסדים או ממצאים בפעילות המשולבת שלכם. אין צורך להטיל ספק בכך; המטרה היא לזהות דפוסים ולהסכים על שיפורים מעשיים. לדוגמה, ייתכן שתשימו לב שכמה שותפים מתקשים בעקביות התיקונים במכונות בנייה, או שהודעות על אירועי תקרית נוטות להגיע מאוחר מדי באזור הזמן שלכם כדי לפעול במהירות.
הכשרה ממוקדת יכולה לתמוך בכך. הדרכה קצרה וממוקדת בנושאים כמו שימוש מאובטח במאגרים שלכם, טיפול בנתוני ניפוי שגיאות או בדיקות מרחוק בטוחות יכולות להעלות את קו הבסיס מבלי לדרוש תוכניות מודעות בקנה מידה מלא. כאשר מערכת ה-ISMS שלכם מתפתחת - נניח שאתם מאמצים מדיניות סיסמאות חדשה או תקן קידוד מאובטח - אתם יכולים לתת לשותפים סיכומים פשוטים ובר-ביצוע במקום לצפות מהם לפענח מסמכים פנימיים.
עם הזמן, שיתוף פעולה מסוג זה משפר לא רק את המצב שלכם, אלא גם את זה של שרשרת האספקה שלכם. עבור ISO 27001, הוא נותן לכם נרטיב אמין ש-A.8.30 אינו משימת תאימות חד פעמית, אלא חלק מהאופן שבו אתם מנהלים את מערכת הפיתוח שלכם. עבור המשחקים שלכם, הוא מפחית את הסיכויים שהחוליה החלשה ביותר בשרשרת תהיה זו החשובה ביותר כאשר עונה חדשה תושק או קידום משמעותי של פלטפורמה יעלה לאוויר.
הזמן הדגמה עם ISMS.online עוד היום
ISMS.online עוזרת לכם להפוך פיתוח במיקור חוץ ממסמכים ותיבות דואר נכנס מפוזרים למערכת אחת ניתנת לביקורת שהסטודיו שלכם יכול לסמוך עליה, מה שמקל על יישום ISO 27001 A.8.30 באופן עקבי על פני כל שותף לפיתוח משותף, אבטחת איכות, אמנות ופעילות חיה, במקום לקוות שמפיקים בודדים יזכרו כל שלב בעצמם כאשר דד-ליינים צפופים. גישה מובנית לפיתוח במיקור חוץ קלה הרבה יותר לשמירה כאשר היא נמצאת במערכת שנבנתה עבור ISO 27001, ולא בסבך של מסמכים וגיליונות אלקטרוניים, מכיוון שמקום מרכזי להגדרת מסגרת הפיתוח במיקור חוץ, מיפוי סיכונים ובקרות ל-A.8.30 ולבקרות הספק, וצירוף ראיות אמיתיות לכל קשר הופך את המעקב אחר מי עושה מה עבור המשחקים שלכם, תחת אילו כללים ועם אילו בדיקות לפשוט הרבה יותר.
גישה מובנית לפיתוח במיקור חוץ קלה הרבה יותר לשמירה כאשר היא מתקיימת במערכת שנבנתה עבור ISO 27001, ולא בסבך של מסמכים וגיליונות אלקטרוניים. ISMS.online מספק לכם מקום מרכזי להגדיר את מסגרת הפיתוח במיקור חוץ שלכם, למפות סיכונים ובקרות לתקן A.8.30 ולבקרות הספק, ולצרף ראיות אמיתיות לכל קשר. זה הופך את המעקב אחר מי עושה מה עבור המשחקים שלכם, תחת אילו כללים ועם אילו בדיקות לפשוט הרבה יותר.
כאשר משתמשים ב-ISMS.online, צוותי ייצור, טכנולוגיה ותאימות עובדים מאותו מקור אמת. משימות קליטה של ספקים, שאלוני בדיקת נאותות, הפניות חוזים, תזכורות לבדיקת גישה ומחזורי בדיקת ספקים הופכות לזרימות עבודה סטנדרטיות במקום פרויקטים אד-הוק. זה עוזר לדרישות ISO 27001 להשתלב בניהול פרויקטים יומיומי, במקום להרגיש כמו מסלול תאימות נפרד שאף אחד לא צריך זמן אליו.
פיילוט ממוקד הוא לעתים קרובות צעד מעשי הבא. בחרו שותף אחד או שניים בסיכון גבוה או כותר דגל והשתמשו ב-ISMS.online כדי למדל את מחזור החיים המלא של פיתוח מיקור חוץ עבור נתח זה של תיק העבודות שלכם. כשאתם בונים הערכות סיכונים, מיפוי חוזים, רישומי בקרת גישה ויומני סקירה, אתם מרכיבים במהירות חבילת ראיות שמתייחסת ישירות ל-A.8.30. אתם גם מקבלים סיפור קונקרטי של "לפני ואחרי" לשיתוף עם מנהלים, מו"לים ושותפי פלטפורמה על האופן שבו חיזקתם את פיתוח המיקור החוץ שלכם.
אם אתם מוכנים לעבור מהסכמי סודיות מפוזרים ומאמץ אישי הרואי למערכת קוהרנטית וניתנת לביקורת לאבטחת פיתוח במיקור חוץ, כדאי לבדוק כיצד ISMS.online מטפלת בתרחישים שלכם בעולם האמיתי. סיור חי יכול להראות כיצד ניתן לנהל במקום אחד את מחזור החיים, מיפוי הסיכונים, התחייבויות חוזיות וסקירות הספקים שזה עתה בחנתם, בקצב שבו אולפני המשחקים מתקדמים בפועל.
כיצד טייס ממוקד בונה ראיות A.8.30
פרויקט פיילוט ממוקד מאפשר לכם להוכיח שמסגרת הפיתוח שלכם במיקור חוץ עובדת בפועל, מבלי שתצטרכו להעביר כל שותף בבת אחת. על ידי התמקדות בכותר אחד או בקבוצה קטנה של ספקים, אתם מייצרים ראיות קונקרטיות עבור A.8.30, תוך שמירה על שינוי בר-ניהול עבור צוותים עסוקים.
בפועל, אתם בוחרים תרחיש בעל השפעה גבוהה - סטודיו גדול לפיתוח משותף, ספק מרכזי של תהליכים חיים או שותף פורט שנוגע בבניות ובמפתחות חתימה. לאחר מכן אתם מדגמים את מחזור החיים המלא ב-ISMS.online: החלטות קליטה, תוצאות בדיקת נאותות, התחייבויות חוזיות, אישורי גישה, בקרות צינור וסקירות ספקים. כל שלב מייצר תוספות שתוכלו להציג למבקרים ולמוציאים לאור: הערכות סיכונים, החלטות, זרימות עבודה ויומני רישום הקשורים לבקרות ספציפיות.
מכיוון שהפיילוט הוא מצומצם, צוותים יכולים לתת משוב שימושי ותוכלו לחדד תבניות, זרימות עבודה ובעלות לפני פריסה רחבה יותר. לאחר השלמת הפיילוט, יהיה לכם גם דפוס חוזר וגם תיק עבודות של דוגמאות מהעולם האמיתי המדגימות כיצד אתם מאבטחים פיתוח במיקור חוץ בפועל, ולא רק במסמכי מדיניות.
למה לצפות מהדגמה של ISMS.online
הדגמה של ISMS.online מעניקה לכם סיור מודרך כיצד שיטות הפיתוח החיצוני הקיימות שלכם יכולות להיראות בתוך מערכת תואמת ISO 27001. אתם רואים כיצד הפלטפורמה יכולה לשקף את מבנה הסטודיו שלכם, תוך מתן המשמעת והנראות הנדרשים לפי A.8.30 ולבקרות הספקים.
בדרך כלל, הדגמה מלמדת כיצד להגדיר מדיניות פיתוח חיצונית, למפות שותפים וסיכונים, להתאים חוזים לבקרות, ללכוד החלטות גישה ולהגדיר מחזורי סקירת ספקים. תראו כיצד יצרנים, מובילי טכנולוגיה וצוותי תאימות יכולים לעבוד באותה סביבה, תוך שימוש בתבניות משותפות במקום לבנות כלים משלהם מאפס. תוכלו להביא דוגמאות אמיתיות - כגון התקשרות נוכחית עם פיתוח משותף או פורט עתידי - ולחקור כיצד הן ישבו בתוך הפלטפורמה.
בחרו ב-ISMS.online כשאתם רוצים שפיתוח חיצוני ירגיש מאורגן, ניתן לביקורת ותואם לתקן ISO 27001, מבלי להאט את הייצור עד אפס מקום. אם אתם מעריכים זרימות עבודה ברורות, בעלות משותפת וראיות שעומדות במבחן, הצוות שלנו מוכן לעזור לכם לבחון איך זה יכול להיראות עבור הסטודיו שלכם בפגישה חיה שנבנתה סביב הכותרים והשותפים שלכם בפועל.
הזמן הדגמהשאלות נפוצות
כיצד על סטודיו למשחקים לפרש את תקן ISO 27001 A.8.30 כאשר הוא משתמש בשותפי פיתוח חיצוניים?
תקן ISO 27001 A.8.30 מצפה מכם להתייחס לפיתוח חיצוני כאילו הוא מתרחש בתוך הסטודיו שלכם, תחת ניהול SDLC ו-ISMS מאובטחים, ולא כפעילות "ספק קופסה שחורה" לא מפוקחת. בפועל, כל בית פיתוח משותף, ספק אמנות, צוות פורט או שותף לייב-אפס שנוגע בקוד, בניות או כלים צריכים לעבוד לפי כללי ה-secure-by-design שלכם, ועליכם להיות מסוגלים להראות כיצד אתם מכוונים, מנטרים ובודקים את עבודתם לאורך מחזור החיים המלא.
אילו סיכונים A.8.30 מנסה בפועל לשלוט?
A.8.30 נועד לעצור כשלים נפוצים מאוד אך מזיקים:
- מחשב נייד של קבלן עם קוד מקור או כלי ניפוי שגיאות נגנב.
- ספק בעלות נמוכה מטפל בצורה שגויה במפתחות חתימה או בתעודות בנייה.
- ספק קטן הופך לנתיב הכניסה למערכת הבנייה או לכלי התפעול החי שלכם.
הבקרה דוחפת אותך ל:
- להחליט מה תעשה במיקור חוץ, על אילו סביבות, באיזה סיכון.
- הפכו את ההחלטות הללו ל דרישות ברורות וכתובות ברמת הפרויקט, לא רק ניסוח של "להיות בטוחים".
- הטמעת דרישות בתוך רכש, חוזים, קליטה, SDLC ויציאה מהחברה, לא רק מדיניות.
- שמור עדות – חוזים, מודלי גישה, רישומי סקירה, יומני בנייה – שמראים כיצד שמרת על שליטה.
אם תוכלו לבחור כל שותף ולענות, בעזרת חפצים, על השאלה "מה הם בונים, במה הם יכולים לגעת, ואיך אנחנו יודעים שהם פעלו לפי הכללים שלנו?", אתם הרבה יותר קרובים למה ש-A.8.30 מצפה מסטודיו משחקים.
במה שונה A.8.30 מבקרות ספק אחרות?
נספחים A.5.19–A.5.22 עוסקים בספקים באופן כללי: בחירה, הסכמים, סיכון שרשרת אספקה וניטור מתמשך. נספח A.8.30 מתמקד בנושא. עבודת פיתוח תוכנה במיקור חוץעבור סטודיו, זה בדרך כלל אומר לקשר את A.8.30 לתוך:
- A.5.19–A.5.22 לבחירת ספקים, חוזים וסקירות.
- A.8.25–A.8.29 לפיתוח, בדיקות וניהול שינויים מאובטחים.
- A.8.31 להפרדת סביבות פיתוח, בדיקה וייצור.
השימוש ב-ISMS.online כדי לקשר ספקים, סיכונים, מדיניות פיתוח מאובטח ובקרות סביבה מראה שעבודה חיצונית נשלטת על ידי אותו ISMS כמו מהנדסים פנימיים, במקום לחיות בכונן משותף או בתיבת הדואר הנכנס של מישהו. תמונה מאוחדת זו היא בדיוק מה שמבקרים, בעלי פלטפורמה ולקוחות ארגוניים מחפשים כשהם שואלים כיצד אתם מנהלים פיתוח משותף וספקים.
כיצד יש לבנות חוזים והסכמי רמת שירות (SLA) כך שעבודה במיקור חוץ תתמוך באמת בתקן ISO 27001 A.8.30?
תקבלו את הערך הרב ביותר מ-A.8.30 אם החוזים שלכם כוללים התחייבויות אבטחה מפורש, עקבי וניתן לבדיקה, במקום להסתיר אותם במסמך סטנדרטי כללי. "מחסנית" חוזים פשוטה עובדת היטב עבור רוב האולפנים: הסכם שירותים ראשי, סודיות (NDA), הצהרת עבודה ולוח זמנים קצר של אבטחה/SLA המצביע על ציפיות ה-ISMS והפיתוח המאובטח שלכם.
איזה תפקיד ממלאת כל שכבת חוזה עבור A.8.30?
כל שכבה הופכת חלקים שונים של הבקרה למציאותיים:
- הסכם שירותים ראשי (MSA): נעילת בעלות על IP, סודיות ברמה גבוהה, חובות אבטחה כלליות ושלכם הזכות לאמת או לבקר.
- סודיות: מפרט מה סודי - מזלגות מנוע, כלים פנימיים, בניות מוקדמות, טלמטריה - וכיצד יש להגן עליו.
- הצהרת עבודה (SoW): מגדיר אילו מודולים, מאגרים, כלים וסביבות השותף יכול להשתמש בהם עבור פרויקט, והיכן מתחילות ומסתיימות תחומי האחריות שלו.
- לוח זמנים לאבטחה ו-SLA: קובע דרישות מעשיות: חשבונות בעלי שם ו-MFA, כללי סקירת קוד, מיקומי בנייה מאובטחים, זמני הודעה על אירועים, שלבי יציאה וכל התחייבויות תאימות ספציפיות.
מנקודת מבט של תקן ISO 27001, השאלה האמיתית אינה "האם יש לכם חוזים?" אלא "האם החוזים שלכם להתאים את מדיניות ה-ISMS שלך", והאם אתה יכול להוכיח שהשתמשת בהם עבור שותף זה בפרויקט הזה?" הקשרים של לוחות זמנים אבטחה סטנדרטיים ל-SDLC המאובטח שלך ומאוחסנים ב-ISMS.online מול כל ספק הופכים את זה לקל מאוד להוכחה.
אילו סעיפים חשובים ביותר עבור אולפני משחקים?
מכיוון שמשחקים משלבים קוד, תוכן ושירותים פעילים תמידיים, חלק מהסעיפים ראויים לתשומת לב מיוחדת:
- IP וכלים: בעלות ברורה ורישוי של קניין רוחני של משחקים, ענפי מנוע, מערכות בנייה וכלים קנייניים שפותחו או נמצאים בשימוש על ידי שותפים.
- בקרת גישה: דרישות ל חשבונות בעלי שם ומאומתים באמצעות MFA ורישוםאיסור מפורש על כניסות משותפות למאגרים, פאנלים של ניהול או קונסולות של לייב-אפס.
- תהליך פיתוח מאובטח: חובה ללכת בעקבותיך SDLC מאובטח – כולל ביקורת עמיתים, ניהול תלויות, טיפול בפגיעויות, שימוש ב-CI/CD שלך ובקרת שינויים.
- דיווח על תקריות: טריגרים המכסים דליפות מקור, שיבוש מערכות בנייה, חשבונות שנפרצו ושימוש לרעה בכלי Live-Ops, לא רק פרצות מידע אישי.
- מונחי עיבוד נתונים: ניסוח התואם את GDPR או חוקי פרטיות אחרים, שבהם שותפים יכולים לראות נתוני שחקנים או צוות (לדוגמה, תוכן דוחות קריסה או פניות תמיכה).
ניתן לשמור על גישה מעשית זו על ידי סטנדרטיזציה של משפחה קטנה של נספחים לאבטחה עבור סוגי ספקים נפוצים (פיתוח משותף, הסבה, אבטחת איכות, עיצוב, פעולות חיים). כאשר תבניות והסכמים חתומים אלה נמצאים ב-ISMS.online, מקושרים לרשומות ספקים וסיכונים קשורים, התשובה לשאלה "כיצד יישמת את A.8.30 כאן?" הופכת לחיפוש מהיר במקום לחטט בתיקיות ישנות.
אילו בקרות טכניות חשובות ביותר כאשר צוותים חיצוניים ניגשים למאגרים, לסביבות ול-CI/CD שלך?
הבקרות הטכניות שמגנות עליך בצורה הטובה ביותר הן אלו ש להגביל ולהתבונן מפתחים חיצוניים באופן אוטומטי, במקום להסתמך על כולם שיזכרו כללים. עבור רוב האולפנים זה מסתכם בניהול זהויות וגישה קפדני במאגרים ובכלים, הפרדת סביבות וצינורות CI/CD שמתייחסים לקוד חיצוני בדיוק כמו קוד פנימי.
כיצד כדאי לעצב גישה עבור מפתחים חיצוניים?
דפוס מעשי הוא לתכנן גישה סביב תפקידים מוגדרים היטב והפריבילגיה הכי פחותה:
- הגדירו מספר קטן של תפקידים חיצוניים כגון *מהנדס משחקיות משותף לפיתוח*, *מהנדס פורט*, *QA חיצוני*, *מפתח כלים חיצוני*.
- מפו כל תפקיד למאגרים, ענפים, דקי בנייה, לוחות פרויקטים וכלים ספציפיים - ולא יותר.
- השתמש בהגנה על סניפים כדי שחשבונות חיצוניים לא ניתן לדחוף ישירות לפתח סניפים ראשיים או לשחרר אותם; לדרוש בקשות מיזוג/משיכה ובדיקה פנימית עבור תחומים רגישים כגון אנטי-צ'יט, מערכות זכאות, כלכלה וירטואלית, שידוכים ואינטגרציה של פלטפורמות.
- יש להרחיק זהויות חיצוניות מקונסולות הייצור והפעילות הלייב; עליהן לעבוד בסביבות פיתוח/בדיקה נפרדות עם אישורים נפרדים, רשתות מפולחות וניטור ברור.
אם חשבון שותף נעשה בו שימוש לרעה, ריסון זה שומר על רדיוס הפיצוץ קטן וקל להסבר למבקרים ולשותפי פלטפורמה. זה גם נותן לך ראיות ישירות לאופן שבו יישמת את A.8.30 כאשר מישהו שואל כיצד נמנע מספק חיצוני מלקדם את הפעולה "בטעות" ישירות לפעילות.
כיצד CI/CD ואוטומציה יכולים לשאת ברוב עומס האבטחה?
צינורות ה-CI/CD שלכם הם המקום שבו אתם יכולים לאפות את ציפיות A.8.30 בעבודה היומיומית:
- הפעלת בדיקות יחידה, בדיקות סגנון קוד, ניתוח סטטי וסריקות תלות על כל בקשת מיזוג, בלי קשר למי שכתב את הקוד.
- אפשרו רק מבנים הניתנים למשלוח או חתומים על ידי הרצים הנשלטים שלך מענפים מוגנים; לעולם אל תסתמך על תוכניות בניה של שותפים מקומיים עבור שום דבר שיכול להגיע לשחקנים.
- דרוש אישורים או בדיקות נוספות בצנרת עבור רכיבים בעלי סיכון גבוה (לדוגמה, אנטי-צ'יט, מסחר, לוגיקת זכאות) כך שסקירתם תהיה חלק מהזרימה, לא רק הנחיה.
- שמרו יומני בנייה, היסטוריית פריטים ורשימות חומרים של התוכנה כדי שתוכלו להראות אשר מתחייבים ותלויות נכנס לבנייה ומתי.
כאשר צינורות אלו גלויים, ניתנים לחזרה וממופים לבקרות ISO 27001 הרלוונטיות בתוך ISMS.online, קל הרבה יותר להרגיע מבקרים, בעלי פלטפורמות ומנהיגים עסקיים שפיתוח במיקור חוץ מנוהל באותו סטנדרט כמו עבודה פנימית, במקום להוות נקודה מתה נוספת.
כיצד יכול סטודיו להעריך ולנטר את מצב האבטחה של שותפי פיתוח חיצוניים לאורך זמן, לא רק בשלב הקליטה?
בדרך כלל תקבלו תוצאות טובות יותר על ידי שילוב בדיקות מקדימות מבוססות סיכון עם מחזור סקירה וניטור פשוט ומתוזמן, במקום להסתמך על שאלון חד פעמי ענק בעת הקליטה. שותפים בעלי השפעה גבוהה מקבלים תשומת לב מובנית יותר, ואתם משתמשים בטלמטריה משלכם כדי ליידע אתכם מתי נדרשת בדיקה נוספת.
איך מחליטים אילו שותפים זקוקים לתשומת לב מירבית?
מודל חלוקה ברור ושונה מאפשר ניהול:
- רובד 1: שותפים עם גישה עמוקה לבסיס הקוד הראשי שלכם, מערכת הבנייה, מפתחות חתימה או כלי לייב-אופס - לדוגמה, בתי פיתוח משותף, ספקי מנועי פיתוח, ספקי אנטי-צ'יטים, פלטפורמות לייב-אופס.
- רובד 2: שותפים עם גישה בינונית, כגון בתי פורט, ספקי כלים ואבטחת איכות חיצונית המשתמשים בבניות פנימיות אך ללא קונסולות ייצור.
- רובד 3: שותפים עם גישה מינימלית או ללא גישה כלל למערכת, כגון ספקי אמנות, אולפני אודיו או ספקי לוקליזציה שעובדים רק על נכסים מיוצאים.
ככל שספק יכול להתעמק יותר בקוד או בתשתית, כך הסקירות צריכות להיות תכופות ומפורטות יותר. אולפנים רבים מוצאים סקירות שנתיות עבור Tier 1, כל 18-24 חודשים עבור Tier 2, ובדיקות מבוססות חידוש עבור Tier 3 כנקודת התחלה מעשית, המתאימות אם הסיכון או ההיקף משתנים.
מה צריך לכלול מחזור סקירה מתמשך?
עבור ספקים ברמה גבוהה יותר, מחזור סקירה חוזר עשוי לכלול:
- אישור כי שלהם אישורים, מדיניות ובקרות טכניות עדיין קיימים ועדיין מכסים את עבודתך (לדוגמה, היקף דוח ISO 27001 או SOC 2).
- סקירה קצרה של שינויים משמעותיים בצד שלהם - אזורי אירוח חדשים, קבלני משנה, משרדים, כלים - והחלטה מפורשת האם שינויים אלה מקובלים.
- בדיקה מהירה של יומני הרישום והמדדים שלך הקשורים לפעילותם: גישה חריגה למאגרים או למערכות בנייה, בעיות תצורה חוזרות ונשנות, מערכות בנייה שנכשלו או חריגות מדיניות המקושרות לחשבונות שלהם.
- סיכום תמציתי בכתב הכולל ממצאים, החלטות, משימות מעקב, בעלים ותאריכי יעד.
מה שרואי החשבון רוצים לראות זה שזה יקרה לפי התכנון ובלוח הזמנים, לא רק אחרי שמשהו השתבש. כאשר אתם שומרים את רישום הספקים שלכם, החלטות רמות, הערות סקירה וראיות מעקב יחד ב-ISMS.online, מקושרים לבקרות ספקים וסיכונים ספציפיים בנספח א', אתם יכולים לדבר על מצב הפיתוח שלכם במיקור חוץ בביטחון רב יותר.
אילו טעויות נפוצות של פיתוח במיקור חוץ תופסות אולפני משחקים, וכיצד A.8.30 עוזר לכם להימנע מהן?
רוב הבעיות נובעות מחוסרי תשומת לב יומיומיים ולא מהתקפות מתוחכמות: חשבונות חיצוניים עם יותר גישה ממה שהם צריכים, הרשאות "זמניות" שלעולם לא מוסרות, מודולים קריטיים שנבנו מחוץ לצינורות המבוקרים שלך, או שותפים המשתמשים במכונות לא מנוהלות עבור בניות מוקדמות וכלי ניפוי באגים. במשחקים, תחומים כמו אנטי-צ'יט, מערכות זכאות וזהות, שידוכים, טלמטריה ומפתחות חתימה רגישים במיוחד אך לעתים קרובות מטופלים כמו קוד רגיל.
אילו נקודות תורפה ראויות לעקוב מקרוב?
כמה דפוסים נוטים לצוץ באולפנים:
- פרילנסרים או ספקים קטנים נשארים עם גישת מאגר, דלי ענן או גישת מנהל הרבה אחרי שהמשימה האחרונה שלהם הסתיימה.
- צוותי פיתוח משותפים מרכיבים מודולים חשובים באופן מקומי על החומרה שלהם, תוך עקיפת מקור הבנייה, החתימה והסריקה.
- ספקי אבטחת איכות או אמנות המריצים בניות פנימיות על מכשירים אישיים או משותפים שנמצאים הרבה מתחת לקו הבסיס של האבטחה שלך.
- סביבות "בדיקה" ישנות, פורטלים של ניפוי שגיאות או דליים לאחסון שאף אחד לא מרגיש אחראי עליהם, אבל אנשים פנימיים וחיצוניים רבים עדיין יכולים להגיע אליהם.
- פרטי גישה משותפים עבור שרתי בנייה, קונסולות ניהול או כלי ניטור המשמשים מספר אנשי צוות של שותפים.
אף אחד מאלה אינו דורש ניצול מתקדם; הם מגדילים בשקט את החשיפה שלך עד שמכשיר שאבד, מתקפת פישינג או תצורה שגויה הופכים אותם לפריצה.
כיצד התייחסות ל-A.8.30 כמחזור חיים עוזרת לכם לסגור את הפערים הללו?
אם תשתמשו ב-A.8.30 כטריגר ליצירת פורמליזציה של מחזור חיים של פיתוח במיקור חוץ, נקודות תורפה אלו הופכות לקלות יותר לאיתור ולטפל בהן. מחזור חיים פשוט עשוי לכלול:
- צריכת מזון והערכת סיכונים: לפני הקליטה, יש להחליט מהו הרמה של השותף, הגישה המותרת, הסטנדרטים הרלוונטיים והראיות הנדרשות.
- דפוסי גישה סטנדרטיים: השתמש בתבניות גישה מוגדרות מראש לכל שכבה ותפקיד (לדוגמה, פיתוח משותף לעומת אבטחת איכות לעומת ספק כלים) במקום בהרשאות חד פעמיות.
- רשימות בדיקה לקליטה: ודא שקיימים חשבונות, ש-MFA מופעל, שההדרכה בוצעה, שהסכמי סודיות נחתמים והסביבות הנכונות מוכנות לפני תחילת העבודה.
- ביקורות תקופתיות: עבור ספקים ברמה 1 ו-2, יש להפעיל את מחזור הניטור והסקירה שהגדרתם ולהתאים את הגישה, החוזים או הבקרות אם תמונת הסיכון משתנה.
- שלבי היציאה מהארון: הסר חשבונות ומפתחות, סגור גישה ל-VPN ולכלים, שמור בסובב סודות משותפים, ושמור בארכיון נתונים ספציפיים לשותפים.
כאשר מחזור החיים הזה עובר דרך ISMS.online – עם ספקים, סיכונים, פרויקטים, משימות וראיות המקושרים יחד – יצרנים, אבטחה והנהגה יכולים לראות את אותה תמונה של "מי עושה מה, איפה ותחת אילו כללים". זה גם נותן לך דרך פשוטה לענות על שאלה קשה של בעל פלטפורמה, מו"ל או רואה חשבון: "מה מונע מפיתוח חיצוני להיות החוליה החלשה ביותר שלך?"
כיצד יכולים מפתחים חיצוניים להתחבר ל-SDLC המאובטח שלכם מבלי להאט את לוחות הזמנים של השחרור?
התשובה הקיימת ביותר היא להשתמש בצוותים חיצוניים לעבוד בתוך ה-SDLC המאובטח שלך ולא סביבו, עם ציפיות ברורות ואוטומציה שמבצעות חלק ניכר מהאכיפה. כאשר שותפים פועלים לפי אותן אסטרטגיות הסתעפות, סקירת דרישות, בדיקת ציפיות ושערי שחרור כמו צוותים פנימיים, אתם מגינים על המשחק מבלי שתצטרכו לתחזק "תהליך ספק" נפרד ושברירי שאף אחד לא באמת מאמין בו.
כיצד אמור להיראות שיתוף פעולה יומיומי עם צוותים במיקור חוץ?
במערכת בריאה, מפתחים במיקור חוץ מתנהגים כמו חברי צוות מרוחק משולבים היטב:
- הם מתכננים ועוקבים אחר העבודה ב עוקבי הבעיות, לוחות הספרינט ומפות הדרכים שלך, לצד צוות פנימי, תוך שימוש בהגדרות משותפות של עדיפות ומעמד.
- הם כותבים קוד עבורך סטנדרטים והגדרה של בוצע, כולל כל קריטריון רלוונטי לאבטחה כגון אימות קלט, רישום, טיפול בשגיאות ותקציבי ביצועים.
- הם מגישים שינויים דרך שלך זרימות של בקשת מיזוג או בקשת משיכה לתוך המאגרים שלך, כאשר בדיקות אוטומטיות וסריקות אבטחה פועלות כברירת מחדל.
- הם מקבלים את אותו משוב - בניות כושלות, אזהרות ניתוח סטטי, הערות על סקירת קוד, בעיות תלות - מוקדם מספיק כדי לתקן בעיות ללא עיכובים בפריסה, תרגילי אש או עיכובים בפריסה.
כאשר שותף שומר חלק משרשרת הכלים שלו (לדוגמה, עבור גרפיקה או לוקליזציה), אתם מסכימים על נקודות אינטגרציה מבוקרות: אולי אתם מקבלים רק קוד דרך בקשות משיכה, או רק בולעים נכסים שעוברים סקריפטי אימות משלכם. הנקודה החשובה היא ש שום דבר לא מגיע למאגרים הראשיים שלך, למערכות הבנייה או לסביבות החיות שלך מבלי לעבור דרך ה-SDLC המאובטח שלך.
איך אתם שומרים על התאמה בין מהירות, אבטחה ותקן ISO 27001?
אתם מגינים על מהירות המשלוח על ידי יצירת SDLC מאובטח צפוי, גלוי ובעיקר אוטומטי:
- תעדו איך נראה "טוב" עבור תורמים חיצוניים: מודלים של הסתעפות, כללי סקירה, כיסוי בדיקות מינימלי, בדיקות אבטחה עבור רכיבים רגישים וקריטריונים ברורים של "עצור את הקו" כאשר הסיכון גבוה.
- קידוד הציפיות הללו לתוך צינורות CI/CD, תבניות פרויקטים ורשימות תיוג, כך שאכיפה מגיעה מכלים במקום מזיכרון.
- בצע פיילוט של ה-SDLC המשולב עם שותף אחד או שניים בעלי חשיבות אסטרטגית, שכלל אותו על סמך ניסיונם, ולאחר מכן השתמש בדפוס זה עבור ספקים חדשים.
כאשר תצוגת SDLC שלכם מתועדת, ממופה לבקרות של נספח A ונתמכת על ידי ראיות המאוחסנות ב-ISMS.online - פעולות commit, ביקורות, הפצות צינור, אישורים, מהדורות ופעילויות ספקים - אתם יוצרים קומה אחת שמדברת לכל הצדדים: יצרנים מקבלים יכולת חיזוי, צוותי אבטחה ופרטיות רואים ממשל יעיל, מבקרים רואים בקרה ומעקב, ושותפים רואים דרך ברורה וברורה למשלוח תוכן ותכונות בזמן. אם אתם רוצים לראות איך זה יכול להיראות סביב אחד מהפרויקטים החיים שלכם, בניית תצוגת SDLC פשוטה ב-ISMS.online עבור מערכת יחסים אחת של פיתוח משותף מספיקה לעתים קרובות כדי להביא את הצוותים שלכם ושותפים חיצוניים לאותו עמוד.
