この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
■ เริ่มเรื่อง
ทุกวันนี้ เกิดการรั่วไหลของ Access Key แล้วถูกนำไปใช้ในโดยไม่ได้รับอนุญาตอยู่บ่อยครั้งครับ
โดยถ้า Access Key หลุดแล้วมีโอกาสสูงมากที่จะกระทบต่อธุรกิจของท่าน
ทาง Classmethod เองก็เป็นห่วงในเรื่องนี้ จึงเกิดเป็นบทความนี้ขึ้นมาครับ
รบกวนท่านผู้อ่าน อ่านบทความด้านล่างต่อไปนี้แล้วตรวจสอบสภาพแวดล้อมของตนเองด้วยครับ
■ สิ่งที่บทความอยากบอก
- งดเว้นการใช้งาน Access Key เท่าที่จะทำได้ เพื่อลดความเสี่ยงการเกิดค่าใช้จ่ายจำนวนมากที่เกิดจากการหลุดของ Access Key
- กรณีจำเป็นการใช้งาน Access Key จริงๆ ให้กำหนดอำนาจของ IAM User ที่มี Access Key ให้ใช้งานได้แค่ที่จำเป็นเท่านั้น และเปิดการใช้งาน MFA(แนะนำอย่างยิ่ง)
■ กระทบต่อธุรกิจที่อาจเกิดเมื่อ Access Key หลุด
▼【การเรียกเก็บค่าใช้จ่ายจำนวนมาก】
เมื่อ Access Key เกิดการรั่วไหล มีกรณีศึกษาหลายกรณีที่ ถูกนำ Access Key นั้นไปใช้ในการใช้งานในการเปิดการใช้งาน Instanceขนาดใหญ่ ที่ใช้ GPU เยอะมากๆ เพื่อใช้ในการขุด Cryptocurrency(หรือที่รู้จักในชื่อ คริปโต หรือ Bitcoin)
ยกตัวอย่างเช่น การเปิดใช้งาน Instance p3.16xlarge 100 เครื่อง(หรืออาจจะโดนมากกว่านั้น) โดยโดนเข้าไปแค่นี้อาจจะเสียค่าใช้จ่าย $2,400 ต่อ 1 ชั่วโมงเลยทีเดียวครับ
ถ้าถูกโจมตีในตอนกลางคืนแล้วไม่รู้สึกตัว อาจจะโดนเรียกค่าใช้จ่ายมากถึง หมื่นดอลล่า หรือ แสนดอลล่า ได้เลยทีเดียวครับ
โดยในทางกฎหมายแล้ว หน้าที่ที่จะต้องจ่ายค่าใช้จ่ายเป็นความรับผิดชอบของเจ้าของ Account ครับ
▼【การรั่วไหลของข้อมูล】
กรณีที่ Access Key ที่เกิดการรั่วไหลมีอำนาจที่กว้างขาง ข้อมูลที่อยู่ใน AWS environment ของคุณจะถูกผู้แฮคเอาไปได้ครับ
ยกตัวอย่างเช่น
ไฟล์บน S3 ที่สามารถดาวน์โหลดไปได้ง่ายๆ
ข้อมูลใน RDS เองก็สามารถเอาไปง่ายๆ โดยสร้าง Instance ขึ้นมาใหม่จากการ Backup
กรณีที่ข้อมูลถูกขโมยไปได้ จะมีผลกระทบอย่างใหญ่ต่อธุกิจของคุณครับ
และอาจจะเสียค่าใช้จ่ายจำนวนมากเพิ่มเติมจากการตรวจสอบว่าข้อมูลถูกนำไปปล่อยที่ไหนหรือมีส่วนอื่นอีกไหมที่ถูกแฮคครับ
การพิสูจน์ว่า[Account ที่ถูกแฮคปลอดภัยแล้ว]ก็เป็นเรื่องที่ยากมากถึงยากที่สุดครับ
ทางที่ดีคือไม่ปล่อยให้ตกอยู่ในสถาการณ์แบบนี้จะดีที่สุดครับ
▼【การถูกข่มขู่(เรียกค่าไถ่)】
เป็นการข่มขู่เรียนค่าไถ่ที่เรามักจะรู้จักในข้อความที่ว่า [ถ้าอยากได้ข้อมูลกลับไปจงจ่ายมาเป็น Cryptocurrency]ซะ ต่อให้เซิร์ฟเวอร์ไม่มีจุดอ่อน แต่ถ้าได้ Access Key ที่มีอำนาจไป ก็จะสามารถใช้ทำอะไรแบบนี้ได้เหมือนกันครับ
▼【ใช้ก่อเหตุโจมตี】
Account ที่ถูกแฮคโดยใช้ Access Key อาจจะถูกนำไปใช้เปิด EC2 แล้วนำไปโจมตี System ของคนอื่น
ทำให้อาจถูกฟ้องจากฝั่งที่ถูกโจมตีได้ครับ ถ้าเกิดข้อพิพาทจริงอาจจะต้องเสียค่าใช้จ่ายไม่น้อยเลยทีเดียวครับ
และ Account ที่นำไปใช้โจมตีนั้น อาจจะถูกทาง AWS สั่งปิด Account หรือตัดการเชื่อมต่อ Internet ก็สามารถเกิดขึ้นได้ครับ
ถ้าเป็นเช่นนี้ มีโอกาสที่ Account ของคุณจะถูกปิดการใช้งานถาวรครับ
■ Access Key จะใช้ในกรณีไหนดี
Access Key จะใช้สำหรับควบคุม AWS Resource จาก ภายนอก AWS ครับ
ถ้าจะให้ยกตัวอย่างก็คือ การควบคุม AWS ผ่าน Local machine ครับ แต่ถ้าไม่ใช้ Access Key แล้วยังสามารถใช้งานได้ก็แนะนำให้เลิกใช้ครับ
ทางเราแนะนำให้วาง เซิร์ฟเวอร์ที่ใช้ควบคุมไว้ใน Private Subnet จะทำให้ไม่ต้องใช้ Access Key ก็สสามารถใช้งานได้ครับ
แล้วก็แนะนำให้ใช้ AWS CloudShell ด้วยครับ
และเพื่อป้องกันไม่ให้เกิดเรื่อง ก็อย่าลืมเปิดการใช้งาน MFA แล้วกำหนดอำนาจให้ใช้ได้แค่ที่จำเป็นด้วยครับ
ห้ามใส่ Key ในโปรแกรม หรือใน EC2 ที่จะใช้ควบคุม AWS Resource ต่างๆ เด็ดขาด
กรณีใช้ Access Key ที่ Root User ให้ระมัดระวังให้สูงที่สูงหรือถ้าไม่จำเป็นก็ไม่ควรใช้ครับ
■ ควรจะทำอย่างไร
- ให้ปฎิบัติตามบทความต่อไปนี้ครับ Security best practices in IAM - AWS Identity and Access Management
▼ ถ้าเป็นไปได้ก็ไม่ใช้ Access Key
ถ้าไม่มี Access Key ก็ไม่มีทางถูกแฮคจาก Access Key ครับ โดยสามารถดูได้จาก Use case ด้านล่างนี้ครับ
▽【กรณีต้องการควบคุม แอปพลิเคชัน หรือ EC2】
โดยพื้นฐานให้ใช้ IAM Role หรือ อำนาจที่จะมีผลแค่ช่วงนึง ไม่มีเหตุผลที่จะต้องให้ Access Key มีอำนาจใหญ่ๆ
▽【กรณีต้องการควบคุม AWS Account】
ควรจะสร้าง EC2 ที่ใช้สำหรับควบคุมไว้ที่ Private Subnet แล้วใช้งาน CLI ในนั้น ไม่ใช้งาน CLI ที่ Local แล้วก็แนะนำให้ใช้ AWS CloudShell ด้วยครับ
▽【กรณีเมื่อใช้ผลิตภัณฑ์ SaaS ของบริษัทอื่น】
กรณีใช้แค่เพื่อเผ้าดูข้อมูล ก็ไม่ควรมีอำนาจที่นอกจากนั้นเช่นอำนาจในการสร้าง EC2
เราอนุญาตอำนาจสำหรับส่งให้ผลิตภัณฑ์ SaaS ของบริษัทอื่นแค่ที่จำเป็นเท่านั้น
▼ ถ้าจะให้ Access Key ให้กำหนดอำนาจให้ใช้ได้แค่ที่จำเป็น
ไม่ควรเปิดการใช้งาน Access Key ที่มีมากจาก IAM User ที่มีอำนาจมากตามด้านล่างนี้
- AdministratorAccess
- PowerUserAccess
- 〜Admin ที่ต่อท้าย ที่สามารถควบคุมได้ทั้ง Services
- อำนาจที่สามารถกำหนด IAM ได้
การใช้อำนาจพวกนี้ทำให้ง่ายต่อในการใช้งานก็จริง แต่มีความเสี่ยงสูงในสภาพแวดล้อมของ AWS
และไม่ควรมอบอำนาจให้ข้างนอก AWS สามารถสั่งสร้าง EC2 ได้ตลอด ถ้าเป็นไปได้ควรรีบปรับการใช้งานให้เร็วที่สุดครับ
▼ เปิดการใช้งาน git-secrets
มีหลายเคสมาก ที่นำข้อมูลไปเผยแพร่ แล้วเผลอใส่ Access Key ลงไปด้วย
git-secrets คือ bot ที่จะทำการตรวจสอบข้อผิดพลาดใน GitHub ครับ
ถ้าเรา git push Access Key ไป ภายใน 10 กว่านาที ก็จะสามารถตรวจเจอ Access Key ได้
ถ้าเป็นมนุษย์ทำ อาจจะมีความผิดพลาดกันได้ ถ้ามีความจำเป็นต้องใช้ Access Key ละก็ แนะนำให้เปิด git-secrets ครับ
▼ ห้ามนำ Access Key ไปเผยแพร่
ถ้ายิ่งมีคนรู้หลายคน ก็ยิ่งมีโอกาสรั่วสูงมากขึ้น เราจึงแนะนำให้ใช้แค่ของสำหรับตัวเองเท่านั้น
■ วิธีการใช้ AWS CLI S3 จาก EC2 โดยไม่ต้องใช้ Access Key
หากเราต้องการใช้ AWS CLI แล้วยังมีหลายวิธีที่ไม่ต้องใช้ Access Key ก็สามารถเข้าใช้ได้
โดยหนึ่งในนั้นคือบทบความด้านล่าง หากสนใจก็สามารถเข้าไปอ่านได้ครับ
■ เพื่อปกป้องทุกท่าน
ทาง Classmethod มีความต้องการให้ทุกท่านใช้ AWS ได้อย่างปลอดภัยครับ
เพราะฉนั้นเราจึงเผยแพร่ข้อมูลต่างเพื่อ Support ทุกท่าน แต่สุดท้ายแล้วคนที่ตัดสินใจคือทุกท่านเอง
คนที่ปกป้องทุกท่านได้ คือทุกท่านเท่านั้นครับ
โดยเฉพาะในเรื่องอำนาจนั้น เป็นส่วนที่จะทำให้เกิดเหตุการณ์ต่างๆได้ ทางเราจึงคาดหวังให้ทุกท่านทำตาม Best Practice ที่มี
หากมีข้อสงสัยอะไรสามารถติดต่อมาได้ที่
25
