Microsoft Cybersecurity ตอนที่ 4 (Microsoft Cybersecurity Reference Architectures)

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะเข้าสู่ตอนที่ 4 สำหรับเรื่องราวที่เกี่ยวข้องกับ Microsoft Cybersecurity ครับ โดยบทความนี้ผมจะพาทุกท่านไปรู้จักกับ "Microsoft Cybersecurity Reference Architectures" หรือเรียกสั้นๆ ว่า MCRA ครับ และเพื่อไม่ให้เป็นการเสียเวลา เรามาทำความรู้จักกับ MCAR กันเลยครับผม

Microsoft Cybersecurity Reference Architectures (MCRA) คืออะไร?

MCRA เป็น Model ที่อธิบายถึงความสามารถต่างๆ ของ Microsoft Cybersecurity ครับ โดย MCRA จะมาพร้อมกับเอกสาร, คำแนะนำ, Templates, และอื่นๆ ที่ท่านผู้อ่านหรือท่านที่ทำหน้าเป็น Cybersecurity Architect จะนำไปพิจารณาเพื่อทำการวางแผนและออกแบบ Cybersecurity Architecture ให้ครอบคลุม IT Environments ขององค์กร เช่น On-Premise, Hybrid, และ Multi-Cloud Environments

MCRA ถูกออกแบบมาเพื่อช่วยองค์กรทุกขนาหรือทุก Sizes ครับ ไม่ว่าจะขนาดเล็กหรือขนาดใหญ่ ที่กำลังวางแผน, ออกแบบ, และดำเนินการติดตั้งหรือ Implement Microsoft Cybersecurity หรือ Security Solutions  เพื่อทำการป้องกันและสร้างความปลอดภัยให้กับ IT Environments ตามความต้องการขององค์กร

นอกจากเอกสารและคำแนะนำต่างๆ ที่อยู่ใน MCRA แล้ว ตัวของ MCRA  ยังอธิบายถึงความสามารถต่างๆ ของ Microsoft Cybersecurity หรือ Security Solutions ในการ Integrate หรือทำงานร่วมกับ Cloud Services ต่างๆ ของ Microsoft เช่น Microsoft 365, Microsoft Azure, Cloud Service Providers อื่นๆ เช่น AWS และ GCP, และอื่นๆ 

รูปด้านล่างเป็นรูปที่แสดงถึง Reference Architectures ของ MCRA ที่เราหรือท่านที่เป็น Cybersecurity Architect จะต้องนำมาพิจารณาเพื่อใช้ในการวางแผนและออกแบบ Cybersecurity Architecture ตามที่ได้เกริ่นไว้ในตอนต้นครับ 

โดยใน Reference Architectures ดังกล่าวนี้ประกอบไปด้วย ส่วนประกอบต่างๆ ดังนี้:

1. Capabilities เป็นส่วนประกอบที่เกี่ยวข้องกับความสามารถของ MCRA ในด้านต่างๆ เช่น Security, Compliance, Identity, และอื่นๆ 

2. People เป็นส่วนประกอบที่เกี่ยวข้องกับคนหรือบุคคลากรซึ่งถือว่าเป็น Asset หนึ่งที่มีความสำคัญที่เราจะต้องดำเนินการวางแผนและออกแบบในการป้องกันและสร้างความปลอดภัย นอกจากนี้แล้วยังรวมถึงเรื่องของการทำ Access Control ในองค์กรอีกด้วย

3. Zero Trust User Access เป็นส่วนประกอบที่เกี่ยวข้องกับการนำเอา Zero Trust Model เข้ามาประยุกต์ใช้งาน โดยเฉพาะการบังคับใช้กับคน (People) ในการเข้าถึง Resources ต่างๆ 

4. Attack Chain Coverage เป็นส่วนประกอบที่เกี่ยวข้องกับการนำเอา Models ต่างๆ เช่น Defense-In-Depth มาช่วยในการวางแผนและออกแบบ

5. Security Operations เป็นส่วนประกอบที่เกี่ยวข้องกับการวางแผนและออกแบบกระบวนการของการดำเนินการ Security Operations ตั้งแต่ การรวบรวมข้อมูล (Data Collection), การค้นหา (Detection), และอื่นๆ 

6. Operational Technology เป็นส่วนประกอบที่เกี่ยวข้องกับการป้องกันและสร้างความปลอดภัยให้กับ Endpoints ในองค์กร

7. Azure Native Controls เป็นส่วนประกอบที่เกี่ยวข้องกับการพิจารณานำเอาฟีเจอร์ทางด้าน Security ของ Microsoft 365 และ Microsoft Azure เข้ามาประยุกต์ใช้งานในองค์กร

8. Multi-Cloud & Cross-Platform เป็นส่วนประกอบที่เกี่ยวข้องกับการวางแผนและออกแบบการป้องกันและสร้างความปลอดภัยให้ครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments 

9. Secure Access Service Edge (SASE) เป็นส่วนประกอบที่เกี่ยวข้องกับ Security Framework ที่ถูกออกแบบให้ครอบคลุมในส่วนของ Networking และใช้งานร่วมกับ Zero Trust โดยใน SASE ยังประกอบไปด้วยส่วนประกอบย่อยๆ อีก เช่น SD-WAN, SWG, CASB, และอื่นๆ 

รูปด้านล่างเป็นรูปที่แสดงถึงความสามารถหลักๆ ของ MCRA โดยการนำเอา Microsoft Cybersecurity หรือ Security Solutions มาใช้งานครับ

สำหรับเรื่องราวของ Microsoft Cybersecurity Reference Architecture (MCRA) ยังมีรายละเอียดอีกเยอะมากครับ สามารถไปศึกษาเพิ่มเติมจาก Link นี้ครับ, Microsoft Cybersecurity Reference Architectures - Security documentation | Microsoft Learn

