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

ทำความรู้จักกับ Cloud-Native Application Protection Platform (CNAPP)

      

สวัสดีครับทุกท่าน สำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Cloud-Native Application Protection Platform หรือเรียกกันสั้นๆ ว่า CNAPP กันครับ โดยบทความนี้ผมจะนำเสนอคอนเซปและเรื่องราวของ CNAPP ให้ทุกท่านได้ทราบกันครับ ก่อนอื่นเลยต้องบอกว่า CNAPP จะเป็น Next Step หรือขั้นตอนต่อไปสำหรับการวางแผนเพื่อดำเนินการ "Multi-Cloud Security" ให้กับองค์กรครับ และเพื่อไม่ให้เป็นการเสียเวลาเรามาเริ่มกันเลยครับผม

Cloud-Native Application Protection Platform (CNAPP) คืออะไร?

สำหรับคอนเซปของ CNAPP นั้น, CNAPP คือ Unifies Security และ Compliance ครับ โดยเราสามารถใช้ CNAPP ในการป้องกัน (Prevent), ค้นหา (Detect), และโต้ตอบ (Response) หรือจัดการกับภัยคุกคามต่างๆ ที่จะจู่โจมหรือ Attack เข้ามาใน IT Environment ขององค์ครับ  โดย CNAPP ทำให้ SOC/Security Teams, DevOps Teams, ตลอดจนผู้ที่เกี่ยวข้องเห็นและเข้าใจภาพรวมของ IT Environment เพื่อทำให้เกิดการทำงานร่วมกันในการที่จะทำให้องค์กรมีความปลอดภัยและลดความเสี่ยงจากภัยคุกคามต่างๆ ครับ การที่องค์กรหรือเรานำเอา CNAPP เข้ามาประยุกต์ใช้งานในองค์กรนั้น เพื่อให้ CNAPP เข้ามาช่วยในเรื่องราวต่างๆ ดังนี้:

- เข้ามาช่วยในการตรวจสอบ, ค้นหา, และป้องกัน DevOps Pipleine ให้กับ DevOps, หรือ SOC Teams        เพื่อทำให้เกิดความมั่นใจว่า Cloud-Native Apps สามารถทำงานได้อย่างปลอดภัยตั้งแต่เริ่มต้นใช้งาน

- เข้ามาช่วยในการตรวจสอบ Security Posture IT Environment ขององค์กรโดยครอบคลุมทั้ง Hybrid และ  Multi-Cloud Environments พร้อมกับคำแนะนำ (Recommendations) ต่างๆ สำหรับให้องค์กรนำไป              พิจารณาปรับปรุงเปลี่ยนแปลงเพื่อทำให้ภาพรวมของความปลอดภัยขององค์กรมีความปลอดภัยมากขึ้น

- เข้ามาช่วยในการค้นหาและป้องกันภัยคุกคามต่างๆ ที่จะเข้ามาจู่โจมหรือ Attack โดย CNAPP จะทำการ  แจ้ง (Alerts) เพื่อให้ Security/SOC Teams ทราบและเข้าไปทำการ Response และดำเนินการต่อไป

ส่วนประกอบของ Cloud-Native Application Protection Platform (CNAPP)

ส่วนประกอบหรือ Services ต่างๆ ของ CNAPP ที่จะเข้ามาทำงานร่วมกันเพื่อช่วยป้องกัน IT Environments ให้กับองค์กรตามที่อธิบายไว้ข้างต้นครับ โดย CNAPP มาพร้อมกับส่วนประกอบหรือ Services ต่างๆ ที่จะเข้ามาทำงานร่วมกันดังนี้:

Cloud Security Posture Mangement (CSPM) ทำหน้าที่ในการตรวจสอบ, วิเคราะห์, และทำการประเมิน Security Posture ขององค์กรว่ามี Workloads หรือ Resources ใดที่มีความเสี่ยงบ้าง และหลังจากที่ CSPMดำเนินการตรวจสอบและประเมินเรียบร้อย CSPM ยังมีคำแนะนำต่างๆ เพื่อให้เราไปพิจารณาปรับปรุงเปลี่ยนแปลง Security Posture ของเราเพื่อทำให้มีความปลอดภัยมากขึ้นครับ โดย CSPM เป็น Solution ที่อยู่ใน Microsoft Defender for Cloud (MDC)

