This content originally appeared on DEV Community and was authored by DEV Community
เพิ่งเล่นจบเลยอยากมาเขียนไว้เป็นที่ระลึกนิดนึง สนุกและได้ประสบการณ์ + ความรู้หลายๆอย่างดีครับ ถ้ามีอีกแนะนำให้ ลองสมัครมาแข่งกันดู
ข้างล่างนี่ไม่ได้เฉลยอะไรนะคับ แค่ Note ไว้เผื่อจะได้ไปศึกษาเพิ่มเติม และแนะนำให้คนที่ได้มาอ่านลองมาหาประสบการณ์ในรอบหน้าดูนะคับ
Secret Manager & DB Password Rotation
ในกรณีที่มีการเชื่อมต่อกับ Database ปกติถ้าทำงานกันแบบไวๆ หลายๆคนน่าจะเคยไปใส่ Password ไว้ใน Code บ้าง ใน ENV บ้าง แต่ Practice ในกรณีนี้ที่ AWS ให้ลองเล่นคือ ใช้ Secret Manager แล้วก็ใช้ Code ไปอ่านและ decrypt/parse ค่าที่ใช้ในการเชื่อมต่อกับ DB ออกมา
ส่วนการ Rotate DB Password สามารถตั้งได้ใน Secret Manager แล้วใช้ Lambda Function เข้าไปแก้ Password database แล้วบันทึกเข้า Secret Manager อีกที
AWS Inspector + EC2 Image Builder
ส่วนตัวชอบ AWS Inspector ที่มี Managed Rule ที่ช่วยหาว่า EC2 ของเรามี Vulnerabilities อะไรบ้าง ซึ่งโดยมาก ถ้าตัวที่ใช้ Common Vulnerabilities and Exposures-1.1 นี่ส่วนมากจะแก้ได้ด้วยการ update OS
ซึ่งจากข้างบนถ้าเราน่าจะมี 2 ทางเลือกคือ เข้าไป update OS เรื่อยๆ (แล้วพัง 555) หรือสร้าง EC2 Image ที่ Update ไว้เรียบร้อยแล้ว ลงโปรแกรมพร้อม เสร็จด้วย EC2 Image Builder แล้วเอา Image นั้นมาใช้งาน
จริงๆ ข้อนี้น่าจะสนุกขึ้นถ้าต้องตั้งให้เปลี่ยน Instance ใหม่ด้วยแบบอัตโนมัติด้วย แต่กรณีนี้น่าจะไม่ใช่เรื่อง Security เลยตัดทิ้งไป (ทำไงหว่า 555)
Secure Database (RDS Encryption + AWS Config)
เสียคะแนนไปตรงนี้นิสนึง >_< หลักๆเป็นเรื่องของการ Encryption at rest ของฐานข้อมูลที่รันอยู่แล้ว โดยการ Copy Snapshot เพิ่มการ Encrypt แล้ว Restore ขึ้นมาใหม่ ซึ่งตรงนี้เพิ่งสังเกตว่า db.t2 ไม่รองรับ Encryption at rest ด้วย ต้องใช้ db.t3 แทน
ส่วน AWS Config ซึ่งจะคอย detect ให้ว่าเราตั้งค่าอะไรผิดไปรึเปล่า เป็นอีกตัวที่ชอบมากพอๆกับ inspector โดยเราไปกำหนด compliance rule ต่างๆ (เลือกจากที่ aws สร้างไว้ให้แหละ ซะส่วนใหญ่) ซึ่งส่วนมากจากตัวอย่างที่เห็นมักจะเห็นใช้กับ RDS และ EC2 ซะเยอะ ถ้ามีโอกาสน่าจะลอง explore กับ service อื่นๆดู
ในรูปข้างล่างน่าจะเอาไปรวมกับข้อแรกว่าต้องตั้ง Rotation ด้วยเพิ่มความยาก 555
สุดท้ายความรู้ใหม่จริงๆ ที่ AWS ใจดีแถม Diagram มาให้ด้วยคือการใช้ AWS Config ร่วมกับ Cloudwatch Event Rule เพื่อไป Trigger Lambda อีกที ซึ่งเคยรู้ว่าทำได้แต่ไม่เคยได้ลอง Hand-on จริงๆ
ตรงนี้สงสัยว่า การที่ snapshot จะเป็น public ได้มันต้องตั้งยังไง เพราะเหมือนวิธีแก้คือให้ลบออก แต่ Root cause จริงๆน่าจะเป็นการตั้งให้เวลาสร้าง snapshot ของ DB ตัวอย่างแล้วเป็น public อัตโนมัติ (ไปสร้างทิ้งไว้ตั้งนาน -.- จน AWS Config ขึ้นว่า Solve แล้วแล้วกลับมาใหม่เพราะไปสร้างเพิ่มเอง
IAM Access Analyzer (IAM Access Analyzer, S3 Bucket Policy)
ข้อนี้ค่อนข้างตรงไปตรงมา คือใช้ IAM Access Analyzer (ซึ่งยอมรับว่าไม่เคยใช้มาก่อน) ก็จะบอกให้รู้ว่าเรามีการตั้ง permission ตรงไหนอนุญาตให้ Account อื่นสามารถเข้ามาใช้ได้ โดยจากใน Gameday จะมี IAM Role, S3 และ KMS ซึ่งถ้าเราไม่ได้ตั้ง Security ไว้ให้ดีตั้งแต่แรก มีโอกาสที่อาจจะเจอ Developer มักง่ายตั้งค่าใช้ Account ส่วนตัว ไม่ต้อง Switch ไปมาเพื่อเข้ามาจัดการได้ (เมื่อไหร่ AWS จะให้ login multiple account ซะที -.-)
- IAM Role จะมีการตั้งให้ Account อื่นสามารถ AssumeRole ได้ผ่าน Trust Relation
- S3 และ KMS จะเป็น Resource Based Policy ที่อนุญาตให้ Account อื่นเข้ามาใช้หรือจัดการ Resource แต่ละตัวได้
ข้อสงสัยค้างคาใจสำหรับกรณีนี้คือ ถ้า Rule ไหนที่เรา Archived ไปแล้ว เพราะว่า ณ เวลานั้นๆเราตั้งใจอนุญาต แล้วอนาคตไม่อนุญาตแล้วเราก็จะไม่เจอ Finding นั้นๆรึเปล่า
Event-Driven Security (Amazon GuardDuty + Event Bridge + Lambda + NACL)
อันนี้น่าจะเป็นข้อที่น่าสนใจสุด เพราะเน้นการทำ Automate จริงๆจังๆมาก โดยจะคล้ายๆกับ กรณีทำ Automate ของข้อ Secure Database ข้างบน แต่ว่าใช้ Event Bridge เป็นตัวกลางแทน ซึ่งก็ไม่เคยลองทำมาก่อนเหมือนกัน
ข้อสงสัยหลักที่อยู่ตรงนี้คือ NACL เนี่ยมี Soft Limit ที่ 20 ต้องไปขอเพิ่ม แต่จากตัวอย่างใน Gameday แป๊บเดียว Lambda ก็ Error
NetworkAclEntryLimitExceededแล้ว เลยไม่รู้ว่าจริงๆแล้วในกรณีแบบนี้้้จะ Automate ในรูปแบบไหนได้บ้างนอกจากแก้ NACL เนื่องจากถ้าเจอเคสนี้จริงๆ น่าจะต้อง block เป็น CIDR หรือไม่ก็ไปแก้ที่ต้นเหตุด้วยการลบ Instance นั้นหรือ block outbound ให้หมดเพราะน่าจะมี Malware ที่คอยยิง outbound แปลกๆอยู่จากข้างบนพอดีทาง AWS แนะนำมาว่าสามารถเพิ่ม NACL ไปที่ 40 ได้ หรือใช้การ Route Traffic ผ่าน custom NAT Instance แล้ว block ที่ NAT แทน หรือ ไม่ก็ Isolate ตัว Instance ด้วย Security Group ไปเลย
สุดท้ายนี้ขอบคุณทีม AWS Thailand สำหรับกิจกรรมที่ได้ทั้งความสนุก ความรู้ และประสบการณ์ Hand-on หลายๆอย่างด้วยนะคับ ถ้ามีอีกแล้วไม่ติดอะไร น่าจะขอเข้าไปร่วมเล่นด้วยอีก ถ้าใครผ่านมาตรงนี้มีโอกาสแนะนำให้ลองดูนะคับ น่าจะได้เรียนรู้อะไรไม่มากก็น้อย
ปล. จริงๆ สำหรับคนที่ประสบการณ์น้อย ถ้าจบการแข่งแล้วทางทีม AWS มาแนะนำวิธีทำด้วยจะดีมากครับ จะคล้ายๆกับของ JAM ที่ถ้าไม่รู้จริงๆลองกดแล้วทำตามดูด้วย
This content originally appeared on DEV Community and was authored by DEV Community
DEV Community | Sciencx (2021-10-06T11:14:35+00:00) เก็บตก AWS Gameday Security. Retrieved from https://www.scien.cx/2021/10/06/%e0%b9%80%e0%b8%81%e0%b9%87%e0%b8%9a%e0%b8%95%e0%b8%81-aws-gameday-security/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.