รู้จักกับ Azure Savings Plan

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมขอนำเสนอเรื่องราวของ Pricing Model ใหม่ของ Microsoft Azure ซึ่งจะมีผลกับ Azure Compute Services ต่างๆ  เช่น Azure Virtual Machine (Azure VM) ครับ โดย Pricing Model ใหม่ที่ว่านี้มีชื่อว่า "Azure Savings Plan" ครับ และที่มาที่ไปของบทความนี้สืบเนื่องมาจากมีลูกค้าสอบถามมาว่า Azure Savings Plan กับ Azure Reservations (หรือ Azure Reserved Instances) ต่างกันอย่างไร? ครับ

โดยผมขออนุญาตยกตัวอย่างประกอบในการอธิบายเรื่องของ Azure Savings Plan รวมถึง Azure Reserved Instances (Azure RIs) ครับ เริ่มจากผมมีความต้องการที่อยากจะสร้างและทำการ Deploy Azure VM ซัก 1 VM ซึ่งแน่นอนว่าผมจะต้องเริ่มจากการวางแผนและทำการประเมินหลายปัจจัยก่อน ปัจจัยหนึ่งที่จะต้องนำมาพิจารณา คือ ค่าใช้จ่ายของ Azure VM ซึ่งจะอยู่ที่เท่าไรนั้น ก็ขึ้นอยู่กับ 2 ส่วนหลัก คือ Compute (Series & Sizes) และ Storages (Disks) ครับ เพราะฉะนั้นนี่คือ ค่าใช้จ่ายที่เราจะต้องจ่ายสำหรับ Azure VM ดังกล่าวนี้โดยเราสามารถทำการประเมินค่าใช้จ่ายได้ก่อนที่จะทำการ Deploy ซึ่งการประเมินโดยส่วนใหญ่ก็จะประเมินค่าใช้จ่ายเป็นรายเดือนครับ จากตัวอย่างดังกล่าวนี้ สมมติว่า Azure VM ที่ผมอยากจะสร้างและใช้งานค่าใช้จ่ายหรือราคาอยู่ที่ 100 บาท/เดือน ซึ่งเราจะเรียกโดยรวมสำหรับค่าใช้จ่ายของ Azure VM ที่ผมยกตัวอย่างขึ้นมานี้ว่าอยู่ในรูปแบบที่เรียกว่า "Pay as You Go" หรือใช้เท่าไรก็จ่ายเท่านั้นครับ 

อีกปัจจัยหนึ่งที่จะต้องนำมาพิจารณาในขณะที่ทำการวางแผน คือ เรื่องของ Optimize เรื่องของค่าใช้จ่าย หรือพูดง่ายๆ ก็คือ จะทำอย่างไรให้ค่าใช้จ่ายของ Services (จากตัวอย่างนี้คือ Azure VM) ใน Microsoft Azure นั้นมีค่าใช้จ่ายที่ลดหรือถูกลง ในกรณีของตัวอย่างนี้การที่จะทำการ Optimize หรือหาวิธีการที่จะทำอย่างไรให้ค่าใช้จ่ายของ Azure VM นั้นถูกลง โดยปรกติสามารถทำได้อยู่แล้วครับ ทางเลือกหนึ่งที่จะนำมาพิจารณาใช้คือ "Azure Reserved Instances" หรือ Azure RIs ครับ โดยคอนเซปของ Azure RIs คือ การที่เราพิจารณาซื้อสัญญาการใช้งาน Azure Compute Services ล่วงหน้า โดยมีระยะเวลาให้เลือก เช่น 1 หรือ 3 ปีครับ ซึ่งจะทำให้ค่าใช้จ่ายของ Azure Compute Services ดังกล่าวนั้นถูกลง จะถูกมากหรือน้อยแค่ไหนขึ้นอยู่กับหลายส่วนครับ เช่น Azure VM Series & Sizes เป็นต้นครับ และช่วงที่ผ่านมาตัวผมเองก็จะแนะนำให้ลูกค้าใช้ทางเลือกนี้ครับ แต่ในช่วงเวลาที่ผ่านมาทาง Microsoft ได้เพิ่ม Pricing Model ใหม่สำหรับ Azure Compute Services ครับ นั่นก็คือ "Azure Savings Plan" นั่นเองตามที่ผมได้เกริ่นไว้ตอนต้นของบทความครับ

