บริหารจัดการ Identity ด้วย Microsoft Entra ตอนที่ 3

      สวัสดีครับทุกท่าน เรากลับมาพบกันอีกเช่นเคยครับ และในบทความนี้จะเป็นบทความที่เริ่มต้นเรื่องราวของการบริหารจัดการ Identity ครับ โดยใช้ Microsoft Entra ซึ่งเป็น Product Family ที่ทาง Microsoft ได้ออกแบบและพัฒนามาเพื่อช่วยองค์กรในการบริหารจัดการ Identities ต่างๆ ซึ่งใน Family ดังกล่าวนี้ยังมีสมาชิกอีกหลายตัวครับ โดยแต่ละตัวก็จะมาช่วยในการบริหารจัดการ Identities ที่ว่านี้ครับ 

แต่ก่อนจะไปถึงรายละเอียดและสมาชิกใน Microsoft Entra ผมอยากจะปูพื้นเรื่องราวของการบริหารจัดการ Identity ก้นก่อนครับ และเหตุผลที่ผมอยากจะนำเอาเรื่องราวของ Identity มานำเสนอ ก็เพราะว่า ณ ปัจจุบันหลายองค์กรมีการนำเอา Cloud Computing คอนเซปและเทคโนโลยีมาประยุกต์ใช้งาน ผ่านทางผู้ให้บริการ Cloud (Cloud Service Providers) เช่น Microsoft, AWS, GCP, เป็นต้นครับ สิ่งหนึ่งที่มีความสำคัญและจะต้องมีการวางแผน, ออกแบบ, ตลอดจนเรื่องของความปลอดภัยให้ดีและให้พร้อม นั่นก็คือ เรื่องของ "Identity" ครับ ณ วันนี้ Identity ไม่ใช่เป็นเพียงแค่สิ่งที่ใช้ในการตรวจสอบเพื่อเข้าถึงข้อมูลต่างๆ ขององค์กรเพียงอย่างเดียว แต่ในวันนี้ "Identity" ถือว่าเป็น Foundation หรือพื้นฐานที่สำคัญสำหรับ Modern Cybersecurity ครับ ดังนั้นก่อนที่เราจะเข้าไปบริหารจัดการตลอดจนสร้างความปลอดภัยให้กับ Identity จึงจำเป็นที่จะต้องทำความเข้าใจกับคอนเซปตลอดจนรายละเอียดที่สำคัญที่เกี่ยวข้องกับ Identity เสียก่อนครับ 

ก่อนที่ผมจะเขียนบทความนี้ ในช่วงที่ผ่านมาผมได้เขียนเรื่องราวพืันฐานหรือ Foundation เกี่ยวกับ Identity เอาไว้ใน ITGeist FB ผมไปแล้ว 2 ตอนครับ จากนั้นจึงมาเขียนเป็นบทความนี้และถือว่าเป็นตอนที่ 3 ครับผม

ตอนที่ 1: https://www.facebook.com/share/p/18FSgcU2Qu/

ตอนที่ 2: https://www.facebook.com/share/p/1ZPeZzTuwn/

เอาล่ะครับ เรามาว่ากันต่อในเรื่องราวของการบริหารจัดการ Identity หลังจากที่ปูพื้นกันมาแล้ว 2 ตอนครับ โดยเนื้อหาของตอนที่ 3 ในบทความนี้ จะเริ่มด้วยคอนเซปการทำงานของการบริหารจัดการ Identity ดังรูปด้านล่าง ซึ่งจะเกี่ยวข้องกับ Identity, Identity Provider (IdP), เป็นต้นครับ

โดยเริ่มจากตัวผู้ใช้งาน (มุมขวาด้านล่างสุดของรูป) เริ่มดำเนินการโดยการส่ง  Authentication Request จากเครื่องของตัวเอง (รวมถึง App ที่เกี่ยวข้อง) ไปยัง IdP (เช่น Microsoft Entra ID) จากนั้น IdP จะทำการตรวจสอบ (Verify) Credentials (Username และ Password) ว่าถูกต้องหรือไม่ผ่านกระบวนที่เรียกว่า Authentication, ถ้าถูกต้อง IdP จะทำการส่ง "ID Token" ซึ่งเก็บข้อมูลต่างๆ ที่เกี่ยวข้องกับตัวผู้ใช้งานกลับไป

และต่อมา IdP ได้รับ User Consent และทำการ Authorize ให้ผู้ใช้งานและ Apps สามารถทำการ Access Resources ต่างๆ โดยผ่านกระบวนการ Authorization ซึ่งจะทำการ Issued "Access Token" และจะถูกส่งไปยังเครื่องของผู้ใช้งานเช่นกัน จากนั้น IdP ก็จะทำการบันทึกเหตุการณ์และ Activities ต่างๆ ที่เกิดขึ้นและที่เกี่ยวข้องกับ Identity ผ่านทางกระบวนการ Auditing ครับ

และนี่คือขั้นตอนการทำงานคร่าวๆ สำหรับการบริหารจัดการ Identity ซึ่งจะเกี่ยวข้องกับ IdP ซึ่งจะดำเนินการกระบวนการ "AAA" (Authentication, Authorization, Auditing) *รายละเอียดจะอยู่ในตอนที่ 1 ใน ITGeist FB ครับ

ในกรณีที่องค์กรต้องการ Solution ในการบริหารจัดการ Identity แบบครบวงจรและครอบคลุมทั้ง On-Premise และ Hybrid Cloud หากเป็น Solution ของทาง Microsoft นั่นก็คือ "Microsoft Entra" ครับและอย่างที่ผมเกริ่นไว้ข้างต้นว่า Microsoft Entra เป็น Product Family ที่ถูกออกแบบมาเพื่อใช้ในการบริหารจัดการ, การสร้างความปลอดภัย, และอื่นๆ ให้กับ Identities ต่างๆ ในองค์กรครับ โดย Microsoft Entra Product Family นี้ยังมาพร้อมกับสมาชิกหลายตัวครับ เช่น

- Microsoft Entra ID (IAM)

- Microsoft Entra Verified ID

- Microsoft Entra ID Governance

- Microsoft Entra Permission Management

- อื่นๆ

สมาชิกตัวหนึ่งใน Family ดังกล่าว จะเป็นสมาชิกที่มีความสำคัญและถือว่าเป็นส่วนประกอบหลักในการบริหารจัดการ Identity นั่นก็คือ "Microsoft Entra ID" หรือชื่อเดิม "Azure Active Directory" ซึ่งผมเชื่อว่าเป็น Service ที่หลายๆ ท่านน่าจะรู้จักและคุ้นเคยกันเป็นอย่างดีครับ นั่นหมายความว่าการที่เราจะดำเนินการในการบริหารจัดการ Identity ด้วย Microsoft Solution (Microsoft Entra) สมาชิกหรือ Service ตัวแรกที่เราควรจะรู้จักและทำความคุ้นเคยให้ได้มากที่สุดก่อนเลย นั่นก็คือ Microsoft Entra ID ครับ

