איך לשלוח יומני מכשיר לקולט מרוחק בצורה מאובטחת

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

התחילו ממה שהמכשיר יכול לפלוט

בפועל יש רק שלוש צורות. אירועי syslog בודדים מעל UDP או TCP, העלאת HTTPS מאומתת המובנית במוצר, או קבצים שלמים שנכתבים לדיסק וצריך להעביר. חומת אש שיכולה לשלוח רק syslog מעל UDP לא תהפוך לשולחת TLS בגלל שהוספתם מנהרה; היא תמשיך לשלוח דאטגרמים לא מאושרים, עכשיו בתוך מעטפה מוצפנת.

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

syslog מעל TLS: הנתיב הקצר ביותר כששני הקצוות מדברים בו

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

ב-rsyslog, שם מודול התעבורה לבדו אומר לכם באיזו תקופה אתם נמצאים: lmnsd_gtls עוטף את GnuTLS, ואילו lmnsd_ossl עוטף את OpenSSL וזה מה שחבילות 8.x הנוכחיות מספקות. פעולת העברה עם אימות תעודה נראית בערך כך, וכדאי לבדוק את שמות הפרמטרים המדויקים מול הגרסה המותקנת:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

אמתו את נקודת הקצה לפני שאתם מדבגים את השולח. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error או שמשלים לחיצת יד עם שרשרת תקפה או אומר לכם בדיוק איזו בדיקה נכשלה. בדקו מהמכשיר, לא מהמחשב הנייד, כי מאגר האמון של המכשיר הוא זה שחשוב.

SFTP: טוב לקבצים, שגוי לזרמים

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

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

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

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

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

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

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

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

כתבו את חוזה המסירה לפני שאתם שולחים

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

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

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