การบริหารจัดการ 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 ครับผม.....

Protecting Server ด้วย Microsoft Defender for Cloud - Defender for Servers

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

สำหร้บบทความนี้ผมอยากจะนำเสนอการนำเอา MDC เข้ามาช่วยในการป้องกัน Servers หรือ VMs (Windows และ Linux) ไม่ว่าจะอยู่ใน On-Premise และ On Cloud โดยครอบคลุมทั้ง Hybrid และ Multi-Cloud Environments ครับ โดยความสามารถที่ว่านี้เรียกกันสั้นๆ ว่า "Defender for Servers" ครับ

Defender for Servers คืออะไร?

อย่างที่ได้เกริ่นไว้เมื่อซักครู่ว่า Defender for Servers เป็นความสามารถหนึ่งของ MDC ที่เข้ามาช่วยป้องกันและสร้างความปลอดภัยให้กับ Servers หรือ VMs ขององค์กรไม่ว่าจะใช้ OS เป็น Windows หรือ Linux และไม่ว่าจะอยู่ที่ไหนก็ตาม (Hybrid หรือ Multi-Cloud Environments) โดย Defender for Servers ยังมาพร้อมกับฟีเจอร์หลายมากมายครับ ทั้งนี้ขึ้นอยู่ Defender Plans ที่เราเลือกครับ  โดยตัวของ MDC นัั้นถ้าเราต้องการใช้งานเราจะต้องทำการวางแแผนกันก่อนนะครับ หลังจากนั้นค่อยดำเนินการใช้งาน เนื่องจากเราจะต้องพิจารณาหลายปัจจัยรวมถึงความต้องการต่างๆ ที่จะต้องนำมาพิจารณา เบื้องต้นสำหรับท่านที่ยังไม่ค่อยคุ้นเคยของ MDC หากต้องการให้ MDC ทำงาน สิ่งที่เราจะต้องจะทราบก่อนเลยคือ MDC เป็น Service หนึ่งใน Microsoft Azure ที่ให้บริการในรูปแบบที่เรียกว่า "Subscription-Based" หมายความว่า ท่านผู้อ่านจะต้องทำการวางแผนและพิจารณามาก่อนว่าต้องการให้ MDC เข้าไปทำหน้าที่ของเค้า (CSPM และ CWPP) กับ Azure Subscriptions ใดที่อยู่ Tenant ของเรา  เมื่อเราเลือก Azure Subscriptions เรียบร้อย MDC ก็จะทำการ Secure และ Protect หรือทำหน้าที่ CSPM และ CWPP กับ Resources ต่างๆ เช่น Azure VMs, Azure Storage Accounts, Azure SQL, และอื่นๆ ที่อยู่ใน Azure Subscriptions นั้น

จากนั้นทำการเลือก Defender Plans ซึ่งตัวของ Defender for Servers ที่ผมกำลังนำเสนออยู่ ณ ขณะนี้ก็จะอยู่ใน Defender Plans ครับ รูปด้านล่างคือ Defender Plans ครับ

โดยใน Defender Plans จะมีให้เลือก 2 ส่วน คือ CSPM และ CWPP หรือ CWP  สำหรับ Defender for Servers ถือว่าเป็นส่วนหนึ่งของหน้าที่หรือ Solution หลักของ MDC ซึ่งก็คือ CWP ดังรูปครับ

ใน Defender for Servers ยังประกอบไปด้วย Plans ของเค้าให้พิจารณาอีก คือ  Microsoft Defender for Servers Plan 1 และ 2 ครับ โดยแต่ละ Plan จะมีความแตกต่างกันทั้งค่าใช้จ่ายและฟีเจอร์ครับ รูปด้านล่างเป็นรูปที่แสดงถึงค่าใช้จ่ายและราคาของแต่ละ Plan ครับ

