מקשי HMAC

הגדרה

בדף הזה מוסבר על מפתחות של קוד אימות הודעות (HMAC) מבוססי-גיבוב (hash), שאפשר להשתמש בהם כדי לאמת בקשות ב-Cloud Storage XML API. מפתחות HMAC שימושיים כשרוצים להעביר נתונים בין Cloud Storage לבין ספקי שירותי אחסון בענן אחרים, כי מפתחות HMAC מאפשרים להשתמש שוב בקוד קיים כדי לגשת ל-Cloud Storage.

סקירה כללית

מפתח HMAC הוא סוג של פרטי כניסה שמשויכים לחשבון, בדרך כלל לחשבון שירות. משתמשים במפתח HMAC כדי ליצור חתימות באמצעות אלגוריתם החתימה HMAC-SHA256. החתימות שיוצרים נכללות בבקשות ל-API בפורמט XML של Cloud Storage. החתימות מוכיחות שבקשה מסוימת אושרה על ידי החשבון שמשויך למפתח ה-HMAC.

למפתחות HMAC יש שני חלקים עיקריים, מזהה גישה וסוד.

  • מזהה הגישה: זוהי מחרוזת אלפאנומרית שמקושרת לחשבון ספציפי.

    • כשהמחרוזת מקושרת לחשבון שירות היא תהיה באורך של 61 תווים.

    • כשהמחרוזת מקושרת לחשבון משתמש היא תהיה באורך 24 תווים.

    כך נראה מזהה גישה לדוגמה:

    GOOGTS7C7FUP3AIRVJTE2BCDKINBTES3HC2GY5CBFJDCQ2SYHV6A6XXVTJFSA

  • סוד: הסוד מורכב ממחרוזת בקידוד Base-64 באורך 40 תווים והוא מקושר למזהה הגישה הספציפי. הסוד הוא מפתח ששותף מראש שידוע רק לכם ול-Cloud Storage. הסוד משמש ליצירת חתימות כחלק מתהליך האימות. כך נראה סוד לדוגמה:

    bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ

גם מזהה הגישה וגם הסוד משמשים בתור מזהים ייחודיים של מפתח HMAC, אבל הסוד הוא מידע רגיש הרבה יותר כי הוא משמש ליצירת חתימות.

אפשר גם להפעיל את האילוץ restrictAuthTypes במשאב, כדי להגביל את הגישה לבקשות שנחתמו על ידי מפתחות HMAC.

אחסון הסודות

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

כדי ליצור מפתח HMAC לחשבון משתמש, אתם צריכים להיות מחוברים למסוףGoogle Cloud באמצעות חשבון המשתמש, ולעבור אל הכרטיסייה Interoperability מתוך התפריט Settings של הפרויקט ב-Cloud Storage. צריכה להיות לכם הרשאת IAM‏ resourcemanager.projects.get בפרויקט הזה. אחרי שיצרתם את המפתח, תוכלו לראות את הסוד של המפתח בכרטיסייה Interoperability בפרויקטים שבהם יש לכם את ההרשאה resourcemanager.projects.get.

שיטות מומלצות לאחסון סודות

  • אל תשתפו את הסוד של מפתח ה-HMAC. עליכם להתייחס לסודות של מפתחות HMAC כמו לפרטי כניסה של גישה.

  • השיטה המומלצת לשמירה על האבטחה היא להחליף את המפתחות באופן קבוע כחלק מרוטציית מפתחות.

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

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

הגבלות

  • אפשר להשתמש במפתחות HMAC רק כדי לשלוח בקשות ל-API ל-XML. אי אפשר להשתמש בהם ב-API ל-JSON.

  • לכל חשבון שירות אפשר ליצור עד 10 מפתחות HMAC. המגבלה הזאת לא כוללת מפתחות שנמחקו.

  • אחרי שיוצרים מפתח HMAC לחשבון שירות, יכולות לחלוף עד 60 שניות לפני שאפשר יהיה להשתמש בו. אחרי מחיקה של חשבון שירות, יכול להיות שמפתחות ה-HMAC ששייכים לו ימשיכו לפעול למשך עד 5 דקות. לעומת זאת, יכולות לחלוף עד 5 דקות לפני שאפשר יהיה להשתמש שוב במפתחות HMAC אחרי ביטול המחיקה של חשבון השירות שבבעלותו הם נמצאים.

  • אם מפעילים את האילוץ restrictAuthTypes במשאב, אי אפשר יותר ליצור או להפעיל מפתחות HMAC במשאב הזה לסוג החשבון שצוין.

העברה ממפתחות HMAC של חשבונות משתמשים

באופן כללי, עדיף לעבוד עם מפתחות HMAC שמשויכים לחשבונות שירות מאשר לשייך אותם לחשבונות משתמשים, במיוחד בעומסי עבודה של סביבת ייצור:

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

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

אם אתם משתמשים כרגע במפתחות HMAC של חשבונות משתמשים, אבל אתם רוצים לעבור לחשבונות שירות, חשוב לזכור:

  • לפרויקט שלכם צריך להיות חשבון שירות עם מפתח HMAC שמשויך אליו.

  • צריך לתת לחשבון השירות את ההרשאות הנדרשות כדי לבצע פעולות ב-Cloud Storage.

    התפקיד Storage Object Admin כולל הרשאה רחבה לעבודה עם אובייקטים, אבל יכול להיות שתרצו להשתמש בחשבונות שירות נפרדים לביצוע פעולות שונות. למשל, יכול להיות שחשבון שירות אחד ישמש לקריאה עם התפקיד Storage Object Viewer, וחשבון שירות נוסף ישמש לכתיבה עם התפקיד Storage Object Creator.

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

  • אחרי שסביבת הייצור עוברת לעבוד עם מפתחות HMAC של חשבונות שירות באופן מלא, כדאי לבדוק את המדד של Cloud Monitoring שמופיע למטה כדי לאמת שמפתחות ה-HMAC שמשויכים לחשבון המשתמש כבר לא בשימוש:

    מדד תיאור
    storage.googleapis.com/authn/authentication_count כמה פעמים נעשה שימוש במפתחות HMAC לאימות בקשות.

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

    • ‫access_id: זהו מזהה הגישה ששלח את הבקשה אתם יכולים להשתמש ב-access_id במהלך רוטציית המפתחות כדי לפקח על המעבר ממפתח אחד למפתח אחר.

    • ‫authentication_method: מזהה אם המפתחות הם מפתחות של חשבון משתמש או של חשבון שירות

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

  • אם אתם לא משתמשים יותר בחשבון המשתמש כדי לגשת למשאבי Cloud Storage, עליכם לבטל את אפשרות הגישה שלו ל-Cloud Storage.

  • אתם יכולים גם להפעיל את האילוץ restrictAuthTypes במפתחות HMAC של חשבונות משתמשים, וכך ליהנות משכבת אבטחה נוספת.

המאמרים הבאים