Azure Savings Plan คืออะไร?

คือ Pricing Model ใหม่สำหรับ Azure Compute Services เช่น

- Azure Virtual Machine

- Azure App Service

- Azure Functions

- Azure Container Instances

- Azure Dedicated Host

- อื่นๆ

โดยเราสามารถ Commit ว่าจะใช้ Azure Compute Services จากที่อธิบายไว้ข้างต้น เป็นเวลากี่ชั่วโมง ยกตัวอย่างเช่น ผมอยากจะใช้ซัก 10 ชั่วโมงต่อปี เป็นต้นครับ ค่าใช้จ่ายโดยรวมก็จะถูกกว่าแบบปรกติ (Pay as You Go) ครับ 

ผมเชื่อว่ามาถึงตรงนี้ ท่านผู้อ่านหลายๆ ท่านคงมีคำถามแน่ๆ เลย คือ  Azure Savings Plan แตกต่างจาก Azure RIs อย่างไร?  อธิบายแบบนี้ครับ สำหรับ Azure Reserved Instances (Azure RIs) นั้นคือ การที่เรากำหนดระยะเวลาในการใช้งาน Azure Compute Services ใดโดยเราจะต้องระบุเลยว่าจะใช้ Azure Compute Services ใด เช่น Azure VM จากตัวอย่างที่ผมได้อธิบายข้างต้นไว้นั่นคือคอนเซปของ Azure RIs ครับ ตามด้วยระยะเวลา เช่น 1 หรือ 3 ปีครับ ดังนั้นสรุปได้ว่าการใช้ Azure RIs นั้น จะต้องระบุการใช้งาน Azure Compute Services และ Regions ครับ ในขณะที่ Azure Saving Plans เราไม่ต้องระบุการใช้งาน Azure Compute Services ว่าจะใช้ Service ใด ขอให้อยู่ใน List ของ Azure Savings Plan, ไม่ต้องระบุหรือกำหนด Regions เป็นแบบ Global เลยครับ นั่นหมายความเราสามารถทำการ Deploy และใช้งาน Azure Compute Services ใดก็ได้ (อยู่ใน List ที่ Azure Saving Plan รองรับ) จะอยู่ใน Regions ใดก็ได้ โดยทำการ Commit จำนวนชั่วโมงของ Azure Compute Services เหล่านั้นหรือที่เรียกว่า "On-Demand Compute Usage" ครับ โดยตัวของ Azure Savings Plan มี Savings Plan Recommendations ช่วยเราในวิเคราะห์การใช้งานที่ผ่านมา, ค่าใช้จ่าย, และอื่นๆ เพื่อช่วยเราในการพิจารณาครับ นอกจากนี้แล้วใน Azure Savings Plan ยังมีความยืดหยุ่นให้เราใช้งาน โดยสามารถกำหนด Scope ในการใช้งาน (Savings Plan Scope) ได้อีกด้วย เช่น Shared Scope, Single Subscription Scope, Management Group Scope, และ Single Resource Group Scope ครับ

และผมขอสรุปแบบนี้นะครับว่า เราจะพิจารณาใช้ Azure Reserved Instances (Azure RIs) สำหรับ Workloads เช่น Azure VMs ที่ต้องให้บริการอย่างต่อเนื่อง (Critical Workloads) และไม่ต้องการเปลี่ยนแปลงใดๆ เช่น Series, Regions, เป็นต้น ถ้าเข้าข่ายลักษณะดังกล่าวนี้แนะนำว่าให้พิจารณาใช้ Azure RIs ครับ แต่ถ้า Workloads มีลักษณะการทำงานเป็นแบบ Dynamic เช่น มีการเปลี่ยนแปลง Sizes, Regions, เป็นต้นอยู่บ่อยๆ หรือเป็นระยะๆ แนะนำว่าควรพิจารณา Azure Savings Plan ครับ

Azure Savings Plan ยังมีรายละเอียดมากกว่านี้นะครับ ข้อมูลหรือรายละเอียดเพิ่มเติมเกี่ยวกับ Azure Savings Plan สามารถไปที่ Link นี้ได้เลยครับ, Azure Savings Plan for Compute | Microsoft Azure

