รู้จักกับ 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 ครับผม.....

การบริหารจัดการ Logs (Azure Log Analytics Workspace) ใน Microsoft Sentinel

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะเป็นการนำเสนอเรื่องราวเกี่ยวกับการพิจารณาและทำความเข้าใจเรื่องของการบริหารจัดการ Azure Log Analytics Workspace สำหรับใช้งานร่วมกับ Microsoft Sentinel ครับ  สำหรับท่านใดที่ยังไม่รู้จักทั้ง Azure Log Analytics Workspace และ Microsoft Sentinel แนะนำให้อ่านบทความนี้ก่อนนะครับ

Microsoft Sentinel, WT Blog (ITGeist): เจาะลึก Phases การทำงานของ Microsoft Sentinel (itgeist5blog.blogspot.com)

Azure Log Analytics Workspace, WT Blog (ITGeist): ทำความรู้จักกับ Azure Log Analytics Workspace (itgeist5blog.blogspot.com)

สำหรับท่านใดที่สนใจและกำลังวางแผนจะนำเอา Microsoft Sentinel ซึ่งเป็น Service หนึ่งใน Microsoft Azure เข้ามาใช้งาน (SIEM & SOAR) นั้น จากประสบการณ์ที่ผมเคยเข้าไปช่วยให้คำปรึกษา, Plan & Design, Implement ตลอดจนจัด Workshop และฝึกอบรมให้กับลูกค้า เรื่องหนึ่งที่ผมมักพบเจออยู่บ่อยๆ คือ เรื่องของความรู้ความเข้าใจคอนเซปและการทำงานของ Microsoft Sentinel ว่าเป็นอย่างไร? ก่อนที่จะเริ่มดำเนินการใช้งาน Microsoft Sentinel ครับ เพราะบางครั้งผมเจอลูกค้ามาขอคำปรึกษาว่า ช่วงที่ผ่านมาได้ดำเนินการติดตั้งและใช้งาน Microsoft Sentinel ไปแล้ว แต่ไม่รู้ว่าจะใช้งานอย่างไร?, จะต้องใช้ฟีเจอร์ใดบ้าง, เรื่องของค่าใช้จ่ายที่เกี่ยวข้องกับ Microsoft Sentinel, และอื่นๆ เป็นต้นครับ

จากประเด็นข้างต้น ผมอยากจะแนะนำครับว่า ในกรณีที่เราสนใจและอยากใช้งาน Microsoft Sentinel ให้เริ่มจากการ Planning & Designing ก่อนครับ และแน่นอนว่าเราจะต้องมีความรู้ความเข้าใจคอนเซปตลอดจนสิ่งต่างๆ ที่เกี่ยวข้องกับ Microsoft Sentinel มาก่อนครับ, จากนั้นทำการเก็บรวบรวมข้อมูลของ Existing Environment ของเราว่าเป็นอย่างไร, ตามด้วย Requirements หรือความต้องการที่จะใช้งาน Microsoft Sentinel เมื่อได้ข้อมูลต่างๆ จากที่อธิบายไว้เมื่อซักครู่แล้ว ในขั้นตอนถัดมาคือ การวางแผนและออกแบบ Architecture ของ Microsoft Sentinel ครับ ซึ่งรายละเอียดเกี่ยวกับเรื่องนี้และเรื่องอื่นๆ ของ Microsoft Sentinel ทาง Microsoft ได้เตรียมข้อมูลและเอกสารต่างๆ เอาไว้ให้ทุกท่านสามารถไปศึกษาเพิ่มเติมครับ สามารถไปที่ Link นี้ครับ, Microsoft Sentinel documentation | Microsoft Learn

