[AWS Technical Support Note] วิธีการรับมือเมื่อเกิดข้อผิดพลาดในการเข้าถึง S3 presigned URL

ดูขั้นตอนในการแยกปัญหาต่างๆที่เกิดขึ้นในการสร้าง S3 presigned URL

ปัญหาที่เกิดขึ้น

หลังจากสร้าง S3 presigned URL และทำการเข้าถึงแต่ได้รับแจ้งข้อผิดพลาดในการเข้าถึง
ต้องทำอย่างไรถึงจะดึงข้อมูลของ object ได้

วิธีแก้ปัญหา

ปัญหานี้มีความเป็นไปได้หลายสาเหตุ ลองทำตามขั้นตอนด้านล่างเพื่อแยกแยะสาเหตุของปัญหานี้

1. ตอนสร้าง S3 presigned URL ระบุชื่อ bucket ไม่ถูกต้อง

จุดที่ต้องตรวจสอบ
ระบุชื่อ bucket ที่ถูกต้องและสร้าง presigned URL อีกครั้ง

ในกรณีนี้ข้อผิดพลาดจะตอบกลับเป็น NoSuchBucketตามด้านล่าง

<Error>
    <Code>NoSuchBucket</Code>
    <Message>The specified bucket does not exist</Message>
    <BucketName>not-exits-bucket</BucketName>
    <RequestId>SK732TEHY0E7FHAR</RequestId>
    <HostId>txJ0vO/b1IOueFBfBBAgh6I6cow4dXSLV+xhbpYcQEWnJa/1ogkzGm/b88RVy0eOh5HNIOP8mI0=</HostId>
</Error>

ในตอนที่สร้าง presigned URL จะไม่พบว่ามี bucket อยู่
เมื่อมีการเข้าถึงแล้วไม่พบว่ามี bucket อยู่ก็จะแสดงข้อผิดพลาดนี้

2. ระบุชื่อไฟล์ผิดในตอนสร้าง presigned URL

จุดที่ต้องตรวจสอบ
ระบุชื่อไฟล์ที่ถูกต้องแล้วสร้าง presigned URL ใหม่อีกครั้ง

ในกรณีนี้ข้อผิดพลาดจะตอบกลับเป็น AccessDenied ตามด้านล่าง

<Error>
    <Code>AccessDenied</Code>
    <Message>Access Denied</Message>
    <RequestId>VTGPPNATQVQCDABD</RequestId>
    <HostId>jPgu4l6UGpMMLhbH0sNStd188hUGPb8Mc7hlTeudWrjTo2sqaMbH0LzXoZqF0r/2/vGoygJjOuA=</HostId>
</Error>

โดยจะไม่ตอบกลับเป็น NoSuchFile เหมือนกรณีที่ชื่อ bucket ผิด

โดยการตอบกลับเป็น NoSuchFile จะเป็นการบอกไบ้ว่ามีไฟล์อยู่หรือไม่

ด้วยเหตุนี้จึงคาดการณ์ได้ว่าเป็นเพียงแค่การตอบกลับว่าไม่มีสิทธิ์ในการเข้าถึง object เท่านั้น

3. นาฬิกาของ client ที่สร้าง S3 presigned URL ไม่ตรงกัน

จุดที่ต้องตรวจสอบ
ตรวจสอบนาฬิกาของ client และปรับเป็นเวลาที่ถูกต้อง

ในกรณีนี้ข้อผิดพลาดจะตอบกลับเป็น AccessDenied ตามด้านล่าง

หากเวลาเป็นวันที่ 2023-11-17 ณ เวลาที่เขียนบทความ(2023-08-01)

<Error>
    <Code>AccessDenied</Code>
    <Message>Request is not yet valid</Message>
    <X-Amz-Date>1641042858000</X-Amz-Date>
    <Expires>2023-11-17T14:14:18Z</Expires>
    <ServerTime>2023-08-01T13:14:44Z</ServerTime>
    <RequestId>SAWAHZHP2A652ZQM</RequestId>
    <HostId>9G4/HhXPM+R5mlUoe72WG5xtOF6Nv/rkFVfBBiULmXZoqmtH0pAVc/oabuCGw49W9yOHtwZ50dQ=</HostId>
