AWS Security เบื้องต้น

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

Rahul Singh

Technical Product Manager

ข้อกำหนดเบื้องต้นของคอร์ส

 

  • ความรู้พื้นฐานด้าน AWS security
  • ความเข้าใจแนวคิด cloud computing
  • แนวคิด AWS Security and Cost Management

 

 

ภาพหน้าปกคอร์ส แนวคิด AWS Security and Cost Management

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

วัตถุประสงค์ของคอร์ส

 

  1. Identity: ใครคือผู้เรียกใช้งาน
  2. Authorization: สิ่งที่พวกเขาเข้าถึงได้
  3. Secrets and encryption: การปกป้องข้อมูล
  4. Evidence: เกิดอะไรขึ้นหลังจากนั้น

แถบตัวเลขสี่แถบเรียงซ้อนกันตามแนวตั้ง แต่ละแถบแทนหัวข้อหนึ่งที่คอร์สนี้ครอบคลุม แถบที่หนึ่ง Identity ระบุเป็นบทที่ 1 แถบที่สอง Authorization ระบุเป็นบทที่ 2 แถบที่สาม Secrets and encryption ระบุเป็นบทที่ 2 และ 3 แถบที่สี่ Evidence ระบุเป็นบทที่ 3 ลูกศรสีส้มทางด้านซ้าย มีป้ายกำกับว่า "วิดีโอนี้" ชี้ไปที่แถบแรก

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

โค้ดของคุณถูกส่งผ่าน pipeline

ลำดับขั้นตอนจากซ้ายไปขวา ขั้นที่หนึ่ง กล่องที่มีป้ายกำกับว่า Your pipeline ประกอบด้วยสามขั้นตอนตามลำดับ ได้แก่ Build, Test, Deploy ขั้นที่สอง ลูกศรที่มีป้ายกำกับว่า git push วิ่งเข้าสู่กล่องนั้นจากกล่องที่มีป้ายกำกับว่า You ขั้นที่สาม ป้ายสีส้มที่ห้อยอยู่ใต้ pipeline มีป้ายกำกับว่า "ตัวตนของตัวเอง" ลูกศรต่อเนื่องจาก pipeline ไปยังกล่องที่มีป้ายกำกับว่า AWS

ก่อนอื่น มาทำความเข้าใจคำศัพท์กันก่อน

  • pipeline คือระบบอัตโนมัติที่ build, test และ deploy โค้ดของคุณ
  • ทำงานเมื่อมีการ push โดยไม่ต้องมีคนเข้ามาเกี่ยวข้อง
การใช้ AWS Security สำหรับนักพัฒนา

Deploy ที่ล้มเหลวด้วยเหตุผลที่ผิด

เมื่อโค้ดเปลี่ยนแปลง สิทธิ์ของใครที่ถูกตรวจสอบจริง ๆ
  1. คุณ push การเปลี่ยนแปลง

ขั้นที่หนึ่งของลำดับขั้นตอนแนวตั้ง กล่องที่มีป้ายกำกับว่า You กำลัง push การเปลี่ยนแปลงโค้ด

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

Deploy ที่ล้มเหลวด้วยเหตุผลที่ผิด

เมื่อโค้ดเปลี่ยนแปลง สิทธิ์ของใครที่ถูกตรวจสอบจริง ๆ
  1. คุณ push การเปลี่ยนแปลง

  2. pipeline ของคุณทำงาน

ลำดับขั้นตอนแนวตั้ง ขั้นที่หนึ่ง You กำลัง push การเปลี่ยนแปลงโค้ด ลูกศรนำไปสู่ขั้นที่สอง pipeline ของคุณซึ่งรันการ deploy

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

Deploy ที่ล้มเหลวด้วยเหตุผลที่ผิด

เมื่อโค้ดเปลี่ยนแปลง สิทธิ์ของใครที่ถูกตรวจสอบจริง ๆ
  1. คุณ push การเปลี่ยนแปลง

  2. pipeline ของคุณทำงาน

  3. การ deploy หยุดลง: AccessDenied

ปฏิกิริยาแรก: "ลองตรวจสอบสิทธิ์ของตัวเองดูก่อน"

ลำดับขั้นตอนแนวตั้ง ขั้นที่หนึ่ง You กำลัง push การเปลี่ยนแปลงโค้ด ขั้นที่สอง pipeline ของคุณรันการ deploy ขั้นที่สาม AWS ประเมินคำขอและส่งคืน AccessDenied

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

สิ่งที่เกิดขึ้นจริง

ขั้นที่หนึ่งของลำดับขั้นตอนจากซ้ายไปขวา กล่องที่มีป้ายกำกับว่า You ซึ่งบทบาทของคุณสิ้นสุดที่นี่

  1. คุณ push บทบาทของคุณสิ้นสุดที่นี่
การใช้ AWS Security สำหรับนักพัฒนา

สิ่งที่เกิดขึ้นจริง

ลำดับขั้นตอนจากซ้ายไปขวา กล่องที่มีป้ายกำกับว่า You มีลูกศรชี้ไปยังกล่องที่มีป้ายกำกับว่า Your pipeline มีป้ายชื่อ deploy-role ห้อยอยู่ใต้ pipeline

  1. คุณ push บทบาทของคุณสิ้นสุดที่นี่
  2. pipeline ทำการ deploy โดยทำงานในฐานะ role ที่ทีมของคุณสร้างขึ้น