Cloud Workload Protection (CWP) ทำหน้าที่ในการค้นหาและป้องกันภัยคุกคามที่อาจจะเข้ามาโจมตี โดย CWP มีความสามารถในการค้นหาและป้องกัน Workloads หรือ Resources ต่างๆ เช่น Virtual Machines, Containers, Apps, Storages, และอื่นๆ ในกรณีที่ CWP เจอสิ่งผิดปรกติหรือสิ่งที่น่าสงสัยก็จะทำการแจ้งเตือน เพื่อให้ Security/SOC Teams สามารถเข้าดำเนินการต่อไปครับ โดย CWP นั้นถือว่าอีกหนึ่ง Solution ที่อยู่ใน Microsoft Defender for Cloud (MDC)  

DevOps Security ทำหน้าที่ในการค้นหา, ตรวจสอบ, และป้องกัน Pipelines ต่างๆ ที่ทาง Developer หรือ DevOps ได้มีการสร้างและใช้งาน ตั้งแต่ Images ที่ใช้งานและอื่นๆ เพื่อทำให้ Apps เหล่านั้นมีความปลอดภัยมากขึ้น โดยการใช้ Microsoft Defender for DevOps ซึ่งเป็นความสามารถหนึ่งของ Microsoft      Defender for Cloud (MDC)

Network Security ทำหน้าที่ในการป้องกัน Cloud Network Infrastructure (Azure Virtual Network และอื่นๆ) และ Applications จากภัยคุกคาม เช่น DDoS Attack โดยใช้ Azure Network Security Solution (ประกอบไปด้วย Services ต่างๆ ที่อยู่ใน Microsoft Azure ตามรูปด้านล่าง) ครับ

Cloud Infrastructure Entitlement Management (CIEM) ทำหน้าที่ในควบคุมการและจัดการการเข้าถึงข้อมูลหรือ Resources ต่างๆ (Permissions Management) ของผู้ใช้งานในองค์กร (Hybrid และ Multi-Cloud Environments) ยิ่งไปกว่านั้น CIEM ถือว่าเป็นส่วนประกอบที่สำคัญส่วนประกอบหนึ่งของ CNAPP เพราะจะทำให้ Security/SOC Teams เห็นภาพของการเข้าถึงข้อมูลต่างๆ จากผู้ใช้งานในองค์กรว่าเป็นอย่างไร?  มีเหตุการณ์ที่ผู้ใช้งานเข้าถึง Resources ที่ไม่ควรเข้าถึงหรือไม่ เพราะถ้าหาก Resources ดังกล่าวนั้นเป็นข้อมูลสำคัญ อาจจะส่งผลกระทบต่อองค์กรได้ นอกจากนี้แล้ว CIEM ยังเข้ามาช่วยทำให้การเข้าถึงข้อมูลขององค์กรดำเนินตาม Best Practices (Zero Trust Model) ยกตัวอย่างเช่น At Least Privilege ซึ่งเป็นกฎข้อหนึ่งของ Zero Trust Model  โดย CIEM จะอยู่ใน Microsoft Entra Permissions Management ซึ่งเป็นสมาชิกหนึ่งของ Microsoft Entra Family ครับ

และจากส่วนประกอบต่างๆ ของ CNAPP ที่ผมได้อธิบายไปข้างต้น สามารถสรุปด้วยรูปด้านล่างนี้ครับ

ท่านผู้อ่านจะเห็นว่า CNAPP  เป็น Single Platform ที่รวบรวมเอาความสามารถต่างๆ ที่เกี่ยวกับ Cloud Security และ Compliance แบบ End-to-End โดยครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments ทำให้ Security/SOC Teams ไม่ต้องไปทำการรวบรวมข้อมูลและใช้งานหลายๆ Tools ในการดำเนินการ Security Operations เหมือนแต่ก่อน ส่งผลทำให้ Security/SOC Teams สามารถบริหารจัดการรวมถึงการ Operations ได้อย่างรวดเร็วและประสิทธิภาพมากขึ้น

