รูปแบบการเข้าถึงข้อมูลแบบ Multi-tenant และนโยบาย IAM
การใช้งาน Data Stores บน AWS
Dunieski Otano
AWS Solutions Architect
เหตุการณ์ละเมิดความปลอดภัยแบบ Multi-tenant
แอปพลิเคชัน SaaS รองรับ 1,000 บริษัท
บั๊กในโค้ดทำให้เข้าถึงข้อมูลข้าม tenant ได้
พนักงานบริษัท A เห็นข้อมูลของบริษัท B
ผลลัพธ์: สูญเสียลูกค้า, ถูกฟ้องร้อง, ชื่อเสียงเสียหาย
ทำความเข้าใจ Multi-tenancy
Multi-tenancy คืออะไร?
ลูกค้าหลายรายใช้โครงสร้างพื้นฐานร่วมกัน
ประโยชน์
ประหยัดค่าใช้จ่าย ดูแลรักษาง่าย
ความท้าทาย
การแยกข้อมูลแต่ละ tenant อย่างสมบูรณ์
รูปแบบ Partition key ต่อ tenant
การออกแบบ
ใช้ tenantId เป็น partition key
ใส่ tenantId ในทุก item
ข้อดี
ประหยัดค่าใช้จ่าย รองรับได้หลายพัน tenant
ข้อกำหนด
ต้องมีการควบคุมการเข้าถึงและนโยบาย IAM ที่เข้มงวด
รูปแบบตารางแยกต่อ tenant
การออกแบบ
สร้างตารางแยกสำหรับแต่ละ tenant
ข้อดี
แยกข้อมูลได้ดีขึ้น รองรับการปฏิบัติตามกฎระเบียบได้ง่ายกว่า
ข้อเสีย
จัดการความซับซ้อนยาก และมีข้อจำกัดด้านจำนวนตาราง
รูปแบบฐานข้อมูลแยกต่อ tenant
การออกแบบ
สร้างฐานข้อมูลแยกสำหรับแต่ละ tenant
ข้อดี
แยกข้อมูลได้อย่างสมบูรณ์ ปรับแต่งค่าได้ตามต้องการ
ข้อเสีย
ค่าใช้จ่ายสูงที่สุด และภาระในการดูแลระบบมาก
IAM condition keys สำหรับการแยก tenant
dynamodb:LeadingKeys
จำกัดการเข้าถึง partition key
ตัวอย่างนโยบาย
"อนุญาตเมื่อ tenantId = tenant-123"
การบังคับใช้
AWS บังคับใช้ที่ระดับ API
การป้องกันแบบ Defense in Depth
ชั้นที่ 1: แอปพลิเคชัน
ตรวจสอบ tenantId ในโค้ด
ชั้นที่ 2: นโยบาย IAM
Condition keys บังคับการแยก tenant
ชั้นที่ 3: การออกแบบฐานข้อมูล
แยกทางกายภาพด้วย partition key
การทดสอบและตรวจสอบความถูกต้อง
ทดสอบการเข้าถึงข้าม tenant
ลองอ่านข้อมูลของ tenant อื่น
ควรล้มเหลวด้วย AccessDeniedException
บันทึกการตรวจสอบ
CloudTrail บันทึกการพยายามเข้าถึงทั้งหมด
ทบทวนสม่ำเสมอ
ตรวจสอบนโยบาย IAM และรูปแบบการเข้าถึง
ยินดีด้วย!
AWS Data Stores
: DynamoDB, S3, ElastiCache, OpenSearch
ออกแบบและปรับแต่ง
: การออกแบบตาราง การจัดการพื้นที่จัดเก็บ
รักษาความปลอดภัยข้อมูล
: การเข้ารหัส การจัดการ secrets และการแยก multi-tenant
มาฝึกกันเถอะ!
การใช้งาน Data Stores บน AWS
Preparing Video For Download...