มาถึงตรงนี้ท่านผู้อ่านจะเห็นว่า บทบาทหน้าที่หรือ Roles ของ Cybersecurity Architect นั้น จะต้องอาศัยความรู้ความเข้าใจคอนเซปตลอดจนเรื่องต่างๆ มากมายครับ เช่น Models (Defense-In-Depth, Zero Trust, และอื่นๆ), รวมถึงเรื่องราวของ MCRA, และอื่นๆ มาใช้ในการวางแผนและออกแบบ Cybersecurity Architecture ให้กับองค์กรครับ และทั้งหมดนี้คือเรื่องราวของ MCRA ครับผม.....

Microsoft Defender for Cloud New Feature - Direct Onboarding

      สวัสดีครับทุกท่านสำหรับบทความนี้ ผมขออนุญาตอัพเดทฟีเจอร์ใหม่ใน Microsoft Defender for Cloud ที่เพิ่ง GA หรือ General Available ไม่กี่วันที่ผ่านมาครับ โดยฟีเจอร์ดังกล่าวนี้มีชื่อว่า "Direct Onboarding" ครับ โดยฟีเจอร์ดังกล่าวถือว่าเป็นการทำงานร่วมกันระหว่าง Microsoft Defender for Cloud (MDC) กับ Microsoft Defender for Endpoint (MDE) ที่มันดีขึ้นหรือ Seamless มากกว่าเดิมครับ ขออนุญาตเล่าให้ฟังคร่าวๆ เกี่ยวกับ Microsoft Defender for Cloud หรือ MDC เผื่อท่านผู้อ่านท่านใดที่เพิ่งเข้ามาอ่านบทความนี้ จะได้ไม่งงครับ แต่ถ้าต้องการทราบเรื่องราวของ Microsoft Defender for Cloud สามารถย้อนไปอ่านบทความก่อนหน้านี้ของผมได้เลยครับ ผมเคยเขียนบทความที่อธิบายถึงเรื่องราวและความสามารถของ MDC เอาไว้ครับ 

กลับมาที่เรื่องราวเกี่ยวกับ Microsoft Defender for Cloud กันต่อครับ โดย MDC เป็น Service หนึ่งใน Microsoft Azure ครับ โดยทำหน้าที่หลัก ๆ อยู่ 2 อย่าง คือ CSPM (Cloud Security Posture Management) และอีกหน้าที่หนึ่งคือ CWPP (Cloud Workload Protection Platform) หรือบางครั้งเรียก CWP ก็ได้ครับ Microsoft ได้ทำการวางแผนและออกแบบให้ Microsoft Defender for Cloud เป็นส่วนประกอบส่วนหนึ่งที่สำคัญของ Microsoft Cybersecurity Solutions ในการที่จะเข้ามาช่วยองค์กรในการป้องกันและสร้างความปลอดภัยให้กับ IT Environment ขององค์กรโดยครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments ครับ ประมาณนี้สำหรับที่มาที่ไปของ MDC ครับ 

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

แต่ ณ ตอนนี้เรามีทางเลือกเพิ่มเติมสำหรับการ Secure และ Protect Non-Azure VM นอกเหนือจากการใช้ Azure Arc คือ การใช้ฟีเจอร์ใหม่ที่ชื่อว่า Direct Onboarding ครับ ด้วยความสามารถของฟีเจอร์ดังกล่าวนี้ทำให้เราสามารถทำการ Deploy MDE (โดยใช้ Scripting, Package, และอื่นๆ) ผ่านทาง Microsoft 365 Defender Portal โดยที่ไม่ต้องมีการติดตั้ง Agent หรือ Extensions ใด และสุดท้าย Microsoft Defender for Cloud ก็จะเข้ามาทำหน้าที่ของเค้าคือ การ Secure และ Protect VMs เหล่านั้นครับ เพราะฉะนั้นในแง่ของการบริหารจัดการสำหรับ Microsoft Defender for Cloud มีความยืดหยุ่นมากขึ้นครับ โดยเฉพาะเรื่องของ Endpoint Security ครับ รูปด้านล่างเป็นภาพของฟีเจอร์ Direct Onboarding ของ Microsoft Defender for Cloud ครับ

*เมื่อมีการ Enable เรียบร้อย จะใช้เวลาราวๆ หรือประมาณ 24 ชั่วโมงเพื่อทำการ Sync ข้อมูลเกี่ยวกับ VMs ใน Designated Subscription และส่วนของ Devices จาก Microsoft Defender for Endpoint (MDE) เป็นระยะๆ ในส่วนของ Licenses จะใช้จาก Microsoft Defender for Cloud (Defender Plan) ที่กำหนดไว้ครับ

สำหรับ Direct Onboarding ฟีเจอร์ดังกล่าวนี้ จะเกี่ยวข้องกับ  Defender Plan ใน Microsoft Defender for Cloud (Defender for Servers) ซึ่งเป็นหน้าที่นึง (CWPP) ของ MDC ตามที่ผมได้อธิบายไว้ข้างต้นครับ ดังรูปด้านล่างครับ

ในการทำงานจริงจะต้องมีการวางแผนและเตรียมความพร้อมกันก่อนนะครับ และจากประสบการณ์โดยส่วนตัวรวมถึง Best Practices ของ Microsoft ไม่แนะนำให้ท่านผู้อ่านไปทำการ Enable และกำหนดค่า Settings ต่างๆ ของ Microsoft Defender for Cloud เพื่อใช้งานทันทีนะครับ เช่นเดียวกับฟีเจอร์ Direct Onboarding ครับ รายละเอียดเพิ่มเติมเกี่ยวกับ Direct Onboarding สามารถไปที่ Link นี้ได้เลยครับ, Onboard non-Azure machines with Defender for Endpoint | Microsoft Learn

และท้้งหมดนี้คือเรื่องราวของฟีเจอร์ใหม่ใน Microsoft Defender for Cloud ที่ชื่อว่า Direct Onboarding ที่ผมอยากจะนำเสนอหรือแนะนำให้ทุกท่านได้รู้จักครับผม.....

