วันอาทิตย์ที่ 30 กรกฎาคม พ.ศ. 2566

Microsoft Entra Conditional Access (Azure AD Conditional Access)

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมอยากจะนำะเสนอความสามารถหรือฟีเจอร์หนึ่งของ Microsoft Entra ID หรือชื่อเดิมคือ Azure Active Directory (Azure AD) ให้ทุกท่านได้รู้จักกันครับ โดยฟีเจอร์ดังกล่าวนี้มีชื่อว่า "Azure AD Conditional Access" ชื่อใหม่คือ "Microsoft Entra Conditional Access" ในบทความนี้ผมขอเรียกสั้นๆ ว่า "Conditional Access" นะครับ สำหรับ Conditional Access อยู่ใน Microsoft Entra ID (Azure AD) นานแล้วครับ โดยจะอยู่ใน Azure AD Premium P1 หรือชื่อใหม่ Microsoft Entra ID P1 (Edition หนึ่งของ Azure AD หรือ Microsoft Entra ID) หรืออยู่ใน Microsoft 365 SKUs ต่างๆ เช่น EMS E3, Business Premium, เป็นต้นครับ รายละเอียดเพิ่มเติมสามารถไปที่ Link นี้ได้เลยครับ, แผนและราคาของ Microsoft Entra | Microsoft Security












และต้องบอกว่า Conditional Access จัดว่าเป็นฟีเจอร์ที่เกี่ยวข้องกับ Security ที่มีประโยชน์อย่างมากสำหรับองค์กรที่กำลังวางแผนเพื่อดำเนินการเรื่องของ Security โดยเฉพาะที่เกี่ยวข้องกับ Identity ครับ


Microsoft Entra Conditional Access (Azure AD Conditional Access) คืออะไร?

อย่างที่เกริ่นไว้ข้างต้นว่า Conditional Access เป็นฟีเจอร์หรือความสามารถหนึ่งของ Microsoft Entra ID และยังเป็นส่วนหรือ Engine ที่สำคัญของ Zero Trust Model อีกด้วยครับ เพราะ Conditional Access จะทำนำเอา Signals จาก Sources ต่างๆ มาเพื่อทำการตัดสินใจในการ Enforce Policy (Conditional Access Policy) ดังรูปด้านล่าง









สำหรับคอนเซปการทำงานของ Conditional Access จะเริ่มหลังจากผ่าน Authentication แรกไปเรียบร้อย (Authentication แรก คือ การที่ผู้ใช้งานใส่ Username และ Password) จากนั้น Conditional Access จะเริ่มทำงานโดยการตรวจสอบและประเมินว่าผู้ใช้งานคนดังกล่าวจะถูก Granted หรือ Denied Access ตาม Conditional Access Policy ที่กำหนด ในการใช้งานจริง เราจะต้องมีการวางแผนก่อนที่จะใช้งาน Conditional Access นะครับ สำหรับ Conditional Access Policy เป็นสิ่งที่เราจะต้องกำหนดเพื่อ Enforce ใช้งาน 

โดยการคอนเซปของ Conditional Access Policy ไม่มีอะไรซับซ้อนครับ ตรงไปตรงมา โดยคอนเซปจะอยู่ในรูปแบบของ If-Then Statements ยกตัวอย่างเช่น ถ้าเราต้องการให้ผู้ใช้งานในองค์กรเข้าถึงหรือ Access Resources ต่างๆ ผู้ใช้งานเหล่านั้นจะต้องทำดำเนินการผ่าน Actions ที่กำหนด เช่น ถ้าผมต้องการให้ทุกท่านเข้าถึงหรือ Access Resources (Apps) ทุกท่านจะต้องทำ MFA (Multi-Factor Authentication) ดังนั้นการที่เราหรือองค์กรพิจารณานำเอา Conditional Access เข้ามาใช้งานนั้น จะส่งผลทำให้เกิดความปลอดภัยมากขึ้นครับ

Signals จาก Sources ต่างๆ ที่ผมได้เกริ่นไว้ตอนต้น สามารถดูจากรูปด้านล่าง โดย Conditional Access จะรวบรวม Signals ต่างๆ มาเพื่อประเมินและตัดสินใจในการ Enforce Policy 












