Azure Active Directory Identity Governance

     สวัสดีครับทุกท่านกลับมาพบกันอีกเช่นเคย สำหรับบทความนี้จะเป็นเรื่องราวเกี่ยวกับ Identity ใน Microsoft Azure ครับ พอพูดหรือนึกถึงเรื่องของ Identity ก็จะเกี่ยวข้องกับ Service ที่ชื่อว่า Azure Active Directory หรือเรียกกันสั้นๆ ว่า Azure AD ซึ่งถือว่าเป็น Service ที่สำคัญมาก Service หนึ่งใน Microsoft Azure และ Cloud Services อื่นๆ ของ Microsoft เช่น Microsoft 365 เพราะเป็น Service ที่จะเข้ามาช่วยบริหารและจัดการ Identity หรือที่เรียกว่า Identity and Access Management (IAM) ครับ และแถบจะทุกองค์กรที่มีการนำเอา Microsoft Azure หรือ SaaS App ของ Microsoft เช่น Microsoft 365 ก็จะต้องวางแผนและพิจารณาการใช้งาน Azure AD เพื่อทำ Hybrid Cloud (Identity) เพื่อทำให้ผู้ใช้งานในองค์กรดังกล่าวสามารถเข้าถึงและใช้งาน Applications และ Data จากที่ไหนก็ได้ โดยใช้ Identity เดียวหรือที่เรียกว่า "Single Sign-On" หรือ SSO ครับ สำหรับท่านผู้อ่านท่านใดยังไม่คุ้นเคยกับ Azure AD ผมแนะนำให้ไปอ่านบทความของผมเกี่ยวกับเรื่องนี้ก่อนครับ  WT Blog (ITGeist): Azure Active Directory (Azure AD) (itgeist5blog.blogspot.com)

เอาล่ะครับเกริ่นมาพอสมควรแล้ว มาเข้าเรื่องกันเลยดีกว่าครับ สำหรับบทความตอนนี้ของผมจะเป็นเรื่องของ "Azure Active Directory Identity Governance" ครับ ซึ่งจะเป็นเรื่องราวที่ต่อยอดหรือเกี่ยวข้องกับการที่องค์กรได้ดำเนินการติดตั้งและใช้งาน Hybrid Cloud (Identity) โดยมีการ Sync Identities (User Accounts) จาก Active Directory Domain Service (AD DS) ซึ่งติดตั้งในเครื่องที่ทำหน้าที่เป็น Domain Controller ซึ่งอยู่ใน On-Premise Data Center ขององค์กร มายัง Azure AD Tenant เพื่อให้เราสามารถใช้ประโยชน์จาก SSO ตามที่ผมได้อธิบายไว้เมื่อซักครู่ครับ 

โดยเรื่องราวของ Azure Active Directory Identity Governance นั้นเป็นเรื่องที่หลายๆ องค์กรให้ความสนใจมากครับ และมีรายละเอียดค่อนข้างเยอะมากครับ โดยส่วนตัวผมได้มีโอกาสไปบรรยายตลอดจนให้คำปรึกษาอยู่หลายครั้งครับ แต่ในขณะเดียวกันยังมีอีกหลายๆ ท่านยังไม่ทราบหรือรู้จัก Azure Active Directory Identity Governance ผมจึงถือโอกาสนี้นำเอาเรื่องนี้มาเล่าสู่กันฟังครับ

Azure Active Directory Identity Governance คืออะไร?

Azure AD Identity Governance จะเป็นส่วนที่เข้ามาช่วยให้องค์กรปรับหรือรักษาสมดุลย์ทั้งในส่วนของการบริหารจัดการและความปลอดภัยครับ โดยคอนเซปของ Azure AD Identity Governance ตลอดจนฟีเจอร์ต่างๆ จะทำให้องค์กรมีความมั่นใจได้ว่าผู้ใช้งานได้รับสิทธิ์และเข้าถึง Applications หรือ Data ได้ตามที่กำหนดและถูกต้อง ตลอดจนไม่มีผู้ใช้งานคนใดสามารถเข้าถึง Applications หรือ Data ได้ทั้งๆ ที่ในการทำงานจริงผู้ใช้งานดังกล่าวไม่เกี่ยวข้องครับ เพราะถ้าเกิดเหตุการณ์ดังกล่าวจริงก็จะทำให้เกิดความสุ่มเสี่ยงต่อความไม่ปลอดภัยครับ เพราะฉะนั้น Azure AD Identity Governance จะทำให้องค์กรสามารถบริหารและจัดการงานต่างๆ ครอบคลุมทั้ง ผู้ใช้งานในองค์กร,  Business Partners และ Vendors ในการเข้าถึง Resources ต่างๆ ขององค์กรไม่ว่าจะอยู่ใน On-Premise และ Cloud ครับ โดยสิ่งที่ Azure AD Identity Governance จะเข้ามาช่วยดำเนินการสิ่งต่างๆ ดังต่อไปนี้ครับ:

- ควบคุมและดูแล Identity Lifecycle

- ควบคุมและดูแล Access Lifecycle

- ควบคุมและดูแล Privileged Access Lifecycle

นอกจากนี้แล้ว Azure AD Identity Governance ยังช่วยมาช่วยจัดการและตอบคำถามต่างๆ ด้านล่างสำหรับกรณีเหล่านี้อีกด้วยครับ:

- คำถามที่สอบถามว่า มีผู้ใช้งานท่านนี้ ณ ตอนนี้สามารถเข้าถึงResources ใดได้บ้าง (ซึ่งในความเป็นจริง

  ควรจะ เป็น Resources ที่เกี่ยวข้องกับหน้าที่การทำงานของผู้ใช้งานเท่านั้น)

- คำถามที่สอบถามว่า ผู้ใช้งานมีสิทธิ์อะไรบ้าง สำหรับเข้าถึงและใช้งาน Resources นั้นๆ

- คำถามที่สอบถามว่า ณ ปัจจุบันองค์การเข้าใจถึง Concept ของการทำ Access Control ได้อย่างถูกต้อง

   ตลอดจนได้นำเอาฟีเจอร์หรือ Services ต่างๆ เข้ามาช่วยหรือไม่

- คำถามที่สอบถามว่า ณ ปัจจุบันการทำ Access Control ขององค์กรนั้นสามารถให้ ผู้ตรวจสอบทำการ

  ตรวจสอบได้หรือไม่

คราวนี้เรามาไล่เรียงกันในแต่ละ Lifecycle ตามที่ผมได้เกริ่นไว้ในตอนต้นครับ

รู้จักกับ Identity Lifecycle

Identity Lifecycle จะเข้ามาช่วยองค์กรให้สามารถบริหารจัดการรวมถึงความปลอดภัยในอย่างสมดุลย์และเหมาะสม เช่น เมื่อมีพนักงานใหม่เข้ามาในองค์กร พนักงานดังกล่าวสามารถมี Identity เพื่อใช้ในการเข้าถึง Applications หรือ Data ตามหน้าที่ของเขาทันทีหรือไม่ ตลอดจนในเวลาต่อมาถ้ามีการเปลี่ยนบทบาทและนหน้าที่ของพนักงานคนดังกล่าว ผู้ดูแลระบบหรือผู้ที่มีหน้าที่เกี่ยวข้องสามารถดำเนินการจัดการได้ทันที โดยที่พนักงานดังกล่าวจะต้องได้รับสิทธิ์ที่ควรจะได้ตามบทบาทและหน้าที่เท่านั้น เพื่อเข้าถึง Resources ต่างๆ เช่น ถ้าพนักงานดังกล่าวมีการย้ายแผนก พนักงานดังกล่าวควรจะเข้าถึง Resources ต่างๆ ของแผนกใหม่เท่านั้น และไม่สามารถเข้าถึง Resources ต่างๆ ของแผนกเดิมที่เคยเข้าถึงได้อีกต่อไป

Identity Lifecycle ถือว่าเป็นหลักพื้นฐานหรือ Foundation ที่สำคัญสำหรับ Azure AD Identity Governance ในการควบคุมและดูแล รักษาความสมดุลย์และความเหมาะสมในส่วนของการบริหารจัดการและความปลอดภัย ในการเข้าถึง Resources ต่างๆ ไม่ว่าจะเป็น Applications และ Data ครับ และมีความเป็นไปได้ในองค์กรส่วนใหญ่ที่จะมีการ Integrate การทำงานร่วมกันระหว่าง Identity Lifecycle กับระบบ HCM (Human Capital Management) เช่น SAP, Oracle eBusiness, Oracle PepoleSoft เป็นต้น ซึ่งจะต้องดำเนินการด้วยความระมัดระวังมากขึ้นอีกครับ 

และยิ่งไปกว่านั้นการควบคุมและดูแลการเข้าถึง Resources ต่างๆ ณ ปัจจุบัน มิใช่ควบคุมเฉพาะพนักงานหรือผู้ใช้งานภายในองค์กรเท่านั้น ยังต้องควบคุมและดูแลบุคคลจากภายนอกที่จะเข้าถึง Resources ต่างๆ ในองค์กรอีกด้วย 

ซึ่งใน Azure AD ได้เตรียม Azure AD B2B หรือ B2C และ Azure AD Entitlement Management (เป็นฟีเจอร์ใน Azure AD Identity Governance) 

เข้ามาช่วยจัดการ, ควบคุมและดูแลสำหรับการที่องค์กรมีความต้องการแชร์ Resources ต่างๆ ให้กับบุคคลภายนอก (Guest Users หรือ External Partners) ครับ

รู้จักกับ Access Lifecycle

องค์กรโดยส่วนใหญ่มีความต้องการกระบวนการหรือ Process ในการบริหารจัดการการเข้าถึง Resources ต่างๆ มากกว่าแค่การสร้างหรือ Provisioning User Accounts เพราะองค์กรต้องการคอยตรวจสอบและสั

เกตถึงความเปลี่ยนแปลงการเข้าถึง Resources ต่างๆ  เช่น  Applications และ Data ของผู้ใช้งานนั้นๆ ว่าเป็นอย่างไร ดังนั้นจากประเด็นนี้ องค์กรจะมีการเตรียมวางแผนและดำเนินการต่างๆ เช่น การนำเอา Policy เข้ามาใช้ในการควบคุม, มีการ Delegate สิทธิ์ให้กับผู้ใช้งานและบุคคลภายนอก (External หรือ Guest Users) และอื่นๆ เป็นต้น โดยใน Access Lifecycle จะเกี่ยวข้องกับหลาย Services และฟีเจอร์ เช่น Azure AD B2B, B2C, Azure AD Entitlement Management, RBAC, และอื่นๆ เป็นต้น เพื่อมาช่วยตอบโจทย์ความต้องการขององค์กรข้างต้นครับ

รู้จักกับ Privileged Access Lifecycle