โดยการที่จะเราจะเลือก Plan ใดของ Defender for Servers จะต้องมีการวางแผนและพิจารณามาก่อนนะครับ นอกจากนี้แล้วในแต่ละ Plan ยังสามารถใช้และทำงานร่วมกับ Microsoft Defender for Endpoint (MDE) หรือเรียกว่าแต่ละ Plan ของ Defender for Servers มาพร้อมกับ (Include) MDE License มาด้วยครับ นั่นหมายความว่าเราสามารถใช้ฟีเจอร์หรือความสามารถต่างๆ ของ MDE  เช่น EDR, Next-Generation Protection, ASR และอื่นๆ เข้ามาช่วยในการ Protect Servers หรือ VMs อีกด้วยครับ ถือว่าเป็น Benefits หนึ่งที่มีประโยชน์มากครับ เมื่อพิจารณาเลือกได้แล้วว่าจะต้องการใช้งาน Plan ใด ของ Defender for Servers ก็ทำการ On และเลือก Plan ที่ต้องการครับ ดังรูป

สำหรับ MDC หรือ Microsoft Defender for Cloud นั้น จะอาศัยการทำงานร่วมกับ Services ตัวอื่นๆ ใน Microsoft Azure ด้วยครับ Service หนึ่งที่จะต้องนำมาทำงานร่วมกับ MDC คือ "Azure Log Analytics Workspace" ครับ เพราะฉะนั้นในการทำงานจริงหรือใน Product Environments จะต้องมีการวางแผนและออกแบบ Azure Log Analytics Workspace ด้วยนะครับ และต้องบอกทุกท่านไว้ว่า Azure Log Analytics Workspace ถือว่าเป็นส่วนประกอบหลักของ Microsoft Security Solutions ครับ สำหรับหน้าที่หลักๆ ของ Azure Log Analytics Workspace เตรียมที่เอาไว้สำหรับให้เราทำการรวบรวมหรือ Collect Data เช่น Logs จาก Sources ต่างๆ เช่น Servers หรือ VMs ที่อยู่ใน On-Premise และ On Cloud, Firewall, และอื่นๆ  สำหรับข้อมูลที่เรารวบรวมมาและถูกเก็บไว้ในตัวของ Azure Log Analytics Workspace เราสามารถทำการ Query ข้อมูลได้ครับ โดยใช้ Query Language ที่ชื่อว่า "Kusto Query Language" หรือเรียกสั้นๆ ว่า KQL ครับ

การที่เราจะทำการ Secure และ Protect Servers หรือ VMs โดยใช้ MDC ด้วย Defender for Servers นั้น มีขั้นตอนหนึ่งที่จะต้องถูกนำมาวางแผนและทำการติดตั้ง นั่นก็คือ การติดตั้ง Agent ไปยัง Server หรือ VMs ที่เราต้องการให้ MDC เข้ามาทำ Secure และ Protect ครับ ดังรูป

สำหรับ Agent ที่จะดำเนินการติดตั้งจากรูปด้านบน แนะนำว่าให้เลือกเป็น Azure Monitor Agent หรือ AMA ครับ เพราะจะเป็น Agent ตัวใหม่ที่มาพร้อมกับความสามารถที่มากกว่าตัวปัจจุบันครับ การติดตั้ง Agent ที่จะทำงานร่วมกับ MDC และ Defender for Servers จะมีความแตกต่างในขั้นตอนเล็กน้อยครับ ทั้งนี้ขึ้นอยู่กับ Servers หรือ VMs ดังกล่าวนั้นอยู่ที่ไหน เช่น Servers หรือ VMs ดังกล่าวอยู่ใน Microsoft Azure (Azure VMs) วิธีการคือตามรูปด้านบนครับ แต่ถ้า Servers หรือ VMs ดังกล่าวนั้นไม่ได้อยู่ใน Microsoft Azure เช่น อยู่ใน On-Premise, AWS, GCP, เป็นต้น จะมีขั้นตอนการติดตั้งอีกแบบครับ ถ้าอ้างอิงตาม Best Practices หรือคำแนะนำของทาง Microsoft จะแนะนำให้เราใช้ Azure Arc-Enabled ครับ (*Azure Arc เป็นอีกหนึ่ง Service ใน Microsoft Azure ที่ถูกออกแบบมาสำหรับการบริหารและจัดการ Servers หรือ VMs ใน Multi-Cloud Environments ครับ รายละเอียดเพิ่มเติมสามารถย้อนไปอ่านบทความของผมได้เลยครับ)

