הגדרת גישה למקור: Microsoft Azure Storage

לפני העברת נתונים מקטגוריה ב-Azure Storage, צריך להגדיר גישה לקטגוריה הזו כדי ש-Storage Transfer Service יוכל לאחזר את האובייקטים שלה.

‫Storage Transfer Service תומך בשיטות האימות הבאות של Azure:

במסמך הזה יש גם מידע על הוספת כתובות IP של עובדים ב-Storage Transfer Service לחומת האש של Azure Storage כדי לאפשר גישה. פרטים נוספים מופיעים במאמר בנושא הגבלות על כתובות IP.

אזורים נתמכים

‫Storage Transfer Service יכול להעביר נתונים מהאזורים הבאים של Microsoft Azure Storage:
  • אמריקה: מזרח ארה"ב, מזרח ארה"ב 2, מערב ארה"ב, מערב ארה"ב 2, מערב ארה"ב 3, מרכז ארה"ב, צפון מרכז ארה"ב, דרום מרכז ארה"ב, מערב מרכז ארה"ב, מרכז קנדה, מזרח קנדה, דרום ברזיל
  • אסיה והאוקיינוס השקט: אוסטרליה מרכזית, אוסטרליה מזרחית, אוסטרליה דרום-מזרחית, הודו מרכזית, הודו דרומית, הודו מערבית, דרום-מזרח אסיה, מזרח אסיה, יפן מזרחית, יפן מערבית, קוריאה דרומית, קוריאה מרכזית
  • אירופה, המזרח התיכון ואפריקה (EMEA): צרפת מרכזית, גרמניה מערב מרכזית, נורווגיה מזרחית, שוודיה מרכזית, שווייץ צפונית, צפון אירופה, מערב אירופה, בריטניה דרומית, בריטניה מערבית, קטאר מרכזית, איחוד האמירויות הערביות צפונית, דרום אפריקה צפונית

אפשרות 1: אימות באמצעות טוקן SAS

כדי להגדיר גישה למאגר Microsoft Azure Storage באמצעות אסימון SAS, צריך לפעול לפי השלבים הבאים. אפשר גם לשמור את אסימון ה-SAS ב-Secret Manager. כדי לעשות זאת, פועלים לפי ההוראות במאמר אימות באמצעות מפתח משותף או אסימון SAS של Azure ב-Secret Manager.

  1. יוצרים משתמש ב-Microsoft Azure Storage או משתמשים במשתמש קיים כדי לגשת לחשבון האחסון של קונטיינר ה-Blob ב-Microsoft Azure Storage.

  2. יוצרים טוקן SAS ברמת המאגר. הוראות מפורטות זמינות במאמר Grant limited access to Azure Storage resources using shared access signatures.

    1. השירותים המותרים חייבים לכלול את Blob.

    2. בקטע Allowed resource types (סוגי משאבים מותרים), בוחרים באפשרות Container (מאגר) וגם באפשרות Object (אובייקט).

    3. ההרשאות המותרות חייבות לכלול את ההרשאות קריאה והצגת רשימה. אם ההעברה מוגדרת למחיקת אובייקטים מהמקור, צריך לכלול גם את ההרשאה מחיקה.

    4. ברירת המחדל של זמן התפוגה של אסימוני SAS היא 8 שעות. כדאי להגדיר זמן תפוגה סביר שיאפשר לכם להשלים את ההעברה בהצלחה.

    5. אל תציינו כתובות IP בשדה כתובות IP מותרות. Storage Transfer Service משתמש בכתובות IP שונות ולא תומך בהגבלת כתובות IP.

    6. ההגדרה פרוטוקולים מותרים צריכה להיות HTTPS בלבד.

  3. אחרי שיוצרים את הטוקן, צריך לשים לב לערך של טוקן SAS שמוחזר. תצטרכו את הערך הזה כשמגדירים את ההעברה באמצעות Storage Transfer Service.

אפשרות 2: אימות באמצעות מפתח משותף של Azure או אסימון SAS ב-Secret Manager

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

‫Storage Transfer Service תומך בשמות משאבים של Secret Manager שמפנים לפרטי הכניסה שלכם ב-Azure שמאוחסנים בצורה מאובטחת.

