אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info
מפתח API (נקרא ב-Apigee Edge מפתח צרכן) הוא ערך מחרוזת שמוענק על ידי אפליקציית לקוח לשרתי ה-proxy ל-API. המפתח מזהה באופן ייחודי את אפליקציית הלקוח.
אימות מפתח API הוא הצורה הפשוטה ביותר של אבטחה מבוססת-אפליקציה שאפשר להגדיר ל-API. אפליקציית לקוח מציגה פשוט מפתח API בבקשה שלה, ואז Apigee Edge בודק אם מפתח ה-API נמצא במצב מאושר למשאב המבוקש. באופן פנימי, שרת ה-proxy משתמש בכללי מדיניות כדי לאמת את האותנטיות של מפתח ה-API.
כדי ליהנות מהפשטות הזו, תצטרכו לבצע כמה הגדרות. כדי לתמוך במפתחות API, צריך:
- יוצרים מוצר API של Apigee Edge שמקבץ את שרתי ה-proxy ל-API שרוצים להגן עליהם באמצעות מפתח ה-API.
-
יוצרים אפליקציית פיתוח ב-Apigee Edge שמייצגת את מפתח אפליקציית הלקוח שאת האפליקציה שלו תרצו לאמת.
כשיוצרים את אפליקציית המפתח, מציינים את מוצרי ה-API שאפליקציית המפתח תקבל אליהם גישה, ועבורם יהיה צורך לספק מפתח API.
- מוסיפים כללי מדיניות לשרתים הווירטואליים (שכללו במוצר ה-API) כדי לוודא שמפתח API נכנס תקף.
המדריך אבטחה של API באמצעות דרישת מפתחות API הוא דרך מהירה ללמוד איך לשלוט בגישה לשרת proxy של API באמצעות מפתח API.
איך פועלים מפתחות API
ב-Apigee Edge, מפתח API נקרא מפתח צרכן. כשאתם רושמים אפליקציות למפתחים, Apigee Edge יוצר אסימון צרכן וסוד צרכן. Apigee Edge שומר את מפתח הצרכן לצורך אימות עתידי. כל מפתח צרכן הוא ייחודי בארגון. מפתח האפליקציה מטמיע את מפתח הצרכן באפליקציית הלקוח. אפליקציית הלקוח חייבת להציג את מפתח הצרכן בכל בקשה. שירותי ה-API מאמתים את מפתח הצרכן לפני שהם מאשרים את הבקשה של האפליקציה.
שלבים ברמה גבוהה
השלבים הבאים מתארים את האופן שבו Apigee Edge משתמש במפתחות API. השלבים האלה כוללים גם את נוכחות האבטחה של OAuth, כי היא משמשת לרוב בשילוב עם מפתחות API.
- יוצרים מוצר API שכולל שרתי proxy ל-API שצריך להגן עליהם באמצעות מפתח ה-API.
- רושמים אפליקציית פיתוח בארגון. כשעושים זאת, Apigee Edge יוצר מפתח צרכן וסודות צרכן.
- משייכים את אפליקציית המפתח למוצר API אחד לפחות. זהו המוצר שמשויך לנתיבי משאבים ולשרתי proxy ל-API עם אישור מפתחות.
- בזמן הריצה, כשאפליקציית הלקוח שולחת בקשה ל-API, אפליקציית הלקוח שולחת את מפתח הצרכן בזמן שליחת הבקשה. בפועל, אפשר להעביר את מפתח הצרכן באופן מפורש או להפנות אליו באופן משתמע באמצעות אסימון OAuth:
- כשה-API משתמש באימות של מפתח API – למשל, באמצעות הטמעת מדיניות VerifyAPIKey – אפליקציית הלקוח צריכה להעביר את מפתח הצרכן באופן מפורש.
- כשב-API נעשה שימוש באימות של אסימון OAuth – למשל, באמצעות הטמעת מדיניות OAuthV2 – אפליקציית הלקוח צריכה להעביר אסימון שנגזר ממפתח הצרכן.
- Proxy API מאמת את פרטי הכניסה של הבקשה באמצעות מדיניות VerifyAPIKey או מדיניות OAuthV2 עם פעולת VerifyAccessToken. אם לא תכללו מדיניות לאכיפת פרטי הכניסה בשרת ה-API, כל מבצע קריאה יוכל להפעיל את ממשקי ה-API שלכם. מידע נוסף זמין במאמר מדיניות האימות של מפתחות API.
אימות פרטי הכניסה של הבקשה
זו סקירה כללית. כדאי לעיין במאמר הגדרת אימות של מפתח API כדי לקבל פרטים ודוגמאות לקוד.
- אם אתם משתמשים באימות באמצעות אסימון OAuth – הטמעתם מדיניות OAuth לאימות ויישום הלקוח העביר אסימון OAuth:
- Apigee Edge מוודא שהאסימון לא פג תוקף, ואז מחפש את מפתח הצרכן ששימש ליצירת האסימון.
- אם אתם משתמשים במפתח API – הטמעתם מדיניות VerifyAPIKey ואפליקציית הלקוח העבירה את מפתח הצרכן שלה:
- Apigee Edge בודק את רשימת מוצרי ה-API שמשויכים למפתח הצרכן.
- Edge בודק כל מוצר API כדי לראות אם שרת ה-API הנוכחי נכלל במוצר ה-API, ואם נתיב המשאב הנוכחי (נתיב כתובת ה-URL) מופעל במוצר ה-API.
- בנוסף, Edge מאמת שמפתח הצרכן לא פג תוקף או בוטל, בודק שהאפליקציה לא בוטלה ושהמפתח לא פעיל.
- אם כל התנאים האלה מתקיימים – תוקף האסימון לא פג (אם רלוונטי), מפתח הצרכן תקף ואושר, האפליקציה אושרה, המפתחות של המפתחים פעילים, שרת ה-proxy זמין במוצר והמשאב זמין במוצר – תהליך אימות פרטי הכניסה מסתיים בהצלחה.