แนะนำฟีเจอร์ใหม่ใน Microsoft Sentinel (Workspace Manager)

      สวัสดีครับทุกท่านกลับมาพบกันเหมือนเช่นเคยครับ สำหรับบทความนี้ของผมจะเป็นเรื่องราวของฟีเจอร์ใหม่ใน Microsoft Sentinel ที่มีชื่อว่า "Workspace Manager" ซึ่ง ณ วันที่ผมเขียนบทความนี้ยังเป็น Preview อยู่นะครับ  สำหรับท่านใดที่คุ้นเคยหรือใช้งาน Microsoft Sentinel กันอยู่แล้ว น่าจะทราบว่า Microsoft Sentinel เองนั้นต้องการอีกหนึ่ง Service ใน Microsoft Azure มาช่วยทำงานและ Service ที่ว่านี้ถือว่าเป็น Service ที่สำคัญมาก Service หนึ่ง สำหรับเรื่องของการทำ Security Operations โดยใช้ Solutions ของทาง Microsoft ครับ Service ที่ผมกำลังพูดถึงนี้มีชื่อว่า "Azure Log Analytics Workspace" ครับ

โดยตัวของ Azure Log Analytics Workspace เองมีความสามารถในการเก็บข้อมูล (Ingested Data) ที่ทำการรวบรวมมาจาก IT Environment ขององค์กร ข้อมูลดังกล่าวจะถูกเก็บไว้ที่นี่ครับ และนอกจากนี้แล้ว SOC หรือ Security Teams ยังสามารถทำการค้นหาหรือ Query ข้อมูลที่เก็บอยู่ใน Azure Log Analytics ได้อีกด้วย โดยใช้ Query Language ที่ชื่อว่า "Kusto Query Language" หรือเรียกสั้นๆ ว่า KQL ครับ เพราะฉะนั้นถ้าเราต้องการที่จะใช้งาน Microsoft Sentinel ทำหน้าทีเป็น SIEM และ SOAR เรื่องนึงที่ควรจะต้องนำมาพิจารณาในขั้นตอนของการวางแผนและออกแบบ คือ การเรื่องของ Azure Log Analytics Workspace ที่จะนำมาใช้งานร่วมกับ Microsoft Sentinel นั้นจะมี Azure Log Analytics จำนวนกี่ Workspaces ? ทั้งนี้ขึ้นอยู่กับความต้องการของแต่ละองค์กร แต่ที่แน่ๆ คือ เราจะต้องมีอย่างน้อย 1 Azure Log Analytics Workspace ใช้งานกับ Microsoft Sentinel แน่นอนครับ

ทำความรู้จักกับ Workspace Manager (Preview)

อย่างที่ผมเกริ่นไว้ตอนต้นของบทความนี้ว่า ผมจะพาทุกท่านมารู้จักกับฟีเจอร์ใหม่ฟีเจอร์หนึ่งใน Microsoft Sentinel ครับ นั่นก็คือฟีเจอร์นี้นั่นเองครับ โดย Workspace Manager ฟีเจอร์ดังกล่าวนี้ ถือว่าเป็นฟีเจอร์ที่น่าสนใจอย่างมากครับ โดยเฉพาะในกรณีที่องค์กรนั้นๆ มีหลายๆ Workspaces หรือหลายๆ Azure Log Analytics Workspaces ครับ 

ด้วยความสามารถของ Workspace Manager จะเข้ามาช่วย SOC หรือ Security Teams ตลอดจนผู้ที่เกี่ยวข้องในการบริหารจัดการใน Environment ที่มีหลาย Workspaces ให้มีความยืดหยุ่นและมีประสิทธิภาพมากขึ้นครับ ยกตัวอย่างเช่น สมมติว่ามีออฟฟิศของท่านผู้อ่านมีการใช้งาน Microsoft Sentinel อยู่แล้ว และมี 2 Azure Log Analytics Workspaces (สมมติชื่อว่า LAW1 กับ LAW2) เราสามารถใช้ Workspace Manager ในการเอา Content จาก LAW1 ไปใส่ที่อีก Azure Log Analytics Workspace หนึ่งซึ่งจากตัวอย่างนี้คือ LAW2 ครับ โดยมีวัตถุประสงค์คือ ต้องการบังคับหรือควบคุมให้ทุกๆ Azure Log Analytics มี Baselines เดียวกัน หรืออาจจะใช้ในอีกวัตถุประสงค์หนึ่งคือ สำหรับใน Environment ที่มีการออกแบบ Microsoft Sentinel ในรูปแบบที่เรียกว่า "MSSP" (ย่อมาจาก Managed Security Service Provider) SOC หรือ Security Teams ต้องการที่จะเอา Content บางส่วน (เช่น Analytic Rules และอื่นๆ) จาก Azure Log Analytics Workspace ของ MSSP หรือของผู้ให้บริการ (LAW1) ไปยัง Azure Log Analytics Workspace ของลูกค้า (LAW2) ครับ

โดยคอนเซปของ Workspace Manager เราจะต้องทำการกำหนดว่า Azure Log Analytics Workspace ใดจะเป็น "Central" หรือ Master จากนั้นท่านผู้อ่านสามารถทำการ Add หรือเพิ่ม Azure Log Analytics อื่นๆ เข้าไปโดยจะอยู่ใน Azure AD Tenant เดียวกันหรืออยู่คนละ Azure AD Tenants ก็ได้ครับ 

จากนั้นทำการพิจารณาและสร้าง "Workspace Manager Group" ขึ้นมา จากนั้นทำการกำหนดว่า Azure Log Analytics Workspaces ใดบ้าง จะอยู่ใน Workspace Manager Group ดังกล่าวนี้ หลังจากนั้น SOC หรือ Security Teams สามารถกำหนดว่าจะทำการส่งหรือ Push Contents (Analytic Rules, Workbooks, และอื่นๆ) ใดจาก Central Workspace ไปยัง Group (Azure Log Analytics Workspace อื่นๆ) และจากคอนเซปดังกล่าวนี้ ถ้าเรามองในแง่หรือประเด็นของประโยชน์หรือ Benefits ที่ได้จากฟีเจอร์ดังกล่าวนี้ คือ Workspace Manager ทำให้การบริหารจัดการใน Environment ที่มีหลายๆ Workspaces มีความยืดหยุ่นและจัดการได้สะดวกและง่ายมากขึ้น