ที่ผ่านมาสิทธิ์ในการเข้าถึง Resources ต่างๆ นั้น องค์กรจะเป็นผู้กำหนดโดยจะมีแผนกหรือทีมงานที่เกี่ยวข้องเข้ามาวางแผน, จัดการ, และดำเนินการ เพื่อให้ผู้ใช้งานทั้งภายในและภายนอกเข้าถึงหรือมีสิทธิ์ในการเข้าถึง Resources ต่างๆ ตามที่องค์กรกำหนดเท่านั้น แต่ในการทำงานจริงมีความเป็นไปได้ที่ จะมีการเพิ่มหรือ Add สิทธิ์ให้กับผู้ใช้งานเพื่อดำเนินงานต่างๆ ตามความต้องการ ตามช่วงเวลาใดเวลาหนึ่ง, หรือจะมีการปรับเปลี่ยนเพิ่ม/ลด สิทธิ์ผู้ใช้งาน เนื่องจากมีการย้ายแผนก, และอื่นๆ เป็นต้น จากตัวอย่างที่ผมได้ยกขึ้นมานั้น สิ่งที่สะท้อนให้เห็นคือ องค์กรจะมีวิธีการในการบริหารจัดการประเด็นดังกล่าวนี้อย่างไร เพราะมีความเกี่ยวข้องกับความปลอดภัยกับ Resources ต่างๆ ขององค์กร  ซึ่งที่ผ่านมาจากประสบการณ์ของผมเอง องค์กรจะมีการนำเอา Solution อื่นๆ เข้ามาช่วยจัดการประเด็นดังกล่าวนนี้ครับ ซึ่งทำให้องค์กรหรือทีมที่เกี่ยวข้องจะต้องมีการเตรียมความพร้อมเพื่อเรียนรู้เครื่องมือเหล่านั้นเพื่อนำมาใช้จัดการกับประเด็นที่ผมได้เกริ่นไว้ครับ จากจุดนี้ทาง Microsoft คิดว่าควรจะมีการนำเอาประเด็นดังกล่าวนี้เข้ามาอยู่ใน Azure AD Identity Governance ด้วย เพื่อทำให้องค์กรหรือทีมงานที่เกี่ยวข้องสามารถบริหารจัดการและควบคุมทั้งหมดในรูปแบบที่เป็น Centralized Management เพื่อทำให้ง่ายและมีความยืดหยุ่นกับการนำไปใช้งานองค์กรครับ โดยใน Privileged Access Lifecycle จะเกี่ยวข้องกับ Services และฟีเจอร์ต่างๆ เช่น Azure AD, RBAC, Azure AD Privileged Identity Management (Azure AD PIM), และอื่นๆ เป็นต้น

รายละเอียดเพิ่มเติมสำหรับเรื่องของ Azure Active Directory Identity Governance สามารถไปที่ Link นี้ได้เลยครับ Identity Governance - Azure Active Directory | Microsoft Docs

และทั้งหมดนี้คือเรื่องราวเบื้องต้นของ Azure Active Directory Identity Governance ครับ เอาไว้โอกาสต่อไป ผมจะมานำเสนอเรื่องราวของฟีเจอร์ที่สำคัญใน Azure Active Directory Identity Governance นั่นก็คือ Azure AD Entitlement Management ครับ โปรดติดตามครับผม..... 

รู้จักกับ Windows 365 Cloud PC

      สวัสดีครับท่านผู้อ่านทุกท่าน สำหรับบทความนี้ผมมานำเสนอเรื่องราวที่หลายๆ ท่านให้ความสนใจกันมากเลยครับในช่วงเดือนที่ผ่านมา นั่นก็คือเรื่องราวของ Service ใหม่ของ Microsoft ที่มีชื่อว่า "Windows 365" หรือที่เรียกกันว่า Cloud PC ครับ และช่วงที่ผ่านตัวผมเองก็ได้มีโอกาสทำการศึกษาหาข้อมูลและทำการทดสอบ Windows 365 ดังนั้นผมจึงคิดว่าจะนำเอาเรื่องราวของ Windows 365 มานำเสนอและเล่าสู่กันฟังเหมือนเช่นเคยครับ

Windows 365 คืออะไร?

Windows 365 คือ Service ที่ทาง Microsoft ให้บริการ PC (ซึ่งติดตั้ง OS เป็น Windows 10  หรือ Windows 11 ในอนาคต)  ให้กับผู้ใช้งาน โดยทำการสตรีม PC (Windows 365) หรือที่เรียกกันว่า Cloud PC มายังเครื่องหรือ Device ของผู้ใช้งาน ไม่ว่าผู้ใช้งานจะอยู่ที่ใด หรือจะใช้ Device ใดครับ ซึ่งคล้ายคลึงกับการที่องค์กรนำเอา SaaS หรือ Cloud Applications เช่น Micrsoft 365 และอื่นๆ มาใช้งานในองค์กร โดยที่ไม่ต้องเตรียมเครื่องเพื่อทำการติดตั้ง SaaS หรือ Cloud Applications ดังกล่าวครับ โดยคอนเซปของ Windows 365 ที่ผมได้อธิบายเมื่อซักครู่นั้น สามารถเรียกได้ว่า Windows 365 (Cloud PC) ให้บริการในรูปแบบที่เรียกว่า Desktop-as-a-Service หรือ DaaS ครับ 

ผมขออนุญาตอธิบายเพิ่มเติมทางด้านเทคนิคอีกซักนิดสำหรับ Windows 365 ครับ  นั่นก็คือตัวของ Windows 365 นั้นทาง Microsoft ได้ทำการพัฒนาและต่อยอดมาจาก Service หนึ่งใน Microosft Azure ที่ชื่อว่า "Azure Virtual Desktop" หรือ AVD ซึ่งเป็น Service ที่ให้บริการ VDI Solution บน Microsoft Azure ซึ่งทำให้องค์กรที่สนใจ VDI Solution มีทางเลือกเพิ่มเติมจากเดิมที่จะต้องเตรียมเครื่องหรือ Servers และ Components ต่างๆ เพื่อทำการติดตั้ง VDI Solution ดังกล่าวที่ On-Premise Data Center ขององค์กร ซึ่งต้องใช้เวลาในการติดตั้งรวมถึงค่าใช้จ่ายค่อนข้างสูงครับ  แต่ ณ วันนี้องค์กรใดที่สนใจ VDI Solution สามารถใช้ติดตั้งและใช้งาน Solution ดังกล่าวบน Microsoft Azure โดยใช้ Azure Virtual Desktop หรือ AVD ซึ่งติดตั้งง่ายและเร็วกว่าแบบเดิม อีกทั้งค่าใช้จ่ายโดยรวมก็ยังถูกกว่าเมื่อนำไปเปรียบเทียบกับการติดตั้งและใช้งาน VDI Solution ก่อนหน้านี้ครับ  

ในส่วนของ Windows 365 จะให้บริการในรูปแบบของ Single User หรือ Single Session (ซึ่งแตกต่างจาก Azure Virtual Desktop ที่ให้บริการแบบ Multi-Sessions) เพื่อให้ทำงานเหมือนกันเป็น PC ของผู้ใช้งานแต่ละคนครับ โดยทาง Microsoft ได้พัฒนา Windows 365 ให้ง่ายและสะดวกต่อการติดตั้งและใช้งานมากขึ้นครับ โดยที่ผู้ดูแลระบบไม่ต้องไปทำการเตรียมและสร้าง Virtual Machine ใดๆ เลยเพื่อให้ผู้ใช้งานเข้ามาใช้งาน Windows 365 รวมถึงตัวของผู้ดูแลระบบก็ไม่สามารถทำการ Remote ไปที่ Windows 365 ได้ครับ เนื่องจากทาง Microsoft เป็นคนจัดการให้ครับ แต่นั่นก็ไม่ได้หมายความว่าผู้ดูแลระบบไม่ต้องทำอะไรกับ Windows 365 นะครับ ในเรื่องของการบริหารและจัดการ เช่น เรื่องของ Security และอื่นๆ ก็ยังคงเป็นหน้าที่ที่ผู้ดูแลระบบจะต้องดำเนินการนะครับ 

ผมอยากให้ทุกท่านมอง Windows 365 คือ Windows 10 หรือต่อไปจะมี Windows 11 ที่ทาง Microsoft ได้จัดการเบื้องหลังสำหรับในส่วนของ System หรือ Infrastrusture เพื่อให้ Windows 365 ดังกล่าวนั้นสามารถให้บริการกับเราได้ครับ ในส่วนของผู้ใช้งานอย่างตัวผมหรือทุกท่าน เราก็จะได้เครื่องหรือ PC มาตัวหนึ่ง ซึ่งโดยปรกติเราจะได้มาในรูปแบบของ Physical เช่น PC หรือ Notebook จากนั้นเราก็จะทำการติดตั้ง Applications และกำหนดค่าต่างๆ ตามที่เรารวมถึงองค์กรต้องการครับ แต่ในมุมของ Windows 365 คือเราจะได้ PC มาเช่นกันครับแต่เป็นแบบ Virtual ครับ ผมหรือท่านผู้อ่านสามารถใช้งาน Windows 365 ผ่านทาง Device ของเรา เช่น Notebook, Tablet , และอื่นๆ ผ่านทาง Browser ครับ และอย่างที่ผมได้อธิบายไว้ข้างต้น คือ ท่านผู้อ่านสามารถใช้งาน Windows 365 จากที่ใดหรือ Device ใดก็ได้ครับ เพราะตัวของ Windows 365 อยู่บน Cloud (Microsoft Azure) ครับ เราจึงเรียกว่า Windows 365 คือ Cloud PC นั่นเองครับผม

และจากที่ผมได้อธิบายเกี่ยวกับคอนเซปของ Windows 365 ไว้ข้างต้น ทำให้องค์กรสามารถที่จะนำเอา Windows 365 มาให้ผู้ใช้งานในองค์กรใช้งานได้อย่างสะดวกและง่ายกว่าแต่ก่อน เพราะองค์กรไม่ต้องเตรียมหรือซื้อเครื่อง PC หรือ Notebook และทำการติดตั้ง OS และอื่นๆ มาให้ผู้ใช้งานเหมือนที่ผ่านมาครับ ดังนั้นทำให้องค์กรมีความยืดหยุ่นในการบริหารและจัดการรวมถึงประหยัดค่าใช้จ่ายด้วยครับ ในมุมของผู้ใช้งานนั้นแทบจะไม่ต้องปรับตัวหรือเรียนรู้มากซักเท่าไรกับ Windows 365 (OS เป็น Windows 10 หรือ Windows 11 ในอนาคต) เพราะผู้ใช้งานคุ้นเคยการใช้งาน Windows 10 (หรือ Windows 11) ที่ใช้งานกันอยู่แล้วครับ

Windows 365 Requirements & Options

ณ ขณะนี้ Windows 365 มีให้เลือกใช้งาน 2 แบบ หรือ 2 Options ครับ คือ แบบ Business กับ Enterprise ครับ โดยจะเลือกแบบใดนั้นขึ้นอยู่กับความต้องการครับ *สำหรับบทความนี้ผมจะนำเสนอ Windows 365 แบบ Business นะครับ 