כדי להשתמש במפתח משותף של Azure, צריך לשמור את המפתח ב-Secret Manager. אפשר לשמור את אסימוני ה-SAS ב-Secret Manager או להעביר אותם ישירות.

כשמציינים מפתח משותף, Storage Transfer Service משתמש במפתח הזה כדי ליצור SAS של שירות שההיקף שלו מוגבל לקונטיינר של Azure שצוין בעבודת ההעברה.

הפעלת ה-API

מפעילים את Secret Manager API.

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

להפעלת ה-API

הגדרת הרשאות נוספות

הרשאות של משתמשים

המשתמש שיוצר את הסוד צריך להיות בעל התפקיד הבא:

  • אדמין של Secret Manager‏ (roles/secretmanager.admin)

איך נותנים תפקיד

הרשאות של סוכן שירות

סוכן השירות של Storage Transfer Service צריך את תפקיד ה-IAM הבא:

  • Secret Manager Secret Accessor (roles/secretmanager.secretAccessor)

כדי להעניק את התפקיד לסוכן השירות:

מסוף Cloud

  1. פועלים לפי ההוראות כדי לאחזר את כתובת האימייל של סוכן השירות.

  2. נכנסים לדף IAM במסוף Google Cloud .

    כניסה לדף IAM

  3. לוחצים על הענקת גישה.

  4. בתיבת הטקסט New principals, מזינים את כתובת האימייל של סוכן השירות.

  5. בתפריט הנפתח Select a role, מחפשים את האפשרות Secret Manager Secret Accessor ובוחרים בה.

  6. לוחצים על Save.

gcloud

משתמשים בפקודה gcloud projects add-iam-policy-binding כדי להוסיף את תפקיד IAM לסוכן השירות.

  1. פועלים לפי ההוראות כדי לאחזר את כתובת האימייל של סוכן השירות.

  2. מזינים את הפקודה הבאה בשורת הפקודה:

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member='serviceAccount:SERVICE_AGENT_EMAIL' \
  --role='roles/secretmanager.secretAccessor'

יצירת סוד

יוצרים סוד באמצעות Secret Manager:

מסוף Cloud

  1. נכנסים לדף Secret Manager במסוף Google Cloud .

    מעבר אל Secret Manager

  2. לוחצים על Create secret (יצירת סוד).

  3. מזינים שם.

  4. בתיבת הטקסט Secret value (ערך סודי), מזינים את פרטי הכניסה באחד מהפורמטים הבאים.

    {
  "sas_token" : "SAS_TOKEN_VALUE"
}

    או:

    {
  "access_key" : "ACCESS_KEY"
}

  5. לוחצים על Create secret (יצירת סוד).

  6. אחרי שיוצרים את הסוד, רושמים את שם המשאב המלא של הסוד:

    1. בוחרים בכרטיסייה סקירה כללית.

    2. מעתיקים את הערך של שם המשאב. הפורמט הוא:

      projects/1234567890/secrets/SECRET_NAME

gcloud

כדי ליצור סוד חדש באמצעות כלי שורת הפקודה של Google Cloud, מעבירים את פרטי הכניסה בפורמט JSON לפקודה gcloud secrets create:

printf '{
  "sas_token" : "SAS_TOKEN_VALUE"
}' | gcloud secrets create SECRET_NAME --data-file=-

או:

printf '{
  "access_key" : "ACCESS_KEY"
}' | gcloud secrets create SECRET_NAME --data-file=-

מאחזרים את השם המלא של משאב הסוד:

gcloud secrets describe SECRET_NAME

שימו לב לערך של name בתגובה. הפורמט הוא:

projects/1234567890/secrets/SECRET_NAME

לפרטים נוספים על יצירה וניהול של סודות, אפשר לעיין בתיעוד של Secret Manager.

העברת הסוד לפקודה ליצירת המשימה

כדי להשתמש ב-Secret Manager עם Storage Transfer Service, צריך להשתמש ב-API בארכיטקטורת REST כדי ליצור עבודת העברה.

מעבירים את שם המשאב של Secret Manager כערך של השדה transferSpec.azureBlobStorageDataSource.credentialsSecret:

POST https://storagetransfer.googleapis.com/v1/transferJobs