รายละเอียดเพิ่มเติมเกี่ยวกับ Workspace Manager สามารถไปที่ Link นี้ได้เลยครับ, Manage multiple Microsoft Sentinel workspaces with workspace manager | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวของฟีเจอร์ใหม่ใน Microsoft Sentinel ที่มีชื่อว่า Workspace Manager ที่ผมอยากแนะนำให้ทุกท่านรู้จักครับผม.....

รู้จักกับ Microsoft Defender Threat Intelligence

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Service ใหม่ใน Microsoft Defender Family ครับ โดย Service นี้มีชื่อว่า "Microsoft Defender Threat Intelligence" หรือเรียกสั้นๆ ว่า MDTI ครับ และก่อนที่จะพาทุกท่านเข้าสู่เรื่องราวของ Microsoft Defender Threat Intelligence ขออนุญาตอธิบายคำว่า "Threat Intelligence" หรือเรียกสั้นๆ ว่า TI ก่อนครับ โดย TI หรือจะมีอีกคำหนึ่งที่คล้ายกันคือ Open Source Intelligence (OSINT) ครับ คือ กระบวนการที่ทำการรวบรวมข้อมูลมาเพื่อมาทำประมวลผล, วิเคราะห์, เพื่อทำความเข้าใจถึง Threat Actors, Behaviors, และอื่นๆ โดยองค์กรสามารถใช้ TI เข้ามาช่วยในการสร้างความปลอดภัยให้กับ IT Environments ขององค์กรครับ

Microsoft Defender Threat Intelligence คืออะไร?

MDTI เป็น Service ที่อยู่ใน Microsoft Defender Family ครับ ก่อนหน้านี้ก็จะมี Microsoft 365 Defender, Microsoft Defender for Cloud, และอื่นๆ ครับ โดย MDTI จะเป็น Service ทำหน้าที่เป็น TI Solution (โดย Microsoft ใช้เทคนิคจาก RiskIQ ใส่เข้ามาใน MDTI รวมถึงมีการนำเอาเทคโนโลยี AI และ Machine Learning เข้ามาใช้งานใน MDTI อีกด้วย) ที่จะมาช่วยองค์กรให้รู้จักตลอดจนทำการป้องกันภัยคุกคามต่างๆ (Threats) ซึ่งช่วงที่ผ่านมาจนถึงปัจจุบัน มีการปรับเปลี่ยนและพัฒนาอยู่ตลอดเวลา เพื่อที่จะหาหนทางหรือช่องโหว่ในการจู่โจมไปยังเป้าหมาย (เช่น ระบบ IT ขององค์กร)  โดยองค์กรสามารถใช้ MDTI เพื่อเข้าถึงข้อมูลและ Signals ต่างๆ แบบ Real-Time เพื่อใช้ในการทำ Hunting ภายในองค์กร สำหรับการใช้งาน MDTI เราสามารถใช้งาน MDTI ได้หลากหลายรูปแบบ เช่น Standalone หรือจะเป็นใช้ในรูปแบบที่ไป Integrate ทำงานร่วมกับ Services ใน Microsoft Defender Family เช่น Microsoft 365 Defender, Microsoft Defender for Cloud, Microsoft Sentinel, และอื่นๆ

และทุกๆ วันตัวของ MDTI จะมีการรวบรวมข้อมูลต่างๆ จาก Sources (เช่น RiskIQ, Microsoft Threat Intelligence Center (MSTIC), และอื่นๆ) ผ่านทาง Internet เพื่อช่วย SOC หรือ Security Teams ในการค้นหา, ทำความเข้าใจกับ Threat Actors, Attack Techniques, และอื่นๆ โดยสามารถเข้าถึงข้อมูลดังกล่าวนั้นใน 2 แบบ คือ ไม่มีค่าใช้จ่าย (Defender TI Community มีข้อจำกัด) กับเสียค่าใช้จ่าย (Defender TI Premium) ครับ

รูปด้านล่างคือ Portal ของ Microsoft Defender Threat Intelligence (MDTI) ครับ

และใน Portal ดังกล่าวนี้ Security หรือ SOC Teams สามารถทำการค้นหาข้อมูลต่างๆ เช่น ฟีเจอร์ใหม่ๆ, Incident Response, Hunting, และอื่นๆ  นอกจากนี้แล้ว MDTI ยังมีบทความต่างๆ มานำเสนอให้กับ Security หรือ SOC Teams ได้ศึกษาและเรียนรู้ข้อมูลต่างๆ เช่น Threat Actors, Attacks, Vulnerabilities, และอื่นๆ จากรูปด้านล่าง ผมได้ลองคลิ๊กเลือก TI Article ใน MDTI 

TI Article ดังกล่าวมาพร้อมกับข้อมูลต่างๆ มากมาย ตามที่อธิบายไว้ข้างต้นครับ โดย เริ่มตั้งแต่ Article Descriptions, Public Indicators, Defender TI Indicators, และอื่นๆ ข้อมูลต่างๆ จะเกี่ยวข้องกับ Licenses การใช้งาน MDTI ด้วยครับ ถ้าเป็นแบบไม่มีค่าใช้จ่ายหรือฟรี ก็จะมีข้อมูลจำกัดครับ

รายละเอียดเพิ่มเติมเกี่ยวกับ Microsoft Defender Threat Intelligence หรือ MDTI สามารถไปที่ Link นี้ได้เลยครับ, What is Microsoft Defender Threat Intelligence (Defender TI)? | Microsoft Learn

และนี่คือเรื่องราวเบื้องต้นของ Microsoft Defender Threat Intelligence, ที่ผมอยากนำเสนอให้ทุกท่านรู้จักครับผม.....