สิ่งที่อยากจะเน้นย้ำคือ การทำความเข้าใจคอนเซปตลอดจนการวางแผนและออกแบบยังคงเป็นสิ่งที่มีความสำคัญมากนะครับ และเป็นเรื่องที่จะต้องทำก่อนที่จะเลือกและติดตั้งใช้งาน Azure Services ใดๆ ก็ตามครับ และทั้งหมดนี้คือเรื่องราวของ Azure Savings Plan ครับผม.....

ทำความรู้จักกับ Azure Monitor Agent (AMA)

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมอยากจะนำเสนอเรื่องราวของการ Monitoring โดยใช้ Services ที่อยู่ใน Microsoft Azure ครับ โดยการ Monitoring ที่ว่านี้ยังรวมถึง Security Operations ด้วยครับ เพราะเนื่องจากมันมีความเกี่ยวข้องกันอยู่ครับ ขออนุญาตยกตัวอย่าง เช่น ถ้าผมมีความต้องการที่อยากจะทำการตรวจสอบ (Monitor) ดูเรื่องของ Performance และ Availability กับ Workloads ต่างๆ  (Azure Virtual Machines, Azure Storage Accounts, และอื่นๆ) ที่ผมใช้งานอยู่ว่าเป็นอย่างไร? ใน Microsoft Azure มี Services ใดที่สามารถจัดการเรื่องนี้ได้มั๊ย คำตอบ คือ ใน Microsoft Azure จะมี Service หนึ่งที่ชื่อว่า "Azure Monitor" ที่จะเข้ามาช่วยจัดการเรื่องดังกล่าวที่ผมยกตัวอย่างนี้ได้ครับ

หรือในกรณีของตัวอย่างต่อมา ถ้าผมต้องการอยากจะทำการตรวจสอบว่า IT Environments (Hybrid และ Multi-Cloud) โดยมี Workloads เช่น Virtual Machines ตัวใดที่มีช่องโหว่หรือมีความเสี่ยงหรือไม่ คำตอบ คือ สามารถใช้ "Microsoft Defender for Cloud" ซึ่งเป็นอีกหนึ่ง Service ที่อยู่ใน Microsoft Azure เข้ามาช่วยจัดการกับตัวอย่างนี้ได้ครับ และจากนี้ผมได้ยกตัวอย่างมานี้ มันเป็นเพียงแค่ส่วนหนึ่งเท่านั้นสำหรับเรื่องราวที่เกี่ยวข้องกับการ Monitoring รวมถึงการทำ Security Operations ครับ

แต่ประเด็นที่ผมอยากจะนำเสนอและมีความเกี่ยวข้องกับเรื่องเหล่านี้ก็คือ ก่อนที่เราจะเริ่มดำเนินการเรื่องดังกล่าวนี้ (Monitoring และ Security Operations) จะต้องเริ่มจากการวางแผนและทำการออกแบบก่อนครับ เพราะเรื่องนี้ยังมีรายละเอียดอีกเยอะพอสมควรครับ อีกทั้งยังเกี่ยวข้องกับหลาย Services ใน Microsoft Azure ดังที่ผมได้ยกตัวอย่างไปในข้างต้นครับ และสำหรับบทความนี้ ผมจะนำเสนอเรื่องของการรวบรวมข้อมูล (Collecting Data) จาก Workloads คือ Virtual Machines ครับ โดยมีวัตถุประสงค์คือ นำเอาข้อมูลดังกล่าวนี้มาทำดำเนินการต่อ เช่น การ Monitoring, การ Detection, และอื่นๆ เป็นต้น ในกรณีที่เราต้องการรวบรวมข้อมูลจาก Virtual Machines ที่อยู่ใน IT Environments (Hybrid และ Multi-Cloud) ถ้าใช้ Microsoft Azure จะต้องมีการติดตั้ง Agent ไปยัง Virtual Machines เหล่านี้ครับ โดย Agent ที่ว่านี้มีชื่อว่า "Azure Monitor Agent" หรือเรียกสั้นๆ ว่า "AMA" ครับ โดย AMA จะเป็น Agent ตัวใหม่ที่ทาง Microsoft ได้มีการพัฒนาขึ้นมาเพื่อใช้งานแทน Agent เดิมคือ Azure Log Analytics Agent ครับ (ซึ่งทาง Microsoft จะ Retired ในวันที่ 31 August 2024 นี้ครับ) รวมถึงมาแทน Agents อื่นๆ เช่น Telegraf Agent และ Diagnostics Extension ด้วยครับ

