CloudFront ร่วมกับ WAF และ Lambda@Edge

AWS WAF (ไฟร์วอลล์แอปพลิเคชันบนเว็บ) จะกรองและตรวจสอบคำขอ HTTP/HTTPS ที่มายังดิสทริบิวชัน CloudFront ของคุณ เมื่อติด Web ACL ของ WAF เข้ากับดิสทริบิวชัน คุณจะสามารถบล็อกการโจมตีเว็บที่พบบ่อย เช่น การแทรก SQL, การเขียนสคริปต์ข้ามไซต์ (XSS), บอตที่เป็นอันตราย และการโจมตีตาม OWASP Top 10 ก่อนที่จะไปถึงต้นทาง

WAF ทำงานที่เอดจ์ของ CloudFront ซึ่งหมายความว่าคำขอที่เป็นอันตรายจะถูกปฏิเสธที่ตำแหน่งเอดจ์ที่ใกล้ที่สุด แทนที่จะเดินทางไปถึง ALB หรือเซิร์ฟเวอร์แอปพลิเคชัน วิธีนี้ช่วยลดภาระของแบ็กเอนด์และหยุดการโจมตีได้ใกล้กับผู้โจมตีมากขึ้น

Web ACL ของ WAF ประกอบด้วย กฎ และ กลุ่มกฎ ที่จัดลำดับไว้ โดยแต่ละรายการจะจับคู่แอตทริบิวต์ของคำขอและดำเนินการ (Allow, Block, Count, CAPTCHA) ระบบจะประเมินกฎตามลำดับความสำคัญ และใช้การดำเนินการของกฎแรกที่ตรงกัน

AWS มีกลุ่มกฎที่ จัดการให้ ซึ่งเป็นชุดกฎสำเร็จรูปที่ AWS และผู้ขายใน AWS Marketplace ดูแล AWS Managed Rules - Core Rule Set ครอบคลุม OWASP Top 10 โดยไม่ต้องกำหนดค่า กลุ่มกฎที่จัดการให้จะได้รับการอัปเดตโดย AWS เมื่อมีภัยคุกคามใหม่เกิดขึ้น จึงช่วยลดภาระการดำเนินงานของคุณ

กฎตามอัตราใน WAF จะนับจำนวนคำขอจาก IP ต้นทางแต่ละรายการภายในช่วงเวลา 5 นาที หาก IP ใดเกินค่าขีดจำกัด (เช่น 2,000 คำขอต่อ 5 นาที) WAF จะบล็อกคำขอเพิ่มเติมจาก IP นั้นจนกว่าอัตราจะลดลง กฎตามอัตราช่วยป้องกันการโจมตีแบบเดารหัสผ่าน การลองใช้ข้อมูลประจำตัวจำนวนมาก และการขูดข้อมูลแบบ DDoS อย่างง่าย

AWS WAF Bot Control เป็นกลุ่มกฎที่จัดการให้ ซึ่งจัดประเภททราฟฟิกเป็นหมวดหมู่ต่าง ๆ ได้แก่ บอตที่ยืนยันแล้ว (Googlebot, Bingbot) โปรแกรมขูดข้อมูล เครื่องมือตรวจสอบ และทราฟฟิกจากมนุษย์ คุณสามารถกำหนดการดำเนินการที่แตกต่างกันให้แต่ละหมวดหมู่ได้ เช่น อนุญาตบอตของเครื่องมือค้นหา ท้าทายบอตที่ไม่รู้จักด้วย CAPTCHA และบล็อกโปรแกรมขูดข้อมูลที่เป็นอันตราย

Web ACL ของ WAF มีขอบเขตเป็น CLOUDFRONT (ทั่วโลก สำหรับใช้กับ CloudFront) หรือ REGIONAL (สำหรับใช้กับ ALB, API Gateway, AppSync หรือกลุ่มผู้ใช้ Cognito ในรีเจียนที่ระบุ) ต้องสร้าง ACL ของ WAF ที่มีขอบเขต CloudFront ใน รีเจียน us-east-1 ไม่ว่าทราฟฟิกจะมาจากที่ใด เนื่องจาก CloudFront ได้รับการจัดการจากรีเจียนนั้น

นี่เป็นจุดที่มักทำให้พลาดในข้อสอบ: หากคุณสร้าง Web ACL ของ WAF ใน eu-west-1 แล้วพยายามนำไปเชื่อมกับ CloudFront การเชื่อมต่อจะล้มเหลว ต้องสร้าง ACL ของ WAF สำหรับ CloudFront ใน us-east-1 เสมอ

