Access Control (RBAC) ใน Microsoft Azure

      สวัสดีครับทุกท่าน กลับมาพบกันเหมือนเดิมครับ สำหรับบทความตอนนี้ของผมจะเป็นเรื่องราวของ Security ใน Microsoft Azure ครับ ซึ่งต้องบอกว่ามีรายละเอียดเยอะมากเลยครับ แต่สำหรับบทความนี้ผมจะหยิบเอาเรื่องหนึ่งมานำเสนอเล่าสู่กันฟังครับ และต้องบอกว่าเรื่องดังกล่าวนี้ถือเป็นพื้นฐานสำคัญสำหรับท่านผู้อ่านที่ทำหน้าที่เป็นผู้ดูแลระบบ (Cloud Admintrator), Cloud  Architect, Consultant ตลอดจนท่านที่สนใจเรื่องราวของความปลอดภัยใน Microsoft Azure ครับ เรื่องดังกล่าวนี้ คือ "Access Control" ใน Microsoft Azure ครับ

Access Control คืออะไร?

ผมเชื่อว่าท่านผู้อ่านโดยส่วนใหญ่น่าจะเคยได้ยินตลอดจนรู้จักกับ Access Control กันมาอยู่แล้วครับ เช่น ใน Active Directory Domain Service (AD DS) เรื่องของ Access Control คือ การกำหนดสิทธิ์ (Privileges หรือ Permissions) ในการเข้าถึงตลอดจนการใช้งาน Resources ต่างๆ ใน Forest/Domain ของ Actvie Directory Domain Service (AD DS) ครับ โดยใน AD DS จะมีรูปแบบการกำหนดสิทธิ์หรือ Access Control ได้ 2 แบบ คือ

- Shared Permissions

- NTFS Permisssions

โดยมีผู้ดูแลระบบหรือท่านที่เกี่ยวข้องเป็นผู้พิจารณาและกำหนดสิทธิ์ต่างๆ ให้กับผู้ใช้งานในองค์กรครับ สำหรับเรื่องราวของ Access Control นั้นจะเกี่ยวกับกระบวนการหนึ่งที่เรียกว่า "Authorization" ซึ่งจะเป็นกระบวนที่เกิดหลังจากกระบวนการแรกที่เรียกว่า "Authentication" ครับ และท่านผู้อ่านท่านใดที่ศึกษาเกี่ยวกับเรื่องราวของ Security น่าจะคุ้นเคยกับคอนเซปที่เรียกว่า "AAA" ผมเรียกว่า Triple A หรือ A สามตัวครับ โดย A แต่ละตัวย่อมาจาก

A ตัวที่ 1 = Authentication, เป็นกระบวนเกี่ยวกับการพิสูจน์ตัวตน (Identity) ตัวอย่างของ Services ที่ทำหน้าที่ดังกล่าว เช่น Active Directory Domain Service (AD DS),  Azure Active Directory (Azure AD), เป็นต้น

A ตัวที่ 2 = Authorization, เป็นกระบวนเกี่ยวกับกำหนดสิทธิ์ (Privileges หรือ Permissions) ในการเข้าถึง Resources ต่างๆ ตัวอย่าง เช่น ถ้าใน AD DS ก็จะเป็น Shared และ NTFS Permissions ที่ได้อธิบายไว้ข้างต้น, ถ้าเป็น Azure AD ก็จะเป็น Role-Based Access Control หรือ RBAC ซึ่งเป็น Feature หนึ่งใน  Azure AD ครับ

A ตัวที่ 3 = Accounting หรือ Auditing, เป็นการกระบวนการบันทึกเหตุการณ์ต่างๆ ที่เกิดขึ้น โดยเหตุการณ์ดังกล่าวนี้ ก็จะเป็นข้อมูลที่เก็บอยู่ใน Logs ต่างๆ เช่น Security Log, Activity Log, เป็นต้น

สำหรับบทความนี้ผมจะโฟกัสที่ A ตัวที่ 2 คือ Authorization หรือ Access Control ที่เกี่ยวข้องกับ Microsoft Azure เพราะฉะนั้นก็จะเกี่ยวข้องกับ Feature หนึ่งใน Azure AD คือ Role-Based Access Control (RBAC) ครับ 

ส่วนประกอบของ Role-Based Access Control (RBAC)

อย่างที่ผมได้อธิบายคร่าวๆ ไว้ข้างต้นว่า RBAC เป็น Feature หนึ่งใน Azure Active Directory (Azure AD) ที่ใช้สำหรับการทำ Access Control นั่นก็คือ การกำหนดหรือ Assign สิทธิ์ (Privileges หรือ Permissions) หรือระดับการเข้าถึงเพื่อใช้ในการบริหารจัดการและใช้งาน Resources ต่างๆ ใน Microsoft Azure ครับ เพราะฉะนั้นท่านผู้อ่านท่านใดที่เป็นผู้ดูแลระบบท่านจะต้องรู้จักและเข้าใจคอนเซปตลอดจนเรื่องราวต่างๆ ของ  RBAC ครับ  โดยตัวของ RBAC ประกอบไปด้วยส่วนประกอบต่างๆ ดังนี้:

- Security Principals (SPs)

- Role Definitions

- Role Assignment

Security Principals (SPs)

คือ สิ่งที่อธิบายหรืออ้างอิงถึง Azure AD Objects ที่เราสามารถกำหนดหรือ Assign สิทธิ์ ได้ครับ ผมอยากให้ท่านผู้อ่านลองนึกดูครับว่า มันคือ  Azure AD Objects ? ครับ..... คำตอบ คือ  User Accounts, Group Accounts, เป็นต้นครับ  Security Principals (SPs) มีอะไรบ้าง สามารถดูจากรูปด้านล่างครับ

Security Principals (User Account)

เรามาเริ่มกันที่ User Accounts เป็น Object ที่ใช้แทนหรือสำหรับผู้ใช้งาน และผมเชื่อว่าทุกท่านน่าจะรู้จักและคุ้นเคยกับ User Accounts เป็นอย่างดี เพราะทุกคนต้องมีเพื่อใช้เป็น Identity สำหรับเข้าถึงหรือใช้งาน Resources ต่างๆ  โดย User Accounts ใน Azure AD จะมี 3 ชนิด คือ

1. Cloud User Accounts

2. Hybrid User Accounts

3. External User Accounts

Security Principals (Group Account)

เราใช้ SPs ชนิดนี้เพื่อช่วยทำให้การทำ  Access Control มีความสะดวกและยืดหยุ่นมากขึ้น และตาม Best Practices ของ Microsoft ควร(Privileges หรือ Permissions) ให้กับ Group Accounts นั่นหมายความว่าใน Azure AD เราควรกำหนดหรือ Assign Group Accounts เข้าไปยัง RBAC Roles ที่เกี่ยวข้องหรือที่ต้องการ

Security Principals (Service Principal)

คือ Identity ของ Applications ต่างๆ ที่เราได้มีการ Deploy ใช้งาน เพื่อทำให้เราสามารถกำหนดหรือ Assign สิทธิ์ (Privileges หรือ Permissions) ให้กับ Applications เพื่อให้ Applications ดังกล่าวเข้าถึง Azure Resources ต่างๆ ได้ครับ การที่ท่านผู้อ่านจะสร้าง Identity ให้กับ Application หรือ Application Identity ได้นั้น ท่านผู้อ่านจะต้องนำเอา Application ดังกล่าวมาทำการ Registered กับ Azure AD โดยใช้ App Registrations ดังรูปด้านล่างครับ

Security Principals (Managed Identity)

เป็น Feature หนึ่งใน Azure AD ที่ทำให้เราสามารถกำหนดสิทธิ์ (Privileges หรือ Permissions)ให้กับ Azure Services เพื่อให้เข้าถึง Azure Resources อื่นๆ ได้ครับ

Role Definitions

ส่วนประกอบต่อมาของ RBAC คือ Role Definitions ครับ โดย Role Definitions คือ ชุดของสิทธิ์ (Privileges หรือ Permissions) ต่างๆ ที่จะใช้กับ Azure Resources ต่างๆ เช่น Read, Write, Delete, เป็นต้น ดังรูปด้านล่างครับ

โดยเราสามารถใช้ Role Definitions ที่ทาง Microsoft Azure เตรียมเอาไว้แล้วผ่านทาง RBAC ที่เรียกว่า "Built-In RBAC Roles" ครับ โดย Built-In ดังกล่าว แบ่งได้เป็น 2 รูปแบบ ดังนี้:

รูปแบบที่ 1 เรียกว่า Azure Active Directory Built-In RBAC ซึ่งเป็น RBAC Roles ต่างๆ ที่เอาไว้ใช้สำหรับการบริหารจัดการ Azure AD Tenant ดังรูปด้านล่าง

รูปแบบที่ 2 เรียกว่า Azure Active Directory Resources Built-In RBAC ซึ่งเป็น RBAC Roles ต่างๆ ที่เอาไว้ใช้สำหรับการบริหารจัดการ Azure AD Resources ต่างๆ ดังรูปด้านล่างครับ

Role Assignment

ส่วนประกอบสุดท้ายของ RBAC คือ Role Assignment คือ ส่วนประกอบที่ใช้สำหรับการกำหนดหรือ Assign สิทธิ์ (Privileges หรือ Permissions) นั่นก็คือการ Assign Security Principals (SPs) เข้าไปยัง RBAC Roles ที่ต้องการ จากนั้นทำการกำหนดขอบเขต (Scope) ตลอดจนระดับ (Levels) ของสิทธิ์ดังกล่าวที่กำหนดผ่านทาง RBAC ว่ามีขอบเขต (Scopes) เป็นอย่างไร โดยขอบเขตที่ว่านี้จะอ้างอิงจาก "Azure Hierarchy" ขององค์กรนั้นๆ ว่าเป็นลักษณะเป็นอย่างไร โดยปรกติจะมี ขอบเขตและระดับต่างๆ ดังรูปด้านล่าง

Scopes และ Levels จากรูปด้านบนที่เราสามารถกำหนดได้ คือ Management Group, Subscription, Resouce Group, และ Resouce ครับ สำหรับ Best Practices ของการทำ Access Control นั้น Microsoft แนะนำให้กำหนดหรือ Assign สิทธิ์ที่ระดับ (Scope และ Level) ของ Azure Hierarchy ที่สูงที่สุดเท่าที่จะเป็นได้หรือตามความต้องการเพราะเมื่อกำหนดสิทธิ์เรียบร้อยแล้ว สิทธิ์ดังกล่าวที่ถูกกำหนดไว้ก็จะถ่ายทอดลงมายังระดับหรือ Level ที่อยู่ด้านล่างของ Azure Hierarchy ตามรูปด้านบนครับ ซึ่งเราเรียกคอนเซปนี้ว่า "Inheritance" ครับ

และภาพรวมของส่วนประกอบต่างๆ ของ RBAC ที่ผมอธิบายไป จะมีหน้าตาตามรูปด้านล่างครับ

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

Audit Logs ใน Azure Active Directory (Azure AD)

      สวัสดีครับทุกท่าน สำหรับบทความนี้ผมจะพาทุกท่านไปรู้จักกับ Audit Logs ใน Azure Active Directory (Azure AD) ครับ สืบเนื่องจากช่วงที่ผ่านมามีลูกค้าสอบถามผมมาว่า ใน Azure AD ของ Microsoft Azure มีการบันทึกเหตุการณ์ต่างๆ ที่เกิดขึ้นใน Azure AD Tenant มั๊ย ถ้ามี จะเข้าไป Track หรือ ดูรายละเอียดเรื่องราวดังกล่าวนี้ได้อย่างไร?  จากคำถามข้างต้น ตอบได้เลยครับว่า ใน Azure AD มีการบันทึกและเก็บเหตุการณ์ต่างๆ เอาไว้ครับ เพื่อให้ผู้ดูระบบหรือท่านที่มีหน้าที่เกี่ยวข้องเข้าไปดูรายละเอียดต่างๆ ได้ครับ โดยสามารถเข้าดูผ่านทาง Azure Portal ครับ ดังรูปด้านล่างครับ

ไหนๆ คุยกันเรื่องของ Audit Logs แล้ว ขออนุญาตอธิบายเพิ่มเติมเกี่ยวกับเรื่องดังกล่าวอีกซักหน่อยครับ เผื่อว่าท่านใดยังไม่ทราบ  โดยอ้างอิงจากรูปด้านบน ถ้าท่านผู้อ่านไปเปิด Azure Portal แล้วไปที่ Azure Active Directory ในนั้นจะมี Logs ต่างๆ ที่สามารถเข้าไปดูได้ 3 แบบ ดังรูป

1. Sign-in logs เป็น Logs ที่เก็บข้อมูล (เหตุการณ์) เกี่ยวกับการ Sign-In ของผู้ใช้งานต่างๆ ในองค์กร รวมถึงการเข้าถึง Resources ต่างๆ ของผู้ใช้งาน

2. Audit logs เป็น Logs ที่เก็บข้อมูล (เหตุการณ์) เกี่ยวกับการเปลี่ยนแปลงของการบริหารจัดการที่เกิดขึ้น

ใน Tenant นั้น ตลอดจนการเปลี่ยนแปลงเรื่องการเข้าถึง Resources ต่างๆ 

3. Provisioning logs เป็น Logs ที่เก็บข้อมูล (เหตุการณ์) เกี่ยวกับที่เกิดจาก Provisioning Service เช่น การสร้าง Groupใน Service Now เป็นต้น

ในบทความนี้เรามาโฟกัสที่ Audit Logs ใน Azure AD กันครับ โดยผู้ดูแลระบบหรือท่านที่มีหน้าที่เกี่ยวข้องสามารถเข้าถึงเหตุการณ์ต่างๆ ที่ถูกบันทึกไว้ใน Audit Logs  ได้ครับ โดยปรกติทั่วไปข้อมูลที่มักเข้าไปดูกันบ่อยๆ ก็จะเป็นเรื่องราวต่างๆ เช่น การจัดการ User และ Group Accounts, การจัดการ Applications โดยมีรายละเอียดดังนี้:

เหตุการณ์ที่เกี่ยวกับ User Accounts หรือผู้ใช้งาน ก็สามารถดูได้ครับ ยกตัวอย่างเช่น มีการอัพเดทหรือเปลี่ยนแปลงกับ User Accounts หรือผู้ใช้งาน, เรื่องของการเปลี่ยน Passwords, Administrator Account ได้เข้าไปทำอะไรบ้าง, เป็นต้น 

เหตุการณ์ที่เกี่ยวกับ Group Accounts ก็จะมีเหตุการณ์ต่างๆ  ถูกบันทึกไว้ เช่น การสร้าง Groups, การเปลี่ยนแปลง Group Membership, การเปลี่ยนแปลง Owner ของ Group, และอื่นๆ

เหตุการณ์ที่เกี่ยวกับ Applications เช่น การ Add หรือ Update Applications, การ Remove, การเปลี่ยนชื่อ Applications, และอื่นๆ

ท่านที่จะสามารถเข้าถึง Audit Logs ได้จะต้องถูก Assign ไปยัง RBAC Roles ต่างๆ ดังนี้:

- Security Administrator

- Security Reader

- Report Reader

- Global Reader

- Global Administrator

นอกจากนี้ ท่านผู้อ่านสามารถใช้ Default List View ตามรูปด้านบนได้เลย หรือจะทำการ Customize List View ได้ตามต้องการครับ

มีอีกสิ่งหนึ่งที่จะต้องพิจารณาเกี่ยวกับเรื่องของ Audit Logs คือเรื่องของการเก็บรักษาหรือ Retention ครับ เพราะระยะเวลาในการเก็บรักษาข้อมูลใน Audit Logs ขึ้นอยู่กับ Edition ของ Azure Active Directory ด้วยนะครับ หรือถ้าต้องการเก็บระยะยาวหรือเก็บนานๆ ก็จะต้องพิจารณาการเรื่องของที่ที่จะใช้ในการเก็บรักษา, ค่าใช้จ่าย, ฟีเจอร์ต่างๆ, และอื่นๆ  ขออนุญาตทางเลือกที่ท่านผู้สามารถนำไปพิจารณาเป็นที่ที่สำหรับเก็บรักษาข้อมูลของ Audit Logs ได้นานๆ คือใช้ Services ใน Microsoft Azure ที่ชื่อว่า Azure Log Analytics ครับ ทั้งนี้จะต้องมีการวางแผนและพิจารณาก่อนที่จะเลือกใข้งานนะครับ