เพราะฉะนั้นในกรณีถ้าหากท่านผู้อ่านมีการใช้งาน Azure Log Analytics Agent อยู่ ก็จะตัองเตรียมวางแผนในเรื่องของการ Migrate มาใช้งาน AMA แทนครับ รายละเอียดเกี่ยวกับเรื่องนี้สามารถไปที่ Link นี้ได้เลยครับ, Migrate from legacy agents to Azure Monitor Agent - Azure Monitor | Microsoft Learn

Azure Monitor Agent (AMA) คืออะไร?

AMA คือ Agent ที่ทำหน้าที่ในการเก็บรวบรวมข้อมูล (Performance Metric และ Logs) จาก Guest OS (Windows และ Linux) ของ Virtual Machines ที่อยู่ใน Microsoft Azure, On-Premise, และที่อื่นๆ (ครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments) โดยข้อมูลที่เก็บรวบรวมมาจาก Virtual Machines ต่างๆ นั้นก็จถูกนำไปใช้งานกับ Services อื่นๆ ใน Microsoft Azure เช่น Azure Log Analytics Workspace, Azure Monitor, Microsoft Defender for Cloud, เป็นต้น

สำหรับ AMA นั้นทาง Microsoft ได้มีการปรับปรุงและพัฒนาความสามารถต่างๆ ที่ดีและเก่งขึ้นกว่า Azure Log Analytics Agent ครับ ยกตัวอย่างเช่น 

- การรวบรวมข้อมูลต่างๆ นั้น เราสามารถกำหนดได้ว่าจะทำเอาข้อมูลอะไรบ้าง ไม่ต้องเอามาทั้งหมดเหมือนแต่ก่อน โดยใช้ "Data Collection Rules" หรือ "DCR" ทำให้เกิดความยืดหยุ่นสำหรับการเก็บรวบรวมข้อมูล และที่สำคัญคือ ทำให้ประหยัค่าใช้จ่ายอีกด้วยครับ

- ใช้ Agent เดียว (AMA) รองรับทั้ง Server และ Devices 

- ข้อมูลที่ถูกรวบรวมมานั้นสามารถถูกส่งไปยังหลายๆ ที่หรือหลาย Azure Log Analytics Workspaces (Multi-Homing) รองรับทั้ง Cross-Region และ Cross-Tenant 

- มีความปลอดภัยและ Performance ดีขึ้น เพราะมีการทำงานร่วมกับ Microsoft Entra ID (Managed Identity) และมี Throughput ดีกว่าเดิมถึง 25% เมื่อเปรียบเทียบกับ Agent เดิม (Azure Log Analytics Agent)

- อื่นๆ

รายละเอียดเพิ่มเติมเกี่ยวกับ AMA ครับ, Azure Monitor Agent overview - Azure Monitor | Microsoft Learn

ในเรื่องของการติดตั้ง AMA นั้น ไม่ได้มีขั้นตอนอะไรที่ยุ่งยากเลยครับ ทั้งนี้ขึ้นอยู่กับ Virtual Machines ของเราอยู่ที่ไหน ยกตัวอย่างเช่น ถ้า Virtual Machines อยู่ใน Microsoft Azure (Azure Virtual Machines) ก็สามารถติดตั้ง AMA ได้จาก Extension ครับ เพราะทาง Microsoft ได้เตรียม AMA สำหรับติดตั้งใน Azure Virtual Machines ไว้เป็น Azure VM Extension เรียบร้อยแล้วครับ รายละเอียดเพิ่มเติมสามารถไปที่ Link นี้ครับ, Manage Azure Monitor Agent - Azure Monitor | Microsoft Learn

สำหรับ Virtual Machines ที่ไม่ได้อยู่ใน Microsoft Azure เช่น อยู่ใน On-Premise จะต้องมีการติดตั้ง Agent ที่ชื่อว่า "Azure Connected Machine Agent" ก่อนจากนั้นค่อยติดตั้ง AMA ครับ โดยตัวของ Azure Connected Machine Agent นั้นจะทำงานร่วมกับ Azure Arc ซึ่งเป็นอีกหนึ่ง Service ที่อยู่ใน Microsoft Azure ครับ

