מכתב לספקי firewall (שהם לא יקראו)

Check Point ,Fortinet ,Cisco היקרים: תבחרו כבר סכמה אחת

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

קריאה של 7 דקות לכל מי שכתב פעם adapter ל-API של vendor

כולם עושים את אותו הדבר. אף אחד לא מסכים על האיך.

אתם רוצים ליצור חוק firewall שמרשה TCP פורט 443 מ-10.0.1.0/24 ל-192.168.5.0/24. זהו. משפט אחד. קונספט אחד. אוניברסלי בכל מוצר firewall שיוצר ב-20 השנים האחרונות.

ככה זה נראה כשמנסים לעשות את זה אוטומטי על פני שלושה ספקים:

Check Point R81 API
// POST /web_api/add-access-rule { "layer": "Network", "position": "top", "name": "Allow-Web", "source": "Net_10.0.1.0", "destination": "Net_192.168.5.0", "service": "https", "action": "Accept", "track": { "type": "Log" } } // But first you need to // create the network objects // with separate API calls // and then "publish" the // session. Because reasons.
Fortinet FortiOS API
// PUT /api/v2/cmdb/ // firewall/policy { "policyid": 0, "srcintf": [{ "name": "internal" }], "dstintf": [{ "name": "wan1" }], "srcaddr": [{ "name": "subnet_10.0.1.0" }], "dstaddr": [{ "name": "subnet_192.168.5.0" }], "service": [{ "name": "HTTPS" }], "action": "accept", "logtraffic": "all" } // Interfaces are mandatory. // Everything is an array. // Even when it's one item.
Cisco ASA REST API
// POST /api/access/in/ // outside_access_in/rules { "sourceAddress": { "kind": "IPv4Network", "value": "10.0.1.0/24" }, "destinationAddress": { "kind": "IPv4Network", "value": "192.168.5.0/24" }, "destinationService": { "kind": "NetworkProtocol", "value": "tcp/https" }, "permit": true, "active": true, "isAccessRule": true } // "kind" and "value". // For an IP address. // In 2026.

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

Action: "Accept" לעומת "accept" לעומת true.
Source: הפניה לאובייקט עם שם לעומת הפניה לאובייקט עם שם לעומת CIDR inline עם wrapper של "kind".
Service: "https" לעומת "HTTPS" לעומת "tcp/https".

אותו קונספט, שלוש ייצוגים שונים
Check Point
"action": "Accept"
"service": "https"
"source": "Net_10.0.1.0"
Fortinet
"action": "accept"
"service": [{"name":"HTTPS"}]
"srcaddr": [{"name":"..."}]
Cisco ASA
"permit": true
"value": "tcp/https"
"kind": "IPv4Network"

עבודת התרגום היומית שלכם

ככה נראה יום העבודה שלכם בפועל כשמתחזקים אוטומציה multi-vendor:

  1. לפרסר את אירוע השינוי של AWS Security Group. לחלץ את ה-CIDR, טווח הפורטים, הפרוטוקול והכיוון מפורמט ה-JSON של AWS. לטפל ב-9 edge cases שונים: prefix lists, הפניות ל-security groups, IPv6, טווחי פורטים אפמריים, groups שמפנים לעצמם...
  2. לתרגם ל-Check Point. קודם ליצור את אובייקט הרשת (קריאת API נפרדת). אחר כך ליצור את אובייקט השירות אם הוא לא קיים (עוד קריאת API). אחר כך ליצור את החוק (עוד קריאת API). אחר כך לעשות "publish" ל-session (ועוד קריאת API). לטפל בנעילת session אם מישהו אחר עורך את הפוליסי. לטפל ב-timeout של 10 דקות על ה-session.
  3. לתרגם שוב ל-Fortinet. שמות שדות שונים. מבנה nesting שונה. הכל במערכים. Interfaces הם חובה אבל ב-Check Point לא משתמשים בהם. למפות את מוסכמות שמות ה-interfaces הפנימיים. לטפל באותנטיקציה באמצעות API key (לא מבוסס session כמו ב-Check Point).
  4. לתרגם שוב ל-Cisco. הפעם CIDR inline, לא אובייקטים עם שמות. wrappers של "kind/value" סביב הכל. מבנה URL path שונה לכל access list. אין bulk operations - חוק אחד לכל קריאת API.
  5. לטפל בשגיאות. Check Point מחזיר task ID שצריך לעשות לו polling. Fortinet מחזיר את השגיאה ב-JSON path שונה תלוי בסוג השגיאה. Cisco מחזיר HTTP 500 על הכל ושם את השגיאה האמיתית ב-response body. לפרסר שלושה פורמטים של שגיאות. להחליט מה לעשות עם כל אחת.
  6. לחזור על הכל בכל פעם שספק מוציא עדכון API. Check Point R81.10 שינה שלושה שמות שדות. Fortinet 7.4 עשה deprecation לשני endpoints. Cisco ASA 9.18 הוסיף שדה חובה. כל אחד מהם שובר לכם את הקוד בשקט. אתם מגלים את זה בשתיים בלילה.