Option 1: Windows 365 Business

สำหรับ Windows 365 แบบ Business นั้นถูกออกแบบมารองรับกับองค์กรขนาดเล็กหรือกลางที่มีผู้ใช้งาน 300 Users หรือน้อยกว่าครับ  องค์กรหรือท่านผู้อ่านสามารถดำเนินการซื้อ Windows 365 Business ได้เลยครับ โดยสั่งซื้อโดยตรงจาก Windows 365 Portal หรือจาก Microsoft 365 admin center ครับ ไม่ต้องซื้อ Azure Subscription นะครับ รองรับและสามารถนำไปใช้กับองค์กรที่มีหรือไม่มี Azure Active Directory (Azure AD) Tenant ก้อได้ครับ นั่นหมายความว่า Windows 365 Business อาศัยการทำงานร่วมกับ Azure AD เป็นหลักหรือจะเรียกว่า Windows 365 หรือ Cloud PC รองรับแบบ Native Azure AD Support ครับ 

Option 2: Windows 365 Enterprise

สำหรับ Windows 365 แบบ Enterprise นั้นถูกออกแบบมาสำหรับองค์กรขนาดใหญ่ ที่มีลักษณะเป็น Hybrid Cloud (Hybrid Identity) โดย Windows 365 Enterprise จะทำงานร่วมกับ Azure Active Directory (Azure AD) และ Active Directory Domain Service (AD DS) ไม่สามารถติดต่อหรือ Reomote ไปยัง Windows 365 เช่นกันครับ แต่สามารถกำหนดค่าให้ Windows 365 Enterprise ดังกล่าวสามารถเชื่อมต่อเข้ามายัง Azure Virtual Network (Azure VNet) ขององค์กรได้ เพราะฉะนั้นองค์กรที่สนใจ Windows 365 Enterprise จะต้องเตรียม Windows 365 Enterprise Licenses, Microsoft Azure Subscription, และอื่นๆ

รายละเอียดเพิ่มเติมสามารถดูได้จาก Link นี้ครับ, Windows 365 requirements | Microsoft Docs

รูปด้านล่างแสดงถึงความแตกต่างด้านเทคนิคระหว่าง Windows 365 Business กับ Enterprise ครับ

สำหรับ Applications ต่างๆ ที่สามารถใช้งานได้ใน Windows 365 ณ ขณะที่ผมเขียนบทความอยู่นี้ มีเยอะเลยครับ โดยส่วนใหญ่ท่านผู้อ่านจะคุ้นเคยกันดีอยู่แล้ว เช่น Microsoft 365, Microsoft Dynamics 365, Microsoft Power Platform, Line of Business (LOB), และอื่นๆ ครับ 

Windows 365 Pricing

สำหรับราคาหรือค่าใช้จ่ายของ Windows 365 นั้นคิดเป็นต่อ User ต่อเดือนครับ ไม่ได้มีการคิดค่าใช้จ่ายค่า Compute หรือ Azure Virtual Machine ของตัว Cloud PCs (Windows 365) ครับ เช่น ถ้าองค์กรหรือออฟฟิศของท่านผู้อ่านมีผู้ใช้งานที่วางแผนต้องการใช้งาน Windows 365 สมมติว่า 50 Users ก็ซื้อ Windows 365 จำนวน 50 Licenses ครับ  ค่าใช้จ่ายของ Windows 365 จะสูงหรือไม่ขึ้นอยู๋กับจำนวนผู้ใช้งานและสปเค (Specification) ของ Windows 365 ครับ ซึ่งมีให้เลือกหลายแบบครับ โดยจะคิดต่าใช้จ่ายข้างต้นเป็นรายเดือนตามที่แจ้งไว้ในตอนต้นครับ  รูปด้านล่างเป็นตัวอย่างของรายละเอียดและราคาของ Windows 365 ครับ

รายละเอียดเพิ่มเติมสามารถเข้าไปที่ Link นี้ได้ครับ Windows 365 Plans and Pricing | Microsoft

Windows 365 Security

ทาง Microsoft ได้ทำการออกแบบและพัฒนา Windows 365 โดยรองรับกับคอนเซปของ "Zero Trust"  ในส่วนของ User Experience นั้นก็ถูกออกแบบมาให้รองรับและคำนึงถึงเรื่องของความปลอดภัยเช่นกันครับ ข้อมูลทุกอย่างของ Windows 365 จะถูกเก็บไว้บน Cloud (Microsoft Azure) ไม่ได้มีการเก็บไว้ที่อุปกรณ์หรือ Device ของผู้ใช้งาน ตลอดจนได้มีการเข้ารหัส (Encryption) ตลอดการใช้งานไม่ว่าจะเป็น Network Traffics จนถึงข้อมูล (Disk ของ Windows 365) ครับ  Windows 365 รองรับกับเทคโนโลยีที่ทาง Microsoft ได้มีการคิดค้นและพัฒนาอย่างต่อเนื่องที่เรียกว่า "Passwordless Technology" ครับ นอกเหนือจาก MFA ครับ ตัวของ Windows 365 ยังสามารถทำงานร่วมกับ Microsoft Security Services อื่นๆ เช่น Microsoft Endpoint Manager (MEM), Microsoft Defender, เป็นต้นครับ

และนี่คือเรื่องราวและคอนเซปของ Windows 365 ในเบื้องต้นครับ สิ่งที่สำคัญที่ผมอยากจะแนะนำเพิ่มเติมก่อนที่ท่านผู้อ่านทุกท่านหรือองค์กรใดที่สนใจจะเริ่มนำเอา Windows 365 ไปใช้งาน ก็คือ การวางแผนและเตรียมความพร้อมอย่างรอบคอบครบถ้วนครับ โดยเริ่มเก็บข้อมูลต่างๆ เช่น ระบบหรือ Environment ณ ปัจจุบันขององค์กรเป็นอย่างไร, มีการใช้งาน Cloud Services ใดของ Microsoft เช่น Microsoft Azure, Microsoft 365, เป็นต้น, รวมถึงความต้องการครับ จากนั้นนำเอาสิ่งเหล่านี้มาพิจารณาควบคู่ไปกับความรู้และความเข้าใจเกี่ยวกับ Windows 365 ไม่ว่าจะเป็น คอนเซปการทำงานของ Windows 365, Windows 365 Options (Business และ Enterprise), ค่าใช้จ่าย, และอื่นๆ ครับ เมื่อพิจารณทุกอย่างครบถ้วนแล้ว ก็จะเข้าสู่ขั้นตอนการดำเนินการจัดซื้อและตามด้วยขั้นตอนการ Deploy Windows 365 ครับผม.....

รู้จักกับ Zero Trust Model

     สวัสดีครับทุกท่าน เรื่องของปลอดภัย (Security) เป็นเรื่องสำคัญเรื่องหนึ่งที่ทุกๆ องค์กรให้ความสนใจ และวางแผนเพื่อเตรียมความพร้อมสำหรับการดำเนินการในเรื่องดังกล่าวครับ แต่หลายๆ องค์กรรวมถึงท่านผู้อ่านด้วย อาจจะมีคำถามครับว่าจะเริ่มต้นเรียนรู้และเตรียมความพร้อมอย่างไร, ทาง Microsoft มี Best Practices, เครื่องมือ, Models และอื่นๆ ที่จะช่วยองค์กรกับเรื่องดังกล่าวนี้หรือไม่ คำตอบ คือ มีครับ โดยทาง Microsoft ได้เตรียมสิ่งต่างๆ ที่ผมเกริ่นไว้เมื่อซักครู่ให้แล้วครับ และจึงเป็นที่มาของบทความนี้ ซึ่งผมจะพาทุกท่านไปทำความรู้จักและทำความเข้าใจเกี่ยวกับคอนเซปของ Security, Compliance, และ Identity กันครับ โดยบทความนี้ผมขอเริ่มจาก Model ที่ชื่อว่า "Zero Trust Model" ครับ

Zero Trust Model คืออะไร?

โดยคอนเซปของ Zero Trust Model มองว่า Data หรือ Resources ทุกอย่างที่องค์กรมีและเปิดให้ผู้ใช้งานเข้าถึงนั้น ไม่ว่า Data หรือ Resources ดังกล่าวนั้นจะอยู่ที่ใดก็ตาม เช่น ใน Cloud (Microsoft Azure, SaaS Apps, เป็นต้น) ตลอดจน Resources ใน On-Premise Data Center และอยู่หลัง Firewall ขององค์กร ในมุมของ Zero Trust ถือว่า ไม่มีที่ใดที่เชื่อถือหรือไว้ใจได้ เพราะฉะนั้นจะต้องมีการตรวจสอบทุกสิ่งทุกอย่างครับ เป็นไปตามกฏของ Zero Trust ที่ใช้ในการปฏิบัติการที่เรียกว่า "Trust no one, Verify everything" ครับ

มาดูกันในฝั่งของ Attackers กันบ้างครับ ในช่วงที่ผ่านมาจนถึง ณ ปัจจุบันได้ Attackers ได้มีการพัฒนาเทคนิคและวิธีการต่างๆ อย่างต่อเนื่อง เพื่อที่จะใช้ในการโจมตีเป้าหมาย เช่น Resources หรือข้อมูลต่างๆ ขององค์กร โดยพยายามหาวิธีการเข้าถึงและ Bypass การควบคุมในการเข้าถึงข้อมูลหรือ Resources ต่างๆ ใน On-Premise Data Center รวมถึง Cloud (เช่น Microsoft Azure เป็นต้น) ซึ่งที่ผ่านมาทุกท่านที่ติดตามข่าวสารก็จะเห็นว่า มีการโจมตีและเข้าถึงข้อมูลต่างๆ ในองค์กร แม้ว่าองค์กรนั้นๆ จะมีการควบคุมและจัดการในเรื่องของความปลอดภัย เช่น มีการแบ่ง Networks ออกเป็นวงย่อยๆ (Segmented Networks), มีการควบคุมการเข้าถึง (Access Control), มีการใช้ Firewall ในการควบคุม Traffics ที่เข้า-ออกทั้งภายในและภายนอก แต่องค์กรดังกล่าวก็ยังถูกโจมตีหรือ Attack ครับ นั่นหมายความว่าแนวทางและวิธีการจัดการในเรื่องของความปลอดภัยที่ใช้กันก่อนหน้านี้ ไม่เพียงพอหรือไม่สามารถป้องกันหรือลดความเสี่ยงที่จะถูกโจมตีจากภัยคุกคามต่างๆ ได้ครับ เพราะฉะนั้นจะทำอย่างไรเพื่อที่จะเตรียมความพร้อมและจัดการในเรื่องของความปลอดภัย จากประเด็นดังกล่าวนี้ จึงเป็นที่มาของการนำเอา Zero Trust Model เข้ามาประยุกต์ใช้งานในองค์กรครับ 

