« לעמוד הראשי

הסבר על HashiCorp Vault

בסרטון זה, Armon Dadgar, מייסד חברת HashiCorp וה- CTO המשותף, מספק מבוא ל- Vault וכיצד המערכת פועלת.

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

תרגום (Transcription)

היום אני רוצה להשקיע קצת זמן בשיחה על Vault של HashiCorp.

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

מהם הסודות שלכם?

כשאנחנו מדברים על ניהול סודות, מה שאנחנו באמת מדברים עליו זה מה שיעניק אותנטיקציה (authentication) או הרשאות (authorization). כוונתנו היא כל דבר שעשוי להעניק לך אימות למערכת או הרשאה למערכת. כמה דוגמאות לכך יכולות להיות שמות משתמש וסיסמאות (passwords). זה יכול להיות למשל אישורי כניסה ל- databases וזה יכול להיות דברים כמו API tokens, או שזה יכול להיות למשל תעודות TLS .

העניין הוא שנצטרך את הנ"ל כדי להכנס למערכת ולהזדהות (כמו username/password) , או שנשתמש בזה כדי לאמת זהות (כמו TLS certificate) – כך שאנחנו משתמשים בנ"ל כדי לאשר גישה למערכת.

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

כאשר אנו מסתכלים מסביב כיצד הדברים הללו מנוהלים כיום בפועל, אנו רואים התפשטות של סודות. הכוונה היא שהסודות מגיעים בסופו של דבר לכל מקום: הם נמצאים בטקסט רגיל (plain text) שנמצא בתוך קוד המקור שלנו, או פשוט נמצא בקובץ הגדרות/ header בצורה של "hard-coded". וזה גם בתוך קבצי קונפיגורציה (configuration management).

אז זה נמצא ב- cleartext, ב- Chef, Puppet, Ansible ודומיהם, כך שכל אחד יכול להיכנס ולראות מה האישורים האלה. ואז זה נכנס למערכת ניהול התצורה/גירסאות (version control) ומגיע אל מערכות כמו GitHub, או GitLab, או Bitbucket –  כך שזה מתפזר בכל התשתית שלנו!

מהם האתגרים כאן?

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

<<>>

גם אם הם היו יכולים לעשות זאת, איננו יודעים אם כבר עשו זאת. אין לנו רישום וביקורת (audit trail) שאומר רק בגלל שאני, Armon, יכולתי לראות את הסוד הזה, האם הוא הלך וניגש אליו? לכן, אין לנו שום יכולת לנהל מי יש גישה או אפילו לבדוק מי עשה מה איתו.

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

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

וכאן מגיע Vault

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אבל אם יש לנו משתמש אנושי, ייתכן שהם נכנסים ומשתמשים במשהו כמו LDAP או Active Directory כדי להוכיח את זהותם. אם אנו משתמשים בפלטפורמה ברמה גבוהה, אולי משהו כמו Kubernetes, אנו עשויים להשתמש בספק האימות שלנו ב- Kubernetes.

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

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

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

אחורי אחסון אחראים לאחסון נתונים במנוחה. זה יכול להיות כמה דברים שונים. זה יכול להיות RDBMS סטנדרטי ב- MySQL Postgres. זו יכולה להיות מערכת כמו Consol, והיא יכולה להיות בסיס נתונים מנוהל בענן כמו Google Spanner. אך המטרה של מערכות backend אלה היא לספק אחסון עמיד באופן זמין מאוד, כך שנוכל לסבול אובדן של אחת ממערכות ה- backend הללו.

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

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

יש לנו תוספי מסד נתונים שונים; תוסף מסד נתונים יאפשר לנו לנהל באופן דינמי את MySQL, ואת Postgres ואת אישורי Oracle, וכו '. יש לנו דברים כמו RabbitMQ, אז אולי אנחנו עושים אישורים דינמיים לתורי ההודעות שלנו.

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

זוהי נקודת הרחבה המאפשרת לכספת ליישם את אותו עיקרון על דברים רבים ושונים. שימוש נפוץ אחד בכך הוא PKI. בפועל, ניהול אישורים נוטה להיות סיוט, ומה שלעתים קרובות אנו רואים הוא תעודות ארוכות-טווח; אולי תעודות של חמש עד עשר שנים מכיוון שאנחנו לא רוצים לעבור את תהליך יצירתן. לעומת Vault, אנו יכולים למצוא אותם וליצור אותם באופן תכנותי. בפועל, אנשים ישתמשו בתעודות קצרות מועד. אולי קצרה כמו 72, 24 שעות. בדרך זו אתה כל הזמן זז ויוצר יעד נע.

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

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

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

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

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

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

אני מקווה שזה היה שימושי כמבוא ל- Vault. תודה!