แต่ในบทความนี้ผมจะโฟกัสที่เรื่องของการพิจารณาการบริหารจัดการ Azure Log Analytics Workspace ที่ใช้งานร่วมกับ Microsoft Sentinel ตามที่เกริ่นไว้ในตอนต้นของบทความครับ โดยถ้าว่ากันตามคอนเซปทางด้านเทคนิคที่เกี่ยวข้องกับ Microsoft Sentinel นั้น ตัวของ Azure Log Analytics Workspace ถือว่าเป็นส่วนประกอบที่สำคัญสำหรับ Microsoft Sentinel ครับ เพราะ Microsoft Sentinel เป็น Service ที่ให้บริการ SIEM & SOAR (Cloud-Native) เพราะฉะนั้นในการทำงานของ Microsoft Sentinel จะต้องมีการเก็บรวบรวมข้อมูล (Collecting Data) ซึ่งข้อมูลในที่นี้ก็คือ Logs ที่เกี่ยวข้องกับใน IT Environment ขององค์กรหรือของทุกท่านครับ โดยตัวของ Microsoft Sentinel เองนั้น เค้าไม่มีความสามารถในการเก็บข้อมูลดังกล่าวนี้ครับ เพราะฉะนั้น Micrsoft Sentinel จึงต้องการ Azure Log Analytics Workspace เข้ามาช่วยในเรื่องนี้ครับ และถ้าทุกท่านรู้จักและเข้าใจคอนเซปการทำงานของ Azure Log Analytics Workspace ก็จะทราบว่าตัวของ Azure Log Analytics Workspace เป็น Service ที่ให้บริหารที่ที่สำหรับเก็บข้อมูล (Data Repository) และสามารถทำการสืบค้นหรือทำการ Query ข้อมูลได้อีกด้วย (โดยใช้ KQL) ครับ แต่สิ่งที่เราจะต้องทำความเข้าใจ Azure Log Analytics Workspace รวมถึง Microsoft Sentinel อีกเรื่องหนึ่งที่สำคัญก่อนที่จะใช้งาน คือ เรื่องของค่าใช้จ่ายครับ โดยเฉพาะตัวของ Azure Log Analytics Workspace ครับ เนื่องจาก Azure Log Analytics Workspace จะคิดค่าใช้จ่ายจากการเก็บข้อมูลที่เราได้ไปรวบรวมมาครับ เพราะฉะนั้นสิ่งสำคัญอย่างที่ผมได้อธิบายไว้ข้างต้น คือ เรื่องของการ Planning & Designing ครับ เพราะถ้าวางแผนและออกแบบไว้ไม่ดี จะส่งผลกระทบหลายๆ อย่างตามมาครับ และที่มาแน่ๆ เลยเรื่องนึง คือ เรื่องของค่าใช้จ่ายนี่ล่ะครับ เพราะฉะนั้นเรื่องที่เราจะต้องทำความเข้าใจเรื่องหนึ่งเลยก็คือ การบริหารจัดการ Logs ใน Azure Log Analytics Workspace ครับ

โดยผมขอเริ่มด้วยประเด็นหลักๆ ที่สำคัญที่จะต้องทำความเข้าใจและพิจารณาการบริหารจัดการ  Azure Log Analytics Workspace ที่จะนำมาใช้งานร่วมกับ Microsoft Sentinel 

- จำนวนของ Azure Log Analytics Workspace

- Logs Sources คือ ต้นทางของ Logs หรือข้อมูลที่จะไปรวบรวมมานั้นมีอะไรบ้าง?

- รูปแบบของการบริหารจัดการ Logs ของ Azure Log Analytics Workspace

- การเก็บรักษาข้อมูล (Data Retention) ไว้นานเท่าไร?

ประเด็นแรก คือ จำนวนของ Azure Log Analytics Workspace ครับ สิ่งที่จะต้องพิจารณาก็คือ เราจะมีกี่ Azure Log Analytics Workspace? คำตอบสำหรับประเด็นนี้คือ อยู่ที่ความต้องการของแต่ละองค์กรครับ แต่ถ้าว่าก็ตาม Best Practices ของ Microsoft คือ ควรจะมีจำนวน Azure Log Analytics Workspace ให้น้อยที่สุดหรือมีเท่าที่จำเป็นครับ ประเด็นที่สอง คือ เรื่อง Sources ของ Logs ที่จะไปเก็บรวบรวมข้อมูลมานั้น จะขึ้นอยู่กับความต้องการและ Environment ของแต่ละองค์กรหรือแต่ละที่เป็นอย่างไรครับ ประเด็นถัดมา คือ รูปแบบของการบริหารจัดการ Logs ของ Azure Log Analytics Workspace ซึ่ง ณ ปัจจุบันมีหลายรูปแบบให้เราเลือกพิจารณาใช้งานครับ มาดูรายละเอียดสำหรับประเด็นนี้กันครับ

รูปแบบของการบริหารจัดการ Logs ใน Azure Log Analytics Workspace ณ ตอนนี้มี 3 แบบให้พิจารณาเลือกใช้ดังนี้:

1. Analytics Log, เป็นรูปแบบหลักหรือรูปแบบปรกติของการบริหารจัดการ Logs ใน Azure Log Analytics Workspace ที่ใช้งาน โดยรูปแบบดังกล่าวนี้มาพร้อมกับความสามารถในการวิเคราะห์เต็มรูปแบบ เช่น Analytic Rules, Workbooks, Hunting Queries, เป็นต้น สำหรับค่าใช้จ่ายของรูปแบบดังกล่าวนี้มีให้เลือก 2 Options คือ  เริ่มจาก Option แรก, Pay-As-You-Go (คิดค่าใช้จ่าย Per GB ตาม Volume ของข้อมูลที่ไปเก็บรวบรวมมา) และ Option ที่สองคือ Commitment Tier (คิดค่าใช้จ่ายตาม Tiers ที่เลือกครับ โดยจะมีส่วนลดหรือถูกกว่า Option แรก) ครับ

2. Basic Log, เป็นรูปแบบของการบริหารจัดการ Logs ที่เน้นเรื่องของค่าใช้จ่ายไม่สูง โดย Basic Logs มาพร้อมกับความสามารถต่างๆ (แต่มีข้อจำกัด) เช่น การ Investigate Incidents, การทำ Threat Hunting  เช่น การเก็บข้อมูลหรือ Data Retention จะเก็บได้ 8 วัน 

3. Archived Log, เป็นรูปแบบของการบริหารจัดการ Logs ที่เน้นการเก็บข้อมูลในระยะเวลานาน โดยสามารถเก็บข้อมูลเอาไว้ได้นานมากถึง 12 ปี และบางครั้งต้องการค้นหาข้อมูล (Threat Hunting)

สำหรับรูปด้านล่างเป็นรูปที่แสดงถึง รูปแบบของการบริหารจัดการ Logs ใน Azure Log Analytics Workspace ที่ผมได้อธิบายไปเมื่อซักครู่นี้ครับ

และอีกหนึ่งประเด็นจากข้างต้นที่จะต้องทำการพิจารณาสำหรับเรื่องของการบริหารจัดการ Logs ใน Azure Log Analytics Workspace คือ เรื่องของ Data Retention ครับ โดยแต่ละองค์กรก็จะมีความต้องการที่จะเก็บรักษาข้อมูลในระยะเวลาที่แตกต่างกันครับ รายละเอียดเพิ่มเติมเกี่ยวกับการบริหารจัดการ Logs ใน Azure Log Analytics Workspace สามารถไปที่ Link นี้ได้เลยครับ, Data retention and archive in Azure Monitor Logs - Azure Monitor | Microsoft Learn

เรื่องราวที่ผมได้นำเสนอในบทความนี้เป็นเพียงแค่ประเด็นหนึ่งเท่านั้นที่เราจะต้องทำความเข้าใจและพิจารณาก่อนที่จะใช้งาน Microsoft Sentinel เท่านั้นนะครับ แต่ถือว่าเป็นเรื่องที่สำคัญเรื่องหนึ่งทีเดียวครับผม.....

สำรวจสมาชิกใน Microsoft Entra

      สวัสดีครับทุกท่านสำหรับบทความนี้ จะเป็นการอัพเดทเรื่องราวของ Product Family หนึ่งของทาง Microsoft ที่ชื่อว่า "Microsoft Entra" ครับ เพราะในช่วงที่ผ่านมาทาง Microsoft ได้มีการเปลี่ยนแปลงและเพิ่มเติมหลายอย่างเข้าไปใน Product Family นี้ครับ โดยภาพรวมของ Microsoft Entra มีความสามารถเยอะครับ แต่หลักๆ จะโฟกัสเรื่องของการบริหารจัดการตลอดจนเรื่องของความปลอดภัยที่เกี่ยวข้องกับ Identity และในช่วงที่ผ่านมานี้เริ่มขยายความสามารถอื่นๆ เพิ่มเติม เช่น Network Access เป็นต้น โดยใน Microsoft Entra มีสมาชิกหรือ Products/Services ต่างๆ อยู่เยอะเลยครับ ซึ่งเดี๋ยวผมจะไล่เรียงให้ทุกท่านได้ทราบกันครับ

เรามาสำรวจสมาชิกต่างๆ ใน Microsoft Entra กันครับ

