n8n באחסון עצמי: audit אחד חושף webhooks לא מוגנים

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

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

מריצים את הביקורת ושומרים נקודת השוואה

הריצו n8n audit בסביבה שמחזיקה את המופע שאותו אתם מתחזקים, ושמרו את הפלט לצד שם הסביבה. אם אתם משתמשים ב־API, הפעולה היא בקשת POST ל־/audit שמחייבת הזדהות כבעל המופע; אפשר גם להפיק ביקורת באמצעות n8n node. בהתקנה עם staging וייצור, תוצאות מסביבה אחת אינן תחליף לבדיקה של האחרת.

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

בודקים את ה־webhooks שמקבלים בקשות מבחוץ

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

ב־הגדרות ה־Webhook node אפשר לדרוש Basic auth, ‏Header auth או JWT auth, ולהגביל כתובות מקור באמצעות IP(s) Allowlist. בחרו מנגנון שהשירות השולח יודע להשתמש בו, עדכנו את ההגדרה גם בצד השולח, ובדקו שבקשה מורשית מפעילה את ה־workflow ובקשה ללא הרשאה נדחית. כאשר אין אפשרות לדרוש אימות ב־node, החליטו במפורש כיצד מגבילים את הגישה לנתיב; עצם העובדה שכתובת ה־URL קשה לניחוש אינה בקרת הרשאה.

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

מנקים אישורים בלי לשבור תהליכים מושבתים

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

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

מתרגמים ממצאי nodes, קבצים ושאילתות לתיקון

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

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

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

מסובבים מפתח נתונים רק לאחר גיבוי ובדיקת staging

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

1. גבו את מסד הנתונים במלואו וודאו שערך N8N_ENCRYPTION_KEY הדרוש לשחזור שמור וזמין למורשים. בהתקנה עם מופע ראשי ו־workers, ודאו שכולם משתמשים באותו ערך. בדיקת שחזור מעשית חשובה יותר מהנחה שקובץ גיבוי לבדו יספיק.
2. בסביבת staging, הגדירו N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION=true בכל המופעים, הפעילו אותם מחדש ובדקו שהמפתח הפעיל מופיע תחת Settings ו־Data Encryption Keys. פתחו אישורים שמורים והריצו workflows שתלויים בהם כדי לוודא שהפענוח עובד.
3. רק לאחר שהבדיקה הצליחה, הפעילו את אותו דגל בייצור ובדקו שוב גישה לאישורים. כאשר תרצו לסובב את מפתח הנתונים הפעיל, השתמשו ב־Rotate key ובדקו מחדש תהליכים שתלויים במידע מוצפן.

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