Identity Management Evo ก่อนจะเข้าสู่ Passkeys

     สวัสดีครับทุกท่านสำหรับ สำหรับบทความนี้จะเป็นบทความที่เกี่ยวข้องกับการบริหารจัดการ Identity ด้วย Microsoft Entra ครับ โดยช่วงที่ผ่านมานั้นมีด้วยกัน  4 ตอน และบทความตอนนี้ ผมจะเรียกว่าเป็นตอนพิเศษครับ โดยตั้งใจว่าจะนำเสนอเรื่องราวเกี่ยวกับวิวัฒนาการหรือ Evo (Evolution) ของการบริหารจัดการ Identity ครับ ประกอบในช่วงที่ผ่านมานั้นทาง Microsoft ได้แจ้งองค์กรต่างๆ ที่ใช้งาน Microsoft Cloud Services ต่างๆ เช่น Microsoft Azure, Microsoft 365, และอื่นๆ ให้ได้ทราบกันว่าทาง Microsoft จะมีการเปลี่ยนแปลงเกี่ยวกับเรื่องของ Authentication โดยจะมีการเริ่มใช้งานรูปแบบหรือวิธีใหม่โดยมีการนำเอา "Passkeys" มาใช้งานครับ และผมได้เขียนเรื่องของ Passkeys ให้ทุกท่านได้รู้จักกันไปแล้วในบทความ "บริหารจัดการ Identity ด้วย Microsoft Entra ตอนที่ 4" ไปก่อนหน้านี้ครับ ท่านใดสนใจสามารถไปที่ Link นี้ได้เลยครับ, WT Blog (ITGeist): บริหารจัดการ Identity ด้วย Microsoft Entra ตอนที่ 4 (Passkeys)

และอย่างที่เกริ่นไว้ข้างต้นของบทความนี้ว่า บทความนี้เป็นตอนพิเศษ โดยผมจะเล่าเรื่องราวของการวิวัฒนาการของการจัดการ Identity (Identity Management Evo) ครับ โดยผมขอเริ่มด้วยกระบวนการที่จะเข้ามาเกี่ยวข้องกับการบริหารจัดการ Identity ที่เราจะต้องเข้าไปเกี่ยวข้องไม่ว่าองค์กรของท่านจะใช้ระบบการบริหารจัดการ Identity ยี่ห้อใดก็ตาม สำหรับทความของผมขอเน้นไปที่ Microsoft Solutions (Microsoft Entra) ครับ แต่สามารถนำเอาไปประยุกต์ใช้งานกับระบบการบริหารจัดการ Identity อื่นๆ ได้ครับ ที่เกริ่นค้างไว้คือ กระบวนการที่เกี่ยวข้องกับการบริหารจัดการ Identity ซึ่งจะประกอบไปด้วย 3 กระบวนการหลักหรือเรียกกระบวนดังกล่าวนี้ว่า "AAA" ประกอบไปด้วย (แบบคร่าวๆ นะครับ)

Authentication = กระบวนในการตรวจสอบ (Verify) Identity 

Authorization = กระบวนการตรวจสอบสิทธิ์ (Permissions) ของ Identity ที่ผ่านการตรวจสอบก่อนหน้านี้

Auditing = กระบวนการตรวจสอบโดยจะมีการบันทึกเหตุการณ์/Activity ต่างๆ ของ Identity ที่เกิดขึ้น