Microsoft Entra ID 

เป็น Service ที่ทาง Microsoft ให้มาพร้อมกับ Cloud Services ต่างๆ ที่ทาง Microsoft ให้บริการอยู่ เช่น Microsoft Azure, Microsoft 365, เป็นต้นครับ โดย Microsoft Entra ID จะเป็น Service ที่ให้บริการ Solution ที่ชื่อว่า "Identity and Access Management" หรือเรียกสั้นๆ ว่า "IAM" ครับ  และเราสามารถเรียกหรือบอกได้ว่า Microsoft Entra ID ทำหน้าที่เป็น IdP ที่ดำเนินการกระบวนการ AAA ครับ นอกจากนี้แล้วตัวของ Microsoft Entra ID ยังมาพร้อมกับความสามารถและฟีเจอร์ต่างๆ มากมาย (ขึ้นอยู่กับ Editions) ในการบริหารจัดการ Identity ให้กับองค์กร

Editions ต่างๆ ของ Microsoft Entra ID มีดังนี้:

1. Microsoft Entra Free Edition, เป็น Edition ที่โดย Default จะถูก Bundle มาพร้อมกับ Microsoft Azure, Microsoft 365, และอื่นๆ โดยมาพร้อมกับความสามารถหลักๆ ในการบริหารจัดการ Identity เช่น การบริการจัดการ Accounts (Users และ Groups), Hybrid Identity Scenario, SSO, SSP (Cloud Users), เป็นต้น

2. Microsoft Entra ID P1 (Premium 1), เป็น Edition ที่สามารถทำทุกฟีเจอร์ของ Free Edition และมาพร้อมกับความสามารถเพิ่มเติม เช่น Dynamic Groups, Conditional Access, เป็นต้น

3. Microsoft Entra ID P2 (Premium 2), เป็น Edition ที่มาพร้อมกับความสามารถหรือฟีเจอร์ต่างๆ ที่อยู่ใน Free และ P1 และมีความสามารถเพิ่มเติม เช่น Microsoft Identity Protection, Microsoft Entra ID Governance, เป็นต้น

4. Microsoft Entra Suite เป็นชุดของ Services/Products ที่มาพร้อมกับความสามารถต่างๆ เช่น Network Access, Identity Protection, Identity Governance, และอื่นๆ 

รายละเอียดเพิ่มเติมสำหรับในแต่ละ Microsoft Entra ID Editions/Plans ไปที่ Link นี้ได้เลยครับ, Microsoft Entra Plans and Pricing | Microsoft Security

เพิ่มเติมอีกซักนิดครับสำหรับเรื่องของการบริหารจัดการ Identity นั้น, Microsoft มี Solution ที่ชื่อว่า "Active Directory-Based Identity Solution" ครับ ซึ่งประกอบไปด้วย Services ต่างๆ  คือ Active Directory Domain Service (AD DS), Microsoft Entra ID, และ Microsoft Entra Domain Service ครับ โดย Solution ดังกล่าวนี้ก็จะอยู่ในเรื่องของการบริหารจัดการ Identity และเกี่ยวข้องกับ Microsoft Entra ครับ รายละเอียดเพิ่มเติมเกี่ยวกับ Solution ดังกล่าวนี้ สามารถไปอ่านบทความนี้ได้เลยครับ, https://itgeist5blog.blogspot.com/2025/01/active-directory-based-identity.html

และทั้งหมดนี้คือเรื่องราวของ Microsoft Entra, Microsoft Entra ID ครับ โปรดติดตามตอนต่อไปครับผม.....

Monitoring vs Observability ตอนที่ 3

      สวัสดีครับทุกท่านสำหรับบทความนี้จะเป็นตอนที่ 3 สำหรับเรื่องราวเกี่ยวกับ Monitoring vs Observability ครับ โดย 2 ตอนก่อนหน้านี้ผมได้เล่าที่มาที่ไปตลอดจนรายละเอียดต่างๆ ไปแล้วสำหรับท่านใดที่เพิ่งจะมาอ่านบทความตอนนี้ สามารถย้อนกลับไปอ่านบทความทั้ง  2 ตอนก่อนนะครับ และอย่างที่ผมได้ทิ้งท้ายไปไว้ในบทความตอนที่ 2 ว่า ในบทความต่อมา (ตอนที่ 3) ผมจะพาทุกท่านไปทำความรู้จักกับ Service ตัวหนึ่งใน Microsoft Azure ที่จะเข้ามาช่วยในเรื่องของการทำ Monitoring และ Observability ครับ และ Service ดังกล่าวนี้มีชื่อว่า "Azure Monitor" ครับ

ทำความรู้จักกับ Azure Monitor

Azure Monitor เป็น Service ใน Microsoft Azure โดยมีความสามารถในการ Monitoring และ Analytics กับ Azure Resources, On-Premise Infrastructure, และอื่นๆ และมาพร้อมกับ AI & ML เทคโนโลยีครับ โดยตัวของ Azure Monitor จะโฟกัสการ Monitoring แบบ Deep Insights และการทำ Analytics เพื่อให้เราเห็นและเข้าใจ Workloads หรือ Azure Resources นั้นๆ  (เช่น Applications) มี Performance และ Availability เป็นอย่างไร อีกทั้ง Azure Monitor ยังทำการ Identify เรื่องของ Optimization อีกด้วย ยกตัวอย่างเช่น เมื่อเรานำเอา Azure Monitor มาทำการ Monitor Applications, Azure Monitor จะทำการ Monitor หรือตรวจสอบ Performance ของ Applications ดังกล่าวแบบ Real-Time, ทำการ Identify Bottlenecks, และ Issues ต่างๆ ที่เกี่ยวข้องกับเรื่องของ Performance และ Availability

*หมายเหตุ: Workloads หมายความถึงระบบหรือ Applications ต่างๆ ที่รันอยู่ Virtual Machines, PaaS Services, Container Services, เป็นต้น

และอย่างที่เกริ่นไว้ก่อนหน้านี้ว่าได้มีการนำเอา AI และ ML เทคโนโลยีมาใช้กับ Azure Monitor, ทำให้ Azure Monitor สามารถทำการค้นหา (Detect) Anomalies และ Potential Issues ก่อนที่มันจะส่งผลกระทบกับ Performance และ Availability ของ Applications นั้นๆ นอกจากนี้แล้ว Azure Monitor ได้เตรียม View หรือมุมมองที่จะช่วยให้เราเห็นภาพและเข้าใจถึงปัญหาต่างๆ ที่ผลกับ Performance ของ Applications ส่งผลทำให้ง่ายต่อการที่เราจะทำการแก้ไข (Troubleshooting) 

