[AZ-305] Design identity, governance, and monitor solutions

Design governance

Recap กันก่อน Azure มี Level การจัดการดังนี้ Tenant Root Group > Management Group > Subscriptions > Resource Group > Resouces เล็กสุด กลยุทธ์ในการสร้าง Governance จะมี Azure Policies / Recsource Tags

Management Group - จุดที่ Apply Policy ที่ Common โดย Level ได้ 6 Level ไม่รวม Root

• Design management groups with governance in mind
• Keep the management group hierarchy reasonably flat - ปกติ 3-4 Level ถ้าลึกมากจะจัดการลำบาก
• Consider a top-level management group - top-level ใส่ common policy/azure role

• Consider an organizational or departmental structure
• Consider a geographical structure - จะได้กำหนด Policy ตาม Region
• Consider a production/sandbox (Dev/Test) management group
• Consider isolating sensitive information in a separate management group - เพื่อ Secure Sensitive Data

Subscriptions

• Treat subscriptions as a democratized unit of management เช่น จับตาม business needs + priorities.
• Group subscriptions together under management groups
• Consider a dedicated shared services subscription - ensure all common network resources are billed together and isolated from other workloads เช่น พวก Azure ExpressRoute / Virtual WAN
• Consider subscription scale limits - specialized workloads HPC, IoT, and SAP ควรแยก Subscription ออกไป จะได้ไม่ติดเรื่อง Resource Limit
• Consider administrative management.
• Consider how to assign Azure policies
• Consider network topologies
  - vnet มันไม่สามารถแชร์ข้าม Subscription ได้นะ ดังนั้นต้องเอาท่าอื่นมาช่วย อย่าง VNET Peering /
• Consider making subscription owners aware of their roles and responsibilities

resource groups - มันมี region เอาไว้เก็บ metadata นะ ถ้า region พัง จะเอ๋อๆนิดหน่อย แต่ resource ไม่จำเป็นต้องอยู่ region เดียวกับ resource group ก็ได้ + nested ไม่ได้

• Consider group by type เช่น SQL-RG / WEB-RG เป็นต้น
• Consider group by app
• Consider group by department, group by location (region), and group by billing (cost center)
• Consider a combination of organizational strategies
  - the combination of options is best"
  - ใช้ตามความเหมาะสม ไม่จำเป็นต้องแบบเดียวกันทั้ง Org
• Consider resource life cycle - นึกภาพเคส Staging / Production เลย หรือ รอบการ update เอามาไว้ใน RG เดียวกันได้
• Consider administration overhead - คนจัดการ RG
• Consider resource access control - Policy / Role (2 อันนี้ มาจาก Management Group) / Resource Lock
• Consider compliance requirements

resource tags - name-value pair เอาไว้จัดการอืนๆ เช่น Billing

• organization's taxonomy
• IT-aligned or business-aligned tagging
• Consider the type of tagging required เช่น Functional, Classification ( เช่น confidentiality / SLA) Accounting (หน้าที่) , Partnership (คนที่เกี่ยวข้อง), Purpose
• starting with a few tags and then scale out
• Azure policy to apply tags and enforce tagging rules and conventions.
• which resources require tagging

Azure Policy มี Policy แบบ built-in policy / initiatives (จัดกลุ่มของ Policy เข้าด้วยกัน) / inherited down the hierarchy ที่ให้จัดตาม Management Group / prevent noncompliant resources from being created อ๋อและใช้กับ Azure DevOps ได้ด้วยนะช่วง pre/post deployment โดยมีสิ่งที่ต้องพิจารณา ดังนี้

• ตรวจสอบจาก Azure Policy compliance dashboard มันเห็นภาพรวม และช่วยทำ Bulk Remediation ได้
• Understand when and how evaluations are triggered เช่น ตอน Resource ถูกสร้าง หรือ Apply Policy อันนี้ Evaluation Cycle 24 hrs
• how to handle a non-compliant resource - ปรับตาม / Log / ไม่สนใจ
• when to automatically remediate noncompliant resources - Azure Policy can tag resources and reapply tags ได้ อาทิ เช่น Location บอก Region เป็นต้น
• how Azure Policy is different from role-based access control (RBAC) - มีดังนี้
  - Azure Policy to ensure the resource state ตาม business rules.
  - Azure RBAC to focus on user actions at different scopes + Control resource access

