שיטות מומלצות לשימוש ב-Apigee CMEK

בדף הזה מפורטות שיטות מומלצות לשימוש ב-CMEK עם Apigee.

מניעת סיכונים

בשלב הזה, Apigee תומך בקבוצה מוגבלת של פונקציות של מפתחות הצפנה בניהול הלקוח (CMEK). כדי למנוע מחיקה בטעות של מפתחות CMEK או של גרסאות מפתח, מומלץ להטמיע את הפעולות הבאות:

  • הגבירו את בקרת הגישה: הגבילו את ההרשאות של התפקיד roles/cloudkms.admin או של מחיקה/עדכון מפתחות רק לאדמינים מהימנים או לחברי צוות בכירים.
  • ביצוע ביקורת על ההרשאות באופן קבוע: חשוב לוודא שההרשאות לא מתרחבות בטעות לאורך זמן.
  • מחיקת מפתחות אוטומטית: אל תגדירו אוטומציות למחיקה או להשבתה אוטומטית של מפתחות.

הגדרת משך הזמן להשמדת המפתח ורוטציה

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

רוטציית מפתחות ב-Apigee

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

דוגמאות להמחשה

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

מגבלה נוכחית: אין הצפנה מחדש אוטומטית

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

השבתת מפתח

השבתה או השמדה של מפתחות תשבש את הפונקציונליות של Apigee. אם משביתים את המפתח קודם, אפשר להפעיל אותו מחדש אם מדובר באזעקת שווא.

אם אתם חושדים שחלה פריצה למפתח (או לגרסת מפתח):

  • תרחיש בסיכון גבוה: אם לדעתכם הנתונים ב-Apigee רגישים ויש סיכוי גבוה שהאקר ינצל אותם, עליכם להשבית את המפתח ולבטל את הגישה אליו באופן מיידי. מומלץ להשבית את המפתח לפני שיוצרים מחדש מופע של apigee וארגון של apigee.
  • תרחיש עם סיכון נמוך: אם צמצום זמן ההשבתה חשוב יותר מהסיכון הפוטנציאלי, כדאי ליצור מחדש את מופע apigee ואת ארגון apigee לפני שמשביתים או מוחקים את CMEK. בהמשך מוסבר איך למנוע השבתה באופן יזום על ידי השקעה בגיבוי ובשחזור.
  • פנייה לתמיכה: מומלץ לפנות ל-Cloud Customer Care אם לדעתכם מפתח נפרץ ואתם צריכים להשבית אותו.

בהמשך מוסבר מה קורה כשמשביתים, מבטלים או מוחקים מפתח. אחרי השבתת המפתח, תצטרכו ליצור מחדש את apigee org/instances. שיטות מומלצות

  • פשרה של CMEK בזמן ריצה: יוצרים מופעים חדשים עם CMEK חדש, ואז מוחקים את המופעים המקוריים ואת ה-CMEK הישן בזמן הריצה אחרי העברת התעבורה.
  • פריצה לכל CMEK: יוצרים ארגון apigee חדש עם מפתח CMEK חדש, משכפלים את ההגדרה, מעבירים את התנועה, ואז משביתים או מוחקים את ה-CMEK המקורי.
  • פנייה אל Cloud Customer Care: אם לוקח הרבה זמן להשתמש ב-API למחיקה או ליצירה מחדש של מופעים או של apigee org, פנו אל Cloud Customer Care.

ההשפעה של השבתה, ביטול או השמדה של מפתח

השבתה, ביטול או השמדה של המפתח יגרמו ל-Apigee לא לפעול כראוי. אלה ההשפעות:

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

הפעלה מחדש של מקש

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

  • אם תקופת ההשבתה של המפתח קצרה: המערכת אמורה להתאושש, למעט אובדן נתונים מסוים באבטחת API ובניתוח נתונים.
  • אם תקופת ההשבתה של המפתח ארוכה: המערכת תתאושש ותחזור לשרת תנועה, אבל זה עלול לגרום לחוסר עקביות בנתונים, שבו אזור אחד מחזיר ערך אחד ואזור שהיה מושבת מחזיר ערך אחר. כדי לתקן את אשכול Apigee, צריך לפנות אל Cloud Customer Care.

