יצירת תמונות מוגנות בהתאמה אישית

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

כברירת מחדל, מכונה וירטואלית מוגנת תומכת ב-מערכת הפעלה שמותאמת לקונטיינרים, בהפצות שונות של Linux ובגרסאות שונות של Windows Server. אבל אם אתם צריכים תמונות בהתאמה אישית לאפליקציה שלכם, עדיין תוכלו להשתמש ב-Shielded VM.

הכנת הדיסק

מכונה וירטואלית מוגנת מסתמכת על קושחה שתואמת ל-Unified Extensible Firmware Interface ‏(UEFI) כדי לתמוך בתכונות כמו אתחול מאובטח. מכונה וירטואלית מוגנת דורשת סכימת טבלת מחיצות GUID ‏ (GPT); אין תמיכה ברשומת אתחול ראשית (MBR).

בדיסק צריכות להיות לפחות שתי מחיצות:

מחיצת מערכת EFI‏ (ESP): נפח של 100 מגה-בייט (MB) מספיק למחיצה הזו, וזה רק הצעה. במקרה הצורך, אפשר ליצור מחיצה גדולה יותר. הדרישה היחידה לגבי ESP היא שהיא תעבור עיצוב עם מערכת קבצים מסוג File Allocation Table ‏ (FAT).
מחיצת מערכת ההפעלה: שאר נפח האחסון בדיסק. המחיצה הזו מכילה את מערכת ההפעלה לאתחול (Linux או Windows). אין הגבלה על גודל המחיצה הזו.

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

העתקת מערכת ההפעלה למחיצת מערכת ההפעלה

אחרי שמפרמטים את הדיסק ומחלקים אותו למחיצות בצורה נכונה, מעתיקים את קובצי מערכת ההפעלה למחיצת מערכת ההפעלה. למערכת ההפעלה יש טוען אתחול שצריך להיות ממוקם בנתיב תקין ב-ESP, כמו שמוגדר במפרט UEFI: \EFI\Boot\bootx64.efi. הערה: יכול להיות שיהיה צורך להעתיק את טוען האתחול של מערכת ההפעלה למיקום שצוין.

ב-Windows, יש פקודה בשם bcdboot שאפשר להשתמש בה כדי להעתיק את טוען האתחול של מערכת ההפעלה למיקום הנכון, בנוסף לפעולות אחרות שנדרשות ב-Windows (כמו העתקה של מאגר ה-BCD). מידע נוסף זמין במאמר BCDBoot Command-Line Options (אפשרויות של שורת הפקודה BCDBoot) ב-Microsoft Hardware Dev Center (מרכז פיתוח חומרה של מיקרוסופט).

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

מודול פלטפורמה מהימן וירטואלי (vTPM)

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

כדי להשתמש ב-vTPM ובאתחול מדוד, נדרש מנהל התקן. הגרסאות המינימליות של מערכת ההפעלה עם תמיכה ב-TPM 2.0 הן:

Windows Server 2012
גרסה 3.20 של Linux
‫Red Hat Enterprise Linux 7.3

מעקב אחר תקינות

התכונה 'מעקב אחר תקינות' מאפשרת להבין את המצב של מכונות וירטואליות (VM) ולקבל החלטות לגביו. ‫Monitoring משתמש בנתונים שנוצרו על ידי Measured Boot כדי לדווח על מופע המכונה הווירטואלית. בתיעוד של מכונות וירטואליות מוגנות יש מידע נוסף על מעקב אחר תקינות ועל אוטומציה של תגובות לכשלים באימות התקינות.

כדי לתמוך בתכונה 'מעקב אחר שלמות המכונה' במכונות וירטואליות מוגנות, התמונה צריכה ליצור אותות שלמות:

מערכת Windows יוצרת אותות יושרה כברירת מחדל.
ב-Linux צריך להתקין ולהפעיל את מודול Integrity Measurement Architecture (IMA). הערך של CONFIG_IMA_MEASURE_PCR_IDX במודול צריך להיות 10. זהו ערך ברירת המחדל של מודול IMA.

ייבוא תמונת הדיסק אל Compute Engine

אחרי שהתמונה מוכנה, צריך להעלות אותה ל-Compute Engine. לשלבים הנדרשים להעלאת התמונה אלGoogle Cloud, אפשר לעיין במאמר ייבוא תמונות של דיסק הפעלה אל Compute Engine.

הגדרת אישורים ל-Secure Boot

כשמוסיפים תמונה של מכונה וירטואלית מוגנת, קבוצה של אישורים ומסדי נתונים ציבוריים של Secure Boot מועברים אל Compute Engine. הקבצים האלה מאוחסנים במשתני ה-UEFI המתאימים ומשמשים ליצירת יחסי אמון בין הפלטפורמה, הקושחה ומערכת ההפעלה. האישורים הם אישורי X.509 בקידוד Distinguished Encoding Rules‏ (DER). מסדי הנתונים יכולים להיות אישור או קובץ בינארי גולמי. יש 4 ערכים בסך הכול:

מפתח פלטפורמה (pk): מפתח שמשמש ליצירת יחסי אמון בין בעלי הפלטפורמה לבין הקושחה. אפשר לציין רק מפתח אחד של הפלטפורמה, והוא חייב להיות אישור X.509 תקין.
מפתח להחלפת מפתחות (kek): מפתח שמשמש ליצירת יחסי אמון בין הקושחה לבין מערכת ההפעלה. אפשר לציין כמה מקשים לערך הזה.
מסד נתונים של מפתחות אסורים (dbx): מסד נתונים של אישורים שבוטלו, ואם קובץ אתחול נחתם באמצעות אחד מהם, המערכת תפסיק את האתחול. אפשר לציין ערך אחד או כמה ערכים.
מסד נתונים של מפתחות (db): מסד נתונים של אישורים מהימנים שאפשר להשתמש בהם לחתימה על קובצי אתחול. אפשר לציין ערך אחד או כמה ערכים.

במפרט UEFI יש מידע נוסף על הערכים האלה ועל אופן הפעולה שלהם.

בדוגמה הבאה נעשה שימוש ב-OpenSSL כדי ליצור את המפתחות והאישורים של אתחול מאובטח.

יצירת זוג מפתחות RSA של 2048 ביט
```
openssl genrsa -out secure-boot-key.rsa 2048
```

יצירת אישור X.509 בחתימה עצמית מהמפתח בפורמט DER

openssl req -new -x509 -sha256 \
    -subj '/CN=secure-boot' \
    -key secure-boot-key.rsa \
    -outform DER \
    -out secure-boot-cert.pem

הוספת התמונה המוגנת אל Google Cloud

אחרי שמעלים את התמונה והאישורים, אפשר להוסיף את התמונה ל-Compute Engine. אפשר להוסיף את התמונה באמצעות Google Cloud CLI או Compute Engine API.

gcloud

מוסיפים את התמונה המותאמת אישית ל-Compute Engine:

gcloud compute images create [IMAGE_NAME] \
    --source-disk [SOURCE_DISK] \
    --source-disk-zone [ZONE] \
    --platform-key-file= \
    --key-exchange-key-file= \
    --signature-database-file=, \
    --forbidden-database-file= \
    --guest-os-features="UEFI_COMPATIBLE[,WINDOWS]"

where:

‫[IMAGE_NAME] הוא השם של קובץ האימג' החדש.
‫[SOURCE_DISK] הוא הדיסק שממנו רוצים ליצור את התמונה החדשה.
‫[ZONE] הוא האזור שבו הדיסק נמצא.

האפשרות WINDOWS עבור guest-os-features נדרשת רק כשמשתמשים בתמונה של Windows. מידע נוסף על יצירת תמונה זמין במאמר בנושא gcloud create.

REST

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

...
"sourceDisk": "/zones/[ZONE]/disks/[SOURCE_DISK]",

"initial_state_config": {
    "pk": {
        "content": [KEY],
        "fileType": [BIN,X509]
    },
    "keks": [
        {
            "content": [KEY],
            "fileType": [BIN,X509]
        },
        ...
    ],
    "dbxs": [
        {
            "content": [KEY],
            "fileType": [BIN,X509]
        },
        ...
    ],
    "dbs": [
        {
            "content": [KEY],
            "fileType": [BIN,X509]
        },
        ...
    ]
}

אישורי ברירת מחדל

שימו לב שהשדות pk, keks, dbxs ו-dbs הם אופציונליים. אם מספקים הגדרת מצב ראשוני, יכול להיות שחלק מהשדות האלה או כולם לא יוגדרו. כשיוצרים מופע חדש מהתמונה, Google Cloud מספק ערך ברירת מחדל ל-PK, ל-KEK, ל-db ול-dbx, אלא אם הוגדר ערך מותאם אישית בשדה כלשהו שלא הוגדר. אם לא מספקים הגדרות של מצב התחלתי (כלומר, ההגדרה חסרה ולא רק ריקה), לתמונה יהיו הגדרות של מצב התחלתי כמו לתמונת המקור.

ערכי ברירת המחדל של השדות האלה הם:

‫PK: האישור שמשויך למפתח הפרטי שנוצר כברירת מחדל על ידי Google.
‫KEK: אישורי ברירת המחדל של Microsoft KEK.
- ‫MicCorKEKCA2011_2011-06-24.crt: אפשר להוריד מ-Microsoft או מ-GitHub.
  
  SHA-1: 31590bfd89c9d74ed087dfac66334b3931254b30
- ‫microsoft corporation kek 2k ca 2023.der: אפשר להוריד מ-Microsoft או מ-GitHub.
  
  SHA-1: 459ab6fb5e284d272d5e3e6abc8ed663829d632b
‫dbx: רשימת הביטול של Microsoft DBX שמוגדרת כברירת מחדל. הורדה מ-Unified Extensible Firmware Interface Forum: קובץ רשימת הביטולים של UEFI
‫db: ארבעת האישורים הבאים:
- ‫MicWinProPCA2011_2011-10-19.der: אפשר להוריד מ-Microsoft או מ-GitHub.
  
  SHA-1: 580a6f4cc4e4b669b9ebdc1b2b3e087b80d0678d
- ‫MicCorUEFCA2011_2011-06-27.der: אפשר להוריד מ-Microsoft או מ-GitHub.
  
  SHA-1: 46def63b5ce61cf8ba0de2e6639c1019d0ed14f3
- ‫microsoft uefi ca 2023.der: אפשר להוריד מ-Microsoft או מ-GitHub.
  
  SHA-1: b5eeb4a6706048073f0ed296e7f580a790b59eaa
- ‫windows uefi ca 2023.der: אפשר להוריד מ-Microsoft או מ-GitHub.
  
  SHA-1: 45a0fa32604773c82433c3b7d59e7466b3ac0c67

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