خطأ Access Denied في S3 محبط لأنّ أسبابه المحتملة متعدّدة الطبقات. هذا الدليل يرتّبها لتفحصها بمنهجية. يفترض إلمامًا بـ ما هو S3؟.
لماذا يظهر هذا الخطأ؟
الوصول إلى كائن في S3 يجب أن تسمح به كل الطبقات المعنيّة؛ يكفي أن ترفضه طبقة واحدة ليظهر Access Denied. الأسباب مرتّبة من الأشيع:
1. حجب الوصول العامّ (Block Public Access)
إن كنت تحاول جعل محتوى عامًّا (كموقع ثابت)، فتذكّر أنّ S3 يحجب الوصول العامّ افتراضيًا. ما لم تعطّل هذا الحجب على الحاوية، ستُرفض المحاولات العامّة مهما كانت السياسة.
2. سياسة الحاوية أو صلاحيات IAM ناقصة
- سياسة الحاوية (Bucket Policy): قد لا تسمح بالإجراء المطلوب (مثل
s3:GetObject) على المورد الصحيح. - صلاحيات IAM: إن كنت تصل عبر مستخدم أو دور، فقد لا تمنحه سياسة IAM إذن الوصول إلى الحاوية.
تذكّر نموذج المسؤولية المشتركة: ضبط هذه الصلاحيات مسؤوليّتك.
3. ملكية الكائن و ACL
قد يكون الكائن مملوكًا لحساب مختلف أو محكومًا بقائمة تحكّم وصول (ACL) تمنعك، خصوصًا في السيناريوهات متعدّدة الحسابات.
4. المنطقة أو الاسم الخاطئ
تأكّد أنّك تخاطب الحاوية بالاسم الصحيح وفي المنطقة الصحيحة؛ خطأ بسيط في الاسم قد يظهر كخطأ صلاحيات.
منهجية التشخيص
اسأل بالترتيب: هل الطلب عامّ ويصطدم بحجب الوصول العامّ؟ → هل تسمح سياسة الحاوية بالإجراء على المورد؟ → هل تملك هويّتك (IAM) الإذن؟ → هل الملكية/الـ ACL تعيق؟ عزل الطبقة المسؤولة يقودك للحلّ.
الخطوات التالية
لجعل موقع S3 عامًّا بأمان راجع استضافة موقع ثابت على S3. ولأخطاء الاعتماد راجع إصلاح خطأ InvalidClientTokenId.