PlAwAnSaI
Administrator
- An Antivirus Security Profile specifies Actions and WildFire Actions. WildFire Actions enable to configure the firewall to perform Block traffic when a WildFire virus signature is detected operation.
- An Interface Management Profile can be attached to Layer 3 and Loopback interface types.
- App-ID running on a firewall identifies applications using Program heuristics, Application signature, and Known protocol decoders methods.
สุดท้าย เป้าหมายของมาตรฐาน Cloud Security ไม่ได้มีเพียงการป้องกัน Hacker แต่เป็นการทำให้หน่วยงานรู้ว่าข้อมูลและระบบสำคัญของตัวเองอยู่ที่ไหน ใครสามารถเข้าถึงได้ ใครเป็นผู้รับผิดชอบ และหากเกิดเหตุผิดปกติจะรับมืออย่างไร รวมถึงต้องคำนึงถึงเรื่อง Data Sovereignty หรืออธิปไตยของข้อมูลด้วย โดยเฉพาะข้อมูลสำคัญของภาครัฐหรือหน่วยงานที่มีความสำคัญต่อประเทศ หากนำไปประมวลผลบน Cloud ในต่างประเทศ ก็ต้องพิจารณาว่าข้อมูลดังกล่าวอยู่ภายใต้กฎหมายและอำนาจศาลของประเทศใด และประเทศไทยยังสามารถกำกับดูแลข้อมูลเหล่านั้นได้มากน้อยเพียงใด นี่จึงเป็นเหตุผลว่าทำไมมาตรฐาน Cloud ของไทยจึงมีข้อกำหนดบางอย่างที่ละเอียดและเฉพาะเจาะจงกว่าการนำมาตรฐานสากลมาใช้ตรง ๆ
ในการทำงานด้าน Information Security สิ่งสำคัญอย่างนึงคือการรู้ว่าทรัพย์สินขององค์กรมีอะไรอยู่บ้าง โดยทะเบียนทรัพย์สินที่จัดเก็บไว้ในระบบงานเรียกว่า CMDB (Configuration Management Database) เช่นอยู่ที่ CMDB.Organizat.COM เมื่อองค์กรประเมินความเสี่ยง หากพบความเสี่ยงในระดับ สีส้ม และสีแดง จะต้องมีมาตรการควบคุมเพิ่มเติมเพื่อจัดการความเสี่ยงนั้น ไม่ควรปล่อยไว้โดยไม่มี Action ใด ๆ ส่วนตัวอย่าง Security Agent ที่กำหนดให้ติดตั้งบนทุก Server ได้แก่ CrowdStrike, Splunk และ Qualys ซึ่งแต่ละตัวมีบทบาทในการช่วยดูแลและตรวจสอบด้านความปลอดภัยของระบบ นอกจากนี้ SOC SLA กำหนดให้เหตุการณ์ระดับ Critical ควรได้รับการแจ้งเตือนภายใน 30 นาที และระดับ High ภายใน 60 นาที ขณะที่ KPI สำหรับการปิด หรือแก้ไขเหตุการณ์ กำหนด Critical ภายใน 24 ชั่วโมง และ High ภายใน 48 ชั่วโมง
ในส่วนของการจัดการช่องโหว่ Qualys VMDR จะให้ความสำคัญกับช่องโหว่ที่มี Severity ระดับ 4–5 และ QID ระดับ 70–100 ซึ่งเป็นช่วงที่ต้องนำมาจัดการตามเกณฑ์ที่กำหนด สำหรับการตั้งค่าความปลอดภัย หรือ Hardening มาตรฐานที่ใช้อ้างอิงคือ CIS (Center for Internet Security) ส่วนมาตรฐานด้านการจัดการความมั่นคงปลอดภัยสารสนเทศที่องค์กรควรได้รับการรับรองคือ ISO/IEC 27001 สำหรับองค์กรที่ทำหน้าที่ตรวจประเมิน และรับรอง ISO เช่น BSI (British Standards Institution) ดังนั้นภาพรวมของเรื่อง Security จึงไม่ได้มีแค่การติดตั้งเครื่องมือ แต่ยังครอบคลุมตั้งแต่การจัดการทรัพย์สิน การประเมินความเสี่ยง การจัดการช่องโหว่ ไปจนถึงมาตรฐาน และการตรวจรับรองด้วย
การมี Load Balancer ไม่ได้หมายความว่าระบบจะมี High Availability เสมอไป หากด้านหลังมี Container เพียง Replica เดียว เมื่อ Container ตัวนั้นล่ม ก็จะไม่มี Target ตัวอื่นรับ Traffic ต่อ ทำให้เกิด Single Point of Failure ได้ ดังนั้นการเพิ่มจำนวน Replica จึงเป็นเรื่องสำคัญ แต่การเพิ่ม Replica อย่างเดียวก็ยังไม่เพียงพอ หาก Application เก็บ Session ไว้ใน Memory ของ Container แต่ละตัว เพราะเมื่อ Request ของ User ถูกส่งไปยัง Replica คนละตัว User อาจถูก Logout หรือเห็นข้อมูลอย่าง Cart ไม่ตรงกันได้ สำหรับระบบ Worker ที่ทำงานกับ Queue การดู CPU เพียงอย่างเดียวก็อาจทำให้ตัดสินใจผิดได้ เพราะ Worker อาจใช้ CPU เพียง 70% แต่ Queue ยังเพิ่มขึ้นเรื่อย ๆ Metric ที่เหมาะกว่าคือ Queue Depth ต่อ Worker หรืออายุของงานที่เก่าที่สุด เพราะสะท้อนโดยตรงว่างานกำลังสะสม และ Worker ไม่เพียงพอหรือไม่
การทำ Cost Optimization ที่ดีไม่ได้ดูเพียงว่า Resource ใช้ CPU หรือ Memory เท่าไหร่ แต่ต้องสามารถตอบได้ว่า ใครเป็นเจ้าของ Resource ใช้ทำอะไร และควร Review เมื่อไหร่ หรือก็คือ Owner, Purpose และ Review Date หากเป็น Development Environment ที่ใช้งานเฉพาะวันจันทร์ถึงศุกร์ เวลาทำงาน การเปิด Resource ทิ้งไว้ตลอดเวลาย่อมไม่เหมาะกับลักษณะการใช้งานแบบ Consumption Model แนวทางที่เหมาะกว่าคือการตั้ง Start/Stop Schedule และกำหนด Expiry เพื่อให้ Resource ทำงานเฉพาะช่วงที่จำเป็น นอกจากนี้การติด Tag ว่าใครเป็น Owner ก็ยังไม่ถือว่าสมบูรณ์ หากคนที่ระบุไว้ย้าย Team ไปแล้ว เพราะ Ownership ควรเชื่อมโยงกับ Registry ที่มีการ Update และมีผู้รับผิดชอบดูแลอย่างต่อเนื่อง ไม่ใช่อาศัย Tag เพียงอย่างเดียว
สำหรับการเข้าถึง Cloud ไม่ควรใช้ IAM User ที่มี Static Access Key เป็นวิธีหลักในการใช้งานประจำ เพราะหาก Key หลุดออกไป ผู้ที่ได้ Key สามารถนำไปใช้งานต่อได้ แนวทางที่เหมาะสมกว่าคือการใช้ Central Identity ร่วมกับ MFA และ Short-lived Session เพื่อให้ Credential มีอายุจำกัดและควบคุมได้ดีขึ้น ในกรณีที่ต้องตรวจสอบว่าใครเป็นคนอ่าน Object จาก S3 Bucket หลักฐานที่เหมาะสมคือ CloudTrail S3 Data Events หรือ S3 Server Access Logging เพราะสามารถบันทึกการทำงานระดับ Object ได้ ขณะที่ CloudTrail Management Events เพียงอย่างเดียวไม่เพียงพอสำหรับการตอบคำถามว่าใครอ่าน Object ใด ส่วนการ Encrypt ข้อมูลแบบ At Rest ก็ไม่ได้หมายความว่าข้อมูลจะปลอดภัยจากทุกกรณี หาก Key หรือ Identity ที่มี Permission ถูกต้อง หลุดออกไป ผู้ที่มีสิทธิ์นั้นยังสามารถอ่านข้อมูลผ่านระบบได้ ดังนั้นการเข้ารหัสต้องทำควบคู่กับการควบคุม Permission และ Identity ที่เหมาะสม
เมื่อพบว่า Credential หลุดและถูกนำไปใช้สร้าง Resource ที่น่าสงสัย สิ่งสำคัญคืออย่ารีบลบทุกอย่างทันที เพราะการลบ Resource หรือ State บางอย่างอาจทำให้ Evidence ที่จำเป็นต่อการตรวจสอบหายไป แนวทางที่เหมาะสมคือ Contain ก่อน โดยจำกัด Resource หรือ Session และเก็บ Evidence สำคัญไว้ก่อน แล้วจึงดำเนินการตามขั้นตอน Incident Response ต่อไป แนวคิดสำคัญคือการควบคุมความเสียหายต้องทำอย่างรวดเร็ว แต่ต้องทำโดยไม่ทำลายหลักฐานที่จำเป็นต่อการวิเคราะห์เหตุการณ์ เพราะการ Rotate Key อย่างเดียวแล้วปิด Incident ทันทีอาจยังไม่เพียงพอ และการ Terminate ทุก Resource ทันทีอาจทำให้ไม่สามารถตรวจสอบได้ว่า Attacker ทำอะไรไปแล้วบ้าง ดังนั้น Incident Response ที่ดีจึงต้องสร้างสมดุลระหว่าง Containment กับ Evidence Preservation
หัวใจสำคัญของ Infrastructure as Code หรือ IaC คือการทำให้ Infrastructure สามารถจัดการด้วย Code ได้อย่างเป็นระบบ ตัวอย่างเช่น หากเรา Run Script เพื่อสร้าง S3 Bucket ซ้ำกี่ครั้งก็ควรได้ End State เดิม ไม่ใช่เกิด Bucket ใหม่ทุกครั้ง แนวคิดนี้เรียกว่า Idempotency ส่วนการบอกว่า IaC ทำให้ผู้เขียนไม่จำเป็นต้องเข้าใจ Infrastructure นั้นเป็นความเข้าใจที่ผิด เพราะ Provider หรือ Tool เป็นเพียงตัวกลาง ผู้ที่เขียน IaC ยังต้องเข้าใจ Infrastructure ที่กำลังจัดการอยู่ด้วย หาก Script ระบุขั้นตอนชัดเจนว่า “สร้าง A ก่อน แล้วจึงสร้าง B” จะเป็นแนวคิดแบบ Imperative เพราะเน้นการบอกว่าต้องทำอะไร และทำตามลำดับ ขณะที่ Immutable Infrastructure หมายถึงการไม่แก้ไข Resource เดิม แต่สร้าง Resource ใหม่ขึ้นมาแทน เช่น การสร้าง AMI ใหม่แทนของเดิมเมื่อมีการเปลี่ยนแปลง
IaC ไม่ได้จำกัดอยู่เฉพาะ Cloud เพราะสามารถนำไปใช้กับ On-premise ได้เช่นกัน ตัวอย่างเช่น Ansible, Puppet และ Chef สามารถใช้จัดการระบบ On-premise ได้ และ Terraform เองก็มี Provider สำหรับ Platform ที่ไม่ได้จำกัดอยู่เฉพาะ Cloud เช่นเดียวกัน นอกจากนี้การ Apply IaC ก็ไม่ได้จำเป็นต้องทำผ่าน Ansible Tower หรือ Terraform Cloud เท่านั้น เพราะสามารถทำผ่าน Local ได้ โดย Platform เหล่านั้นเป็นเพียงทางเลือกที่ช่วยเพิ่มความสะดวก การจัดการ Permission และ Audit Trail สำหรับ Terraform สิ่งหนึ่งที่ควรจำคือ Data Block ไม่ได้สร้าง Resource ใหม่ แต่ใช้สำหรับอ่านข้อมูลของ Resource ที่มีอยู่แล้ว ส่วนการตั้งชื่อ Resource ก็ควรตั้งให้สื่อความหมาย เช่น ชื่อ S3 Bucket ที่ระบุ Environment+Team Application และ Purpose จะช่วยให้คนที่มาเห็นภายหลังเข้าใจได้ง่ายกว่าชื่อทั่วไปที่ไม่บอกบริบท
Terraform สามารถตรวจจับ Implicit Dependency ได้โดยอัตโนมัติจากการที่ Resource หนึ่งอ้างอิง Attribute ของอีก Resource ดังนั้นเราไม่จำเป็นต้องเขียนความสัมพันธ์ด้วยตัวเองทุกครั้ง หาก Terraform มองเห็นความสัมพันธ์จาก Configuration ก็สามารถจัดลำดับการสร้าง Resource ให้เหมาะสมได้ อีกเรื่องที่สำคัญมากคือ ห้ามเขียน Secret ลงใน Infrastructure Code แล้วหวังว่า Terraform หรือระบบจะซ่อนให้เอง แม้ Repository จะเป็น Private หรือใส่ File ไว้ใน .gitignore ก็ไม่ได้ทำให้ Secret ปลอดภัยโดยอัตโนมัติ แนวทางที่เหมาะสมคือแยก Secret ออกจาก Code และเก็บไว้ในระบบจัดการ Secret ที่เหมาะสม สำหรับ Ansible เองก็มีแนวคิดคล้ายกัน โดย Ansible เป็นเครื่องมือแบบ Agentless ไม่จำเป็นต้องติดตั้ง Agent บนเครื่องปลายทาง Linux สามารถใช้ SSH ส่วน Windows ใช้ WinRM ในการเชื่อมต่อกับ Managed Node ได้
Last edited: