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

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

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

הכנת הדיסק

מכונה וירטואלית מוגנת מסתמכת על קושחה שתואמת ל-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) הוא מכשיר ייעודי להגנה על אובייקטים, כמו מפתחות ואישורים, שבהם אתם משתמשים כדי לאמת את הגישה למערכת. באימג'ים של מכונות וירטואליות מוגנות, נעשה שימוש בגרסאות וירטואליות של מכשירי TPM כדי להפעיל אתחול מדוד. בקיצור, אתחול מדוד מבטיח את התקינות של נתיב הטעינה הקריטי של מנהלי ההתקנים של האתחול והליבה. פרטים נוספים על vTPM ועל אתחול מדוד זמינים במאמרי העזרה בנושא מכונות וירטואליות מוגנות.

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

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

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

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

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

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

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

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

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

אי אפשר להוסיף אישורים ישירות למשתני UEFI של Compute Engine באמצעות כלי כמו mokutil. הסיבה היא שתפריטי הניהול האינטראקטיביים של UEFI ו-MOK לא תומכים בקלט של מסוף טורי ב- Cloud de Confiance by S3NS. במקום זאת, מוסיפים אישורים למסד נתונים של מפתחות כשיוצרים תמונה של מכונה וירטואלית מוגנת.

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

המסד נתונים יכול להיות אישור או קובץ בינארי גולמי. יש ארבעה ערכים בסך הכול:

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

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

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

  • יצירת זוג מפתחות 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

הוספת התמונה המוגנת אל Cloud de Confiance by S3NS

אחרי שמעלים את התמונה והאישורים, אפשר להוסיף את התמונה ל-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 הם אופציונליים. אם מספקים הגדרת מצב ראשוני, יכול להיות שחלק מהשדות האלה או כולם לא יוגדרו. כשיוצרים מכונה חדשה מהתמונה, Cloud de Confiance מספק ערך ברירת מחדל ל-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 שמוגדרת כברירת מחדל. הורדה מפורום ממשק קושחה מאוחד וניתן להרחבה: קובץ רשימת הביטולים של 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

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