ตัวอย่างของ Signals เช่น

Users Or Groups Memberships, ใน Conditional Access Policy สามารถกำหนดหรือระบุ Users หรือ Groups เพื่อให้ครอบคลุมเฉพาะที่ต้องการ

IP Location Information, สามารถสร้าง Trusted IP Address Ranges เพื่อใช้ในการตัดสินใจในการใช้ Policy อีกทั้งยังสามารกำหนด Countries/Regions IP Ranges เพื่อทำการ Block หรือ Allow Traffic From

และยังมีบาง Signals ที่เกิดจากการ Integrate ทำงานร่วมกับฟีเจอร์ที่ชื่อว่า "Azure AD Identity Protection" (คาดว่าจะต้องเปลี่ยนขื่อเหมือนกันครับ) ของ Microsoft Entra ID (Azure AD) ครับ โดย Azure AD Identity Protection จะทำการ Detect 2 สิ่ง คือ Sign-In Risk และ User Risk ยกตัวอย่างเช่น Attackers ใช้เทคนิค Password Spray Attack, รวมถึงการที่ Attackers ทำการ Sign-In มาจาก New Countries, Anonymous IP Address, และอื่นๆ สิ่งเหล่านี้จะถูกตรวจสอบและ Azure AD Identity Protection จะ Detect เจอครับ และเมื่อมีการทำงานร่วมกัน เมื่อเจอเหตุการณ์ที่ผิดปรกติที่น่าสงสัยซึ่งมีความเสี่ยงกับ Identity ดังรูปด้านล่างครับ











รายละเอียดเพิ่มเติมสามารถไปที่ Link นี้ได้เลยครับ, What is Conditional Access in Azure Active Directory? - Microsoft Entra | Microsoft Learn













และใน Conditional Access จะมี Templates ต่างๆ เอาไว้ให้เราสามารถนำไปพิจารณาเพื่อนำมาประยุกต์ใช้งานในองค์กรได้ครับ รายละเอียดเพิ่มเติมตาม Link นี้ครับ, Secure your resources with Conditional Access policy templates - Microsoft Entra | Microsoft Learn













และทั้งหมดนี้คือเรื่องราวเริ่มต้น ของ Microsoft Entra Conditional Access หรือ Azure AD Conditional Access ครับผม.....



วันจันทร์ที่ 17 กรกฎาคม พ.ศ. 2566

มาทำความรู้จักกับ Microsoft Entra Permissions Management

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Service หนึ่ง ซึ่งเป็นหนึ่งในสมาชิกของ Microsoft Entra Family ครับ ซึ่งใน Microsoft Entra Family จะประกอบไปด้วยหลาย Services เลยครับ ยกตัวอย่างเช่น Azure Active Directory หรือชื่อใหม่คือ Microsoft Entra ID เป็นต้นครับ โดย Service ดังกล่าวนี้มีชื่อว่า "Microsoft Entra Permissions Managment" ครับ โดยคอนเซปเบื้องต้นของ Microsoft Entra Permissions Management นั้นจะให้บริการ Cloud Infrastructure Entitlement Management หรือเรียกกันย่อๆ ว่า CIEM Solution ครับ 


Cloud Infrastructure Entitlement Management (CIEM) คืออะไร?

CIEM Solution เป็น Service หนึ่งที่ให้บริการอยู่บน Cloud โดยให้บริการอยู่ในรูปแบบของ SaaS ซึ่งทำหน้าที่ในเรื่องของการบริหารจัดการ Identities และ Permissions ใน Multi-Cloud Environment ครับ โดย CIEM ที่ว่านี้สามารถทำงานร่วมกับ Zero Trust Model โดยเฉพาะกฎข้อหนึ่งของ Zero Trust Model คือ A Least-Privilege Access ครับ โดยตัวของ CIEM จะเข้ามาช่วยองค์กรในการตรวจสอบ (Monitor), แจ้งเตือน (Alerts), และทำการแก้ไข (Remediate) สิ่งผิดปรกติหรือพฤติกรรที่น่าสงสัยที่อาจจะก่อให้เกิดความสุ่มเสี่ยง

