אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
כדי שלקוח יוכל לעמוד בדרישות התאימות לתקן PCI ב-Apigee Edge Public Cloud, יש פעולות ותהליכים שהלקוח אחראי להם במסגרת 'מודל האחריות המשותפת'. הפריטים הבאים מיועדים לבדיקה על ידי לקוחות שרכשו את חבילת התאימות ל-PCI ונדרשים לעמוד בדרישות התאימות ל-PCI. הפריטים האלה הם בניהול עצמי ב-Edge, וצריך לטפל בהם כדי שהארגון של הלקוח יעמוד בדרישות התאימות לתקן PCI. הקונספט הכללי הוא: Google מאבטחת את הפלטפורמה, הלקוח מאבטח את הנתונים שלו.
מטריצת האחריות של הלקוח
הלקוחות צריכים לעיין ב מטריצת האחריות המשותפת של Google Cloud Platform: PCI DSS v4.0.1 ולשתף אותה עם בוחן האבטחה המוסמך שלהם ל-PCI כשהם מבצעים ביקורת PCI משלהם.
מיפוי הדרישות של PCI
| דרישת PCI | Section |
|---|---|
| דרישה 7: הגבלת הגישה לרכיבי המערכת ולנתונים של בעלי כרטיסים לפי הצורך העסקי לדעת | |
| דרישה 3: הגנה על נתוני החשבון המאוחסנים | |
| דרישה 10: רישום ביומן ומעקב אחרי כל הגישה לרכיבי המערכת ולנתוני בעלי הכרטיסים | |
| דרישה 8: זיהוי משתמשים ואימות גישה לרכיבי המערכת | |
| דרישה 11: בדיקה קבועה של אבטחת המערכות והרשתות | |
| דרישה 4: הגנה על נתוני בעלי הכרטיס באמצעות קריפטוגרפיה חזקה במהלך ההעברה ברשתות ציבוריות פתוחות | |
| דרישה 3: הגנה על נתוני החשבון המאוחסנים | |
| דרישה 4: הגנה על נתוני בעלי הכרטיס באמצעות קריפטוגרפיה חזקה במהלך ההעברה ברשתות ציבוריות פתוחות |
כדי לקבל אישור תאימות (AOC) לתקן אבטחת הנתונים של PCI, פותחים כרטיס תמיכה ב-Apigee או פונים לצוות המכירות של Apigee.
מעקב / ניפוי באגים
Trace/Debug הוא כלי לפתרון בעיות שמאפשר למשתמש לראות את הסטטוס והתוכן של קריאה ל-API בזמן שהיא מעובדת דרך מעבד ההודעות של Apigee. Trace ו-Debug הם שני שמות לאותו שירות, אבל הגישה אליהם מתבצעת באמצעות מנגנונים שונים. Trace הוא השם של השירות הזה בממשק המשתמש של Edge. Debug הוא השם של אותו שירות כשמשתמשים בו דרך קריאות ל-API. השימוש במונח Trace במסמך הזה תקף גם ל-Trace וגם ל-Debug.
במהלך סשן של Trace, נאכפת 'הסתרת נתונים'. הכלי הזה יכול לחסום את הצגת הנתונים במהלך מעקב. מידע נוסף זמין בקטע הסתרת נתונים שבהמשך.
לקוחות שעומדים בדרישות של PCI יכולים להשתמש במיפויים מוצפנים של ערכי מפתח (KVM). אם נעשה שימוש ב-KVM מוצפן, עדיין אפשר להשתמש בכלי Trace, אבל חלק מהמשתנים לא יוצגו במסך התצוגה של Trace. אפשר לבצע שלבים נוספים כדי להציג את המשתנים האלה גם במהלך מעקב.
הוראות מפורטות לשימוש ב-Trace זמינות במאמר שימוש בכלי Trace.
פרטים על KVM, כולל KVM מוצפנים, זמינים במאמר עבודה עם מיפויים של מפתח/ערך.
שימוש/הרשאות
הגישה ל-Trace מנוהלת דרך מערכת RBAC (בקרת גישה מבוססת-תפקידים) עבור חשבונות משתמשים ב-Edge. הוראות מפורטות לשימוש במערכת RBAC כדי להעניק ולבטל הרשאות ל-Trace זמינות במאמרים הקצאת תפקידים ויצירה של תפקידים בהתאמה אישית בממשק המשתמש. הרשאות המעקב מאפשרות למשתמש להפעיל מעקב, לעצור מעקב ולגשת לפלט של סשן מעקב.
ל-Trace יש גישה למטען הייעודי (payload) של קריאות ל-API (שנקרא בעבר 'גוף ההודעה'), ולכן חשוב לשקול למי יש גישה להרצת Trace. ניהול המשתמשים הוא באחריות הלקוח, ולכן גם מתן הרשאות ל-Trace הוא באחריות הלקוח. ל-Apigee, כבעלים של הפלטפורמה, יש אפשרות להוסיף משתמש לארגון של לקוח ולהקצות לו הרשאות. היכולת הזו משמשת רק לבקשת תמיכה של לקוח במצב שבו נראה ששירות הלקוחות לא פועל, ובדיקה של סשן Trace עשויה לספק את המידע הטוב ביותר על שורש הבעיה.
אנונימיזציה של נתונים
התממת נתונים מונעת את הצגת המידע הרגיש רק במהלך סשן של מעקב או ניפוי באגים, גם במעקב (ממשק משתמש של Edge) וגם בקצה העורפי באמצעות ניפוי באגים (Edge API). פרטים על הגדרת אנונימיזציה זמינים במאמר אנונימיזציה והסתרה של נתונים. הסתרת מידע אישי רגיש היא חלק מדרישה 3 של PCI – הגנה על נתונים של בעלי כרטיסים שמאוחסנים
הסתרת נתונים לא מונעת את הצגת הנתונים בקובצי יומן, במטמון, ב-Analytics וכו'. כדי לקבל עזרה בהסתרת נתונים ביומנים, אפשר להוסיף תבנית regex לקובץ logback.xml. בדרך כלל, לא כדאי לכתוב מידע אישי רגיש במטמון או ב-Analytics בלי הצדקה עסקית חזקה ובלי בדיקה של צוותי האבטחה והמשפטים של הלקוח.
מטמון L1 ו-L2
לקוחות שעומדים בדרישות התקן PCI יכולים להשתמש במטמון רק עם נתונים לא מפוקחים. אסור להשתמש במטמון לנתוני בעלי כרטיסים (CHD) של PCI. המטמון לא אושר על ידי ביקורת התאימות ל-PCI של Apigee כמקום אחסון ל-CHD. בהתאם להנחיות של PCI (דרישה 3: הגנה על נתונים של בעלי כרטיסים שמאוחסנים) , נתוני PCI צריכים להיות מאוחסנים רק במיקום שתואם ל-PCI. אם משתמשים במטמון L1, המערכת תשתמש אוטומטית גם במטמון L2. מטמון L1 הוא 'זיכרון בלבד', ומטמון L2 כותב נתונים לדיסק כדי לסנכרן בין כמה מטמוני L1. מטמון L2 הוא מה ששומר על סנכרון בין כמה מעבדי הודעות באזור מסוים ובעולם. בשלב הזה, אי אפשר להפעיל מטמון L1 בלי מטמון L2 מאחוריו. המטמון L2 כותב נתונים לדיסק כדי שאפשר יהיה לסנכרן אותם עם מעבדי הודעות אחרים בארגון של הלקוח. מכיוון ש-L2 Cache כותב את הנתונים לדיסק, השימוש במטמון ל-CHD או לנתונים מוגבלים אחרים לא נתמך.
מותר ללקוחות להשתמש במטמון לנתונים שאינם CHD ולנתונים אחרים ללא הגבלה. אנחנו לא משביתים את המטמון כברירת מחדל ללקוחות שעומדים בדרישות התאימות לתקן PCI, כי חלק מהלקוחות מריצים קריאות API שקשורות לתקן PCI וקריאות API שלא קשורות לתקן PCI דרך ארגון יחיד. היכולת הזו עדיין מופעלת עבור לקוחות שעומדים בדרישות של PCI, ולכן הלקוח אחראי להשתמש בשירות בצורה מתאימה ולהנחות את המשתמשים שלו לא להשתמש במטמון כשיש סיכוי שנתוני PCI ייכללו בקריאה ל-API. בביקורת התאימות לתקן PCI של Apigee אין תמיכה בנתוני כרטיסי אשראי שמאוחסנים במטמון.
הוראות מפורטות לשימוש במטמון זמינות במאמר הוספת מטמון והתמדה.
נתיב ביקורת
הלקוחות יכולים לבדוק את נתיב הביקורת של כל הפעילויות האדמיניסטרטיביות שבוצעו בארגון שלהם, כולל השימוש בכלי Trace. הוראות מפורטות זמינות כאן ובמאמר שימוש בכלי למעקב. (דרישת PCI מספר 10: מעקב וניטור של כל הגישה למשאבי הרשת ולנתוני בעלי הכרטיסים)
דרישות מורכבות לסיסמאות או SAML
לקוחות עם דרישות ספציפיות לסיסמאות צריכים להשתמש ב-SAML כדי לעמוד בדרישות האישיות שלהם. אפשר לקרוא את המאמר בנושא הפעלת אימות SAML ב-Edge. ב-Edge יש גם אימות רב-שלבי (דרישת PCI מספר 8: הקצאת מזהה ייחודי לכל אדם עם גישה למחשב). איך מפעילים אימות דו-שלבי בחשבון Apigee
אבטחת נקודות קצה
סריקת נקודות קצה
סריקה ובדיקה של מארחים נדרשות לצורך עמידה בתקן PCI (דרישה 11: בדיקה קבועה של מערכות ותהליכי אבטחה). ב-Edge Cloud, הלקוחות אחראים לסריקה ולבדיקה של נקודות הקצה של ה-API שלהם (לפעמים נקראות 'רכיבי זמן הריצה') ב-Edge. בדיקות הלקוחות צריכות לכלול את שירותי ה-API proxy בפועל שמארחים ב-Edge, שבהם תנועת ה-API נשלחת ל-Edge לפני העיבוד ואז מועברת למרכז הנתונים של הלקוח. לקוחות פרטיים לא יכולים לבדוק משאבים משותפים, כמו ממשק המשתמש של פורטל הניהול (לקוחות יכולים לקבל דוח של צד שלישי שכולל בדיקות של השירותים המשותפים, בכפוף להסכם סודיות ולבקשה).
מומלץ ללקוחות לבדוק את נקודות הקצה שלהם ל-API. ההסכם שלך עם Apigee לא אוסר על בדיקת נקודות הקצה של ה-API, אבל אנחנו לא מאפשרים לך לבדוק את ממשק המשתמש המשותף לניהול. עם זאת, אם דרושה הבהרה נוספת, אפשר לפתוח בקשת תמיכה ולציין בה את הבדיקות המתוכננות. נשמח לקבל הודעה מראש ל-Apigee כדי שנוכל להיות מודעים לתנועת הבדיקה.
לקוחות שבודקים את נקודות הקצה שלהם צריכים לחפש בעיות ספציפיות ל-API, בעיות שקשורות לשירותי Apigee, ולבדוק גם את ה-TLS ופריטים אחרים שאפשר להגדיר. אם נמצאים פריטים שקשורים לשירותי Apigee, צריך לדווח על כך ל-Apigee באמצעות בקשת תמיכה.
רוב הפריטים שקשורים לנקודת הקצה הם פריטים בניהול עצמי של הלקוח, ואפשר לפתור את הבעיות בהם על ידי עיון במסמכי התיעוד של Edge. אם יש פריטים שלא ברור איך לתקן אותם, אפשר לפתוח בקשת תמיכה.
הגדרת TLS
בהתאם לתקני PCI, צריך להעביר את SSL וגרסאות קודמות של TLS לגרסאות מאובטחות. הלקוחות אחראים להגדיר ולתת הגדרה משלהם לנקודות קצה של TLS עבור שרתי proxy של API. זוהי תכונה בשירות עצמי ב-Edge. הדרישות של הלקוחות לגבי הצפנה, פרוטוקול ובחירת אלגוריתם משתנות מאוד וספציפיות לתרחישי שימוש פרטניים. מכיוון ש-Apigee לא יודע את הפרטים של עיצוב ה-API ומטעני הנתונים של כל לקוח, הלקוחות אחראים לקבוע את ההצפנה המתאימה לנתונים בזמן ההעברה. הוראות מפורטות להגדרת TLS זמינות במאמר בנושא TLS/SSL.
אחסון הנתונים
אחסון נתונים ב-Edge לא נדרש כדי ש-Edge יפעל בצורה תקינה. עם זאת, יש שירותים לאחסון נתונים ב-Edge. הלקוחות יכולים לבחור להשתמש במטמון, במפות של ערכי מפתח או בניתוח נתונים לאחסון נתונים. אף אחד מהשירותים האלה לא מורשה לאחסן נתוני כרטיסי אשראי בהתאם לביקורת PCI של Apigee. בהתאם לדרישה 3 של PCI (הגנה על נתונים של בעלי כרטיסים שמאוחסנים), נתוני PCI צריכים להיות מאוחסנים רק במיקומים שעומדים בדרישות של PCI. הלקוחות יכולים להשתמש בשירותים האלה כדי לאחסן נתונים שלא קשורים ל-PCI או נתונים אחרים ללא הגבלה, בכפוף לדרישות האבטחה והדרישות המשפטיות של הלקוח. השירותים האלה הם פריטים של שירות עצמי ללקוחות, ולכן הלקוח אחראי להגדיר אותם כך שלא יתעדו או יאחסנו נתוני כרטיסי אשראי. מומלץ שמנהלי לקוחות יבדקו את ההגדרות, המדיניות והפריסות כדי למנוע שימוש לא תואם בשירותי אחסון נתונים ב-Edge, בטעות או בזדון .
הצפנת נתונים
אנחנו לא מציעים ללקוחות כלים להצפנת נתונים לשימוש ב-Edge. עם זאת, הלקוחות יכולים להצפין את נתוני ה-PCI שלהם לפני שהם שולחים אותם ל-Edge. דרישה 4 של PCI: (הצפנת שידור של נתוני בעלי כרטיסים ברשתות ציבוריות פתוחות) מומלץ להצפין נתוני בעלי כרטיסים ברשתות ציבוריות פתוחות. נתונים מוצפנים במטען הייעודי (או בגוף ההודעה) לא מונעים מ-Edge לפעול. יכול להיות שחלק ממדיניות Edge לא יוכלו ליצור אינטראקציה עם הנתונים אם הלקוח יקבל אותם מוצפנים. לדוגמה, לא ניתן לבצע טרנספורמציה אם הנתונים עצמם לא זמינים ל-Edge כדי לשנות אותם. אבל מדיניות אחרת, מדיניות שנוצרה על ידי לקוחות וחבילות מדיניות יפעלו גם אם מטען הנתונים מוצפן.