streamalism.org

1. סקירה כללית

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

הנושאים העיקריים שנעסוק בהם כוללים:

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

2. הבעיה במידע רגיש

לפני שנעמיק בכספת, בואו ננסה להבין את הבעיה שהיא מנסה לפתור: ניהול מידע רגיש.

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

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

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

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

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

אז מה אנו יכולים לעשות? בוא נקמר את זה!

3. מה זה קמרון?

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

Hashicorp מציעה שתי גרסאות של Vault. גרסת הקוד הפתוח, המשמשת במאמר זה, היא חופשית לשימוש, גם בסביבות מסחריות. קיימת גם גרסה בתשלום הכוללת תמיכה טכנית ב- SLA שונים ותכונות נוספות, כגון תמיכה ב- HSM (Hardware Security Module).

3.1. אדריכלות ותכונות עיקריות

הארכיטקטורה של הכספת היא פשוט מטעה. המרכיבים העיקריים שלה הם:

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

על ידי האצלת כל הטיפול הסודי בכספת, אנו יכולים להקל על כמה בעיות אבטחה:

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

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

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

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

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

3.2. אימות

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

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

הכספת תומכת גם במנגנוני אימות אחרים כגון LDAP, JWT, אישורי TLS, בין היתר. כל המנגנונים הללו נבנים על גבי מנגנון האסימונים הבסיסי: ברגע ש- Vault מאמת את הלקוח שלנו, הוא יספק אסימון שבו נוכל להשתמש כדי לגשת לממשקי API אחרים.

לטוקנים יש כמה מאפיינים המשויכים אליהם. המאפיינים העיקריים הם:

• קבוצה של קשורים מדיניות (ראה סעיף הבא)
• זמן לחיות
• אם אפשר לחדש את זה
• ספירת שימוש מרבית

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

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

3.3. מדיניות

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

נתיב "סודי / חשבונאי" {יכולות = ["קרא"]}

כאן השתמשנו בתחביר HCL (שפת התצורה של Hashicorp) כדי להגדיר את המדיניות שלנו. Vault תומך גם ב- JSON למטרה זו, אך אנו נצמד ל- HCL בדוגמאות שלנו מכיוון שקל יותר לקרוא אותו.

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

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

המדיניות שתוארה עד כה נקראת גם מדיניות רשימת בקרת גישה, או מדיניות ACL. הכספת תומכת גם בשני סוגי מדיניות נוספים: מדיניות EGP ו- RGP. אלה זמינים רק בגרסאות בתשלום ומרחיבים את תחביר המדיניות הבסיסי עם תמיכה בסנטינל.

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

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

4. סוגי סוד

הכספת תומכת במגוון סוגים סודיים שונים העוסקים במקרי שימוש שונים:

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

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

• א הרנְקוּדָה, המגדיר את קידומת ה- REST API שלו
• מערך פעולות שנחשף דרך ה- API המתאים
• קבוצה של פרמטרים לתצורה

ניתן להגיע למופע סודי נתון באמצעות נָתִיב, בדומה לעץ ספריות במערכת קבצים. המרכיב הראשון בנתיב זה תואם ל- נקודת הר שם נמצאים כל הסודות מסוג זה.

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

4.1. סודות ערך-מפתח

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

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

הכספת תומכת בשלושה סוגים של סודות ערך מפתח:

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

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

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

4.2. סודות שנוצרו באופן דינמי

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

• אישורי מסד נתונים
• זוגות מפתח SSH
• תעודות X.509
• אישורי AWS
• חשבונות שירות ענן גוגל
• חשבונות Active Directory

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

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

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

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

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

4.3. מפתחות קריפטוגרפיים

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

ה- API המשויך מאפשר ללקוחות לשלוח נתוני טקסט רגיל של Vault ולקבל גרסה מוצפנת שלהם. ההפך אפשרי גם: אנו יכולים לשלוח נתונים מוצפנים ולקבל בחזרה את הטקסט המקורי.

נכון לעכשיו, יש רק מנוע אחד מסוג זה: מַעֲבָר מנוע. מנוע זה תומך בסוגי מפתחות פופולריים, כגון RSA ו- ECDSA, וגם תומך הצפנה מתכנסת. בעת שימוש במצב זה, ערך טקסט רגיל נתון תמיד יביא לאותה תוצאת cyphertext, מאפיין שימושי מאוד ביישומים מסוימים.

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

5. הגדרת הכספת

בחלק זה ניצור סביבת בדיקה מקומית ולכן נבדוק את יכולות הכספת.

הפריסה של הכספת פשוטה: פשוט הורידו את החבילה המתאימה למערכת ההפעלה שלנו וחילצו את הפעלה שלה (כספת אוֹ vault.exe ב- Windows) לספרייה כלשהי ב- PATH שלנו. הפעלה זו מכילה את השרת והיא גם הלקוח הסטנדרטי. יש גם תמונה רשמית של Docker, אך לא נסקור אותה כאן.

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

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