และทั้งหมดนี้เป็นเรื่องราวของ Azure Monitor Agent (AMA) ที่ผมนำมาให้ทุกท่านได้รู้จักกันครับ และอย่างที่ผมได้อธิบายไว้ในข้างต้นของบทความนี้ว่า ยังมีรายละเอียดอีกเยอะครับ และที่สำคัญคือ การวางแผนและออกแบบก่อนที่จะเริ่มใช้งานนะครับ.....

Microsoft Defender for Cloud กับ Azure Arc-enabled Servers

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมจะมานำเสนอเรื่องราวของ Cloud Security โดยจะเข้าไปเกี่ยวข้องกับ Microsoft Defender for Cloud หรือ MDC ครับ และอย่างที่หลายๆ ท่านรู้จักและคุ้นเคยกับ MDC อยู่แล้ว ก็พอจะทราบว่า MDC เป็น Service หนึ่งที่อยู่ใน Microsoft Azure ที่ให้บริการ Security Solutions เช่น Cloud Security Posture Management (CSPM), Cloud Workload Protection (CWP), และ Cloud-Native Application Protection Platform (CNAPP) สำหรับท่านใดที่ยังไม่คุ้นเคยหรือยังไม่รู้จัก Microsoft Defender for Cloud สามารถไปหาอ่านบทความของผมก่อนหน้าได้เลยครับ

กลับมาที่ตัวของ MDC กันต่อครับ ด้วยความสามารถที่เพิ่มได้เกริ่นไว้เมื่อซักครู่นั้น ทำให้เราสามารถพิจารณานำเอา MDC เข้ามาช่วยในการ Secure & Protect Workloads ต่างๆ ยกตัวอย่างเช่น Virtual Machines โดย Workloads (Virtual Machines) เหล่านั้นจะอยู่ใน On-Premise หรือ On Cloud ก็ได้ครับ เพราะ MDC สามารถทำการ Secure & Protect ครอบคลุม IT Environments ทั้ง Hybrid และ Multi-Cloud อยู่แล้วครับ จากตัวอย่างของ Workloads ที่ผมได้เกริ่นไว้ นั่นก็คือ Virtual Machines นั้นในกรณีที่องค์กรใดก็ตามที่ต้องการบริหารจัดการตลอดจนการ Secure & Protect Virtual Machines ที่อยู่ใน Hybrid หรือ Multi-Cloud Environment อย่างในกรณีของตัวอย่างที่ผมกำลังอธิบายอยู่นี้ คือ ผมต้องการที่จะทำการ Secure & Protect Virtual Machines ของผมโดยใช้ MDC ครับ และจากความต้องการนี้ส่งผลทำให้ผมจะต้องนำเอาอีกหนึ่ง Service ที่อยู่ใน Microsoft Azure ที่มีชื่อว่า "Azure Arc" เข้ามาทำงานร่วมกับ MDC ครับ เพราะตัวอย่างของผมนี้ Virtual Machines ของผมไม่ได้อยู่ใน Microsoft Azure ครับ อาจจะอยู่ใน On-Premise หรือ On Cloud (Cloud Service Providers อื่นๆ เช่น AWS, GCP, เป็นต้น) โดย Azure Arc จะเป็น Service ที่เข้ามาทำให้การบริหารจัดการ Resources ต่างๆ ที่อยู่ใน Hybrid และ Multi-Cloud Environments ได้สะดวกและง่ายมากขึ้นครับ และในความเป็นจริงแล้วตัวของ Azure Arc นั้นมีความสามารถเยอะครับ ดังรูป

แต่สำหรับบทความนี้ผมจะหยิบเอาความสามารถของ Azure Arc ที่เกี่ยวข้องกับการทำงานร่วมกับ MDC เพื่อทำการ Secure & Protect Virtual Machines ครับ และความสามารถของ Azure Arc นี้มีชื่อว่า "Azure Arc-enabled Servers" ครับ

Azure Arc-enabled Servers คืออะไร?

ตามที่ผมไว้อธิบายไว้ก่อนหน้านี้ว่า Azure Arc-enabled Servers นั้นจะเข้ามาช่วยในเรื่องของการบริหารจัดการตลอดจนการทำงานร่วมกันกับ MDC เพื่อทำการ Secure & Protect Virtual Machines (ที่ไม่ได้อยู่ใน Microsoft Azure) ครับ

