مصدر الصورة: freecodecamp.org

كيفية التعامل مع البيانات من دلو AWS S3 الخاص وتقديمها مع AWS STS في node.js؟

عندما بدأت استخدام AWS S3 لأول مرة مع STS ، كان الأمر محيرًا بالنسبة لي في تنفيذ هذه الأشياء. على الرغم من أن الوثائق تحتوي على كل الأشياء المذكورة فيه ، كطالب مبتدئ في AWS ، كانت مهمة استخراج جميع المعلومات منه صعبة ، حيث يتم توزيعها على العديد من الصفحات وهناك أمثلة قليلة جدًا.

لذا فإن هذه المدونة هي دليل نهائي لنشر نظام لخدمة المحتوى الحساس من دلو S3 الخاص بك باستخدام AWS STS.

نشر في الأصل على https://gosink.in/how-to-handle-and-serve-data-from-aws-s3-s-private-bucket-with-aws-sts-in-node-js/

لماذا دلو خاص؟

قبل بضعة أشهر ، بدأت في تطوير منتج كان يقدم بلاطات الخرائط (الصور) مع بعض المعلومات الحساسة المشفرة في تلك الصور.

لم يكن لدينا خيار سوى تشفير بياناتنا في الصور لأننا لا نستطيع تقديم JSON بشكل صريح لأن أي شخص يمكنه بسهولة استخراج جميع البيانات منه.

ولكن حتى بعد تشفير البيانات ، كانت المشكلة الجديدة هي ، إذا جعلنا هذه الصور عامة ، فيمكن لأي شخص على الأقل امتلاك كل البلاط لإنشاء نظامه الخاص وعرضه بسهولة.

أعلم أنه إذا فعل شخص ما ذلك ، يمكننا اتخاذ بعض الإجراءات القانونية ضده. ولكن ، كعمل تجاري ناشئ ، لا نريد المخاطرة ، واتخاذ بعض الإجراءات القانونية كان أسوأ سيناريو يمكن أن نتخيله في ذلك الوقت. أعتقد أنها كانت أفضل فكرة لجعل المحتوى الخاص بنا وخدمته لبعض العملاء المقيدين والجديرين بالثقة (لأن هذا المنتج لم يكن مفيدًا للناس العاديين على أي حال). لذلك بعد بعض الأبحاث والمقارنة ، قررنا الذهاب مع AWS.

كومة التكنولوجيا

AWS S3 (خدمة التخزين البسيطة):

لتخزين البيانات. سنقوم بإنشاء دلو ونجعل من قاعدة البيانات الخاصة بنا. أقوم بتخزين صورة واحدة للمظاهرة.

AWS STS (خدمة رمز الأمان):

ويوفر بعض بيانات الاعتماد المؤقتة للمستخدمين. لذلك ، لا يتعين علينا إنشاء مستخدم IAM جديد في كل مرة يتم فيها تسجيل مستخدم جديد.

AWS IAM (إدارة الهوية والوصول):

من الممارسات الجيدة عدم استخدام بيانات اعتماد المستخدم الجذر. لذلك ، سنقوم بإنشاء دور سيكون له حق الوصول للقراءة فقط لمجموعة واحدة وإمكانية إنشاء رموز مؤقتة جديدة لكل عميل.

نود.جي إس:

سنضيف aws-sdk وننشئ بيانات اعتماد جديدة. أيضًا ، سوف نستخدم بيانات الاعتماد هذه لتقديم طلب والحصول على بياناتنا من مجموعة S3 خاصة.

AWS EC2:

سنقوم بتعيين دور لهذا الخادم وسيتم تشغيل تطبيق node.js على خادم EC2.

إنشاء دلو S3:

ما عليك سوى الانتقال إلى وحدة التحكم في S3 وإنشاء دلو جديد. نطاق اسم المجموعة هو عالمي ، مما يعني أنه يمكن لمستخدم واحد فقط أن يكون له اسم المجموعة المحدد. لذا حدد اسمًا فريدًا والمنطقة التي تتوقع أن يكون فيها عدد كبير من المستخدمين لديك ، وحدد التكوينات المناسبة للجرافة الخاصة بك وقم بإنشاء واحد. لاحظ أيضًا دلو ARN الخاص بك. سيساعدنا ذلك في تقييد دورنا في إنشاء بيانات اعتماد لهذا الدلو فقط.

سنقوم بتحميل صورة إلى هذا الدلو. يمكنك تحميل أي مستند آخر إذا كنت تريد. فقط تذكر ألا تجعل ملفك عامًا. الخاص هو الافتراضي. ومع ذلك ، إذا كنت تريد التأكد ، افتح عنوان URL الخاص بالكائن. إذا حدث خطأ ، فمن الجيد أن نذهب (وهذا يعني أنه لا يمكن الوصول إليه بشكل عام).

إنشاء سياسات دور وإلحاق IAM

اختر خدمة:

انتقل إلى وحدة التحكم في IAM وإنشاء دور جديد. أثناء إنشاء دور ، حدد EC2 كخدمة ستستخدم هذا الدور.

إرفاق السياسات:

اضغط على زر "التالي" لإضافة أذونات وإضافة AmazonS3ReadOnlyAccess لأنه إذا منحنا الوصول الكامل إلى دلو S3 الخاص بنا ، فسيتمكن عملائنا من التعامل مع المحتوى داخل دلونا ما لم تقم بإضافة سياسة أخرى أثناء إنشاء بيانات الاعتماد (لأنه يأخذ التقاطع لكل من دور وصول السياسة المقدمة).
على الرغم من أن تطبيق سياسة مخصصة يعد ميزة رائعة للغاية ، إلا أنني أتجنب هذا بشكل عام لأنني إذا كنت قادرًا على القيام بأدوار منفصلة لأداء مهام أخرى ، فلماذا أتحمل أي مخاطرة؟