Role-based access control (RBAC) - An allow model + additive model, Azure RBAC enables the user to perform the actions associated with that role.

Default จะปิดไง ถ้าจะใช้ต้องกำหนดให้ User / Group นั้นๆ โดยมีสิ่้งที่ต้องพิจารณา ดังนี้

• highest scope level for each requirement - Key ทำ role definition และกำหนด Assign จะ management groups, subscriptions, resource groups, and resources.
  จะได้ลด Effort + assigning roles to groups, and not users ถ้าทำที่ละจุด จะจัดการยาก
• Consider the access needs of each user - ชอบภาพนี้นะ หามานาน

• when to use Azure policies vs Azure RBAC

• custom role shared between subscriptions - แต่ใช้ Azure AD เดียวกัน
• how to resolve overlapping role assignments ยกตัวอย่าง user เดียวกัน ได้ Role Subscription (Contributor) / Resource group (Reader) มันยึดตัวใหญ่กว่า additive model

Azure Blueprints - scale governance practices + orchestrates the deployment throughout an organization โดยสิ่งต้องพิจารณาจากตอน Compose

• Resource groups
• Azure Resource Manager (ARM) Templates
• Policy assignment - policy or initiative must be within the scope of the blueprint definition
• Role assignment

Azure landing zone provides an infrastructure environment for hosting your workloads / defined by management groups and subscriptions
โดยมีสิ่งที่ต้องสนใจ ดังนี้

• including landing zones in your design
• creating landing zones through code - มันช่วยให้ Re-created ง่าย
• ใช้ Azure landing zone accelerator ทำให้เห็นภาพ conceptual ว่าจะ Link กับ management group ไหน และช่วย transitioning existing architectures to Azure landing zones
• application-centric migrations and development + Use Azure-native design and aligning with the platform- พยายาม modernize มากกว่า lift-and-shift เช่น มี Web ให้ App Service + Azure SQL แทนที่จะใช้ Azure VM แต่จริงๆ อันนี้มันทำให้เรา Coupling กับ Azure ไปเลยนะ
• scoping for both migrations and greenfield (ทำใหม่) situations
• อย่าลืมทำ Azure landing zone review ก่อน Start

Knowledge check: Design governance

Design authentication and authorization solutions

identity and access management (IAM)

• IAM - Unified identity management / Seamless user experience / Secure adaptive access (authentication and risk-based adaptive access policies) และ Simplified identity governance //สรุปรวมศูนย์ ง่าย และสะดวก ไม่กระทบ User
• ที่ควรพิจารณาสำหรับใช้ IAM
  - ใช้ Entra Id (Azure AD) - Internal
  - Microsoft Entra External ID (Azure AD B2B) กรณี ฺBusiness กับ Business เช่น เรา กับ Vendor
  - Azure Active Directory B2C กรณี ฺBusiness กับ Customer เช่น เรา กับ ลูกค้า ที่อาจจะสมัคร App ไงงี้

Design for Azure Active Directory

• Entra Id (Azure AD) ตัว IAM ของ Azure ที่เตรียมไว้ให้ Link ได้ทาั้ง Azure + On-Premises

• สิ่งที่ควรพิจารณาสำหรับใช้ Entra Id
  - benefits of centralized identity management - จัดการง่าย
  - using a single Microsoft Entra instance - ลด Risk/Human Error + จัดการง่าย
  - limiting account synchronization - Don't synchronize accounts to Active Directory that have high privileges in your existing Azure AD //สิทธิสูง ให้แยก
  - password hash synchronization - sync helps to protect leak แบบว่าเปลี่ยน Cloud แต่ On-Premises เหมือนเดิม
  - single sign-on (SSO) - reduce multiple identity
  - overhead of managing separate identities - มีเยอะเพิ่ม mistakes + security breaches

Microsoft Entra business-to-business (B2B) - จัดการ External Identity //ตอนแรกฟัง 104 มาก็งงๆ ตอนนี้เข้าใจ และ

