מפתח גישה של AWS הוא שתי מחרוזות שיחד מאפשרות לתוכנה לפעול בשם משתמש IAM: מזהה מפתח הגישה (access key ID), שמזהה את המפתח, ומפתח הגישה הסודי (secret access key), שמוכיח שהמפתח בידיכם. אנשים מחפשים אותם בשלושה שמות, access key and secret key, secret access key או פשוט AWS secret key, וכולם מתייחסים לאותו זוג. הזוג הזה מופיע בהגדרות CLI, בצינורות CI ולעיתים קרובות מדי גם בהודעת Slack.
המדריך מסביר מה הם שני החלקים, איך יוצרים ומגדירים אותם, איך מחליפים אותם בלי השבתה ומה עושים כשאחד מהם דולף. הוא עונה גם על השאלה שעולה בכל פעם שמתכנת מצטרף או קבלן מתחיל לעבוד: איך מוסרים מפתח סודי לאדם בלי לשלוח אותו באימייל.
מזהה מפתח הגישה לעומת מפתח הגישה הסודי
| מזהה מפתח הגישה | מפתח הגישה הסודי | |
|---|---|---|
| איך הוא נראה | AKIAIOSFODNN7EXAMPLE (20 תווים) | 40 תווים של אותיות גדולות וקטנות וסמלים |
| תפקיד | מזהה איזה מפתח חותם על הבקשה | חותם על הבקשה ומוכיח שהמפתח בידיכם |
| סודי? | לא, התייחסו אליו כמו לשם משתמש | כן, התייחסו אליו כמו לסיסמה |
| אפשר לראות אותו אחר כך? | כן, בקונסולת IAM | לא, אף פעם אחרי היצירה |
מפתחות לטווח ארוך מתחילים ב-AKIA. פרטי התחברות זמניים מ-STS, שמגיעים גם עם טוקן סשן, מתחילים ב-ASIA ותוקפם פג מעצמו. אם מופיע מפתח ASIA בקובץ הגדרות, הוא יפסיק לעבוד תוך שעות, וכך זה תוכנן.
אף אחד משני החלקים לא מעניק הרשאות. המפתח מזדהה כמשתמש IAM, והמדיניות (policies) שמצורפת למשתמש קובעת מה הזהות הזו יכולה לעשות. דליפה של מפתח ששייך למשתמש עם הרשאות קריאה בלבד היא בעיה. דליפה של מפתח של אדמיניסטרטור היא אירוע אבטחה.
מתי בכלל צריך מפתח לטווח ארוך
בכנות: פחות ממה שנדמה.
- עומסי עבודה ב-AWS (EC2, Lambda, ECS, EKS) צריכים להשתמש בתפקידי IAM (IAM roles). ה-SDK טוען פרטי התחברות קצרי מועד באופן אוטומטי, ואין מה להחליף או להדליף.
- אנשים צריכים להתחבר דרך IAM Identity Center או SSO מאוחד ולקבל פרטי התחברות זמניים מ-
aws sso login. - מערכות CI כמו GitHub Actions יכולות לקבל תפקיד (assume role) דרך OIDC, בלי מפתח שמור.
- מפתחות לטווח ארוך נשארים למקרים שבהם אף אחת מהאפשרויות האלה לא עובדת: כלי במחשב נייד שלא תומך ב-SSO, שירות צד שלישי שמקבל רק מפתחות קבועים, משימה ישנה שעוד לא הועברה.
אם בכל זאת צריך מפתח כזה, צרו אותו על משתמש IAM ייעודי עם המדיניות המצומצמת ביותר שמספיקה למשימה, ואף פעם לא על חשבון אדמיניסטרטור של אדם.
יצירה והגדרה של מפתח
בקונסולת IAM פתחו את המשתמש, בחרו "Security credentials" ואז "Create access key". בחרו את תרחיש השימוש ש-AWS שואל עליו, קראו את החלופה שהוא מציע והמשיכו. הסוד מוצג פעם אחת בלבד. שמרו אותו מיד במאגר הסודות או במנהל הסיסמאות, או הורידו את קובץ ה-CSV ומחקו אותו אחרי הייבוא. לכל משתמש IAM יכולים להיות לכל היותר שני מפתחות בו-זמנית, וזה מה שמאפשר להחליף מפתחות.
במחשב, הגדירו פרופיל עם שם ולא את פרופיל ברירת המחדל:
aws configure --profile deploy-tool
# AWS Access Key ID [None]: AKIA...
# AWS Secret Access Key [None]: ...
# Default region name [None]: eu-west-1
הפקודה כותבת את ~/.aws/credentials ואת ~/.aws/config. הגבילו את הקובץ למשתמש שלכם עם chmod 600. בקונטיינרים וב-CI, הזריקו את AWS_ACCESS_KEY_ID ואת AWS_SECRET_ACCESS_KEY כסודות ממאגר הסודות של הפלטפורמה, לא כמשתנים רגילים בקובץ YAML. ואף פעם אל תעבירו אותם בשורת הפקודה, שם הם נשמרים בהיסטוריה של ה-shell.
החלפה בלי לשבור שום דבר
ההחלפה היא תהליך של ארבעה שלבים, והמגבלה של שני מפתחות היא מה שמאפשר אותו.
- צרו מפתח שני על אותו משתמש.
- עדכנו כל מקום שמשתמש במפתח כך שישתמש במפתח החדש: קובצי הגדרות, סודות CI, הרשומה במנהל הסודות. קונסולת IAM מציגה לכל מפתח מתי השתמשו בו לאחרונה, וכך אפשר לראות אם פספסתם מקום.
- השביתו את המפתח הישן. חכו יום או מחזור פריסה אחד. אם משהו נשבר, הפעילו אותו מחדש, תקנו את המקום שמשתמש בו ונסו שוב.
- מחקו את המפתח הישן כששום דבר כבר לא משתמש בו.
עשו את זה לפי לוח זמנים קבוע למפתחות שחייבים להתקיים, ולכל המפתחות גם בעקבות אירועים: עובד שעוזב, החלפת ספק, מחשב נייד שאבד, חשד לדליפה. AWS Config ו-IAM Access Analyzer יכולים לסמן מפתחות ישנים יותר ממה שהמדיניות שלכם מתירה.
כשמפתח נחשף
מפתח שהופיע במאגר קוד, בקובץ לוג, בכרטיס תמיכה או בצ'אט נחשב פרוץ, גם אם נמחק דקה אחר כך. סורקים מוצאים סודות שנדחפו למאגר תוך שניות.
- השביתו את המפתח ב-IAM עכשיו. אל תחכו קודם ליצירת מפתח חלופי, אלא אם השבתת השירות תזיק יותר מהחשיפה.
- צרו מפתח חלופי ועדכנו את המקומות שמשתמשים בו.
- עברו על CloudTrail ובדקו כל פעולה שבוצעה עם מזהה מפתח הגישה הזה מאז החשיפה. חפשו משתמשי IAM או מפתחות חדשים, מכונות (instances) חדשות, שינויים במדיניות של buckets ואזורים (regions) לא מוכרים.
- בדקו את החשבונית ואת Cost Explorer וחפשו קפיצות שנראות כמו כריית מטבעות קריפטו.
- הסירו את הסוד מהקוד, מהלוגים ומהיסטוריית git. כש-AWS מזהה דליפה ציבורית, הוא עשוי לצרף בעצמו את המדיניות
AWSCompromisedKeyQuarantineלמשתמש. השאירו אותה במקומה עד שהניקוי יסתיים. - מחקו את המפתח הישן, ואז בררו איך הוא הגיע לשם וסגרו את הדרך הזו.
איך משתפים מפתח סודי של AWS עם אדם
לפעמים המפתח צריך להגיע לאדם: קבלן שצריך אותו לכלי פריסה, מתכנת שמצטרף לפרויקט לפני שהוגדר SSO, אינטגרציה עם ספק שמבקשת להדביק אותו בלוח הבקרה שלו. אימייל, Slack וכרטיסי תמיכה שומרים עותקים, וסוד באורך 40 תווים שנמצא באחד מהם אפשר לקרוא במשך שנים.
השגרה הבטוחה לוקחת דקה:
- צרו מפתח לאותו אדם על משתמש IAM ייעודי, עם המדיניות שהמשימה שלו דורשת ולא יותר. אל תשתפו מפתח שמשהו אחר משתמש בו.
- הדביקו רק את מפתח הגישה הסודי בקישור סודי חד-פעמי. הוא מוצפן בדפדפן שלכם לפני שהוא נשמר, העותק השמור מושמד בפעם הראשונה שפותחים את הקישור, ואם אף אחד לא פותח אותו, תוקף הקישור פג אחרי שעה, יום או שבוע.
- שלחו את הקישור עם שורת הסבר אחת. את מזהה מפתח הגישה, האזור ושם הפרופיל שלחו בהודעה נפרדת. אף אחד מהם אינו סודי בפני עצמו.
- הוסיפו ביטוי סיסמה בחשבון Pro לכל מה שמעבר להרשאות קריאה בלבד, ומסרו אותו בהודעת SMS או בשיחה.
- ודאו שהנמען פתח את הקישור. אם הקישור מציין שכבר צפו בו והנמען לא פתח אותו, השביתו את המפתח והתחילו מחדש.
- השביתו את המפתח כשההתקשרות מסתיימת, ואחר כך מחקו אותו.
המדריך לשיתוף מפתחות API מציג את אותו דפוס לספקים אחרים, והמדריך שיתוף קישורים מאובטח למפתחים מסביר איך לכתוב סקריפט למסירה בתהליך הקליטה של עובדים חדשים.