Lambda@Edge ช่วยให้คุณเรียกใช้ฟังก์ชัน Lambda ของ Node.js หรือ Python ที่ตำแหน่งเอดจ์ของ CloudFront เพื่อตอบสนองต่อเหตุการณ์ของ CloudFront ฟังก์ชันจะทำงานภายในเวลาไม่กี่มิลลิวินาทีหลังคำขอของผู้ใช้ โดยไม่ต้องส่งทราฟฟิกกลับไปยังรีเจียนส่วนกลางเพื่อประมวลผล

ฟังก์ชัน Lambda@Edge จะติดตั้งใช้งานในรีเจียน us-east-1 แต่จะถูกจำลองไปยังตำแหน่งเอดจ์ของ CloudFront ทั่วโลกโดยอัตโนมัติ ซึ่งทำให้โค้ดทำงานใกล้ผู้ใช้มากที่สุด และรองรับการปรับเนื้อหาเฉพาะบุคคล การตรวจสอบสิทธิ์ และการทดสอบ A/B ที่เอดจ์ โดยเพิ่มเวลาแฝงเพียงเล็กน้อย

ฟังก์ชัน Lambda@Edge สามารถดักจับคำขอและการตอบกลับของ CloudFront ได้ที่สี่จุดในวงจรการทำงาน:

• Viewer Request: หลังจาก CloudFront ได้รับคำขอจากผู้ชมและก่อนตรวจสอบแคช ใช้สำหรับการตรวจสอบสิทธิ์ การเปลี่ยนเส้นทาง และการปรับแต่งส่วนหัว
• Origin Request: หลังแคชไม่พบข้อมูลและก่อนส่งต่อไปยังต้นทาง ใช้สำหรับการเขียน URL ใหม่และเพิ่มส่วนหัวแบบกำหนดเองให้ต้นทาง
• Origin Response: หลังได้รับการตอบกลับจากต้นทางและก่อนแคชการตอบกลับนั้น ใช้สำหรับเพิ่มส่วนหัวด้านความปลอดภัยและแก้ไขการตอบกลับ
• Viewer Response: ก่อนที่ CloudFront จะส่งการตอบกลับไปยังผู้ชม ใช้สำหรับเพิ่มหรือแก้ไขส่วนหัวของการตอบกลับ

AWS มีตัวเลือกการประมวลผลที่เอดจ์สองแบบ ซึ่งมีข้อแลกเปลี่ยนแตกต่างกัน:

• CloudFront Functions: ทำงานภายในเวลาไม่ถึงหนึ่งมิลลิวินาที รองรับเฉพาะ JavaScript มีค่าใช้จ่ายต่ำมาก (ประมาณ 1/6 ของราคา) ทำงานเฉพาะเหตุการณ์ Viewer Request และ Viewer Response จำกัดเวลาประมวลผล 1 มิลลิวินาที และไม่มีสิทธิ์เข้าถึง VPC/เครือข่าย
• Lambda@Edge: ทำงานได้นานสูงสุด 30 วินาที (Viewer) / 30 วินาที (Origin) รองรับ Node.js หรือ Python ครบทั้งสี่จุดทริกเกอร์ สามารถส่งคำขอเครือข่าย และเข้าถึงเนื้อหาของคำขอ/การตอบกลับได้

ใช้ CloudFront Functions สำหรับการปรับแต่งส่วนหัวอย่างง่าย การทำให้ URL อยู่ในรูปแบบมาตรฐาน และการคำนวณคีย์แคช และใช้ Lambda@Edge สำหรับตรรกะที่ซับซ้อนซึ่งต้องเรียกเครือข่าย ใช้เวลาประมวลผลนานกว่า หรือประมวลผลที่ฝั่งต้นทาง

รูปแบบการใช้ Lambda@Edge ที่พบบ่อยในข้อสอบ SAA-C03:

• การตรวจสอบ JWT ที่เอดจ์: ฟังก์ชัน Viewer Request ตรวจสอบส่วนหัว Authorization และส่ง 401 กลับสำหรับคำขอที่ไม่ได้รับอนุญาตโดยไม่เรียกถึงต้นทาง
• การทดสอบ A/B: Viewer Request กำหนดผู้ใช้ให้อยู่ในกลุ่ม A หรือ B (ผ่านคุกกี้) และแก้ไขคำขอเพื่อดึง /a/page.html หรือ /b/page.html
• การเขียน URL ใหม่: Origin Request เปลี่ยน URL ที่อ่านง่ายให้เป็นเส้นทางไฟล์จริงใน S3
• การปรับขนาดรูปภาพแบบไดนามิก: Origin Request สร้างคำขอไปยัง Lambda สำหรับประมวลผลรูปภาพ และ Origin Response แคชรูปภาพที่ปรับขนาดแล้ว
• ส่วนหัวความปลอดภัย HTTP: Viewer Response แทรกส่วนหัว CSP, HSTS และ X-Frame-Options

Lambda@Edge มีข้อจำกัดหลายประการเมื่อเทียบกับ Lambda มาตรฐาน:

• ฟังก์ชันต้องอยู่ในรีเจียน us-east-1
• ไม่รองรับ VPC (ไม่สามารถเข้าถึงทรัพยากรใน VPC ได้)
• ไม่มีตัวแปรสภาพแวดล้อม (ให้ฝังคอนฟิกูเรชันไว้ในโค้ดของฟังก์ชัน หรือดึงข้อมูลจาก Parameter Store เมื่อเริ่มทำงานแบบ cold start)
• ไม่สามารถใช้ Lambda Layers ได้
• ระยะหมดเวลาของเหตุการณ์จากผู้ชม: 5 วินาที; ระยะหมดเวลาของเหตุการณ์จากต้นทาง: 30 วินาที
• ขีดจำกัดขนาดแพ็กเกจสำหรับการดีพลอย: 1 MB (เหตุการณ์จากผู้ชม) / 50 MB (เหตุการณ์จากต้นทาง)

ข้อจำกัดเหล่านี้ทำให้ Lambda@Edge ไม่เหมาะสำหรับการคำนวณที่ใช้เวลานาน การดำเนินงานที่ต้องพึ่งพา VPC หรือฟังก์ชันที่ต้องใช้คอนฟิกูเรชันแบบไดนามิกในการดีพลอยแต่ละครั้ง

WAF และ Lambda@Edge มีบทบาทด้านความปลอดภัยที่แตกต่างกันและช่วยเสริมการทำงานซึ่งกันและกัน:

• WAF: บล็อกการโจมตีโดยอาศัยลายเซ็น (การแทรก SQL, XSS, ผู้โจมตีที่รู้จัก, การจำกัดอัตรา)—กฎที่มีการจัดการจะจัดการการโจมตีทั่วไปโดยอัตโนมัติ
• Lambda@Edge: ใช้ตรรกะทางธุรกิจแบบกำหนดเองเพื่อรักษาความปลอดภัย (การตรวจสอบ JWT การตรวจสอบเซสชัน การตรวจสอบโทเค็นเข้าถึง)—มีความยืดหยุ่น แต่ต้องใช้ความพยายามในการพัฒนา

สถาปัตยกรรมแบบป้องกันเชิงลึก: WAF บล็อกรูปแบบการโจมตีที่รู้จักก่อน จากนั้น Lambda@Edge ตรวจสอบการยืนยันตัวตนในระดับธุรกิจ URL/คุกกี้ที่ลงนามของ CloudFront จำกัดการเข้าถึงเนื้อหา และ OAC ทำให้ S3 เป็นส่วนตัว แต่ละชั้นป้องกันการโจมตีคนละประเภทได้อย่างเป็นอิสระ

ตรวจสอบชั้นความปลอดภัยที่ขอบเครือข่ายด้วยเครื่องมือเหล่านี้:

• บันทึกของ WAF: เปิดใช้การบันทึกคำขอแบบเต็มไปยัง S3, CloudWatch Logs หรือ Kinesis Firehose เพื่อดูว่ากฎใดตรงกันและบล็อกทราฟฟิกใดบ้าง
• เมทริกซ์ของ WAF: BlockedRequests, AllowedRequests, CountedRequests แยกตามกฎใน CloudWatch
• บันทึกของ Lambda@Edge: กลุ่ม CloudWatch Logs จะถูกสร้างขึ้นในแต่ละรีเจียนที่ฟังก์ชันทำงาน ให้ใช้ CloudWatch Insights เพื่อค้นหาข้อมูลข้ามรีเจียน
• บันทึกแบบเรียลไทม์ของ CloudFront: สตรีมบันทึกการเข้าถึงไปยัง Kinesis เพื่อวิเคราะห์ได้ทันที (ต่างจากบันทึกการเข้าถึงมาตรฐานที่รวมข้อมูลทุกสองสามนาที)

ทดสอบความเข้าใจแนวคิดของ AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

ในบทเรียนนี้ คุณได้เรียนรู้ว่า AWS WAF บล็อกการโจมตีเว็บทั่วไปที่ขอบเครือข่ายของ CloudFront โดยใช้กลุ่มกฎที่มีการจัดการและกลุ่มกฎแบบกำหนดเอง, Lambda@Edge เรียกใช้โค้ดแบบกำหนดเองที่จุดทริกเกอร์ของ CloudFront ทั้งสี่จุด ทั่วโลก และ CloudFront Functions ทำงานเสร็จภายในเวลาไม่ถึงหนึ่งมิลลิวินาที สำหรับตรรกะอย่างง่ายที่ฝั่งผู้ชม ต้องสร้าง WAF ACL สำหรับ CloudFront ใน us-east-1 บทถัดไปเราจะสำรวจ Application, Network และ Gateway Load Balancer