โดย AAA จะถูกดำเนินการผ่านทาง Identity Provider (IdP) ครับ เช่น ถ้าเป็นของ Microsoft เช่น Active Directory Domain Service (AD DS) ซึ่งเป็น Role (ไม่ใช่ Feature นะครับ) หนึ่งใน Windows Server ซึ่งถ้า Role ดังกล่าวนี้ติดตั้งไปที่ Windows Server ตัวใดก็ตาม เราจะเรียก Windows Server ตัวดังกล่าวที่มีการติดตั้ง AD DS Role ว่า "Domain Controller" หรือ "DC" และ DC จะทำหน้าที่ในการบริหารจัดการ Identity ผ่านทางกระบวนที่ได้อธิบายไปครับ อีก Solution ในการบริหารจัดการ Identity ซึ่งจะอยู่บน Cloud นั่นก็คือ "Microsoft Entra ID" ซึ่งเป็นสมาขิกตัวนึงที่อยู่ภายใต้ Microsoft Entra Product Family ครับ โดย Microsoft Entra ID จะถูก Bundled มาพร้อมกับ Microsoft Cloud Services เช่น Microsoft 365, Microsoft Azure, และอื่นๆ ครับ และจะดำเนินการกระบวนการ AAA เช่นกันครับ

และอย่างที่หลายท่านทราบกันว่าในช่วงที่ผ่านมาเรื่องของการบริหารจัดการ Identity ตลอดจนการ Secure & Protect Identity ถือว่าเป็นเรื่องหนึ่งที่มีความสำคัญที่ทุกๆ องค์กรจะต้องเตรียมความพร้อมตั้งแต่การวางแผนและออกแบบเพื่อดำเนินการเรื่องดังกล่าวนี้ อีกทั้ง ณ ปัจจุบัน Identity ถือว่าเป็น Foundation ของ Modern Cybersecurity ครับ เนื่องจาก Identity ถือว่าเป็นเป้าหมายหลักของการ Attacks ครับ และจึงเป็นสิ่งที่ทาง Microsoft ตลอดจน Vendors ต่างๆ ให้ความสำคัญกับเรื่องของการบริหารจัดการ Identity ครับ และต้องบอกว่าท่านใดที่สนใจเรื่องของ Cloud Security หรือ Cybersecurity ประเด็นหนึ่งหรือหัวข้อหนึ่งที่จะเข้ามาเกี่ยวข้องนั่นก็คือ "Identity" ที่ว่านี้ล่ะครับ ตลอดจนท่านใดที่รู้จัก "Zero Trust", Identity ถือว่าเป็น Foundation Pillar หรือส่วนประกอบหลักส่วนหนึ่งครับ สำหรับการที่เราจะทำการวางแผนและออกแบบเพื่อทำการ Secure & Protect IT Environments (ครอบคลุมทั้ง Hybrid และ Multi-Cloud) ครับ

ดังนั้นการที่เราจะเข้าไปเกี่ยวข้องกับการบริหารจัดการ Identity รวมถึงเรื่องของความปลอดภัยของ Identity เราจะพิจารณาและดำเนินการอย่างไร? ซึ่งก็จะเกี่ยวข้องกับ AAA กระบวนที่ได้อธิบายไปคร่าวๆ ก่อนหน้านี้ครับ โดยผมขอเริ่มจาก A ตัวแรก "Authentication" ก็จะมีคำศัพท์และคอนเซปที่เกี่ยวข้องกับ Authentication เริ่มด้วย

- Legacy Authentication หมายถึง Authentication Protocols ที่เราใช้กันในช่วงก่อนหน้านี้ โดยเฉพาะกับ Active Directory Domain Service (AD DS) เช่น  NTLM และ Kerberos เป็นต้น และจะมาพร้อมกับรูปแบบ Authentication ที่เรียกว่า "Single Step Authentication" นั่นก็คือ Username และ Password ที่ผู้ใช้งานจะต้องเตรียมเพื่อเข้าสู่กระบวนนี้ (Authentication) ก่อนที่จะเข้าสู่กระบวนต่อไป

- Modern Authentication หมายถึง กระบวนที่ครอบคลุมทั้ง Authentication และ Authorization ซึ่งมีความปลอดภัยมากขึ้น โดยจะมาพร้อมกับ Authentication Protocols เช่น OAuth, SAML, WS-Federation, เป็นต้น รวมถึงวิธีการในการ Authentication ต่างๆ เช่น Multi-Factor Authentication และ Feature ต่างๆ เช่น Conditional Access (เป็น Feature หนึ่งของ Microsoft Entra ID) เป็นต้น นอกจากนี้แล้วในขั้นตอนการทำงานของกระบวน Authentication ยังมาในรูปแบบของ Claim-Based Authentication และ Tokens ครับ