และ CIEM จะทำการตรวจสอบในส่วนของ Identities อย่างต่อเนื่องและยังทำการประเมิน Permissions ที่มีถูก Assigned ให้กับ Identities เพื่อเข้าถึง Resources ต่างๆ ใน Environments ดังกล่าว (ครอบคลุม Multi-Cloud Environments) โดยใช้ Analytics, เทคโนโลยี ML (Machine Learning) และอื่นๆ ในการค้นหา Identities ที่มีสิทธิ์หรือ Permissions มากเกินไปหรือได้ Permissions มากเกินกว่าที่ใช้งาน, เพื่อดูว่ามีสิ่งผิดปรกติหรือพฤติกรรมที่น่าสงสัยเกิดขึ้นหรือไม่, และอื่นๆ  สุดท้ายองค์กรก็จะทำการปรับปรุงเปลี่ยนแปลงทั้งในเรื่องของ Identities และ Permissions ให้เป็นไปตามความต้องการหรือ Compliance ที่องค์กรต้องการได้ครับ


Microsoft Entra Permissions Management คืออะไร?

สำหรับ Microsoft Entra Permissions Management คือ หนึ่งในสมาชิกของ Microsoft Entra Family ดังรูปด้านล่าง และ Microsoft Entra Permissions Management เป็น Service ที่ให้บริการ Cloud Infrastructure Entitlement Management (CIEM) Solution ตามที่อธิบายไว้ในหัวข้อก่อนหน้านี้ 













โดย Microsoft Entra Permissions Managment ทำให้เราสามารถเห็นภาพและเข้าใจถึงเรื่องราวของ Identities และ Permissions ที่ใช้งานอยู่นั้น (Access Control) เป็นอย่างไร ส่งผลทำให้ผู้ดูแล (Security Operations Administrators) ตลอดจนผู้ที่มีบทบาทหน้าที่เกี่ยวข้องสามารถเข้าไปบริหารจัดการเรื่องของการเข้าถึง Resources ต่างๆ (Permissions ที่ถูก Assigned ให้กับ Identities ต่างๆ) ไม่ว่าจะอยู่ใน Microsoft Azure, Amazon Web Services (AWS), และ Google Cloud Platform (GCP) เป็นไปตามความต้องการหรือตาม Compliance ที่องค์กรกำหนด 















โดยตัวของ Microsoft Entra Permissions Management จะทำหน้าที่ต่างๆ เช่น ตรวจสอบและค้นหาพฤติกรรมผิดปรกติหรือที่น่าสงสัยที่อาจจะก่อให้เกิดความเสี่ยง, ตรวจสอบ Permissions ว่ามีมากเกินไปหรือมากเกินกว่าความจำเป็นต่อการใช้งาน (โดยตรวจสอบจาก Permissions ที่ถูก Assigned ไปกับ Permissions ที่ถูกใช้งานจริง), Enforce A Least-Privilege, และอื่นๆ โดยอาศัยการทำงานผ่านขั้นตอนหลักๆ ของ Microsoft Entra Permissions Management อย่างต่อเนื่อง คือ Discover, Remediate, และ Monitor ดังรูปด้านล่าง






นอกจากนี้แล้ว Microsoft Entra Permissions Management ยังมาพร้อมกับแนวคิดและวิธีการในการบริหารจัดการ Identities และ Permissions ในรูปแบบใหม่ ดังรูปด้านล่าง เช่น การให้สิทธิ์ (Grant Permissions) จะให้จากประวัติการใช้และ Activity, การให้สิทธิ์หรือ Grant สิทธิ์โดยมีการกำหนดระยะเวลาหรือ On-Demand, และการตรวจสอบ (Monitor) อย่างต่อเนื่องตามที่อธิบายไว้ก่อนหน้านี้ครับ













สำหรับเรื่องราวของ Microsoft Entra Permissions Management ยังมีอีกเยอะมากครับ บทความนี้เป็นเพียงจุดเริ่มต้นในการพาทุกท่านมาทำความรู้จักกับ Service นี้ สำหรับรายละเอียดเพิ่มเติมของ Microsoft Entra Permissions Management สามารถไปที่ Link นี้ได้เลยครับ, What's Permissions Management? - Microsoft Entra | Microsoft Learn