รู้จักกับ Microsoft Defender EASM (External Attack Surface Management)

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะเป็นบทความเกี่ยวกับ Product ใหม่ที่อยู่ภายใต้ Microsoft Defender Family ครับ โดย Product นี้มีชื่อว่า "Microsoft Defender EASM (External Attack Surface Management" ซึ่งขอเรียกสั้นๆ ว่า EASM นะครับ ผมเชื่อว่าท่านผู้อ่านหลายท่านน่าจะคุ้นเคยและรู้จักสมาชิกใน Microsoft Defender Family มาบ้าง เช่น Microsoft Defender for Cloud ซึ่งเป็น Product ที่ให้บริการเป็น Service หนึ่งใน Microsoft Azure โดย Microsoft Defender for Cloud จะทำหน้าที่หลักๆ คือ Cloud Security Posture Management (CSPM) และ Cloud Workload Protection Platform (CWPP) เพื่อช่วยป้องกัน IT Environment ขององค์กร โดยครอบคลุมทั้ง Hybrid และ Multi-Cloud สำหรับท่านผู้อ่านท่านใดยังไม่รู้จัก Microsoft Defender for Cloud ผมแนะนำให้ทุกท่านลองย้อนไปหาอ่านบทความก่อนหน้านี้ของผมครับ หรือจะไปที่ช่อง YouTube ของผมก็ได้ครับ, Wisit Thongphoo - YouTube

ก่อนที่จะพาทุกท่านไปทำความรู้จักกับ Microsoft Defender EASM กัน ผมอยากให้ทุกท่านลองนึกภาพตามผมดูนะครับว่า ในช่วงที่ผ่านมาหลายๆ องค์กรรวมถึงองค์กรที่ท่านผู้อ่านทำงานอยู่นั้น ได้มีการนำเอา Cloud Computing Technology เข้ามาประยุกต์ใช้งาน ส่งผลทำให้เกิดความเปลี่ยนแปลงเกิดขึ้นหลายอย่างในองค์กร ตั้งแต่ Infrastructure, Identity, Endpoint, และอื่นๆ การเปลี่ยนแปลงหนึ่งที่เห็นได้ชัดมากที่สุด คือ Resources หรือ Assets ต่างๆ ขององค์มีการกรกระจายอยู่ใน Hybrid หรือ Multi-Cloud Environment และสิ่งหนึ่งที่ทุกๆ องค์กรจะต้องวางแผนและดำเนินการ คือ เรื่องของความปลอดภัยหรือ Security  ตลอดช่วงเวลาที่ผ่านมาหลายองค์กรทำการทุ่มเทและใช้เวลาในการวางแผนเพื่อดำเนินการเรื่องความปลอดภัยให้กับ Resources หรือ Assets ต่างๆ ที่อยู่ภายใน (On-Premise) และภายนอกองค์กร (On Cloud) ซะเป็นส่วนใหญ่ โดยมีวัตถุประสงค์คือ ลดความเสี่ยงที่จะถูกโจมตีจากภัยคุกคามต่างๆ และ Attackers 

แต่การที่เราจะทำการวางแผนเพื่อดำเนินการป้องกัน Resources หรือ Assets ต่างๆ นั้น เราจำเป็นต้องทราบก่อนใช่มั๊ยครับ ว่าสิ่งที่เราหรือองค์กรจะทำการป้องกันคือ อะไรและอยู่ตรงไหนบ้าง เพื่อจะได้ทำการป้องกันได้อย่างถูกต้องและมีประสิทธิภาพ แต่ในความเป็นจริงแล้ว อาจจะยังมีบาง Resources หรือ Assets ที่องค์กรอาจจะยังไม่ทราบและไม่ได้ทำการป้องกัน ยกตัวอย่างเช่น พวก Resources หรือ Assets ที่เรียกว่า "Internet-Facing Assets" ครับ เพราะ Assets ดังกล่าวนี้อาจจะก่อให้เกิดช่องทางหรือช่องโหว่ที่ทำให้เกิดความสุ่มเสี่ยงต่อความไม่ปลอดภัยกับองค์กรครับ จากประเด็นดังกล่าวนี้ ผมอยากจะให้ท่านผู้อ่านทุกท่านเห็นว่า ในแต่ละองค์กรอาจจะมีจุดหรือ Assets ที่เรียกว่า Internet-Facing Assets อยู่ แต่องค์กรอาจจะไม่ทราบ, มองไม่เห็น, หรือทราบก็ได้ครับ แต่เข้าใจว่าไม่น่าจะเกิดความสุ่มเสี่ยงใดๆ แต่ในความเป็นจริงแล้วไม่ได้เป็นเช่นนั้นครับ

เนื่องจาก Internet-Facing Assets เหล่านี้ เช่น Domain Names, SSL Certificates, IP Addresses, Hostnames, และอื่นๆ ในช่วงที่ผ่านมาหลายองค์กรมีการใช้งานเพื่อเป็นช่องทางการติดต่อสื่อสารระหว่างภายในและภายนอกองค์กร แต่ช่องทางของ Internet-Facing Assets เหล่านี้อาจจะมาพร้อมกับช่องทางหรือช่องโหว่ที่ภัยคุกคามหรือ Attackers ใช้ในการ Access เข้ามา (Attack Vectors) ใน Environment ขององค์กรก็เป็นได้ครับ นอกจากนี้แล้วบาง Internet-Facing Assets ถูกบริหารจัดการจากภายนอก (3rd Party Vendors ที่องค์กรใช้บริการอยู่) เพราะฉะนั้นองค์กรจะดำเนินการอย่างไร ที่จะป้องกันและปิดช่องทางหรือช่องโหว่ที่มาจาก Internet-Facing Assets เหล่านี้ เพราะเป็นสิ่งที่อาจจะก่อให้เกิดความสุ่มเสี่ยงต่อความไม่ปลอดภัยกับองค์กร 

EASM จึงเข้ามาช่วยองค์กรในการที่จะจัดการดูแล Internet-Facing Assets ที่อยู่ในองค์กร และช่วยองค์กรในการป้องกันช่องทางหรือช่องโหว่ที่อาจจะเกิดขึ้น ซึ่งจะทำให้เกิดความสุ่มเสี่ยงต่อความปลอดภัยขององค์กรครับ และจากประเด็นนี้เองจึงเป็นที่มาของบทความนี้ที่ผมอยากจะนำเสนอ Microsoft Defender EASM มาให้ทุกท่านรู้จักครับ

Microsoft Defender EASM คืออะไร?