{
  "description": "Transfer with Secret Manager",
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "transferSpec": {
    "azureBlobStorageDataSource": {
      "storageAccount": "AZURE_STORAGE_ACCOUNT_NAME",
      "container": "AZURE_CONTAINER_NAME",
      "credentialsSecret": "SECRET_RESOURCE_ID",
    },
    "gcsDataSink": {
      "bucketName": "CLOUD_STORAGE_BUCKET_NAME"
    }
  }
}

פרטים מלאים על יצירת העברה זמינים במאמר בנושא יצירת העברות.

אפשרות 3: אימות באמצעות זהות מאוחדת

שירות העברת נתונים (Storage Transfer Service) תומך באיחוד שירותי אימות הזהות של עומסי עבודה ב-Azure עם Google Cloud. ‫Storage Transfer Service יכול לשלוח בקשות ל-Azure Storage דרך אפליקציות רשומות ב-Azure, כך שלא צריך להעביר פרטי כניסה ישירות ל-Storage Transfer Service.

כדי להגדיר זהות מאוחדת, פועלים לפי ההוראות האלה.

הגדרת פרטי כניסה ל-Google Cloud

כדי לאפשר יצירה של אסימונים מזהים מסוג OpenID Connect ‏(OIDC) לחשבון, צריך להוסיף את התפקיד יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator) לסוכן השירות של Storage Transfer Service.

  1. אחזור של accountEmail ושל subjectId של סוכן השירות שמנוהל על ידי Google, שנוצר באופן אוטומטי כשמתחילים להשתמש ב-Storage Transfer Service. כדי לאחזר את הערכים האלה:

    1. עוברים אל דף העזר של googleServiceAccounts.get.

      תיפתח חלונית אינטראקטיבית עם הכותרת Try this method (כדאי לנסות את השיטה הזו).

    2. בחלונית, בקטע Request parameters, מזינים את מזהה הפרויקט. הפרויקט שאתם מציינים כאן צריך להיות הפרויקט שבו אתם משתמשים כדי לנהל את Storage Transfer Service.

    3. לוחצים על Execute. השדות accountEmail ו-subjectId נכללים בתשובה. שומרים את הערכים האלה.

  2. מקצים את התפקיד יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator) לסוכן השירות של Storage Transfer Service. פועלים לפי ההוראות במאמר ניהול הגישה לחשבונות שירות.

הגדרת פרטי הכניסה של מיקרוסופט

קודם כול, רושמים אפליקציה ומוסיפים אמצעי אימות מאוחד:

  1. נכנסים לחשבון בכתובת https://portal.azure.com.
  2. עוברים לדף רישום אפליקציות.
  3. לוחצים על New registration.
  4. מזינים שם. לדוגמה, azure-transfer-app.
  5. בוחרים באפשרות חשבונות רק במדריך הארגוני הזה.
  6. לוחצים על הרשמה. האפליקציה נוצרת. רושמים את Application (client) ID ואת Directory (tenant) ID. אפשר גם לאחזר אותם מאוחר יותר מדף הסקירה הכללית של האפליקציה.
  7. לוחצים על Certificates & secrets ובוחרים בכרטיסייה Federated credentials.
  8. לוחצים על הוספת פרטי כניסה.
  9. בוחרים באפשרות מנפיק אחר כתרחיש ומזינים את הפרטים הבאים:
    • מנפיק: https://accounts.google.com
    • מזהה הנושא: subjectId של סוכן השירות, שאוחזר בהגדרת פרטי הכניסה של Google Cloud.
    • שם ייחודי לפרטי הכניסה המאוחדים.
    • הקהל חייב להישאר api://AzureADTokenExchange.
  10. לוחצים על הוספה.