5.1. הפעלת שרת הכספת

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

אחסון "קובץ" {path = "./vault-data"} מאזין "tcp" {address = "127.0.0.1:8200" tls_cert_file = "./src/test/vault-config/localhost.cert" tls_key_file = ". /src/test/vault-config/localhost.key "}

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

שרת הכספת $ -config ./vault-test.hcl

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

5.2. אתחול הכספת

שרת הכספת שלנו פועל כעת, אך מכיוון שזו הריצה הראשונה שלו, עלינו לאתחל אותו.

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

$ export VAULT_ADDR = // localhost: 8200 $ export VAULT_CACERT =. / src / test / vault-config / localhost.cert $ initial vault operator

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

• VAULT_ADDR: URI בסיסי בו שרת ה- API שלנו יגיש בקשות
• VAULT_CACERT: נתיב למפתח הציבורי של אישורי השרת שלנו

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

לאחר הנפקת הפקודה הנ"ל, עלינו לראות הודעה כזו:

מפתח אטום 1: מפתח אטום 2: מפתח 3 לא אטום: מפתח 4 ללא אטום: מפתח אטום 5: אסימון שורש ראשוני: ... הודעות נוספות הושמטו

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

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

$ export VAULT_TOKEN = (יוניקס / לינוקס)

בואו נראה את סטטוס השרת שלנו כעת לאחר שאותחלנו אותו, עם הפקודה הבאה:

סטטוס הכספת $ ערך מפתח --- ----- סוג חותם shamir אטום נכון סך הכל מניות 5 סף 3 התקדמות לא אטום 0/3 לא אטום לא חובה לא גרסה 0.10.4 HA מופעל כוזב

אנו יכולים לראות כי הכספת עדיין אטומה. אנו יכולים גם לעקוב אחר ההתקדמות הבלתי סגורה: "0/3" פירושו כי הכספת זקוקה לשלוש מניות, אך לא קיבלה עד כה. בוא נתקדם ונספק לו את המניות שלנו.

5.3. קמרון לא אטום

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

מפעיל $ הכספת unseal $ הכספת מפעיל unseal $ הכספת unseal 

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

ערך מפתח --- ----- סוג חותם שמיר אטום כוזב ... נכסים אחרים הושמטו

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

6. בדיקת קמרון

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

6.1. שימוש בסודות מפתח / ערך

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

$ vault kv put secret / fakebank api_key = abc1234 api_secret = 1a2b3c4d

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

$ vault kv get secret / fakebank ======= נתונים ======= ערך מפתח --- ----- api_key abc1234 api_secret 1a2b3c4d 

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

6.2. יצירת אסימונים חדשים

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

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

אסימון הכספת $ ליצור -ttl 1m ערך מפתח --- ----- אסימון token_accessor token_duration 1m token_renewable token_policies ["שורש"] מדיניות זהות [] מדיניות ["root"]

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

$ export VAULT_TOKEN = $ vault kv get secret / fakebank ======= Data ======= ערך מפתח --- ----- api_key abc1234 api_secret 1a2b3c4d

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

$ vault kv get secret / fakebank שגיאה בהגשת בקשת API. כתובת אתר: GET // localhost: 8200 / v1 / sys / internal / ui / mounts / secret / fakebank קוד: 403. שגיאות: * הרשאה נדחתה

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

6.3. מדיניות בדיקה

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

לדוגמה, בואו נגדיר מדיניות המאפשרת רק גישה לקריאה ל- סוד / פאקבנק נתיב שהשתמשנו בו בעבר:

$ cat> sample-policy.hcl <

כעת אנו יוצרים אסימון עם מדיניות זו עם הפקודה הבאה:

$ export VAULT_TOKEN = $ אסימון הכספת ליצור -מדיניות = fakebank-ro ערך מפתח --- ----- אסימון token_accessor token_duration 768h token_renewable token_policies ["default" "fakebank-ro"] policies_policies [] default ["default" " fakebank-ro "]

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

$ export VAULT_TOKEN = $ vault kv get secret / fakebank ======= Data ======= ערך מפתח --- ----- api_key abc1234 api_secret 1a2b3c4d

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

$ vault kv put secret / fakebank api_key = foo api_secret = bar שגיאה בכתיבת נתונים לסוד / fakebank: שגיאה בהגשת בקשת API. URL: PUT //127.0.0.1:8200/v1/secret/fakebank קוד: 403. שגיאות: * הרשאה נדחתה

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

6.4. באמצעות אישורי מסד נתונים דינמי

כדוגמה האחרונה שלנו במאמר זה, בואו נשתמש במנוע הסודי של מסד הנתונים של הכספת בכדי ליצור אישורים דינמיים. אנו מניחים כאן שיש לנו שרת MySQL זמין באופן מקומי ושאנחנו יכולים לגשת אליו עם הרשאות "שורש". נשתמש גם בסכמה מאוד פשוטה המורכבת מטבלה אחת - חֶשְׁבּוֹן .

