วันอาทิตย์ที่ 29 ตุลาคม พ.ศ. 2566

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 ครับผม.....


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

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 ครับผม.....





วันเสาร์ที่ 2 กันยายน พ.ศ. 2566

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 ที่ผมนำมาฝากครับผม.....

วันพุธที่ 9 สิงหาคม พ.ศ. 2566

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 ครับผม.....

วันอาทิตย์ที่ 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 ประกาศเปลี่ยนแแปลงครับผม.....