นอกจากนั้นแล้ว Azure Monitor ยังเป็นอีก Service หนึ่งที่ต้องอาศัยการทำงานร่วมกับ Services ตัวอื่นๆ ใน Microsoft Azure ตัวอย่างของ Services อื่นๆ ใน Microsoft Azure ที่ถูกนำเอามา Integrate และทำงานร่วมกับ Azure Monitor เช่น Azure Policy, Azure Log Analytics Workspace, เป็นต้น  โดยเฉพาะ Azure Log Analytics Workspace ถือว่า Service และส่วนประกอบที่สำคัญสำหรับ Azure Monitor ครับ เพราะจากข้างต้นทุกท่านจะเห็นแล้วว่า Azure Monitor สามารถทำการตรวจสอบ (Monitoring) และ วิเคราะห์ (Analytics) Performance และ Availability ของ Workloads/Apps, และอื่นๆ การที่จะดำเนินการดังกล่าวนี้ได้ จะต้องมีการเก็บรวบรวมข้อมูลจาก Workloads/Apps ที่เราต้องการให้ Azure Monitor ทำการตรวจสอบ และข้อมูลที่ว่านี้แบ่งออกเป็น 2 ชนิด คือ

1. Metric Data, ข้อมูลชนิดนี้เป็นตัวเลขที่เกี่ยวข้องกับการใช้งาน (Usage) จาก Processor, Memory, และอื่นๆ

2. Log Data, ข้อมูลชนิดนี้เป็นข้อมูลที่เก็บเหตุการณ์และ Activities ต่างๆ

โดยข้อมูลทั้ง 2 ชนิดข้างต้นจะถูกรวบรวมมาจาก Workloads ที่เราต้องการครอบคลุมทั้ง On-Premise และ On Cloud ครับ

ดังนั้นสิ่งที่เราต้องเตรียมไว้ก่อน คือ ที่ที่สำหรับเก็บข้อมูลดังกล่าวครับ และ Azure Log Analytics Workspace คือ Service ที่เตรียมที่สำหรับเก็บข้อมูลที่ว่านี้ได้ครับ อีกทั้งเรายังสามารถทำการ Query ข้อมูลที่เก็บใน Azure Log Analytics Workspace ได้อีกด้วยครับ โดยใช้ Query Language ที่ชื่อว่า "Kusto Query Language" หรือ "KQL" ครับ

ดังนั้นสิ่งสำคัญสิ่งหนึ่งเลยก่อนที่เราจะใช้งาน Azure Monitor คือ การ Planning และ Designing เพื่อเตรียมความพร้อมก่อนที่จะนำเอา Azure Monitor มาใช้งาน เนื่องจากมีหลายปัจจัย เช่น Cost, Security, และอื่นๆตลอดจนความต้องการ (Requirements) ที่จะต้องนำเอาคิดและพิจารณาครับ 

รายละเอียดเพิ่มเติมสำหรับ Azure Monitor สามารถไปที่ Link นี้ได้เลยครับ, Azure Monitor | Microsoft Azure

และ Link นี้ครับ, Azure Monitor documentation - Azure Monitor | Microsoft Learn

ประมาณนี้ครับผม.....

Monitoring vs Observability ตอนที่ 2

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะยังคงเป็นเรื่องราวต่อเนื่องมาจากที่ผมได้นำเสนอไปก่อนหน้านี้ครับ นั่นก็คือเรื่องราวของการ Monitoring และ Observability  โดยในบทความก่อนหน้านี้ผมได้อธิบายถึงที่มาที่ไปรวมถึงความแตกต่างระหว่าง Monitoring และ Observability ซึ่งในความเป็นจริงแล้วจะต้องดำเนินการร่วมกันครับ และที่สำคัญคือเรื่องราวเหล่านี้ที่ผมกำลังนำเสนอทุกท่านอยู่จนถึงบทความนี้จะเป็นการปูทางเข้าสู่การ Monitoring  และ  Observability โดยใช้ Service ตัวหนึ่งใน Microsoft Azure ซึ่งเป็น Service ที่มีความสำคัญตัวนึงที่เกี่ยวข้องกับเรื่องราวของ Cybersecurity โดย Service ดังกล่าวนี้มีความสามารถในการ Monitoring รวมถึง Observability Workloads ต่างๆ ใน IT Environments (Hybrid และ Multi-Cloud)  ขององค์กรครับ แต่ก่อนจะไปถึง Service ดังกล่าวนี้ ผมอยากจะอธิบายเพิ่มเติมเกี่ยวกับคอนเซปและรายละเอียดของ Monitoring และ Observability อีกซักนิดครับ และเพื่อไม่ให้เป็นการเสียเวลาเรามาว่ากันต่อสำหรับเรื่องราวของ Monitoring และ Observability ครับ

โดยเริ่มด้วยส่วนประกอบหลักๆ สำหรับการ Monitoring รวมถึง Observability ครับ นั่นก็คือ การรวบรวมข้อมูลหรือ Collected Data จาก Workloads ต่างๆ ใน IT Environments (ครอบคลุมทั้ง Hybrid และ Multi-Cloud) เช่น VMs, Apps, Networks, และอื่นๆ ครับ ซึ่งจะต้องมีการวางแผนและออกแบบก่อนว่า เรามีความต้องการที่จะทำการรวบรวมข้อมูลดังกล่าวนี้จาก Workloads หรือ IT Assets ใดบ้าง, Workloads หรือ IT Assets ดังกล่าวนั้นอยู่ที่ใด (On-Premise หรือ Cloud), รูปแบบของ Workloads, Roles ของ Workloads ดังกล่าวนั้นคืออะไร เช่น Apps, Databases, และอื่นๆ ครับ

และสำหรับข้อมูลที่ถูกรวบรวมมานั้น (Collected Data) จะเป็นข้อมูลที่เกี่ยวข้องและถูกนำมาใช้ในเรื่องของ Security Operations เท่านั้นนะครับ จะไม่เกี่ยวข้องกับขัอมูลขององค์กรครับ โดยข้อมูลที่ว่านี้โดยหลักๆ จะมีอยู่ด้วยกัน 2 ชนิด คือ:

1. Metric Data คือ ข้อมูลที่เป็นตัวเลข ที่มาจากการใช้งาน System Resources ของ Workloads นั้นๆ ตัวอย่างของ System Resources เช่น Processor, Memory, เป็นต้น เพราะข้อมูลชนิดนี้มีประโยชน์ในการที่นำเอามาตรวจสอบ, วิเคราะห์, และอื่นๆ เพื่อดูรูปแบบการใช้งาน (Usage Patterns), แนวโน้มการใช้งาน System Resources, และอื่นๆ

2. Log Data คือ ข้อมูลที่เป็นการบันทึกเหตุการณ์หรือ Activities ต่างๆ ที่เกี่ยวข้องกับ Workloads หรือ IT Assets นั้น โดยข้อมูลชนิดนี้มีประโยชน์ในการค้นหาหรือติดตามในกรณีที่เราต้องการค้นหาดูว่าช่วงที่ผ่านมานั้นมีเหตุการณ์ใดเกิดขึ้นบ้าง เพื่อนำมาประกอบในการติดตามและวิเคราะห์เพื่อดำเนินการต่อไปครับ