ดังนั้นในช่วงที่ผ่านมารวมถึง ณ ปัจจุบัน ก่อนที่ผู้ใช้งานจะเข้าถึงข้อมูลหรือ Resources ต่างๆ ขององค์กรไม่ว่าจะอยู่ใน On-Premise และ On Cloud ก็จะต้องเข้าสู่กระบวนการ AAA โดยเริ่มจากกระบวน Authentication ซึ่งในฝั่งของผู้ใช้งานจะต้องเตรียม Username และ Password (หรือจะเรียกว่า Credential) โดยดำเนินการตามวิธีของการ Authentication ที่เรียกว่า "Single Step Authentication" ซึ่ง ณ ปัจจุบันหากองค์กรใดยังใช้วิธีดังกล่าวนี้อยู่ ก็จะต้องทราบว่ามันที่ความเสี่ยงที่จะถูก Attacks ด้วยเทคนิคต่างๆ เช่น Phishing, Brute Force, และอื่นๆ เพราะ Attackers ต้องการขโมย Credentials ของผู้ใช้งาน เพื่อจะได้นำเอา Credentials ที่ได้ไป นำไปใช้งานครับ ดังนั้นเพื่อเป็นการป้องกันหรือทำให้วิธี Single Step Authentication มีความปลอดภัยมากขึ้น ก็จะต้องมีการกำหนดและบังคับใช้เรื่องของ Password Policy, Account Lockout Policy, เป็นต้นครับ

จากนั้นในเวลาต่อมาครับ ก็จะมีคอนเซปและวิธีการใหม่เข้าในช่วงเวลานั้นๆ นั่นก็คือ "Multi-Factor Authentication" หรือ "MFA" ซึ่งจะมาใช้แทนวิธีเดิม (Single Step Authentication) ครับ และโดยคอนเซปของ MFA คือ ในกระบวนการ Authentication จากเดิมที่เป็น Single Step ก็จะมีการเพิ่มอีก Step หนึ่งเข้าไปเพื่อทำให้กระบวนการ Authentication มีความปลอดภัยมากขึ้นครับ

โดยในคอนเซปและการทำงานของ MFA จะประกอบไปด้วย:

- Something you know เช่น Username และ Password, PIN, เป็นต้น

- Something you have เช่น Mobile Phone, Smart Card, Security Key, Certificate, เป็นต้น

- Something you are เช่น Biometric (Facial Recognition, Fingerprint, เป็นต้น)

โดยมีหลากหลายวิธีให้เลือกใช้สำหรับ MFA ครับ ยกตัวอย่างเช่น

1. MFA-Mobile Phone, จะมีการใช้ SMS ในการรับ Verification Code หรือ Voice Call  *Microsoft ได้มีการแจ้งเตือนว่าทาง Microsoft จะมีการ Retire หรือเลิกใช้ในเร็วนี้ตาม Timeline ที่ทาง Microsoft ได้มีการกำหนดไว้ครับ Passkeys by default and retirement of Microsoft-provided SMS and voice authentication - Microsoft Entra ID | Microsoft Learn

2. MFA-OATH Token, จะมีทั้งที่เป็น Hardware Token และ Software Token