รู้จักกับ Azure Arc (Introduction to Azure Arc)

      

     สวัสดีครับทุกท่านกลับมาพบกันอีกเช่นเคยครับ สำหรับบทความตอนนี้ของผมจะเป็นเรื่องเกี่ยวกับการบริหารจัดการ Hybrid และ Multi-Cloud Environments โดยใช้ Service ตัวหนึ่งใน Microsoft Azure ที่ชื่อว่า "Azure Arc" ครับ โดยผมเชื่อว่าทุกท่านที่ติดตามทั้ง Blog และ FB ของผมมาโดยตลอดน่าจะคุ้นเคยและรู้จักเรื่องราวของ Hybrid และ Mulit-Cloud กันพอสมควร ซึ่งสืบเนื่องมาจากช่วงที่ผ่านมานั้นมีแนวโน้มมากขึ้นเรื่อยๆ ครับ ว่าหลายๆ องค์กรที่กำลังวางแผนที่จะนำเอา Cloud Computing เทคโนโลยีเข้ามา Adopt ใช้ในองค์กรนั้นจะมีลักษณะเป็น Hybrid Cloud และมีความเป็นไปได้อีกว่าองค์กรนั้นๆ อาจจะมีการนำเอา Cloud Providers มากกว่าหนึ่งยี่ห้อเข้ามาใช้งานในองค์กร หรือที่เราเรียกกันว่า "Multi-Cloud" ครับ

หลายๆ ท่านอาจจะมีคำถามหรือข้อสงสัยว่าทำไมแนวโน้นดังกล่าวที่หลายๆ องค์กรจะนำเอา Cloud เข้ามา Adopt หรือนำมาประยุกต์ใช้งานนั้นไม่ว่าจะเป็น Hybrid หรือ Multi-Cloud Environments นั้นเพราะอะไร? มาดูจากประเด็นและคำถามด้านล่างนี้กันครับ

- Workloads หรือระบบต่างๆ ไม่สามารถย้ายไปที่ Public Cloud เนื่องจากติดเรื่องของ Regulatory หรือ Compliance ตลอดจนเรื่องของ Data Sovereignty เช่น  Financial, Healthcare, หรือ Government และอื่นๆ เป็นต้น

- หลายองค์กรมีการลงทุนใน On-Premise Datacenter ไปแล้ว จึงอยากใช้งานให้เต็มประสิทธิภาพและก่อให้เกิดประโยชน์ให้มากที่สุด ดังนั้นจะต้องมีการ Adpot และทำการ Modernize Applications 

- ม้่นใจว่ามีการหยืดหยุ่นที่มากขึ้น

- ทำการ Manage, Monitor, Govern, และ Protect Workloads หรือ IT Assets โดยไม่ต้องสนใจว่ามันทำงาน อยู่ที่ไหน (เช่น On-Premise, Microsoft Azure, AWS, Google, และอื่นๆ)

- มีความเป็นไปได้หรือไม่ที่จะนำเอา Cloud Innovation เข้ามาใช้ทำงานร่วมกับ Infrastructure หรือ Environment ที่ใช้งานอยู่แล้วในปัจจุบัน

- ทำการ Modernize On-Premise Datacenters โดยการ Adopt หรือการนำเอา Cloud Soltuions เข้ามาใช้งาน

- อื่นๆ 

จากประเด็นตลอดจนคำถามต่างๆ ทั้งหมดในข้างต้น องค์กรจะวางแผนและดำเนินการอย่างไรดีครับ คำตอบคือ "ใช้ Azure Arc ครับ"

Azure Arc คืออะไร?

อย่างที่ผมได้เกริ่นไว้ตอนต้นของบทความว่า Azure Arc คือ Service หนึ่งใน Microsoft Azure ที่จะมาช่วยในเรื่องของการบริหารจัดการและ Governance ให้กับ Workloads หรือ IT Assets ต่างๆ ที่อยู่ทั้งใน Hybrid และ Multi-Cloud Environments (On-Premise, Microsoft Azure, AWS, Google, และอื่นๆ) ครับ 

โดย Azure Arc ได้มีการขยาย Azure Management Plane ให้สามารถบริหารจัดการและ Governance กับ IT Assets เหล่านั้นได้ครับ พูดถึง Azure Management Plane ไว้เมื่อซักครู่ ก็ต้องขออนุญาตอธิบายเพิ่มเติมนิดนึงครับเผื่อท่านใดที่ยังงงๆ แต่สำหรับท่านผู้อ่านท่านใดที่ใช้งาน Microsoft Azure อยู่แล้ว จะต้องรู้จักและเข้าใจคอนเซปของ Azure Management Plane ที่ว่านี้ โดยจะเกี่ยวข้องกับสิ่งที่เรียก  “Azure Resource Manager ” หรือเรียกสั้นๆ ว่า ARM ครับ ซึ่งเป็นคอนเซปและรูปแบบที่ใช้ในการ Deploy Resources ต่างๆ (Azure Deployment Model) ใน  Microsoft Azure เช่น Azure Virtual Machine, Azure Virtual Network, Azure SQL, และอื่นๆ โดย Resources เหล่านี้จะถูกรวบรวมอยู่ภายในสิ่งที่เรียกว่า Resource Groups ดังรูป

และเราสามารถจัดการ Resource Groups และ Resources เหล่านี้ผ่านทางเครื่องมือต่างๆ เช่น Azure Portal, Azure PowerShell, Azure CLI, รวมถึง Services ต่างๆ ใน Microsoft Azure ครับ 

มาถึงตรงนี้ ผมขอสรุปให้ทุกท่านเข้าใจง่ายๆ แบบนี้ครับ Azure Arc เป็น Service ที่จะเข้ามาช่วยองค์กรในการบริหารจัดการและ Governance Resources ต่างๆ เพื่อให้เป็นไปตามความต้องการและนโยบายขององค์กร โดยองค์กรสามารถขยายขอบเขตในการบริหารจัดการและ Governance โดยใช้ Azure Management Plane (ที่อธิบายไว้ก่อนหน้านี้) กับ IT Assets ที่อยู่ใน On-Premise Datacenters, Clouds ต่างๆ เช่น Microsoft Azure, AWS, Google และอื่นๆ ได้ เสมือนกับว่า IT Assets เหล่านั้นคือ Resources ที่อยู่ใน Microsoft Azure ครับ โดย IT Assets ที่เกริ่นไว้ เช่น Virtual Machines (Windows และ Linux), Kubernetes Clusters และอื่นๆ ที่อยู่ใน On-Premise Datacenters, Microsoft Azure, AWS, Google, และอื่นๆ ครับ

เราสามารถใช้ Azure Arc บริหารจัดการและ Governance Resources (IT Assets) ดังต่อไปนี้:

- บริหารจัดการ Resources ผ่านทาง Azure Portal

- กำหนดสิทธิ์ในการเข้าถึง (Access Control) โดยใช้ RBAC

- กำหนดนโยบาย (Policy) ให้กับ Resources โดยใช้ Azure Policy

- ตรวจสอบและป้องกัน Resources โดยใช้ Azure Monitor และ Microsoft Defender for Cloud

- ทำ Auditing

- Query โดยใช้ Azure Resource Graph

- Security Management

- อื่นๆ

ต่อไปเรามาดูความสามารถของ Azure Arc (ณ ตอนที่ผมเขียนบทความนี้นะครับ) มีดังนี้ครับ

1. Azure Arc-Enbled Infrastructure  ประกอบไปด้วย

- Azure Arc-enabled Servers

- Azure Arc-enabled Kubernetes

- Azure Arc-enabled SQL Server

2. AzureArc-Enabled Services ประกอบไปด้วย

- Azure Arc-enabled Data Services

- Azure Arc-enabled Machine Learning (Preview)

อธิบายเพิ่มเติมจากข้างต้น: 

Extend Azure Management Across Your Environments, Azure Resource Manager และ Azure Management เป็นสิ่งที่ Microsoft Azure ใช้ในการจัดการและควบคุม Resources ต่างๆ  เช่น Azure Virtual Machines และอื่นๆ เป็นต้น  โดย Azure Arc จะทำการขยายการใช้งาน Azure Resource Manager และ Azure Management เพื่อทำการบริหารจัดการและควบคุมไปยัง Windows และ Linux Servers, Kubernetes Clusters และ Resources อื่นๆ ที่ทำงานอยู่ใน On-Premise, Clouds ต่างๆ เช่น Microsoft Azure, AWS, Google, และอื่นๆ