การใช้งาน Cloud-Native Application Protection Platform (CNAPP)

ทาง Microsoft ได้เตรียม CNAPP  ซึ่งผมได้อธิบายคอนเซปตลอดจนส่วนประกอบต่างๆ ข้างต้น เข้ามาเป็นความสามารถหนึ่งหรือ Solution หนึ่งของ Microsoft Defender for Cloud เรียบร้อยแล้วครับ โดยสามารถใช้งาน CNAPP ผ่านทาง Microsoft Defender for Cloud หรือ MDC (Single Platform) ได้เลย ทั้งนี้ MDC มีความสามารถที่จะไปทำงานร่วมกันกับ Security Services หรือ Solutions ต่างๆ (อ้างอิงจากส่วนประกอบของ CNAPP ที่อธิบายไว้ข้างต้น) ได้ เช่น Azure Network Security, Microsoft Entra, และอื่นๆ  ยกตัวอย่างของการนำเอา MDC มาทำการ Integrate กับ CIEM (Microsoft Entra Permissions Management) กับ MDC ดังรูปด้านล่าง

นอกจากนั้นแล้ว MDC ยังสามารถไปทำงานร่วมกับ Microsoft Sentinel (SIEM & SOAR Solutions) ได้อีกด้วย มาถึงตรงนี้ ท่านใดที่คุ้นเคยหรือใช้งาน MDC อยู่แล้ว จะเห็นว่า MDC จะมีความสามารถมากขึ้นเรื่อยๆ จากเดิมที่สามารถทำ CSPM และ CWP ได้อยู่แล้ว 

นอกจาก CNAPP ใน MDC แล้ว ยังมีอัพเดทเพิ่มเติมเกี่ยวกับ MDC จากงาน Microsoft Ignite ที่ผ่านมาทาง Microsoft ได้มีการเพิ่มความสามารถหรือฟีเจอร์ใหม่ๆ ให้กับ MDC อีกด้วย เช่น เรื่องของการทำ Security Compliance กับ GCP, ป้องกัน Malware Distribution ใน Storages ด้วย Malware Scanning, เป็นต้น

รายละเอียดเพิ่มเติมเกี่ยวกับ Microsoft Defender for Cloud และ CNAPP สามารถไปที่ Link นี้ได้เลยครับ, What is Microsoft Defender for Cloud? - Microsoft Defender for Cloud | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวของ CNAPP ครับผม.....

ทำความรู้จักกับ Microsoft Defender XDR

      สวัสดีครับทุกท่าน กลับมาพบกันอีกเช่นเคยครับ สำหรับบทความนี้จะเป็นเรื่องของการอัพเดทเปลี่ยนแปลงจากงาน Microsoft Ignite ที่ผ่านมาครับ โดยในงานดังกล่าวนี้มีการอัพเดทเรื่องและข้อมูลข่าวสารต่างๆ, รวมถึงมี Services หรือ Products ใหม่, ตลอดจนฟีเจอร์ใหม่ๆ มาเยอะแยะมากมายครับ แต่ในบทความนี้ผมจะโฟกัสที่เรื่องของการเปลี่ยนแปลงที่เกี่ยวข้องกับ Cybersecurity หรือ Cloud Security เรื่องหนึ่งครับ โดยเรื่องดังกล่าวนี้จะเกี่ยวข้องกับ ชุดของ Product หรือ Product Suite หนึ่งของทาง Microsoft ครับ นั่นก็คือ "Microsoft Defender XDR" ครับ และนี่คือเรื่องหรือการเปลี่ยนแปลงที่สำคัญเรื่องหนึ่งของงาน Microsoft Ignite ครั้งนี้ครับ และเพื่อไม่ให้เป็นการเสียเวลาเรามาทำความรู้จักกับ Microsoft Defender XDR กันเลยครับ

Microsoft Defender XDR คืออะไร?

