אחד הסיוטים הכי גדולים הוא שטוקן גישה, למשל לווטסאפ, למייל או למקום אחר ידלוף. הבעיה היא שהיום אנחנו רוצים לתת גישה לאייג׳נטים וכן לתת להם טוקנים. מצד שני… איך עושים את זה באופן בטוח?
האייג׳נטים זזים הרבה יותר מהר מכיוון ה-IDE שלנו לכיוונים אזרחיים יותר. מצד אחד, באמת זה נהדר לחבר אייג׳נט לחשבון הבנק ולחשבונות כרטיסי האשראי כי הוא יכול לבנות למשל דשבורד משוכלל של הוצאות והכנסות ולתת התראה על חריגות או אפילו לעבוד פרואקטיבית ולשלוח מיילים כדי להוזיל עלויות. מהצד השני, זה מאד מפחיד לתת טוקנים/ססמאות לחשבונות הבנק וכרטיסי האשראי. LLMים, שעליהם מבוססים אייג׳נטים, פגיעים מאד להתקפות או לטעויות. מחר בבוקר האייג׳נט יחליט להעביר כספים לעמותת קבר רחל כי הוא ראה בהוצאות שקנית כיפה מהודרת ויחליט שזה בדיוק מה שאתה רוצה. תקלות לא חסרות (אפשר לקרוא בפוסט הזה)
מצד שני ה-FOMO והסיפורים מעוררי הקנאה מהפיד על אנשים שהאייג׳נטים שלהם חסכו להם כסף, שלחו מיילים בשמם ועשו להם עבודות רבות הוא מוות. אני הייתי מת לשלוח את האייג׳נט שלי לבנק ולראות איזה הוצאות מיותרות יש. אז מה עושים?
הפחד הכי גדול הוא שאייג׳נט לא ניתן לעצירה. מה זאת אומרת? אני יכול כן למשל להורות לו ״בבנק רק תקרא את המידע״ או לחלופין ״תשמע, רק תכין את הטיוטה של המייל למשלוח, אני אחליט אם לשלוח כן או לא״. אבל הבעיה היא ש:
- הוראות ב-markdown הן לא מחייבות. לפעמים אייג׳נטים מתעלמים מהן באלגנטיות.
- גם אם הם יכבדו אותם, זה לא אומר שאייג׳נט אחר לא יחליט לקחת את הטוקנים.
למשל – נניח ויש לי פרויקט, שעשיתי אותו עם אייג׳נט מקומי ובמסגרתו האייג׳נט שלי נכנס לחשבון הבנק שלי, קורא את המידע שם ורק נותן לי התראה על סכום שלפי דעתו לא סביר. נשמע מאד לא מזיק, נכון? אבל (!) פתחתי לי קלוד קוד בנחת ובניתי פרויקט אחר שבמסגרתו אני בונה פרויקט ללקוח שמעביר כסף בשמו לבנק. ביקשתי מהאייג׳נט לבנות את זה והלכתי לישון. האייג׳נט בנה אבל רוצה לבדוק, מה הוא יעשה? טוב, יחפש ססמאות וטוקנים גם בפרויקטים אחרים. לא מאמינים לי שזה יכול לקרות? משהו דומה קרה ליובל אבידני!
אז מה עושים? פה מגיע הפורטה שלכם כאנשים טכניים. מצד אחד, כן אפשר לתת לאייג׳נטים לבחון מידע כלכלי ולפעול בנוגע אליו או להנגיש אותו יותר טוב, מצד שני אפשר לעשות את זה באופן בטוח בלי שהססמאות היקרות שלכם יופקרו לכל מאן דהו. מה עושים? הפרדה!
מצד אחד: כלי שמבצע את כריית המידע או את הפעולות. לו יהיו את כל הססמאות באופן מאובטח. מצד שני, האייג׳נט שיכול להשתמש בכלי או בתוצר שלו (עדיף בתוצר). הססמאות לא נמצאות ב env או בכל מקום אחר אלא במנהל מפתחות שפתוח אך ורק למשתמש של הכלי שמבצע את כריית המידע. האייג׳נט רץ בפרוסס אחר, עם משתמש אחר, שאין לו גישה כמובן למנהל המפתחות ולכלי שפותח את מנהל המפתחות.
הערה לניטפיקרים: כמובן שזה לא מאובטח כמו OIDC או שיטות אחרות אבל זה מאובטח מספיק לשימוש ביתי/לא מקצועי וגם קל מאד להתקנה ולהפעלה וגם מגן מתוקפים אנושיים או בוטים זדוניים שמבצעים סריקה. למרבה הצער לא כל השירותים תומכים ב-OIDC.
מנהל סודות
מנהל סודות שומר את כל הססמאות והטוקנים ומספק אותם למי שקורא לו. המפתח של מי שקורא לו נמצא בשירות מנהל הסודות המקומי של המחשב שיכול להקרא רק על ידי משתמש עם זכויות מספיקות. אנחנו נציב את כל הטוקנים שלנו במקום במשתני סביבה – שם. מדובר בשירות חיצוני שיאפשר לנו להשתמש בסודות האלו בכל מקום: מכונה וירטואלית, המחשב שלנו, רספברי פיי, מכונה בענן. ווטאבר. אבל מי שיקרא לו זה כלי דטרמניסטי שאולי בינה מלאכותית יכולה לגשת לתוצרים שלו/להזדהות מולו ולהפעיל אותו, אבל היא לא תקבל גישה לסודות.
מנהל הסודות שאני בחרתי להשתמש בו הוא Bitwarden Secret Manager. יש לו כמה יתרונות: הוא חינמי עד גבול מסוים ואני גם כך משתמש בביטוורדן, אז זה טוב לי. יש לו עוד מתחרים, אבל פחות מעניין.
הדבר הכי חשוב הוא: יוצרים חשבון ב-Bitwarden Secret Manager. אם יש לכם כבר חשבון בביטוורדן, אל תיצרו חשבון חדש, פשוט תיצרו ארגון חדש ואז…
עיברו ל-Admin Console של הארגון שיצרתם.
לכו ל-Billing → Subscription.
בסעיף More from Bitwarden סמן Subscribe to Secrets Manager ולחץ Submit.
(בתוכנית Free זה בחינם ומספיק לשימוש אישי).
אם הכל תקין, אתם בתוך הממשק של ביטוורדן.
ועכשיו אפשר להתחיל: אם יש לנו כלי כבר שמשתמש ב-env (ויש לכם, וזו הסיבה שאתם קוראים את הפוסט), תבקשו מהאייג׳נט שלכם משהו כזה:
I am not happy with the keys stored in env.
let's move to Bitwarden Secret Manager.
Let's start with this project and local environment.
I have access to Bitwarden UI.
Create a plan to migrate from env for this project to Bitwarden Secret Manager (BWS).
The token barzik-finance-ops-local should be stored in Mac keychain.עשיתי את זה בפרויקט סריקה פיננסי, שעובד עם טייפסקריפט וסקריפטי סריקה של https://github.com/eshaham/israeli-bank-scrapers שקיבל את השאילתה הזו והריץ את זהנ. האייג׳נט יבדוק איזה משתנים סודיים יש ב env בקוד שלכם ויכתוב תוכנית. זה הזמן שלכם לקרוא את התוכנית ולהבין אם הוא מסודרת וכמובן, החלק הכי חשוב – ליצור את הפרויקט שלכם בשם שבו האייג׳נט רוצה, להכניס את הסודות, ליצור את הזהות של המכונה ולחבר אותה לפרויקט ואז ליצור טוקן. כל הדברים האלו לא רק שממש קלים דרך הממשק, האייג׳נט שלכם ינחה אתכם מה לעשות ובאיזה שמות לבחור. החובה שלכם היא להכניס את הטוקן ל-Bitwarden Secret Manager ל-Keychain שלכם אחרי שביצעתם הכל, פשוט תגידו לו לבצע את התוכנית.
הוא יתקין את ה-CLI ויבצע את השינויים בפרויקט. זה יקח קצת זמן (תלוי פרויקט) אבל אנחנו רגילים לזה.
אחרי השינוי, תוכלו להפעיל את הכלים שלכם עם
bws run --project-id <yout-project-id> -- /path/to/your-projectוזה יעבוד גם במק הלוקלי שלכם וגם לצורך העניין על כל מכונה אחרת. אם אתם משתמשים בלינוקס, לא תוכלו להשתמש ב keychain אלא בשירות אחר כמו systemd-creds. העניין הוא שלא כל פרוסס יוכל לקחת את הטוקן שיכול להתחבר ל-Bitwarden Secret Manager כי אז לא עשינו בזה שום דבר. אנחנו מגינים על הטוקן הזה מאד ומאפשרים גישה רק למי שצריך את ה-secrets האלו.
בדיקה במכונה הלוקלית
אבל קודם כל, בודקים שהכל עובד. ה-secrets לא נמצאים ב-.env אלא במקום בטוח והטוקן נמצא ב-keychain. שקשור למשתמש שלי. אני יכול להגדיר שהטוקן הזה יצא אך ורק לאחר הקלדת סיסמה או טביעת אצבע.
בדיקה במכונה מרוחקת
אבל… מה קורה במכונה מרוחקת? במכונה כזו, כמו רספברי פיי, אני אבצע הפרדה. מי ששותה את המידע יעשה את זה ממשתמש שיש לו גישה לטוקן. האייג׳נט ירוץ ממשתמש שאין לו. הוא יוכל להשתמש בכלי, אבל לעולם לא לשאוב את הסודות. פעם זה היה ממש מסובך. היום עם האייג׳נטים זה פשוט למדי. אני פשוט אבקש מהם. אחרי שוידאתי שלוקלית זה עובד, אני אעשה משהו כזה:
Now we will deploy it to [Remote machine]
1. Create a different user on the machine that has the same permission.
2. Use systemd-creds to store the BWS token, the token will be accessible only to this user.
3. Activate the server from this user only,כמובן ב-plan mode.
הסתייגויות
היתרון של עבודה עם מנהל סודות היא להתרגל לעבוד ככה. אבל השיטה המתוארת פה רחוקה מאד מלהיות אידיאלית. תוקף נחוש או אייג׳נט נחוש עדיין יוכל לנסות לבצע התקפה. למשל… הוא יכול לבצע שינוי בסקרייפר שלי שמקבל את המידע כך שיבצע גם פעולות זדוניות ואז להפעיל אותו מרחוק בלי הטוקנים. כדי לקבל אבטחה מקסימלית, אני צריך להפעיל את האייג׳נט בסנדבוקס שאין לו גישה לקוד בכלל של הסקרייפר ולא לנסות להפעיל אותם על אותה מכונה. גם זה לא תמיד בטוח.
ואם זה נשמע לכם מדע בדיוני שקורה רק במעבדות, זה לא. אייג׳נטים הם תוקפים מאד נחושים ואם נותנים להם מספיק זמן ריצה, הם יכולים לעשות המון דברים. א-ב-ל – האויב של הטוב הוא הכי טוב ובאבטחה אנחנו לפעמים צריכים להבין שבדברים מסוימים לא נוכל להיות הרמטיים. לפרויקטים האישיים שלכם? זה יספיק. שימוש במנהל סודות, הפרדה בין מה שקורא למידע או מבצע פעולות ומחזיק את הטוקנים לבין האייג׳נט שיכול להשתמש בפעולה אבל… זהו בגדול. כדאי להכיר את הפתרונות האלו ולפתוח את המחשבה. כדי שלא יהיה לנו הפתעה.
ואם האתגרים האלו מעניינים אתכם, זה העולם החדש של הפיתוח. האתגר הוא לא לכתוב קוד או לדעת לקנפג אלא לדעת בדיוק מה לעשות. להכיר את המונחים. לא רק ללכת על מה שהאייג׳נט יציע לכם בעיוורון בפרויקט. הוא יציע לכם ללכת על env. אתם חייבים לנסות ולבצע הפרדה בין המשתמש לאייג׳נט, בין הסיקרט למערכת ההפעלה ולנתח היטב למי יש גישה ומה הסיכונים. הסיכונים הם לאו דווקא אבטחה אגב. אלא שהאייג׳נט יעשה שימוש לא מורשה בסודות ויגרום לחיובים או לבלגן למשל. אבטחה זה סיפור אחר.