Run Azure Data Services Anywhere, ด้วยความสามารถนี้ของ Azure Arc จะทำให้องค์กรสามารถรันและใช้งาน Azure Data Services (Azure SQL Database และ Azure Database for PostgreSQL) ใน Kubernetes ซึ่งอยู่ที่ใดก็ได้ เช่น On-Premise เป็นต้น

Adopt Cloud Practice On-Premises, เราสามารถใช้ Azure Arc เข้ามาช่วยในการ Deploy Containerized Applications ไปยัง Microsoft Azure และ Non-Azure Infrastrcture ได้อย่างปลอดภัย เช่น ด้วยการใช้ Azure Arc กับ Azure DevOps สามารถทำการ Deploy Applications ไปยัง Kubernetes Clusters ที่อยู่ที่ไหนก็ได้ เป็นต้น  

Implement Azure Security Anywhere, ใน Microsoft Azure จะ Service ที่เข้ามาจัดการในเรื่องของความปลอดภัย (Security Management) เช่น Role-Based Access Control (RBAC), Azure Policy, Microsoft Defender for Cloud, และอื่นๆ เพราะฉะนั้นด้วย Azure Arc, องค์กรสามารถใช้ Services เหล่านี้กับ Resources ต่างๆ ที่อยู่ในที่ต่างๆ นอกเหนือจาก Microsoft Azure

ขออนุญาตอ้างอิงจากประเด็นและคำถามตอนต้นของบทความนะครับ สำหรับ Mulit-Cloud Environment ถือเป็นรูปแบบและเป็นสิ่งสำคัญสำหรับองค์กรที่กำลังวางแผนและดำเนินการอยู่ครับ ไม่ว่าองค์กรนั้นจะเล็ก, กลาง, หรือใหญ่ ครอบคลุมทุกขนาดครับ โดยเฉพาะ Workloads ที่เป็น Applications นั้นหลายองค์กรที่ได้มีการ Adopt หรือนำเอา Cloud เข้ามาประยุกต์ใช้งานนั้น สิ่งที่หนีไม่พ้นจะต้องมีการวางแผนเตรียมความพร้อมเพื่อดำเนินการนั่นก็คือ เรื่องของการ Migration, เรื่องของการทำ Application Modernization (คือการนำเอาเทคโนโลยีใหม่เข้ามาพัฒนาและใช้งาน เช่น การนำเอา Containerization เทคโนโลยีเข้ามาใช้งาน ตลอดจนการ Deploy Cloud-Native, และอื่นๆ เป็นต้น) จากจุดนี้เอง ทาง Microsoft Azure จึงได้เตรียม Azure Arc ที่มาพร้อมกับความสามารถและฟีเจอร์ต่างๆ ที่ได้อธิบายไว้ก่อนหน้านี้ มาช่วยองค์กรครับ

สำหรับท่านใดที่สนใจเรื่องราวของ Azure Arc ซึ่งยังมีอีกเยอะเลยครับ ท่านใดที่สนใจสามารถไปที่ Link นี้ได้เลยครับ,  Azure Arc overview - Azure Arc | Microsoft Docs

สำหรับบทความนี้เป็นเพียงแค่เริ่มต้นเท่านั้นครับ เอาไว้โอกาสต่อไปผมจะนำเรื่องราวของ Azure Arc มานำเสนอและเล่าสู่กันฟังอีกครับ โปรดติดตามครับผม.....

ป้องกันข้อมูลจาก Ransomware ด้วย Azure Backup

      สวัสดีครับทุกท่าน สำหรับบทความนี้ของผมจะเป็นเรื่องราวที่สำคัญและหลายๆ ท่านให้ความสนใจครับ เรื่องดังกล่าวนี้คือ เรื่องของภัยคุกคามรูปแบบหนึ่งที่เรียกว่า "Ransomware" ครับ  พอเอ่ยชื่อนี้ขึ้นมาผมเชื่อว่าท่านผู้อ่านทุกท่านต้องรู้จักและเคยได้ทราบเรื่องราวเกี่ยวกับเจ้า Ransomware กันมาพอสมควร จากข่าวสารต่างๆ ที่มีให้เราเห็นได้ทราบกันเป็นระยะๆ ว่ามีองค์กรที่โดนเจ้า Ransomware นี้เล่นงานครับ สิ่งที่ผมอยากจะนำเสนอแนวทางการป้องกันเพื่อให้เราลดความสุ่มเสี่ยงไม่ต้องเป็นเจอครับ และเพื่อไม่ให้เป็นการเสียวเวลาเราเข้าสู่เรื่องราวนี้กันเลยครับ

Ransomware คืออะไร?

เป็นรูปแบบหนึ่งของการจู่โจมหรือโจมตีด้วยการบีบบังคับ (Extortion Attack) โดยจะการเข้ารหัส (Encrypt) Files และ Folders ต่างๆ เพื่อไม่ให้ผู้ใช้งานสามารถเข้าถึงหรือใช้งานข้อมูลดังกล่าวนี้ได้ครับ ซึ่งถ้าองค์กรใดโดนเจ้า Ramsomware นี้เข้าไป ก็จะตกเป็นเหยื่อของ Attackers ครับ นั่นหมายความว่าองค์กรดังกล่าวนั้นจะต้องจ่ายเงินให้ไป เพื่อแลกกับข้อมูลที่โดนเจ้า Ransomware เล่นงานกลับมาครับ คำถามที่ผมมักเจออยู่บ่อยๆ คือ  Ransomware มาจากไหน? ต้องบอกว่ามาได้หลายทางครับ เช่น ทางเมล์, ทาง Internet (การเข้าถึง Web Site ที่มีความสุ่มเสี่ยงต่อความไม่ปลอดภัย), จากช่องโหว่ในระบบ, และอื่นๆ ครับ หลังจากที่โดน Ransomware เล่นงาน มันจะเริ่มทำงานอย่างช้าๆ นั่นก็คือ การเข้ารหัสข้อมูลของท่านไปเรื่อยๆ โดยข้อมูลที่ว่านี้จะอยู่ในเครื่องของท่านหรือใน Networks ก็ได้ครับ นั่นหมายความว่า  Ransomware จะไล่เข้ารหัสข้อมูลไปเรื่อยๆ ครับ!!!!!

ผลกระทบที่เกิดขึ้นจาก Ramsomware Attack

- ไม่สามารถเข้าถึงข้อมูล

- ส่งผลกระทบกับการดำเนินงานทางธุรกิจ

- ทำให้ภาพลักษณ์ขององค์กรเสียหาย (ทางด้านการเงิน, ความมั่นใจ, และอื่นๆ)

- อื่นๆ

จะป้องกันข้อมูลอย่างไร?

เริ่มจากการหาเครื่องมือหรือ Solutions ต่างๆ เข้ามาช่วยในการป้องกันข้อมูลขององค์กรครับ ซึ่งปัจจุบันมีหลากหลาย Solutions ให้เลือกครับ เพื่อป้องกันทุกขั้นตอนที่เป็นไปได้จากการถูกโจมตีจากภัยคุกคามต่างๆ รวมถึง Ransomware ครับ ทางเลือกหนึ่งที่หลายๆ องค์กรใช้คือ การย้ายหรือ Deploy Workloads, ระบบต่างๆ ไปทำงานบน Cloud เช่น Microsoft Azure ครับ เพราะทำให้ลดช่องโหว่หรือลดความเสี่ยงที่ภัยคุกคามจะโจมตีได้มากกว่าใน On-Premise ครับ ยกตัวอย่างเช่น ถ้าเราย้ายระบบต่างๆ มายัง Microsoft Azure ทาง Microsoft เตรียมเครื่องมือตลอดจน Solutions ต่างๆ ช่วยองค์กรในป้องกันภัยคุกคามต่างๆ ครับ เช่น Microsoft Defender for Cloud, Microsoft Sentinel, Azure Disk Encryption, Azure Backup, และอื่นๆ ครับ ทั้งนี้ขึ้นอยู่กับความต้องการของแต่ละองค์กรครับ

เพราะฉะนั้นองค์กรจะต้องมีการวางแผนเพื่อเตรียมหาพร้อมในการจัดหาเครื่องมือหรือ Solutions เข้ามาช่วยป้องกันครับ เพื่อลดความเสี่ยงหรือความน่าจะเป็นที่จะถูกโจมตีหรือตกเป็นเหยื่อของ Ransomware ครับ สิ่งหนึ่งที่ควรพิจารณา, วางแผน, ตลอดจนการดำเนินการ และเรื่องหนึ่งที่สำคัญและขาดไม่ได้เลย นั่นก็คือ เรื่องของการสำรองและกู้คืนข้อมูลหรือที่เราเรียกกันว่าการ Backup & Restore ข้อมูลนั่นล่ะครับ 

