פתרון בעיות בהצפנת נתונים שקופה

בחירת גרסת תיעוד:

בדף הזה מוסבר איך לפתור בעיות שקשורות להצפנת נתונים שקופה (TDE) ב-AlloyDB Omni.

אחזור יומנים לפתרון בעיות

כדי לפתור בעיות ב-TDE, אתם יכולים לאסוף יומנים בהתאם לסוג הפריסה.

אוספים את יומני ה-systemd של שירות AlloyDB Omni ומסננים הודעות שקשורות ל-TDE:

sudo journalctl -u alloydbomni18 | grep "TDE"

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

  • TDE: TdeContext initialization failed
  • TDE: Vault server unreachable
  • TDE: CipherTrust request failed
  • TDE: Certificate expired

תרחישי שגיאה

בקטע הזה מתוארים תרחישי שגיאות נפוצים שקשורים ל-TDE ומוצעים פתרונות לתיקון שלהם.

שגיאות JWT‏ (HashiCorp Vault)

אם ביומנים שנאספו מופיעות שגיאות שקשורות לאימות או לאתחול של HashiCorp Vault, הן לרוב קשורות לבעיות ב-JSON Web Token‏ (JWT).

תיאור

יכול להיות שיוצגו שגיאות כמו:

שגיאה תיאור סיבה
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 3, error message: JWT cannot be empty JWT לא נמצא או ריק אסימון ה-JWT חסר או ריק.
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 3, error message: Invalid JWT format. Expected JWS compact serialization (three dot-separated segments: header, payload, and signature) with base64url encoded values. פורמט JWT פגום הטוקן של JWT לא בפורמט הנכון של JWS compact serialization.
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 3, error message: Vault request failed with HTTP code: 400, Vault errors: ["error validating token: invalid expiration time (exp) claim: token is expired"] פג התוקף של ה-JWT פג התוקף של טוקן ה-JWT.
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 3, error message: Vault request failed with HTTP code: 400, Vault errors: ["error validating token: error verifying token signature: failed to verify id token signature"] חתימת JWT לא תקינה שרת Vault לא הצליח לאמת את החתימה של אסימון ה-JWT.
TDE: Failed to register Key Store with URL: VAULT_URL, error code: 9, error message: Failed to get Vault configuration parameter 'VAULT_JWT' בעיה בהרשאות ל-AlloyDB Omni אין הרשאה לקרוא את קובץ אסימון ה-JWT, או שמשתנה הסביבה VAULT_JWT לא מוגדר.

כדי לפתור בעיות שקשורות ל-JWT:

  1. אחזור ה-JWT הפעיל:

    מוודאים שהנתיב של אסימון ה-JWT מוגדר בסביבה או בהגדרת השירות, לדוגמה, ב-override.conf:

    cat PATH_TO_JWT_FILE

    מחליפים את PATH_TO_JWT_FILE בנתיב לאסימון ה-JWT במארח.

  2. בודקים את המבנה של JWT: מוודאים שהאסימון תקין ושהוא תואם לפורמט הסדרתי הדחוס של JWT.

  3. מאמתים את מצב הטוקן: מוודאים שהטוקן פעיל ולא פג תוקפו.

שגיאות בפרטי הכניסה ל-CipherTrust‏ (Thales CipherTrust Manager)

אם ביומנים שנאספו מופיעים כשלים באימות או באתחול של Thales CipherTrust Manager, בדרך כלל הם נגרמים בגלל פרטי כניסה חסרים או לא חוקיים של המשתמש (username ו-password).

תיאור

יכול להיות שיוצגו שגיאות כמו:

שגיאה תיאור סיבה
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 3, error message: CipherTrust user cannot be empty חסר שם משתמש משתנה הסביבה CIPHERTRUST_USER או המפתח username ב-Kubernetes Secret ריקים.
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 3, error message: CipherTrust password cannot be empty חסרה סיסמה משתנה הסביבה CIPHERTRUST_PASSWORD או המפתח password ב-Kubernetes Secret ריקים.
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 9, error message: Failed to get CipherTrust configuration parameter 'CIPHERTRUST_USER'
או
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 9, error message: Failed to get CipherTrust configuration parameter 'CIPHERTRUST_PASSWORD'		 משתנה הסביבה לא מוגדר משתנה הסביבה CIPHERTRUST_USER או CIPHERTRUST_PASSWORD חסר.
TDE: Failed to register Key Store with URL: CIPHERTRUST_URL, error code: 16, error message: CipherTrust request failed with HTTP code: 401 פרטי כניסה לא תקינים ה-username או ה-password נדחו על ידי נקודת הקצה לאימות של Thales CipherTrust Manager‏ (/api/v1/auth/tokens).

מוודאים שהערכים CIPHERTRUST_USER ו-CIPHERTRUST_PASSWORD מוגדרים ב-/etc/systemd/system/alloydbomni18.service.d/override.conf:

systemctl show alloydbomni18 -p Environment

שגיאות בכתובת ה-URL של ה-KMS

אם מסד הנתונים לא מצליח לבצע אתחול או הפעלה, יכול להיות שהסיבה לכך היא הגדרה שגויה של כתובת ה-URL של המפתח להצפנת מפתחות הצפנה (KEK) של Key Management Service ‏ (KMS).

תיאור

יכול להיות שיוצגו שגיאות כמו:

שגיאה תיאור סיבה
TDE: Failed to register Key Store with URL: KMS_URL, error code: 12, error message: Unsupported key store type סוג מאגר המפתחות לא נתמך השגיאה הזו מתרחשת כשפרוטוקול כתובת ה-URL של ה-KEK הוא לא vault או ciphertrust. לדוגמה, שימוש ב-http:// או ב-https:// במקום ב-vault:// או ב-ciphertrust://, או השמטה של הסכימה לחלוטין.
TDE: Failed to register Key Store with URL: KMS_URL, error code: 3, error message: Invalid Vault address format. Expected hostname or hostname:port
או
TDE: Failed to register Key Store with URL: KMS_URL, error code: 3, error message: Invalid CipherTrust address format. Expected hostname or hostname:port		 פורמט כתובת KMS לא חוקי השגיאה מתרחשת כשהפורמט של כתובת ה-KMS בחלק של כתובת ה-URL שגוי. לדוגמה, אם היא כוללת שוב את סכמת הפרוטוקול, כמו vault://https://vault.example.com:8200/... או ciphertrust://https://ciphertrust.example.com:443/....
TDE: Failed to read KEK, error code: 3, error message: Invalid key path format. Must start with '/', not end with '/', and contain only valid characters פורמט לא תקין של נתיב המפתח השגיאה הזו מתרחשת כשהפורמט של החלק של הנתיב בכתובת ה-URL של ה-KMS שגוי. הנתיב חייב להתחיל בקו נטוי / ולא יכול להסתיים בקו נטוי.
TDE: Failed to register Key Store with URL: KMS_URL, error code: 13, error message: curl_easy_perform() failed: Could not resolve hostname שגיאה בזיהוי שם המארח השגיאה הזו מתרחשת כשאי אפשר לזהות את שם המארח של ה-KMS בכתובת ה-URL של ה-KEK. זה יכול לקרות אם כתובת ה-URL לא תקינה או אם יש בעיה בהגדרת ה-DNS.
  • מאמתים את סכמת ה-URL של ה-KEK: מוודאים שכתובת ה-URL מתחילה ב-vault:// (ל-HashiCorp Vault) או ב-ciphertrust:// (ל-Thales CipherTrust Manager). אל תשתמשו ב-https:// בתור הקידומת.
    • נכון (Vault): vault://vault.example.com:8200/v1/secret/data/key
    • נכון (CipherTrust): ciphertrust://ciphertrust.example.com:443/api/v1/vault/secrets/key
    • לא נכון: https://vault.example.com:8200/v1/secret/data/key
  • בדיקת פורמט הכתובת: מוודאים שהמארח והיציאה מצוינים בצורה נכונה מיד אחרי הקידומת vault:// או ciphertrust://.
  • מוודאים שהפורמט של הנתיב תקין: מוודאים שהנתיב מתחיל ב-/ ושאין לוכסן בסוף (לדוגמה, משתמשים ב-/v1/secret/data/key ל-HashiCorp Vault או ב-/api/v1/vault/secrets/key ל-Thales CipherTrust Manager, בלי / בסוף).
  • אימות של רזולוציית המארח: מוודאים ששם המארח של KMS שצוין בכתובת ה-URL נכון, ושאפשר לפתור אותו מתוך שרת מסד הנתונים.

KEK not base64-encoded

אם מפתח ה-KEK שמאוחסן ב-KMS החיצוני לא מקודד בפורמט base64 בצורה נכונה, מערכת AlloyDB Omni לא מצליחה לפענח אותו בזמן השליפה. כתוצאה מכך, המערכת לא יכולה לפענח את המפתחות המקומיים להצפנת נתונים (DEK) וההפעלה נכשלת.

תיאור

יכול להיות שיופיעו שגיאות כמו אלה ביומני האבחון של מסד הנתונים (postgresql.log):