לאחר מכן, מעניקים לאפליקציה גישה לקונטיינר של Azure Storage:

  1. עוברים אל הדף Storage Accounts (חשבונות אחסון) בחשבון Azure.
  2. בוחרים את חשבון האחסון ואז בוחרים באפשרות Containers בקטע Data storage.
  3. לוחצים על מאגר הנתונים שרוצים לתת לו גישה.
  4. בתפריט שמימין, לוחצים על Access Control (IAM) ובוחרים בכרטיסייה Roles.
  5. לוחצים על סמל האפשרויות הנוספות (...) לצד תפקיד כלשהו ובוחרים באפשרות שיבוט.
  6. מזינים שם לתפקיד המותאם אישית ובוחרים באפשרות Start from scratch (התחלה מאפס). לוחצים על הבא.
  7. לוחצים על הוספת הרשאות ומחפשים את Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read.
  8. לוחצים על הכרטיס Microsoft Storage שמופיע.
  9. לוחצים על כפתור הבחירה פעולות על נתונים.
  10. בוחרים באפשרות קריאה : קריאת Blob.
  11. לוחצים על הוספה.
  12. אם אתם מתכוונים למחוק אובייקטים במקור אחרי ההעברה, לוחצים שוב על הוספת הרשאות ומחפשים את Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete.
  13. לוחצים על הכרטיס Microsoft Storage שמופיע, בוחרים באפשרות פעולות על נתונים ואז בוחרים באפשרות מחיקה : מחיקת blob.
  14. לוחצים על הוספה.
  15. לוחצים על בדיקה + יצירה ואז על יצירה. אתם חוזרים לדף בקרת גישה (IAM) של הקטגוריה.
  16. לוחצים על הוספה ובוחרים באפשרות הוספת הקצאת תפקיד.
  17. ברשימת התפקידים, בוחרים את התפקיד בהתאמה אישית ולוחצים על הבא.
  18. לוחצים על בחירת חברים.
  19. בשדה Select (בחירה), מזינים את שם האפליקציה שרשמתם קודם. לדוגמה, azure-transfer-app.
  20. לוחצים על משבצת האפליקציה ואז על בחירה.
  21. לוחצים על בדיקה והקצאה.

העברת מזהי האפליקציות לפקודה ליצירת משימות

המזהים של האפליקציה מועברים לפקודה ליצירת משימה באמצעות אובייקט federatedIdentityConfig. מעתיקים את מזהה האפליקציה (הלקוח) ואת מזהה הספרייה (הדייר) ששמרתם בשלבים של הגדרת פרטי הכניסה של מיקרוסופט לשדות client_id ו-tenant_id.

"federatedIdentityConfig": {
  "client_id": "efghe9d8-4810-800b-8f964ed4057f",
  "tenant_id": "abcd1234-c8f0-4cb0-b0c5-ae4aded60078"
}

דוגמה לבקשה ליצירת משימה:

POST https://storagetransfer.googleapis.com/v1/transferJobs

{
  "description": "Transfer with Azure Federated Identity",
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "transferSpec": {
    "azureBlobStorageDataSource": {
      "storageAccount": "AZURE_STORAGE_ACCOUNT_NAME",
      "container": "AZURE_CONTAINER_NAME",
      "federatedIdentityConfig": {
        "client_id": "AZURE_CLIENT_ID",
        "tenant_id": "AZURE_TENANT_ID"
      }
    },
    "gcsDataSink": {
      "bucketName": "CLOUD_STORAGE_BUCKET_NAME"
    }
  }
}

פרטים מלאים על יצירת העברה זמינים במאמר בנושא יצירת העברות.

הגבלות על כתובות IP

אם אתם מגבילים את הגישה למשאבי Azure באמצעות חומת אש של Azure Storage, אתם צריכים להוסיף לרשימת כתובות ה-IP המותרות את טווחי כתובות ה-IP שמשמשים את העובדים של Storage Transfer Service.

טווחי כתובות ה-IP האלה יכולים להשתנות, ולכן אנחנו מפרסמים את הערכים הנוכחיים כקובץ JSON בכתובת קבועה:

https://www.gstatic.com/storage-transfer-service/ipranges.json

כשמוסיפים טווח חדש לקובץ, אנחנו ממתינים לפחות 7 ימים לפני שאנחנו משתמשים בטווח הזה לבקשות מ-Storage Transfer Service.

מומלץ לשלוף נתונים מהמסמך הזה לפחות פעם בשבוע כדי לשמור על עדכניות של הגדרות האבטחה. במאמר הזה מתוך מסמכי הענן הווירטואלי הפרטי יש סקריפט לדוגמה ב-Python שמביא טווחי כתובות IP מקובץ JSON.

כדי להוסיף את הטווחים האלה ככתובות IP מותרות, צריך לפעול לפי ההוראות במאמר של Microsoft Azure בנושא הגדרת חומות אש ורשתות וירטואליות ב-Azure Storage.