הסתרת נתונים

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

כשמבצעים ניפוי באגים בקריאות ל-API ב-Apigee, התוכן יכול לפעמים לכלול נתונים רגישים, כמו כרטיסי אשראי או מידע רפואי אישי מזהה (PHI) שצריך להסתיר.

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

הסתרת מידע אישי רגיש

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

<ServiceRequest>
  <request-id>B540A938-F551</request-id>
  <customer-name>**********</customer-name>
</ServiceRequest>

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

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

המבנה של הגדרת מסכה

הגדרות המיסוך הן קבצים בפורמט JSON שמאפשרים לכם לזהות מידע אישי רגיש במקורות הבאים:

• מטענים ייעודיים (payloads) של XML: באמצעות XPath, אתם מזהים רכיבי XML שצריך לסנן ממטענים ייעודיים של הודעות בקשה או תגובה.
• מטענים ייעודיים (payloads) של JSON: באמצעות JSONPath, מזהים מאפייני JSON שצריך לסנן ממטענים ייעודיים (payloads) של הודעות בקשה או תגובה.
• משתני זרימה: אפשר לציין רשימה של משתנים שיוסוו בפלט של ניפוי הבאגים. כשמציינים את משתני הזרימה request.content, response.content או message.content, גם גוף הבקשה או התגובה מוסתר.

בהמשך מופיעה דוגמה למבנה הבסיסי של הגדרת מסכה בפורמט JSON. מידע נוסף על שדות הגדרת המסכה שמוצגים בדוגמה זמין במאמר DebugMask.

{
  "namespaces": {
    "myco": "http://example.com"
  },
  "requestXPaths": [
    "/myco:Greeting/myco:User"
  ],
  "responseXPaths": [
    "/myco:Greeting/myco:User"
  ],
  "faultXPaths": [
    "/myco:Greeting/myco:User"
  ],
  "requestJSONPaths": [
    "$.store.book[*].author"
  ],
  "responseJSONPaths": [
    "$.store.book[*].author"
  ],
  "faultJSONPaths": [
    "$.store.book[*].author"
  ],
  "variables": [
    "request.header.user-name",
    "request.formparam.password",
    "myCustomVariable"
  ]
}

הצגת הגדרות המסיכה בסביבה באמצעות ה-API

כדי לראות את הגדרות המסיכה בסביבה, מריצים GET למשאב הבא:

/organizations/{org}/environments/{env}/debugmask

לדוגמה:

curl "https://apigee.googleapis.com/v1/organizations/myorg/environments/test/debugmask" \
  -X GET \
  -H "Authorization: Bearer $TOKEN"

‫$TOKEN מוגדר לאסימון הגישה מסוג OAuth 2.0, כפי שמתואר במאמר קבלת אסימון גישה מסוג OAuth 2.0. מידע על האפשרויות curl שבהן נעשה שימוש בדוגמה הזו מופיע במאמר שימוש ב-curl. תיאור של משתני הסביבה שבהם אפשר להשתמש מופיע במאמר בנושא הגדרת משתני סביבה לבקשות API של Apigee.

זוהי דוגמה לתשובה:

{
  "name": "organizations/myorg/environments/test/debugmask"
  "namespaces": {
    "myco": "http://example.com"
  },
  "requestXPaths": [
    "/myco:Greeting/myco:User"
  ],
  "responseXPaths": [
    "/myco:Greeting/myco:User"
  ]
}

עדכון הגדרת המסכה בסביבה באמצעות ה-API

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

/organizations/{org}/environments/{env}/debugmask

אפשר גם להעביר את פרמטרים של שאילתה הבאים:

• מגדירים את פרמטר השאילתה updateMask כדי לציין מסכת שדות שכוללת רשימה מופרדת בפסיקים של שמות שדות שמוגדרים במלואם במסכת הניפוי באגים. לדוגמה: "requestJSONPaths"
• מגדירים את פרמטר השאילתה replaceRepeatedFields כדי לציין אם להחליף ערכים קיימים במסכת הניפוי באגים כשמבצעים עדכון. כברירת מחדל, הערכים מצורפים (false)

לדוגמה:

curl "https://apigee.googleapis.com/v1/organizations/myorg/environments/test/debugmask" \
  -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-type: application/json" \
  -d \
  '{
     "namespaces": {
       "ns1": "http://example.com"
     },
     "requestXPaths": [
       "/ns1:employee/ns1:name"
     ]
   }'

‫$TOKEN מוגדר לאסימון הגישה מסוג OAuth 2.0, כפי שמתואר במאמר קבלת אסימון גישה מסוג OAuth 2.0. מידע על האפשרויות curl שבהן נעשה שימוש בדוגמה הזו מופיע במאמר שימוש ב-curl. תיאור של משתני הסביבה שבהם אפשר להשתמש מופיע במאמר בנושא הגדרת משתני סביבה לבקשות API של Apigee.