คือ ชุดของ Product (Product Suite) ที่ถูกออกแบบมาสำหรับเรื่องของความปลอดภัย โดยชุด Product ดังกล่าวนี้จะช่วยป้องกัน IT Environment (เช่น Microsoft 365, Identity, Endpoint, เป็นต้น) ขององค์กรจากภัยคุกคามต่างๆ ครับ ถ้าท่านใดคุ้นเคยกับ Cybersecurity Solutions ของทาง Microsoft มาก่อนก็จะทราบว่า ทาง Microsoft มี Solutions ทางด้านนี้เยอะมากครับ มีทั้งเป็น Product/Service เดี่ยวๆ รวมถึงที่เป็น Family Products ก็มีครับ ดังรูปด้านล่างครับ

รูปด้านบนคือ Portfolio ที่เกี่ยวข้อง Security Solutions ต่างๆ ของทาง Microsoft ครับ และหนึ่งในนั้นจะมี Microsoft Defender อยู่ครับ โดย Microsoft Defender ถือว่าเป็น Family Product ที่ถูกออกแบบมาเพื่อช่วยป้องกันภัยคุกคามต่างๆ ที่จะเข้ามาโจมตีครับ ตัวอย่างของสมาชิกที่อยู่ใน Family Product ดังกล่าวนี้ (Microsoft Defender) เช่น Microsoft Defender for Cloud, Microsoft 365 Defender, และอื่นๆ ครับ แล้วมันเกี่ยวข้องอะไรกับ Microsoft Defender XDR ล่ะ????? คำตอบ คือ มันเกี่ยวข้องกันครับ ผมจึงได้เล่าที่มาที่ไปให้ทุกท่านได้ทราบก่อน ที่ว่าเกี่ยวข้องกันเพราะ Microsoft Defender for XDR คือชื่อใหม่ของ Microsoft 365 Defender ครับ!!!!!

โดย Microsoft Defender XDR (ชื่อเดิม Microsoft 365 Defender) คือ ชุดของ Product ที่ช่วยในการป้องกัน (Defense Suite) ภัยคุกคามต่างๆ โดยทำหน้าที่ต่างๆ เช่น Detection, Prevention, Investigation, และ Response จาก IT Environments ขององค์กร เช่น Identities, Emails, Endpoints, และอื่นๆ ครับ ดังรูปด้านล่างครับ

โดย Microsoft Defender XDR มาพร้อมกับ Products/Services ย่อยๆ ต่างๆ ดังนี้ครับ:

- Microsoft Defender for Office 365

  (ตรวจสอบและป้องกัน Phishing Mail, ทำการตรวจสอบ Attached Files, Links, และอื่นๆ)

- Microsoft Defender for Identity

  (ตรวจสอบและป้องกัน Identity ใน On-Premise เช่น AD DS)

- Microsoft Defender for Endpoint

  (ตรวจสอบและป้องกัน Endpoints โดยมาพร้อมกับความสามารถต่างๆ เช่น EDR, ASR, และอื่นๆ อีกทั้งยัง

  ทำงานร่วมกัน Microsoft Defender AV อีกด้วย)

- Microsoft Defender for Cloud Apps

  (ตรวจสอบและป้องกัน SaaS หรือ Cloud Apps ว่ามีเหตุการณ์หรือพฤติกรรมของผู้ใช้งานที่ผิดปรกติหรือ

  น่าสงสัย)

- Microsoft Defender Vulnerability Management

  (ตรวจสอบช่องโหว่ของ Endpoints โดยจะทำงานร่วมกับ Microsoft Defender for Endpoint)

- Microsoft Entra ID Protection (ชื่อเดิม Azure AD Identity Protection)

  (ตรวจสอบและป้องกัน Identities ของ Microsoft Entra ID)

- Microsoft Data Loss Prevention (ทำงานร่วมกับ Microsoft Purview)

- App Governance (เป็นความสามารถหนึ่งของ Microsoft Defender for Cloud Apps ในการเข้าไปจัดการ

  ควบคุมเรื่องของความปลอดภัยกับ Apps ต่างๆ ที่มา Integrated และ Registered กับ Microsoft Entra ID)