שגיאה תיאור סיבה
TDE: Failed to read KEK, error code: 13, error message: Error decoding base64 key string שגיאה בפענוח מחרוזת מפתח Base64 השגיאה הזו מתרחשת כשמנהל המפתחות מנסה לפענח את הסוד שאוחזר מה-KMS באמצעות Base64, אבל המחרוזת היא לא Base64 תקין.
  • אחזור ערך ה-KEK: מאחזרים ובודקים את ערך ה-KEK ישירות מ-KMS (HashiCorp Vault או Thales CipherTrust Manager).
  • עדכון הערך ב-KMS: ודאו שה-KEK שמאוחסן ב-KMS מקודד ב-base64. אם הוא מאוחסן כקובץ בינארי גולמי או כטקסט פשוט, צריך לעדכן את הערך ב-KMS לערך המקביל בקידוד Base64.
    1. ממירים את המפתח הגולמי ל-Base64:
      ‫
      echo -n "RAW_KEY" | base64
       מחליפים את <var>RAW_KEY</var> בערך המפתח הלא מקודד.
    2. מעדכנים את הסוד ב-KMS למחרוזת שנוצרה בקידוד Base64.

גרסת ה-KEK חסרה ב-KMS

השגיאה "גרסת ה-KEK חסרה" מתרחשת כש-AlloyDB Omni מנסה לפתוח את האריזה של מפתחות DEK מקומיים באמצעות גרסה היסטורית ספציפית של ה-KEK, אבל הגרסה הזו נמחקה, הושמדה או חסרה ב-KMS החיצוני. הבעיה הזו נפוצה בעיקר במהלך פעולות שחזור גיבוי או אתחול של עותק משוכפל במצב המתנה.

תיאור

יכול להיות שיופיעו שגיאות כמו אלה ביומני האבחון של מסד הנתונים (postgresql.log):

שגיאה תיאור סיבה
TDE: Failed to read KEK, error code: 5, error message: Vault request failed with HTTP code: 404, Response body: {... "destroyed":true, "version":4 ...}
או
TDE: Failed to read KEK, error code: 5, error message: CipherTrust request failed with HTTP code: 404, CipherTrust error: "NCERRResourceNotFound: ..."		 גרסת המפתח חסרה או הושמדה גרסת ה-KEK המבוקשת חסרה, נמחקה או הושמדה באופן סופי ב-KMS.
  • אימות גרסת ה-KEK ב-KMS: מוודאים שגרסת ה-KEK המבוקשת קיימת ופעילה (לא נמחקה או הושמדה) ב-KMS.
  • שחזור של גרסת KEK חסרה: שחזור או ביטול מחיקה של גרסת ה-KEK המבוקשת ב-KMS אם היא נמחקה אבל לא הושמדה.
  • טיפול במפתחות שהושמדו: אם גרסת המפתח המבוקשת מושמדת באופן סופי ב-KMS, לא ניתן לשחזר באופן סופי את הנתונים או את הגיבוי שהוצפנו באמצעות הגרסה הזו.

אישורי TLS או SSL לא תקינים או חסרים

השגיאה 'אישור TLS או SSL פגום או חסר' מתרחשת כש-AlloyDB Omni לא מצליח ליצור חיבור TLS מאובטח ל-KMS חיצוני (HashiCorp Vault או Thales CipherTrust Manager) כי האישורים חסרים, פג תוקפם, הם לא מהימנים או שהם הוגדרו בצורה שגויה.

תיאור

יכול להיות שיופיעו שגיאות כמו אלה ביומני האבחון של מסד הנתונים (postgresql.log):

שגיאה תיאור סיבה
TDE: Failed to read KEK, error code: 13, error message: curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK
או
TDE: Failed to read KEK, error code: 13, error message: curl_easy_perform() failed: Peer certificate cannot be authenticated with given CA certificates		 אימות האישור של שרת ה-KMS נכשל אי אפשר לאמת את האישור של שרת ה-KMS באמצעות אישור ה-CA שסופק.
TDE: Failed to register Key Store with URL: KMS_URL, error code: 13, error message: curl_easy_perform() failed: Problem with the local SSL certificate בעיה באישור SSL מקומי השגיאה הזו מתרחשת אם נדרש אישור לקוח ויש בו בעיות.

כדי לפתור בעיות באימות TLS, ודאו שהאישורים הנכונים סופקו, הותקנו וניתנים לקריאה על ידי המשתמש postgres.

ב-Linux, האישורים צריכים להיות בנתיב שצוין במשתנה הסביבה VAULT_CERT_PATH (ל-HashiCorp Vault) או CIPHERTRUST_CERT_PATH (ל-Thales CipherTrust Manager).

  1. מוודאים שהערך של VAULT_CERT_PATH או CIPHERTRUST_CERT_PATH מוגדר נכון בסביבה או בשינוי ברירת המחדל של השירות:

    systemctl show alloydbomni18 -p Environment

  2. בודקים שקובצי האישורים קיימים ושהמשתמש postgres יכול לקרוא אותם:

    ls -la CERT_PATH

    מוודאים ששמות הקבצים ca.crt, ‏tls.crt ו-tls.key קיימים ושיש להם הרשאות קריאה למשתמש postgres.

מחליפים את CERT_PATH בנתיב לספריית אישורי ה-TLS במארח (לדוגמה, /tde-tls).