מבוא ל-mTLS ב-Apigee

התכונה Apigee mTLS מוסיפה אבטחה לתקשורת בין רכיבים באשכול של Edge for Private Cloud. הוא מספק דרך סטנדרטית בתחום להגדיר ולהתקין את רשת השירות. הוא תומך בניהול חבילות ובאוטומציה של הגדרות אישיות.

סקירה כללית של הארכיטקטורה

כדי לספק תקשורת מאובטחת בין רכיבים, Apigee mTLS משתמש ב-Service mesh שיוצר חיבורי TLS מאובטחים ומאומתים הדדית בין רכיבים.

בתמונה הבאה מוצגים החיבורים בין רכיבי Apigee שמאובטחים באמצעות Apigee mTLS (in red). היציאות שמוצגות בתמונה הן דוגמאות. בשימוש ביציאות מופיעה רשימה של טווחים שכל רכיב יכול להשתמש בהם.

(שימו לב שהיציאות שמסומנות באות M משמשות לניהול הרכיב, והן צריכות להיות פתוחות ברכיב כדי ששרת הניהול יוכל לגשת אליהן).

כפי שניתן לראות בתרשים שלמעלה, Apigee mTLS מוסיף אבטחה לחיבורים בין רוב הרכיבים באשכול, כולל:

מקור יעד
שרת ניהול צומתי Router,‏ MP,‏ QPid,‏ LDAP,‏ Postgres,‏ Zookeeper ו-Cassandra
נתב Loopback; צמתים של Qpid,‏ Zookeeper ו-Cassandra
מעבד בקשות Loopback; צמתים של Qpid,‏ Zookeeper ו-Cassandra
‫ZooKeeper ו-Cassandra צמתים אחרים של Zookeeper ו-Cassandra
ממשק המשתמש של Edge ‫SMTP (ל-IDP חיצוני בלבד)
Postgres צמתים אחרים של Postgres,‏ Zookeeper ו-Cassandra

הצפנה ופענוח של הודעות

רשת השירות mTLS של Apigee מורכבת משרתי Consul שפועלים בכל צומת ZooKeeper באשכול, ומשירותי Consul הבאים בכל צומת באשכול:

  • שרת proxy יוצא שמיירט הודעות יוצאות בצומת המארח. השירות הזה מצפין הודעות יוצאות לפני שהן נשלחות ליעד שלהן.
  • שרת proxy נכנס שמיירט הודעות נכנסות בצומת המארח. השירות הזה מפענח הודעות נכנסות לפני שהוא שולח אותן ליעד הסופי שלהן.

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

כל התהליך הזה מתבצע באופן שקוף לרכיבי Edge: הם לא מודעים לתהליך ההצפנה והפענוח שמבוצע על ידי שירותי ה-proxy של Consul.

בנוסף, ב-Apigee mTLS נעשה שימוש בכלי iptables, שירות חומת אש של Linux שמנהל את ההפניה האוטומטית של התנועה.

דרישות

כדי להתקין את Apigee mTLS, הסביבה שלכם צריכה לעמוד בדרישות הבאות:

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

דרישות הטופולוגיה

כדי להשתמש ב-mTLS ב-Apigee, הטופולוגיה של הסביבה צריכה לכלול לפחות שלושה צומתי Zookeeper. לכן, אפשר להתקין את Apigee mTLS רק בטופולוגיות שמשתמשות ב-5, 9, 12 (מרכז נתונים מרובה) או 13 צמתים. מידע נוסף זמין במאמר טופולוגיות התקנה.

חבילות/כלי ניהול

כדי להשתמש ב-Apigee mTLS, צריך להתקין ולהפעיל את החבילות הבאות בכל מכונה באשכול, כולל מכונת הניהול, לפני שמתחילים בתהליך ההתקנה:

כלי שירות/חבילה תיאור אפשר להסיר אחרי ההתקנה?
base64 מאמת את הנתונים בסקריפטים של ההתקנה.
gnu-bash
gnu-sed
gnu-grep		 משמש את סקריפט ההתקנה וכלים נפוצים אחרים.
iptables החלפת חומת האש שמוגדרת כברירת מחדל, firewalld.
iptables-services מספק פונקציונליות לכלי iptables.
lsof בשימוש על ידי סקריפט ההתקנה.
nc מאמת iptables מסלולים.
openssl חותם על אישורים באופן מקומי במהלך תהליך ההפעלה הראשוני.

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

