Cloud & IT Cert Prep · บทเรียน

ความปลอดภัยแบบไร้เซิร์ฟเวอร์และความปลอดภัยของฟังก์ชัน

ความปลอดภัยแบบไร้เซิร์ฟเวอร์และความปลอดภัยของฟังก์ชัน เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

การประมวลผลแบบไร้เซิร์ฟเวอร์คืออะไร

การประมวลผลแบบไร้เซิร์ฟเวอร์ (ฟังก์ชันในรูปแบบบริการ หรือ FaaS) ช่วยให้นักพัฒนานำฟังก์ชันแต่ละรายการไปใช้งานและเรียกใช้ด้วยเหตุการณ์ต่าง ๆ เช่น คำขอ HTTP ข้อความในคิว ตัวกระตุ้นจากฐานข้อมูล หรือเครื่องตั้งเวลาตามกำหนด โดยไม่ต้องจัดการเซิร์ฟเวอร์เบื้องหลัง แพลตฟอร์มชั้นนำได้แก่ AWS Lambda, Google Cloud Functions และ Azure Functions ผู้ให้บริการคลาวด์จะจัดการการติดตั้งแพตช์ การปรับขนาด และโครงสร้างพื้นฐาน แม้วิธีนี้จะลดภาระด้านการปฏิบัติงาน แต่ก็เปลี่ยนรูปแบบความรับผิดชอบด้านความปลอดภัย กล่าวคือ ผู้ให้บริการรักษาความปลอดภัยของสภาพแวดล้อมขณะทำงาน แต่นักพัฒนาต้องรับผิดชอบแต่เพียงผู้เดียวต่อ โค้ดฟังก์ชัน สิทธิ์ และการกำหนดค่า

พื้นผิวการโจมตีเฉพาะของระบบไร้เซิร์ฟเวอร์

ฟังก์ชันแบบไร้เซิร์ฟเวอร์มีพื้นผิวการโจมตีที่แตกต่างจากแอปพลิเคชันแบบดั้งเดิมอย่างชัดเจน โดยทั่วไปฟังก์ชันจะมี อายุการทำงานสั้น (ตั้งแต่ไม่กี่วินาทีถึงไม่กี่นาที) ทำให้ EDR แบบดั้งเดิมและการเฝ้าติดตามเครือข่ายมีประสิทธิภาพลดลง ฟังก์ชันทำงานแบบ ขับเคลื่อนด้วยเหตุการณ์ ซึ่งหมายความว่าแหล่งข้อมูลเข้าได้หลายประเภท (เหตุการณ์ S3, API Gateway, SNS) สามารถเรียกใช้การทำงานได้ ฟังก์ชันมักทำงานด้วย สิทธิ์ IAM ที่เข้าถึง Resource อื่นบนคลาวด์ได้ และใช้ ส่วนที่ต้องพึ่งพาจากบุคคลที่สาม (แพ็กเกจ npm และ pip) ซึ่งอาจมีโค้ดอันตราย พื้นผิวการโจมตีกำหนดโดยข้อมูลเข้าเหตุการณ์ สิทธิ์ IAM และห่วงโซ่ความน่าเชื่อถือของส่วนที่ต้องพึ่งพา

บทบาท IAM ที่มีสิทธิ์มากเกินไป: ภัยคุกคามอันดับต้น

ช่องโหว่ด้านความปลอดภัยที่พบบ่อยที่สุดของระบบไร้เซิร์ฟเวอร์คือ บทบาท IAM ที่มีสิทธิ์มากเกินไป เมื่อนักพัฒนาต้องการให้ฟังก์ชันเข้าถึงบัคเก็ต S3 เพียงหนึ่งรายการ ก็มักถูกล่อลวงให้กำหนด s3:* (การเข้าถึง S3 อย่างเต็มรูปแบบ) เพื่อหลีกเลี่ยงข้อผิดพลาดด้านสิทธิ์ จากนั้นฟังก์ชันที่ถูกเจาะหรือมีช่องโหว่ซึ่งใช้บทบาทนี้ก็อาจอ่าน เขียน หรือลบบัคเก็ตใด ๆ ในบัญชีได้ การป้องกันคือการใช้ บทบาท IAM ที่มีสิทธิ์เท่าที่จำเป็นน้อยที่สุด อย่างเคร่งครัด โดยแต่ละฟังก์ชันควรมีบทบาทเฉพาะที่มอบเพียงสิทธิ์ขั้นต่ำที่จำเป็นสำหรับงานเฉพาะของฟังก์ชันนั้น เครื่องมืออย่าง AWS IAM Access Analyzer และ Cloudsplaining สามารถระบุบทบาท Lambda ที่มีสิทธิ์มากเกินไปได้โดยอัตโนมัติ