3. MFA-Microsoft Authenticator App, จะเป็นวิธีที่เกี่ยวข้องกับคอนเซปและเทคโนโลยี "Passwordless Authentication" และใช้ Asymmetric Key Pair  และ Protected ด้วย Biometrics, เป็น Message ส่งมาให้เรากด Approve จากผู้ใช้งาน (ซึ่งเราเรียกการทำงานดังกล่าวว่า Push Notification) ต่อมาทาง Microsoft ได้ทำการพัฒนาความสามารถของ Microsoft Authenticator ออกมาหลายอย่างครับ หนึ่งในนั้น คือ ความสามารถในการป้องกัน MFA Fatigue โดยจะต้องมีการกดตัวเลข (2 หลัก) เพื่อแก้ความเสี่ยงเดิม คือ ผู้ใช้งานได้รับการแจ้งเตือนจาก Push Notification แล้วกด Approve ตามที่ได้อธิบายไว้ก่อนหน้านี้ครับ และมีการแสดงชื่อของ Identity (เช่น Apps) และ Geographic Location เพิ่มเข้ามาด้วยครับ

4. MFA-Windows Hello for Business (WHB), *เป็น "Windows Hello สำหรับใช้งานในองค์กร และเป็นวิธีที่เกี่ยวข้องกับคอนเซปและเทคโนโลยี "Passwordless Authentication"และใช้ Asymmetric Key Pair โดยมีการผูก Key เข้ากับ Device (TMP Chip)

5. MFA-FIDO2 Security Key, เป็นวิธีที่จะต้องใช้ Hardware เข้ามาใช้งาน และเป็นวิธีที่เกี่ยวข้องกับคอนเซปและเทคโนโลยี "Passwordless Authentication" และใช้ Asymmetric Key Pair 

จากนั้นก็จะมาถึง "Passkeys" ครับ ซึ่งทาง Microsoft จะนำเข้ามาใช้ในการบริหารจัดการ Identity ในส่วนของกระบวนการ Authentication โดย Microsoft ได้เตรียม Microsoft Entra และ Microsoft Entra ID รองรับการทำงานร่วมกับ Passkeys เพื่อใช้ในกระบวนการ Authentication และรองรับกับ MFA ด้วยครับ เพราะตัวของ Passkeys คือ รูปแบบของการ Authentication ที่มีความปลอดภัยมากกว่าเดิม และมาพร้อมกับความสามารถต่างๆ เช่น Phishing-Resistant และอื่นๆ ครับ รายละเอียดเพิ่มเติมเกี่ยวกับเรื่องของ Passkeys กับ Microsoft Entra ไปที่ Links เหล่านี้ครับ

Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID | Microsoft Security Blog

Passkeys (FIDO2) authentication method in Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn

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

ทำความรู้จักกับ Copilot in Azure (Azure Copilot)

      สวัสดีครับทุกท่าน สำหรับบทความนี้จะพาทุกท่านไปทำความรู้จักกับ Microsoft Copilot ซึ่งเป็น Commercial AI Product ของทาง Microsoft ครับ ซึ่งทาง Microsoft ได้วางแผนให้ Microsoft Copilot ไปทำงานร่วมกับ Products/Services ต่างๆ ของ Microsoft ครับ ไม่ว่าจะเป็น Microsoft 365, Microsoft Intune, Microsoft Purview, Microsoft Security Solutions, และอื่นๆ ครับ

และสำหรับบทความนี้ผมจะพาทุกท่านไปทำความรู้จักกับ Microsoft Copilot ที่ไปทำการ Integrate หรือไปทำงานร่วมกับ Microsoft Azure ครับ หรือเรียกว่า "Copilot in Azure" หรือ "Azure Copilot" ครับ ซึ่งยังไม่ค่อยมีใครรู้จักมากซักเท่าไร แต่ต้องบอกทุกท่านก่อนว่าเจ้า Copilot in Azure หรือ Azure Copilot มีประโยชน์มากสำหรับองค์กรตลอดจนท่านใดที่ใช้งาน Microsoft Azure อยู่ครับ และเพื่อไม่ให้เป็นการเสียเวลาผมจะพาทุกท่านไปทำความรู้จักกับ Copilot in Azure หรือ Azure Copilot กันเลยครับ

ทำความรู้จักกับ Azure Copilot (Copilot in Azure)