โดยคอนเซปของ Zero Trust Model นั้น จะต้องทำการตรวจสอบทุกอย่างที่จะเข้าถึงข้อมูลหรือ Resources ต่างๆ ไม่ว่าจะอยู่ที่ใดก็ตามครับ และที่ผ่านมาหลายๆ องค์กรได้ดำเนินการตาม Best Practices ไปบ้าง เช่น มีการนำเอาคอนเซปและเทคโนโลยีที่เรียกว่า Multi-Factor Authentication เข้ามาเพื่อช่วยทำให้กระบวนการในการตรวจสอบ Identity (Authentication) นั้นมีความแข็งแรงหรือปลอดภัยมากขึ้น เสริมการ Authentication ในรูปแบบปรกติ นั่นก็คือ การ Sign-In โดยใช้ Username และ Password ครับ แต่ยังไม่ครบถ้วนทั้งหมดครับ ดังนั้นผมจะพาทุกท่านเข้าสู่รายละเอียดของ Zero Trust Model กันมากขึ้นครับ

Zero Trust Model (Principles)

มีหลักปฏิบัติด้วยกัน 3 ข้อ ดังนี้:

1. Verify Explicitly ทำการ Authenticate และ Authorize Data Points และ Endpoints เช่น  User, Location, Device, Service หรือ Workload, Data Classification, และอื่นๆ ตลอดเวลา

2. Least Privileged Access จำกัดการเข้าถึงข้อมูล Resources ต่างๆ ด้วย Just-in-time และ Just-enough access (JIT/JEA), Policies, Data Protection เป็นต้น

3. Assume Breach ทำการแยกหรือแบ่งการเข้าถึงโดยกำหนดตาม Network, User Devices,  Application,

เป็นต้น ใช้การการเข้ารหัส (Encryption) เพื่อป้องกันข้อมูล, ทำการค้นหาตรวจสอบและวิเคราะห์ภัยคุกคาม (Threats) เพื่อปรับปรุงความปลอดภัยให้ดีขึ้น

Zero Trust Model (6 Foundation Components)

ใน Zero Trust Model นั้นประกอบไปด้วย ส่วนประกอบหรือ Components ต่างๆ ที่จะต้องทำงานร่วมกันเพื่อทำ End-to-End Security โดยส่วนประกอบที่ทำงานร่วมกันนี้ถือเป็นพื้นฐานสำคัญของ Zero Trust Model ซึ่งประกอบไปด้วย 6 ส่วนประกอบโดยมีรายละเอียดดังนี้:

Identities เป็นสิ่งที่ Attackers ต้องการเพื่อใช้ในการเข้าถึง โดยส่วนประกอบนี้ (Identities)  คือ Users, Services และ Devices เมื่อ Identity เหล่านี้พยายามที่จะเข้าถึงข้อมูลหรือ Resources ต่างๆ ก็จะต้องมีการตรวจสอบโดยใช้ Authentication ที่มีความแข็งแรงและปลอดภัย เช่น MFA (Multi-Factor Authentication) และต้องดำเนินการตามหลักปฏิบัติที่อยู่ในหัวขัอก่อนหน้านี้ นั่นก็คือ Least Privileged Access ครับ

Devices เป็นสิ่งที่ Attackers ต้องการเช่นเดียวกันกับ Identities โดย Attackers พยายามค้นหาช่องโหว่ของเครื่องของผู้ใช้งาน (Devices) เพื่อใช้ Devices ดังกล่าวในการเข้าถึงข้อมูลหรือ Resources ใน On-Premise หรือ Cloud  ดังนั้นจะต้องมีการวางแผนและจัดการโดยการ Monitoring Health และ Compliance ของ Devices เหล่าน้้นว่าเป็นไปตามที่กำหนดไว้หรือไม่

Applications ถือว่าเป็นช่องทางหนึ่งที่สามารถเข้าถึงข้อมูลได้ เพราะฉะนั้นจะต้องทำการตรวจสอบสิทธิ์ในการเข้าถึงของ Applications กับข้อมูลที่เกี่ยวข้องกับ Applications นั้นๆ ด้วย

Data ควรมีการวางแผนดำเนินสร้างความปลอดภัยให้กับข้อมูล เช่น การแบ่งแยกประเภทข้อมูล (Classification), การกำหนดคำอธิบายข้อมูล (Labeling), และการเข้ารหัสข้อมูล (Encryption) เพื่อทำการปกป้องข้อมูล (Data Protection) ให้มีความปลอดภัย ไม่ว่าจะมีการเข้าถึงจากทีใด, อุปกรณ์ใด, และจากใคร

Infrastructure จะต้องมีการปรับปรุงในเรื่องของความปลอดภัยให้กับ Infrastructure ท้้งที่อยูใน On-Premise และ Cloud โดยจะต้องมีการตรวจสอบและทำการประเมิน, การค้นหา (Detection), และป้องกัน (Protection), และอื่นๆ เพื่อป้องกันและลดความเสี่ยงที่ภัยคุกคามที่จะเข้ามาโจมตี

Network ควรจะต้องมีการแบ่งแยก Networks เป็น Network ย่อยๆ และควรจะมีการนำเอา Real-Time Threat Protection, End-to-End Encryption, Monitoring และอื่นๆ เข้ามาใช้งานเพื่อสร้างความปลอดภัย

รายละเอียดเพิ่มเติมสำหรับเรื่องราวของ Microsoft Zero Trust Model สามารถไปที่ Link นี้ได้เลยครับ

Zero Trust Security Model and Framework | Microsoft Security

และทั้งหมดนี้คือคอนเซปของ Zero Trust Model ครับผม.....

Azure Active Directory (Azure AD)

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะพาทุกท่านไปทำความรู้จักกับ Concept และ Service ที่ทำหน้าที่ในการบริหารและจัดการ Identity ครับ โดย Service ดังกล่าวนี้มีชื่อว่า   “ Azure Active Directory” หรือเรียกกันสั้นๆ ว่า "Azure AD"  ครับ  สำหรับ Azure Active Directory นั้นถือว่าเป็น Service ตัวหนึ่งที่มีความสำคัญมากตัวหนึ่งสำหรับการนำเอา Cloud เข้ามาประยุกต์ใช้งานในองค์กร ในรูปแบบต่างๆ เช่น Public, Hybrid Cloud เป็นต้น 

สิ่งหนึ่งที่องค์กรจะต้องทำการวางแผนเตรียมความพร้อมนั่นก็คือ เรื่องของการบริหารจัดการและควบคุม Identity ซึ่ง ณ วันนี้ การบริหารจัดการและควบคุม Identity เพื่อเข้าถึงและใช้งานทรัพยากรต่างๆ ไม่ได้จำกัดอยู่เพียงแค่ใน On-Premise เพียงที่เดียวอีกต่อไปครับ  โดยเฉพาะหลังจากองค์กรได้มีการนำเอา Cloud  เข้ามาประยุกต์ใช้งาน จึงทำให้ทรัพยากรต่างๆ ที่เคยอยู่ใน On-Premise  ก็จะถูกย้าย (Migrate) หรือจะเป็นสร้าง Workloads ใหม่บน Cloud รวมถึงความต้องการที่นำเอา Cloud หรือ SaaS Applications เข้ามาใช้งาน เป็นต้น 

ขอยกตัวอย่างเพิ่มเติม เพื่อให้ทุกท่านได้เห็นภาพและมีความเข้าใจมากขึ้นจากที่ผมได้เกริ่นไว้ในตอนต้น เช่น ถ้าองค์กรหนึ่งมีความต้องการใช้งาน Cloud หรือ SaaS Applications โดยองค์กรดังกล่าวมีผู้ใช้งาน 1,000 คน และมี Active Directory Domain Services (AD DS) ใช้งานอยู่  สิ่งที่องค์กรจะต้องพิจารณาจากความต้องการข้างต้น คือ

- ผู้ใช้งานในองค์กรดังกล่าว จะต้องมีและจดจำ Username และ Password มากขึ้นตามจำนวนของ Cloud หรือ SaaS Applications  ที่องค์กรดังกล่าวนำเข้ามาใช้งาน ซึ่งมีความเป็นไปได้ที่ผู้ใช้งานจะกำหนด Username และ Password เหมือนกันทั้งหมดเพื่อให้ง่ายและสะดวกใน การเข้าถึงและใช้งาน แต่จะทำให้เกิดความยุ่งยากในการบริหารจัดการ และเกิดความไม่ปลอดภัย

- เกิดความยุ่งยากในการบริหารและจัดการ Username และ Password 

- IT ทำการตรวจสอบ Activities ได้ยาก เนื่องจากผู้ใช้งานมีหลาย Identities

- อื่นๆ 

จากประเด็นต่างๆ ข้างต้น ทำให้ ณ ปัจจุบัน องค์กรต่างๆ จะต้องเตรียมความพร้อมและวางแผนการบริหารและจัดการ Identity  ของผู้ใช้งานในองค์กร ที่ต้องการเข้าถึงทรัพยากรต่างๆ ไม่ว่าจะอยู่ใน On-Premise และบน Cloud  อย่างไร เพื่อให้เกิดความยืดหยุ่นและปลอดภัยได้อย่างไร และนี่จึงเป็นที่มาของ Azure Active Directory (Azure AD) ครับ  และก่อนที่จะไปถึงเรื่องราวของ Azure  Active Directory หรือ Azure AD นั้น ผมขออนุญาตอธิบายคร่าวๆ เกี่ยวกับ Service ตัวหนึ่ง ซึ่งผมเชื่อว่าหลายๆ องค์กรใช้งานกันอยู่ครับ และท่านผู้อ่านทุกท่านน่าจะคุ้นเคยกันอยู่แล้วครับ  Service ที่ว่านี้ก็คือ “Active Directory Domain Services (AD DS) ” ครับ ซึ่งเป็น Role ที่อยู่ใน Windows Server ครับ และในช่วงที่ผ่านมา ยังมีหลายท่านๆ ยังสับสนและเข้าใจว่า Active Directory Domain Services หรือ  AD DS คือ Service ตัวเดียวกันกับ Azure Active Directory หรือ Azure AD ครับ ดังนั้นผมขออธิบายเรื่องราวของ Active Directory Domain Services (AD DS) กันซักนิดก่อนครับ

ทำความรู้จักกับ Active Directory Domain Services (AD DS)

Active Directory Domain Services (AD DS) เป็น Role หนึ่งใน Windows Server มาตั้งนานแล้วครับ โดยทาง Microsoft ได้นำเอา Active Directory มาเริ่มให้บริการและใช้งานตั้งแต่ใน Windows Server 2000 ครับ โดยในส่วนของ Active Directory ใน Windows Server นั้นมีหลาย Roles ให้พิจารณาเลือกไปใช้งานครับ เช่น

- Active Directory Domain Services (AD DS)

- Active Directory Certificate Services (AD CS)

- Active Directory Federation Services (AD FS)

- Active Directory Right Management Services (AD RMS)

- Active Directory Lightweight Directory Services (AD LDS)