# IAM policy: least privilege for specific Lambda function
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Action': ['s3:GetObject'],
    'Resource': 'arn:aws:s3:::my-specific-bucket/uploads/*'
  }]
}

การโจมตีด้วยการแทรกเหตุการณ์

การแทรกเหตุการณ์ เกิดขึ้นเมื่อโค้ดฟังก์ชันประมวลผลข้อมูลในส่วนข้อมูลเหตุการณ์ที่ผู้โจมตีควบคุมได้อย่างไม่ปลอดภัย เนื่องจากฟังก์ชันแบบไร้เซิร์ฟเวอร์สามารถถูกเรียกใช้จากแหล่งเหตุการณ์ได้มากมาย เช่น ส่วนหัว HTTP พารามิเตอร์คำค้น ระเบียนการเปลี่ยนแปลงฐานข้อมูล เนื้อหาข้อความในคิว และเนื้อหาอีเมล แหล่งข้อมูลเหล่านี้จึงอาจนำส่งข้อมูลอันตรายได้ทั้งหมด ประเภทการแทรกที่พบบ่อย ได้แก่ การแทรก SQL หากฟังก์ชันใช้ข้อมูลเหตุการณ์ในการสอบถามฐานข้อมูล การแทรก NoSQL (ตัวดำเนินการ MongoDB ในข้อมูล JSON) การแทรกคำสั่ง หากนำข้อมูลเหตุการณ์ไปใช้ในคำสั่ง OS และ SSRF (การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์) หากมีการดึงข้อมูลจาก URL ในข้อมูลเหตุการณ์ การตรวจสอบข้อมูลเข้าและคำค้นแบบกำหนดพารามิเตอร์เป็นแนวป้องกันที่สำคัญ

# Vulnerable: event data used directly in shell command
# const filename = event.filename;
# exec('convert ' + filename + ' output.jpg');

# Safe: validate and sanitize input
# const filename = path.basename(event.filename);
# if (!/^[a-z0-9_-]+\.(jpg|png)$/i.test(filename)) throw new Error('Invalid');
# execFile('convert', [filename, 'output.jpg']);

ความเสี่ยงจากส่วนที่ต้องพึ่งพา: แพ็กเกจจากบุคคลที่สาม

ฟังก์ชันแบบไร้เซิร์ฟเวอร์มักต้องพึ่งพาแพ็กเกจจากบุคคลที่สามหลายสิบรายการ ส่วนที่ต้องพึ่งพาเหล่านี้ก่อให้เกิดความเสี่ยงต่อห่วงโซ่อุปทาน แพ็กเกจที่เป็นอันตรายหรือถูกเจาะอาจเรียกใช้โค้ดใด ๆ ภายในสภาพแวดล้อมการทำงานของฟังก์ชัน เข้าถึงตัวแปรสภาพแวดล้อม (ซึ่งมักมีข้อมูลลับ) สร้างการเชื่อมต่อเครือข่ายขาออก และใช้บทบาท IAM ของฟังก์ชันเพื่อเข้าถึง Resource บนคลาวด์ การโจมตีที่มีชื่อเสียง เช่น กรณีแพ็กเกจ npm event-stream ถูกเจาะ (ปี 2018) และ แพ็กเกจที่ตั้งชื่อเลียนแบบ จำนวนมาก แสดงให้เห็นถึงความเสี่ยงนี้ แนวป้องกันประกอบด้วย การตรึงส่วนที่ต้องพึ่งพา การสแกน SCA ใน CI/CD และการลดจำนวนส่วนที่ต้องพึ่งพาให้เหลือน้อยที่สุด

ข้อมูลลับในระบบไร้เซิร์ฟเวอร์: ตัวแปรสภาพแวดล้อม

ฟังก์ชันแบบไร้เซิร์ฟเวอร์มักรับข้อมูลลับผ่าน ตัวแปรสภาพแวดล้อม ที่กำหนดค่าไว้ในคอนโซลคลาวด์ ตัวแปรสภาพแวดล้อมเหล่านี้มองเห็นได้โดยทุกคนที่มีสิทธิ์ IAM เข้าถึงการกำหนดค่า Lambda และโค้ดใด ๆ ที่ทำงานภายในฟังก์ชันก็สามารถเข้าถึงได้ แนวปฏิบัติที่ดี ได้แก่ หลีกเลี่ยงการจัดเก็บข้อมูลลับโดยตรงเป็นตัวแปรสภาพแวดล้อมแบบข้อความธรรมดา แต่ให้จัดเก็บ ARN หรือชื่อข้อมูลลับ แล้วดึงข้อมูลลับขณะทำงานจาก AWS Secrets Manager หรือ Parameter Store เปิดใช้ การเข้ารหัส KMS สำหรับตัวแปรสภาพแวดล้อมของ Lambda ขณะจัดเก็บ และไม่บันทึกตัวแปรสภาพแวดล้อมลงในบันทึกเด็ดขาด (ตัวบันทึกการแก้ไขข้อบกพร่องจำนวนมากจะดัมป์ตัวแปรสภาพแวดล้อมทั้งหมดเมื่อเกิดข้อผิดพลาด)