• ตัว External Identity เราไม่ต้องจัดการ //ฝั่งเราจัดการสิทธิ apps and services
• สิ่งที่ควรพิจารณาสำหรับใช้ Azure AD (B2B)
  - designating an app owner to manage guest users. ให้ app owner จัดการ รู้ว่าใครควรใช้ และลดภาระ Admin
  - MFA + conditional access policies to control access
  - integration external (Microsoft นอกองค์กร / FB / Google etc.) identity providers
  - self-service sign-up user flow - ลดภาระ Admin

Azure Active Directory B2C (business-to-customer)

• B2B กับ B2C ต่างกันยังไง ?

WoodGrove Groceries tutorial - Sample นี้ดี มี use-case เยอะดี

• สิ่งที่ควรพิจารณาสำหรับใช้ Azure AD (B2C)
  - reusable flows for user journey - user flows
  - allowing users to sign in with their social identities (นึกพวก FB / Google / Twitter etc)
  - customizable user interface to support branding - custom UI สำหรับองค์กร ดูเพิ่มได้จาก page layout templates.
  - integration with external user stores - custom field หรือ จะเอาข้อมูลจาก External System อย่าง CRM ก็ได้
  - customizable user interface to support branding
  

Conditional Access - เอาร่วมกับ MFA เพื่อให้ Secure ขึ้่น ดูจาก Condtion + Risk การเปิดใช้งาน Report-only mode ช่วยให้เห็น Impact หรือจะ What If ช่วยแก้ปัญหา หรือ Simulate ก่อน Implement

• สิ่งที่ควรพิจารณาสำหรับใช้ conditional access
  - MFA for more granular control. ทำให้ยืดหยุ่น มาจาก Device ขององค์กร
  - preventing access from specific geographic areas - IP แปลก Block ไว้
  - access only from managed devices
  - access only from approved client apps - จะเป็นเรื่อง BYOD เอา Device มาเอง
  - using policies to handle compromised accounts - ถ้ามี user ส่งสัยว่า Identity หลุด Required เจ้าตัวทำ MFA หรือ ทุกคนเป็นต้น
• blocking access + เคส Migrate กันคนมาทำอะไรแปลกๆ หรือ legacy authentication protocols
• Consider running Report-only mode - evaluate the impact of Conditional Access policies before enabling บอกผลกระทบ
• Consider using the What If tool - ตัว  What If เป็น Tools ที่ช่วยตรวจสอบ Conditional Access

Identity Protection - tool ที่เอา Signal มาได้จาก SIEM และนำมา Apply ช่วยจัดการเรื่อง Automate the detection and remediation of identity-based risks / Investigate risks (จาก Signal) / Export risk detection data 

• Identity Protection มี 2 กลุ่ม User risk (เช่น Leaked credentials / AI เจอ Activity แปลกๆ) และ Sign-in risk (เช่น IP แปลก / Password Spray)

• สิ่งที่ควรพิจารณาสำหรับใช้ Identity Protection
  - "High" threshold for user risk policy - ช่วยดู leaked credentials / unusual activity + known attack patterns
  - "Medium and above" threshold for sign-in risk policy - Option นี้ มัน self-remediation options อย่าง MFA หรือ เปลี่ยน Pass และไม่ไป Block การทำงานของ User
  - investigating risks in the Azure portal
  - exporting your risk detection data

Design for access reviews - คนเรามีหมวกหลายใบ และมีการปรับเปลี่ยนอยู่ตลอด ย้ายหน่วย ย้ายงาน ลาออก บราๆ การจัดการสิทธิ เพื่อให้มัน Up to Date และลดความเสี่ยงที่คนที่ไม่เกี่ยวข้อง ยังเข้าถึง Resource ได้อยู่

• Review Azure AD roles + Azure Resource roles Access จาก Privileged Identity Management (PIM).
• access review plan
  - ใครที่เกี่ยวข้อง: Resource owners / Delegates (Admin มอบหมาย) / End Users ที่ยังใช้ //อารมณ์ ถ้าไม่แจ้งตัดออก
  - อะไรที่ต้อง Review: Azure AD roles + Azure Resource roles
