הגדרת הצפנת LUKS לדיסקים בשרתים כפתרון כולל

הצפנת דיסקים עם LUKS: היכן נשברת הגנת הנתונים

הצפנת דיסקים בשרת כמעט לעולם אינה נשברת באלגוריתם עצמו — AES-256 במצב XTS פועל באופן צפוי, וכוח גס כאן אינו רלוונטי. הבעיה היא במקום אחר: הגנת הנתונים בשרת קורסת בגלל טעויות ארגוניות סביב הקריפטוגרפיה. שלושה תרחישים נפוצים ביותר.

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

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

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

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

מה נותן הצפנת דיסקים מנוהלת

קיצור זמן ההתאוששות

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

ביטול מחלקת הכשלים הקשורים לדליפת נתונים

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

עלות מוגדרת מראש של זמן השבתה

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

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

הגנת נתונים ללא אובדן יכולת הניהול

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

השוואת מצבי הצפנה: LUKS1, LUKS2 וחלופות

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

מה משתנה בפועל

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

היכן הטעות הנפוצה ביותר

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

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

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

1. ביקורת תשתית. אוספים מפת דיסקים ומחיצות, קובעים מה מצפינים — מחיצת השורש, כרכים נפרדים של נתונים או הכול יחד. מתעדים את סכימת האתחול הנוכחית, קיומו של /boot ייעודי, סוג הקושחה ואמצעי הניהול מרחוק. בשלב זה מבררים אם קיימים כבר RAID תוכנתי ו-LVM — מכך תלוי סדר השכבות.
2. תכנון הסכימה. בוחרים אלגוריתם ומצב, מתכננים את החלוקה ואת מיקום כותרות LUKS, קובעים היכן יאוחסן חומר המפתח. בנפרד מפתחים תרחיש לשחרור נעילה מרחוק: בלעדיו, אתחול מחדש של השרת במרכז הנתונים משמעו הגעה פיזית.
3. הגדרת ההצפנה. פורסים כרכים מוצפנים, מעבירים נתונים, מגדירים חיבור אוטומטי דרך crypttab ו-fstab. עבור שרתים חדשים מצפינים בשלב ההתקנה, ועבור פעילים — מעבירים נתונים לכרך מוצפן ללא אובדן זמינות.
4. אינטגרציה עם האתחול. מגדירים שחרור נעילה בעת העלייה: הזנת סיסמה דרך הקונסולה, קובץ מפתח על אמצעי חיצוני או מנגנון רשתי. בודקים שהשרת עולה לאחר אתחול מחדש ללא התערבות ידנית.
5. בדיקה וטסטים. מריצים תרחישים: אתחול מחדש שגרתי, כיבוי חירום, שחזור מגיבוי, ביטול והחלפת מפתח. מוודאים שהנתונים על הדיסק אינם קריאים ללא המפתח ושהגישה ניתנת לשחזור.
6. מסירה ותיעוד. מוסרים את סכימת החלוקה, הקונפיגורציות, סדר הפעולות בעת תקלה והוראות עבודה עם מפתחות. מאמנים את הצוות שלכם, כדי שפעולות שגרה לא ידרשו אותנו.

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

מה הלקוח מקבל לאחר ההטמעה

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

• תצורות הצפנה — קונפיגים עובדים של LUKS עבור מחיצת השורש, הנתונים וה-swap: בחירת צופן ומצב, פרמטרים של גזירת מפתח, הצמדה לדיסקים ולמחיצות ספציפיים. הכול ניתן לשחזור: התקנה מחדש או החלפת צומת אינן מחייבות לבחור מחדש את הפרמטרים.
• תרשימי פריסה — מפה של איזה כרך מוצפן, כיצד בנויה האתחול (‏/boot נפרד ולא מוצפן), אילו מחיצות עולות אוטומטית ואילו נפתחות ידנית. התרשים מסיר את השאלה "מה יקרה בעת אתחול מחדש" לפני שהיא מתעוררת בשטח.
• מדיניות גישה למפתחות — מי ובאמצעות מה מקבל גישה לכרכים המוצפנים: הפרדת תפקידים, עבודה עם אמצעי אחסון חיצוניים של מפתחות, סדר הזנת ביטוי הסיסמה בעת האתחול, כללי רוטציה. בנפרד מתעדים מה לעשות בעת אובדן גישה וכיצד הדבר אינו חוסם שחזור.
• נהלי תפעול — נהלים שלב-אחר-שלב: רוטציית מפתחות מתוכננת, הוספה והוצאה של דיסק ממערך מוצפן, כיבוי תקין ואתחול חירום. הנהלים מתארים גם את הצד ההפוך — כיצד להסיר הצפנה בבטחה אם המתחם משנה ייעוד.
• תיעוד והעברת ידע — הנחיות למשמרת התורן ולמנהלים, תרשים שחזור גישה, רשימת בדיקה לאחר שינויים. הצוות שלכם יכול לתחזק את ההצפנה בעצמו, בלי לפנות אלינו בכל צעד.
• סקריפטים לאוטומציה — פתיחת כרכים בעת עלייה, בדיקת מצב המחיצות המוצפנות, התראות בעת חריגות. פעולות ידניות שקל לשכוח הומרו לתרחישים צפויים.
• דוח בדיקה — תוצאות בדיקות בתרחישים אמיתיים: אתחול לאחר הפסקת חשמל, שחזור גישה, התנהגות בעת אובדן מפתח. מאשר שההגנה עובדת, ולא רק מוגדרת.

כל סעיף הוא משהו שניתן להעביר למהנדס אחר ולקבל את אותה תוצאה. תארו את המתחם שלכם — נחזור עם הערכה ותוכנית הטמעה.

מקרה בוחן: כיצד מנענו סיכון לדליפת נתונים

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

מה עשינו

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

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

מדדים לפני ואחרי

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

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

במה שונה LUKS2 מ-LUKS1 ומה לבחור?

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

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

ההבדל השני — אלגוריתמים לגזירת מפתח ולהצפנה. LUKS2 תומך ב-Argon2, אשר עמיד בפני ניסיונות פיצוח בכרטיסי מסך ומאפשר עלות גזירת מפתח הניתנת להתאמה לחומרה מסוימת; LUKS1 עובד רק עם PBKDF2, והפרמטרים שלו יש להעלות ידנית, תוך התנגשות בזמן ההמתנה לפתיחה בעת האתחול.

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

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

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

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

ספקות טכניים ותשובות להם

האם זה תואם לתשתית ולמנהל האתחול הנוכחיים?

LUKS פועל מעל התקן בלוקים ואינו תלוי במערכת הקבצים — ext4, XFS, ZFS מסתדרים איתו באופן תקין. הניואנס העיקרי הוא האתחול: כרך השורש דורש מחיצת /boot נפרדת שאינה מוצפנת או חיבור ל-TPM, כדי שהמכונה תעלה ללא הזנת סיסמה ידנית.

עבור LVM, RAID ודיסקים בענן הסכימה גם כן עובדת, אך את סדר השכבות (הצפנה לפני או אחרי RAID) אנו בוחרים בהתאם למשימה — מכך תלויים גם עמידות בכשלים וגם נוחות התחזוקה.

מה יקרה אם המפתח יאבד או שהדיסק יכשל?

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

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

האם יהיה צורך לבנות מחדש את השרתים ולעצור שירותים?

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

נדון במשימה שלכם להגנת נתונים

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית עבודה. כדי שהשיחה תהיה עניינית, כדאי להבין מראש:

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

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

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