# Retrieve secret at runtime instead of hardcoding
# Using AWS SDK in Lambda
# const secretsClient = new SecretsManagerClient({});
# const response = await secretsClient.send(
#   new GetSecretValueCommand({ SecretId: 'prod/myapp/db-password' })
# );
# const dbPassword = response.SecretString;

ขีดจำกัดเวลาการทำงานและการทำงานพร้อมกันของฟังก์ชัน

การปฏิเสธการให้บริการต่อฟังก์ชันแบบไร้เซิร์ฟเวอร์อาจอยู่ในรูปแบบการระดมเรียกใช้ กล่าวคือ ผู้โจมตีที่สามารถเรียกใช้ฟังก์ชันซ้ำ ๆ อาจใช้ ขีดจำกัดการทำงานพร้อมกันของบัญชีจนหมด (ค่าเริ่มต้นของ Lambda คือการทำงานพร้อมกัน 1,000 ครั้งต่อภูมิภาค) ส่งผลให้ฟังก์ชันอื่นในบัญชีไม่สามารถทำงานได้ ฟังก์ชันที่ประมวลผลข้อมูลเข้าซึ่งผู้ใช้ควบคุมได้ควรใช้ การจำกัดอัตราที่ระดับ API Gateway ตรวจสอบขนาดข้อมูลให้เป็นไปตามขีดจำกัด และกำหนด ค่าการหมดเวลาที่เหมาะสมเพื่อป้องกันการทำงานที่ยืดเยื้อจนควบคุมไม่ได้ นอกจากนี้ ฟังก์ชันยังอาจตกเป็นเป้าหมายของ การโจมตีขยายข้อมูลรูปแบบ Billion Laughs ในการแยกวิเคราะห์ XML/YAML หากไม่มีการจำกัดขนาดข้อมูลเข้า

# AWS Lambda: set reserved concurrency to prevent account-wide DoS
aws lambda put-function-concurrency \
  --function-name my-api-handler \
  --reserved-concurrent-executions 100

การผสานรวม VPC และการแยกเครือข่าย

โดยค่าเริ่มต้น ฟังก์ชัน AWS Lambda จะทำงานใน VPC ที่ AWS จัดการและมีสิทธิ์เข้าถึงอินเทอร์เน็ต แต่ไม่สามารถเข้าถึง Resource ใน VPC ส่วนตัวของคุณได้ (ฐานข้อมูล RDS, ElastiCache และ API ส่วนตัว) หากต้องการเข้าถึง Resource ส่วนตัว จะต้องกำหนดค่า Lambda ให้ทำงานภายใน VPC ของคุณ โดยระบุซับเน็ตและกลุ่มความปลอดภัย อย่างไรก็ตาม ฟังก์ชัน Lambda ที่เชื่อมต่อกับ VPC จะไม่มีสิทธิ์เข้าถึงอินเทอร์เน็ตตามค่าเริ่มต้น — จำเป็นต้องมี เกตเวย์ NAT สำหรับอินเทอร์เน็ตขาออก กลุ่มความปลอดภัยที่เชื่อมต่อกับฟังก์ชัน Lambda ควรปฏิบัติตามหลักสิทธิ์เท่าที่จำเป็นน้อยที่สุด โดยอนุญาตเฉพาะพอร์ตและปลายทางที่จำเป็น หลีกเลี่ยงการใช้กฎขาออก 0.0.0.0/0 กับกลุ่มความปลอดภัยของฟังก์ชันในสภาพแวดล้อมจริง

การเฝ้าติดตามฟังก์ชันแบบไร้เซิร์ฟเวอร์