จากนั้นสิ่งที่เราจะต้องวางแผนและออกแบบต่อมาคือ ที่ที่เก็บ Collected Data  หรือที่เราเรียกว่า "Data Repository" ว่าจะเก็บไว้ที่ไหน โดยที่ดังกล่าวนี้จะต้องรองรับการค้นหาข้อมูล (Querying Data), และเรื่องของระยะเวลาในการเก็บรักษาข้อมูล (Data Retention) ครับ รวมถึงการพิจารณาหรือดูว่าจะมี Tools หรือ Solutions ใด ที่จะต้องมา Integrate และใช้งานที่ที่เก็บข้อมูลดังกล่าวนี้ด้วยหรือไม่ครับ

สำหรับในช่วงที่ผ่านมาจนถึงปัจจุบันมี Tools หรือ Solutions สำหรับการทำ Monitoring และ Observability ให้เลือกมากมายครับ แต่โดยหลักๆ ควรจะต้องมีความสามารถเหล่านี้หรือมากกว่านี้ครับ

- Log Management

- Application Performance Monitoring (APM)

- Network Monitoring

- Service Monitoring

- อื่นๆ 

นอกจากนี้ความสามารถข้างต้นแล้ว Tools หรือ Solutions ดังกล่าวนี้ควรจะมีความสามารถในการตรวจสอบและวิเคราะห์เชิงลึกหรือโดยละเอียด (Insights) แบบ Real-Time เพื่อช่วยองค์กรหรือเราในการตรวจสอบ (Monitor) เหตุการณ์หรือ Activities ต่างๆ, สิ่งผิดปรกติหรือสิ่งที่น่าสงสัย, และอื่นๆ ที่อาจส่งผลกระทบกับ Performance และ Availability โดยการตรวจสอบตามคอนเซปดังกล่าวนี้จะเป็นการตรวจสอบแบบเฉพาะเจาะจงกับ Workloads หรือ IT Assets นั้นไม่ได้เป็นการตรวจแบบทั่วๆไป ยกตัวอย่าง เช่น Workloads ที่เป็น Web Apps การตรวจสอบในคอนเซปนี้จะไม่ได้เป็นการตรวจสอบเพียงแค่ Processor, Memory, Disk, เป็นต้น แต่จะเป็นการเข้าไปตรวจสอบและวิเคราะห์เชิงลึก (Insights) ของเฉพาะ Workloads (Specific Workloads) เพื่อทำให้เราเข้าใจถึงการทำงานตลอดจนส่วนประกอบต่างๆ ที่เกี่ยวข้องกับ Apps ว่าทำงานเป็นอย่างไร และมีจุดใดที่มีอาจจะก่อให้เกิดปัญหาและส่งผลกระทบการทำงานและการให้บริการของ Apps ดังกล่าวนี้ ที่มีผู้ใช้งานใช้งานอยู่ครับ โดยความสามารถดังกล่าวนี้ (Real-Time Insights) นี้มีความสำคัญมากในการช่วยองค์กรในการตรวจสอบ Performance, Availability, และ Behavior ของ Workloads ต่างๆ แบบเฉพาะเจาะจงกับ Workloads นั้นๆ ครับ และจากความสามารถและคอนเซปดังกล่าวนี้ส่งผลทำให้การ Monitoring และ Observability สามารถช่วยในการ Detect และ Identify Root Causes, Optimize Performance & Availability, ลดเรื่องของ MTTD (Mean Time To Detect) และ MTTR (Mean Time To Recovery), และอื่นๆ ครับ

ประมาณนี้ครับสำหรับตอนต่อไปผมจะพาทุกท่านไปทำความรู้จักกับ Service ใน Microsoft Azure ที่มีความสามารถในการ Monitoring และ Observability ครับผม.....

Monitoring vs Observability ตอนที่ 1

      สวัสดีครับทุกท่าน กลับมาพบกันอีกเช่นเคยครับ  และยังคงนำเสนอเรื่องราวเกี่ยวกับ Cybersecurity เหมือนเดิมครับ และสำหรับบทความนี้อยากจะนำเสนอเรื่องหนึ่งที่มีความสำคัญกับทุกๆ องค์กรที่มีการนำเอา Cloud เข้ามาประยุกต์ใช้งานในองค์กร นั่นก็คือ เรื่องของการตรวจสอบการทำงานของ Workloads หรือ Resources ต่างๆ ว่ามี Performance ตลอดจนรายละเอียดต่างๆ รวมถึงเรื่องของความปลอดภัยหรือ Security ครับ ดังนั้นหลายๆ องค์กรจึงเตรียมความพร้อมในการดำเนินการดังกล่าว 

และจากประเด็นข้างต้นนี่เองครับ จึงเป็นนำเอาคำศัพท์ (Terminology) ต่างๆ เข้ามาเกี่ยวข้องและผมอยากจะอธิบายคำศัพท์ซัก 2 คำที่มีความสำคัญและน่าสนใจครับ และผมเชื่อว่ายังมีอีกหลายๆ ท่านที่อาจจะยังไม่ทราบและไม่เข้าใจครับ นั่นก็คือคำว่า "Monitoring" กับ "Observability" ครับ ถ้าแปลความหมายตรงตัวมันคือ การตรวจสอบและการสังเกตครับ และถ้าดูเผินๆ ก็จะมีความคล้ายกัน นั่นก็คือ การที่เราจะเข้าไปดำเนินการตรวจสอบ Workloads หรือ Resources ต่างๆ ที่อยู่ใน IT Environments (Hybrid และ Multi-Cloud) ว่าเป็นอย่างไร เช่น เรื่องของ Performance, Availability, รวมถึง Security ครับ

โดยเริ่มจาก Monitoring ครับ, คือ กระบวนหรือขั้นตอนในการรวบรวมข้อมูล (Collecting Data) เกี่ยวกับ Performance (CPU, Memory, Network, เป็นต้น), Health, และอื่นๆ ของ Workloads หรือ Resources ต่างๆ เช่น Virtual Machines, Apps, และอื่นๆ โดยมีวัตถุประสงค์ คือ เพื่อทำ Detect และ Respond เมื่อมีสิ่งผิดปรกติหรือมีการเปลี่ยนแปลงบางอย่างที่ผิดปรกติเกิดขึ้น โดยการ Monitoring โดยปรกติหรือส่วนใหญ่ก็จะเกี่ยวข้องกับการกำหนดค่าต่างๆ กับการ Monitoring เช่น การกำหนดค่า Thresholds, Alerts, และ Notifications เพื่อทำการแจ้งกับผู้ที่ดำเนินการหรือผู้ที่เกี่ยวข้องเมื่อมีสิ่งผิดปรกติเกิดขึ้น