การใช้ AWS Security สำหรับนักพัฒนา

สิ่งที่เกิดขึ้นจริง

ลำดับขั้นตอนจากซ้ายไปขวา จาก You ไปยัง Your pipeline แล้วไปยัง AWS มีป้ายชื่อ deploy-role ห้อยอยู่ใต้ pipeline และมีลูกศรเส้นประที่มีป้ายกำกับว่า checks วิ่งจาก AWS กลับไปยังป้ายนั้น แทนที่จะกลับไปยัง You

  1. คุณ push บทบาทของคุณสิ้นสุดที่นี่
  2. pipeline ทำการ deploy โดยทำงานในฐานะ role ที่ทีมของคุณสร้างขึ้น
  3. AWS ประเมิน role นั้น
การใช้ AWS Security สำหรับนักพัฒนา

Actor และ Principal

Actor

คือผู้ที่เริ่มต้นงานนั้น

ในที่นี้คือ: คุณ

ไอคอนรูปคนแทน actor ผู้เริ่มต้นงาน

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

Actor และ Principal

Actor

คือผู้ที่เริ่มต้นงานนั้น

ในที่นี้คือ: คุณ

Principal

คือตัวตนที่ AWS ใช้ประเมินเมื่อคำขอมาถึง

ในที่นี้คือ: role ของ pipeline

ไอคอนรูปคนแทน actor ผู้เริ่มต้นงาน

ไอคอนแทน principal

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

Actor และ Principal

Actor

คือผู้ที่เริ่มต้นงานนั้น

ในที่นี้คือ: คุณ

Principal

คือตัวตนที่ AWS ใช้ประเมินเมื่อคำขอมาถึง

ในที่นี้คือ: role ของ pipeline

  • Lambda: execution role ECS: task role ชื่อต่างกันแต่เป็น principal เดียวกัน
  • ข้อยกเว้น: key ที่ใช้งานระยะยาวใน terminal ของคุณ ทำให้ IAM user เป็น principal

ไอคอนรูปคนแทน actor ผู้เริ่มต้นงาน

ไอคอนแสดง AWS กำลังตรวจสอบ principal แทนที่จะเป็น actor

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

Deploy เดียวกัน สอง role

Role A (ลักษณะของ AdministratorAccess)

  • อ่าน bucket ทุกตัว
  • ใช้ key ทุกตัว
  • อัปเดต function ทุกตัว

Role B

  • อ่าน bucket เดียว
  • ใช้ key เดียว
  • อัปเดต function เดียว

Prefix: เส้นทางคล้ายโฟลเดอร์ภายใน bucket

ภาพแสดง role ที่เข้าถึงได้ทุกอย่าง มีสิทธิ์เข้าถึง policy ทั้งหมด 6 รายการ

ภาพแสดง role ที่เข้าถึงได้อย่างจำกัด มีสิทธิ์เข้าถึงเพียง policy เดียว

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

รัศมีความเสียหาย

Role ขอบเขตกว้าง

หากถูกบุกรุก: เข้าถึงได้ทุก bucket, prefix และ object ในบัญชี

Role ขอบเขตแคบ

หากถูกบุกรุก: เข้าถึงได้เพียง prefix เดียวใน bucket เดียว ไม่มีมากไปกว่านั้น

วงแหวนซ้อนกันแสดง role ขอบเขตกว้างที่เข้าถึงได้ทุกส่วนของบัญชีทั้งหมด

วงแหวนซ้อนกันแสดงว่า role ขอบเขตแคบเข้าถึงได้เฉพาะวงในสุดของ object และ prefix เท่านั้น ส่วนอื่นไม่ถูกแตะต้อง

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

Least Privilege ในทางปฏิบัติ

role ควรทำเท่าที่งานต้องการ และน้อยกว่านั้นเพียงเล็กน้อย

  • AWS managed อย่าง AmazonS3ReadOnlyAccess: ครอบคลุมทุก bucket ส่วน customer managed: เป็นของคุณเอง จำกัดลงไปถึงระดับ prefix เดียว
  • กำหนดขอบเขตการเข้าถึงและอายุการใช้งาน: ใช้ credential ระยะสั้นแทน key ระยะยาว
  • AWS ดูแลความปลอดภัยของโครงสร้างพื้นฐาน
  • ขอบเขตความกว้างของ role เป็นการตัดสินใจของคุณ และอยู่ใน repository ของคุณ

ตัวอย่าง: role สำหรับอ่าน reports-bucket อนุญาตสองรายการ ไม่มีสิ่งอื่นที่ได้รับอนุญาต

  • ไม่มีสิทธิ์ใด ๆ บน IAM ซึ่งเป็นบริการที่กำหนดว่าใครทำอะไรได้บ้าง

รายการสิทธิ์ของ role โดยมีสิทธิ์ส่วนเกินสามรายการถูกขีดฆ่าด้วยสีแดง และสิทธิ์ที่จำเป็นสองรายการคงไว้เป็นสีเขียว

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

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

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

Preparing Video For Download...