เลือก Authorizer ของ API Gateway

การใช้ AWS Security สำหรับนักพัฒนา

Rahul Singh

Technical Product Manager

ตรวจสอบก่อนโค้ดจะทำงาน

ผู้เรียกผ่าน Authorizer ของ API Gateway ก่อนจะถึงโค้ดของคุณ และผู้เรียกที่ถูกปฏิเสธจะถูกตีกลับด้วยรหัส 401

ผ่าน: คำขอไปถึงโค้ดของคุณ

ไม่ผ่าน: 401 unauthorized โค้ดของคุณไม่ทำงานเลย

ใครเป็นผู้ตรวจสอบ

Authorizer ให้เลือก 3 แบบ

IAM auth (AWS_IAM): AWS ตรวจสอบ signature

แผนภาพแนวตั้งบนแกนที่ไล่จาก AWS เป็นผู้ตรวจสอบไปจนถึงคุณเป็นผู้ตรวจสอบเอง มีเพียงการ์ดแรกที่เติมข้อมูลแล้ว คือ IAM auth ที่ AWS ตรวจสอบ signature

ใครเป็นผู้ตรวจสอบ

Authorizer ให้เลือก 3 แบบ

IAM auth (AWS_IAM): AWS ตรวจสอบ signature
Cognito authorizer (COGNITO_USER_POOLS): AWS ตรวจสอบ token
- Signature, iss, aud, exp

แผนภาพแนวตั้งเดิมที่เติมข้อมูลแล้ว 2 การ์ด คือ IAM auth ที่ AWS ตรวจสอบ signature และ Cognito authorizer ที่ AWS ตรวจสอบ token

ใครเป็นผู้ตรวจสอบ

Authorizer ให้เลือก 3 แบบ

IAM auth (AWS_IAM): AWS ตรวจสอบ signature
Cognito authorizer (COGNITO_USER_POOLS): AWS ตรวจสอบ token
- Signature, iss, aud, exp
Lambda authorizer: ฟังก์ชันของคุณคืนค่า allow หรือ deny
- สำหรับ token ที่ไม่ใช่ Cognito

Authorizer สามแบบเรียงจาก AWS เป็นผู้ตรวจสอบไปจนถึงคุณเป็นผู้ตรวจสอบเอง: IAM auth ที่ AWS ตรวจสอบ signature, Cognito authorizer ที่ AWS ตรวจสอบ token และ Lambda authorizer ที่คุณเขียนการตรวจสอบเอง

จับคู่ประตูกับผู้เรียก

ผู้เรียกเป็นตัวตัดสิน

บริการภายใน: มี AWS credentials อยู่แล้ว

แถวแรกจากสามแถวที่จับคู่ผู้เรียกกับ authorizer: บริการภายในจับคู่กับ IAM auth

จับคู่ประตูกับผู้เรียก

ผู้เรียกเป็นตัวตัดสิน

บริการภายใน: มี AWS credentials อยู่แล้ว
ผู้ใช้แอป: ถือ Cognito token

สองในสามแถวที่จับคู่ผู้เรียกกับ authorizer: บริการภายในจับคู่กับ IAM auth และผู้ใช้แอปจับคู่กับ Cognito authorizer

จับคู่ประตูกับผู้เรียก

ผู้เรียกเป็นตัวตัดสิน

บริการภายใน: มี AWS credentials อยู่แล้ว
ผู้ใช้แอป: ถือ Cognito token
แอปพาร์ทเนอร์: มีตรรกะการตรวจสอบสิทธิ์ของตัวเอง

ผู้เรียกสามแบบจับคู่กับ authorizer ที่แต่ละแบบต้องการ: บริการภายในกับ IAM auth, ผู้ใช้แอปกับ Cognito authorizer และแอปพาร์ทเนอร์กับ Lambda authorizer

ใส่ใจประเภทของ API

REST API

Authorizer ทั้งสามแบบ รวมถึง resource policy
API key, การจำกัดอัตราต่อไคลเอนต์, การตรวจสอบคำขอ, WAF

การ์ดเปรียบเทียบของ REST API ที่ติ๊กถูก IAM auth, Cognito user pool authorizer, Lambda authorizer และ resource policy ส่วนการ์ด HTTP API ข้าง ๆ ยังไม่ได้เติมข้อมูล

ใส่ใจประเภทของ API

REST API

Authorizer ทั้งสามแบบ รวมถึง resource policy
API key, การจำกัดอัตราต่อไคลเอนต์, การตรวจสอบคำขอ, WAF

HTTP API

JWT authorizer รองรับ OIDC issuer ใดก็ได้
ไม่มี resource policy เร็วกว่าและถูกกว่า

การ์ดสองใบเปรียบเทียบ authorizer ที่ API แต่ละประเภทรองรับ: REST API เพิ่ม resource policy ส่วน HTTP API เปลี่ยนจาก Cognito authorizer เป็น JWT authorizer และไม่มี resource policy

Authorizer จำคำตอบไว้

แคชไว้เพื่อประหยัดเวลา

การเรียกครั้งแรก: authorizer ทำงาน
การเรียกครั้งถัดไป: อ่านคำตอบจากแคช