</Error>

หากเวลาเป็นวันที่ 2024-02-14 ณ เวลาที่เขียนบทความ(2023-08-01)

<Error>
    <Code>AccessDenied</Code>
    <Message>Request has expired</Message>
    <X-Amz-Expires>3600</X-Amz-Expires>
    <Expires>2024-02-14T14:20:28Z</Expires>
    <ServerTime>2023-08-01T13:20:36Z</ServerTime>
    <RequestId>VB2DAMC20SC2GQ1N</RequestId>
    <HostId>/JZxZlicBUAKVc7sn2sNQKNQ0Pxc2IVdo6Y4ifpew1fi5Nc1qrzcZVBBHyFMJPZQV2sXNcpDcE8=</HostId>
</Error>

※ ระยะเวลาการหมดอายุ expires-in จะระบุเป็นค่าเริ่มต้น 1 ชั่วโมง (3600)

4. สิทธิ์ของ IAM user/role ที่สร้าง S3 presigned URL s3:getObject ไม่เพียงพอ

จุดที่ต้องตรวจสอบ
ตรวจสอบว่าการดำเนินการด้วย s3:getObject ได้รับอนุญาตตามข้อมูลต่อไปนี้หรือไม่ เมื่อมีการเข้าถึง S3 presigned URL

ตรวจสอบว่าเมื่อมีการเข้าถึง S3 presigned URL การดำเนินการด้วย s3:getObject ได้รับอนุญาตตามข้อมูลต่อไปนี้หรือไม่

  • IAM User/Role policy
  • S3 Bucket policy

โดยสามารถวินิจฉัยได้ว่าเข้าถึง object ได้หรือไม่โดยการเข้าถึงด้วย IAM User/Role

ในกรณีนี้ข้อผิดพลาดจะตอบกลับเป็น AccessDenied ตามด้านล่าง

<Error>
    <Code>AccessDenied</Code>
    <Message>Access Denied</Message>
    <RequestId>VTGPPNATQVQCDABD</RequestId>
    <HostId>jPgu4l6UGpMMLhbH0sNStd188hUGPb8Mc7hlTeudWrjTo2sqaMbH0LzXoZqF0r/2/vGoygJjOuA=</HostId>
</Error>

ถึงแม้จะเป็น User หรือ Role ที่ไม่มี policy ใดๆเลยก็สามารถสร้าง S3 Presigned URL ได้

แต่การจะเข้าถึงได้หรือไม่ขึ้นอยู่กับตอนที่เข้าถึง Presigned URL
โดย IAM User/Role ที่สร้าง Presigned URL หากได้รับสิทธ์จะไม่ถูกปฏิเสธโดย IAM policy หริอ bucket policy และสามารถเข้าถึงได้

สำหรับท่านใดที่ต้องการรู้รายละเอียดเพิ่มเติมสามารถตรวจสอบได้ตามรายละเอียดทางด้านล่าง(Japanese)

ข้อสังเกตุในการดำเนินการ

บทความนี้ได้มีเขียนเกี่ยวกับการตรวจสอบแยกแยะข้อผิดพลาดของชื่อไฟล์ หรือ ชื่อ bucket ไว้แล้วในข้างต้น

แต่ในการตรวจสอบตามข้อ「4. สิทธิ์ของ IAM user/role ที่สร้าง S3 presigned URL s3:getObject ไม่เพียงพอ」อาจทำได้ยากขึ้นตามจำนวนของ policy

ดังนั้น การแก้ไขควรทดสอบแยกปัญหาจากวิธีที่ขั้นตอนน้อย (ที่สะดวก) ก่อน และเมื่อมีการจดบันทึกว่าได้แยกปัญหาไหนไปแล้วบ้าง ก็อาจจะช่วยให้การแก้ปัญหาใช้เวลาได้สั้นลง

หวังว่าบทความนี้จะสามารถช่วยแก้ปัญหาหรือเป็นประโยชน์สำหรับผู้ที่กำลังเจอปัญหานี้ หรือ มีข้อสงสัยเกี่ยวกับปัญหานี้กันนะครับ

บทความอ้างอิง

บทความต้นฉบับ