ส่วน Observability, คือ ความสามารถในการได้รับรู้และเข้าใจเกี่ยวกับ Workloads, Resources หรือระบบต่างๆ โดยละเอียดว่าเป็นอย่างไร โดยมีวัตถุประสงค์ คือ การให้ข้อมูลเชิงลึกและโดยละเอียดของ Workloads, Resources, หรือระบบต่างๆ เช่น ส่วนประกอบต่างๆ ที่เกี่ยวข้อง, ความสัมพันธ์ของส่วนประกอบต่างๆ, และอื่นๆ เพื่อให้ผู้ที่เกี่ยวข้อง เช่น Security Operators, Developers, System Engineers, เป็นต้น สามารถเห็นภาพโดยละเอียดและเข้าใจ เพื่อใช้ประกอบในการตัดสินใจว่า จะทำการแก้ไข, ปรับปรุง, และอื่นๆ เพื่อทำการ Optimize ต่อไป  โดยปรกติ Observability จะเกี่ยวข้องกับการ Collecting Data จาก Sources (Workloads, Resources, และอื่นๆ) เช่น Metric Data, Log Data, และอื่นๆ เพื่อนำมาใช้ในการพิจารณารวมถึงการสำรวจและวิเคราะห์ข้อมูลเหล่านี้

ความแตกต่างหลักระหว่าง Monitoring และ Observability

การ Monitoring โดยปรกติจะโฟกัสเรื่องของการ Detecting และ Responding ในขณะที่ Observability จะโฟกัสที่การเตรียมข้อมูลเชิงลึกของ Workloads, Resources, หรือระบบนั้นๆ เพื่อก่อให้เกิดความเข้าใจและเห็นภาพทั้งหมด เพื่อนำไปใช้สำรวจและวิเคราะห์เพื่อทำการตัดสินใจว่าจะดำเนินการอย่างไรต่อไป นอกจากนี้แล้ว Monitoring ยังเกี่ยวข้องกับการกำหนดค่าต่างๆ ในการค้นหาสิ่งผิดปรกติหรือสิ่งที่น่าสงสัย โดยจะเกี่ยวข้องกับการกำหนดค่า Settings ต่างๆ เช่น Thresholds, Alerts, เป็นต้น ในขณะที่ Observability จะเน้นไปที่การ Collecting Data จาก IT Assets (Workloads, Resources, หรือระบบต่างๆ) เพื่อจะนำเอาข้อมูลเหล่านี้ (Metrics, Logs, Dumps, และอื่นๆ) มาทำสำรวจและวิเคราะห์เพื่อตัดสินใจว่าจะทำการปรับปรุง, เปลี่ยนแปลง, และอื่นๆ อย่างไร เพื่อทำให้เกิดความปลอดภัยมากขึ้น อีกสิ่งหนึ่งที่มีความแตกต่างอีก คือ ระยะเวลา (Timeframe) สำหรับ Monitoring โดยปรกติหรือทั่วๆไปจะเน้นไปที่การตรวจสอบแบบ Real-Time หรือระยะเวลาสั้นๆ เช่น 1-2 สัปดาห์เป็นอย่างน้อยขึ้นอยู่กับความต้องการ ในขณะที่ Observability จะใช้เวลาโดยรวมนานกว่าการ Monitoring เพราะจะต้องทำการวิเคราะห์เพื่อทำการ Identify Trends หรือแนวโน้มต่างๆ รวมถึง Patterns ด้วยครับ

และนี่คือเรื่องราวเริ่มต้นเกี่ยวกับ Monitoring และ Observability ครับ โปรดติดตามตอนต่อไปครับผม.....

สร้าง Modern Blue Team ด้วย Microsoft Security Solutions ตอนที่ 1

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะนำเสนอเรื่องราวของการสร้าง Modern Blue Team ด้วย Microsoft Security Solutions ครับ แต่ก่อนจะไปถึงเรื่องราวด้งกล่าว ก็ต้องขออนุญาตเกริ่นหรือท้าวความถึงที่มาที่ไปของ Teams ต่างๆ ที่เกี่ยวข้องกับ Security Operations ใน Cybersecurity ครับ โดยมีรายละเอียดคร่าวๆ ดังนี้:

- Red Team, เป็น Team ที่อยู่ภายใน Security หรือ Cybersecurity Operations โดยหน้าที่คือ ดำเนินการในเรื่องของ Simulated Attacks และ Penetration Testing หรือการเจาะระบบภายใน Infrastructure ขององค์กร

- Blue Team, เป็น Team ที่อยู่ภายใน Security หรือ Cybersecurity Operations เช่นกัน โดยหน้าที่คือ การ Defense และ Response กับภัยคุกคามหรือ Attacks ต่างๆ 

- Yellow Team, เป็น Team ของ Developers หรือเรียก Team นี้ว่า "Builder" โดย Team ดังกล่าวนี้จะรับผิดชอบการ Developing, Coding, รวมถึงการ Implement Secure Applications และ Infrastructures ตั้งแต่เริ่มต้น

- Purple Team, เป็น Team ที่โฟกัสเรื่องของแนวคิดและ Methodology กับ Cybersecurity Architecture รวมถึงการป้องกัน โดย Purple Team จะทำงานร่วมกับทั้ง Red และ Blue Teams เพื่อทำให้ความสามารถต่างๆ ที่เกี่ยวข้องกับ Cybersecurity ถูกนำมาใช้ได้อย่างเต็มประสิทธิภาพ นอกจากนั้นแล้ว Purple Team ยังนำเอาข้อมูลต่างๆ เช่น Feedback, Lessons Learned และอื่นๆ จากทั้ง 2 Teams (Red และ Blue Teams) มาทำการวิเคราะห์เพื่อทำการปรับปรุงกระบวนการต่างๆ ของ Security Operations ให้มีประสิทธิภาพมากขึ้น

สำหรับบทความนี้ผมจะโฟกัสที่ Blue Team ซึ่งท่านผู้อ่านจะเห็นแล้วว่า Team ดังกล่าวนี้มีหน้าที่หลักๆ คือการป้องกัน IT Assets ต่างๆ ที่อยู่ใน IT Environments (Hybrid และ Multi-Cloud) ขององค์กรให้มีความปลอดภัย โดยแต่เดิมนั้นสิ่งที่ Blue Team จะต้องดำเนินการ เช่น การใช้ Firewall ในการป้องกันโดยการควบคุม Traffics ต่างๆ ที่เข้าและออกขององค์กร, การติดตั้งและใช้งาน Antivirus, Intrusion Detection System, และอื่นๆ โดยภาพรวมที่ดำเนินการคือ การป้องกันหรือ Protection/Prevention อย่างเดียว แต่อาจจะไม่ได้เข้าใจคอนเซปและการทำงานของภัยคุกคามหรือ Threats ที่จะ Attack เข้ามา 