เป็น Service ที่ทาง Microsoft Acquired มาจาก RiskIQ โดย Microsoft Defender EASM จะเข้ามาช่วยองค์กรค้นหา (Discover), จัดทำ Inventory, และป้องกัน Resources หรือ Assets (Internet-Facing) ที่ได้อธิบายไว้ก่อนหน้านี้ครับ โดยเริ่มจากการ Discover และจัดทำ Inventory ของ Internet-Facing Assets ต่างๆ ขององค์กร แล้วทำการตรวจสอบดูว่า Assets ใดที่อาจจะก่อให้เกิดช่องโหว่เพื่อเป็นช่องทางที่ Attackers อาจจะลอบเข้ามา เพื่อทำให้ Security หรือ SOC Teams ขององค์กรมองเห็นภาพรวมของ Resources หรือ Assets (Internet-Facing) และจะได้ดำเนินการป้องกันไม่ให้ภัยคุกคามตลอดจนความเสี่ยงต่างๆ เกิดขึ้นในองค์กร 

โดย Microsoft Defender EASM จะดำเนินการกับ Internet-Facing Assets ดังนี้:

- Domains

- Hostnames

- Web Pages

- IP Addresses

- SSL Certificates

- อื่นๆ

ณ เวลาที่ผมเขียนบทความนี้ Microsoft Defender EASM ยังไม่เปิดให้บริการทุก Azure Regions นะครับ มี Azure Regions ดังต่อไปนี้เท่านั้นครับ

- southcentralus

- eastus

- australiaeast

- westus3

- swedencentral

- eastasia

- japaneast

รายละเอียดเพิ่มเติมเกี่ยวกับ Microsoft Defender EASM สามารถไปที่ Link นี้ได้เลยครับ, Overview | Microsoft Learn

ดังนั้นถ้าองค์กรได้นำเอา Microsoft Defender EASM มาทำงานร่วมกับ Services อื่นๆ ใน Microsoft Defender Family เช่น Microsoft Defender for Cloud และอื่นๆ ส่งผลทำให้ภาพรวมเรื่องของการป้องกันมีประสิทธิภาพ, ครอบคลุมและปลอดภัยมากขึ้น อีกทั้งยังช่วยให้ Security หรือ SOC Teams มองเห็นและเข้าใจภาพรวมของ Resources หรือ Assets ต่างๆ ที่กระจายอยู่ในองค์กร (Hybrid และ Multi-Cloud Environment) มากขึ้นทำให้เกิดความยืดหยุ่นในการบริหารจัดการดูแลมากขึ้น และทั้งหมดนี้คือภาพรวมของ Microsoft Defender EASM ที่ผมนำมาให้ทุกท่านได้รู้จักครับผม....

Microsoft Cybersecurity ตอนที่ 3 (Zero Trust Model)

     สวัสดีครับทุกท่าน สำหรับบทความนี้ จะเป็นตอนที่ 3 ของ Microsoft Cybersecurity ครับ และสำหรับบทความนี้ผมจะพาทุกท่านมาทำความรู้จักกับอีก 1 Model ที่มีความสำคัญสำหรับ Microsoft Cybersecurity ครับ Model ที่ว่านี้มีชื่อว่า "Zero Trust Model" ครับ และเพื่อไม่ให้เป็นการเสียเวลา เรามาทำความรู้จักกับ Zero Trust กันเลยครับ

Zero Trust Model คืออะไร ?

เป็น Model ที่เราสามารถนำเอาไปใช้ในวางแผนและออกแบบ Cybersecurity ในองค์กรครับ ซึ่ง ณ ปัจจุบันหลายๆ องค์กรได้มีการนำเอา Cloud Computing Technology มาประยุกต์หรือ Adopt ใช้งาน ทำให้เกิดการเปลี่ยนแปลงเกิดขึ้นมากมายในองค์กร เช่น Infrastructure, Endpoint, Identity, และอื่นๆ ตลอดจนการจัดการและควบคุมการเข้าถึง Resources ต่างๆ ขององค์กร ซึ่ง ณ วันนี้ไม่ได้อยู่เพียงแค่ใน On-Premise ที่เดียวอีกต่อไป ดังนั้นสิ่งหนึ่งที่องค์กรจะต้องทำการวางแผนเพื่อเตรียมความพร้อมนั่นก็คือ เรื่องของ Security หรือความปลอดภัยนั่นเองครับ จากประเด็นดังกล่าวนี้ทำให้หลายๆ องค์กร ไม่ทราบว่าจะเริ่มหรือจะดำเนินการอย่างไร เพื่อทำให้ Environment ขององค์กรดังกล่าวนั้นมีความปลอดภัยมากขึ้น และแน่นอนคือลดความเสี่ยงที่จะถูกโจมตีจากภัยคุกคามต่างๆ 

Zero Trust Model ถูกนำมาเกี่ยวข้องกับประเด็นที่ผมได้เกริ่นไว้ข้างต้น เพราะ Zero Trust จะถูกนำเอามาเป็น Security Strategy สำหรับองค์กรที่กำลังวางแผนเพื่อดำเนินการเรื่องของความปลอดภัยครับ และต้องบอกทุกท่านไว้ก่อนเลยครับว่า Zero Trust ไม่ใช่เป็น Product หรือ Service ที่เราซื้อมาติดตั้งใช้งานนะครับ อย่างที่ได้อธิบายไปก่อนหน้านี้ว่า Zero Trust Model ที่จะเข้ามาช่วยกำหนด Security Strategy เพื่อให้ทีม Security หรือ Cybersecurity Team นำเอาไปประยุกต์ใช้ในการ Designing และ Implementing Microsoft Security Solution ครับ

Zero Trust Model Principles

จะมีหลักหรือกฎเกณฑ์อยู่ด้วยกัน 3 ข้อครับ

1. Verify Explicitly, จะต้องมีการดำเนินการในส่วนของ Authentication และ Authorization อีกครั้ง เมื่อมีการเปลี่ยนแปลงเกิดขึ้นกับ User หรือ Device เช่น เมื่อมีการเปลี่ยน Location, Compliance, และอื่นๆ เกิดขึ้น เพราะตัวอย่างดังกล่าวนี้ อาจเป็นสิ่งผิดปรกติที่เกิดจากภัยคุกคามที่จะจู่โจมหรือ Attack เข้ามายังองค์กรก็มีความเป็นไปได้ครับ