סקריפט SQL המשמש ליצירת סכמה זו והמשתמש המורשה זמין כאן.

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

סודות הכספת $ מאפשרים הצלחה במסד נתונים! אפשר את מנוע סודות מסד הנתונים בכתובת: database /

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

$ vault write database / config / mysql-fakebank \ plugin_name = mysql-legacy-database-plugin \ connection_url = "{{username}}: {{password}} @ tcp (127.0.0.1:3306) / fakebank" \ allow_roles = "*" \ username = "fakebank-admin" \ password = "Sup & rSecre7!"

קידומת הנתיב מסד נתונים / תצורה זה המקום שבו יש לאחסן את כל תצורות מסד הנתונים. אנו בוחרים את השם mysql-fakebank כך שנוכל להבין לאיזה בסיס נתונים תצורה זו מתייחסת. באשר למפתחות התצורה:

• תוסף_שם: מגדיר באיזה תוסף מסד נתונים ישמש. שמות התוספים הזמינים מתוארים במסמכי הכספת
• חיבור_סיבוב: זו תבנית המשמשת את התוסף בעת התחברות למסד הנתונים. שימו לב למקומות המיקום של התבנית {{username}} ו- {{password}}. בעת התחברות למסד הנתונים, Vault יחליף את אותם מצייני מיקום בערכים בפועל
• מותר_רולס: הגדר אילו תפקידי Vault (שנדון בהמשך) יוכלו להשתמש בתצורה זו. במקרה שלנו אנו משתמשים ב- "*", כך שהוא זמין לכל התפקידים
• שם משתמש סיסמא: זהו החשבון בו Vault ישתמש לביצוע פעולות בסיס נתונים, כגון יצירת משתמש חדש וביטול הרשאותיו

הגדרת תפקיד מסד הנתונים של הכספת

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

כאן אנו יוצרים תפקיד המעניק גישה לקריאה בלבד לכל הטבלאות של ה- בנק בנק סכֵימָה:

$ vault לכתוב מסד נתונים / תפקידים / fakebank-accounts-ro \ db_name = mysql-fakebank \ creation_statements = "צור משתמש '{{name}}' @ '%' מזוהה על ידי '{{password}}'; בחר בחירה ב- fakebank. * לקרוא בשם}}'@'%';" 

מנוע מסד הנתונים מגדיר את קידומת הנתיב מסד נתונים / תפקידים כמיקום לאחסון תפקידים. fakebank-accounts-ro הוא שם התפקיד בו נשתמש בהמשך בעת יצירת אישורים דינמיים. אנו מספקים גם את המפתחות הבאים:

• db_name: שם תצורת מסד נתונים קיימת. תואם את החלק האחרון של הנתיב בו השתמשנו בעת יצירת משאב התצורה
• היצירה_סטטוסים: רשימה של תבניות משפט SQL בהן Vault ישתמשו ליצירת משתמש חדש

יצירת אישורים דינמיים

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

בסיס נתונים לקרוא $ vault / creds / fakebank-accounts-ro ערך מפתח --- ----- lease_id database / creds / fakebank-accounts-ro / 0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4 lease_duration 1h שם משתמש סיסמה אמיתית חכירה חוזרת 

ה מסד נתונים / זיכויים הקידומת משמשת ליצירת אישורים לתפקידים הזמינים. מאז השתמשנו ב- fakebank-accounts-ro תפקיד, שם המשתמש / הסיסמה שהוחזר יוגבל ל בחר פעולות.

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

$ mysql -h 127.0.0.1 -u -p fakebank הזן סיסמה: MySQL [fakebank]> בחר * מחשבון; ... הושמט בקיצור 2 שורות בערכה (0.00 שניות) MySQL [fakebank]> מחק מחשבון; שגיאה 1142 (42000): הפקודה DELETE נדחתה למשתמש 'v-fake-9xoSKPkj1' @ 'localhost' עבור חשבון 'שולחן' 

אנחנו יכולים לראות את זה בחר הושלם בהצלחה, אך לא הצלחנו לבצע את לִמְחוֹק הַצהָרָה. לבסוף, אם נמתין שעה אחת וננסה להתחבר באמצעות אותם אישורים, לא נוכל להתחבר יותר למסד הנתונים. הכספת ביטלה באופן אוטומטי את כל ההרשאות ממשתמש זה

7. מסקנה

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

בהמשך הדרך יצרנו סביבת בדיקה פשוטה אך פונקציונאלית בה נשתמש במאמרי המשך.

המאמר הבא יעסוק במקרה שימוש ספציפי מאוד עבור Vault: שימוש בו בהקשר של יישום Spring Boot. המשך לעקוב!