และทั้งหมดนี้คือเรื่องราวของ Microsoft Entra Permissions Management ซึ่งเป็นหนึ่งในสมาชิกของ Microsoft Entra ครับผม.....



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

เมื่อ Azure Active Directory กลายเป็น Microsoft Entra ID

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะเป็นการอัพเดทเรื่องราวของ Azure Active Directory (Azure AD) ซึ่งเป็น Service ที่สำคัญที่ใช้ในการบริหารจัดการ Identity หรือให้บริการในส่วนของ Identity and Access Management (IAM) ครับ เพราะฉะนั้นถ้าองค์กรใดก็ตาม หากมีการนำเอา Cloud Services ของ Microsoft เช่น Microsoft Azure, Microsoft 365, และอื่นๆ มา Adopt หรือประยุกต์ใช้งานในองค์กร  Azure AD ก็จะเป็น Service หนึ่งที่ถูกนำมาใช้งานอย่างแน่นอนครับ โดย Azure AD จะเข้าจัดการ Identity ต่างๆ ตามความต้องการหรือ Scenarios ที่องค์กรต้องการ 


ผมขออนุญาตยกตัวอย่าง Scenarios หนึ่งที่ชื่อว่า "Hybrid Identity" ซึ่งถือว่า Scenarios ยอดนิยม Scenarios หนึ่งครับ โดย Hybrid Identity Scenario คือ การ Sync Identities จาก On-Premise (จาก Active Directory Domain Service หรือ AD DS) มายัง Azure AD (Tenant) เพื่อให้องค์กรได้ Benefit ที่เรียกว่า "Single Sign-On" หรือ SSO ส่งผลทำให้ผู้ใช้งานในองค์กรดังกล่าวนั้นสามารถเข้าถึงหรือ Access Resources ต่างๆ ที่อยู่ที่ไหนก็ได้ (Hybrid Cloud Environment) โดยใช้ Identity เดียว ทำให้เกิดความยืดหยุ่นและเพิ่มประสิทธิภาพในการทำงานของผู้ใช้งานในองค์กร และนี้คือตัวอย่างหรือ Scenarios หนึ่งที่เราสามารถใช้งาน Azure AD ได้ครับ แต่ในความเป็นจริงแล้ว Azure AD ยังมีความสามารถหรือฟีเจอร์อีกเยอะมากครับ ขอยกตัวอย่างเพิ่มเติมอีกซักนิด เช่น ความสามารถในการ Integrate หรือไปทำงานร่วมกับ SaaS หรือ Cloud Applications เพื่อดำเนินการในส่วนของ Authentication และ Authorization, การทำงานร่วมกับ Endpoints หรือ Devices, และอื่นๆ ครับ


สำหรับท่านผู้อ่านท่านใดยังไม่ค่อยรู้จักหรือยังไม่คุ้นเคยกับ Azure Active Directory (Azure AD) สามารถอ่านบทความนี้ของผมได้เลยครับ, WT Blog (ITGeist): Azure Active Directory (Azure AD) (itgeist5blog.blogspot.com) หรือดู Clip VDO นี้ครับ, https://youtu.be/UlyssmXjnrI















และเมื่อวานนี้ (ณ เวลาที่ผมเขียนบทความนี้) ทาง Microsoft ได้ประกาศแจ้งเปลี่ยนชื่อของ Azure Active Directory (Azure AD) มาเป็น "Microsoft Entra ID" นั่นหมายความนี่คือชื่อใหม่ของ Azure AD ครับ !!!!! และถ้าท่านใดติดตามข่าวสารเกี่ยวกับ Azure AD ในช่วงที่ผ่านมาหรือติดตาม ITGeist FB ของผม ผมได้มีการอัพเดทก่อนหน้านี้ว่าทาง Microsoft มี Family ใหม่ที่ชื่อว่า "Microsoft Entra" ซึ่งประกอบด้วย Services หลาย Services ใน Family ดังกล่าว และหนึ่งในนั้นคือ Azure AD หรือ Microsoft Entra ID นั่นเองครับ ดังนั้นพอมาถึงเวลานี้ทาง Microsoft ก็เลยเปลี่ยนชื่อ Azure AD เพื่อให้สอดคล้องกับ Family (Microsoft Entra) ดังกล่าวครับ รูปด้านล่าง คือ อัพเดทล่าสุดของ Microsoft Entra Family ครับ