اضف اشارة:

العلامات اختيارية. أضف المفتاح والوصف الخاص به إذا كنت تريد.

مراجعة:

أثناء مراجعة دورك ، تحقق من السياسات المرتبطة به. لقد عيّنت s3-temp لحقل اسم الدور.

إضافة سياسة مضمنة:

بعد إنشاء الدور ، افتح هذا الدور داخل وحدة التحكم وسترى خيارًا يوضح سياسة الإضافة المضمّنة. انقر فوقه وابحث عن STS وأضفه في دورك. سوف يساعد على إنشاء بيانات اعتماد مؤقتة.

بعد إضافة هذه السياسة المضمّنة ، امنحها اسمًا مناسبًا. لقد أطلقوا عليها اسم STS. يمكنك أيضًا تحديد الموارد التي تريد أن يكون دورك قادراً على إنشاء بيانات اعتماد مؤقتة لها. عليك فقط تحديد ARN لمجموعة S3 الخاصة بك إذا كنت لا تريد أن يكون هذا الدور قادراً على إنشاء بيانات اعتماد لبعض المجموعات الأخرى.

قم بإرفاق هذا الدور بمثيل EC2

لأول مرة ، كنت عالقًا لفترة من الوقت لأنني لم أكن أعلم أنه يتعين علي تعيين دور لمثيل EC2 معين. استغرق الأمر مني ساعات لإثبات ذلك وعلي تحديد علاقة ثقة بين مثيل EC2 ودوري. تزيد هذه الخطوة من الأمان حيث لا يمكنك إنشاء بيانات اعتماد جديدة دون تعيين الدور لمثيلك.

للحصول على مثيل EC2 جديد

أثناء إنشاء مثيل EC2 جديد ، في خيار تكوين تفاصيل مثيل ، حدد دور IAM الذي أنشأناه.

لمثيل EC2 موجود

انقر بزر الماوس الأيمن على مثيل EC2 الحالي وحدد إرفاق / استبدال دور IAM داخل Sesstings Instance وتعيين الدور.

كتابة الكود

أنا أستخدم node.js لجلب البيانات باستخدام aws-sdk. أثناء كتابة هذه المدونة ، الإصدار الحالي من SDK هو 2.393.0

أولاً ، سنكتب الرمز لإنشاء بيانات اعتماد

باستخدام رد الاتصال:

استخدام المتزامن / انتظار:

باستخدام. ثم ():

لقد نجحنا في إنشاء بيانات الاعتماد. من الجيد الآن تخزين البيانات في متغير بعد إجراء بعض التنسيقات لإعادة استخدامها.

const accessparams = {
    accessKeyId: data.Credentials.AccessKeyId،
    secretAccessKey: data.Credentials.SecretAccessKey ،
    sessionToken: data.Credentials.SessionToken،
}؛

الآن قبل جلب البيانات ، سنناقش الخيارات المختلفة المتوفرة لدينا في aws-sdk للحصول على البيانات.

  1. getSignedUrl: يستغرق بيانات الاعتماد المؤقتة وينشئ عنوان URL موقعًا جديدًا في كل مرة تقوم فيها بالاتصال بهذه الطريقة لأنه يأخذ الطوابع الزمنية الجديدة في كل مرة لإنشاءها.
  2. getObject: يستغرق أيضًا بيانات الاعتماد المؤقتة ولكنه لا يُرجع عنوان URL موقعًا جديدًا. تقوم بإرجاع محتوى ملفنا في الجزء الأساسي من الاستجابة بتنسيق المخزن المؤقت.

ماذا تختار

في حالتي ، اضطررت إلى إنشاء عناوين URL للبلاط جديدة في كل مرة ولم يكن لدي أي سيطرة على عناوين URL لإعادة استخدامها لأن الخريطة تنشئ عناوين URL جديدة في كل مرة نتفاعل معها. بشكل عام ، في أي تطبيق خريطة ، يمكنك تخزين تجانب الخريطة مؤقتًا وإعادة استخدامها في كل مرة بعد أي تفاعل. لكن ليس من الممكن استخدام getSignedUrl. ولكن إذا كان لديك التحكم في عناوين URL ويمكنك إعادة استخدامها ، فيجب عليك بالتأكيد الحصول على getSignedUrl. عناوين URL هذه صالحة لفترة زمنية معينة تقدمها أثناء إنشائها.

ولكن هناك بعض الحالات التي لا تكون فيها عناوين URL مفيدة وتحتاج فقط إلى الكائن نفسه أو إذا كنت لا ترغب في إنشاء عناوين URL بشكل متكرر وتخزين الصور بشكل مباشر ، فإن getObject يعد خيارًا جيدًا.

ملاحظة: انتهى بي الأمر باستخدام AWS CloudFront لأن getObject كان بطيئًا جدًا بالنسبة للتطبيق الخاص بي لأنه عمومًا في التطبيقات مثل لي ، يجب فقط تحديد

مرجع الكود

فيما يلي المستندات الرسمية إذا كنت ترغب في استكشاف المزيد حول عمليات S3 (خدمة التخزين البسيطة) أو أي خدمات AWS أخرى.

https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html

الحواشي

اسمحوا لي أن أعرف إذا كنت قد وجدت بعض الأفكار أفضل أو كان هناك خطأ في التعليمات البرمجية الخاصة بي أو الوصف. إذا كانت لديك أي شكوك أو لم تتمكن من فهم / تنفيذ ذلك ، فاترك تعليقًا أدناه وسنحاول الرد في أسرع وقت ممكن. حتى المرة القادمة!