ตลอดจนช่วงที่ผ่านมาการ Attacks มีการพัฒนาและปรับเปลี่ยนรูปแบบต่างๆ มากขึ้นกว่าแต่ก่อน เพราะฉะนั้นการที่ Blue Team จะดำเนินการเพียงแค่การป้องกันอย่างเดียวไม่พอ จะต้องเพิ่มและพัฒนาปรับปรุงในเรื่องของการค้นหาหรือ Detection แต่เดิมที่เคยค้นหาโดยอาศัยรูปแบบหรือ Signatures เป็นหลัก จะต้องมีการสังเกตหรือ Observe IT Assets ต่างๆ ด้วย เช่น Identities, Devices, Applications, และอื่นๆ เพื่อมองหาสิ่งผิดปรกติหรือสิ่งที่น่าสงสัย เพราะฉะนั้นจากประเด็นดังกล่าวนี้สิ่งที่จะต้องนำเอาเข้ามาเพื่อทำการสร้าง Modern Blue Team ประกอบไปด้วย:

1. Behavioral Analytic/Detection คือ การค้นหาหรือตรวจสอบดูว่ามีสิ่งผิดปรกติ, พฤติกรรมที่น่าสงสัย, และอื่นๆ ที่สุ่มเสี่ยงที่จะก่อให้เกิดความไม่ปลอดภัยกับ IT Assets ต่างๆ ขององค์กร เช่น Identities, Devices, และอื่นๆ ตามที่เกริ่นไว้ก่อนหน้านี้ครับ

2. Identity Management คือ การบริหารจัดการรวมถึงการสร้างความปลอดภัยให้กับ Identities ต่างๆ ไม่ว่าจะเป็น Users, Groups, Apps, รวมถึง Services ที่ต้องการเข้าถึง Resources หรือ Data ขององค์กร นอกจากเรื่องของการบริหารจัดการแล้ว ยังต้องพิจารณถึงเรื่องของการป้องกัน Identities เหล่านี้ด้วย รวมถึงการที่ Blue Team จะต้องเข้าไปทำการตรวจสอบ Logs, เหตุการณ์ต่างๆ, และอื่นๆ ที่เกี่ยวข้องกับ Identity ด้วย เพราะ ณ วันนี้ Identity ถือว่าเป็น New Security Perimeter ที่องค์กรจะต้องพิจารณาในการจัดการและป้องกันเป็นอันดับแรก เพราะ Identity คือ เป้าหมายแรกของ Attackers ครับ

3. Integration และ Correlation คือ การรวบรวมนำเอา Signals ตลอดจนข้อมูลต่างๆ จาก IT Assets เช่น Identities, Endpoints (Devices), Applications, และอื่นๆ ที่เกี่ยวข้องและสัมพันธฺ์กันเพื่อทำให้ Blue Team เข้าใจและเห็นภาพทั้งหมดว่าเป็นอย่างไร มีอะไรที่เกี่ยวข้องบ้าง ตลอดจนรายละเอียดต่างๆ หากมีเหตุการณ์หรือ Incident เกิดขึ้น ส่งผลทำให้การ Investigate และ Response ได้รวดเร็วและมีประสิทธิภาพ

จากทั้ง 3 สิ่งที่ผมได้ไป เราจะต้องนำมาพิจารณาวางแผนในการสร้าง Modern Blue Team โดยหา Security Solutions ที่มีความสามารถครอบคลุมกับทั้ง 3 สิ่งบวกกับความสามารถอื่นๆ เข้ามาเป็นเครื่องมือให้กับ Blue Team ใช้ในการดำเนินการ Security Operations ให้มีประสิทธิภาพมากขึ้น โดยถ้า Map Microsoft Security Solutions เข้ากับสิ่งๆ ต่างๆ ที่ผมได้อธิบายไว้ข้างต้น คือ

1. Microsoft Defender Product Family, Services ที่เกี่ยวข้อง คือ Microsoft Defender XDR (ประกอบไปด้วย Microsoft Defender for Office 365, Microsoft Defender for Identity, Microsoft Defender for Endpoint, และ Microsoft Defender for Cloud Apps) ที่จะเข้ามา Protect และ Detect สิ่งผิดปรกติ, พฤติกรรมที่น่าสงสัย, และอื่นๆ ที่อาจจะเป็นการ Attack 

2.  Microsoft Entra Product Family, Service หลักที่เกี่ยวข้อง คือ Microsoft Entra ID กับ Features ต่างๆ ที่จะเข้าบริหารจัดการและสร้างความปลอดภัยให้กับ Identities ขององค์กร

3. Microsoft Sentinel, Service ตัวนี้จะให้บริการ SIEM และ SOAR โดยสามารถที่จะทำงานร่วมกับ Security Solutions ต่างๆ ของทั้ง Microsoft และ 3rd Party ในการ Correlate Signals และอื่นๆ ที่เกี่ยวข้องหรือสัมพันธ์กันรวบรวมมาเป็นไว้จุดเดียวหรือเป็น Incident เพื่อให้ Blue Team สามารถดูและทำความเข้าใจกับ Incident และรายละเอียดต่างๆ ในการทำ Investigation และส่งผลทำให้การ Response ได้อย่างรวดเร็วและมีประสิทธิภาพ *ณ ปัจจุบันทาง Microsoft ได้มีการปรับปรุงเปลี่ยนแปลง Microsoft Sentinel ภายใต้คอนเซปที่เรียกว่า "Unified Security Operations Platform" คือ การนำเอา Microsoft Sentinel ใส่เข้าไปใน Portal ของ Microsoft Defender เพื่อทำให้การจัดการรวมถึงการทำ Security Operations มีความสะดวกและยืดหยุ่นมากขึ้นครับ

และทั้งหมดนี้คือภาพรวมของการสร้าง Modern Blue Team ด้วย Microsoft Security Solutions/Ecosystem ครับผม.....

Agentless Machine Scanning ใน Microsoft Defender for Cloud (MDC)

      สวัสดีครับทุกท่านสำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Agentless Machine Scanning ใน Microsoft Defender for Cloud กันครับ ซึ่งถือเป็นความสามารถหรือฟีเจอร์ที่สำคัญในการ Secure และ Protect Workloads (Servers หรือ VMs) ในองค์กรครับ ก่อนที่จะเข้าสู่เรื่องราวของ Agentless Machine Scanning ขออนุญาตอธิบายคร่าวๆ เกี่ยวกับ Microsoft Defender for Cloud (MDC) ซักหน่อยครับ เผื่อว่าผู้อ่านท่านใดอาจจะยังไม่คุ้นเคยกับ Microsoft Defender for Cloud หรือ MDC ครับ

เริ่มจาก Microsoft Defender for Cloud ถือว่าเป็นเซอร์วิสหนึ่งใน Microsoft Azure ครับ และอีกมุมหนึ่งถือว่า Microsoft Defender for Cloud เป็นสมาชิกอยู่ใน Microsoft Defender Family ครับ ซึ่งเป็น Family ที่ถูกออกแบบมาเพื่อทำ Threat Detection และ Protection ให้กับ IT Environments ขององค์กร โดยครอบคลุมท้้ง Hybrid และ Multi-Cloud ครับ โดย Microsoft Defender Family เป็นเพียงแค่ส่วนหนึ่งของ Microsoft Security Ecosystem ครับ เพราะทาง Microsoft ยังมี Security Solutions ต่างๆ อีกเยอะครับ รวมถึงยังมีการนำเอา AI เทคโนโลยีเข้ามาช่วยในเรื่องของ Cybersecurity อีกด้วยครับ รูปด้านล่างเป็น ภาพรวมที่แสดงถึง Microsoft Security Solutions ที่มี ณ ตอนนี้ครับ