โดยตัวของ Azure Copilot เป็น AI Assistant ที่ถูกนำมา Integrated ให้ทำงานกับ Microsoft Azure ครับ ซึ่งจะเข้ามาช่วยเราตั้งแต่การ Plan, Design, Operate, Optimize, และ Troubleshoot Microsoft Azure Environments 

โดยการนำเอา AI เทคโนโลยีเข้ามาช่วยครับ เช่น LLMs (เป็นรูปแบบของ AI ที่เข้าใจและโต้ตอบด้วย Natural Human Language) ซึ่งเป็นเครื่องมือหลักของ Copilot in Azure (Azure Copilot) ทำให้มันมีความสามารถในการโต้ตอบ (Response) และทำงานต่างๆ เช่น Queries, Generating Code, Summarize Data, เป็นต้น ยิ่งไปกว่านั้น Copilot in Azure (Azure Copilot) ยังนำเอา LLMs และการทำ Governance, Access Control, Microsoft Graph, และอื่นๆ มาช่วยเราหรือองค์กรในการบริหารจัดการ Azure Environments ขององค์กรให้มีประสิทธิภาพมากขึ้นครับ

อีกมุมหนึ่ง Copilot in Azure (Azure Copilot) คือ AI Agent ของเราที่สามารถเข้าถึงและใช้งานผ่านทาง Azure Portal, Azure CLI, และอื่นๆ  

และด้วยความสามารถต่างๆ ในข้างต้นส่งผลทำให้ท่านที่เป็นผู้ดูแลบริหารจัดการ Microsoft Azure สามารถเห็นภาพรวมและข้อมูลต่างๆ แบบเจาะลึก (Deep Insight) ของ Azure Environments ที่ดูแลอยู่ เพื่อดำเนินการในเรื่องของการ Operations และการบริหารจัดการต่างๆ ใน Microsoft Azure ได้อย่างถูกต้องและเหมาะสมด้วย Azure Copilot เช่น ตัวอย่างในรูปด้านล่าง เราสามารถให้ Azure Copilot เข้ามาช่วยในการออกแบบ, Optimize ค่าใช่จ่าย, และอื่นๆ ในการสร้างและ Deploy Azure Virtual Machine ใช้งานในองค์กรครับ

หรือใช้ Azure Copilot ให้ช่วยตรวจสอบ Azure Services/Resources ต่างๆ ตามที่ต้องการ เช่น ผมต้องการทราบว่ามี Azure Services/Resources ถูกสร้างขึ้นเมื่อ 24 ชั่วโมงที่ผ่านมา ดังรูปด้านล่างครับ

อีกตัวอย่างหนึ่ง คือ เราสามารถให้ Azure Copilot (Copilot in Azure) ช่วยเขียน KQL (Kusto Query Language) Query ในการลิสต์ Azure Virtual Machines ที่ใช้งานอยู่ตาม OS ดังรูปด้านล่างครับ

โดย Default, ตัวของ Azure Copilot (Copilot in Azure) จะ Available ให้กับผู้ใช้งานทุกคนครับ แต่สามารถถูกกำหนดสิทธิ์ในการเข้าถึงหรือใช้งาน Azure Copilot (Copilot in Azure) จากผู้ดูแลและบริหารจัดการ (ผู้ที่มีสิทธิ์เป็น Global Administrator)

ยังมีความสามารถอีกเยอะแยะมากมายตลอดจน Use Cases ต่างๆ ที่เราสามารถจะใช้ Azure Copilot (Copilot in Azure) ครับ บทความนี้เป็นเพียงแค่การพาทุกท่านไปทำความรู้จักแค่นั้น รายละเอียดเพิ่มเติมเกี่ยวกับ Azure Copilot (Copilot in Azure) ไปที่ Link นี้ได้เลยครับ, Azure Copilot Overview | Microsoft Learn