หลังจากนั้น MDC ก็จะเริ่มทำงานโดยการเข้าไปตรวจสอบดูว่า Servers หรือ VMs ดังกล่าวมีช่องโหว่หรือมีความเสี่ยงอะไรบ้าง, การตรวจสอบค้นหาภัยคุกคามและป้องกัน (Threat Detection และ Protection) ในกรณีที่ MDC เจอสิ่งผิดปรกติหรือพฤติกรรมใดที่น่าสงสัยเกิดขึ้นกับ Servers หรือ VMs (ที่ถูก Protected โดย MDC) MDC จะทำการแจ้งเตือนเป็น Alerts (ใน MDC เรียกว่า Security Alerts) เพื่อให้ Security หรือ SOC Teams เข้าไปดำเนินการ Response หรือจัดการต่อไปครับ

สิ่งที่ผมได้อธิบายทั้งหมดข้างต้นเป็นเพียงภาพรวมของคอนเซปตลอดจนขั้นตอนหลักๆ ที่เกี่ยวข้องกับการนำเอา MDC เข้ามาช่วยในการ Protect Servers หรือ VMs โดยใช้  Defender for Servers เท่าน้้นนะครับ ขั้นตอนโดยละเอียดจะมีอยู่ในเอกสารของทาง Microsoft อยู่แล้วครับ แต่สิ่งสำคัญมากที่สุดสำหรับการนำเอา MDC มาใช้งานคือ การ Planning และ Designing เพื่อเตรียมความพร้อมกันก่อนครับ เพราะ MDC ไม่ใช่เป็น Service ที่เราสามารถ Enable ใช้งานทันทีโดยไม่ได้มี Planning และ Designing ล่วงหน้าครับ เพราะถ้าทำเช่นนั้นอาจจะก่อให้ปัญหาและความยุ่งยากตามมาภายหลังครับ

และทั้งหมดนี้คือเรื่องราวของ MDC ในส่วนของ Defender for Servers ครับผม.....

Protecting Storages ด้วย Microsoft Defender for Cloud - Defender for Storage

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

โดยความสามารถหรือฟีเจอร์ของ Microsoft Defender for Cloud ที่พบหยิบยกมานำเสนอให้กับทุกท่านในบทความนี้ก็ คือ "Microsoft Defender for Cloud - Defender for Storage" โดยเราสามารถใช้ความสามารถที่ว่านี้ในการป้องกัน Azure Storage Account ครับ และสำหรับท่านใดที่ยังไม่คุ้นเคยกับ Azure Storage Account ผมขออธิบายเพิ่มเติมนะครับ Azure Storage Account ถือว่าเป็น Core Service หรือเป็น Service หลักใน Microsoft Azure ที่หลายๆ องค์กรนำไปประยุกต์ใช้งาน ในการเก็บข้อมูลครับ โดยข้อมูลที่ถูกเก็บไว้ใน Azure Storage Account สามารถอยู่ในรูปแบบ Structure หรือ Un-Structure ก็ได้ครับ เพราะตัวของ Azure Storage Account มี Storage Types หลายรูปแบบเอาไว้รองรับกับความต้องการ เช่น Blob, Table, Files, เป็นต้นครับ และตัวของ Azure Storage Account ถูกออกแบบมาให้บริการในรูปแบบของ PaaS ครับ นั่นหมายความว่าเราสามารถทำการ Deploy Azure Storage Account ได้ทันเลย โดยที่ไม่ต้องมีส่วนของ IaaS (เช่น Azure Virtual Machines) เข้ามาเกี่ยวข้อง อีกทั้งยังมาพร้อมกับความสามารถต่างๆ เช่น  Availability, Security, เป็นต้น ประมาณนี้นะครับสำหรับเรื่องราวที่มาที่ไปของ Azure Storage Account 