ปัจจุบันทุกองค์กรมีการใช้งาน  Active Directory  Roles ต่างๆ กันอยู่อย่างแพร่หลายครับ โดยเฉพาะ Active Directory Domain Services (AD DS)  เพราะองค์กรต้องการ Solution ที่มาช่วยในการบริหารและจัดการการเช้าถึงและใช้งานทรัพยากรต่างๆ ในองค์กร เช่น File Server, Print Server, Application Server และอื่นๆ และรองรับกับการทำ Single Sign-On (SSO) ครับ 

สำหรับ Active Directory Domain Service (AD DS) นั้นเป็น Service ที่ทำหน้าที่เรียกว่า “Directory Service” หรือจะเรียกอีกชื่อว่า “LDAP Service” ก็ได้ครับ โดยจะมีโครงสร้างแบบ Hierarchical Structure คือ จะมี Forest, Tree, Domain, และ Organizational Unit (OU) ครับ ดังนั้นจะเห็นว่าเวลาที่ทำสร้าง Active Directory Domain Service (AD DS) จะต้องมีการออกแบบว่าจะมีกี่ Forest, Tree, Domain และอื่นๆ ครับ และจะมี Features ต่างๆ ที่มาพร้อมกับ Active Directory Domain Service (AD DS)  เช่น การสร้าง User, Group, และ Computer Accounts ต่างๆ ไว้ใน Domain, Group Policy ซึ่งเป็น Feature ที่ให้องค์กรสามารถสร้างและกำหนด Policy ในการควบคุมและจัดการ Resources ต่างๆ และอื่นๆ 

 

ดังนั้นผู้ใช้งานที่จะเข้ามาใช้งานทรัพยากรต่างๆ ก็จะต้องมี User Account ใน Active Directory Domain Service (AD DS) ก่อนครับ นอกจากนี้แล้วเครื่องของผู้งานก็จะต้องทำกระบวนที่เรียกว่าการ “Join Domain” เพื่อจะเข้าถึงทรัพยากรต่างๆ เช่นกันครับ สำหรับในส่วนของ Authentication Protocols ที่ Active Directory Domain Service (AD DS) ที่รองรับคือ NTLM และ Kerberos ครับ ในส่วนของการทำ Query ข้อมูลใน Active Directory Domain Service (AD DS) ใช้ LDAP Protocol ครับ

จากสิ่งที่ผมได้อธิบายเกี่ยวกับ Active Directory Domain Services (AD DS) ไว้ในข้างต้น เพื่อให้ทุกท่านเห็นภาพและเข้าใจเกี่ยวกับ Service นี้กันก่อนครับ จากนั้นในหัวข้อถัดไปท่านผู้อ่านก็จะได้รู้จักกับ Azure Active Directory (Azure AD)) ว่ามี Concept และรายละเอียดเป็นอย่างไร และมีความแตกต่างกับ Active Directory Domain Services (AD DS) อย่างไร แต่สิ่งสำคัญไปกว่านั้นคือ เราสามารถใช้ทั้ง Active Directory Domain Services(AD DS) และ Azure Active Directory (Azure AD)  ทำงานร่วมกันได้เพื่อทำ Hybrid Cloud ครับ

ทำความรู้จักกับ Azure Active Directory (Azure AD)

Azure Active Directory (Azure AD) เป็น Service หนึ่งใน Microsoft Azure ครับ  โดยทำหน้าที่เป็น Identity and Access Management (IAM) Solution ทำหน้าที่ในการบริหาจัดการและควบคุมในส่วนของ Identity สำหรับการเข้าถึงและใช้งานทรัพยากรต่างๆ (Azure Storages, Azure App Services, Devices และอื่นๆ )  ใน Microsoft Azure รวมถึงใน On-Premise Data Center ครับ

นอกจากนี้แล้วยังมีความสับสนและข้อสงสัยเกี่ยวกับ Azure Active Directory  เช่น  Azure Active Directory เหมือกับ Active Directory Domain Services (AD DS) ใน Windows Server หรือไม่?   Azure Active Directory จะมาแทน Active Directory Domain Services (AD DS) ใน Windows Server หรือไม่ ?

สำหรับ Azure Active Directory  (Azure AD) มีความแตกต่างกับ Active Directory Domain Services (AD DS) ที่อยู่ใน Windows Server ครับ โดย Azure Active Directory  (Azure AD) นั้นไม่ใช่ Directory Service (LDAP Service) เหมือนกับ Active Directory Domain Services (AD DS) ใน Windows Server ครับ เพราะใน Azure Active Directory (Azure AD) มี Concept, Structure, และรายละเอียดต่างๆ ที่แตกต่างจาก Active Directory Domain Services (AD DS) ครับ สำหรับใน Azure Active Directory (Azure AD) นั้นไม่มี Forest, Tree และ Domain ซึงเป็น Hierarchical Structure เหมือนกันใน Active Directory Domain Services (AD DS) ครับ สำหรับโครงสร้างและ Structure ของ Azure Active Directory (Azure AD) นั้นมีโครงสร้างเป็น Flat Structure ครับ, รวมถึงไม่มี Group Policy สำหรับจัดการ Policy, ไม่มี Kerberos และ NTLM Protocols สำหรับการทำ Authentication ครับ

ดังนั้น Azure Active Directory (Azure AD) จะไม่ใข่ Service ที่จะมาทดแทน Active Directory Domain Services (AD DS) ที่อยู่ใน Windows Server ที่องค์การต่างๆ ใช้งานอยู่ครับ  แต่ในทางกลับกันเราสามารุถนำเอา Azure Active Directory (Azure AD) มาทำการ Integrate กับ Active Directory Domain Services (AD DS) เพื่อทำงานร่วมกันได้ใน Concept และการทำงานที่เรียกว่า Hybrid Cloud ดังรูปด้านล่างครับ