• จัดกลุ่มการ Review ยังไง โดยมีคำถาม ดังนี้
  - What are the resources to review
  - How often should the access review be done
  - Who are the reviewers
  - How will reviewers be notified
  - How long should the review take to complete
  - Are there automatic actions for these resources - default remove สิทธิสำหรับคนที่ไม่ได้ access เกิน x วัน หรือเอาออกหมดเลย
  - Are there manual actions available to the reviewers
  - How will affected users be notified - คนที่เกี่ยวข้อง จะมีแจ้งเตือนไหม
• ดูอันนี้เพิ่มได้ละเอียดดี What are access reviews? - Microsoft Entra

Design service principals for applications

• two ways an app can be represented in Azure AD
  - Application objects (definition for an app 1-1)
  - Service principals (definition for an app 1-many) แยก tenant จะมาตอน registration /consent หรือจะใช้ Tools อื่นๆ อย่าง PowerShell, Azure CLI, Microsoft Graph เป็นต้น

• service principals
  - application service principal
  - Managed identity
  - Legacy - มาก่อน before app registrations / ใช้ได้ภายใน tenant
• สิ่งที่ควรพิจารณาสำหรับใช้ service principals
  - Consider how to create your application service principals โดยมาจากหลายแบบ
  1. app is given permission to access resources จาก registration or consent / service principal
  2. register an app ตัว service principal สร้างมานะ
  ตัว service principal สร้างได้จากหลายตัว CLI / MS Graph / ..
  - Use service principals without managed identities when you want to be able to manage the credentials.
  - Authenticate external apps to Azure resources by using service principals.
  - best practices for requesting permissions - ขอเท่าที่ใช้ (least-privileged) / Error แจ้งให้ชัดว่าขาดอะไร ติดต่อใคร remedy the issue
  - restricting user consent - ทำได้ แต่ต้องเข้ากับ policy ของ org

Design managed identities

• managed identity - เป็นตัวที่เราจะให้ App ถือ Azure AD tokens มา access resource ต่อ โดยมี 2 แบบ
  - System-assigned (มาคู่กับ Resource)
  - User-assigned (จัดการเอง ให้ Resource ใช้ Identity เดียวกัน)
• A managed identity combines Azure AD authentication and Azure role-based access control (RBAC).
• สิ่งที่ควรพิจารณาสำหรับใช้ managed identities
  - using system-assigned managed identities
  - choosing user-assigned managed identities - workloads with resources that are recycled frequently / ต้องการ Shared Identity อาจจะทำเป็น Pre-Authorization
  - Consider your Azure services and your targets บาง Service เช่น VM / AKS เราเอา managed identities มาใช่กับ Resource อื่นๆได้ เช่น Azure Key Vault, Azure Storage, Azure SQL เป็นต้น
  - managed identities for VMs in Azure
  -> ตัวอย่าง Lab ใน AZ-400 เลย Tailwind Traders stock-tracking apps inside an Azure-hosted VM that has an assigned managed identity. This setup allows the app to use an Azure key vault to authenticate
  -> พอใช้ key vault และเอา Code ที่ Hard Code ในส่วน Authentication ออกได้
  - ใช้ Azure Key Vault authentication for Azure resources.

Design for Azure Key Vault

• Azure Key Vault
  - เป็น Centralized secret storage จัดการ secrets / keys / certificates ทำให้ไม่มีอะไรตกหล่นไว้ใน Code ของ Deploy ของเรา
  - โดย Tier Premium จะมี hardware security module (HSM) ด้วย
• สิ่งที่ควรพิจารณาสำหรับใช้ Azure Key Vault
  - shared access signatures (SAS) for clients - delegate หลังจาก Login ขอ SAS Token เลย หรือถ้าไม่มีใช้ SAS Token
  - Consider user read and write access to your storage account.
  1. Clients upload and download data via a front-end proxy service that performs authentication. ช้าลง
  2. A lightweight service shared access signature มาเข้าถึง Resource
  3. hybrid approach 1+2
  - data protection for your key vault: Soft Delete (กันลบแบบไม่ตั้งใจ) / Purge protection (Recycle Bin)
  - using separate key vaults อย่างใช่ key เดวกับทุกระบบ
  - access to the key vault - access policy / least privilege / firewall / network

Knowledge check: Design authentication and authorization solutions

Design a solution to log and monitor Azure resources