และในช่วงที่ผ่านมาถ้าท่านผู้อ่านท่านใดติดตามข้อมูลข่าวสารต่างๆ ที่เกี่ยวข้องกับ Cybersecurity ท่านจะทราบว่า เริ่มมีการ Attack มาที่ Azure Storage Account โดย Attackers อาศัยช่องโหว่ที่อาจจะเกิดจากการกำหนดค่าบางอย่างที่ไม่ถูกต้อง และอาจจะส่งผลทำให้ Azure Storage Account กลายเป็นจุดที่ Malware เข้ามาหรืออาจจะกลายเป็นจุดที่กระจาย Malware ก็ได้ เพราฉะนั้นจะต้องมีการป้องกัน เช่น การ Scanning Malware สำหรับข้อมูลต่างๆ ก่อนที่จะถูกเข้าถึงจาก Azure Storage Account ตลอดจนมีการป้องกันอื่นๆ เพิ่มเติม

Microsoft Defender for Cloud - Defender for Storage คืออะไร?

คือ Azure-Native Layer สำหรับการป้องกัน Storage (Azure Storage Account) ซึ่งเป็นความสามารถหรือฟีเจอร์หนึ่งที่อยู่ใน Microsoft Defender for Cloud โดย ณ ขณะนี้ Microsoft Defender for Cloud - Defender for Storage supported Storage Types ของ Azure Storage Account  ดังนี้:

- Azure Files (Azure File Share)

- Blob

- Azure Data Lake Storage Gen 2

Microsoft Defender for Cloud - Defender for Storage มาพร้อมกับฟีเจอร์หรือความสามารถต่างๆ เช่น

- Activity Monitoring

- Malware Scanning

- Sensitive Data Threat Detection

- Others

ในกรณีที่ท่านผู้อ่านต้องการใช้งานก็สามารถได้โดยการ Enable หรือ On Microsoft Defender for Cloud -  Defender for Storage ดังรูปด้านล่าง Microsoft Defender for Cloud - Defender for Storage จะทำหน้าที่ในการ Detect และ Identify (โดยใช้ Malware Scanning, Near-Real Time Scanning, และอื่นๆ) Attacks ต่างๆ  ที่เข้ามายัง Azure Storage Account โดยที่ท่านผู้อ่านไม่ต้องมีการกำหนดค่าต่างๆ (Configuration) เพิ่มเติม นอกจากนี้แล้วเรายังสามารถ Integrate Microsoft Defender for Cloud รวมถึง Defender for Storage เพื่อทำงานร่วมกับ SIEM เช่น Microsoft Sentinel ได้อีกด้วย

ตัวอย่างของ Attacks เช่น Malware Upload (มีการ Upload Malware เข้าไปยัง Azure Storage Account แล้วใช้งาน ซึ่งถือว่าเป็นทางเข้าและจุดที่กระจาย Malware ไปยังส่วนต่างๆ ใน Environment นั้น), Data Exfiltration (การย้ายข้อมูลจาก Azure Storage Account ออกไปภายนอก), และ Ransomware (ทำการ Encrypt ข้อมูลที่อยู่ใน Azure Storage Account) เป็นต้น

Scenarios ที่เราสามารถนำเอา Microsoft Defender for Cloud - Defender for Storage ไปประยุกต์ใช้งานเพื่อทำการป้องกัน Azure Storage Account เช่น 

- ใช้งานร่วมกับ Web Applications ที่มีการ Upload ข้อมูลไปยัง Azure Storage Account

- ใช้งานร่วมกับ CDNs เพื่อทำหน้าที่เป็น Content Protection

- Compliant/Regulatory 

- อื่นๆ 

รายละเอียดเพิ่มเติมเกี่ยวกับ Microsoft Defender for Cloud - Defender for Storage สามารถไปที่ Link นี้ได้เลยครับผม, Microsoft Defender for Storage - the benefits and features - Microsoft Defender for Cloud | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวของความสามารถหนึ่งของ Microsoft Defender for Cloud ที่ผมนำมาฝากครับผม.....