เมื่อชื่อของ Azure AD (ชื่อใหม่ Microsoft Entra ID) เปลี่ยนแล้ว สิ่งที่จะถูกเปลี่ยนแปลงตามก็คือ ชื่อของ Azure AD Editions ต่างๆ ครับ  ถ้าท่านใดคุ้นเคยก็จะทราบว่าตัวของ Azure AD มีหลาย Editions ครับ โดยความแตกต่างของแต่ละ Editions คือ ฟีเจอร์และราคา ตัวอย่างของ Azure AD Editions เช่น Azure AD Free, Azure AD Premium P1, Azure AD Premium P2, และอื่นๆ รูปด้านล่าง คือ ชื่อของ Azure AD (Microsoft Entra ID) Editions  ที่มีการเปลี่ยนแปลงครับ













นอกจาการเปลี่ยนชื่อของ Azure AD (ชื่อใหม่ Microsoft Entra ID) และ Editions ตามที่ผมได้อธิบายไว้ข้างต้นแล้ว สิ่งที่อยากจะเน้นให้ทุกท่านเข้าใจตรงกัน คือ การเปลี่ยนปลงดังกล่าวนี้จะเป็นการเปลี่ยนเฉพาะชื่อเท่านั้นนะครับ (ตามที่ทาง Microsoft ประกาศหรือแจ้งไว้) เพราะฉะนั้น เราในฐานะผู้ใช้งานไม่ต้องดำเนินการใดทั้งสิ้นครับ ความสามารถหรือฟีเจอร์ต่างๆ ของ Azure AD ที่เราใช้งานกันอยู่ ก็ยังคงใช้งานได้ตามปรกติครับ และหลังจากที่ทาง Microsoft ได้ประกาศเปลี่ยนชื่อ Azure AD แล้ว ต่อจากนี้ไปก็จะเริ่มทยอยเปลี่ยนชื่อฟีเจอร์ของ Azure AD ด้วยครับ ยกตัวอย่างเช่น 

Azure AD Conditional Access เป็น Microsoft Entra Conditional Access

Azure AD MFA เป็น Microsoft Entra MFA

เป็นต้นครับ สำหรับรายละเอียดของการเปลี่ยชื่อดังกล่าวนี้ สามารถไปที่ Link นี้ได้เลยครับ, New name for Azure Active Directory - Microsoft Entra | Microsoft Learn

















และมีอีกหนึ่งเรื่องที่เกี่ยวข้องกับการเปลี่ยนชื่อของ Azure AD ที่ผมอยากจะอัพเดททุกท่านเพิ่มเติม นั่นก็คือ Portal ที่ใช้ในการบริหารจัดการ Identity ครับ แต่เดิมท่านผู้อ่านสามารถใช้ Portals ต่างๆ เช่น Microsoft Azure Portal, Microsoft 365 Admin Center, เป็นต้น ณ ตอนนี้เรายังคงใช้งาน Portals เหล่านี้ที่เราคุ้นเคยได้อยู่เหมือนเดิมครับ แต่สิ่งที่ทาง Microsoft ได้เตรียม Portal ใหม่ที่มีชื่อว่า "Microsoft Entra Admin Center", ดังรูปครับ
























และทั้งหมดนี้คืออัพเดทล่าสุดเกี่ยวกับ Azure AD ที่ทาง Microsoft ประกาศเปลี่ยนแแปลงครับผม.....

วันพฤหัสบดีที่ 22 มิถุนายน พ.ศ. 2566

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

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


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


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


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


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


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











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


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


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


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


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


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


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


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


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


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


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












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












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

วันศุกร์ที่ 16 มิถุนายน พ.ศ. 2566

Microsoft Defender for Cloud New Feature - Direct Onboarding

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


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











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


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




















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


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











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



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



วันจันทร์ที่ 12 มิถุนายน พ.ศ. 2566

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

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










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


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


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











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


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









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


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













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

วันศุกร์ที่ 19 พฤษภาคม พ.ศ. 2566

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

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


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


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

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


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






















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























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


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










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