ผมเชื่อว่าทุกท่านน่าจะพอเห็นภาพว่า Azure Copilot (Copilot in Azure) ซึ่งเป็นการนำเอา AI เทคโนโลยีเข้ามาช่วยในการบริหารจัดการและดำเนินการต่างๆ กับ Azure Environments ขององค์กรได้อย่างไร และที่สำคัญ ณ ตอนนี้ Azure Copilot (Copilot in Azure) ทาง Microsoft ให้ใช้งานได้ฟรี !!!!!! ครับผม.....

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

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมขอนำเสนอเรื่องราวเกี่ยวกับ "Passkeys" ซึ่งทาง Microsoft นำเอามาใช้งานใน Microsoft Entra ID ครับ สำหรับเรื่องที่มาที่ไปของ Passkeys นั้นจะเกี่ยวข้องกับเรื่องของกระบวนการ Authentication ครับ ซึ่งทาง Microsoft เองก็ได้มีการปรับปรุงพัฒนาอย่างต่อเนื่อง โดยมีวัตถุประสงค์คือทำให้กระบวนการทำ Authentication ของ Identity นั้นมีความแข็งแรงและปลอดภัยมากขึ้นครับ

โดยหากเรานึกถึงกระบวนการของทำ Authentication ในมุมของผู้ใช้งานก็จะต้องเตรียม (Username และ Password) หรือเรียกว่า "Credential" เพื่อทำการตรวจสอบ (Verified) ตัวตนกับ Identity Provider ที่องค์กรใช้งานอยู่ เช่น ถ้าเป็นของ Microsoft ถ้าอยู่ใน On-Premise ก็จะเป็นหน้าที่ของ Active Directory Domain Service (AD DS) หรือถ้าอยู่บน Cloud ก็จะเป็นหน้าที่ของ Microsoft Entra ID ครับ โดยการ Authenticate นั้น โดยปรกติก็จะเป็นแบบที่เรียกว่า "Single Step Authentication" คือ ฝั่งของผู้ใช้งานเตรียม Credentials เพื่อเข้าสู่กระบวนการดังกล่าวครับ ซึ่งการ Authenticate แบบ Single Step นี้ 

*การใช้ Single Step Authentication (Passwords) ถือว่ามีความเสี่ยงที่จะถูกโจมตีจากหลากหลายรูปแบบ เช่น Phishing, Brute Force, และ Credential Stuffing ครับ แต่จะเสี่ยงมากหรือน้อยก็ขึ้นอยู่กับการบริหารจัดการ Identity ของแต่ละองค์กรเองว่าจะมีการจัดการเรื่องนี้อย่างไร เช่น มีการกำหนดและบังคับใช้ในเรื่องของ Password Policy, Account Lockout Policy, เป็นต้น แต่สังเกตให้ดีคือ ผู้ใช้งานยังคงจะมีหน้าที่ในการจัดการกับ Passwords ของตัวเอง รวมถึงจะต้องทำ Passwords ของตัวเองในแต่ละช่วงเวลาเพราะจะมี Policy บังคับให้เปลี่ยน Passwords ซึ่งก็อาจจะเป็นปัญหาหรือเรื่องหนึ่งที่ก่อให้เกิดความยุ่งยากในมุมของผู้ใช้งานครับ

หลังจากนั้นในเวลาต่อมามีการพัฒนาจาก Single Step Authentication (Primary Step Authentication) มาเป็น "Multi-Factor Authentication (MFA)" ครับ หรือบางท่านจะเรียกว่า "Two Steps Authentication" หรือ Secondary Step สำหรับการ Authentication ก็ได้ครับ โดยจะมีการเพิ่มขั้นตอนในการทำ Authentication เข้าไป เพื่อทำให้เกิดความปลอดภัยมากกว่าแบบเดิมครับ ซึ่งทาง Microsoft เองก็มีการนำเอาคอนเซปและเทคโนโลยีดังกล่าวมาใช้งานครับ และก็พัฒนามาเป็นคอนเซปและเทคโนโลยีที่เรียกว่า "Passwordless" ครับ  และรูปด้านล่างจะเป็นรูปที่แสดงการเปรียบเทียบของวิธีการหรือรูปแบบต่างๆ ในการทำ Authentication กับ Microsoft Entra ID ครับ