Design for Azure Monitor

• data sources มี 2 อย่างที่สำคัญ Log + Metric และมี Sources of monitoring data from 
  - high application เรา
  - low ของ azure

• สิ่งที่ควรพิจารณาสำหรับใช้ Azure Monitor
  - data sources and data access
  -> Application data จาก Code ของเรา
  -> Operating system data มี 3 ส่วน Diagnostic extension / monitor log / VM Agents
  -> Azure resource data - เช่น web app / load balancer.
  -> Azure subscription data - ข้อมูล Subscription / Azure health and availability.
  -> Azure tenant data - Azure organization-level services - Azure Active Directory.
  -queries on Logs data
  -alerts based on Logs and Metrics data
  -Metrics Explorer to analyze metrics interactively

Design for Azure Monitor Logs (Log Analytics) workspaces

• Azure Monitor Logs (Log Analytics) เก็บ Log ของ Azure Monitor โดยการ Deploy มี Factor ที่ต้องดู ดังนี้
  - Availability, latency, and cost - hot / cool / cold / archive + premium storage + geolocation
  - Immutable storage - ตามกฏหมาย (Legal hold) / Time-based retention
  - single workspace for all resource with Azure RBAC
  - ถ้า Data > 500 GB ควรเลือก own dedicated clusters สำหรับ Workspace

• สิ่งที่ควรพิจารณาสำหรับใช้ Log Analytics workspaces
  - access control strategy - บังคับ data ต้องตาม Geo-Location ไหม เช่น ต้องอยู่ในไทยนะ (ยังไม่มี DC 55) หรือ ลด Cost ของ outbound data transfer charges สุดท้ายตาม Org Chart
  - deployment model options
  -> Centralized ( hub and spoke) รวมศูนย์ Data ใหญ่ ใช้ Admin Effort เพิ่ม แต่เห็นภาพรวม
  -> Decentralized - difficult to cross-correlate logs.
  -> Hybrid
  - access mode
  -> Workspace-context - เห็นหมด
  -> Resource-context เห็นตาม resource, resource group, or subscription
  - Azure RBAC and workspaces
  - scale and ingestion volume rate limit.

Design for Azure Workbooks and Azure insights

• Azure Workbooks รวม Data Source ของ Azure Logs / Metrics / Resource Graph/ Alerts / Workload Health / Resource Health / Azure Data Explorer มาเป็น 1 เดียว และมาสร้าง health (availability, performance, usage)
• Insight มาจากไหนบ้าง Application Insights / Container insights (ACI / AKS) / Networks insights / Resource group insights / Virtual machine insights / Azure Cache for Redis insights / Azure Cosmos DB insights / Azure Key Vault insights / Azure Storage insights
  //เยอะจริง ตอนลองเล่น Azure เองลองแต่ Application Insights ตลอด
• สิ่งที่ควรรู้ สำหรับใช้ Azure Workbooks and Azure insights
  - Azure Workbooks - หา root cause analysis of incidents และ shared เป็น operational playbook
  - Azure insights and data analysis - เปิดไว้ และ Tune
  - Combined data sources and visual reporting

Design for Azure Data Explorer

• Azure Data Explorer - Big Data แล้วแหละ unified big data analytics platform ที่เอา log + telemetry data มา diagnostics, monitoring reporting หรือจะ Analysis + ML ก็ได้

• สิ่งที่ควรพิจารณาสำหรับใช้ Azure Data Explorer
  - เข้าใจ native capabilities in Azure Monitor
  - ไม่มีอะไรดีสุด Combine features Microsoft Sentinel / Azure Monitor with Azure Data Explorer to build a flexible and cost-optimized end-to-end monitoring
  - advantages of Azure Data Explorer ทีตัว Microsoft Sentinel + Azure Monitor ยังไม่ได้ทำสะดวกมี application trace logs / near-real-time analytics / role-based access control/ anomaly detection and forecasting / machine learning (ต่อยอดกับ Data Bricks หรือ Azure ML ก็ได้นะ)
  - long data retention in a cost-effective manner

Knowledge check: Design a solution to log and monitor Azure resources

Reference

• AZ-305: Design identity, governance, and monitor solutions - Training | Microsoft Learn