הסתרת XML בהיקף מרחב שמות

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

לדוגמה, נניח שרוצים להסתיר את שם העובד במטען הייעודי (payload) של הבקשה, ובקובץ ה-XML לא נעשה שימוש במרחבי שמות של XML:

<employee>
  <name>Shanmu Tharman</name>
  <age>50</age>
</employee>

לכן, בהגדרת debugmask לא נדרש האלמנט namespaces:

{
  "requestXPaths": [
    "/employee/name"
  ]
}

אם מטען ה-XML הייעודי משתמש במרחבי שמות עם תחיליות:

<cym:employee xmlns:cym="http://cymbalgroup.com" xmlns:id="http://cymbalgroup.com/identity">
  <id:name>Shanmu Tharman</id:name>
  <id:age>50</id:age>
</cym:employee>

במקרה כזה, הגדרת המסכה צריכה לכלול את הרכיב namespaces. אתם יכולים לבחור כל תחילית חוקית של מרחב שמות בהגדרת debugmask. התחילית של מרחב השמות בהגדרת debugmask יכולה להיות זהה לתחילית של מרחב השמות שמשמשת ב-XML, אבל זה לא חובה.

{
  "namespaces": {
    "cym": "http://cymbalgroup.com",
    "idns": "http://cymbalgroup.com/identity"
  },
  "requestXPaths": [
    "/cym:employee/idns:name"
  ]
}

אם מטען ה-XML משתמש במרחב שמות ללא תחילית, כלומר במרחב השמות שמוגדר כברירת מחדל:

<employee xmlns="http://cymbalgroup.com" xmlns:id="http://cymbalgroup.com/identity">
  <id:name>Shanmu Tharman</id:name>
  <id:age>50</id:age>
</employee>

במקרה כזה, בהגדרת debugmask עדיין צריך להגדיר קידומת ברכיב namespaces שמתאים למרחב השמות שמוגדר כברירת מחדל. אתם יכולים להשתמש בכל קידומת ייחודית שתרצו.

{
  "namespaces": {
    "p1": "http://cymbalgroup.com",
    "id": "http://cymbalgroup.com/identity"
  },
  "requestXPaths": [
    "/p1:employee/id:name"
  ]
}

הערות נוספות לגבי הגדרות

• בעזרת רכיבי ההגדרה *XPaths ו-*JSONPaths, אפשר להסוות נתונים שמופיעים בהודעות request, response או fault. אבל יכול להיות שתוכן ההודעה המלא יתועד גם בסשנים של ניפוי באגים. כדי למנוע הצגה של מידע אישי רגיש, אפשר גם להגדיר את request.content או את response.content בקטע variables.

• אם משתמשים במדיניות ServiceCallout כדי לשלוח בקשה, המידע בבקשה ובתגובה של הקריאה הזו לא יוסתר באמצעות רכיבי ההגדרה כמו requestXPaths או responseJSONPaths. אם רוצים להסתיר את הנתונים האלה, צריך לציין שם משתנה להודעות הבקשה והתגובה במדיניות ServiceCallout, ואז לציין את המשתנים האלה בקטע variables של debugmask. לדוגמה, אם מדיניות ServiceCallout משתמשת ב:

  <ServiceCallout name='SC-1'>
    <Request variable='rbacRequest'>
      <Set>
        <Payload contentType='application/json'>{ ... }</Payload>
         ...
  

  לאחר מכן צריך לכלול את rbacRequest.content ברכיב variables של הגדרת debugmask.

  {
    ...
    "variables": [
      "request.content",
      "response.content",
      "rbacRequest.content"
    ]
  }

הסתרה של מידע אישי ורגיש

בנוסף להסתרת נתונים, אפשר למנוע מנתונים רגישים להופיע בכלי Trace ובסשנים של ניפוי באגים. לשם כך, צריך לבחור שם שמתחיל ב-private. למשתנים המותאמים אישית.

לדוגמה, כשמשתמשים במדיניות Key Value Map Operations כדי לאחזר ערך ממפת ערכי מפתח, אפשר לבחור את שם המשתנה באופן הבא כדי לוודא שהערך לא יופיע ב-Trace או בסשנים של ניפוי באגים:

<KeyValueMapOperations name='KVM-Get-1'>
    <Scope>environment</Scope>
    <ExpiryTimeInSecs>300</ExpiryTimeInSecs>
    <MapName>settings</MapName>
    <Get assignTo='private.privatekey'>
      <Key>
        <Parameter>rsa_private_key</Parameter>
      </Key>
    </Get>
  </KeyValueMapOperations>

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