สำหรับ Azure Arc (Azure Arc-enables Servers) นั้นจะมีส่วนประกอบที่สำคัญคือ Agent ครับ โดย Agent ของ Azure Arc จะมีชื่อว่า "Connected Machine Agent" โดย Agent ดังกล่าวนี้จะนำไปติดตั้งที่ Virtual Machines ที่ต้องการ และตัวของ Agent จะตัวเองเสมือนกับเป็นสะพานในการเชื่อมต่อกันระหว่างตัวของ Virtual Machines (Resources) กับ Microsoft Azure ครับ นอกจากนี้แล้วในตัวของ Connected Machine Agent ยังประกอบไปด้วย Logical Components ต่างๆ ดังนี้:

- Hybrid Instance Metadata Service (HIMDS) มีหน้าที่จัดการ Connection ระหว่าง Microsoft Azure กับ Azure Identity ของ Connected Machine

- Guest Configuration Agent ทำหน้าที่ในการประเมินว่า Machines ดังกล่าว Comply กับ Policies หรือ Compliances ต่างๆ ที่ได้มีการบังคับใช้หรือไม่

- Extension Agent ทำหน้าที่ในการจัดการ VM Extensions รวมถึง การ Install, Uninstall, และ Upgrade

เมื่อมีการสร้างการเชื่อมต่อระหว่าง Azure Arc กับ Resources นั้น (Virtual Machines ที่อยู่ใน On-Premise หรืออยู่ใน Cloud Service Providers อื่นๆ) ผ่านทาง Connected Machine Agent เรียบร้อยแล้ว ส่งผลทำให้เกิดสิ่งที่เรียกว่า "Arc-enabled" กับ Resouces นั้นๆ 

ทำให้ Resources ที่ว่านี้เปรียบเสมือนกับว่ามันเป็น Resources ที่ถูกสร้างหรือเกิดขึ้นใน Microsoft Azure อย่างที่เราคุ้นเคยครับ ส่งผลทำให้เราสามารถบริหารจัดการ Resources (ผ่าน Arc-enabled) นั้นๆ ได้ (สามารถทำ Access Control, Policy, เป็นต้น) นอกจากนี้แล้วเรายังสามารถนำเอา Services ต่างๆ ใน Microsoft Azure เข้ามาทำงานร่วมกัน ตัวอย่างของ Services ที่ผมนำมาทำงานร่วมกันนั่นก็คือ Microsoft Defender for Cloud หรือ MDC นั่นเองครับ

ความสามารถของ Azure Arc-enables Servers

- สามารถจัดการ Resources (ผ่าน Arc-enabled ที่อธิบายไปก่อนหน้านี้) โดยสามารถจัดเรียงเพื่อทำ Inventory ของ Resources ดังกล่าวนี้เข้ามาอยู่ใน Resource Group และบริหารจัดการผ่านทาง Tools ต่างๆ ของ Microsoft Azure เช่น Azure Portal, Azure Command Line Interface (CLI), Azure PowerShell, และอื่นๆ

- สามารถทำงานร่วมกับ Microsoft Defender for Cloud

- สามารถทำงานร่วมกับ Microsoft Sentinel

- สามารถทำงานร่วมกับ Azure Policy

- อื่นๆ

รายละเอียดเพิ่มเติมสำหรับ MDC ที่จะทำงานร่วมกับ Azure Arc สามารถไปที่ Link ดังกล่าวนี้ได้เลยครับ, Connect on-premises machines - Microsoft Defender for Cloud | Microsoft Learn

และทั้งหมดคือเรื่องราวของตัวอย่างการนำเอา 2 Services ใน Microsoft Azure ซึ่งก็คือ Microsoft Defender for Cloud (MDC) กับ Azure Arc (Azure Arc-enabled Servers) มาทำงานร่วมกันเพื่อดำเนินการ Secure & Protect Virtual Machines ที่อยู่ที่ไหนก็ได้ครับผม.....