החבילה apigee-mtls מתקינה ומגדירה את שרתי Consul, כולל שרתי ה-proxy של תעבורת הנתונים הנכנסת והיוצאת בצומתי ZooKeeper באשכול.

הרשאות בחשבון המשתמש

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

החשבון שמפעיל את ההתקנה של Apigee mTLS בכל צומת באשכול צריך להיות מסוגל:

  • הפעלה, עצירה, הפעלה מחדש ואיניציאליזציה של רכיבי Apigee
  • הגדרת כללים לחומת האש
  • יצירת חשבון משתמש חדש במערכת ההפעלה
  • הפעלה, השבתה, התחלה, עצירה והסתרה של שירותים באמצעות systemctl

מכונת ניהול (מומלץ)

ב-Apigee מומלץ שיהיה צומת באשכול שבו אפשר לבצע משימות ניהול שונות שמתוארות במסמך הזה, כולל:

  1. מתקינים את HashiCorp Consul 1.6.2.
  2. יוצרים ומפיצים זוג מפתחות/אישור ומפתח הצפנה של Gossip.
  3. מעדכנים ומפיצים את קובץ התצורה.

כשמגדירים את מכונת הניהול:

  • מוודאים שיש לכם גישת root למכשיר.
  • מורידים ומתקינים את כלי השירות apigee-service ו-apigee-setup, כמו שמתואר במאמר התקנת כלי השירות apigee-setup של Edge.
  • מוודאים שאפשר להשתמש ב-scp/ssh כדי לגשת לכל הצמתים באשכול ממכונת הניהול. ההרשאה הזו נדרשת כדי שתוכלו להפיץ את קובץ התצורה ופרטי הכניסה.

שימוש ביציאות והקצאת יציאות

בקטע הזה מתוארים השימוש ביציאות וההקצאות של היציאות לתמיכה בתקשורת של Consul עם Apigee mTLS.

שימוש ביציאות: כל הצמתים שמריצים את apigee-mtls

כל הצמתים באשכול שמשתמשים בשירות apigee-mtls צריכים לאפשר חיבורים משירותים במארח המקומי (127.0.0.1). כך שרתי ה-proxy של Consul יכולים לתקשר עם השירותים האחרים בזמן שהם מעבדים הודעות נכנסות ויוצאות.

שימוש ביציאה: צומתי שרת Consul (צמתים שמריצים את ZooKeeper)

כדי לקבל בקשות מכל הצמתים באשכול, צריך לפתוח את רוב היציאות הבאות בצומתי השרת של Consul (הצמתים שבהם פועל ZooKeeper):

צומת יציאת שרת Consul תיאור פרוטוקול לאפשר סוכני mTLS חיצוניים
*
שרת Consul (צומתי ZooKeeper) 8300 מחבר את כל שרתי Consul באשכול. הכנסה לקליק
8301 מטפל בהודעות חברות ובהודעות לכולם בתוך האשכול. UDP/TCP
8302 יציאת WAN שמטפלת בהודעות חברות והודעות לכולם בתצורה של כמה מרכזי נתונים. UDP/TCP
8500 מטפל בחיבורי HTTP לממשקי ה-API של שרת Consul מתהליכים באותו צומת.

היציאה הזו לא משמשת לתקשורת או לתיאום מרחוק, אלא רק להאזנה ב-localhost.

 HTTP
8502 מטפל בחיבורי gRPC+HTTPS לממשקי ה-API של שרת Consul מצמתים אחרים באשכול. gRPC+HTTPS
8503 מטפל בחיבורי HTTPS לממשקי ה-API של שרת Consul מצמתים אחרים באשכול. HTTPS
8600 מטפל ב-DNS של שרת Consul. UDP/TCP
* ב-Apigee מומלץ להגביל את הבקשות הנכנסות לחברי האשכול בלבד (כולל מאגרי נתונים שונים). אפשר לעשות את זה באמצעות iptables.