אתם לא מהנדסי אבטחה. אתם מתרגמי JSON במשרה מלאה שבמקרה מבינים ב-firewalls.

מה אם התרגום פשוט... יקרה לבד?

זה החלק שכמעט פשוט מדי כדי להאמין לו. Cyberm8 מבין מה זה כתובת IP. מה זה סאבנט. מה זה טווח פורטים. מה הכוונה ב-"allow TCP 443 from A to B". המערכת יודעת לבטא את הקונספט הזה בשפה של Check Point, ובשפה של Fortinet, ובשפה של Cisco, ובשפה של Palo Alto.

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

ב-Cyberm8, מתארים את הכוונה פעם אחת

// What you configure in Cyberm8: Rule: Allow-Web-Finance Source: 10.0.1.0/24 Destination: 192.168.5.0/24 Service: TCP/443 Action: Allow Targets: all-perimeter-firewalls // What Cyberm8 does automatically: // → Translates to Check Point format. Creates objects. Publishes session. // → Translates to Fortinet format. Maps interfaces. Wraps in arrays. // → Translates to Cisco format. Inlines CIDR. Adds kind/value wrappers. // → Pushes to all targets atomically. Verifies. Logs. Done.

בלי Python. בלי קוד ספציפי לספק. בלי פרסור JSON. בלי ניהול sessions. בלי תרגום פורמטים של שגיאות. תיארתם את ה-מה. המנוע טיפל ב-איך.

וכשCheck Point יוציאו R82 וישנו שלושה שמות שדות? Cyberm8 מעדכן את ה-adapter. הקונפיגורציה שלכם לא משתנה. השינה שלכם בלילה לא משתנה. אתם אפילו לא צריכים לדעת שזה קרה.

איך למכור את זה לצוות

הפיץ' למנהל הצוות

"אנחנו מבזבזים X שעות בשבוע על תחזוקת שלושה adapters ספציפיים לספקים שעושים את אותו הדבר: מתרגמים חוקי firewall בין פורמטים. כל עדכון של ספק שובר לפחות אחד מהם. יש פלטפורמה שמטפלת בתרגום הזה באופן מובנה לכל הספקים שלנו. זה יחסל את כל הקוד הספציפי לספקים ואת עומס ה-on-call שבא איתו. אני רוצה לבדוק את זה מול ה-cluster של Check Point שלנו לשעה. אפשר?"

הגרסה החזקה ביותר של הפיץ' הזה: תראו למנהל הצוות את שלושת ה-JSON payloads אחד ליד השני (השתמשו באלה שלמעלה - הם אמיתיים). אחר כך תראו לו את הגרסה של Cyberm8. הוויזואל אומר יותר מכל טיעון.

תפסיקו להיות מתרגמי JSON.

חברו את ה-firewalls שלכם לסביבת הבדיקה החינמית. דחפו חוק אחד לשלושה ספקים. תראו את התרגום קורה בזמן אמת. לוקח פחות זמן מלדבג timeout אחד של Check Point session.

← נסו את הדמו Multi-Vendor info@cyberm8.com - אנחנו יודעים מה זה להרגיש "kind": "IPv4Network".