שיטות מומלצות לשימוש ב-Secret Manager

במדריך הזה מפורטות כמה שיטות מומלצות לשימוש ב-Secret Manager. המדריך הוא רשימה חלקית של המלצות. לפני שתקראו את המדריך הזה, מומלץ לעיין בסקירה הכללית על הפלטפורמה כדי להבין את הסביבה הכוללת של Google Cloud ובסקירה הכללית על Secret Manager.

בקרת גישה

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

• הגבלת הבעלות על הארגון לחשבון סופר-אדמין מאובטח.

• מפלחים את האפליקציות והסביבות (staging או ייצור) לפרויקטים נפרדים, כמו שמתואר במאמר בחירה של היררכיית משאבים לאזור הנחיתה ב- Google Cloud Google Cloud. ההפרדה הזו יכולה לעזור לבודד סביבות עם קישור IAM ברמת הפרויקט, ולוודא שהמכסות נאכפות באופן עצמאי.

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

• אם סודות של הרבה שירותים נמצאים בפרויקט אחד, כדאי להשתמש בקישורים של IAM ברמת הסוד או בתנאים של IAM כדי להגביל את הגישה לקבוצת המשנה הנדרשת של הסודות.

• ‫IAM Recommender יכול לעזור לזהות קשרי IAM עם הרשאות עודפות.

נדרשים פרטי כניסה כדי לבצע אימות ל-Secret Manager API. כל ספריות הלקוח משתמשות באותה אסטרטגיה לחיפוש פרטי כניסה, שנקראת Application Default Credentials.

• בפיתוח מקומי, משתמשים ב- gcloud auth application-default login. כך נוצר קובץ עם פרטי כניסה שספריות הלקוח מאתרות באופן אוטומטי.

• ב-Compute Engine ובפלטפורמות מחשוב אחרות של Google Cloud כמו פונקציות של Cloud Run, ספריות הלקוח מקבלות פרטי כניסה דרך שרת המטא-נתונים של המכונה.

• ב-GKE, Workload Identity מספק גם פרטי כניסה באמצעות שירות מטא-נתונים.

• בפלטפורמות אחרות כמו Amazon Web Services או Microsoft Azure, כדאי להגדיר איחוד שירותי אימות הזהות של עומסי עבודה, שמשתמש במנגנוני זהות קיימים כדי לבצע אימות לממשקי API של Google Cloud .

כל השיטות האלה עדיפות על ייצוא פרטי כניסה של חשבון שירות, כי הן לא דורשות אחסון מאובטח של סוד נוסף וגישה אליו מחוץ ל-Secret Manager API.

שיטות תכנות

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

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

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

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

  • האם מאגר הנתונים מרחיב את הגישה לסוד?

  • האם אפשר לבדוק את הגישה לסוד?

  • האם מאגר הנתונים עומד בדרישות ההצפנה של נתונים במנוחה והחלוקה לאזורים?

מומלץ להשתמש ב-Secret Manager API ישירות באמצעות אחת מספריות הלקוח שסופקו, או באמצעות עיון במסמכי התיעוד של REST או של GRPC.

עם זאת, בשילובים מסוימים של מוצרים, כמו שילובים בלי שרת (serverless), אפשר להעביר סודות דרך מערכת הקבצים או דרך משתני סביבה. מידע נוסף זמין במאמר בנושא שימוש ב-Secret Manager עם מוצרים אחרים.

ניהול

כשיוצרים סודות, מומלץ לבחור את מדיניות השכפול האוטומטי, אלא אם לעומס העבודה יש דרישות ספציפיות לגבי מיקום (שאפשר לאכוף באמצעות האילוץ constraints/gcp.resourceLocations).

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

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

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

חשוב להחליף את הסודות שלכם באופן קבוע כדי:

• הגבלת ההשפעה במקרה של סוד שנחשף.

• חשוב לוודא שאנשים שכבר לא צריכים גישה לסוד לא יוכלו להמשיך להשתמש בסוד שהייתה להם גישה אליו בעבר.

• הפחתת הסבירות להשבתה.

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

• עוזר לזהות סודות בכל הארגון.

• זיהוי אי-התאמה לדרישות הארגון, כמו רוטציה, הגדרת הצפנה ומיקום.

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

בנוסף לאמצעי הבקרה של IAM, אפשר להגביל את הגישה ל-Secret Manager API באמצעות אמצעי בקרה מבוססי-רשת על ידי הגדרת service perimeter של VPC Service Controls לארגון.

אפשר להשתמש במדיניות הארגון constraints/iam.allowedPolicyMemberDomains כדי להגביל את הזהויות שאפשר להוסיף למדיניות IAM עבור סודות.

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

תאימות למיקום הנתונים

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