วันพฤหัสบดีที่ 28 ธันวาคม พ.ศ. 2566

การบริหารจัดการ 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 เท่านั้นนะครับ แต่ถือว่าเป็นเรื่องที่สำคัญเรื่องหนึ่งทีเดียวครับผม.....




วันอังคารที่ 26 ธันวาคม พ.ศ. 2566

สำรวจสมาชิกใน 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 ครับ ฝากติดตามกันด้วยครับผม.....

วันจันทร์ที่ 18 ธันวาคม พ.ศ. 2566

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


วันศุกร์ที่ 1 ธันวาคม พ.ศ. 2566

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