Microsoft Entra ID ในช่วงที่ผ่านมาทาง Microsoft ได้มีการเปลี่ยนชื่อของ Azure Active Directory (Azure AD) มาเป็น Microsoft Entra ID ครับ โดย Microsoft Entra ID ถือว่าเป็น Service หนึ่งที่มีความสำคัญมาก Service หนึ่ง เนื่องจาก Microsoft Entra ID มีหน้าที่ในการบริหารจัดการ Identity หรือที่เรียกกันทั่วๆ ไปว่า "Identity and Access Management" หรือ IAM นั่นเอง โดย Microsoft Entra ID จะเป็น Service ที่เริ่มทำงานทันทีหลังจากที่เรามีการนำเอา Cloud ของทาง Microsoft ไม่ว่าจะเป็น Microsoft Azure, Microsoft 365, และอื่นๆ เข้ามาประยุกต์ใช้งาน โดย Microsoft Entra ID จะเข้าดำเนินการในกระบวนการต่างๆ เช่น Authentication, Authorization, เป็นต้น 

นอกจากนี้แล้วเรายังสามารถนำเอา Microsoft Entra ID มาทำงานร่วมกับ Active Direct Domain Service (AD DS) เพื่อทำ Hybrid Identity Scenario ส่งผลทำให้ผู้ใช้งานในองค์กรสามารถเข้าถึงหรือ Access Resources ที่อยู่ใน On-Premise และ Cloud โดยใช้ Identity เดียวหรือที่เราเรียกคอนเซปและ Benefit ดังกล่าวนี้ว่า "Single Sign-On" หรือ SSO นั่นเอง 

นอกจากเปลี่ยนชื่อแล้ว ยังมีการเปลี่ยนชื่อฟีเจอร์ต่างๆ ของ Microsoft Entra ID อีกด้วยครับ ยกตัวอย่างเช่น

Azure AD Free เป็น Microsoft Entra ID Free

Azure AD Premium P1 เป็น Microsoft Entra ID P1

Azure AD Premium P2 เป็น Microsoft Entra ID P2

Azure AD External Identities เป็น Microsoft Entra External Identities

Azure AD B2C เป็น Microsoft Entra External ID

Azure AD Graph เป็น Microsoft Graph

Azure AD Authentication Library (ADAL) เป็น Microsoft Authentication Library (MSAL)

และอื่นๆ รายละเอียดเพิ่มเติมสามารถไปที่ Link นี้ได้เลยครับ, New name for Azure Active Directory - Microsoft Entra | Microsoft Learn

Microsoft Entra ID Governance (ชื่อเดิม Azure AD Identity Governance) ช่วยในเรื่องของการทำ Identity Governance เช่น การ Protect, Monitor, Audit การเข้าถึง Assets หรือ Resources ต่างๆ ของผู้ใช้งานในองค์กร, รายละเอียดเพิ่มเติม Microsoft Entra ID Governance - Microsoft Entra ID Governance | Microsoft Learn

Microsoft Entra External ID ช่วยในเรื่องของการสร้างความปลอดภัยในการเข้าถึง Apps ต่างๆ ของลูกค้าและ Partners, รายละเอียดเพิ่มเติม Microsoft Entra External ID overview - Microsoft Entra External ID | Microsoft Learn

Microsoft Entra Verified ID ช่วยในเรื่องของการบริหารจัดการ Identity ในรูปแบบ Decentralized Identity หรือ Verifiable Credentials หรือ VC, รายละเอียดเพิ่มเติม Introduction to Microsoft Entra Verified ID - Microsoft Entra Verified ID | Microsoft Learn

Microsoft Entra Permissions Management ช่วยในเรื่องของการบริหารจัดการ Permissions ใน Multi-Cloud Environment หรือเรียกว่า "Cloud Infrastructure Entitlement Management" หรือเรียกสั้นๆ ว่า "CIEM", รายละเอียดเพิ่มเติม What's Microsoft Entra Permissions Management? - Microsoft Entra Permissions Management | Microsoft Learn

Microsoft Entra Workload ID ช่วยในเรื่องของการสร้างความปลอดภัยสำหรับ Apps หรือ Services ต่างๆ ที่จะเข้าถึงหรือ Access Resources ต่างๆ ในองค์กร