และจาก List ข้างต้นจะเห็นว่าหลายๆ Products/Services อยู่ใน Microsoft 365 Defender อยู่แล้ว และมีอีกหลาย Products/Services ที่เข้ามาอยู่ใน Microsoft Defender XDR เพิ่มเติมครับ และด้วยความสามารถต่างๆ จาก Products/Services ข้างต้น ก็จะทำงานร่วมกันโดยเราสามารถบริหารจัดการเรื่องของความปลอดภัยผ่านทาง Microsoft Defender XDR จาก Portal ที่ชื่อว่า Microsoft Defender Portal ครับ โดย Portal ดังกล่าวนี้ก็จะแสดงข้อมูลตลอดจนรายละเอียดต่างๆ ในกรณีที่ Microsoft Defender XDR ค้นหาเจอสิ่งผิดปรกติ, สิ่งที่น่าสงสัย, และอื่นๆ ที่น่าจะก่อให้เกิดความเสี่ยงหรือความไม่ปลอดภัยเกิดขึ้น ทำให้ผู้ดูแลระบบ, Security Teams, ตลอดจนผู้เกี่ยวข้อง เข้าใจและเห็นภาพรวมตลอดจนรายละเอียดต่างๆ เพื่อจะได้ดำเนินการจัดการต่อไปครับ ดังตัวอย่างตามรูปด้านล่างครับ

 

สำหรับท่านใดที่สนใจอยากจะใช้งาน Microsoft Defender XDR ก็จะต้องวางแผนสำหรับการจัดซื้อ Licenses  โดยมี Plans ต่างๆ ให้เลือกซื้อครับ ทั้งนี้ขึ้นอยู่กับความต้องการของแต่ละองค์กรครับ ตัวอย่างของ Licenses ที่สามารถใช้งาน Microsoft Defender XDR:

รายละเอียดเพิ่มเติมเรื่องของ Licenses สามารถไปที่ Link นี้ได้เลยครับ, Microsoft Defender XDR prerequisites | Microsoft Learn

เมื่อพิจารณาเรื่องของ Licenses เรียบร้อย ขั้นตอนต่อมา คือ การวางแผนเพื่อเตรียมใช้งาน Micrsoft Defender XDR ครับ รายละเอียดเพิ่มเติมสามารถไปที่ Link นี้ได้เลยครับ, Turn on Microsoft Defender XDR | Microsoft Learn

และรายละเอียดเพิ่มเติมของ Microsoft Defender XDR สามารถไปที่ Link ได้เลยครับ, What is Microsoft Defender XDR? | Microsoft Learn

และนี่คือเรื่องหนึ่งที่ผมอยากจะอัพเดทการเปลี่ยนแปลงที่เกิดขึ้นจากงาน Microsoft Ignite ที่ผ่านมาครับผม.....

Security Defaults ใน Microsoft Entra ID

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมอยากนำเสนอเรื่องราวความสามารถของ Microsoft Entra ID หรือชื่อเดิมคือ Azure Active Directory (Azure AD) ที่ผมเชื่อว่าหลายๆ ท่านน่าจะคุ้นเคยกันเป็นอย่างดี เพราะเนื่องจาก Microsoft Entra ID เป็น Service ที่มีความสามารถมาก Service หนึ่ง เพราะเป็น Service ที่จะเข้ามาช่วยองค์กรที่มีการนำเอา Cloud เข้ามาประยุกต์ใช้งาน ในส่วนของการบริหารจัดการ Identity หรือที่เราเรียกว่า Identity and Access Managment (IAM)  นั่นเองครับ  และ ณ ปัจจุบันนี้ IT Environment ขององค์กรส่วนใหญ่จะมีลักษณะเป็น Hybrid Cloud Environment (Hybrid Identity Scenario) หมายความว่า องค์กรมีการเชื่อมต่อระหว่าง On-Premise กับ Cloud เช่น Microsoft 365, Micrsoft Azure, และอื่นๆ เป็นต้น ตลอดจนมีการย้าย Workloads ต่างๆ เช่น Virtual Machines, Files & Folders, และอื่นๆ ไปไว้อยู่ใน Cloud ส่งผลทำให้การทำงานตลอดจนการใช้งานของผู้ใช้งานในองค์กรมีการเปลี่ยนแปลง ยกตัวอย่างเช่น ผู้ใช้งานสามารถเข้าถึง Resources ต่างๆ ที่อยู่ใน On-Premise และ Cloud จากที่ไหนก็ได้ ตลอดจนใช้ Endpoints/Devices Platforms ใดก็ได้ และที่สำคัญคือ ผู้ใช้งานใช้ Identity (Username และ Password) เดียวในการเข้าถึง Resources เหล่านั้น ซึ่งเราเรียกคอนเซปดังกล่าวนี้ว่า "Single Sign-On" หรือ SSO นั่นเอง 

