IPsec בין שני מארחים: היכן ההגנה מתחילה ומסתיימת
זוג מארחים יכול להגן על זרימות נבחרות בלי שער. הגדירו את נקודות הקצה, את המדיניות שבוחרת את התעבורה ואת ההרשאות שנשארות נפרדות.
ההגנה על זוג מארחים מתחילה במקום שבו אגודת האבטחה מסתיימת, וזה העובדה שהאינטואיציה המעוצבת בידי שערים מחמיצה לרוב. שרת יישום ושרת מסד הנתונים שלו יכולים להגן על השיחה שלהם בעצמם ישירות, בלי שום מרכז גישה מרחוק בנתיב, וגבול ההגנה נמצא אז בתוך כל מארח ולא בחומת אש. מה שזה נותן לכם הוא כיסוי מקצה לקצה עבור זרימות נבחרות. מה שזה לא נותן לכם הוא החלטה מי רשאי לקרוא איזו שורה.
הגבול הוא במקום שבו ה-SA מסתיים
RFC 4301 מתאר אגודות אבטחה במצב תעבורה כסידור שמשמש בדרך כלל בין זוג מארחים להגנה מקצה לקצה. שני המארחים האלה מחזיקים במפתחות, וכל אחד מחליט אילו מהמנות שלו נכנסות לאגודה. מנהרת שער מסתיימת במקום אחר לגמרי ומגיעה למארח דרך מקטע פנימי נוסף, שזה גבול אמון אחר גם כאשר המנה מוצפנת ברוב דרכה.
מארח-למארח ומצב תעבורה אינם מילים נרדפות עם זאת. שני מארחים יכולים לבנות ביניהם אגודה במצב מנהרה באותה מידה של נכונות, לכן בחרו תחילה את המצב ואחר כך תארו את נקודות הקצה. כתבו את שניהם בהערת התכנון לצד כתובות העמיתים, כי סוקר שמכיר רק את המצב יניח את האחר.
ה-SPD מחליט על ההגנה, המסלול מחליט על הכיוון
טבלת ניתוב עונה לאן מנה הולכת. מסד נתוני מדיניות האבטחה עונה כיצד התעבורה הנבחרת חוצה את גבול ההגנה, והוא עושה זאת לכל כיוון עם בוררים משלו. אותה הפרדה היא הסיבה לכך שמסלול עובד אל מסד הנתונים אינו מוכיח דבר בשאלה אם הבקשה הייתה מוגנת, ולכך משא ומתן מבוסס אינו מוכיח דבר גם בשאלה אם היישום המסוים הזה תאם לו. השוו את הבוררים לפני שתשוו את המונים, כי המונים מתארים רק את הזרימות שהגיעו עד כאן.
ב-Linux הפקודה ip xfrm policy מדפיסה את הרשומות האלה עם הכיוון, העדיפות, הבורר והפעולה שלהן permit, block או trap, ואילו ip xfrm state מציגה את האגודות הנובעות ואת המונים שלהן. קריאת שתיהן יחד היא הדרך למצוא את הזרימה שעקפה בשקט את המנהרה מפני שרשומת הרשאה רחבה יותר התאימה ראשונה.
סדר העדיפויות הוא חלק מהמדיניות, לא פרט מימוש. רשומה צרה שאמורה להגן על פורט מסד הנתונים מפסידה לרשומה רחבה יותר בעדיפות גבוהה יותר, והכשל נראה כאילו המדיניות מעולם לא נשאלה.
מצב תעבורה מכסה את השכבה הבאה, לא את כותרת ה-IP
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
במצב תעבורה כותרת ESP יושבת בין כותרת ה-IP למטען, ושדות הכתובת של אותה כותרת נשארים גלויים לכל התקן בנתיב. זה בסדר כאשר הכתובות אינן הסוד והמטען הוא הסוד. זו הבחירה השגויה אם גם צריך להסתיר את הטופולוגיה הפנימית, כי רק מצב מנהרה עוטף את הכותרת המקורית בכותרת חדשה.
שני המצבים יכולים לשאת כמה פרוטוקולים של השכבה הבאה, ו-ESP יגן על מה שהבורר מתאים לו ולא על כל מה שהמארח שולח.
הבחירה צרה מהחיבור
אגודה אחת יכולה לשאת כמה זרימות, אבל רק את אלה שהמדיניות בוחרת. תעדו את זהויות העמיתים, כתובות המקור והיעד, הפרוטוקול והיקף השירות עבור היחסים שאתם מתכוונים להם, ואחר כך החליטו בנפרד אם תעבורה שאינה מתאימה רשאית לעבור בגלוי, אם היא חייבת להיות מוגנת, או אם יש להפיל אותה כאשר האגודה אינה זמינה. ההחלטה האחרונה היא זו שמייצרת הפתעות, כי כלל שדורש הגנה עבור המקור השגוי יכול לחסום את גישת הניהול שלכם באותה יעילות שבה הוא חוסם פורץ.
שמרו על נתיב מחוץ לפס מאושר בזמן שאתם משנים את האכיפה, ובדקו אותו לפני שתזדקקו לו ולא אחרי ששני המארחים הפכו בלתי נגישים.
זהות המכונה אינה הרשאת יישום
IPsec מאמת עמית מוגדר ומגן על מנות נבחרות. הוא אינו מחליט איזה רשומה במסד הנתונים אדם רשאי לערוך, ואינו הופך זהות שרת מהימנה להענקת כל הרשאת יישום. חשבונות, תפקידים והרשאות של היישום נשארים בדיוק במקום שבו היו, ודרישת TLS ברמת היישום שומרת על מטרתה שלה גם כאשר נתיב הרשת כבר מוגן.
קבלו את התכנון בפעולה אחת מהמקור המיועד ואחת שחייבת להידחות, והכלילו מה קורה כאשר לא ניתן להקים את האגודה הנדרשת. בדיקת נגישות רגילה אומרת לכם שהמנות זזות; היא אינה אומרת שהן זזו תחת המדיניות שכתבתם.