הגדרת 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, בלי להשתמש ברשת שירותים חיצונית.

תכונת 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.

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

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

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

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

אם יש מפתח או אישור ביניים משותף באשכול אחד, אפשר להגדיר מאגר אישורים משותף (שכולל את אותו שרשרת אישורים בסיסיים ואישורי ביניים) בכל צומת של 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. יוצרים זוג מפתחות/אישורים מסוג עלה של צומת Cassandra אחד, חותמים עליו, מאחסנים אותו במאגר מפתחות ומגדירים את Cassandra ל-mTLS אופציונלי. חוזרים על השלבים לכל צומת של Cassandra, אחד בכל פעם.
  3. יוצרים זוג מפתח/אישור עלים של אפליקציית לקוח אחת, חותמים עליו, מאחסנים אותו במאגר מפתחות ומגדירים את אפליקציית הלקוח ל-mTLS. חוזרים על השלבים בכל אפליקציית לקוח, אחת בכל פעם. אפליקציות לקוח:
    1. edge-management-server
    2. edge-message-processor
    3. edge-router

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

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

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

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

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

  1. בחירת צומת Cassandra
  2. יוצרים זוג של מפתח ואישור עלים וחותמים עליו באמצעות אישור הביניים. מאחסנים את המפתח ואת האישור החתום ב-keystore. דוגמה: 
    
# 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

    ממקמים את קובצי מאגר המפתחות ומאגר האישורים במיקום מסוים בצומת, ומוודאים שמשתמש 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

    בנוסף, במערכות הפעלה עם FIPS מופעל, מוסיפים את המאפיין הבא לקובץ /opt/apigee/customer/application/cassandra.properties: 

    conf_cassandra_client_encryption_protocol=TLSv1.2

    מוודאים שמשתמש 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
  • edge-router

  1. בחירת רכיב לקוח
  2. יוצרים זוג של מפתח ואישור עלים וחותמים עליו באמצעות אישור הביניים. מאחסנים את המפתח ואת האישור החתום ב-keystore. דוגמה: 
    
# 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

    ממקמים את קובצי מאגר המפתחות ומאגר האישורים במיקום מסוים בצומת, ומוודאים שמשתמש 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, ‏ 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
    • edge-router
    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. חוזרים על שלבים א' עד ד' בכל אפליקציית לקוח, אחת בכל פעם.
  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

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

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

# 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 נחתמים. באופן דומה, לכל אפליקציות הלקוח יכול להיות סט נפרד של אישורי בסיס או אישורי ביניים לחתימה על אישורי עלים של אפליקציות. הגדרות כאלה אפשריות, אבל הן כוללות הוספה של שרשרת אישורים של בסיס/ביניים למאגר האישורים המתאים. בדוגמה הזו, מאגרי האישורים של Cassandra צריכים להכיל אישורים בסיסיים או אישורי ביניים של הלקוח, ובמאגר האישורים של אפליקציות הלקוח צריכה להיות שרשרת של אישורים בסיסיים או אישורי ביניים של צמתי Cassandra.
  3. בדומה לאמור למעלה, יכול להיות שיש לכם מספר קבוצות של אישורי בסיס ואישורי ביניים לאזורים שונים, אבל צריך להוסיף את כל שרשראות אישורי הבסיס ואישורי הביניים למאגר האישורים המוגדר כדי שכל הלקוחות בכל האזורים וכל השרתים בכל האזורים יכירו אותן.