2. Use Least Privilege Access, วางแผนและพิจารณาเรื่องของจัดการและควบคุม (Access Control) การเข้าถึง Resources ต่างๆ องค์กร เช่น สิทธิ์ที่ผู้ดูแลระบบหรือผู้เกี่ยวข้องจะทำการ Assign ให้กับผู้ใช้งานองค์กรนั้น ควรจะพิจารณา Assign สิทธิ์เท่าที่จำเป็นต่อการใช้งาน ไม่ควรให้สิทธิ์มากเกินกว่าความจำเป็น ตลอดจนสิทธิ์ที่จะทำการ Assign ให้นั้นจะให้กับผู้ใช้งานแบบถาวรหรือเพียงแค่ช่วงระยะเวลาหนึ่งเท่านั้น เพราะสิ่งเหล่านี้จะเกี่ยวข้องกับการเข้าถึง Applications และ Data ซึ่งถือว่าเป็นสิ่งสำคัญขององค์กรที่จะต้องทำการป้องกัน

3. Assume Breach, วางแผนพิจารณานำเอา Security Strategy และ Solution เข้ามาช่วยในการตรวจสอบ, ค้นหา, ป้องกัน, และอื่นๆ Resources และ Environments (ครอบคลุมทั้ง Hybrid และ Multi-Cloud Environment) ขององค์กร สิ่งหนึ่งที่จะองค์กรจะต้องคิดและตระหนักอยู่เสมอ คือ ระบบต่างๆ ตลอดจน Environment ขององค์กรนั้นๆ มีโอกาสที่จะถูกโจมตีตลอดเวลา ดังนั้นองค์กรจะต้องมีวางแผนและออกแบบ Security Strategy เพื่อที่จะได้ดำเนินการติดตั้ง Security Solution เพื่อมาทำการป้องกันภัยคุกคามต่างๆ

Zero Trust Pillars/Components

ภาพรวมและส่วนประกอบหลักๆ ของ Zero Trust Model  ประกอบไปด้วย 6 ส่วนหรือ Pillars ที่เราจะต้องนำมาวางแผนและออกแบบให้ครอบคลุมครบถ้วน โดยมีรายละเอียดดังนี้ครับ

1. Identity  เป็นส่วนแรกหรือ Pillar แรกนี้ถือว่าเป็นส่วนที่สำคัญสำหรับการวางแผนและออกแบบ Security Strategy และ Solution ครับ เพราะ Identity ถือว่าเป็น เป้าหมายแรกที่ Attackers โฟกัสครับ ยกตัวอย่างของ Identity เช่น User Accounts ใน Active Directory Domain Service (AD DS), User Accounts ใน Azure Active Directory (Azure AD) ดังนั้นองค์กรจะต้องวางแผนและออกแบบว่าจะจัดการและป้องกัน Identity ขององค์กรอย่างไร? 

2. Endpoints เป็นอีกส่วนที่องค์กรจะต้องวางแผนและออกแบบการจัดการ, ควบคุม, และ ป้องกัน Endpoint ซึ่งจะเกี่ยวข้องกับ Devices (Corporate และ BYOD Devices) ต่างๆ ของผู้ใช้งานในองค์กร อีกทั้งยังมีความหลากหลายของ Platforms ต่างๆ ของ Devices ด้วย เช่น Windows, iOS, และอื่นๆ เป็นต้น

3. Applications เป็นส่วนที่เกี่ยวข้องกับช่องทางที่เปิดโอกาสให้ผู้ใช้งานเข้าถึง Resources ต่างๆ ขององค์กร เพราะฉะนั้นองค์กรจะต้องมีการวางแผนจัดการตลอดจนการป้องกัน Applications ด้วย เช่น การป้องกันการเข้าถึง Applications, การนำเอา Applications มาทำงานร่วมกับ Azure Active Directory, เป็นต้น

4. Networks เป็นส่วนที่องค์กรจะต้องวางแผนและออกแบบเพื่อป้องกัน Network (ยกตัวอย่าง เช่น Azure Virtual Networks ใน Microsoft Azure) เพราะจะเป็นส่วนที่เกี่ยวข้องกับการเข้าถึง Resources ต่างๆ ขององค์กร ตัวอย่างของการป้องกัน Azure Virtual Networks เช่น Azure DDos Protection, Azure Firewall, และอื่นๆ 

5. Infrastructure เป็นส่วนที่จะต้องทำการวางแผนและออกแบบเพื่อป้องกัน Infrastructure เพราะเป็นส่วนที่จะมีการ Hosting Resources ต่างๆ เช่น Virtual Machines และ Containers  ยกตัวอย่างการป้องกัน เช่น การ Hardening OS, Bastion Hosts, และอื่นๆ 

6. Data เป็นส่วนที่สำคัญที่สุด ดังนั้นองค์กรจะต้องมีการวางแผนออกแบบการป้องกัน Data หรือข้อมูล ยกตัวอย่าง เช่น Key Management, Data Loss Prevention, และอื่นๆ 

ส่วนประกอบหรือ Pillars ทั้งหมดที่ผมได้อธิบายไปข้างต้น คือ สิ่งที่ท่านผู้อ่านทุกท่านจะต้องทำความเข้าใจเพื่อจะทำการวางแผนและออกแบบ Security Strategy และ Solution เพื่อป้องกันและสร้างความปลอดภัยให้กับองค์กรครับ และต้องบอกกับทุกท่านว่า Zero Trust Model เป็นเพียงแค่ Model หนึ่งเท่านั้นที่เราจะนำเอามาประยุกต์ใช้นะครับ ในการออกแบบจริง จะต้องมีการนำเอาคอนเซปตลอดจน Models อื่นๆ เข้ามาช่วยและประยุกต์ใช้งานร่วมกันครับ

และทั้งหมดนี้ Zero Trust Model ที่ผมนำมาฝากทุกท่านครับผม.....

รู้จักกับ Azure Lighthouse

สวัสดีครับทุกท่านสำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Service หนึ่งใน Microsoft Azure ที่มีชื่อว่า "Azure Lighthouse" ครับ 