แต่การวางแผนสำหรับการดำเนินการ Backup & Restore ข้อมูลให้มีความปลอดภัยและมั่นใจว่าจะไม่ถูกโจมตีหรือไม่โดน Ransomware และใช้งานได้นั้น เราจะวางแผนและดำเนินการอย่างไร?  สำหรับบทความนี้ผมขอนำเสนอ Service หนึ่งใน Microsoft Azure ที่จะเข้ามาช่วยในเรื่องของการ Backup & Restore ข้อมูล ซึ่งถือว่าข้อมูล เป็นสิ่งที่มีความสำคัญมากสำหรับองค์กรครับ โดย Service ที่ว่านี้มีชื่อว่า "Azure Backup" ครับ

รู้จักกับ Azure Backup

อย่างที่ผมได้เกริ่นไว้เมื่อซักครู่ว่า Azure Backup เป็น Service หนึ่งใน Microsoft Azure ครับ และเป็น Service ที่มาช่วยในการสำรองหรือ Backup ข้อมูลที่อยู่ใน On-Premise และ Cloud ไปเก็บไว้ที่ Microsoft Azure (Azure Backup) ครับ โดยเมื่อองค์กรมีการติดตั้งและใช้งาน Backup Environment ทั้งหมดจะถูกป้องกันโดย Azure Backup ครับ

Azure Backup ป้องกันข้อมูลจาก Ransomware ได้อย่างไร?

อย่างที่ผมอธิบายไว้ในหัวข้อก่อนหน้านี้ว่า ถ้ามีการติดตั้งและใช้งาน Azure Backup, Backup Environment ทั้งหมดจะถูกปกป้องโดย Azure Backup ครับ สำหรับข้อมูลที่ถูก Backup ด้วย Azure Backup นั้น Azure ฺBackup ก็จะมีการป้องกันโดยครอบคลุมทั้งในเวลาที่การรับ-ส่ง (Data In Transit) และเวลาที่ข้อมูลที่ทำการ Backup ถูกเก็บใน Azure Backup (Data At Rest) ครับ  นอกจากนี้แล้ว Azure Backup สามารถป้องกันหรือ Backup ข้อมูลต่างๆ ได้หลายรูปแบบดังนี้:

1. Files, Folders, และ System State ที่อยู่ใน On-Premise

2. Virtual Machines (OS เป็น Windows และ Linux) ที่อยู่บน Cloud และใน On-Premise

3. Azure Managed Disks (เป็น Storage Type ชนิดหนึ่งใน Microsoft Azure)

4. Azure File Shares

5. SQL Server (ที่ติดตั้งและใช้งานใน Azure Virtual Machines)

6.  SAP HANA

7. อื่นๆ 

นอกจากนี้แล้ว Azure Backup ยัง Built-In ในส่วนของฟีเจอร์ต่างๆ เช่น การ Monitoring และ Alerting ช่วยตรวจสอบและแจ้งเตือนเหตุการณ์ต่างๆ (เช่น  Unauthorized, Suspicious, เป็นต้น),  มี Azure Backup Reports (มีให้เลือกดูในรูปแบบ HTML และ PDF), และอื่นๆ มาให้ด้วย เพื่อให้เราสามารถเข้าไปดูข้อมูลตลอดจนรายละเอียดต่างๆ เกี่ยวกับการทำงานของ Azure Backup ครับ

ข้อมูลต่างๆ ที่เราได้มีการ Backup ด้วย Azure Backup เช่น Virtual Machines (ที่อยู่ใน Microsoft Azure และ On-Premise), Azure SQL Databases, และอื่นๆ จะถูกเก็บไว้ในสิ่งที่เรียกว่า "Recovery Service Vault"

อีกเรื่องหนึ่งที่จะต้องพิจารณาเกี่ยวกับ Azure Backup นั่นก็คือ เรื่องของ Availability ครับ โดยใน Azure Backup จะมีฟีเจอร์ที่เข้าช่วยในเรื่องนี้โดย เราสามารถเลือกได้ครับว่าจะทำการ Replicate ข้อมูลซึ่งถูก Backup โดย Azure Backup ไปเก็บไว้ที่อื่นได้ด้วยครับ โดยมีให้เลือกหลาย Options เช่น

- Locally Redudant Storage (LRS)

- Zone-Redudant Storage (ZRS)

- Geo-Redudant Storage (GRS)

และอย่างที่ผมได้อธิบายไว้ในข้างต้นว่า Azure Backup มีการป้องกันข้อมูลที่เราทำการ Backup ทั้งในเวลาที่การรับ-ส่ง (Data In Transit) และเวลาที่ข้อมูลที่ทำการ Backup ถูกเก็บใน Azure Backup (Data At Rest) ครับ นอกจากนี้แล้วมีสิ่งต่างๆ ดังต่อไปนี้ที่ควรทำก่อนเพื่อเป็นการป้องกันไว้ก่อนครับ

- Authentication & Authorization คือ ควรจะมีการกำหนดสิทธิ์ให้กับผู้ใช้งานหรือผู้ที่เกี่ยวข้องในการ

  เข้าถึงหรือจัดการ Azure Backup โดยท่านผู้อ่านสามารถกำหนดสิทธิ์ให้กับผู้ใช้งานหรือผู้ที่เกี่ยวข้องที่

  มี User Accounts อยู่ใน Azure Active Directory รวมถึงถ้ามีการติดตั้ง Hybrid Identity และใช้ 

  RBAC เข้ามาช่วย ในการควบคุมสิทธิ์เรื่องดังกล่าวนี้

- Data Encryption คือ การพิจารณาวางแผนและดำเนินการเรื่องดังกล่าวนี้ ซึ่งใน Microsoft Azure มี

  Services และฟีเจอร์ต่างๆ ที่ทำการเรื่องดังกล่าวนี้ให้องค์กรสามารถพิจารณาและนำไปใช้งานครับ

- Security Management & Operations คือ การทำการตรวจสอบ, วิเคราะห์, ประเมิน, และป้องกันระบบหรือ

  Workloads ต่างๆ ที่อยู่ใน Environment ขององค์กรทั้ง On-Premise และ Cloud 

สำหรับท่านใดที่สนในและอยากศึกษาข้อมูลเกี่ยวกับ Azure Backup สามารถเข้าไปที่ Link นี้ได้เลยครับ What is Azure Backup? - Azure Backup | Microsoft Docs

 

และทั้งหมดนี้คือคอนเซปและเรื่องราวของการป้องกันข้อมูลจาก Ransomware โดยใช้ Azure Backup ครับผม.....

Trusted Launch-Secure Azure Virtual Machines

      สวัสดีครับทุกท่าน มาพบกันอีกเช่นเคยนะครับ สำหรับบทความของผมตอนนี้จะเป็นเรื่องราวของฟีเจอร์ใหม่ใน Microsoft Azure ที่ชื่อว่า "Trusted Launch" ครับ โดยฟีเจอร์ดังกล่าวนี้จะเข้ามาช่วยทำให้ Azure Virtual Machines (Windows และ Linux) มีความปลอดภัยมากขึ้นครับ เรื่องราวจะเป็นอย่างไร เชิญติดตามกันได้เลยครับผม

Trusted Launch คืออะไร?

เป็นฟีเจอร์ทางด้านความปลอดภัยที่นำมาใช้กับ Azure Virtual Machines (Generation 2 เท่านั้น) และยังสามารถทำงานร่วมกับ Microsoft Defender for Cloud (ชื่อเดิม คือ Azure Security Center)  สำหรับท่านผู้อ่านท่านใดที่ใช้งานและมีความคุ้นเคยกับ Hyper-V ซึ่งเป็น Virtualization Technology ของทาง Microsoft น่าจะทราบว่า VM Generation 2 (Gen 2) คืออะไรนะครับ  แต่สำหรับท่านใดที่ไม่คุ้นเคย ผมขออนุญาตอธิบายสั้นๆ นะครับว่า ตอนที่เราสร้าง VM ใน Hyper-V เราสามารถเลือกได้ว่า VM ที่กำลังสร้างจะเป็น Generation 1 หรือ Generation 2 ครับ โดยความแตกต่างระหว่างสอง Generations นั่นคือ ฟีเจอร์ต่างๆ และอื่นๆ ซึ่งมีรายละเอียดคร่าวๆ ดังนี้:

ความแตกต่างระหว่าง Hyper-V VM Gen 1 และ Gen 2

OS ที่รองรับ

 

Boot Methods ของ Hyper-V VM Gen 1 และ Gen 2

Device Support ของ Hyper-V VM Gen 1 และ Gen 2

รายละเอียดเพิ่มเติมสามารถดูได้จาก Link นี้ครับ, Should I create a generation 1 or 2 virtual machine in Hyper-V? | Microsoft Docs

สำหรับใน Microsoft Azure,  ถ้าท่านผู้อ่านมีการสร้างและ Deploy Azure VMs ก็จะมีให้เลือก Generation 1 และ 2 เช่นเดียวกันครับ แต่มีรายละเอียดที่แตกต่างกันพอสมควรระหว่าง Hyper-V VM กับ Azure VM โดยมีรายละเอียดคร่าวๆ ดังนี้ครับ

ฟีเจอร์ของ Azure VM Gen 1 และ Gen 2

รายละเอียดเพิ่มเติมสามารถดูได้จาก Link นี้ครับ, Azure support for generation 2 VMs - Azure Virtual Machines | Microsoft Docs

เอาล่ะครับ เรากลับมาที่เรื่องราวของ Trusted Launch กันต่อครับ และอย่างที่ผมได้เกริ่นไว้ข้างต้นว่า Trusted Lanuch เป็นฟีเจอร์ที่เกี่ยวกับความปลอดภัยที่นำมาใช้งานกับ Azure VMs (Gen 2)  โดยจะมาทำการป้องกัน (Protect) จาก Advanced และ Persistent Attacks Techniques ครับ ในส่วนของประโยชน์ (Benefits) ที่เราได้จากการนำเอา Launch Trusted มาใช้งานกับ Azure VMs (Gen 2) มีดังนี้ครับ

- ทำให้การ Deploy Azure VMs มีความปลอดภัยมากขึ้นด้วยการตรวจสอบ Verified Boot Loader,                OS Kernels, และ Drivers

- ป้องกัน Keys, Certificates, และ Secrets ใน Azure VMs

- มั่นใจว่า Workloads มีความน่าเชื่อถือและตรวจสอบได้

- อื่นๆ

Trusted Launch มี Options ให้เลือกในการ Configuration ดังนี้ครับ

1. Secure Boot, ทำให้มั่นใจว่าเฉพาะ Signed OSs และ Drivers เท่านั้นที่สามารถ Boot ได้

2. vTPM, มันคือ Virtual TPM ซึ่ง Compliant กับ TPM 2.0 โดย vTPM จะทำการรับรอง (Attestation)           โดยการประเมิน (Measuring) ทั้ง Boot Chain ของ Azure VMs (UEFI, OS, System, และ Drivers)  

        

วิธีการ Configure Trusted Launch

1. ไปที่ Azure Portal จากนั้นให้ท่านผู้อ่านทำการเลือก OS ที่ต้องการติดตั้งและ Deploy Azure VM ดังกล่าว จากนั้นให้ทำการ Click Drop-Down List เพื่อทำการเลือก Generation ดังรูปด้านล่างครับ

 

จากนั้นในส่วนของ Security Type สามารถเลือก Options สำหรับ Trusted Launch ได้ว่าจะเป็น Secure Boot หรือ vTPM ดังรูปด้านล่างครับ

จากนั้นก็เข้าสู่ขั้นตอนการสร้างและ Deploy Azure VMs ปรกติอย่างที่เราคุ้นเคยกันครับ สำหรับรายละเอียดของการ Deploy Azure VMs กับ Trusted Launch ท่านผู้อ่านสามารถเข้าไปดูรายละเอียดได้จาก Link นี้ครับ, Deploy a trusted launch VM - Azure Virtual Machines | Microsoft Docs

สำหรับรายละเอียดของ Trusted Launch เพิ่มเติม สามารถดูได้จาก Link นี้ครับ, Trusted launch for Azure VMs - Azure Virtual Machines | Microsoft Docs  และทั้งหมดนี้คือเรื่องราวของฟีเจอร์ Trusted Launch ซึ่งเป็นฟีเจอร์ที่ช่วยป้องกันและทำให้ Azure VMs ที่ท่านผู้อ่านได้มีการติดตั้งและ Deploy ใช้งานนั้นมีความปลอดภัยมากขึ้นครับผม.....

Microsoft Defender for Cloud

      สวัสดีครับท่านผู้อ่านทุกท่าน สำหรับบทความตอนนี้ของผมจะมาอัพเดทความเปลี่ยนแปลงกับ Service ตัวหนึ่ง ที่อยู่ใน Microsoft Azure ครับ และผมเชื่อว่าหลายๆ ท่านน่าจะรู้จัก Service นี้กันอยู่แล้ว Service ที่ว่านี้ก็คือ "Azure Security Center" แต่ ณ วันนี้ Service ดังกล่าวนี้เค้าเปลี่ยนชื่อแล้วนะครับ ชื่อใหม่ของเค้าคือ "Microsoft Defender for Cloud" ครับ  

ดังนั้นท่านผู้อ่านท่านใดที่ใช้งาน Microsoft Azure กันอยู่แล้ว และใช้ Azure Security Center อาจจะงงในช่วงที่ผ่านมาว่า Azure Security Center หายไปไหน!!!!! นอกจากนี้จะมีอีกส่วนประกอบหนึ่งหรือจะเรียกว่าฟีเจอร์ก็ได้ครับที่ชื่อว่า "Azure Defender" ซึ่ง ณ วันนี้ก็ไม่มีชื่อนี้แล้วเช่นกันครับ โดย ณ วันนี้ชื่อใหม่คือ Workload Protections ครับ สำหรับท่านผู้อ่านท่านใดยังไม่รู้จักทั้ง Azure Security Center รวมถึง Azure Defender ตลอดจนท่านใดที่เคยใช้งานหรือพอจะคุ้นเคยอยู่แล้ว บทความนี้จะพาท่านไปทำความรู้จัก Microsoft Defender for Cloud ครับ

Microsoft Defender for Cloud คืออะไร?

อย่างที่ผมเกริ่นไว้ในข้างต้นว่า Azure Security Center และ Azure Defender ณ วันนี้จะถูกนำมารวมกันภายใต้ชื่อใหม่ นั่นก็คือ "Microsoft Defender for Cloud" ครับ และยังมีอีกหลายๆ อย่างที่เปลี่ยนไปจากเดิมครับ ซึ่งก่อนที่ผมจะพาท่านผู้อ่านเข้าไปดูนั้น เรามาทำความรู้จักกับ Microsoft Defender for Cloud กันก่อนนะครับ โดยหน้าที่ของ Service นี้จะเข้ามาช่วยองค์กรในเรื่องของความปลอดภัยครับ โดย Microsoft Defender for Cloud จะทำหน้าที่ในการทำ Security Posture Management และ Threat Protection ครับ 

แต่ถ้าจะอ้างอิงตาม Cloud Security Reference Framework ตัวของ Microsoft Defender for Cloud จะมี 2 หน้าที่ครับ

1. Cloud Security Posture Management (CSPM), โดย Microsoft Defender for Cloud จะเข้ามาทำการรวบรวมข้อมูลต่างๆ จาก Existing Environment ขององค์กร จากนั้นจะนำเอาข้อมูลที่ได้ไปทำการวิเคราะห์, ตรวจสอบ, ประเมินว่า Environment ดังกล่าวนั้นเป็นอย่างไรบ้างในแง่ของความปลอดภัย มีจุดใดที่สุ่มเสี่ยงต่อความไม่ปลอดภัยหรือไม่

2. Cloud Workload Protection Platform (CWPP), โดย Microsoft Defender for Cloud จะเข้ามาทำการค้นหาและป้องกัน Threats หรือภัยคุกคามครับ

โดยทั้ง 2 หน้าที่ที่ Microsoft Defender for Cloud ที่ผมได้อธิบายไปเมื่อซักครู่นั้น ครอบคลุมทั้ง On-Premise, Hybrid และ Multi-Cloud Environment ครับ และรูปด้านล่างเป็นหน้าตาของ Microsoft Defender for Cloud ครับ