สำหรับ Microsoft Defender for Cloud จะให้บริการ Security Services/Solutions หลักๆ ดังนี้:

- Cloud Security Posture Management (CSPM)

- Cloud Workload Protection Platform (CWPP)

- Cloud-Native Application Protection Platform (CNAPP)

และสำหรับบทความนี้เรื่องของ Agentless Machine Scanning ซึ่งเป็นความสามารถหนึ่งของ Microsoft Defender for Cloud จะอยู่ภายใน Security Services/Solutions ที่ชื่อว่า Cloud Workload Protection Platform หรือ CWPP ครับ โดย Agentless Machine Scanning จะเข้ามาช่วยในการ Secure และ Protect Workloads นั่นก็คือ Servers หรือ VMs นั่นเองครับ นั่นหมายความถ้าท่านผู้อ่านต้องการที่จะป้องกัน Servers หรือ VMs ที่อยู่ใน IT Environments ของท่าน สามารถพิจารณนำเอา Microsoft Defender for Cloud ไปประยุกต์ใช้งานได้ครับ

กลับมาที่เรื่องของการ Secure และ Protect Servers หรือ VMs ใน Microsoft Defender for Cloud นั้นจะเกี่ยวข้องกับ CWPP ดังนั้นจะต้องมีการวางแผน, ออกแบบ, เพื่อเตรียมความพร้อมในการ Secure และ Protect Servers หรือ VMs เหล่านั้น โดยการติดตั้ง Agents ไปยัง Servers หรือ VMs ที่ต้องการครับ ในยุคแรกๆ ของ Microsoft Defender for Cloud, ตัวของ Agent ที่ใช้คือ Azure Log Analytics Agent ซึ่งปัจจุบันไม่มีให้ใช้งานแล้วครับ โดยถูกแทนด้วย Agent ตัวต่อมา คือ Azure Monitor Agent หรือเรียกสั้้นๆ ว่า AMA ครับ จากนั้นก็มาถึง Agentless (นั่นก็คือ Agentless Machine Scanning ครับ) ครับ โดยการที่ Microsoft ทำการปรับปรุงและเปลี่ยนแปลงจาก Agent-Based มาเป็น Agentless (Agentless Machine Scanning) นั้นถือว่าเป็นการเปลี่ยนแปลงที่สำคัญในการ Secure และ Protect Workloads ในองค์กรเลยทีเดียวครับ เพราะอย่างที่เราทราบกันโดยปรกติ คือ หากองค์กรมีการนำเอา Security Solutions ใดๆ ก็ตามมาใช้งานในองค์กร ก็จะต้องมีการติดตั้งส่วนประกอบต่างๆ ของ Security Solutions ดังกล่าวรวมถึง Agent ด้วยครับ แต่สำหรับ Microsoft Defender for Cloud ตัวของมันเองไม่มีการติดตั้งใดๆ ที่ IT Environments ของลูกค้า หมายความว่า Microsoft Defender for Cloud ไม่ต้องการ Servers หรือ VMs ใดๆ เพื่อติดตั้งตัวมันเพื่อทำงานครับ เพราะ Microsoft Defender for Cloud รันอยู่ใน Data Centers ของ Microsoft หรือพูดง่ายๆ คือ รันและทำงานอยู่บน Cloud นั่นเองครับ

และในการที่เราต้องการ Secure และ Protect (Servers หรือ VMs) ที่ผมได้อธิบายไปก่อนหน้านี้ก็เช่นกันครับ ณ ตอนนี้เราไม่ต้องติดตั้ง Agent ใดๆ ของ Microsoft Defender for Cloud เหมือนกับแต่ก่อนครับ แต่ต้องบอกทุกท่านไว้ก่อนว่า Agentless เป็นเพียง Option หนึ่งที่เราสามารถนำไปพิจารณาครับ นอกเหนือจาก Agent-Based แบบก่อนหน้านี้ครับ ข้อดีของ Agentless คือ ไม่มีการติดตั้งสิ่งใดๆ ไปยัง Servers หรือ VMs ที่จะให้ Microsoft Defender for Cloud ไปทำการ Secure และ Protect ครับ ดังนั้นจะไม่มีการไปกระทบกับการทำงานของ Servers หรือ VMs นั้น ไม่ว่าจะเป็นเรื่องของ Performance และอื่นๆ ครับ เพราะเป็นสิ่งที่องค์กรกังวลครับ

หลังจากทำการเปิดใช้งานหรือ Activate ตัว Agentless Machine Scanning แล้ว มันจะเริ่มทำงานโดยทำการเก็บรวบรวมข้อมูลจาก Servers หรือ VMs มาทำการตรวจสอบและค้นหาเป็นระยะๆ ไม่ใช้แบบ Real-Time ครับ โดยการทำ Read-Only Snapshots ของ Servers หรือ VMs แล้วมาทำรวบรวมข้อมูลต่างๆ เช่น Installed Apps, Configurations, OS Versions, และอื่นๆ  ดังนี้:

- ทำการ Scans Endpoint Detection and Response (EDR) Settings เพื่อทำการประเมินค่า Settings ของ EDR ที่รันอยู่ใน Servers หรือ VMs ว่าถูกต้องหรือไม่ ถ้า Servers หรือ VMs ดังกล่าวทำงานร่วมกับหรือ Integrate กับ Microsoft Defender for Endpoint หรือ MDE

- ทำการ Scans Software Inventory และทำงานหรือ Integrate กับ Microsoft Defender Vulnerability Management หรือ MDVM

- ทำการ Scans Vulnerabilities เพื่อประเมินช่องโหว่ ด้วย Microsoft Defender Vulnerability Management หรือ MDVM

- ทำการ Scans Malware โดยทำงานร่วมกับ Microsoft Defender Antivirus

- อื่นๆ 

ข้อดีของ Agentless Machine Scanning 

- Zero Performance Impact เพราะไม่มีการติดต้ั้งใดๆ ไปยัง Servers หรือ VMs

- Simplified Deployment เพราะไม่มีการดาวน์โหลดและติดต้้งส่วนประกอบหรือสิ่งใดๆ ที่ Servers หรือ VMs ที่ต้องการ Secure และ Protect

- อื่นๆ