และจากคอนเซปการทำงานดังกล่าวนี้เอง จะเห็นได้ว่าตัวของผู้ใช้งานหรือ Users ในองค์กรสามารถที่จะเข้าถึง Resources ต่างๆ ทั้งที่อยู่ใน On-Premise และ On Cloud (Microsoft 365, Microsoft Azure, SaaS Apps, และอื่นๆ) ทำให้ผ่านรวมการทำงานของผู้ใช้งานในองค์กรดังกล่าวนี้มีความยืดหยุ่นและสะดวกมากขึ้น แต่ถ้าเรามองในเรื่องของความปลอดภัยจากเรื่องราวนี้จะเห็นว่า มีความเสี่ยงมากขึ้นที่องค์กรจะโดนโจมตีหรือ Attacks จาก Attackers เพราะ Identity ถือว่าเป็น เป้าหมายหลักของ Attackers ครับ โดย Attacker จะใช้ Compromised Identity ที่ขโมยมาได้นั้น เข้าถึง Resources ต่างๆ เพราะฉะนั้นสิ่งที่องค์กรจะต้องทำการวางแผนและดำเนินการก็คือ เรื่องของความปลอดภัยนั่นเองครับ โดยเรื่องราวของ Cloud Security หรือ Cybersecurity นั้นมีรายละเอียดเยอะพอสมควรครับ แต่จุดเริ่มต้นที่องค์กรควรจะพิจารณก่อนเป็นอันดับแรกสำหรับเรื่องของ Cloud Security คือ การป้องกัน Identity ขององค์กรจากภัยคุกคามต่างๆ ครับ

โดยในบทความตอนนี้ผมจึงอยากเรื่องราวเกี่ยวกับการป้องกัน Identity หรือเรียกว่าการ Securing และ Protecting Identity ครับ โดยเริ่มด้วยสิ่งที่เรียกว่า "Security Defaults" ครับ และเพื่อไม่ให้เป็นการเสียเวลาผมจะพาทุกท่านไปทำความรู้จักกับ Security Defaults กันเลยครับ

Security Defaults คืออะไร ?

Security Defaults จะเข้ามาช่วยองค์กรในการป้องกันภัยคุกคามหรือความเสี่ยงที่เกี่ยวข้องกับ Identity (Identity-Related Attacks) ยกตัวอย่างวิธีการหรือเทคนิคที่ Attackers จะใช้ในการโจมตี Identity ขององค์กร เช่น Brute Force Attack, Password Spray, Phishing, และอื่นๆ  สำหรับตัวของ Security Defaults คือ ค่า Settings ต่างๆ ที่เกี่ยวข้องกับเรื่องของความปลอดภัยที่ทาง Microsoft ได้เตรียมเอาไว้ (Preconfigured Security Settings) เอาไว้ให้กับองค์กร เนื่องจากการกำหนดค่า Settings ที่เกี่ยวข้องกับ Security ดังกล่าวนี้มีความซับซ้อนพอสมควร เพราะฉะนั้นทาง Microsoft จึงได้เตรียม Security Defaults เข้ามาช่วยเรื่องของความปลอดภัยให้กับองค์กรนั่นเองครับ  ยกตัวอย่างค่า Settings หนึ่งใน Security Defaults คือ Multi-Factor Authentication (MFA) รวมถึงการ Block Legacy Authentication จะช่วยหยุดหรือยับยั้งภัยคุกคามที่เกี่ยวข้องกับ Identity ทั่วไป (Common Identity-Related Attacks) ได้มากถึง 99.9%  และวัตถุประสงค์ที่ Microsoft ได้เตรียม Security Defaults เอาไว้ให้กับองค์กรนั้น เพื่อทำให้มั่นใจว่าทุกองค์กรได้มีการกำหนดค่า Settings ต่างๆ ที่เกี่ยวข้องกับความปลอดภัยเบื้องต้นแล้ว และทำสำคัญคือตัวของ Security Defaults ดังกล่าวนี้องค์กรสามารถ Enable หรือดำเนินการใช้งานได้โดยไม่มีค่าใช้จ่ายครับ (สามารถใช้งานได้ใน Microsoft Entra ID ที่เป็น Free Edition หรือชื่อเดิมคือ Azure AD Free Edition)