จากรูปด้านบนจะเห็นว่าจะไม่มีชื่อ Azure Security Center เหมือนก่อนหน้านี้ครับ จากนั้นผมจะทำการคลิ๊กที่ Microsoft Defender for Cloud เพื่อจะพาท่านผู้อ่านเข้าไปดูด้านในว่าหน้าตาเป็นอย่างไร ดังรูปด้านล่างครับ

จากนั้นผมคลิ๊กที่ Environment settings ซึ่งจะเป็นส่วนที่เราจะต้องทำการกำหนดว่าจะให้ Microsoft Defender for Cloud ทำหน้าที่อะไรบ้าง รวมถึงฟีเจอร์ต่างๆ ที่เราสามารถใช้งานได้ครับ และแน่นอนมีผลกับเรื่องของค่าใช้จ่ายด้วยนะครับ ดังรูปครับ

จากนั้นท่านผู้อ่านคลิ๊กที่ Tenant Root Group แล้วทำการเลือก Azure Subscriptions ครับ ว่าต้องการให้ Microsoft Defender for Cloud เข้าไปดำเนินการตามหน้าที่ที่ผมได้อธิบายไว้ก่อนหน้านี้กับ Azure Subscriptions ใดบ้างครับ เมื่อเลือก Azure Subscriptions ที่ต้องการแล้ว จากนั้นท่านผู้อ่านจะต้องทำการเลือก Defender Plans ดังรูปด้านล่างครับ

ซึ่งโดย Defautl ในส่วนของ Defender Plans จะเป็น Enhanced security off และมีฟีเจอร์ที่สามารถใช้งานได้อยู่ 2 ฟีเจอร์ คือ Continuous assessment and security recommendations กับ Secure score ตามรูปด้านบนครับ นั้นหมายความว่า Microsoft Defender for Cloud ทำหน้าที่ใน การรวบรวมข้อมูลต่างๆ จาก Existing Environment ขององค์กร จากนั้นจะนำเอาข้อมูลที่ได้ไปทำการวิเคราะห์, ตรวจสอบ, ประเมินว่า Environment ดังกล่าวนั้นเป็นอย่างไรบ้างในแง่ของความปลอดภัย และมีคำแนะนำมาให้เพื่อนำเอาไปปรับปรุง Environment ดังกล่าวนั้นให้มีความปลอดภัยมากขึ้นครับ รวมถึงมีการประเมินเป็นคะแนนให้ด้วยครับ ดังรูปด้านล่างครับ โดยไม่มีค่าใช้จ่ายครับ!!!!!

แต่ถ้าเราทำการเปลี่ยน Defender Plans มาเป็น Enable all Microsoft Defender for Cloud plans ก็จะเป็นการกำหนดให้ Microsoft Defender for Cloud ทำหน้าที่เพิ่มเติมจากก่อนหน้านี้ นั่นก็คือ การค้นหาและป้องกัน Threats หรือภัยคุกคาม บวกกับฟีเจอร์ต่างๆ ครับ โดย Plan ดังกล่าวนี้สามารถทดลองใช้งานได้ 30 วัน หลังจากนั้นมีค่าใช้จ่ายนะครับ ดังรูปด้านล่างครับ

เพราะฉะนั้น สิ่งสำคัญที่ผมอยากจะแนะนำท่านผู้อ่านทุกท่าน คือ เราจะต้องมีการวางแผนและเตรียมตัวกันก่อนนะครับว่า เราจะใช้ Microsoft Defender for Cloud ทำการป้องกัน Workloads ต่างๆ ใน Enviroment (On-Premise, Hybird, และ Multi-Cloud) ของเรามีอะไรบ้างและเป็นอย่างไร จากนั้นมาทำการพิจารณาในส่วนของ Defender Plans และอื่นๆ ครับ เพราะเราจะได้ประเมินค่าใช้จ่ายของ Microsoft Defender for Cloud ได้ครับ

ฟีเจอร์ต่อมาที่ผมอยากพาท่านผู้อ่านไปดู นั่นก็คือ Security Alerts ครับ โดยฟีเจอร์ดังกล่าวนี้จะทำการแจ้งเตือนเมื่อ Microsoft Defender for Cloud เจอ Threats ครับ ดังรูปด้านล่าง โดยรูปด้านล่างเป็นการแจ้งเตือนว่า Azure VM (WTADDSD2) ของผมถูก RDP Attacks ครับ

สามารถเข้าไปดูรายละเอียดของการแจ้งเตือนได้ ตามรูปครับ

จากข้อมูลข้างต้น Microsoft Defender for Cloud ก็จะแนะนำวิธีการที่จะ Mitigate ให้เราครับ ซึ่งในความเป็นจริงแล้ว Microsoft Defender for Cloud ยังมีความสามารถอีกเยอะเลยครับ บทความนี้เป็นเพียงแค่ส่วนหนึ่เท่านนั้นครับ  สำหรับท่านผู้อ่านท่านใดสนใจสามารถไปเข้าดูที่ Link นี้ได้เลยครับผม Microsoft Defender for Cloud - an introduction | Microsoft Docs

และทั้งหมดนี้คือเรื่องราวเกี่ยวกับ Microsoft Defenfer for Cloud ที่ผมมาให้อัพเดทความเปลี่ยนแปลงของ Service ดังกล่าวนี้ให้ทุกท่านได้ทราบกันครับผม.....

Data Encryption ใน Microsoft Azure

      สวัสดีครับทุกท่าน สำหรับบทความตอนนี้ของผมจะเป็นเรื่องราวเกี่ยวกับความปลอดภัยใน Microsoft Azure ครับ โดยบทความนี้จะโฟกัสไปที่เรื่องของ "Data Encryption" ครับ ซึ่งถือเป็นเรื่องที่แทบทุกองค์กรให้ความสนใจ เพื่อวางแผนและจัดการเรื่องดังกล่าวนี้ครับ เอาล่ะครับเรื่องราวจะเป็นอย่างไร สามารถติดตามกันได้เลยครับผม

โดยผมขอเริ่มจากในช่วงหลายปีที่ผ่านมาจนถึงปัจจุบัน หลายๆ องค์กรมีการนำเอา Microsoft Azure เข้ามา Adopt ใช้งาน สิ่งที่เกิดขึ้นตามมาแน่นอน นั่นก็คือการติดตั้งและใช้งาน Services ต่างๆ ใน Microsoft Azure เช่น Azure Virtual Machine, Azure Virtual Network, Azure Storage, Azure SQL และอื่นๆ ครับ  ดังนั้นเมื่อองค์กรใดต้องการที่จะทำการวางแผนเพื่อดำเนินการเรื่องของ Security นั้นก็จะต้องเริ่มต้นจากการรวบรวมและรีวิวข้อมูลต่างๆ ดูว่า ณ ปัจจุบันเป็นอย่างไร, เช่น Environment ขององค์กรเป็น Hybrid หรือ Multi-Cloud Environment, องค์กรของเราได้มีการติดตั้งและใช้งาน Services ใน Microsoft Azure ใดไปบ้าง และอื่นๆ และสุดท้ายคือ ความต้องการหรือ Requirements ครับ ข้อมูลและรายละเอียดต่างๆ ที่ได้รวบรวมมานั้น ก็จะนำเอามาทำการวิเคราะห์, วางแผน, ออกแแบบ, และดำเนินการต่อไปครับ 

สำหรับองค์กรที่สนใจเรื่องราวดังกล่าวนี้ ทาง Microsoft ได้เตรียม Models, Guidances, และอื่นๆ มาช่วยองค์กรที่ต้องการที่จะดำเนินการเรื่องดังกล่าวนี้ครับ เช่น Zero Trust Model, Defense-In-Depth Model, และอื่นๆ ครับ สำหรับบทความนี้ผมจะโฟกัสเรื่องของ Data Encryption นะครับ 

โดยผมขอแนะนำ Defense In-Depth Model มาใช้เป็น Reference ในการวางแผนและดำเนินการได้ครับ เพราะใน Defense-In-Depth จะประกอบไปด้วย Layers ต่างๆ ซึ่งองค์กรสามารถทำการพิจารณา, วางแผนและดำเนินการเรื่องของ Security ได้ในแต่ละ Layers ครับ โดยแต่ละ Layers ทาง Microsoft ได้เตรียม Services ตลอดจนฟีเจอร์ต่างๆ ใน Microsoft Azure เข้ามาช่วยในเรื่องของ Security ครับ เพื่อทำให้ภาพรวมของ Environment ขององค์กรมีความปลอดภัยและลดความสุ่มเสี่ยงต่อการถูกโจมตีจากภัยคุกคามครับ รูปด้านล่างคือ รูปที่แสดงถึง Layers ต่างๆ ของ Defense-In-Depth ครับ