Azure Lighthouse คืออะไร?

เป็น Service ที่ทำให้เราสามารถทำการบริหารจัดการในลักษณะของ Multiple Tenants หรือ Cross-Tenants คือ กรณีที่องค์กรมีหลายๆ Tenants หรือองค์กรที่เป็น Service Provider แล้วต้องการเข้าไปบริหารจัดการใน Tenants ของลูกค้า ซึ่งโดยปรกติแล้วการบริหารจัดการในลักษณะดังกล่าวนั้น ค่อนข้างยุ่งยากและขาดความยืดหยุ่น เพราะเนื่องจากแต่ละ Tenants แยกการบริหารจัดการออกจากกันครับ  

*Azure AD Tenant หรือ Tenant เกิดจากองค์กรนั้นๆ ได้นำเอา Cloud Services ของ Microsoft  เช่น Microsoft 365, Microsoft Azure, เป็นต้น โดยการซื้อ Subscription ของ Cloud Services ของ Microsoft แล้วนำเอา Subscription ดังกล่าวมาทำการ Activate ใช้งานเป็น Subscription แรกในองค์กร ซึ่งส่งผลทำให้เกิดสิ่งที่เรียกว่า Azure AD Tenant หรือ Tenant นั่นเอง โดย Azure AD Tenant จะสะท้อนให้เห็นถึงขอบเขตของ Resources ต่างๆ ขององค์กรนั้นๆ  ซึ่งโดยปรกติแล้วองค์กรส่วนใหญ่จะมี Azure AD Tenant แค่ 1 Tenant แต่บางกรณีหรือบางครั้งอาจจะมีมากกว่า 1 ก็ได้ทั้งนี้ขึ้นอยู่กับความต้องการของแต่ละองค์กร

โดย Azure Lighthouse จะทำหน้าที่เป็น Control Pane หรือส่วนที่เข้ามาช่วยในการบริหารจัดการต่างๆ เช่น IT Servie Management, Monitoring, Security Operations, และอื่นๆ ใน Tenants ของลูกค้าหรือ Tenants อื่นๆ ที่องค์กรต้องการ โดยองค์กรสามารถทำการให้บริการ Secure Managed Services  เพื่อช่วยลูกค้าในการบริหารจัดการ สำหรับในฝั่งของลูกค้าหรืออีก Tenanst หนึ่งก็ยังคงสามารถบริหารจัดการได้เหมือนเช่นเดิม 

โดย Azure Lighthouse ถูกออกแบบมาให้รองรับกับ Scenarios ต่างๆ เช่น

- Service Providers คือ Scenario ที่ลูกค้าจ่ายค่าบริการให้กับบริษัทที่เป็น Service Provider ให้เข้ามาช่วยใการบริหารจัดการ Resources ผ่านทาง Services (เช่น การ Monitoring, Governance, และอื่นๆ) ต่างๆ ใน Tenants ของลูกค้า ซึ่งทำให้ Service Providers สามารถสร้างและให้บริการ Managed Services ต่างๆ ให้กับลูกค้าได้อย่างมีประสิทธิภาพและมีความยืดหยุ่นมากขึ้น 

- Application Providers คือ Scenario ที่บริษัทนั้นๆ ให้บริการ Applications (ที่อยู่ใน Microsoft Azure)  ผ่านทาง Azure Marketplace และให้องค์กรหรือลูกค้าที่สนใจทำการ Deploy Applications ดังกล่าวใน Subscriptions ที่อยู่ภายใน Tenants ของตัวเอง

- Multi-Tenant คือ Scenario ที่องค์กรนั้นๆ มีหลายๆ Tenants แล้วองค์กรดังกล่าวต้องการที่จะเข้าไปช่วยบริหารจัดการใน Tenants นั้นๆ ซึ่งอยู่ในองค์กรเดียวกัน โดยปรกติแล้วถ้าเป็น Scenario นี้เราจะใช้วิธีการ Switch Azure AD Tenants ซึ่งถ้าใช้ Azure Lighthouse เราไม่ต้องการทำการ Swtich ครับ

ความสามารถของ Azure Lighthouse

1. Azure Delegated Resource Management  สามารถทำการบริหารจัดการ Subscriptions และ Azure Resources ต่างๆ ของลูกค้าหรือของ Tenants อื่น โดยไม่ต้องการมีการ Switch 

2. New Azure Portal Experience สามารถดูหรือ View ข้อมูลต่างๆ ของ Tentants อื่นๆ ในการบริหารจัดการซึ่งจะอยู่ใน "My Customers" Page ภายใน Azure Portal  

นอกจากนี้แล้วยังมีส่วนที่เรียกว่า " Service Providers" Page เพื่ออนุญาตให้ลูกค้าสามารถทำการดูข้อมูลต่างๆ ในการจัดการ Service Providers ในการเข้าถึง Resources ต่างๆ ตลอดจนการตรวจสอบ Activity ต่างๆ ของ Service Providers ได้อีกด้วย

3. Azure Resource Manager (ARM) Templates สามารถใช้ ARM Templates กับ Tenants ต่างๆ (Cross-Tenant Management) รายละเอียดเพิ่มเติม Onboard a customer to Azure Lighthouse - Azure Lighthouse | Microsoft Learn และ Azure Lighthouse samples and templates - Azure Lighthouse | Microsoft Learn

4. Managed Service Offers in Azure Marketplace สามารถ Provide Services ต่างๆ ที่ต้องการให้กับลูกค้า (Tenants อื่นๆ) แบบ Public หรือ Private  รายละเอียดเพิ่มเติม Managed Service offers in Azure Marketplace - Azure Lighthouse | Microsoft Learn

ในเรื่องของค่าใช้จ่ายของ Azure Lighthouse นั้น ไม่มีครับ เราสามารถนำเอา Azure Lighthouse เข้ามาใช้งานได้เลยครับ สำหรับท่านใดที่สนใจเรื่องราวของ Azure Lighthouse สามารถไปที่ Link นี้ได้เลยครับ Azure Lighthouse Documentation | Microsoft Learn

และทั้งหมดนี้คือ Introduction ของ Azure Lighthouse ครับผม.....