מחיקת מפתח

לפני שמוחקים מפתח, כדאי לשקול את הנקודות הבאות:

הגנה על הארגון ב-Apigee באמצעות גיבויים של CI/CD

במקרה של פריצה למפתחות הצפנה בניהול הלקוח (CMEK), חשוב מאוד לפעול מיידית כדי להשבית, לבטל או להשמיד את המפתח שנפרץ. עם זאת, אמצעי האבטחה הזה עלול לגרום למערכת Apigee להפסיק לפעול, מה שיוביל להשבתה פוטנציאלית ולשיבושים בשירות.

כדי להבטיח זמן השבתה מינימלי או אפסי בשירותי Apigee, חשוב ליישם גישה פרואקטיבית: גיבויים רציפים של הגדרות הארגון (גיבויים של שילוב רציף/פריסה רציפה (CI/CD)). כדאי לעיין בכלים הזמינים ובשיטות המומלצות לשחזור ארגון Apigee.

העוצמה של CI/CD ו-IaC

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

כלים זמינים

אתם יכולים לשלב את כל הכלים הבאים כדי לגבות מעת לעת את הארגון שלכם ב-apigee ולבדוק את תהליך השחזור.

שיטות מומלצות

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

ייצוא או יצירה מחדש של ארגונים

הכלי apigeecli הוא כלי של שורת הפקודה שמאפשר לכם לנהל משאבים של Apigee. הוא מאפשר לכם לבצע את אותן פעולות כמו Apigee API בממשק שורת פקודה קל לשימוש, בדומה לפקודות gcloud.
אם רוצים ליצור מחדש ארגונים ב-Apigee או להעביר לארגון אחר ב-Apigee, אפשר להשתמש ב-apigeecli organizations export וב-apigeecli organizations import. אפשר להשתמש בו גם כבסיס לגיבויים שוטפים. אפשר לייצא ולייבא משאבים כמו:

  • מסמכי API portal
  • קטגוריות של פורטל API
  • ממשקי proxy ל-API
  • הגדרת אבטחה של API ופרופילי אבטחה
  • תהליכי עבודה משותפים
  • מוצרי API
  • מפתחים
  • אפליקציות למפתחים, כולל פרטי כניסה
  • AppGroups and Apps including credentials
  • פרטי הסביבה
  • קבוצות סביבות
  • הגדרת מכשירים לאיסוף נתונים
  • מאגרי מפתחות ואישורים עם כינוי ברמת הסביבה
  • שרתי יעד ברמת הסביבה
  • הפניות ברמת הסביבה
  • מפות מפתח/ערך (KVM) ורשומות ברמת הארגון, הסביבה וה-Proxy
  • מאגרי מפתחות ואישורים עם כינויים, למעט מפתחות פרטיים

הכלי יכול לנהל את כל המשאבים האחרים של Apigee. אפשר לראות את הרשימה המלאה של הפקודות באמצעות apigeecli tree.

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

  • כשיוצרים Keystore, צריך לשמור את המפתח הפרטי ולכלול אותו בקובצי הגיבוי המקומיים
  • לא תהיה אפשרות לגבות ולשחזר טוקנים של OAuth. המשמעות היא שלקוחות יצטרכו להתחבר מחדש למופעי Apigee חדשים שנוצרו.
  • אמצעי בקרת גישה כמו מדיניות ארגונית וכללי IAM לא מועברים. אם רוצים להעביר את הכללים האלה, צריך להשתמש ב- Google Cloud API.
  • אין תמיכה בייצוא של דוחות Analytics, ומדדים אנליטיים לא מועתקים לארגון החדש apigee.
  • הפקודה import הזו לא יוצרת באופן אוטומטי מופע, envGroup,‏ EnvAttachments,‏ endpoint attachment או פריסת פרוקסי בשבילכם. אתם יכולים לנהל את המשאבים האלה, אבל לא באופן ישיר באמצעות הפקודה import.
  • הפקודה import לא יוצרת באופן אוטומטי אתרים של פורטלים. צריך ליצור אתרי פורטל באופן ידני דרך ממשק המשתמש.
  • מומלץ להשקיע בשחזור אחרי אסון למחיקה של מפתחות, ולבדוק מעת לעת את תהליך השחזור כדי לוודא שאפשר להעביר את התנועה במהירות לארגוני Apigee שנוצרו לאחרונה.

