S3 Storage بدون وصول عام

في إعدادنا، نقوم بتشغيل Discourse في مجموعة AWS EKS، ونتوقع استخدام S3 Bucket في نفس حساب AWS لتخزين الوسائط. يتم تزويد حاوية EKS التي تشغل Discourse بحساب خدمة Kubernetes ودور IAM. تم حظر جميع الوصول العام إلى S3 Bucket، مع منح ACL المالك فقط للحساب (حساب AWS) إمكانية الوصول للقراءة/الكتابة.

مع تمكين إعدادات موقع Discourse “تمكين تحميلات S3” و “استخدام ملف تعريف IAM لـ S3” و “تحميلات الوسائط الآمنة”، نتمكن من استخدام إعدادنا لتحميل الوسائط إلى مواضيع Discourse. ومع ذلك، بسبب عمليات التحقق في وحدة UploadCreator، تفشل أي تحميلات متعلقة بإعدادات الموقع مثل الشعار، إلخ، لأنها تحاول تحميل الوسائط مع تعيين المعلمة الخاصة بـ S3 API private_acl إلى “false”. ألن يكون من المنطقي أنه عند تمكين “تحميلات الوسائط الآمنة”، يتم تحميل جميع المحتويات مع تعيين private_acl إلى “true”؟

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

إعجاب واحد (1)

في هذه الحالة، هل سيكون من المنطقي جعل هذا يعتمد على تمكين علامة “s3 use iam profile” أم لا؟ إذا تم تمكين استخدام ملف تعريف IAM، فإننا نؤكد بطريقة ما أن الدلو ليس له وصول عام، وبالتالي سيحتاج إلى الوصول إليه باستخدام ACL خاص. قد أكون مخطئًا، لكنني لا أرى سببًا لاستخدام هذا الإعداد في Discourse، إلا إذا لم يتمكنوا من جعل الدلو الخاص بهم عامًا.

لا، هذا غير منطقي.

يستخدم هذا الموقع هنا s3 use iam profile ولديه أيضًا حاوية عامة. لا توجد أي علاقة بين أحدهما والآخر على الإطلاق.

s3 use iam profile يعني فقط “لا أريد تمرير زوج مفتاح/سر، تفضل واحصل عليه تلقائيًا من أجلي من واجهة برمجة تطبيقات AWS الداخلية”.

حسناً. إذن أعتقد أن الحل الوحيد أمامنا سيكون وجود علامة إعداد أخرى لتحديد ACL دلو s3 على أنه خاص، أم أن هذا يبدو غير منطقي؟

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

3 إعجابات

حسنًا، هذا قرار على مستوى الشركة في حالتنا. من المفترض أن تكون جميع الأصول، بما في ذلك الدلو، خاصة، ويجب جعلها متاحة عبر أدوار IAM. لتسليم كائنات الدلو إلى الواجهة الأمامية لـ Discourse، قمنا ببناء تطبيق S3 Proxy يعمل في نفس مجموعة EKS، وقمنا بتكوينه كشبكة توصيل محتوى (CDN) في إعدادات Discourse. الآن كل ما تبقى هو القدرة على تحميل أصول إعدادات الموقع مثل الشعار، وما إلى ذلك، كملفات خاصة، ولهذا نحتاج إلى هذا العلم. افتراضيًا، يحاول Discourse تحميل مثل هذه الأصول كملفات عامة، وهو ما أود تجاوزه بهذا العلم الجديد.

إعجاب واحد (1)

نحن نستخدم ميزة التحميلات الآمنة الممتازة لمثيل Discourse الخاص بنا، وهي تعمل بشكل جيد ولكن سيكون من الرائع لو كان هناك دعم لمنع جميع الوصول العام إلى الحاوية.

في الآونة الأخيرة، كنت أحاول حل جميع مشكلات “أفضل الممارسات الأمنية الأساسية لـ AWS” التي أثارها AWS Security Hub. أحد هذه المشكلات هو أن “حاويات الأغراض العامة S3 يجب أن تمنع الوصول العام”.

أتخيل أن العديد من الشركات تمر بنفس عملية محاولة تطبيق “أفضل الممارسات الأمنية الأساسية لـ AWS” وتواجه هذه المشكلة.

لا أتوقع أن يتم تحديد أولويات هذا في أي وقت قريب ولكنني وجدت هذا الموضوع وفكرت في إضافة +1 إليه.

إليك توصية AWS FSBP: Security Hub controls for Amazon S3 - AWS Security Hub

إعجاب واحد (1)