มาทำความรู้จักกับ Kusto Query Language (KQL) เพื่อทำ Threat Hunting

      สวัสดีปีใหม่ 2567 ครับทุกท่าน สำหรับบทความนี้ถือว่าเป็นบทความแรกของปี 2567 ครับ โดยจะเป็นบทความที่จะนำเสนอเรื่องราวเกี่ยวกับ Microsoft Sentinel ครับ แต่จะโฟกัสที่เรื่องของการทำ Threat Hunting ใน Microsoft Sentinel และ Azure Log Analytics Workspace ครับ เพราะโดยคอนเซปการทำงานของ Microsoft Sentinel นั้นจะต้องอาศัยการทำงานร่วมกับหลายๆ Services (ใน Microsoft Azure) ตัวอย่างเช่น Azure Log Analytics Workspace ซึ่งถือว่าเป็นมีบทบาทสำคัญกับ Microsoft Sentinel เนื่องจากตัวของ Azure Log Analytics Workspace จะทำหน้าที่ในการเก็บข้อมูลต่างๆ ของ IT Environment นั้น (รายละเอียดเพิ่มเติมเกี่ยวกับ Azure Log Analytics Workspace สามารถย้อนกลับไปอ่านบทความก่อนหน้านี้ของผมได้เลยครับ) เมื่อข้อมูลที่ได้ทำการรวบรวมมาถูกเก็บไว้ใน Azure Log Analytics Workspace เรียบร้อยแล้ว ท่านที่เป็นเกี่ยวข้องกับ Security เช่น Security Operations Analyst หรือ SOC Teams เป็นต้น ก็สามารถทำการค้นหาข้อมูลที่เก็บอยู่ใน Azure Log Analytics Workspace ได้โดยใช้วิธีการเขียน Query ซึ่งใช้ภาษาที่เรียกว่า "Kusto Query Language" หรือ "KQL" ครับ 

โดยการ Query ข้อมูลดังกล่าวนี้มีวัตถุประสงค์คือ ต้องการที่ทำการค้นหาจากข้อมูลที่ได้เก็บรวบรวมมานั้น เพื่อมาวิเคราะห์และตรวจสอบดูว่ามีสิ่งผิดปรกติ,  เหตุการณ์ที่น่าสงสัย, หรือมี Activities ใดๆ ที่ผิดปรกติเกิดขึ้นใน IT Environment นั้นๆ หรือไม่ โดยการดำเนินการดังกล่าวนี้ในมุมของ Cybersecurity จะเรียกว่า "Threat Hunting" ครับ ซึ่งถือว่าเป็น การตรวจสอบและป้องกันแบบเชิงรุก (Proactive) ครับ ลำดับถัดไปผมจะพาทุกท่านมาทำความรู้จักกับ KQL ที่เกี่ยวข้องกับ Microsoft Sentinel เท่านั้นนะครับ เพื่อดำเนินการในเรื่องของการทำ Threat Hunting อย่างที่อธิบายไว้เมื่อซักครู่ครับ

Kusto Query Language (KQL) คืออะไร ?

อย่างที่อธิบายไปก่อนหน้านี้เกี่ยวกับ KQL คือ ภาษาที่เราสามารถเขียนเพื่อทำการดึงและวิเคราะห์ข้อมูล (รองรับข้อมูลขนาดใหญ่)ที่เก็บอยู่ใน Azure Log Analytics Workspace (ที่ได้มีการ Integrate หรือทำงานร่วมกับ Microsoft Sentinel) มาทำการค้นหาหรือวิเคราะห์สำหรับการทำ Threat Hunting  โดย KQL เป็นการเขียน Query แบบที่เรียกว่า "Read-Only Request" คือ เป็นการเขียน Query เพื่อทำการ Explore, Filter, Correlate, และ Summarize ข้อมูลครับ และรูปด้านล่างเป็นการแสดงถึงความสามารถหรือฟีเจอร์หนึ่งใน Azure Log Analytics Workspace ที่ชื่อว่า "Log Analytics Explorer" ดังรูปด้านล่างครับ

เราสามารถใช้ Log Analytics Explorer ในการเขียน KQL Query ได้ครับ สิ่งที่ผมอยากจะอธิบายเพิ่มเติมเกี่ยวกับ Azure Log Analytics Workspace เพิ่มเติม คือ เมื่อทำการรวบรวมข้อมูลต่างๆ มาเก็บไว้ใน Azure Log Analytics Workspace  ตัวของ Azure Log Analytics Workspace จะทำการจัดเก็บข้อมูลที่ได้รวบรวมมานั้นในรูปแบบของ Table ครับ เพราะฉะนั้นมีความเป็นไปได้ที่แต่ละองค์กรที่มีการใช้งาน Microsoft Sentinel และ Azure Log Analytics Workspace จะมี Tables ที่เหมือนแลแตกต่างกันครับ เพราะฉะนั้นเมื่อข้อมูลถูกเก็บมาไว้ที่ Azure Log Analytics Workspace เรียบร้อย หมายความว่าจัดเก็บอยู่ใน Tables ต่างๆ เรียบร้อยแล้ว จากนั้นเราสามารถที่จะเขียน KQL Query เพื่อดึงข้อมูลที่เก็บไว้ใน Tables ต่างๆ ตามความต้องการได้ครับ 