และจากรูปด้านบนที่แสดงถึงวิธีหรือรูปแบบต่างๆ สามารถสรูปได้ประมาณนี้ครับ

- Password (Primary Authentication) *คือ Single Step Authentication ที่อธิบายไว้ข้างต้นครับ

- Phone-Based Auth, SMS (Primary and Secondary Auth) และ Voice (Secondary Auth)

- OATH Auth (Secondary Auth) เช่น OTP, HW Tokens, และ SW Tokens

- Passwordless Auth (Primary และ Secondary Auth) เช่น Windows Hell for Business, FIDO2, อื่นๆ

เอาล่ะครับมาถึงตรงนี้ที่ออฟฟิศของท่านผู้อ่านใช้วิธีการหรือรูปแบบในการ Authentication ครับ สำหรับตัวผม ณ ปัจจุบันเลยก็ต้องเป็น MFA ครับ ซึ่งถือเป็นรูปแบบหรือวิธีการหนึ่งที่หลายองค์กรใช้กันอยู่ครับ รวมถึงเวลาที่เราเข้าไป Access Microsoft Cloud Services ต่างๆ เช่น Microsoft 365, Microsoft Azure, รวมถึง Cloud Services อื่นๆ ด้วยก็จะใช้รูปแบบดังกล่าวนี้เป็นอย่างน้อยในการทำการตรวจสอบ Identity ของผู้ใช้งานครับ และบางองค์กรก็เริ่มนำเอารูปแบบหรือวิธีการที่เรียกว่า "Passwordless" มาใช้งานกันมากขึ้นเรื่อยๆ ครับ ซึ่งรูปแบบด้งกล่าวนี้ Microsoft Entra ID ก็รองรับครับ และถือว่าเป็นรูปแบบหรือวิธีการที่ดีที่สุด ณ ตอนนี้ครับ โดยตัวของ Passwordless เอง รองรับหลายแบบ ครับ เช่น Microsoft Authenticator (Mobile App), Windows Hello for Business (เป็น Windows Hello ที่ใช้งานในองค์กร), FIDO2, เป็นต้นครับ 

ที่นี้ก็มาถึง "Passkeys" กันแล้วครับ โดยผมขอเริ่มจากพาทุกท่านไปทำความรู้จักกับ Passkeys กันก่อนครับ สำหรับ Passkeys นั้นคือ Modern, Highly Secure, และ User-Friendly ที่มีการพัฒนาต่อยอดมาจาก Passwordless ให้มีความปลอดภัยมากขึ้นและจะมาแทนการใช้ Passwords ครับ อีกทั้ง Passkeys  ถูกสร้างมาให้รองรับกับ Standards ต่างๆ เช่น Web Authentication (WebAuthn), FIDO, เป็นต้น ตัวของ Passkeys ใช้คอนเซปของ Public-Key Cryptography ซึ่งจะประกอบไปด้วย 2 Keys หลัก คือ:

1. Private Key ถูกเก็บใน Device อย่างปลอดภัยและ Private Key จะอยู่และใกล้กับ Device นั้นๆ เสมอ

2. Public Key ถูกส่งและเก็บไว้ใช้งานโดย Services ต่างๆ เช่น Microsoft Entra ID และจะมีการผูกเข้ากับ User Account

Passkeys เป็น Unique Cryptographic Key Pairs (Private และ Public Keys) ที่มาพร้อมกับ Phishing-Resistant Authentication Method ซึ่งนำเอามาทำงานร่วมกับ Microsoft Entra Product Family (รวมถึง Microsoft Entra ID) โดยเราสามารถนำเอา Passkeys ไปให้กับผู้ใช้งานใช้งานเพื่อการทำ Authentication ซึ่งง่ายต่อการใช้งานและยัง Compliant กับ MFA Strategy อีกด้วย