การเรียกครั้งแรกทำให้ authorizer ทำงานและเขียนค่า allow ลงในแคชพร้อมกำหนดอายุ ส่วนการเรียกครั้งถัดไปอ่านค่า allow จากแคชโดยไม่ต้องรัน authorizer อีกครั้ง

Authorizer จำคำตอบไว้

แคชไว้เพื่อประหยัดเวลา

การเรียกครั้งแรก: authorizer ทำงาน
การเรียกครั้งถัดไป: อ่านคำตอบจากแคช

อายุแคช (TTL)

authorizerResultTtlInSeconds: ค่าเริ่มต้น 300 วินาที สูงสุด 3600 วินาที
ตั้งเป็น 0 เพื่อปิดการแคช

ค่า allow ที่แคชไว้อาจอยู่นานกว่าสิทธิ์จริง

เส้นเวลาสองช่องทาง ช่องสิทธิ์เปลี่ยนจากใช้ได้เป็นถูกเพิกถอน ณ จุดเพิกถอน ส่วนช่องค่า allow ที่แคชไว้ด้านล่างยังคงแสดง allow หลังจุดนั้น โดยช่วงเวลาหลังเพิกถอนถูกแรเงาไว้

ณ ขณะที่คุณเพิกถอนสิทธิ์

สิทธิ์: ถูกเพิกถอนทันที
ค่า allow ที่แคชไว้: ยังคงให้สิทธิ์อยู่

ค่า allow ที่แคชไว้อาจอยู่นานกว่าสิทธิ์จริง

เส้นเวลาสองช่องทางเดิมที่มีช่วงระหว่างจุดเพิกถอนกับ TTL หมดอายุถูกแรเงาและระบุว่ายังคงให้สิทธิ์ โดยสิทธิ์ถูกเพิกถอนแล้วแต่ค่า allow ที่แคชไว้ยังคงให้สิทธิ์เข้าถึงอยู่

ช่วงเวลาคั่นกลาง

สิทธิ์หมดไปแล้ว แต่แคชไม่รับรู้
การเข้าถึงยังคงอยู่จนกว่า TTL จะหมดอายุ

ค่า allow ที่แคชไว้อาจอยู่นานกว่าสิทธิ์จริง

เส้นเวลาสองช่องทางเดิมพร้อมลูกศรข้ามช่วงที่แรเงา แสดงให้เห็นว่า TTL ที่สั้นลงทำให้หมดอายุเร็วขึ้นและลดช่วงเวลาที่สิทธิ์ซึ่งถูกเพิกถอนแล้วยังคงให้สิทธิ์เข้าถึง

ควบคุมช่วงเวลานั้น

ใช้ TTL สั้นเมื่อต้องเพิกถอนสิทธิ์อย่างรวดเร็ว
ตั้ง TTL เป็น 0 สำหรับเส้นทางที่อ่อนไหวที่สุด

ผู้เรียกรายหนึ่งข้ามประตูหน้าไป

บุคคลที่สามภายในบัญชีของคุณ

สวมบทบาท (assume role) ที่คุณสร้างไว้
คุณมอบ role ARN ให้

ผู้ให้บริการ monitoring อยู่ระหว่างกล่องลูกค้าสองกล่องด้านบนกับ role ของคุณด้านล่าง กล่องของคุณส่ง role ARN ลงไปให้ผู้ให้บริการ ซึ่งสวมบทบาทของคุณ กล่องลูกค้าที่สองยังเป็นสีเทาและยังไม่เข้ามาในเรื่องนี้

ผู้เรียกรายหนึ่งข้ามประตูหน้าไป

บุคคลที่สามภายในบัญชีของคุณ

สวมบทบาท (assume role) ที่คุณสร้างไว้
คุณมอบ role ARN ให้

Role ARN ไม่ใช่ความลับ

ปัญหา confused deputy

กล่องลูกค้าที่สองเปิดใช้งานเป็นสีแดงและส่ง role ARN ของคุณราวกับเป็นของตัวเอง ตอนนี้มีลูกศรสองเส้นวิ่งจากผู้ให้บริการ monitoring ลงไปยัง role ของคุณ หนึ่งเส้นต่อหนึ่งลูกค้า โดยไม่มีสิ่งใดแยกความแตกต่างระหว่างทั้งสอง

ผู้เรียกรายหนึ่งข้ามประตูหน้าไป

บุคคลที่สามภายในบัญชีของคุณ

สวมบทบาท (assume role) ที่คุณสร้างไว้
คุณมอบ role ARN ให้

Role ARN ไม่ใช่ความลับ

ปัญหา confused deputy

วิธีแก้: sts:ExternalId

ผู้ให้บริการสร้างค่าหนึ่งต่อลูกค้าหนึ่งราย
trust policy ของคุณกำหนดให้ต้องตรงกัน

role ของคุณตอนนี้มีข้อกำหนดว่า external ID ต้องเท่ากับ 12345 การเรียกที่มีค่า 12345 ไปถึง role ได้ ส่วนการเรียกที่มีค่า 99999 ถูกหยุดด้วยเครื่องหมายกากบาทสีแดงก่อนจะไปถึง

มาฝึกกันเถอะ!

การใช้ AWS Security สำหรับนักพัฒนา