דרישות מוקדמות

לפני שמתחילים, צריך לוודא שהתנאים המוקדמים הבאים מתקיימים:

  • ה-CLI של Apigee מותקן: מתקינים את apigeecli על ידי ביצוע השלבים ב מדריך ההתקנה.
  • אימות: אתם צריכים הרשאות ופרטי אימות כדי לבצע פעולות בארגונים של Apigee. צריך לוודא שהגדרתם:
    • ‫Google Cloud SDK ‏ (gcloud): מותקן ומאומת.
    • טוקן גישה: משיגים טוקן גישה באמצעות gcloud auth print-access-token.
  • גישה לרשת: מוודאים שהרשת מאפשרת גישה לממשקי ה-API של Apigee.
  • ‫Create org: יצירת ארגון apigee חדש שאליו רוצים להעביר את הנתונים. אפשר ליצור סוגים שונים של ארגוני apigee, אבל חשוב לוודא שמשתמשים באותו סוג של ארגון (תשלום לפי שימוש או מינוי) ובאותו סוג של ניתוב רשת שבו השתמשתם בארגון המקורי.

ייצוא של ארגון Apigee

בדוגמה הבאה מוצגת פקודה לדוגמה. פרטים על הדגלים השונים זמינים במאמר בנושא apigeecli organizations export. 

# Sample command
mkdir apigee_backup
cd apigee_backup

# gcloud auth application-default login
export ORG_FROM=REPLACE
apigeecli organizations export -o $ORG_FROM --default-token

ייבוא של ארגון Apigee

בדוגמה הבאה מוצגת פקודה לדוגמה. פרטים על הדגלים השונים זמינים במאמר בנושא apigeecli organizations import

# Sample command
# gcloud auth application-default login
export ORG_TO=REPLACE
apigeecli organizations import -o $ORG_TO -f . --default-token

שלבים אחרי הייבוא

יצירת מכונה והגדרת רשתות

כדי ליצור מכונה ולהגדיר רשתות:

  1. פועלים לפי השלבים במאמר בנושא יצירת מכונה חדשה כדי ליצור מכונה חדשה.
  2. הגדרת תעבורת נתונים צפונה: תעבורת נתונים צפונה מתייחסת לתעבורת נתונים של API מלקוחות חיצוניים או פנימיים אל Apigee דרך מאזן עומסים. צריך לוודא שהגדרתם את Private Service Connect או את ה-VPC בצורה נכונה כדי שהמופע יהיה נגיש. תצטרכו להגדיר שמות מארחים של קבוצת סביבות בארגון החדש.
  3. הגדרת תעבורת נתונים מדרום לצפון: מדרום לצפון מתייחס לתעבורת נתונים של API מ-Apigee לשירותי היעד של ה-proxy ל-API. לכן, צריך להזמין ולהפעיל כתובות IP חדשות עבור NAT, ולהגדיר מחדש את חומות האש או את רשימות ההיתרים בנקודות הקצה של היעד.

מידע נוסף זמין במאמר אפשרויות רשת ב-Apigee.

גיבוי/שחזור של הגדרות אחרות

כדי לגבות או לשחזר הגדרות אחרות, אפשר להשתמש באחת מהאפשרויות הבאות:

  • לכללי IAM: אפשר להשתמש ב gcloud projects get-iam-policy וב gcloud projects set-iam-policy כדי להעתיק את מדיניות ה-IAM שלכם, לשנות את הפרויקט ואת שם הארגון apigee, ולהחיל אותה על פרויקט חדש Google Cloud ועל ארגונים חדשים apigee.
  • לגבי הגדרות אחרות של Apigee: אפשר להשתמש ב-Apigee Management API.

פריסת שרתי ה-proxy

כדי לפרוס את ה-proxies, אפשר להשתמש באחת מהאפשרויות הבאות:

החלפת התנועה

כדי להעביר את התנועה:

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