הצפנה במנוחה מול הצפנה בתעבורה: שתי הגנות שאף אחת לא מספיקה לבד

מאת צוות מדיה דיל · 03.07.2026 · אבטחת מידע · 4 דק׳

TLS ו-Encryption in Transit, הצפנת דיסק ומסד נתונים At Rest, הפער בזיכרון בזמן עיבוד, ניהול מפתחות עם KMS, והגנה על Backups.

"המידע שלנו מוצפן" היא משפט שנשמע כמו הבטחה שלמה, אבל בפועל היא תשובה לשאלה אחת מתוך שתיים שונות לגמרי: הצפנה בתעבורה (in transit) מגנה על המידע בזמן שהוא זז בין שני קצוות - דפדפן לשרת, שירות לשירות - ואילו הצפנה במנוחה (at rest) מגנה על אותו מידע כשהוא יושב בשקט על דיסק, בגיבוי, או בתוך מסד נתונים. תוקף שגונב backup לא נעצר על ידי TLS, ותוקף שמיירט תעבורה ברשת לא נעצר על ידי הצפנת דיסק - ולכן מערכת שמסתמכת רק על אחת מהשתיים משאירה חצי מהמשוואה חשופה לחלוטין.

Encryption in Transit - TLS ומה שהוא לא פותר

TLS מגן על התוכן מפני מי שיושב על הרשת בין שני הצדדים - ספק אינטרנט, נקודת Wi-Fi ציבורית, כל man-in-the-middle פוטנציאלי - ומוודא גם שלא שינו את התוכן בדרך. אבל TLS נגמר ברגע שהבקשה מגיעה לשרת: מרגע שהמידע פוענח בקצה השרת הוא זמין בפורמט קריא לכל תהליך שרץ שם, ואם אותו מידע נשמר אחר כך למסד נתונים בלי הצפנה נוספת, TLS לא נתן שום הגנה על מה שקורה אחריו. הצפנה בתעבורה עונה רק על "מי ראה את זה בדרך", לא על "מי יכול לגשת אליו עכשיו".

Encryption at Rest - מה שקורה כשהמידע נח

הצפנה במנוחה חלה ברמות שונות: הצפנת דיסק מלאה (full-disk encryption) שמגנה אם מישהו גונב פיזית את השרת, הצפנה ברמת מסד הנתונים (Transparent Data Encryption) שמגנה גם אם קובץ הדאטהבייס עצמו דולף, והצפנה ברמת שדה בודד (field-level) לנתונים רגישים במיוחד כמו מספרי כרטיס אשראי. backups דורשים תשומת לב מיוחדת - הם לרוב נשמרים לתקופה ארוכה יותר, לפעמים אצל ספק חיצוני, והם יעד אטרקטיבי לתוקף בדיוק כי אף אחד לא בודק אותם באותה תדירות כמו את ה-production database הפעיל.

הפער האמצעי - מה קורה בזיכרון ובזמן עיבוד בפועל

בין "בתעבורה" ל"במנוחה" יש שלב שלישי שנשכח לעיתים קרובות - זמן העיבוד עצמו, כשהמידע מפוענח בזיכרון ה-RAM כדי שהאפליקציה תוכל לעבוד איתו. גישה לזיכרון תהליך רץ (דרך core dump, debugger מחובר, או חולשת memory disclosure) חושפת את המידע גם אם הוא מוצפן היטב בכל שאר השלבים. Confidential Computing, המבוסס על enclaves מבודדות בחומרה, מנסה לסגור בדיוק את הפער הזה - אבל ברוב המערכות בפועל, השלב הזה נשען פשוט על בקרת גישה קפדנית לתהליך ולזיכרון.

ניהול מפתחות - החוליה שקובעת אם ההצפנה שווה משהו בכלל

הצפנה חזקה עם ניהול מפתחות רשלני שקולה בפועל לאין הצפנה - אם המפתח שמפענח את הדיסק המוצפן יושב בקובץ תצורה באותו שרת, כל תוקף שמשיג גישה לשרת מקבל גם את המפתח וגם את הדאטה המוצפנת בו-זמנית. שירותי KMS ייעודיים (AWS KMS, HashiCorp Vault) שומרים את המפתחות מופרדים פיזית ולוגית מהמידע עצמו, אוכפים רוטציה תקופתית, ומתעדים כל שימוש במפתח ב-audit log. זה בדיוק החלק שקשור לניהול סודות ארגוני רחב יותר, לא רק להצפנה עצמה.

תרחיש שממחיש למה צריך את שתיהן ביחד

דמיינו אתר שמצפין תעבורה היטב עם TLS 1.3 מקצה לקצה, אבל שומר backup יומי של מסד הנתונים לא מוצפן ב-storage bucket עם הרשאות שגויות - ההצפנה בתעבורה חסרת ערך לגמרי מול תוקף שמצא את ה-bucket הפתוח. באותה מידה, מסד נתונים מוצפן היטב במנוחה לא עוזר כלום אם ה-API שניגש אליו רץ על HTTP רגיל ומעביר תוצאות שאילתה בטקסט גלוי ברשת ציבורית. רק שילוב של שתי השכבות, יחד עם ניהול מפתחות תקין, נותן הגנה עסקית מלאה על המידע לאורך כל מחזור החיים שלו.

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

תגיות: Encryption at Rest · Encryption in Transit · TLS · KMS · Key Management · Data Protection

← חזרה לבלוג · צור קשר