*Workload ID (Workload Identities) คือ Identity ที่ได้มีการ Granted ให้กับ Apps หรือ Services ที่ต้องการเข้าถึง Resources หรือต้องการติดต่อสื่อสารกับ Services อื่นๆ 

รายละเอียดเพิ่มเติม Workload identities - Microsoft Entra Workload ID | Microsoft Learn

Microsoft Entra Internet Access ทำหน้าที่ Identity-Centric Secure Web Gateway (SWG) ให้กับ SaaS Apps และ Internet Traffic อื่นๆ เพื่อทำการ Protect Users, Devices, และ Data จากภัยคุกคามต่างๆ, รายละเอียดเพิ่มเติม Learn about Microsoft Entra Internet Access - Global Secure Access | Microsoft Learn

Microsoft Entra Private Access ช่วยในเรื่องของความปลอดภัยสำหรับผู้ใช้งานที่ต้องการเชื่อมต่อจากภายนอกเพื่อเข้ามาใช้งาน Apps ต่างๆ ภายในองค์กร โดยที่ไม่จำเป็นต้องใช้ VPN ในการถึงเหมือนแต่ก่อน, รายละเอียดเพิ่มเติม Learn about Microsoft Entra Private Access - Global Secure Access | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวส่วนหนึ่งของ Microsoft Entra ครับ ในโอกาสต่อไปผมจะนำเสนอเรื่องราวของสมาชิกแต่ละตัวใน Microsoft Entra ครับ ฝากติดตามกันด้วยครับผม.....

ทำความรู้จักกับ Azure Log Analytics Workspace

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Service หนึ่งใน Microsoft Azure ที่มีชื่อว่า "Azure Log Analytics Workspace" ครับ และต้องบอกทุกท่านไว้ก่อนเลยว่า Azure Log Analytics Workspace ถือว่าเป็นส่วนประกอบที่สำคัญส่วนหนึ่งสำหรับการทำ Security Operations เช่น การ Monitoring, Hunting, และอื่นๆ ครับ และในช่วงที่ผ่านมามีหลายๆ ท่านสอบถามผมว่า อยากจะทำการ Monitor และค้นหาข้อมูลจาก Logs จะต้องทำอย่างไร? และใน Microsoft Azure จะต้องใช้ Services ใด? และเพื่อไม่ให้เป็นการเสียเวลาเรามารู้จักกับ Azure Log Analytics Workspace กันเลยครับผม

Azure Log Analytics Workspace คืออะไร ?

และอย่างที่เกริ่นไว้ข้างต้นครับว่า Azure Log Analytics Workspace เป็น Service หนึ่งที่อยู่ใน Microsoft Azure ครับ โดย Azure Log Analytics Workspace จะเข้ามาเกี่ยวข้องในกรณีที่องค์กรหรือตัวของเรามีความต้องการที่จะทำการ Monitor Workloads ต่างๆ (เช่น VMs, Storages, Networks, และอื่นๆ) หรือภาพใหญ่กว่านั้นคือ เราต้องการดำเนินการเรื่องราวของ Security Operations ครับ ไม่ว่าจะด้วยเหตุผลหรือความต้องการใดก็ตาม สิ่งที่ตามคือ เราต้องการที่จะทำการตรวจสอบและค้นหาข้อมูลบางอย่างจาก Workloads ต่างๆ ที่เราได้มีการติดตั้งและใช้งานอยู่ โดยมีวัตถุประสงค์คือ อยากทราบว่า Workloads เหล่านั้นเป็นอย่างไร? มีปัญหาเรื่องของ Performance, Availability, Security, และอื่นๆ หรือไม่ 