ส่วนประกอบของ KQL Query

จากรูปด้านบนส่วนประกอบของ KQL Query ประกอบไปด้วยส่วนประกอบต่างๆ ดังนี้:

1. Data หรือ Dataset คือ ข้อมูลที่มาจาก Table เดียว (Single Table), จากหลายๆ Tables (Multiple Tables), จาก User Defined Tables (Tables ที่เราสร้างเอง), เป็นต้น

2. Condition คือ การกำหนดเงื่อนไขในการดึงและวิเคราะห์ข้อมูล

3. Evidence หรือ Project คือ การกำหนดข้อมูลใดบ้างที่จะถูกแสดงผล ถ้าไม่กำหนดก็จะแสดงผลทั้งหมด

จาก 3 ส่วนประกอบของ KQL Query ก็จะถูกเชื่อมกันด้วย " | "  เรียกว่า "Pipeline Operators" หมายความว่า Output ที่ได้จากส่วนประกอบหนึ่งจะกลายเป็น Input ของส่วนประกอบถัดไปครับ  

ตัวอย่าง KQL Query แบบง่ายๆ ดังรูปด้านล่าง

SecurityEvent

| where EventID == 4624

SecurityEvent คือ ชื่อของ Table โดยผมต้องการค้นหาข้อมูลคือ EventID หมายเลข 4624 ครับ

หรืออีกหนึ่งตัวอย่าง

SigninLogs | where ResultType == "Failure" 

SigninLogs คือ ชื่อของ Table โดยผมต้องการค้นหาข้อมูลคือ การ Sign-In ที่มีผลลัพธ์เป็น Failure ครับ

โดย KQL Query ข้างต้น เราสามารถเขียนและรัน (Run) ได้ผ่านทาง Log Analytics Explorer โดยตัวของ Log Analytics Explorer เป็นฟีเจอร์หนึ่งที่อยู่ใน Azure Log Analytics Workspace อย่างที่เกริ่นไว้ข้างต้นครับ คราวนี้มาสำรวจดู Log Analytics Explorer กันครับ

1. Action Bar คือ ส่วนที่เราสามารถกำหนด Scope, Run, Save, และอื่นๆ กับ KQL Query 

2. Metadata คือ Tables, Queries (Microsoft Defined Queries and Saved Queries), และอื่นๆ ดังรูปด้านล่าง

3. Query Windows คือ ส่วนที่เราเขียน KQL Queries ดังรูปด้านล่างครับ

4. Result Windows คือ ส่วนที่แสดงผลลัพธ์หรือ Result ของ KQL Query

สิ่งที่เราจะต้องดำเนินการก่อนที่จะทำ Threat Hunting หรือการเขียน KQL Query เพื่อทำการค้นหาและวิเคราะห์ข้อมูลต่างๆ ตามที่ได้อธิบายไว้ในข้างต้น คือ การวางแผนเพื่อดำเนินการ Hunting ครับ ยกตัวอย่างเช่น เราจะต้องมีการวางแผนกำหนดวัตถุประสงค์ของการทำ Threating Hunting ก่อนว่าเราต้องการค้นหาและวิเคราะห์ข้อมูลเพื่ออะไร?, การค้นหาดังกล่าวนี้เกี่ยวข้องกับข้อมูลใดบ้างๆ, และอื่นๆ หลังจากนั้นค่อยมาทำการเขียน KQL Query ครับ โดย Microsoft ได้มีเตรียมข้อมูลและ Resources ต่างๆ ตลอดจนตัวอย่างของ KQL Queries เอาไว้ให้เราพิจารณาเพื่อนำไปประยุกต์ใช้งานครับ ผมขอแนะนำ Link นี้ (Kusto Query in Microsoft Sentinel) ครับ, Kusto Query Language in Microsoft Sentinel | Microsoft Learn

และนี่คือเรื่องราวเบื้องต้นเกี่ยวกับการทำ Threat Hunting ใน Microsoft Sentinel โดยใช้ KQL ครับผม.....