לפני העברת נתונים ממאגר Azure Storage, צריך להגדיר גישה למאגר הזה כדי ש-Storage Transfer Service יוכל לאחזר את האובייקטים שלו.
שירות העברת נתונים (Storage Transfer Service) תומך בשיטות האימות הבאות של Azure:
אסימוני חתימת גישה משותפת (SAS). אפשר לציין את אסימוני ה-SAS ישירות כשיוצרים העברת נתונים, או לאחסן אותם ב-Secret Manager.
אפשר לאחסן מפתחות משותפים של Azure ב-Secret Manager ולהעביר את הסוד כשיוצרים עבודת העברה.
פרטי כניסה מאוחדים מועברים באובייקט
federatedIdentityConfigבמהלך יצירת משימת ההעברה.
במסמך הזה יש גם מידע על הוספת כתובות 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.
יוצרים משתמש ב-Microsoft Azure Storage או משתמשים במשתמש קיים כדי לגשת לחשבון האחסון של קונטיינר ה-BLOB ב-Microsoft Azure Storage.
יוצרים טוקן SAS ברמת המאגר. הוראות מפורטות זמינות במאמר Grant limited access to Azure Storage resources using shared access signatures.
השירותים המותרים חייבים לכלול את Blob.
בקטע Allowed resource types (סוגי משאבים מותרים), בוחרים באפשרויות Container (מאגר) ו-Object (אובייקט).
ההרשאות המותרות חייבות לכלול את ההרשאות קריאה והצגת רשימה. אם ההעברה מוגדרת למחיקת אובייקטים מהמקור, צריך לכלול גם את ההרשאה מחיקה.
ברירת המחדל של זמן התפוגה של אסימוני SAS היא 8 שעות. כדאי להגדיר זמן תפוגה סביר שיאפשר לכם להשלים את ההעברה בהצלחה.
אל תציינו כתובות IP בשדה כתובות IP מותרות. Storage Transfer Service משתמש בכתובות IP שונות ולא תומך בהגבלת כתובות IP.
הפרוטוקולים המותרים צריכים להיות HTTPS בלבד.
אחרי שיוצרים את הטוקן, צריך לשים לב לערך של טוקן 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
Enable the Secret Manager API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM
role (roles/serviceusage.serviceUsageAdmin), which
contains the serviceusage.services.enable permission. Learn how to grant
roles.
הגדרת הרשאות נוספות
הרשאות של משתמשים
המשתמש שיוצר את הסוד צריך להיות בעל התפקיד הבא:
- אדמין של Secret Manager (
roles/secretmanager.admin)
הרשאות של סוכן שירות
סוכן השירות של Storage Transfer Service צריך את תפקיד ה-IAM הבא:
- Secret Manager Secret Accessor (
roles/secretmanager.secretAccessor)
כדי להעניק את התפקיד לסוכן השירות:
מסוף Cloud
פועלים לפי ההוראות כדי לאחזר את כתובת האימייל של סוכן השירות.
נכנסים לדף IAM במסוף Google Cloud .
לוחצים על הענקת גישה.
בתיבת הטקסט New principals, מזינים את כתובת האימייל של סוכן השירות.
בתפריט הנפתח Select a role, מחפשים את האפשרות Secret Manager Secret Accessor ובוחרים בה.
לוחצים על Save.
gcloud
משתמשים בפקודה gcloud projects add-iam-policy-binding כדי להוסיף את תפקיד ה-IAM לסוכן השירות.
פועלים לפי ההוראות כדי לאחזר את כתובת האימייל של סוכן השירות.
מזינים את הפקודה הבאה בשורת הפקודה:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member='serviceAccount:SERVICE_AGENT_EMAIL' \ --role='roles/secretmanager.secretAccessor'
יצירת סוד
יוצרים סוד באמצעות Secret Manager:
מסוף Cloud
נכנסים לדף Secret Manager במסוף Google Cloud .
לוחצים על Create secret (יצירת סוד).
מזינים שם.
בתיבת הטקסט Secret value, מזינים את פרטי הכניסה באחד מהפורמטים הבאים.
{ "sas_token" : "SAS_TOKEN_VALUE" }או:
{ "access_key" : "ACCESS_KEY" }לוחצים על Create secret (יצירת סוד).
אחרי שיוצרים את הסוד, רושמים את שם המשאב המלא של הסוד:
בוחרים בכרטיסייה סקירה כללית.
מעתיקים את הערך של שם המשאב. הפורמט הוא:
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) לחשבון, צריך להוסיף את התפקיד Service Account Token Creator (roles/iam.serviceAccountTokenCreator) לסוכן השירות של Storage Transfer Service.
אחזור של
accountEmailושלsubjectIdשל סוכן שירות שמנוהל על ידי Google, שנוצר באופן אוטומטי כשמתחילים להשתמש ב-Storage Transfer Service. כדי לאחזר את הערכים האלה:עוברים אל
googleServiceAccounts.getדף העזר.תיפתח חלונית אינטראקטיבית עם הכותרת Try this method (נסו את השיטה הזו).
בחלונית, בקטע Request parameters, מזינים את מזהה הפרויקט. הפרויקט שאתם מציינים כאן צריך להיות הפרויקט שבו אתם משתמשים כדי לנהל את Storage Transfer Service.
לוחצים על Execute. השדות
accountEmailו-subjectIdנכללים בתשובה. שומרים את הערכים האלה.
מקצים את התפקיד יצירת אסימונים בחשבון שירות (
roles/iam.serviceAccountTokenCreator) לסוכן השירות של Storage Transfer Service. פועלים לפי ההוראות במאמר ניהול הגישה לחשבונות שירות.
הגדרת פרטי כניסה של מיקרוסופט
קודם כול, רושמים אפליקציה ומוסיפים אמצעי אימות מאוחד:
- נכנסים לחשבון בכתובת https://portal.azure.com.
- עוברים לדף רישום אפליקציות.
- לוחצים על New registration.
- מזינים שם. לדוגמה,
azure-transfer-app. - בוחרים באפשרות חשבונות רק במדריך הארגוני הזה.
- לוחצים על הרשמה. האפליקציה נוצרת. רושמים בצד את
Application (client) IDואתDirectory (tenant) ID. אפשר גם לאחזר אותם מאוחר יותר מדף הסקירה הכללית של האפליקציה. - לוחצים על Certificates & secrets ובוחרים בכרטיסייה Federated credentials.
- לוחצים על הוספת פרטי כניסה.
- בוחרים באפשרות מנפיק אחר כתרחיש ומזינים את הפרטים הבאים:
- מנפיק:
https://accounts.google.com - מזהה הנושא:
subjectIdשל סוכן השירות, שאותו אחזרתם בהגדרת פרטי הכניסה של Google Cloud. - שם ייחודי לפרטי הכניסה המאוחדים.
- הקהל חייב להישאר
api://AzureADTokenExchange.
- מנפיק:
- לוחצים על הוספה.
לאחר מכן, מעניקים לאפליקציה גישה לקונטיינר של Azure Storage:
- עוברים אל הדף Storage Accounts (חשבונות אחסון) בחשבון Azure.
- בוחרים את חשבון האחסון ולוחצים על Containers בקטע Data storage.
- לוחצים על דלי האחסון שרוצים לתת לו גישה.
- בתפריט שמימין, לוחצים על Access Control (IAM) ובוחרים בכרטיסייה Roles.
- לוחצים על סמל האפשרויות הנוספות (
...) לצד תפקיד כלשהו ובוחרים באפשרות שיבוט. - מזינים שם לתפקיד המותאם אישית ובוחרים באפשרות Start from scratch (התחלה מאפס). לוחצים על הבא.
- לוחצים על Add permissions ומחפשים את
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read. - לוחצים על הכרטיס Microsoft Storage שמופיע.
- לוחצים על כפתור הבחירה פעולות על נתונים.
- בוחרים באפשרות קריאה : קריאת Blob.
- לוחצים על הוספה.
- אם אתם מתכוונים למחוק אובייקטים במקור אחרי ההעברה, לוחצים שוב על הוספת הרשאות ומחפשים את
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete. - לוחצים על הכרטיס Microsoft Storage שמופיע, בוחרים באפשרות פעולות על נתונים ואז באפשרות מחיקה : מחיקת blob.
- לוחצים על הוספה.
- לוחצים על בדיקה + יצירה ואז על יצירה. אתם חוזרים לדף בקרת גישה (IAM) של הקטגוריה.
- לוחצים על הוספה ובוחרים באפשרות הוספת הקצאת תפקיד.
- ברשימת התפקידים, בוחרים את התפקיד בהתאמה אישית ולוחצים על הבא.
- לוחצים על בחירת חברים.
- בשדה Select (בחירה), מזינים את שם האפליקציה שרשמתם קודם. לדוגמה,
azure-transfer-app. - לוחצים על משבצת האפליקציה ואז על בחירה.
- לוחצים על בדיקה והקצאה.
העברת מזהי האפליקציות לפקודה ליצירת המשימה
המזהים של האפליקציה מועברים לפקודה ליצירת משימה באמצעות אובייקט 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.
מומלץ לשלוף נתונים מהמסמך הזה לפחות פעם בשבוע כדי לשמור על עדכניות של הגדרות האבטחה. במאמר הזה מתוך מסמכי התיעוד של הענן הווירטואלי הפרטי (VPC) יש סקריפט Python לדוגמה שמביא טווחי כתובות IP מקובץ JSON.
כדי להוסיף את טווחי כתובות ה-IP האלה ככתובות IP מורשות, צריך לפעול לפי ההוראות במאמר של Microsoft Azure בנושא הגדרה של חומות אש ורשתות וירטואליות ב-Azure Storage.