Defense-In-Depth Model

มาดูกันครับว่าในแต่ละ Layers ของ Defense-In-Depth มีรายละเอียดอย่างไรครับ

Physical Sercurity, Layer นี้จะโฟกัสที่ความปลอดภัยของ Physical Data Center ตลอดจน Hardware ต่างๆ ครับ ในกรณีที่องค์กรได้มีการติดตั้งและใช้งาน Services ต่างๆ ใน Microsoft Azure ใน Layer นี้ก็จะเป็นหน้าที่ความรับผิดชอบของทาง Microsoft ครับ ในทางกลับกัน ถ้า Workloads หรือระบบต่างๆ รันใน On-Premise Data Center ก็จะเป็นหน้าที่ความรับผิดชอบขององค์กรสำหรับเรื่องของ Security นะครับ

Identity & Access, Layer นี้จะโฟกัสที่ความปลอดภัยของ Identity ของผู้ใช้งานในองค์กรครับ เนื่องจาก ณ ป้จจุบ้น ผู้ใช้งานในองค์กรสามารถเข้าถึง Data หรือ Applications ต่างๆ ที่อยู่ที่ไหนก็ได้ (On-Premise หรือ On Cloud) ดังนั้นองค์กรจะต้องมีการวางแผนในเรื่องของความปลอดภัยของ Identity หรือ User Accounts ของผู้ใช้งานด้วยครับ โดยองค์กรสามารถนำเอาฟีเจอร์ต่างๆ ใน Azure Active Directory (Azure AD) มาช่วยได้ครับ ทั้งนี้ขึ้นอยู่กับ Azure AD Edition ที่องค์กรใช้งานด้วยนะครับ

Perimeter, Layer นี้จะโฟกัสเรื่องความปลอดภัย โดยพิจารณาเรื่องการควบคุมและจัดการ Traffics ที่เข้าและออกขององค์กร โดยเฉพาะองค์กรที่มีลักษณะเป็น Hybrid Cloud Envrionment เช่น มีการเชื่อมต่อระหว่าง On-Premise กับ Microsoft Azure ผ่านทาง VPN เป็นต้น ดังนั้นองค์กรควรจะมีการพิจารณาวางแผนนำเอา Firewall เข้ามาใช้งาน, รวมถึงการป้องกันการโจมตี เช่น DDos เป็นต้นครับ

Network, Layer นี้จะโฟกัสเรื่องความปลอดภัยของ Networks โดยเฉพาะ Azure Virutal Networks หรือ Azure VNets ครับ เช่น การควบคุมหรือการ Filter Traffics ระหว่าง Subnets หรือระหว่าง Azure Virtual Networks ครับ

Compute, Layer นี้จะโฟกัสเรื่องความปลอดภัยเกี่ยวกับ Services ของ Microsoft Azure ครับ เช่น Azure Virtual  Machines, Azure Containers เป็นต้น ยกตัวอย่าง เช่น การเข้ารหัส Disks, การติดตั้ง Anti-Virus, การอัพเดท Patches, และอื่นๆ ของ Azure Virtual Machines เป็นต้นครับ

Application, Layer นี้จะโฟกัสเรื่องความปลอดภัยของ Applications เช่น การตรวจสอบช่องโหว่ (Vulnerabilities), การเก็บรักษา Secrets, และอื่นๆ เป็นต้นครับ

Data, Layer นี้จะโฟกัสเรื่องความปลอดภัยของ Data ครับ โดยในบทความนี้ของผมจะโฟกัสที่ Layer นี้ครับผม

เอาล่ะครับ มาถึงจุดที่องค์กรของเราหรือตัวของท่านผู้อ่านเองต้องการที่จะดำเนินการเรื่องดังกล่าวนี้ (Data Encryption) สิ่งที่ผมแนะนำก่อนเลยและถือเป็นเรื่องที่สำคัญ นั่นก็คือ ท่านผู้อ่านจะต้องทำความเข้าใจก่อนว่าการทำ Data Encryption ใน Microsoft Azure นั้นมีคอนเซปเป็นอย่างไร โดยผมขอเริ่มจากลำดับแรกเลย คือ Data ครับ โดย Data ดังกล่าวที่เราต้องการจะทำ Encryption นั้นเกี่ยวข้องกับ Services ใดใน Microsoft Azure เช่น Azure Virtual Network, Azure Storage, Azure Virtual Machine เป็นต้น เพราะแต่ละ Services ใน Microsoft Azure จะมีฟีเจอร์ในการทำ Encyrpiton ครับ ผมยกตัวอย่าง เช่น ใน Azure Virtual Machines จะมีฟีเจอร์ที่ชื่อว่า "Azure Disk Encryption" หรือ ADE เพื่อใช้ในการเข้ารหัส Data นั่นก็คือ Disks ของ Azure Virtual Machines เป็นต้นครับ  ลำดับถัดมา เราจะต้องทำการเข้าใจเกี่ยวกับสถานะ หรือ State ของ Data ที่เราต้องการทำ Encryption ครับ โดยจะมีรายละเอียดดังนี้ครับ

1. Data At-Rest, เป็น State หรือสถานะของ Data ที่ถูกเข้ารหัส (Encryption) ที่ Physical Drives เพื่อสร้างความมั่นใจว่า ถ้าเกิดเหตุการณ์ที่มีบุคคลใดๆ เข้าไปขโมยหรือนำเอา Physical Drives (Disks) ออกมาจาก Azure Data Center จะไม่สามารถทำการอ่านข้อมูลที่อยู่ใน Physical Drives ดังกล่าวได้ครับ

2. Data In-Transit, เป็น State หรือสถานะของ Data ที่ถูกเข้ารหัส (Encryption) ในการติดต่อสื่อสาร (Communication) กันระหว่างผู้ใช้งานกับ Services เช่น การใช้ HTTPS เป็นต้นครับ

3. Data In-Memory, เป็น State หรือสถานะของ Data ที่ถูกเข้ารหัส (Encryption) ใน Memory ของ Azure Virtual Machine เป็นต้น เพื่อป้องกันการเอา Data ที่อยู่ใน Memory ออกไปครับ

4. File-Level, เป็น State หรือสถานะของ Data ที่ถูกเข้ารหัส (Encryption) ในระดับของ File (File-Level) ที่อยู่ภายใน Azure Virtual Machines หรือ Azure Services (PaaS) เช่น ถ้ามีบุคคลที่สามารถทำการเข้าถึง Azure Virtual Machines (SQL หรือ File Servers เป็นต้น) ได้ นั่นหมายความว่าบุคคลดังกล่าวก็สามารถทำการ Read /Copy File หรือ Content ได้ ดังนั้นถ้าเรามีการทำ Data Encryption ใน State หรือสถานะดังกล่าวได้ก็จะทำให้มีความปลอดภัยมากขึ้น

5. Server Side, เป็น State หรือสถานะของ Data ที่ถูกเข้ารหัส (Encryption) เพื่อช่วยทำให้ Data มีความปลอดภัยจากกรณีการเข้าถึงโดยการใช้ API/Portal  ยกตัวอย่างเช่น มีบุคคล Sign-In โดยใช้ Azure Portal แล้วทำการดาวน์โหลด Virtual Hard Disk (Disks ของ Azure Virtual Machines) ดังนั้นการทำการ Encryption ใน State หรือสถานะดังกล่าวนี้ก็จะช่วยป้องการการรั่วไหลของข้อมูลได้อีกทางครับ

เอาล่ะครับ เมื่อมาถึงตรงนี้หลังจากที่ผมได้อธิบายเรื่องราวของ Defense-In-Depth Model และ State หรือ สถานะของ Data แล้ว ในขั้นตอนถัดไป ก็จะเป็นการเริ่มวางแผน, ออกแบบ, และดำเนินการครับ ซึ่งจะทำตรงไหนอย่างไร ก็ขึ้นอยู่กับความต้องการของแต่ละองค์กรครับ แต่สิ่งสำคัญคือ ความเข้าใจกับคอนเซปตลอดจนเรื่องราวต่างๆ ที่ผมได้นำเสนอไปครับ

และทั้งหมดนี้คือเรื่องราวภาพรวมและคอนเซปต่างๆ ที่เกี่ยวกับเรื่องของ Data Encryption ใน Microsoft Azure ครับผม.....