אבטחה של הקילומטר האחרון

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

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

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

אלה האפשרויות העיקריות להגדרת אבטחה של השלב האחרון בתהליך:

• TLS/SSL של לקוח
• אימות בשיחות יוצאות

TLS/SSL של לקוח

המנגנון העיקרי לאבטחת הקילומטר האחרון הוא TLS/SSL של הלקוח, שנקרא גם 'אימות הדדי'.

אפשרויות להגדרת TLS

אימות בשיחות יוצאות

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

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

מפתח API

אפשר להחיל מפתחות API על בקשות יוצאות משרתי proxy ל-API לשירותי קצה עורפי. ההנחה היא ששירות לקצה העורפי הוא API שיכול להנפיק מפתחות API ולאמת אותם.

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

אתם יכולים להשתמש בסוג המדיניות AssignMessage כדי להוסיף את מפתח ה-API ככותרת HTTP, כפרמטר של שאילתה או כרכיב של מטען ייעודי (payload) לבקשה היוצאת. איך מקצים מדיניות להעברת הודעות

שיטה מומלצת: כדי למנוע חשיפה של מפתחות API ברשת, תמיד צריך להגדיר TLS/SSL בצד השרת בשירותי הקצה העורפי לעסקאות יוצאות שמשתמשות במפתחות API

פרטי כניסה של לקוח OAuth

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

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

אזהרה: כדי שהשיטה הזו תפעל, שירותי ה-Backend שלכם צריכים להיות מסוגלים להנפיק ולאמת אסימוני גישה באמצעות סוג ההרשאה client credentials.

תמיד צריך להגדיר TLS/SSL בצד השרת בשירותי הקצה העורפי לעסקאות שמשתמשות באסימוני גישה.

יש כמה גישות להטמעה של פרטי כניסה של לקוח יוצא.

דוגמה: דוגמה של OAuth יוצאת שפועלת ומשתמשת בפרטי לקוח מיושמת בדוגמה של OAuth יוצאת ב-GitHub.

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

SAML

אפשר להשתמש בסוג המדיניות GenerateSAMLAssertion כדי לצרף הצהרת SAML להודעת בקשת XML יוצאת, מ-proxy ל-API לשירות לקצה העורפי. כך שירות לקצה העורפי יוכל לבצע אימות והרשאה לבקשות שמתקבלות מ-proxy ל-API.

מדיניות בנושא הצהרות SAML