Microsoft Cybersecurity ตอนที่ 5 (Rapid Modernization Plan-RaMP)

     สวัสดีครับทุกท่าน สำหรับบทความนี้จะพาทุกท่านไปทำความรู้จักกับ "Rapid Modernization Plan" หรือเรียกสั้นๆ ว่า "RaMP" ครับ โดยเจ้า RaMP นี้ถือว่าเป็นส่วนหนึ่งของ Zero Trust Model ของ Microsoft ครับ สำหรับท่านใดที่ยังไม่รู้จัก Microsoft Zero Trust Model สามารถย้อนไปอ่านบทความที่อยู่ใน Microsoft Cybersecurity Series ของผมก่อนนะครับ, WT Blog (ITGeist): Microsoft Cybersecurity ตอนที่ 3 (Zero Trust Model) (itgeist5blog.blogspot.com)

Rapid Modernization Plan (RaMP) คืออะไร?

อย่างที่เกริ่นไว้ตอนต้นว่า RaMP เป็นส่วนหนึ่งของ Zero Trust Model ดังรูปด้านล่าง 

โดย Zero Trust Model เป็น Security Model หรือ Strategy ที่มาพร้อมกับ Security หรือ Trust Principles และ Pillars ต่างๆ เช่น Identity, Device (Endpoint), Network, และอื่นๆ (อ้างอิงจาก Microsoft Zero Trust Model) ดังรูปด้านล่างครับ

ท่านที่ทำหน้าที่เป็น Cybersecurity Architect หรือท่านที่มีบทบาทหน้าที่เกี่ยวข้องสามารถที่จะนำเอา Microsoft Zero Trust Model และ RaMP ดังกล่าวนี้ เข้ามาช่วยในการวางแผน, ออกแบบ, และดำเนินการเพื่อทำให้ IT Environments (Hybrid และ Multi-Cloud) ขององค์กรมีความปลอดภัยมากขึ้น โดยใน Microsoft Zero Trust นั้นมีส่วนประกอบหลายส่วนตามข้างต้น หนึ่งในนั้นคือ RaMP ซึ่งโฟกัสเรื่องของการ Secure Privileged Access เพื่อทำการปิดหรือลดช่องทางของ Unauthorized Access ในองค์กร และ RaMP ยังมาพร้อมกับ Services และ Technologies ต่างๆ เพื่อทำการ Protect และ Monitor Authorized Access อย่างใกล้ชิด โดยอ้างอิงตาม Microsoft Zero Trust Principles (Verify Explicitly, Use Least Privileged Access, และ Assume Breach) รูปด้านล่างเป็นรูปที่อธิบายเกี่ยวกับ RaMP ครับ

โดยใน RaMP มาพร้อมกับคอนเซป, Reference Architectures, Best Practices, และอื่นๆ  ยกตัวอย่างเช่น Enhanced Security Admin Environment หรือเรียกสั้นๆ ว่า ESAE (หรือเรียกอีกชื่อว่า Red Forest)  รายละเอียดเพิ่มเติมของ ESAE สามารถไปที่ Link นี้ได้เลยครับ, Enhanced Security Admin Environment (ESAE) architecture mainstream retirement | Microsoft Learn

โดยใน ESAE จะมาพร้อมกับรายละเอียดต่างๆ เช่น Best Practices ในการ Secure และ Protect Identities ขององค์กร โดยนำเอา Services ต่างๆ เข้ามาช่วย เพื่อป้องกันไม่ให้ Identity ถูก Compromised เป็นต้น

จากที่ผมได้อธิบายท้้งหมดข้างต้น สรุปได้ว่า RaMP ถูกออกแบบมาเพื่อช่วยองค์กรในการนำเอา Microsoft Zero Trust Model มา Adopt ใช้งาน โดยโฟกัสที่ Privileged Access Strategy ตาม Principles (At Least Privileged Access) ของ Microsoft Zero Trust Model ครับ

รายละเอียดเพิ่มเติมเกี่ยวกับ RaMP สามารถไปที่ Link ได้เลยครับ, Zero Trust Rapid Modernization Plan | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวของ RaMP ซึ่งเป็นส่วนประกอบหนึ่งของ Microsoft Zero Trust Model ครับผม.....