הגדרת mTLS מקורי ב-Cassandra

מבוא

כברירת מחדל, רכיבים שונים של Edge for Private Cloud, כמו מעבדי בקשות, שרתי ניהול ונתבים, מתחברים לצומתי Cassandra דרך ערוץ טקסט פשוט. בערוצים כאלה, הנתונים שמועברים אל Cassandra וממנה מועברים באופן גלוי. ‫Apigee mTLS הוא פיצ'ר שמבוסס על רשת שירותים של Consul, שמוסיף אבטחה לתקשורת בין רכיבים באשכול של Edge for Private Cloud. השירות הזה של Apigee מוסיף גם אבטחת TLS לערוץ התקשורת בין רכיבי הלקוח לבין Cassandra.

במאמר הזה נסביר על חלופה חדשה של Apigee שבה התקשורת בין רכיבי הלקוח לבין Cassandra ב-Edge for Private Cloud מאובטחת באמצעות TLS הדדי (שנקרא גם TLS דו-כיווני) באמצעות תכונות שזמינות באופן מקורי ב-Cassandra, בלי להשתמש ב-Service mesh חיצוני.

תכונת mTLS מובנית

הפעלת mTLS בין Cassandra לבין רכיבי הלקוח שמתוארים במאמר הזה מסתמכת על תכונות TLS שסופקו באופן מקורי על ידי Apache Cassandra. כשההגדרה מופעלת, חיבורי לקוחות ל-Cassandra (ביציאת התעבורה המקורית של CQL‏ 9042) מבצעים לחיצת יד בפרוטוקול TLS דו-כיוונית עם לקוחות לפני שהם מאפשרים ליצור חיבורים. לצורך החיבור הדו-כיווני הזה של TLS, ‏Cassandra פועלת כשרת, ולקוחות שונים שמתחברים ל-Cassandra (כמו edge-message-processor, הכלי cqlsh וכו') פועלים כלקוחות.

כדי להשתמש ב-TLS דו-כיווני (או ב-TLS הדדי או mTLS), צריך להגדיר גם את Cassandra וגם את הלקוחות עם מאגר מפתחות משלהם. מאגר המפתחות של כל צומת Cassandra צריך להכיל מפתח ואישור משלו. מאגר המפתחות של כל אפליקציית לקוח צריך להכיל את המפתח והאישור של אותו לקוח ספציפי. צריך להוסיף ל-Cassandra וללקוחות מאגר אמון שמכיל את האישורים ואת השרשרת המשויכת של הצד השני. מאגר האישורים של כל צומת Cassandra צריך להכיל אישורים של לקוחות, ומאגר האישורים של כל לקוח צריך להכיל אישורים של כל צומתי Cassandra. במאמר של Apigee בנושא TLS/SSL דו-כיווני יש מידע נוסף על אופן הפעולה של לחיצת יד בפרוטוקול TLS דו-כיווני באופן כללי.

שרשרת אישורים

באופן כללי, ב-Two-Way TLS, אפשר ליצור אישורי שרת, אישורי לקוח, שרשראות אישורים, מאגרי מפתחות ומאגרי אישורים מהימנים בדרכים שונות. הכלל הזה חל גם על Cassandra ועל mTLS מקורי של הלקוח. בהתחשב באופן שבו ארגונים בדרך כלל מפעילים אשכולות של Edge for Private Cloud ובמספר הזוגות הייחודיים של חיבורי לקוח ל-Cassandra שאפשר ליצור, Apigee ממליצה להשתמש בגישה הכללית הבאה להגדרת מפתחות ואישורים לתכונה הזו. יש שיטות אחרות שאפשר להשתמש בהן, אבל השיטה שבהמשך כנראה מספקת איזון טוב בין אבטחה לבין עלויות התחזוקה.

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

  2. משתמשים במפתח או באישור הביניים הנפוץ שלמעלה כדי לחתום על כל המפתחות והאישורים הספציפיים לאפליקציה (עלה).

אם יש מפתח/אישור ביניים משותף באשכול אחד, אפשר להגדיר מאגר אישורים מהימנים משותף (שמכיל את אותה שרשרת אישורים בסיסיים ואישורי ביניים) בכל צומת של Cassandra ושל הלקוח. כל צומת של Cassandra ואפליקציית לקוח מקבלים מפתח עלים ייחודי משלהם ואישור שנחתם על ידי מפתח/אישור ביניים משותף.

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

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

בשלבים הבאים במאמר הזה מוסבר בפירוט איך ליצור מפתחות ואישורים לפי השיטה שלמעלה.

מגבלות וסייגים

התכונה הזו כפופה למגבלות הבאות.

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

הפעלת mTLS מקורי

באופן כללי, הפעלת mTLS מקורי היא תהליך בן 3 שלבים, כפי שמתואר בהמשך:

  1. משיגים אישור בסיס וזוג מפתחות/אישורים של ביניים.
  2. יוצרים זוג מפתחות/אישורים של עלה (leaf) לצומת אחד של Cassandra, חותמים עליו, מאחסנים אותו במאגר מפתחות ומגדירים את Cassandra ל-mTLS אופציונלי. חוזרים על השלבים לכל צומת Cassandra, אחד בכל פעם.
  3. יוצרים זוג מפתח/אישור עלים של אפליקציית לקוח אחת, חותמים עליו, מאחסנים אותו במאגר מפתחות ומגדירים את אפליקציית הלקוח ל-mTLS. חוזרים על השלבים בכל אפליקציית לקוח, אחת בכל פעם. אפליקציות לקוח:
    1. edge-management-server
    2. edge-message-processor
    3. נתב קצה

השלבים האלה מפורטים בהמשך:

השגת אישורי בסיס ואישורי ביניים

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

  • ‫intermediate.key – קובץ מַפְתח לאישור ביניים לחתימה על אישורי קצה
  • ‫intermediate-cert.pem – אישור ביניים

הגדרת צמתים של Cassandra

  1. בחירת צומת Cassandra
  2. יוצרים זוג של מפתח ואישור עלה וחותמים עליו באמצעות אישור הביניים. שומרים את המפתח ואת האישור החתום במאגר מפתחות. דוגמה: 
    
# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout cass-node1.key -out cass-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=cassnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in cass-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out cass-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in cass-node1-cert.pem -inkey cass-node1.key -out cass-node1-keystore.pfx -name nativemtls -password pass:keystorepass

    ממקמים את קובצי ה-keystore וה-truststore במיקום מסוים בצומת ומוודאים שהם נגישים למשתמש apigee 

    cp cass-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/cass-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

  3. יוצרים או עורכים את הקובץ /opt/apigee/customer/application/cassandra.properties. מוסיפים את התוכן הבא לקובץ: 
    ### Enable Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=true

### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

### Keystore details
conf_cassandra_client_encryption_keystore=/opt/apigee/customer/application/cass-node1-keystore.pfx
conf_cassandra_client_encryption_keystore_password=keystorepass
conf_cassandra_server_encryption_store_type=PKCS12

### Whether to enable 2-way TLS (or mTLS) - true or false
conf_cassandra_client_encryption_require_client_auth=true

### When 2-way TLS is enabled, client certificate details need to be provided via a truststore
conf_cassandra_client_encryption_truststore=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_client_encryption_truststore_password=trustpass
conf_cassandra_client_encryption_store_type=PKCS12

    מוודאים שמשתמש apigee הוא הבעלים של הקובץ ויכול לקרוא אותו:

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. הגדרה והפעלה מחדש של צומת Cassandra 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  5. חוזרים על השלבים שלמעלה בכל צומת של Cassandra, אחד בכל פעם.

הגדרת אפליקציות לקוח

הקטע הזה רלוונטי לרכיבי הלקוח הבאים שמתחברים ל-Cassandra:

  • edge-management-server
  • edge-message-processor
  • נתב קצה

  1. בחירת רכיב אחד של הלקוח
  2. יוצרים זוג של מפתח ואישור עלה וחותמים עליו באמצעות אישור הביניים. מאחסנים את המפתח ואת האישור החתום במאגר מפתחות. דוגמה: 
    
# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout mgmt-node1.key -out mgmt-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=mgmtnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in mgmt-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out mgmt-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in mgmt-node1-cert.pem -inkey mgmt-node1.key -out mgmt-node1-keystore.pfx -name nativemtls -password pass:keystorepass

    ממקמים את קובצי ה-keystore וה-truststore במיקום מסוים בצומת ומוודאים שהם נגישים למשתמש apigee.

    cp mgmt-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/mgmt-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

  3. יצירה ועריכה של קובץ תצורה על סמך האפליקציה שאתם מגדירים
    אפליקציה קובץ תצורה
    שרת ניהול /opt/apigee/customer/application/management-server.properties
    מעבד ניהול /opt/apigee/customer/application/message-processor.properties
    נתב /opt/apigee/customer/application/router.properties

    מוסיפים לקובץ את ההגדרות הבאות: 

    ### Enable TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=true
conf_cassandra_sslconfig.enable.mtls=true

### Keystore Details
conf_cassandra_sslconfig.keystore.path=/opt/apigee/customer/application/mgmt-node1-keystore.pfx
conf_cassandra_sslconfig.keystore.password=keystorepass
conf_cassandra_sslconfig.keystore.type=PKCS12

### Truststore Details
conf_cassandra_sslconfig.truststore.path=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_sslconfig.truststore.password=trustpass
conf_cassandra_sslconfig.truststore.type=PKCS12

    מוודאים שקובץ התצורה נמצא בבעלות של משתמש apigee ושהוא קריא על ידו 

    chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties

  4. מפעילים מחדש את אפליקציית הלקוח. 
    # Configure and restart service:
apigee-service component configure
apigee-service component restart
# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart
  5. כדי לוודא ש-SSL הוגדר בצורה נכונה באפליקציית הלקוח, מחפשים ביומן המערכת של האפליקציה המתאימה שורות שדומות לאלה:

    אפשרויות SSL נוספו לחיבור Cassandra

  6. חוזרים על השלבים שלמעלה בכל אפליקציית לקוח, אחת בכל פעם.

פעולות והגדרות

אכיפת mTLS

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

  1. בוחרים צומת Cassandra אחד.
  2. יוצרים או עורכים את הקובץ /opt/apigee/customer/application/cassandra.properties. מוסיפים או עורכים את המאפיין הבא בקובץ: 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=false

    מוודאים שהקובץ נמצא בבעלות של משתמש Apigee ושהוא יכול לקרוא אותו

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. הגדרה והפעלה מחדש של צומת Cassandra 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. חוזרים על השלבים שלמעלה בכל צומת של Cassandra, אחד אחרי השני.

אחרי שמפעילים אכיפה של mTLS ב-Cassandra, אי אפשר להתחבר ישירות ל-Cassandra באמצעות כלי השאילתות הרגיל של Cassandra‏ cqlsh. כדי להגדיר SSL ב-cqlsh, יוצרים מפתח ואישור חדשים של עלה (בדומה למפתח ואישור של עלה בשביל אפליקציות לקוח) ומבצעים את הפעולות הבאות:

  1. יצירה או עריכה של הקובץ $HOME/.cassandra/cqlshrc
  2. מוסיפים את התוכן הבא לקובץ: 
    [ssl]
certfile = /home/admin-user/certs/inter-root.pem
validate = false
userkey = /home/admin-user/certs/cqlsh1.key
usercert = /home/admin-user/certs/cqlsh1-cert.pem
    • ‫certfile – קובץ אישור שמכיל את שרשרת האישורים של הבסיס ושל הביניים
    • ‫userkey – מפתח הלקוח שבו cqlsh ישתמש. זה צריך להיות זוג של מפתח/אישור עלה שאפשר ליצור ולחתום עליו באמצעות אישור הביניים.
    • ‫usercert – אישור לקוח לשימוש על ידי cqlsh. זה צריך להיות מפתח/אישור עלים שאפשר ליצור ולחתום עליו באמצעות אישור הביניים.
  3. מריצים את הפקודה cqlsh כרגיל, ומספקים את הארגומנט --ssl. לדוגמה: 
    $  /opt/apigee/apigee-cassandra/bin/cqlsh --ssl X.X.X.X
Connected to Apigee at X.X.X.X:9042
[cqlsh 6.0.0 | Cassandra 4.0.13 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh>

השבתת האכיפה של mTLS ב-Cassandra

כדי להשבית את האכיפה של mTLS ב-Cassandra, פועלים לפי השלבים הבאים:

  1. בוחרים צומת Cassandra אחד.
  2. יוצרים או עורכים את הקובץ /opt/apigee/customer/application/cassandra.properties. מוסיפים או עורכים את המאפיין הבא בקובץ: 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

    מוודאים שהקובץ נמצא בבעלות של משתמש apigee ושהוא יכול לקרוא אותו

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. הגדרה והפעלה מחדש של צומת Cassandra 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. חוזרים על השלבים שלמעלה בכל צומת של Cassandra, אחד בכל פעם.

השבתת mTLS מקורי

השבתה של mTLS מקורי היא תהליך שכולל כמה שלבים, בדומה להפעלה של mTLS מקורי. השלבים העיקריים הם:

  1. השבתת האכיפה של mTLS ב-Cassandra (אם היא נאכפת)
  2. משביתים את mTLS בכל הצמתים של אפליקציות הלקוח הבאות, אחת אחרי השנייה:
    • edge-management-server
    • edge-message-processor
    • נתב קצה
    1. יוצרים ועורכים קובץ תצורה בהתאם לאפליקציה שמגדירים:
      אפליקציה קובץ תצורה
      שרת ניהול /opt/apigee/customer/application/management-server.properties
      מעבד ניהול /opt/apigee/customer/application/message-processor.properties
      נתב /opt/apigee/customer/application/router.properties
    2. מוסיפים או עורכים את המאפיינים הבאים בקובץ התצורה: 
      ### TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=false
conf_cassandra_sslconfig.enable.mtls=false
    3. מוודאים שקובץ התצורה נמצא בבעלות של משתמש apigee וניתן לקריאה על ידו: 
      chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties
    4. מפעילים מחדש את אפליקציית הלקוח: 
      
# Configure and restart service:
apigee-service component configure
apigee-service component restart

# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart
    5. חוזרים על שלבים #a עד #d בכל אפליקציית לקוח, אחת בכל פעם.
  3. משביתים את mTLS בכל צומתי Cassandra, אחד אחרי השני:
    1. בוחרים צומת Cassandra אחד.
    2. יוצרים או עורכים את הקובץ /opt/apigee/customer/application/cassandra.properties. מוסיפים או עורכים את המאפיין הבא בקובץ הזה: 
      ### Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=false

      מוודאים שמשתמש apigee הוא הבעלים של הקובץ ויש לו הרשאת קריאה

      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    3. הגדרה והפעלה מחדש של צומת Cassandra
      4. apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
    4. חוזרים על שלבים א עד ג בכל צומת של Cassandra, אחד בכל פעם.

רוטציות של אישורים

רוטציה של אישורי עלה בלבד (שמירה על אותם אישורי ביניים ואישורי בסיס)

אפשר לבצע שלבים דומים לאלה שבקטע הגדרת אפליקציות לקוח:

  1. יצירת מפתח/אישור עלה חדש לאפליקציה באמצעות אותו מפתח/אישור ביניים
  2. מגדירים באפליקציה את הנתיב למפתח או לאישור העלה החדש, יחד עם הסיסמה וסוג מאגר המפתחות.
  3. הפעלה מחדש של האפליקציה
רוטציה של אישורי בסיס או אישורי ביניים

אם אתם מתכננים להחליף אישור ביניים או אישור בסיס, מומלץ לעשות זאת בתהליך רב-שלבי:

  1. משביתים את ה-mTLS המקורי של Cassandra בכל האשכול.
  2. משתמשים באישורי הבסיס והביניים החדשים כדי ליצור אישורי עלה או אישורי אפליקציה חדשים.
  3. פועלים לפי השלבים להפעלת mTLS מקורי של Cassandra באמצעות קבוצת המפתחות והאישורים החדשה.

פעולות כלליות ב-Apigee

כדי לבצע פעולות כלליות ב-Apigee, כמו שדרוג תוכנת Apigee, הוספה או הסרה של צומתי Cassandra, הוספה או הסרה של מרכזי נתונים, הפעלה או השבתה של אימות Cassandra וכו', צריך לוודא ש-mTLS לא נאכף ב-Cassandra. אם אכפתם mTLS, השביתו את האכיפה לפני שתמשיכו בפעולות האלה.

נספח 1

אפשר לפעול לפי השלבים בנספח הזה כדי ליצור זוג מפתחות/אישורים עם חתימה עצמית ברמה הבסיסית וברמת הביניים, ולהוסיף את שרשרת האישורים הזו ל-truststore.

יצירת אישורי ביניים ואישורי בסיס בחתימה עצמית

# Create self-signed root key and cert
openssl req -x509 -newkey rsa:2048 -keyout root.key -out root-cert.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=root.yourorg.com/emailAddress=apigeeroot@yourorg.com"

# Create intermediate key and cert (signed by root)
openssl req -newkey rsa:2048 -keyout intermediate.key -out intermediate-req.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=inter.yourorg.com/emailAddress=apigeeinter@yourorg.com"

openssl x509 -req -in intermediate-req.pem -CAkey root.key -CA root-cert.pem -days 3650 -CAcreateserial -out intermediate-cert.pem

יצירת מאגר אישורים מהימנים (truststore)

# Merge root and intermediate cert into 1 file
cat intermediate-cert.pem > inter-root.pem
cat root-cert.pem >> inter-root.pem

# Create truststore to be used everywhere
keytool -keystore truststore.pfx -storetype PKCS12 -importcert -file inter-root.pem -keypass trustpass -storepass trustpass -alias nativemtls -noprompt

נספח 2: הגדרות חלופיות לשרשור אישורים

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

  1. מפתחות ואישורים ישירים של עלים לכל צומת Cassandra או אפליקציית לקוח (ללא אישורים של שורש חתימה או אישורי ביניים). הדבר הזה כנראה יסבך את תהליך הרוטציה של האישורים.
  2. שימוש בכמה קבוצות של שורש וביניים לתרחישים שונים. לדוגמה, לצומתי Cassandra יש קבוצה אחת של אישורי בסיס/ביניים שבאמצעותם נחתמים כל אישורי הקצה של Cassandra. באופן דומה, לכל אפליקציות הלקוח יכולה להיות קבוצה נפרדת אחת של אישורי בסיס או אישורי ביניים לחתימה על אישורי קצה של אפליקציות. הגדרות כאלה אפשריות, אבל צריך להוסיף את שרשרת האישורים ברמת הבסיס או ברמת הביניים ל-truststore המתאים. בדוגמה הזו, מאגרי ה-truststore של Cassandra צריכים להכיל אישורי בסיס או אישורי ביניים של הלקוח, ובמאגרי ה-truststore של אפליקציות הלקוח צריכה להיות שרשרת בסיס או שרשרת ביניים של צומתי Cassandra.
  3. בדומה לאמור למעלה, יכולות להיות לכם כמה קבוצות של אישורי בסיס ואישורי ביניים לאזורים שונים, אבל כל הלקוחות בכל האזורים וכל השרתים בכל האזורים צריכים להיות מודעים לכל שרשראות הבסיס והביניים. כדי לעשות את זה, צריך להוסיף את כולן ל-truststore שהוגדר.