จากรูปด้านบนเป็นรูปแสดงถึงภาพรวมของ Hybrid Cloud โดยการนำเอา Azure Active Directory (Azure AD) และ Active Directory Domain Services (AD DS) มาทำงานร่วมกัน เพื่อบริหารจัดการ Identity และรองรับ Single Sign-On (SSO) ให้กับองค์กร ดังนั้นสิ่งที่องค์กรจะต้องเตรียมพิจารณาวางแผนและเตรียมความพร้อมตามที่ผมได้เกริ่นไว้ในตอนต้นนั่น คือ องค์กรจะต้องเตรียมดำเนินการ ซิงค์โครไนท์ (Synchronize) Users และ Groups  ที่อยู่ใน Active Directory Domain Services (AD DS) ใน Windows Server ซึ่งอยู่ใน On-Premise Data Center ขององค์กร กับ Azure Active Directory (Azure AD) ใน Microsoft Azure โดยผ่านเครื่องมือที่มีชื่อว่า “Azure AD Connect” (สามารถดาวน์โหลดมาใช้งานได้ฟรี จากที่นี่ครับ, https://www.microsoft.com/en-us/download/details.aspx?id=47594 ) เพื่อทำการกระบวน Synchronization ที่เรียกว่า “Directory Synchronization”  ดังรูปด้านล่าง

หลังจากระบวนการดังกล่าวเสร็จเรียบร้อย ก็จะทำให้ผู้ใช้งาน (Users) ในองค์กรดังกล่าวสามารถเข้าถึงและใช้งานทรัพยากรต่างๆ  (เช่น File & Print Sharing, Applications, และอื่นๆ) ใน Active Directory Domain Services (AD DS) ของ Windows Server (On-Premise) ได้ตามปรกติ แต่สิ่งที่ผู้ใช้งานทำได้มากกว่านั้น คือ ผู้ใช้งานดังกล่าวยังสามารถเข้าถึงและใช้งาน, Resources ต่างๆ ใน Microsoft Azure, Cloud Applications หรือ SaaS Applications (Microsoft 365 และ 3^rd Party Cloud Applications) ได้อีกด้วย โดยใช้ Identity เดียวกัน ด้วยรูปแบบดังกล่าวนี้ทำให้องค์กรนั้นๆได้รับประโยขน์ในเรื่องของทำ Single Sign-On (SSO) ตลอดจนการบริหารจัดการและควบคุมในเรื่องของ Identity อีกด้วยครับ

ในความเป็นจริงแล้ว Azure Active Directory (Azure AD) ไม่ได้มีอยู่ใน Microsoft Azure เพียงที่เดียวนะครับ ทาง Microsoft ได้เตรียมและให้ Azure Active Directory ( Azure AD)  มาใน Cloud Services อื่นๆ ของ Microsoft  ด้วยเช่นกันครับ เช่น Microsoft 365, Microsoft Endpoint Manager, และอื่นๆ  โดยมีวัตถุประสงค์ คือ เตรียมเอาไว้ให้กับลูกค้าหรืององค์กรต่างๆ ใช้สำหรับการบริหารและจัดการ Identity (IAM) เพื่อเข้าถึงและใช้งานทรัพยากรต่างๆ ไม่ว่าจะอยู่ที่ใด (On-Premise และ Cloud) โดยที่ทางลูกค้าหรืององค์กรสามารถนำ Azure Active Directory (Azure AD) ไปใช้งานได้เลยโดยไม่มีค่าใช้จ่าย !!!!! นั้นหมายถึง Azure AD เป็น Service ที่ทาง Microsoft ให้ลูกค้าและองค์กรต่างๆ สามารถนำไปใช้งานได้ฟรีครับ

รายละเอียดเพิ่มเติมเกี่ยวกับ Azure Active Directory (Azure AD) สามารถดูได้จาก Link ดังต่อไปนี้ครับ:

https://azure.microsoft.com/en-us/services/active-directory/

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis

และทั้งหมดนี้คือเรื่องราวของ Azure Active Directory (Azure AD) ครับผม.....

-

Azure Security ตอนที่ 1 (Azure Security Center)

     สวัสดีครับทุกท่าน สำหรับบทความนี้จะเป็นบทความเริ่มต้นเกี่ยวกับเรื่องราวของ Security ใน Microsoft Azure ครับ สืบเนื่องจากช่วงระยะหลายปีที่ผ่านมา หลายๆ องค์กรได้มีการย้ายหรือสร้าง ระบบหรือ Workloads ต่างๆ ขึ้นไปทำงานใน Microsoft Azure โดยใช้งานผ่าน Azure Services ต่างๆ เช่น Azure Virtual Machine, Azure Virtual Network,  Azure App Service, Azure Storage, Azure SQL และอื่นๆ  ประเด็นหนึ่งทีสำคัญที่หลายๆองค์กรให้ความสนใจมากเรื่องหนึ่ง นั่นก็คือเรื่องของความปลอดภัยหรือ Security ครับ หลายๆ องค์กรจะต้องมีวางแผนและเตรียมความพร้อมว่าจะทำอย่างไรให้ระบบหรือ Workloads ต่างๆ ที่ติดตั้งและใช้งานอยู่ใน Microsoft Azure นั้นมีความปลอดภัยรวมถึงรองรับกับ Compliances ต่างๆ ที่องค์กรนั้นๆ จะต้องดำเนินการและปฏิบัติตาม จากประเด็นที่ว่านี้ที่ถ้าหากเรามองหรือโฟกัสลงไปภาพใหญ่ก็จเป็นเรื่องของ Cloud Security ครับ ซึ่งจะประกอบไปด้วยส่วนประกอบ 2 ส่วนที่เข้ามาทำหน้าที่และเกี่ยวข้องครับ นั่นก็คือ

Cloud Security Posture Management (CSPM) จะเป็นส่วนที่เกี่ยวข้องกับเครื่องมือ (Tools) ซึ่งจะทำหน้าที่ในการประเมินเรื่องของความปลอดภัย (Security Assessment) รวมถึงการตรวจสอบเรื่องของ Compliance (Compliance Monitoring) ระบบหรือ Workloads ต่างๆ ที่องค์กรได้มีการติดตั้งและใช้งานบน Cloud (Microsoft Azure เป็นต้น) เช่น Azure Virtual Machine, Azure Virtual Network,  Azure App Service, Azure Storage, Azure SQL และอื่นๆ

Cloud Workload Platform Protection (CWPP) จะเป็นส่วนที่เกี่ยวข้องกับเครื่องมือ (Tools) ซึ่งทำหน้าที่ตรวจสอบ (Monitoring) และป้องกัน (Protecting) ภัยคุกคาม (Threats) ที่จะเข้ามาจู่โจมหรือสร้างปัญหากับระบบหรือ Workloads ต่างๆ ที่องค์กรได้มีการติดตั้งและใช้งานบน Cloud (Microsoft Azure เป็นต้น) เช่น Azure Virtual Machine, Azure Virtual Network,  Azure App Service, Azure Storage, Azure SQL และอื่นๆ

Azure Security Center คืออะไร?

เป็น Service หนึ่งใน Microsoft Azure ที่จะเข้ามาช่วยองค์กรต่างๆ ในการจัดการและควบคุมระบบหรือ Workloads ต่างๆ ที่องค์กรได้มีการติดตั้งและใช้งานไม่ว่าจะอยู่ใน Microsoft Azure, On-Premise, หรือ Cloud Providers อื่นๆ เช่น AWS, Google GCP, เป็นต้น ให้มีความปลอดภัย โดย Azure Security Center หรือเรียกสั้นๆ ว่า ASC จะเข้าช่วยและดำเนินการส่วนประกอบทั้ง 2 ส่วน (CSPM และ CWPP) ตามที่ผมได้อธิบายไว้ในตอนต้นครับ

สำหรับ Cloud Security Posture Management (CSPM) นัั้น Azure Security Center หรือ ASC จะทำหน้าที่ในการประเมินและตรวจสอบในเรื่องของ Configuration ของ Azure Resources ต่างๆ ที่องค์กรได้มีการติดตั้งและใช้งานอยู่นั้น มีค่า Configuration ของ Azure Services (ครอบคลุมท้้ง IaaS, PaaS, และ SaaS) ใดที่สุ่มเสี่ยงต่อความไม่ปลอดภัยหรือไม่ ถ้า ASC ตรวจพบเจอก็จะมีคำแนะนำเกี่ยวกับความปลอดภัย (Security Recommendations) ให้เราไปทำการปรับปรุงแก้ไขครับ สำหรับ Security Recommendations หรือเรียกสั้นๆ ว่า Recommendations นั้น ถือว่าเป็นฟีเจอร์หนึ่งที่มีความสำคัญมากของ ASC ครับ หน้าตาของ ASC ในส่วนของ Recommendations สามารถดูได้จากรูปด้านล่างครับ

จากรูปของ Recommendations เราสามารถคลิ๊กเข้าไปดูรายละเอียดเพิ่มเติมได้นะครับ ซึ่ง ASC มีข้อมูลและรายละเอียดให้ครับ เพื่อให้ท่านผู้อ่านสามารถนำไปปรับปรุงแก้ไขได้ครับ 

มาที่ฟีเจอร์ต่อมาของ ASC ที่น่าสนใจอีกฟีเจอร์หนึ่งครับ นั่นก็คือ Secure Score ซึ่งเป็นอีกฟีเจอร์หนึ่งของ ASC  ที่จะช่วยทำให้เราเข้าใจถึงสถานการณ์ปัจจุบันสำหรับเรื่องของความปลอดภัยของ Workloads หรือ Azure Resources ต่างๆ นั้นว่าเป็นอย่างไร และจะทำการปรับปรุงอย่างไร ในเรื่องของการปรับปรุงนัน ASC ก็จะมี Recommendations ที่ผมได้อธิบายไว้ก่อนหน้านี้ครับ

อีกฟีเจอร์หนึ่งที่น่าสนใจของ ASC นั่นก็คือ Security Alerts ซึ่งจะเป็นฟีเจอร์ที่ทำหน้าที่ในการแจ้งเตือน (Notification) เมื่อ ASC ตรวจพบภัยคุกคาม (Threats) เกิดขึ้นกับ Workloads ต่างๆ ไม่ว่าจะอยู่ใน On-Premise หรือ Microsoft Azure รวมถึงรายละเอียดและแนวทางในการแก้ไขครับ ดังรูป

สำหรับในส่วนของ Cloud Workload Platform Protection (CWPP) นั้น ASC จะมี Azure Defender ซึ่งเป็นส่วนที่จะเข้ามาทำการตรวจสอบและป้องกัน Azure Resources ต่างๆ (ครอบคลุมทั้ง IaaS และ PaaS) เช่น  Azure Virtual Machine, Azure App Service, Azure Storage, Azure SQL, Azure Key Vault, และอื่นๆ ที่องค์กรได้มีการติดตั้งและใช้งานอยู่นั้นจากภัยคุกคาม (Threats) ครับ ดังรูปด้านล่างครับ

มาถึงตรงนี้ท่านผู้อ่านทุกท่านจะเห็นว่า Azure Security Center หรือ  ASC เป็น Service ที่มีความสำคัญมากส่วนหนึงของ Cloud Security ครับ เพราะ ASC จะเป็นทำหน้าที่เป็นศุนย์กลางในการจัดการและควบคุมเรื่องของความปลอดภัยหรือเรียกว่าเป็น Unified Infrastructure Security Management ให้กับระบบหรือ Workloads ต่างๆ ขององค์กรโดยครอบคลุมทั้ง On-Premise และ Cloud หรือที่เรียกว่า Hybrid Cloud รวมถึง Multi-Cloud ตามที่ผมได้อธิบายไว้ในข้างต้นครับ

สำหรับเบื้องหลังการทำงานของ Azure Security Center นั้น ตัวของ ASC ยังทำงานร่วมกับ Azure Services อื่นๆ เช่น Azure Log Analytics (Log Analytics Workspace) สำหรับเก็บข้อมูล (Logs และ Metrics Data) ที่รวบรวมมาจาก Sources ซึ่งก็คือระบบหรือ Workloads หรือ Azure Resources ต่างๆ เช่น Azure Virtual Machine เป็นต้น, อีก Service หนึ่งก็คือ Azure Policy ซึ่ง ASC จะมาพร้อมกับ Pre-defined Policies ครับ โดย ASC จะทำงานร่วมกับ Azure Policy เพื่อทำการประเมินและตรวจสอบ Workloads หรือ Azure Resources ต่างๆ ในเรื่องของความปลอดภัยหรือตามทำหน้าที่ในส่วนของ CSPM ตามที่ผมได้อธิบายไว้ในตอนต้นครับ 

ดังนั้นก่อนที่ท่านผู้อ่านจะใช้งาน Azure Security Center หรือ ASC สิ่งแรกที่จะต้องทำ นั่นก็คือ การวางแผนและออกแบบ Azure Security Center Architecture รวมถึง Workloads หรือ Azure Resources ต่างๆ ที่จะให้ ASC เข้าไปประเมินและตรวจสอบครับ

สิ่งที่จะต้องพิจารณาต่อมานั่นก็คือเรื่องของราคาหรือ Pricing ของ ASC ครับ ซึ่งจะมี 2 แบบครับ แบบแรกคือ ฟรีไม่มีค่าใช้จ่าย !!!!!  หรือเรียกว่า "Azure Defender off" ครับ อีกแบบคือ มีค่าใช้จ่ายครับ หรือเรียกว่า "Azure Defender on" ครับ สำหรับความแตกต่างของระหว่าง 2 แบบนั่นก็คือ ความสามารถและฟีเจอร์ครับ ซึ่งผมได้หยิบบางฟีเจอร์ของ ASC มาอธิบายในทุกท่านได้ทราบไปแล้งในตอนต้นครับ สำหรับแบบที่ ฟรี (Azure Defender on) นั้น จะ Enable โดย Default ครับ โดย ASC จะทำการตรวจและประเมิน Azure Resources  (ตามที่ได้ององค์กรได้วางแผนเอาไว้เรียบร้อยแล้ว) ที่เป็น PaaS เช่น Azure Service Fabric, Azure SQL, และอื่นๆ สำหรับ Azure Resources ที่เป็น IaaS เช่น Azure Virtual Machine จะต้องมีการติดตั้ง Agent ก่อนครับ 

สำหรับ Pricing แบบที่มีค่าใช้จ่าย (Azure Defender on) นั้นยังมาพร้อมกับฟีเจอร์ต่างๆ อีกมากมายครับ เช่น

Vulnerability Assessment เป็นฟีเจอร์ที่จะเข้าไปตรวจสอบและประเมินเรื่องของ Vulnerability เครื่อง (Virtual Machines) ขององค์กรที่อยู่ใน On-Premise หรือใน Microsoft Azure 

Just in time VM access เป็นฟีเจอร์ที่จะทำการ Lock Down Ports ที่ใช้ในการบริหารจัดการ (Management Ports) เช่น RDP (3389) Port ซึ่งโดยปรกติจะเปิดตลอดเวลาสำหรับ Azure Virtual Machine ซึ่งสุ่มเสี่ยงต่อการโจมตี (RDP Attacks) ดังนั้น Just in time VM access จะเข้ามาจัดการโดยการปิด Port ดังกล่าวและจะเปิดเมื่อมีการร้องขอ (Request) มาเท่านั้น ซึ่งผลทำให้ Azure Virtual Machine มีความปลอดภัยมากขึ้น

Adaptive Application Control เป็นฟีเจอร์ที่มีความฉลาดและมีความสามารถในการกำหนดลิสต์ของ Applications ใดที่สามารถรันและทำงานในเครื่องได้ ซึ่งจะทำให้ลดความเสี่ยงจากภัยคุกคามต่างๆ

สำหรับรายละเอียดเกี่ยวกับ Pricing (Azure Defender on และ off) ของ ASC สามารถดูได้จาก Link นี้ครับ Pricing—Security Center | Microsoft Azure

และทั้งหมดนี้คือเรื่องราวเริ่มต้นของ Azure Security ครับ โปรดติดตามตอนต่อไปเร็วๆ นี้ครับผม.....

รู้จักกับ Azure Active Directory Privileged Identity Management (PIM)

      สวัสดีครับทุกท่าน สบายดีกันทุกท่านนะครับ สำหรับบทความตอนนี้ของผมจะเป็นเรื่องราวของฟีเจอร์หนึ่งใน Azure Active Directory ที่ชื่อว่า "Azure Active Directory Privileged Identity Management" หรือเรียกสั้นๆ ว่า Azure AD PIM ครับ และถือว่า Azure AD PIM เป็นส่วนประกอบหนึ่งที่สำคัญสำหรับการ Identity Security ครับ และเพื่อไม่ให้เป็นการเสียเวลาผมจะพาทุกท่านไปทำความรู้จักกับ Azure AD PIM กันเลยครับ

Azure Active Directory Privileged Identity Management (Azure AD PIM) คืออะไร ?

เริ่มจากกันด้วยตัวอย่างง่ายๆ ก่อนที่จะเข้าสู่เรื่องราวของ Azure AD PIM ครับ โดยตัวอย่างนี้มีรายละเอียดดังนี้ครับ สมมติว่าท่านผู้อ่านทุกท่านเป็นผู้ดูแลระบบ (Administrator) หรือเรียกว่าท่านผู้อ่านเป็น Global Administrator ของ Microsoft Azure  และงานที่ท่านก็จะต้องเข้าไปยุ่งเกี่ยวนั้นก็คือ การจัดการและควบคุมการกำหนดสิทธิ์ในการเข้าถึง Resources ต่างๆ ให้กับผู้ใช้งาน ดังนั้นสิ่งที่ท่านจะต้องวางแผนและพิจารณาคือ ท่านจะจัดการ Identity (User และ Group Accounts) อย่างไร และจะกำหนดสิทธิ์ (Assign) ในการเข้าถึง Resources ต่างๆ ให้กับผู้ใช้งานอย่างไร ซึ่งแน่นอนว่าจะต้องเกี่ยวข้องกับเรื่องของ Accounts ต่างๆ ใน Azure AD นั่นก็คือ User และ Group Accounts ดังรูปครับ

โดยผมอยากจะโฟกัสไปที่ Group Account  (ใน Azure AD) มากกว่า User Account เนื่องจากผมเชื่อว่าท่านผู้อ่านทุกท่านน่าจะคุ้นเคยกับ User Account ใน Azure AD กันอยู่แล้ว สาเหตุที่ผมให้ความสนใจกับ Group Account ใน Azure AD เนื่องจาก Group Account มีประโยชน์ในเรื่องของการจัดการและควบคุมการเข้าถึง Resources หรือเรียกกันสั้นๆ ว่า "Access Control" มากครับ เพราะทำให้ง่ายและเกิดความยืดหยุ่นในเรื่องของ Access Control ครับ เพราะแทนที่ทุกท่านจะกำหนดสิทธิ์ในการเข้าถึง Resources โดยตรงให้กับผู้ใช้งาน (User Account) ก็ให้กำหนดสิทธิ์ดังกล่าวนี้ให้กับกลุ่มผู้ใช้งาน (Group Account) แทนครับ ดังนั้นหากมีการปรับเปลี่ยนหรือเปลี่ยนแปลงใดๆ เช่น ผู้ใช้งานมีการย้ายแผนกหรือมีการปรับเปลี่ยนบทบาทหน้าที่ในการทำงาน และทำให้มีความต้องการในการเข้าถึง Resources ต่างๆ มากขึ้น ในทางกลับกันอาจจะมีการ Remove สิทธิ์ในการเข้าถึงที่เคยได้รับมา  ท่านผู้อ่านก็สามารถจัดการควบคุมได้ง่ายและสะดวกกว่าการให้สิทธิ์ (Assign) โดยตรงกับผู้ใช้งาน (User Account) ครับ ซึ่ง Concept ดังกล่าวนี้ถือว่าเป็น Best Practices เบื้องต้นที่ควรนำเอามาใช้ครับ โดย Concept ดังกล่าวนี้ไม่ใช่เรื่องใหม่เลยครับ ใช้กันมานานแล้วใน Active Directory Domain Service (AD DS) ซึ่งทาง Microsoft มี Strategy ดังกล่าวนี้หลากหลายรูปแบบให้เลือกพิจารณาเพื่อนำเอาไปประยุกต์ใช้งานในองค์กรครับ 

แต่ใน Azure AD จะมีความแตกต่างกับ Active Directory Domain Service (AD DS) ในเรื่องดังกล่าวนี้ครับ ยกตัวอย่างเช่น ใน Active Directory Domain Service (AD DS) เมื่อท่านผู้อ่านทำการ Add User Account หลายๆ Accounts เข้าไปยัง Group จากนั้นก็ไปกำหนดสิทธิ์ในการเข้าถึงหรือจัดการ Resources ต่างๆ  แต่สำหรับใน Azure AD เมื่อท่านผู้อ่านทำการ Add User Accounts เข้าไปยัง Group (ใน Azure AD) เรียบร้อย จากนั้นท่านผู้อ่านจะต้องทำการกำหนดสิทธิ์ในเข้าถึงหรือจัดการ Resources ผ่านทางสิ่งที่เรียกว่า "Role-Based Access Control" เรียกสั้นๆ ว่า RBAC ครับ โดย Microsoft ได้เตรียม Built-In RBAC Roles ต่างๆ มากมายเพื่อช่วยองค์กรในเรื่องของ Access Control ครับ  ดังรูปด้านล่างครับ

และสำหรับท่านผู้อ่านท่านใดที่มีความคุ้นเคยหรือชำนาญกับเรื่องของ Access Control ใน Active Directory Domain Service (AD DS) ผมอยากให้นึกภาพตามสิ่งที่ผมกำลังจะอธิบายต่อจากนี้ครับ เริ่มจาก เมื่อผมต้องการให้ผู้ใช้งาน (User Account) เข้าถึงข้อมูล ตาม Best Practices ข้างต้น ผมจะทำการ Add ผู้ใช้งาน (User Account) ดังกล่าวเข้าไปยัง Group ที่มีสิทธิ์ นั่นหมายความว่าผู้ใช้งาน (User Account) ดังกล่าวก็จะกลายเป็นสมาชิกของ Group และสุดท้ายผู้ใช้งานดังกล่าวก็จะมีสิทธิ์ในการเข้าถึงข้อมูลหรือ Resources ต่างๆ ตาม Group ที่ตัวของผู้ใช้งานเป็นสมาชิกอยู่ ถูกต้องมั๊ยครับ,,,  คำถามคือ การเป็นสมาชิกของผู้ใช้งาน (User Account) กับ Group จากประเด็นดังกล่าวนี้ การเป็นสมาชิกที่ว่านี้จะอยู่นานแค่ไหนครับ?  คำคอบ คือ ตลอดไปตราบเท่าที่ทุกท่านซึ่งเป็นผู้ดูแลระบบ ยังไม่ทำการ Remove ผู้ใช้งานท่านดังกล่าวออกจาก Group ครับ และถ้าในความเป็นจริงแล้ว ผู้ใช้งานท่านดังกล่าวนี้ ต้องการที่จะเข้าถึงข้อมูลเพียงช่วงเวลาหนึ่ง ไม่ต้องการตลอดล่ะครับ ท่านผู้อ่านจะจัดการอย่างไรครับ  คำตอบคือ  Azure AD PIM ครับ ซึ่งจะเป็นฟีเจอร์ที่จะเข้ามาช่วยจัดการและควบคุมครับจากเรื่องราวทั้งหมดที่ผมได้อธิบายไว้ในข้างต้นครับ ด้วยเหตุผลที่ ณ วันนี้หลายๆ องค์กรต้องการที่หาวิธีการที่จะลดจำนวนผู้ใช้งานที่จะเข้าถึงข้อมูลหรือ Resources ต่าง ๆ เช่น Azure AD, Azure Resources, Microsoft 365 และ SaaS Applications ต่างๆ โดยมีวัตถุประสงค์คือ ลดความเสี่ยงต่อความไม่ปลอดภัยกับ Resources เหล่านี้  ตามที่ผมได้อธิบายจากตัวอย่างข้างต้นและทุกท่านจะเห็นว่ามีสิ่งใดบ้างที่เราจะต้องทำการพิจารณาวางแผนและจัดการครับ

ความสามารถของ Azure Active Directory Privileged Identity Management (Azure AD PIM)

Azure AD PIM จะเป็นฟีเจอร์ที่จะเข้ามาช่วยในจัดการและควบคุมการกำหนดสิทธิ์ โดยสามารถเลือกหรือกำหนด User หรือ Group Accounts ใน Azure AD กับ Roles (RBAC Roles) ที่เหมะสมเพื่อเข้าถึงและใช้งาน Azure AD, Azure Resources, และอื่นๆ ได้ แต่สิทธิ์ดังกล่าวนี้จะไม่ได้ให้หรืออยู่ตลอดไปนะครับ จะมีช่วงเวลาทั้งนี้ขึ้นอยู่กับผู้ดูแลระบบหรือท่านที่มีหน้าที่เกี่ยวข้องเป็นผู้กำหนดครับ  โดยใน Azure AD PIM ได้เตรียมความสามารถที่เรียกว่า Time-Based และ Approval Based Role Activation ครับ โดยมาพร้อมกับ Workflow ในการจัดการและควบคุมครับ ซึ่งประกอบไปด้วย  Assign, Activate, Approve, และ Audit เพื่อช่วยลดความเสี่ยง เช่น การให้สิทธิ์ผู้ใช้งานมากเกินกว่าความจำเป็น,  การกำหนดและให้สิทธิ์ที่ไม่ถูกต้องและอื่นๆ ซึ่งผมได้อธิบายเอาไว้ในข้างต้นครับ และนี่คือสิ่งที่ Azure AD PIM สามารถทำได้ครับ

1. กำหนด Roles แบบ Just-in-time privileged ให้กับผู้ใช้งานในการเข้าถึง Azure AD และ                              Azure Resources ต่างๆ 

2. กำหนด Time-bound ในการเข้าถึง Resources ต่างๆ โดยกำหนดวันที่เริ่มและสิ้นสุด

3. ทำการ Approve เพื่อทำการ Activate Privileged Roles ให้กับผู้ใช้งาน

4. ใช้งานร่วมกับ Multi-Factor Authentication

5. การแจ้งเตือน (Notification) เมื่อ Privileged Roles ถูก Activated

6. ใช้งานร่วมกับ Azure AD Access Reviews เพื่อทำการตรวจสอบว่าผู้ใช้งานยังคงต้องการ Roles นั้นๆ อยู่

7. Auditing

รูปด้านล่าง คือ Azure AD PIM Dashboard ครับ

เตรียมพร้อมสำหรับ Azure Active Directory Privileged Identity Management (Azure AD PIM) 

สำหรับท่านที่จะบริหารและจัดการ Azure AD PIM ได้นั้น จะต้องอยู่ใน Privileged Role Administrator หรือ Global Administrator ครับ และต้องการ Azure AD Premium P2 License ครับ ซึ่งถ้ามีครบเรียบร้อยแล้วก็จะเข้าสู่ขั้นตอนต่อมาคือ การรวบรวบข้อมูลและความต้องการ เพื่อนำเอามาใช้สำหรับการวางแผนและออกแบบในเรื่องของการจัดการและควบคุมการเข้าถึง Azure AD, Azure Resources ต่างๆ ซึ่งแน่นอนว่าแต่ละองค์กรก็จะมีรายละเอียดที่แตกต่างกันไปครับ จากนั้นก็ทำการ Deploy Azure AD PIM ครับ

สำหรับในส่วนของ RBAC Roles ที่สามารถใช้งานร่วมกับ Azure AD PIM ได้มีดังนี้ครับ

Azure AD Roles เป็น Roles ที่เกี่ยวข้องกับการบริหารและจัดการ Azure Active Directory

Azure Roles เป็น Roles ที่เกี่ยวข้องกับการบริหารและจัดการ Azure Resources ต่างๆ 

รายละเอียดเกี่ยวกับ Azure AD RBAC Built-In Roles สามารถดูได้จาก Link นี้ครับ

Azure AD built-in roles - Azure Active Directory | Microsoft Docs

รายละเอียดและข้อมูลเพิ่มเติมเกี่ยวกับ Azure AD PIM สามาถดูได้จาก Link นี้ครับ

Privileged Identity Management documentation | Microsoft Docs

และทั้งหมดนี้คือเรื่องราวของ Azure Active Directory Privileged Identity Management (Azure AD PIM) ที่ผมอยากให้ท่านผู้อ่านทุกท่านได้รู้จักครับ และต้องบอกว่า Azure AD PIM เป็นฟีเจอร์ที่น่าสนใจและเป็นส่วนประกอบหนึ่งที่สำคัญสำหรับการทำ Identity Security ครับ ซึ่งเป็นเรื่องที่สำตัญมากสำหรับทุกองค์กรที่นำเอา Cloud Technology เข้าไปประยุกต์ใช้งาน สิ่งหนึ่งที่องค์กรจะต้องทำการวางแผนและเตรียมความพร้อมนั่นก็คือ เรื่องของการจัดการ Identity (Identity and Access Management) ครับ เพราะผู้ใช้งานในองค์กรมีความต้องการที่จะเข้าถึงข้อมูลหรือ Resources ต่างๆ ที่อยู่ใน On-Premise และ Cloud  คำถามคือ องค์กรดังกล่าวจะจัดการเรื่องของ Identity สำหรับประเด็นนี้อย่างไร จะใช้ Solution ใดเข้ามาจัดการเรื่องดังกล่าวนนี้ คำตอบคือ ใช้ Azure Active Directory หรือ Azure AD ที่ทาง Microsoft ได้เตรียมเอาไว้ใหักับลูกค้าของ Microsoft เรียบร้อยแล้วครับ อีกประเด็นหนึ่งที่จะต้องพิจารณาควบคู่กันไปกับเรื่องของการจัดการ Identity นั่นก็คือ เรื่องของ Identity Security ครับ และตอนนี้ท่านผู้อ่านทราบแล้วว่าจะใช้อะไรเข้ามาช่วยในเรื่องนี้ ซึ่งยังมีรายละเอียดอีกเยอะครับสำหรับเรื่องของ Identity Security เอาไว้ผมจะมาเล่าสู่กันฟังในโอกาสต่อไปครับผม.....

Azure Resource Mover

      สวัสดีครับทุกท่าน เรากลับมาพบกันอีกครั้งสำหรับเรื่องราวของ Microsoft Azure ครับ และสำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับฟีเจอร์ใหม่ที่มีชื่อว่า "Azure Resource Mover" ครับ โดยส่วนตัวผมถือว่าเป็นฟีเจอร์หนึ่งที่น่าสนใจและมีประโยชน์มากครับ ก่อนที่จะมาทำความรู้จักกับ Azure Resource Mover ผมขออนุญาตอธิบายเพิ่มเติมซักนิดก่อนนะครับ เริ่มจากเราได้มีการสร้างและ Deploy Azure Services ต่างๆ ใช้งาน เช่น Azure Storage, Azure Virtual Network, Azure Virtual Machine, และอื่นๆ ใช้งานกันในองค์กรหรือในออฟฟิศ และมีความเป็นไปได้ว่าในเวลาต่อมา หลายๆ องค์กรหรือออฟฟิศมีความต้องการที่จะทำการย้าย Resources (Azure Services ต่างๆ ที่ได้มีการสร้างและใช้งานอยู่) จาก Resource Group หนึ่งไปอีก Resource Group หนึ่งซึ่งจะอยู่ใน Azure Subscription เดียวกันหรือคนละ Azure Subscription ก็ตาม ซึ่งสามารถทำได้หลายวิธีครับ เช่น ใช้ Azure Portal หรือ PowerShell เป็นต้นครับ แต่ถ้าผมมีความต้องการที่จะย้าย Resources ต่างๆ ข้าม Location หรือย้ายไปอีก Location หนึ่งล่ะครับ จะทำได้หรือไม่ คำตอบคือ สามารถทำได้ครับแต่ไม่ใช่ทำด้วยวิธีการง่ายๆ ครับ 

แต่สำหรับวันนี้สามารถทำได้และไม่ยุ่งยากเหมือนก่อนครับ เพราะมี Azure Resource Mover ฟีเจอร์ใหม่มาช่วยแล้วครับ และด้วยความสามารถของฟีเจอร์ดังกล่าวนี้ สามารถช่วยองค์กรหรือออฟฟิศที่มีความต้องการจะย้าย Resources ข้าม Locations ครับ ผมขออยกตัวอย่างสถานการณ์ที่ต้องการย้าย Resources จาก Location หนึ่งไปอีก Location หนึ่งครับ

- องค์กรหรือบริษัทต้องการย้ายไปประเทศอื่น

- องค์กรต้องการย้าย Server (Azure Virtual Machine) ไปยังอีกที่หนึ่ง เช่น สาขาต่างๆ 

- องค์กรต้องการย้ายเพื่อให้เป็นไปตามกฎข้อบังคับ (Regulation)

และจากสถานการณ์หรือตัวอย่างข้างต้น เป็นตัวอย่างที่ทำให้เกิดความต้องการในการย้าย Resources ต่างๆ ข้าม Location ครับ ดังนั้นจึงเป็นสิ่งที่ Azure Resource Mover จะเข้ามาช่วยได้ครับ โดยฟีเจอร์ดังกล่าวนี้จะช่วยลดความยุ่งยากสลับซับซ้อนสำหรับการย้าย Resources ซึ่งท่านผู้อ่านท่านใดมีประสบการณ์เคยทำการย้าย Resources ต่างๆ ใน Microsoft Azure มาก่อน จะทราบดีว่าไม่ใช่เรื่องง่ายเลยครับ อย่างผมเคยมีประสบการณ์เข้าไปช่วยลูกค้าย้าย Resources ข้าม Azure Subscription ซึ่งแต่ก่อนนี้ต้องทำด้วย PowerShell อย่างเดียวครับ ไม่สามารถใช้ Azure Portal ได้ แต่เดี๋ยวนี้สามารถทำได้แล้วรวมถึงย้ายข้าม Location ด้วยครับ และในขณะที่ทำการย้าย Resources ที่อยู่ฝั่งต้นทาง (Source) จะยังคง Active อยู่จนกว่าการย้าย Resources ดังกล่าวมายังฝั่งปลายทาง (Target) เสร็จครับ และสุดท้ายก็จะทำการลบ Resources ต่างๆ ที่อยู่ต้นทาง (Source) ก็เป็นอันเสร็จสิ้นกระบวนการย้ายครับผม

เอาล่ะครับผมจะพาทุกท่านมาดูวิธีการย้าย Resources ต่างๆ โดยใช้ Azure Resource Mover กันครับ  เริ่มจากผมมี Resource Group ชื่อว่า SourceRG ซึ่งมี Resources ต่าง ๆ ดังรูปครับ

และมีอีก Resource Group อีก Resource Group หนึ่งชื่อ TargetRG ซึ่งอยู่คนละ Location หรือ Region กับ SourceRG ครับ  จากนั้นผมจะลองทำการเลือก Resources ต่างๆ เพื่อทำการย้าย ดังรูปครับ

จากรูปด้านบนผมได้ทำการเลือก Resources ในที่นี้คือ Azure Virtual Machine ครับ จากนั้นเลือก Move จากนั้นเลือก Move to another region จากนั้นจะเข้ามาที่หน้าจอตามรูปด้านล่างครับ

จากนั้นให้คลิ๊ก Next ครับ ด้งรูปครับ

คลิ๊ก Checkbox แล้วคลิ๊ก Proceed ดังรูปครับ

จากนั้นรอซักครู่ครับ

จากนั้นไปที่ Azure Resource Mover ดังรูปครับ

จากนั้นให้คลิ๊กที่ Across Regions เพื่อให้ Azure Resource Mover ทำการตรวจสอบเรื่องของ Dependencies (Validate Dependencies) ของ Resources (Azure Virtual Machine)  ดังกล่าวว่ามี Resources อื่นๆ ที่เกี่ยวข้องหรือไม่ ซึ่งถ้ามี เราจะต้องทำการ Add Dependencies ที่เกี่ยวข้องเข้าไป ดังรูป

จากนั้นรอซักครู่ Azure Resource Mover ก็จะทำการ Add Dependency Resources ดังกล่าวเข้ามา ดังรูปครับ

จากนั้นทำการเลือก Resources ต่างๆ ที่ต้องการย้าย จากนั้นผมจะเริ่มทำการย้าย โดยการคลิ๊ก Initiate Move ใน Azure Resource Mover ครับ

และจากนั้นก็รอครับ สุดท้าย Resources ดังกล่าวก็จะถูกย้ายไปยัง TargetRG (Resource Group) ใน Location หรือ Region ที่ต้องการครับ  โดยรวมผมมองว่าขั้นตอนและการกำหนดค่าต่างๆ ของ Azure Resource Mover ไม่ได้ยุ่งยากสลับซับซ้อนอะไรครับ แต่สิ่งที่ยากและมีรายละเอียดคือ การเตรียมความพร้อมครับ สำหรับการย้าย Resources จะใช้เวลามากหรือน้อยขึ้นอยู่กับปัจจัยหลายอย่างครับ เช่น ชนิดของ Resources เป็นต้น 

แต่สิ่งที่สำคัญที่สุดคือ จะต้องทำการวางแผนเพื่อเตรียมความพร้อมก่อนที่จะทำการย้ายนะครับ เช่น ควรจะทำการตรวจเช็ค Resources ต่างๆ ที่ต้องการย้าย เพราะมี Resources บางชนิดที่ไม่สามารถย้ายได้ครับ โดยสามารถตรวจเช็คได้จาก Link นี้ครับ https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/move-support-resources

และทั้งหมดนี้คือเรื่องราวของ Azure Resource Mover ครับผม.....