הגדרת גישה למקור: 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 באמצעות אסימון 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. הפרוטוקול Allowed protocols צריך להיות HTTPS only.

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

אפשרות 2: אימות באמצעות מפתח משותף או טוקן SAS של Azure ב-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, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

להפעלת ה-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. לוחצים על יצירת סוד.

  3. מזינים שם.

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

    {
  "sas_token" : "SAS_TOKEN_VALUE"
}

    או:

    {
  "access_key" : "ACCESS_KEY"
}

  5. לוחצים על יצירת סוד.

  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

כדי לאפשר ל-Storage Transfer Service ליצור אסימונים מזהים מסוג OpenID Connect ‏ (OIDC):

סוכן שירות

אם בעבודת ההעברה לא מצוין serviceAccount (כלומר, אתם לא מאצילים הרשאות של סוכן שירות לחשבון שירות בניהול המשתמשים), צריך להקצות לסוכן השירות את התפקיד יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator):

  1. מאחזרים את accountEmail של סוכן השירות:

    1. עוברים אל דף העזר של googleServiceAccounts.get.
    2. בקטע Request parameters, מזינים את מזהה הפרויקט.
    3. לוחצים על Execute. הסכומים accountEmail וsubjectId יוחזרו.

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

חשבון שירות בניהול המשתמש

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

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

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

  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. בוחרים באפשרות מנפיק אחר כתרחיש ומזינים את הפרטים הבאים:

  10. לוחצים על הוספה.

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

  1. עוברים לדף Storage Accounts (חשבונות אחסון) בחשבון Azure.
  2. בוחרים את חשבון האחסון ואז בוחרים באפשרות Containers בקטע Data storage.
  3. לוחצים על הדלי שרוצים להעניק לו גישה.
  4. בתפריט הימני, לוחצים על Access Control (IAM) ובוחרים בכרטיסייה Roles.
  5. לוחצים על סמל האפשרויות הנוספות (...) לצד תפקיד כלשהו ובוחרים באפשרות שיבוט.
  6. מזינים שם לתפקיד המותאם אישית ולוחצים על יצירה מאפס. לוחצים על הבא.
  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 האלה ככתובות IP מותרות, צריך לפעול לפי ההוראות במאמר של Microsoft Azure בנושא הגדרת חומות אש ורשתות וירטואליות ב-Azure Storage.