ยกตัวอย่างเช่น ถ้าผมอยากจะทราบว่า VMs ที่รันและใช้งานอยู่ในออฟฟิศของผมนั้น จากช่วงที่ผ่านมาจนถึง ณ ตอนนี้ มีการทำงานเป็นอย่างไร มีประเด็นเรื่องของ Performance, Security, และอื่นๆ หรือไม่? จากตัวอย่างนี้ ในการทำงานจริงสิ่งที่ผมจะต้องวางแผนและดำเนินการคือ ทำการเก็บรวบรวมข้อมูลต่างๆ จาก VMs เหล่านั้นมาทำการตรวจสอบและวิเคราะห์ครับ โดยข้อมูลที่ผมไปทำการรวบรวมมาจาก VMs เหล่านั้นมีหลายประเภทครับ เช่น Logs เป็นต้น และเมื่อทำการรวบรวมข้อมูลมาเรียบร้อยแล้ว ผมต้องการที่ที่เก็บข้อมูลดังกล่าวนี้ครับ ดังนั้นในการทำงานจริงเราคงไม่ได้แค่ VM เดียวหรืออาจจะไม่ได้มีเพียงแค่ Workloads แบบนี้อย่างเดียวแน่นอน เพราะฉะนั้นข้อมูลที่ได้รวบรวมมาจาก Workloads ต่างๆ ที่อยู่ใน Environments (Hybrid และ Multi-Cloud) ขององค์กรนั้น ก็จะต้องถูกรวบรวมมาเก็บไว้ที่ที่หนึ่งแบบ Centralize ครับ คำถามคือ เราจะไปหาที่ที่เก็บข้อมูลที่ว่านี้จากไหน?

คำตอบ คือ Azure Log Analytics Workspace ครับ เพราะตัวของ Azure Log Analytics Workspace มีความสามารถในการเตรียมที่ที่สำหรับเก็บข้อมูล (Data Repository) ครับ ดังรูปด้านล่างครับ

จากรูปฝั่งซ้ายมือ Data Source1, 2, และอื่นๆ คือ ต้นทางของข้อมูลครับ ซึ่งในกรณีจากตัวอย่างนี้ คือ VMs ครับ ในการทำงานจริงมีความเป็นไปได้แน่นอนว่า Data Sources จะมาจากหลากหลายที่ทั้งนี้ขึ้นอยู่แต่ละ Environments ครับ และข้อมูลที่รวบรวมมานั้นก็จะถูกเก็บไว้ที่ตัวของ Azure Log Analytics Workspace ครับ มาถึงตรงนี้ผมจะนำเสนออีกหนึ่งความสามารถของ Azure Log Analytics Workspace คือ การค้นหาข้อมูล (Query) ครับ หมายความว่า ข้อมูลที่เราได้รวบรวมมาจาก Workloads ต่างๆ และถูกเก็บอยู่ในตัวของ Azure Log Analytics Workspace เราสามารถทำการค้นหาข้อมูลหรือทำการเขียน Query เพื่อค้นหาข้อมูลต่างๆ ตามที่เราต้องการครับ โดยภาษาที่ใช้ในการเขียน Query ข้อมูลใน Azure Log Analytics Workspace จะใช้ภาษาที่ชื่อว่า "Kusto Query Language" หรือเรียกสั้นๆ ว่า "KQL" ครับ

นอกจากนี้แล้วอีกหนึ่งความสามารถของ Azure Log Analytics Workspace คือ การทำงานร่วมกับ Services อื่นๆ ใน Microsoft Azure เช่น Azure Monitor, Microsoft Sentinel, เป็นต้นครับ

และนี่คือคอนเซปและการทำงานเบื้องต้นของ Azure Log Analytics Workspace ครับ ดังนั้นถ้าทุกท่านมีความต้องการที่จะทำการ Monitoring Workloads ต่างๆ หรือต้องการทำ Security Operations สิ่งสำคัญมากที่สุดคือ การวางแผนและออกแบบเพื่อดำเนินการสร้างและใช้งาน Azure Log Analytics Workspace ครับ เพราะยังมีอีกหลายเรื่องที่จะต้องพิจารณาก่อนที่จะทำดำเนินการสร้าง Azure Log Analytics Workspace ครับ เช่น Sources (Workloads ที่เราต้องการรวบรวมข้อมูล เช่น Logs) จากที่ใดบ้าง, ข้อมูลอะไรบ้างที่ต้องการเก็บรวบรวม, ระยะเวลาในเก็บรักษาข้อมูลเหล่านี้ (Data Retention), และอื่นๆ เพราะเรื่องเหล่านี้ที่ผมยกตัวอย่าง มีผลกับการทำงานและค่าใช้จ่ายของ Azure Log Analytics Workspace ครับ 

รายละเอียดเพิ่มเติมของ Azure Log Analytics Workspace สามารถไปที่ Link นี้ได้เลยครับผม, Log Analytics workspace overview - Azure Monitor | Microsoft Learn

และนี่คือเรื่องราวเบื้องต้นของ Azure Log Analytics Workspace ครับผม.....