دعم بروتوكول نقل الملفات SSH (SFTP) لتخزين Azure Blob
يدعم تخزين كائن ثنائي كبير الحجم الآن بروتوكول نقل ملفات SSH (SFTP). يتيح لك هذا الدعم الاتصال بأمان ب Blob Storage باستخدام عميل SFTP، مما يسمح لك باستخدام SFTP للوصول إلى الملفات ونقل الملفات وإدارة الملفات.
إليك مقطع فيديو يخبرك بالمزيد عن ذلك.
يسمح Azure بنقل البيانات بأمان إلى حسابات تخزين الكائن الثنائي كبير الحجم باستخدام خدمة واجهة برمجة تطبيقات REST لـ Azure Blob وAzure SDKs وأدوات مثل AzCopy. ومع ذلك، غالباً ما تستخدم أحمال العمل القديمة بروتوكولات نقل الملفات التقليدية مثل SFTP. يمكنك تحديث التطبيقات المخصصة لاستخدام واجهة برمجة تطبيقات REST ومجموعات Azure SDK، لكن فقط عن طريق إجراء تغييرات كبيرة في التعليمات البرمجية.
قبل إصدار هذه الميزة، إذا كنت ترغب في استخدام SFTP لنقل البيانات إلى Azure Blob Storage، فسيتعين عليك إما شراء منتج تابع لجهة أخرى أو تنسيق الحل الخاص بك. بالنسبة للحلول المخصصة، سيتعين عليك إنشاء أجهزة ظاهرية (VMs) في Azure لاستضافة خادم SFTP، ثم تحديث بنية معقدة وتصحيحها وإدارتها وتوسيع نطاقها وصيانتها.
الآن، مع دعم SFTP ل Azure Blob Storage، يمكنك تمكين دعم SFTP لحسابات Blob Storage بنقرة واحدة. ثم يمكنك إعداد هويات المستخدمين المحليين للمصادقة للاتصال بحساب التخزين الخاص بك باستخدام SFTP عبر المنفذ 22.
توضح هذه المقالة دعم SFTP لـ Azure Blob Storage. لمعرفة كيفية تمكين SFTP لحساب التخزين الخاص بك، راجع الاتصال إلى Azure Blob Storage باستخدام بروتوكول نقل ملفات SSH (SFTP).
إشعار
SFTP هي خدمة على مستوى النظام الأساسي، لذلك سيتم فتح المنفذ 22 حتى إذا تم تعطيل خيار الحساب. إذا لم يتم تكوين الوصول إلى SFTP، فستتلقى جميع الطلبات قطع اتصال من الخدمة.
SFTP ومساحة الأسماء الهرمية
يتطلب دعم SFTP تمكين مساحة اسم هرمية. تقوم مساحة الأسماء الهرمية بتنظيم العناصر (الملفات) في تدرج هرمي للدكتورات والتسلسلات الفرعية بنفس الطريقة التي يتم بها تنظيم نظام الملفات على الكمبيوتر. تُقاس مساحة الأسماء الهرمية خطيًا ولا تقلل من سعة البيانات أو أدائها.
يتم دعم البروتوكولات المختلفة بواسطة مساحة الاسم الهرمية. SFTP هو أحد هذه البروتوكولات المتاحة. تظهر الصورة التالية الوصول إلى التخزين عبر بروتوكولات متعددة وواجهات برمجة تطبيقات REST. لتسهيل القراءة، تستخدم هذه الصورة مصطلح Gen2 REST للإشارة إلى Azure Data Lake Storage Gen2 REST API.
نموذج إذن SFTP
لا يمكن تخويل عملاء SFTP باستخدام هويات Microsoft Entra. بدلاً من ذلك، يستخدم SFTP شكلاً جديداً من أشكال إدارة الهوية يُسمى المستخدمين المحليين.
يجب على المستخدمين المحليين استخدام كلمة مرور أو بيانات اعتماد مفتاح خاص Secure Shell (SSH) للمصادقة. يمكنك الحصول على 2000 مستخدم محلي كحد أقصى لحساب تخزين.
لإعداد أذونات الوصول، يمكنك إنشاء مستخدم محلي، واختيار أساليب المصادقة. بعد ذلك، لكل حاوية في حسابك، يمكنك تحديد مستوى الوصول الذي تريد منحه لهذا المستخدم.
تنبيه
لا يتداخل المستخدمون المحليون مع نماذج أذونات Azure Storage الأخرى مثل RBAC (التحكم في الوصول المستند إلى الدور) وABAC (التحكم في الوصول المستند إلى السمة). يتم دعم قوائم التحكم بالوصول (ACLs) للمستخدمين المحليين على مستوى المعاينة.
على سبيل المثال، يتمتع جيف بإذن القراءة فقط (يمكن التحكم فيه عبر RBAC أو ABAC) عبر هوية Microsoft Entra للملف foo.txt تخزينه في حاوية con1. إذا كان جيف يصل إلى حساب التخزين عبر NFS (عندما لا يتم تحميله كجذر/مستخدم فائق) أو Blob REST أو Data Lake Storage Gen2 REST، فسيتم فرض هذه الأذونات. ومع ذلك، إذا كان لدى جيف أيضا هوية مستخدم محلي مع إذن حذف البيانات في حاوية con1، فيمكنه حذف foo.txt عبر SFTP باستخدام هوية المستخدم المحلي.
لا يمنع تمكين دعم SFTP أنواع أخرى من العملاء من استخدام معرف Microsoft Entra. بالنسبة للمستخدمين الذين يصلون إلى Blob Storage باستخدام مدخل Azure وAzure CLI والأوامر Azure PowerShell وAzCopy بالإضافة إلى Azure SDKs وواجهات برمجة تطبيقات Azure REST، يمكنك الاستمرار في استخدام النطاق الكامل لإعداد أمان Azure Blob Storage لتخويل الوصول. لمعرفة المزيد ، راجع نموذج التحكم في الوصول في Azure Data Lake Storage Gen2 .
طرق المصادقة
يمكنك مصادقة المستخدمين المحليين الذين يتصلون عبر SFTP باستخدام كلمة مرور أو زوج مفاتيح خاص - عام لـ Secure Shell (SSH). يمكنك تكوين نماذج المصادقة والسماح للمستخدمين المحليين المتصلين باختيار النموذج الذي سيُستخدم. ومع ذلك، لا تُدعم المصادقة متعددة العوامل، حيث يلزم وجود كلمة مرور صالحة ومفتاح "عام خاص" مزدوج صالح للمصادقة الناجحة.
كلمات المرور
لا يمكنك تعيين كلمات مرور مخصصة، بدلا من ذلك يقوم Azure بإنشاء كلمة مرور لك. إذا اخترت مصادقة كلمة المرور، فسيتم توفير كلمة المرور الخاصة بك بعد الانتهاء من تكوين مستخدم محلي. تأكد من نسخ كلمة المرور هذه وحفظها في موقع يمكنك العثور عليه لاحقا. لن تتمكن من استرداد كلمة المرور هذه من Azure مرة أخرى. إذا فقدت كلمة المرور، يجب عليك إنشاء كلمة مرور جديدة. لأسباب أمنية، لا يمكنك تعيين كلمة المرور بنفسك.
أزواج مفاتيح SSH
زوج المفاتيح الخاص - العام هو النموذج الأكثر شيوعاً للمصادقة Secure Shell (SSH). المفتاح الخاص سري ويجب أن يكون معروفاً فقط للمستخدم المحلي. يُخزن المفتاح العام في Azure. عندما يتصل عميل SSH بحساب التخزين باستخدام هوية مستخدم محلي، فإنه يرسل رسالة بالمفتاح العام والتوقيع. يقوم Azure بالتحقق من صحة الرسالة ويتحقق من التعرف على المستخدم والمفتاح بواسطة حساب التخزين. لمعرفة المزيد، راجع نظرة عامة على SSH والمفاتيح.
إذا اخترت المصادقة باستخدام زوج مفاتيح خاص - عام، فيمكنك إما إنشاء واحد أو استخدام مفتاح مُخزّن بالفعل في Azure أو تزويد Azure بالمفتاح العام لزوج مفاتيح خاص - عام موجود. يمكنك الحصول على 10 مفاتيح عامة كحد أقصى لكل مستخدم محلي.
أذونات الحاوية
بالنسبة للأذونات على مستوى الحاوية، يمكنك اختيار الحاويات التي تريد منح حق الوصول إليها ومستوى الوصول الذي تريد توفيره (قراءة وكتابة وقائمة وحذف وإنشاء وتعديل الملكية وتعديل الأذونات). تنطبق هذه الأذونات على جميع الدلائل والدلائل الفرعية في الحاوية. يمكنك منح كل مستخدم محلي الوصول إلى ما يصل إلى 100 حاوية. يمكن أيضاً تحديث أذونات الحاوية بعد إنشاء مستخدم محلي. يصف الجدول التالي كل إذن بمزيد من التفصيل.
الإذن | الرمز | الوصف |
---|---|---|
قراءة | r | |
كتابة | w | |
List | l | |
حذف | d | |
إنشاء | ج | |
تعديل الملكية | o | |
تعديل الأذونات | -p |
عند تنفيذ عمليات الكتابة على الكائنات الثنائية كبيرة الحجم في الدلائل الفرعية، يلزم الحصول على إذن قراءة لفتح الدليل والوصول إلى خصائص الكائن الثنائي كبير الحجم.
قوائم التحكم بالوصول (ACLs)
هام
هذه الإمكانية حاليًا في PREVIEW. للحصول على الشروط القانونية التي تنطبق على ميزات Azure الموجودة في الإصدار التجريبي، أو المعاينة، أو التي لم يتم إصدارها بعد في التوفر العام، راجع شروط الاستخدام التكميلية لمعاينات Microsoft Azure.
تتيح لك قوائم التحكم بالوصول (ACLs) منح حق الوصول "الدقيق"، مثل الوصول للكتابة إلى دليل أو ملف معين. لمعرفة المزيد حول قوائم التحكم بالوصول، راجع قوائم التحكم بالوصول (ACLs) في Azure Data Lake Storage Gen2.
لتخويل مستخدم محلي باستخدام قوائم التحكم بالوصول، يجب أولا تمكين تخويل ACL لهذا المستخدم المحلي. راجع منح الإذن للحاويات.
إشعار
بينما يمكن ل ACL تحديد مستوى الأذونات للعديد من أنواع الهويات المختلفة، يمكن استخدام المستخدم المالك والمجموعة المالكة وجميع هويات المستخدمين الآخرين فقط لتخويل مستخدم محلي. المستخدمون المسماة والمجموعات المسماة غير مدعومة بعد لتخويل المستخدم المحلي.
يصف الجدول التالي خصائص المستخدم المحلي المستخدمة لتخويل ACL.
الخاصية | الوصف |
---|---|
معرف المستخدم | |
GroupId | |
AllowAclAuthorization |
كيفية تقييم أذونات ACL
يتم تقييم قوائم التحكم بالوصول فقط إذا لم يكن لدى المستخدم المحلي أذونات الحاوية الضرورية لتنفيذ عملية. بسبب الطريقة التي يتم بها تقييم أذونات الوصول بواسطة النظام، لا يمكنك استخدام قائمة التحكم بالوصول لتقييد الوصول الذي تم منحه بالفعل بواسطة أذونات على مستوى الحاوية. وذلك لأن النظام يقيم أذونات الحاوية أولا، وإذا منحت هذه الأذونات إذن وصول كافيا، يتم تجاهل قوائم التحكم في الوصول.
هام
لمنح مستخدم محلي حق الوصول للقراءة أو الكتابة إلى ملف، ستحتاج إلى منح هذا المستخدم المحلي أذونات التنفيذ إلى المجلد الجذر للحاوية، وإلى كل مجلد في التسلسل الهرمي للمجلدات التي تؤدي إلى الملف. إذا كان المستخدم المحلي هو المستخدم المالك أو مجموعة المالك، فيمكنك تطبيق أذونات التنفيذ إما على المستخدم المالك أو مجموعة المالك. وإلا، يتعين عليك تطبيق إذن Execute على جميع المستخدمين الآخرين.
تعديل قوائم التحكم بالوصول باستخدام عميل SFTP
بينما يمكن تعديل أذونات ACL باستخدام أي أداة Azure معتمدة أو SDK، يمكن للمستخدمين المحليين أيضا تعديلها. لتمكين مستخدم محلي من تعديل أذونات ACL، يجب أولا منح المستخدم Modify Permissions
المحلي إذنا. راجع منح الإذن للحاويات.
يمكن للمستخدمين المحليين تغيير مستوى الأذونات للمستخدم المالك فقط، ومجموعة المالك، وجميع المستخدمين الآخرين ل ACL. إضافة إدخالات ACL أو تعديلها للمستخدمين المسمين والمجموعات المسماة وأساسيات الأمان المسماة غير مدعومة حتى الآن.
يمكن للمستخدمين المحليين أيضا تغيير معرف المستخدم المالك والمجموعة المالكة. في الواقع، يمكن للمستخدمين المحليين فقط تغيير معرف المستخدم المالك أو مجموعة المالك إلى معرف مستخدم محلي. لا يمكنك بعد الرجوع إلى معرف مستخدم محلي في قائمة التحكم بالوصول باستخدام أداة Azure أو SDK. لتغيير امتلاك المستخدم أو مجموعة امتلاك دليل أو كائن ثنائي كبير الحجم، يجب منح Modify Ownership
المستخدم المحلي الإذن.
لعرض الأمثلة، راجع تعديل قائمة التحكم بالوصول لملف أو دليل.
الدليل الرئيسي
أثناء تكوين الأذونات، يتوفر لديك خيار تعيين دليل رئيسي للمستخدم المحلي. إذا لم يتم تحديد حاوية أخرى في طلب اتصال SFTP، فإن الدليل الرئيسي هو الدليل الذي يتصل به المستخدم بشكل افتراضي. على سبيل المثال، ضع في اعتبارك الطلب التالي المُقدم باستخدام Open SSH. لا يُحدد هذا الطلب اسم حاوية أو دليل كجزء من الأمر sftp
.
sftp myaccount.myusername@myaccount.blob.core.windows.net
put logfile.txt
إذا قمت بتعيين الدليل الرئيسي للمستخدم إلى mycontainer/mydirectory
، فسيتصل بهذا الدليل. بعد ذلك، logfile.txt
سيتم تحميل الملف إلى mycontainer/mydirectory
. إذا لم تقم بتعيين الدليل الرئيسي، فستفشل محاولة الاتصال. بدلاً من ذلك، سيتعين على المستخدمين الذين يقومون بالاتصال تحديد حاوية مع الطلب ثم استخدام أوامر SFTP للانتقال إلى الدليل الهدف قبل تحميل ملف. يوضح المثال التالي ما يلي:
sftp myaccount.mycontainer.myusername@myaccount.blob.core.windows.net
cd mydirectory
put logfile.txt
إشعار
الدليل الرئيسي هو الدليل الأولي فقط الذي يُوضع فيه المستخدم المحلي المتصل. يمكن للمستخدمين المحليين الانتقال إلى أي مسار آخر في الحاوية التي يتصلون بها إذا كانت لديهم أذونات الحاوية المناسبة.
الخوارزميات المدعومة
يمكنك استخدام العديد من عملاء SFTP المختلفين للاتصال الآمن ثم نقل الملفات. يجب أن يستخدم العملاء المتصلون الخوارزميات المحددة في الجدول أدناه.
نوع | خوارزمية |
---|---|
مفتاح المضيف 1 | rsa-sha2-256 2 rsa-sha2-512 2 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 |
تبادل المفاتيح | ecdh-sha2-nistp384 ecdh-sha2-nistp256 diffie-hellman-group14-sha256 diffie-hellman-group16-sha512 diffie-hellman-group-exchange-sha256 |
الأصفار / التشفير | aes128-gcm@openssh.com aes256-gcm@openssh.com aes128-ctr aes192-ctr aes256-ctr |
تكامل البيانات / وحدة تحكم وصول الوسائط | hmac-sha2-256 hmac-sha2-512 hmac-sha2-256-etm@openssh.com hmac-sha2-512-etm@openssh.com |
المفتاح العام | ssh-rsa 2 rsa-sha2-256 rsa-sha2-512 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 |
1 تم نشر مفاتيح المضيفهنا. يجب أن يكون طول مفتاحي RSA 2048 بت كحد أدنى.
يحد دعم SFTP لـ Azure Blob Storage حالياً من دعم خوارزمية التشفير استناداً إلى اعتبارات الأمان. نوصي بشدة بأن يستخدم العملاء الخوارزميات المعتمدة من دورة تطوير الأمان من Microsoft (SDL) للوصول إلى بياناتهم بشكل آمن.
في الوقت الحالي، وفقا ل Microsoft Security SDL، لا نخطط لدعم ما يلي: ssh-dss
، diffie-hellman-group14-sha1
، diffie-hellman-group1-sha1
، diffie-hellman-group-exchange-sha1
، hmac-sha1
. hmac-sha1-96
دعم الخوارزمية عرضة للتغيير في المستقبل.
الاتصال بـ SFTP
للبدء، قم بتمكين دعم SFTP وإنشاء مستخدم محلي وتعيين أذونات لهذا المستخدم المحلي. بعد ذلك، يمكنك استخدام أي عميل SFTP للاتصال بأمان ثم نقل الملفات. للإرشادات التفصيلية، راجع الاتصال بـ Azure Blob Storage باستخدام بروتوكول نقل الملفات SSH (SFTP).
اعتبارات الشبكات
SFTP هي خدمة على مستوى النظام الأساسي، لذلك سيتم فتح المنفذ 22 حتى إذا تم تعطيل خيار الحساب. إذا لم يتم تكوين الوصول إلى SFTP، فستتلقى جميع الطلبات قطع اتصال من الخدمة. عند استخدام SFTP، قد تحتاج إلى تقييد الوصول العام من خلال تكوين جدار حماية أو شبكة ظاهرية أو نقطة نهاية خاصة. يتم فرض هذه الإعدادات في طبقة التطبيق، ما يعني أنها ليست خاصة ب SFTP وستؤثر على الاتصال بجميع نقاط نهاية تخزين Azure. لمزيد من المعلومات حول جدران الحماية وتكوين الشبكة، راجع تكوين جدران حماية تخزين Azure والشبكات الظاهرية.
إشعار
قد تقوم أدوات التدقيق التي تحاول تحديد دعم TLS في طبقة البروتوكول بإرجاع إصدارات TLS بالإضافة إلى الحد الأدنى من الإصدار المطلوب عند تشغيلها مباشرةً مقابل نقطة نهاية حساب التخزين. لمزيد من المعلومات، راجع فرض الحد الأدنى المطلوب من إصدار أمان طبقة النقل (TLS) للطلبات إلى حساب تخزين.
عملاء مدعومون معروفون
العملاء التاليون لديهم دعم خوارزمية متوافق مع SFTP ل Azure Blob Storage. راجع القيود والمشكلات المعروفة المتعلقة بدعم بروتوكول نقل ملفات SSH (SFTP) لـ Azure Blob Storage إذا كنت تواجه مشكلة في الاتصال. هذه القائمة ليست شاملة وقد تتغير بمرور الوقت.
- AsyncSSH 2.1.0+
- Axway
- Cyberduck 7.8.2+
- edtFTPjPRO 7.0.0+
- FileZilla 3.53.0+
- libssh 0.9.5+
- Maverick Legacy 1.7.15+
- Moveit 12.7
- OpenSSH 7.4+
- paramiko 2.8.1+
- phpseclib 1.0.13+
- PuTTY 0.74+
- QualysML 12.3.41.1+
- RebexSSH 5.0.7119.0+
- Salesforce
- ssh2js 0.1.20+
- sshj 0.27.0+
- SSH.NET 2020.0.0+
- WinSCP 5.10+
- يوم عمل
- XFB.Gateway
- JSCH 0.1.54+
- curl 7.85.0+
- AIX1
- MobaXterm v21.3
1 يجب تعيين AllowPKCS12KeystoreAutoOpen
الخيار إلى no
.
القيود والمشاكل المعروفة
راجع مقالة القيود والمشكلات المعروفة للحصول على قائمة كاملة بالقيود والمشكلات المتعلقة بدعم SFTP لـ Azure Blob Storage.
التسعير والفوترة
تمكين SFTP له تكلفة كل ساعة. للحصول على أحدث معلومات التسعير، راجع تسعير Azure Blob Storage.
تلميح
لتجنب الرسوم السلبية، ضع في اعتبارك تمكين SFTP فقط عندما تستخدمه بنشاط لنقل البيانات. للحصول على إرشادات حول كيفية تمكين دعم SFTP ثم تعطيله، راجع الاتصال إلى Azure Blob Storage باستخدام بروتوكول نقل ملفات SSH (SFTP).
يتم تطبيق أسعار المعاملات والتخزين والشبكات لحساب التخزين الأساسي. يتم تحويل جميع معاملات SFTP إلى عمليات قراءة أو كتابة أو معاملات أخرى على حسابات التخزين الخاصة بك. يتضمن ذلك جميع أوامر SFTP واستدعاءات واجهة برمجة التطبيقات. لمعرفة المزيد، راجع فهم نموذج الفوترة الكامل لـ Azure Blob Storage.
المحتوى ذو الصلة
- دعم بروتوكول نقل الملفات SSH (SFTP) لتخزين Azure Blob
- تمكين دعم بروتوكول نقل ملفات SSH (SFTP) أو تعطيله في Azure Blob Storage
- تخويل الوصول إلى Azure Blob Storage من عميل بروتوكول نقل ملفات SSH (SFTP)
- الاتصال بتخزين Azure Blob باستخدام بروتوكول نقل ملفات SSH (SFTP)
- المشكلات المعروفة مع دعم بروتوكول نقل الملفات SSH (SFTP) لـ Azure Blob Storage
- دعم بروتوكول نقل الملفات SSH (SFTP) لـ Azure Blob Storage
- اعتبارات أداء بروتوكول نقل ملفات SSH (SFTP) في تخزين Azure Blob
الملاحظات
https://aka.ms/ContentUserFeedback.
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجعإرسال الملاحظات وعرضها المتعلقة بـ