สำหรับการเรียกใช้งาน Agentless Machine Scanning นั้นจะขึ้นอยู่กับ Defender Plan ในส่วนของ Cloud Workload Protection Platform (CWPP) ในส่วนของ Workloads ที่เป็น Servers โดยจะมี 2 Plans ให้เลือกพิจารณา คือ Plan 1 และ Plan 2 ครับ ความแตกต่างของแต่ละ Plan ในการ Secure และ Protect Servers หรือ VMs คือ ฟีเจอร์และราคาครับ สำหรับ Agentless Machine Scanning เป็นฟีเอจร์หรือความสามารถที่อยู่ใน Plan 2 ครับ ดังรูปด้านล่างครับ

สำหรับการ Secure และ Protect Servers หรือ VMs ในองค์กรด้วย Microsoft Defender for Cloud นั้นในความเป็นจริงแล้วยังมีอีกหลายสิ่งที่จะต้องพิจารณาครับ นอกเหนือจาก Agentless Machine Scanning แล้ว ยังมี Microsoft Defender for Endpoint หรือ MDE ด้วยครับ เพราะ ณ ตอนนี้ Microsoft Defender for Cloud และ Microsoft Defender for Endpoint ทั้ง 2 Services นี้ Integrate ทำงานร่วมกันในการ Secure และ Protect Servers หรือ VMs ครับ และ Best Practices ในการดำเนินการ Secure และ Protect Servers หรือ VMs ควรพิจารณานำเอา Agentless Machine Scanning และ MDE Agent (MDE Sensor) ตลอดจน Services หรือส่วนประกอบอื่นๆ มาใช้งานร่วมกันครับ

รายละเอียเพิ่มเติมเกี่ยวกับ Agentless Machine Scanning สามารถไปที่ Link นี้ได้เลยครับ, Agentless machine scanning in Microsoft Defender for Cloud - Microsoft Defender for Cloud | Microsoft Learn

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

และทั้งหมดนี้คือเรื่องราวของ Agentless Machine Scanning ใน Microsoft Defender for Cloud ครับผม.....

Microsoft Cybersecurity ตอนที่ 6 (Security Adoption Framework)

      สวัสดีครับทุกท่าน กลับมาพบกันเช่นเคยครับ สำหรับบทความตอนนี้มีที่มาจากช่วงที่ผ่านมานั้น ผมมีโอกาสไปสอนและบรรยายเกี่ยวกับ Microsoft Cybersecurity Architect ให้กับลูกค้า ประกอบก่อนหน้านี้ผมเคยเขียนบทความเกี่ยวกับ Microsoft Cybersecurity ไปหลายตอน เพื่อแนะนำให้ทุกท่านได้รู้จักและทำความเข้าใจกับ Frameworks และ Models ต่างๆ ที่เกี่ยวข้องกับเรื่องของ Security เพื่อสามารถนำไปประยุกต์ใช้งานในการวางแผนออกแบบ Cybersecurity Architecture เพื่อทำการป้องกัน IT Environments (ครอบคลุมทั้ง Hybrid และ Multi-Cloud) ขององค์กร ไม่ว่าจะเป็น Cyber Kill Chain, Zero Trust, Defense In-Depth, และอื่นๆ ท่านใดที่ยังไม่รู้จักสามารถย้อนไปอ่านบทความของผมได้เลยครับ

สำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Framework หนึ่ง ซึ่งถูกออกแบบมาให้ใช้งานร่วมกับ Microsoft Zero Trust Model, Cloud Adoption Framework (CAF) ใน Secure Phase, Microsoft Cybersecurity Reference Architectures (MCRA) รวมถึง CIA Triad ครับ โดย Framework นี้มีชื่อว่า "Security Adoption Framework" หรือเรียกย่อๆ ว่า "SAF" ครับ

*Microsoft Zero Trust Model ถือว่าเป็นหัวใจและเป็นสิ่งสำคัญสำหรับการวางแผนและออกแบบ Cybersecurity Architecture และยังถือว่าเป็นหัวใจของ MCRA อีกด้วยครับ รายละเอียดเพิ่มเติมสามารถย้อนไปอ่านบทความของผมก่อนหน้านี้ได้ครับ

*CIA Triad คือ สิ่งสำคัญหรือเป็นพื้นฐานสำคัญสำหรับ Cybersecurity เมื่อ Security Architect จะทำการวางแผน, ออกแบบ, และทำการ Implement Security Solutions ต่างๆ เพื่อทำการ Secure & Protect IT Environments ขององค์กร โดย CIA Triad มีกฎหลัก 3 ข้อ คือ Confidentiality, Integrity, และ Availability ครับ

Security Adoption Framework (SAF) คืออะไร?

เป็น Framework ที่ถูกออกแบบมาเพื่อช่วยองค์กรในการนำเอา Security Best Practices ต่างๆ มาประยุกต์ใช้งานในองค์กรตามที่องค์กรต้องการ โดย SAF เตรียมแนวทางในการนำเอา Security Best Practices ดังกล่าวเข้ามาประยุกต์ใช้งานในองค์กร โดยมี Stages ดังนี้:

Stage 1: Assess คือ Stage ที่เริ่มด้วยการทำการประเมิน Security Posture ณ ปัจจุบันขององค์กรว่าเป็นอย่างไร เพื่อ Identify หรือกำหนด Gaps หรือ Risks ที่เกี่ยวข้องและทำการจัดลำดับ (Prioritize) ที่จำเป็นต่อการปรับปรุงเพื่อทำให้ Security Posture ขององค์กรมีความแข็งแรงและปลอดภัยมากขึ้น

*Security Posture คือ ภาพรวมของ Security Status ของ IT Assets/Services ที่อยู่ใน IT Environments ขององค์กร

Stage 2: Plan: คือ Stage ที่นำเอาผลลัพธ์ที่ได้จากวิเคราะห์และประเมิน Security Posture ณ ปัจจุบันขององค์กรจาก Stage 1 มาทำการพัฒนาหรือ Develop แผน (Plan) ในการปรับปรุง Security Posture ขององค์กร โดยแนวทางดังกล่าวจะประกอบไปด้วย Outline และ Actions ตามการจัดลำดับความสำคัญและมีการนำเอา Best Practices ต่างๆ มาช่วยในการพิจารณา

Stage 3: Implement คือ Stage ที่นำเอา Plan ใน Stage ก่อนหน้านี้มาทำการปรับปรุงเรื่องความปลอดภัยตามที่วางแผนและกำหนดไว้ โดยใน Stage นี้ คือ การนำเอา Microsoft Security Solutions ต่างๆ เข้าช่วยในการป้องกัน

Stage 4: Manage คือ Stage ที่จะต้องวางแผนเพื่อดำเนินการตรวจสอบค้นหาและจัดการ Security ใน IT Environments ขององค์กรอย่างต่อเนื่อง อีกทั้งยังสามารถปรับหรือเพิ่มเติมการค้นหาและป้องกันเมื่อมีภัยคุกคามใหม่เกิดขึ้น เพื่อช่วยลดความเสี่ยงที่องค์กรจะถูกโจมตีจากภัยคุกคาม (Threats) 

และทั้งหมดนี้คือเรื่องราวของ SAF คร่าวๆ ที่อยากให้ทุกท่านได้รู้จักครับผม.....