כפי שמוצג בטבלה, הצמתים שמריצים את הרכיב consul-server (צמתי ZooKeeper) צריכים לפתוח את היציאות 8301,‏ 8302,‏ 8502 ו-8503 לכל החברים באשכול שמריצים את השירות apigee-mtls, גם במרכזי נתונים שונים. בצמתים שלא מריצים את ZooKeeper לא צריך לפתוח את היציאות האלה.

הקצאות של יציאות לכל הצמתים של Consul (כולל צמתים שבהם פועל ZooKeeper)

כדי לתמוך בתקשורת של Consul, צמתים שמריצים את רכיבי Apigee הבאים חייבים לאפשר חיבורים חיצוניים ליציאות בטווחים הבאים:

רכיב Apigee טווח מספר היציאות הנדרשות לכל צומת
Apigee mTLS 10700 עד 10799 1
Cassandra ‫10100 עד 10199 2
מעבד בקשות 10,500 עד 10,599 2
OpenLDAP ‫10200 עד 10299 1
Postgres ‫10300 עד 10399 3
Qpid ‫10400 עד 10499 2
נתב ‫10600 עד 10699 2
ZooKeeper ‫10000 עד 10099 3

‫Consul מקצה יציאות באופן לינארי פשוט. לדוגמה, אם באשכול יש שני צומתי Postgres, הצומת הראשון משתמש בשתי יציאות, ולכן Consul מקצה לו את היציאות 10300 ו-10301. גם הצומת השני משתמש בשתי יציאות, ולכן Consol מקצה לצומת הזה את היציאות 10302 ו-10303. ההגדרה הזו רלוונטית לכל סוגי הרכיבים.

כמו שאתם רואים, מספר היציאות בפועל תלוי בטופולוגיה: אם באשכול יש שני צומתי Postgres, תצטרכו לפתוח ארבע יציאות (שני צמתים כפול שתי יציאות לכל אחד).

שימו לב לנקודות הבאות:

  • שרתי proxy של Consul לא יכולים להאזין לאותן יציאות כמו שירותי Apigee.
  • ל-Consul יש רק מרחב כתובות אחד של יציאות. הקצאות הפורטים של שרת ה-proxy של Consul צריכות להיות ייחודיות בכל האשכול, כולל מרכזי נתונים. כלומר, אם שרת proxy א' במארח א' מאזין ליציאה 15000, שרת proxy ב' במארח ב' לא יכול להאזין ליציאה 15000.
  • מספר היציאות שבשימוש משתנה בהתאם לטופולוגיה, כפי שמתואר למעלה.

בהגדרה של כמה מרכזי נתונים, כל המארחים שמריצים mTLS צריכים לפתוח גם את יציאה 8302.

אתם יכולים להתאים אישית את יציאות ברירת המחדל שבהן Apigee mTLS משתמש. במאמר התאמה אישית של טווח היציאות של שרת ה-proxy מוסבר איך עושים את זה.

מגבלות

ל-Apigee mTLS יש את המגבלות הבאות:

  • לא מצפין תקשורת בין צומתי Cassandra (יציאה 7000)
  • ההגדרה וההתקנה לא אידמפוטנטיות. כלומר, אם מבצעים שינוי בצומת אחד, צריך לבצע את אותו שינוי בכל הצמתים. המערכת לא מחילה את השינוי הזה בצמתים אחרים. מידע נוסף זמין במאמר שינוי הגדרה קיימת של apigee-mtls.

הסברים על המונחים

בקטע הזה נעשה שימוש במונחים הבאים:

מונח הגדרה
cluster קבוצת המכונות שמרכיבות את ההתקנה של Edge for Private Cloud.
Consul Service mesh שמשמש את Apigee mTLS. במאמר מודל האבטחה של Consul מוסבר איך Consul מאבטח את התקשורת ב-Private Cloud.
mTLS ‫TLS עם אימות הדדי (mTLS).
Service mesh רשת שכבת-על (או רשת בתוך רשת).
TLS ‫Transaction Layer Security (אבטחה בשכבת התעבורה). פרוטוקול אימות סטנדרטי בתחום לתקשורת מאובטחת.