ดังนั้นหากเรายังไม่รู้ว่าจะต้องวางแผนและดำเนินการเรื่องราวของ Security อย่างไร (อย่างที่ได้เกริ่นไว้ข้างต้นว่าเรื่องของ Security เป็นเรื่องที่มีรายละเอียดเยอะพอสมควรครับ) ทาง Microsoft จึงได้เตรียม Security Defaults ให้กับทุกท่านตลอดจนองค์กรต่างๆ ให้ดำเนินการเรื่องของความปลอดภัยเบื้องต้นไปก่อนครับ

โดย Security Defaults จะควบคุมค่า Settings ที่เกี่ยวข้องต่างๆ ดังนี้

- Require ผู้ใช้งานทุกคนจะต้องทำการ Register Multi-Factor Authentication (MFA)

- Require ผู้ดูแลระบบ (Administrator) Sign-In ในรูปแบบ Multi-Factor Authentication (MFA)

- การ Blocking Legay Authentication Protocols

- อื่นๆ 

วิธีการ Enable ใช้งาน Security Defaults

ไปที่ Microsoft Entra Admin Center จากนั้นไปที่ Identity จากนั้นไปที่ Properties ดังรูป

จากนั้นเลื่อนลงมาด้านล่างจะเจอ Security Defaults จากนั้นเลือก Manage Security Defaults และในส่วนของ Security Defaults ให้เลือก Enable แล้ว Save ครับ สำหรับรูปด้านล่างเป็นรูปที่ผมได้ทำการ Enabled Security Defaults เรียบร้อยแล้วครับ

หรือจะไป Enable Security Defaults ผ่านทาง Microsoft Entra ID ใน Azure Portal ก็ได้ครับ เมื่อเข้าไปที่ Azure Portal แล้ว ให้ไปที่ Dashboard ของ Microsoft Entra ID แล้วเลือก Properties ครับ สุดท้ายมันจะเข้ามาที่หน้าเดียวกันครับ ดังรูปด้านล่าง

อธิบายเพิ่มเติมเกี่ยวกับ Security Defaults ครับ, ในกรณีถ้าเรามีการสร้าง Tenant (Microsoft Entra Tenant) หลังจากวันที่ 22 October 2019 เป็นต้นมา ทาง Micrsoft จะมีการแจ้งให้เราทำการ Enable ครับและเมื่อเราทำการ Enabled Security Defaults เสร็จเรียบร้อยตามที่อธิบายไว้ข้างต้น  Users ทุกคนจะต้องทำการ Register Multifactor Authentication ครับ โดย Users หรือผู้ใช้งานจะมีเวลา 14 วันสำหรับการ Register ดังกล่าวนี้ครับ โดยผู้ใช้งานสามารถทำการ Register MFA  โดยใช้ Microsoft Authenticator App หรือ App ต่างๆ ที่ Support OATH TOTP ครับ

หลังจาก Enabled Security Defaults แล้ว ผู้ดูแลระบบ (Administrator) หรือผู้ที่เกี่ยวข้องที่อยู่ใน RBAC Roles ดังต่อไปนี้ จะต้องทำการ Sign-In ในรูปแบบของ MFA 

- Global Administrator

- Application Administrator

- Authentication Administrator

- Billing Administrator

- Cloud Application Administrator

- Conditional Access Administrator

- Exchange Administrator

- Helpdesk Administrator

- Password Administrator

- Privileged Authentication Administrator

- Privileged Role Administrator

- Security Administrator

- SharePoint Administrator

- User Administrator

รายละเอียดเพิ่มเติมเกี่ยวกับ Security Defaults สามารถไปที่ Link นี้ได้เลยครับ, Providing a default level of security in Microsoft Entra ID | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวของ Security Defaults ใน Microsoft Entra ID ครับผม.....