การเฝ้าติดตามความปลอดภัยแบบไร้เซิร์ฟเวอร์ต้องใช้แนวทางที่แตกต่างจากการเฝ้าติดตามโฮสต์แบบดั้งเดิม เนื่องจากฟังก์ชันมีอายุสั้น ตัวแทนที่ทำงานบนโฮสต์จึงไม่เหมาะสม การเฝ้าติดตามที่มีประสิทธิภาพใช้ AWS CloudTrail เพื่อบันทึกการเรียก API ของ Lambda ทั้งหมด (การเรียกใช้ การเปลี่ยนแปลงการกำหนดค่า และการสวมบทบาท) ใช้ CloudWatch Logs Insights เพื่อสอบถามบันทึกการทำงานของฟังก์ชันและค้นหารูปแบบผิดปกติ ใช้ Amazon GuardDuty เพื่อตรวจจับภัยคุกคาม รวมถึงกิจกรรมเครือข่ายของ Lambda ที่ผิดปกติ และใช้เครื่องมือรักษาความปลอดภัยแบบไร้เซิร์ฟเวอร์เชิงพาณิชย์ เช่น Protego (ปัจจุบันเป็นส่วนหนึ่งของ Check Point) หรือการเฝ้าติดตามแบบไร้เซิร์ฟเวอร์ของ Datadog ซึ่งติดตั้งการตรวจวัดในฟังก์ชันผ่านเลเยอร์เพื่อให้มองเห็นการทำงานขณะรันไทม์

# Query CloudWatch Logs for Lambda errors and anomalies
aws logs start-query \
  --log-group-name '/aws/lambda/my-function' \
  --start-time $(date -d '-1 hour' +%s) \
  --end-time $(date +%s) \
  --query-string 'fields @timestamp, @message | filter @message like /ERROR|WARN|credential/'

การทดสอบความปลอดภัยแบบไร้เซิร์ฟเวอร์

การทดสอบความปลอดภัยแบบไร้เซิร์ฟเวอร์ต้องใช้เครื่องมือเฉพาะ ได้แก่ PureSec CLI (ปัจจุบันคือ Check Point) และ Prowler ซึ่งสแกนการกำหนดค่าคลาวด์เพื่อหาการกำหนดค่าผิดพลาดของระบบไร้เซิร์ฟเวอร์ เครื่องมือ DAST สามารถทดสอบฟังก์ชันที่ถูกเรียกผ่าน HTTP เพื่อหาช่องโหว่จากการแทรก การวิเคราะห์แบบสถิตของโค้ดฟังก์ชันด้วยเครื่องมืออย่าง Bandit (Python) หรือปลั๊กอินความปลอดภัยของ ESLint ช่วยตรวจจับรูปแบบการเขียนโค้ดที่ไม่ปลอดภัย และควรทดสอบด้วยตนเองโดยระบุแหล่งเหตุการณ์ทั้งหมดที่สามารถเรียกใช้แต่ละฟังก์ชัน แล้วทดสอบแต่ละแหล่งด้วยข้อมูลที่มีรูปแบบผิดและข้อมูลอันตราย OWASP Serverless Top 10 มีรายการตรวจสอบช่องโหว่ที่ครอบคลุมและออกแบบมาเฉพาะสำหรับสถาปัตยกรรมแบบไร้เซิร์ฟเวอร์

# Prowler: check Lambda security posture
prowler aws --service lambda
# Checks: public URL, over-privileged roles, unencrypted env vars,
# outdated runtime, missing VPC config, excessive timeout

ความรับผิดชอบร่วมกันในระบบไร้เซิร์ฟเวอร์

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

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้

สรุปบทเรียน

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

คำถามที่พบบ่อย

บทเรียน “ความปลอดภัยแบบไร้เซิร์ฟเวอร์และความปลอดภัยของฟังก์ชัน” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “ความปลอดภัยแบบไร้เซิร์ฟเวอร์และความปลอดภัยของฟังก์ชัน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “ความปลอดภัยแบบไร้เซิร์ฟเวอร์และความปลอดภัยของฟังก์ชัน”

ระบุพื้นผิวการโจมตีเฉพาะของฟังก์ชันแบบไร้เซิร์ฟเวอร์ (บทบาท IAM ที่มีสิทธิ์เกินจำเป็น การแทรกเหตุการณ์ และความเสี่ยงจากสิ่งที่พึ่งพา) พร้อมใช้การควบคุมสิทธิ์เท่าที่จำเป็นและการตรวจสอบข้อมูลนำเข้า คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “ความปลอดภัยแบบไร้เซิร์ฟเวอร์และความปลอดภัยของฟังก์ชัน” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม

ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

ความปลอดภัยคอนเทนเนอร์: การเสริมความแข็งแกร่งของอิมเมจและการป้องกันขณะทำงาน
ความปลอดภัย Kubernetes: RBAC นโยบายเครือข่าย และความปลอดภัยของพ็อด
ความปลอดภัยแบบไร้เซิร์ฟเวอร์และความปลอดภัยของฟังก์ชัน
การสแกนความปลอดภัยโครงสร้างพื้นฐานในรูปโค้ด

← กลับไปที่ Cloud & IT Cert Prep