שיטות מומלצות לשימוש ב-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: אם הפעולה של מחיקה או יצירה מחדש של מופעים או של apigee org נמשכת זמן רב מאוד, פנו אל Cloud Customer Care.

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

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

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

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

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

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

מחיקת מפתח

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

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

הגנה על הארגון ב-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
  • מפתחים
  • אפליקציות למפתחים, כולל פרטי כניסה
  • קבוצות של אפליקציות ואפליקציות, כולל פרטי כניסה
  • פרטי הסביבה
  • קבוצות סביבות
  • הגדרת כלי איסוף נתונים
  • מאגרי מפתחות ואישורים עם כינוי ברמת הסביבה
  • שרתי יעד ברמת הסביבה
  • הפניות ברמת הסביבה
  • מפות מפתח/ערך (KVM) ורשומות ברמת הארגון, הסביבה וה-Proxy
  • מאגרי מפתחות ואישורים עם כינויים, למעט מפתחות פרטיים

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

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

  • כשיוצרים Keystore, צריך לשמור את המפתח הפרטי ולכלול אותו בקובצי הגיבוי המקומיים.
  • לא תהיה אפשרות לגבות ולשחזר טוקנים של OAuth. המשמעות היא שלקוחות יצטרכו להתחבר מחדש למופעי Apigee חדשים שנוצרו.
  • אמצעי בקרת גישה כמו מדיניות ארגונית וכללי IAM לא מועברים. אם רוצים להעביר את הכללים האלה, צריך להשתמש ב- Google Cloud API.
  • אין תמיכה בייצוא של דוחות Analytics, ומדדים אנליטיים לא מועתקים לארגון החדש apigee.
  • הפקודה import לא יוצרת באופן אוטומטי מופע, envGroup,‏ EnvAttachments,‏ נקודת הקצה של הקישור או פריסת פרוקסי בשבילכם. אתם יכולים לנהל את המשאבים האלה, אבל לא באופן ישיר באמצעות הפקודה 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 לשירותי היעד של ה-API proxy. לכן, צריך להזמין ולהפעיל כתובות 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. מגדירים מאזן עומסים כדי להעביר את תעבורת הנתונים בהדרגה למופע החדש, תוך מעקב אחר הביצועים.