และที่สำคัญ Passkeys จะเป็นวิธีการหรือรูปแบบของการทำ Passwordless Authentication ในอนาคต (อันใกล้) ครับ เนื่องด้วยมัมมีความปลอดภัยมากขึ้นเมื่อไปเปรียบเทียบกับการใช้ Passwords เพราะตัวของ Passkey มาพร้อมกับ Phishing-Resistant Solution อย่างที่เกริ่นไว้ก่อนหน้านี้ครับ อีกท้้งมันไม่สามารถนำเอาไป Reused ใช้งานได้ รวมถึงป้องกันการโดยขโมย และนี่คือข้อดีของ Passkeys ครับ:

- Phishing Resistance

- Brute Force Attack Prevention

- Enhanced Security (Private Key) 

- Contextual Authentication ตัวของ Passkeys เป็น Single Auth แต่สามารถใช้งานร่วมกับ Biometrics หรือ PIN เพื่อรองรับ MFA

- Standardized Support ใช้และรองรับ Open Protocols เช่น WebAuthn, FIDO, เป็นต้น

- Faster Sign-In

- อื่นๆ 

Passkeys กับ Microsoft Entra ID นั้น, จะเป็นการใช้งาน Passwordless Authentication ผ่านทาง Biometric, PIN-Based Verification ใน Registered Devices โดยจะมีการเก็บ Cryptographic Key (Private Key) อย่างปลอดภัยไว้ที่ Hardware ของ Device (เช่น TPM Chip) เพื่อให้มั่นใจในเรื่องของ Authorization โดยจะมีการส่งและเก็บ Public Key เอาไว้ใน Microsoft Entra ID ในขณะที่ Private Key ยังคงถูกเก็บไว้ใน Device อย่างปลอดภัย

และสำหรับ Microsoft Entra รองรับการใช้ Passkeys 2 แบบ คือ Device-Bound Passkeys กับ Synced Passkeys 

- Device-Bound Passkeys, ถูกเก็บอยู่ใน Device นั้นอย่างปลอดภัย

- Synced Passkeys, ถูกเก็บอยู่ใน Cloud Platform Credential Managers หรือ Password Managers (เช่น iCloud Keychain, Google Password Manager, เป็นต้น)

*ณ ตอนที่ผมเขียนบทความนี้ Microsoft Entra support Device-Bound Passkeys GA เรียบร้อยแล้วในขณที่ Synced Passkeys เป็น Public Preview ครับ

นอกจากนี้แล้ว Microsoft ได้ประกาศและแจ้งให้ทราบโดยทั่วกันแล้วว่าในวันที่ 1 September 2026, Microsoft จะกำหนดให้ Passkeys เป็น Default Authentication ใน Microsoft Entra ID ครับ รายละเอียดเพิ่มเติมสามารถไปดูเพิ่มเติมได้จาก Link นี้ครับ, Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID | Microsoft Security Blog

ตามด้วยการ Enable Passkeys ใน Microsoft Entra ID ครับ, How to enable passkeys (FIDO2) in Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn

และทั้งหมดนี้คือเรื่องราวเริ่มต้นของ Passkeys กับ Microsoft Entra ที่ผมอยากจะนำเสนอครับผม.....

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

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

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

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

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

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

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

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

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

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

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

- Microsoft Entra ID (IAM)

- Microsoft Entra Verified ID

- Microsoft Entra ID Governance

- Microsoft Entra Permission Management

- อื่นๆ

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

Microsoft Entra ID 

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

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

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

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

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

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

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

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

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

Monitoring vs Observability ตอนที่ 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Monitoring vs Observability ตอนที่ 2

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

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

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

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

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

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

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

- Log Management

- Application Performance Monitoring (APM)

- Network Monitoring

- Service Monitoring

- อื่นๆ 

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

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

Monitoring vs Observability ตอนที่ 1

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

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

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

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

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

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

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