ISSAP — Information Systems Security Architecture Professional

1. Domain 1 — Governance, Compliance & Risk Architecture / Quản trị, tuân thủ & quản lý rủi ro

1.1. Enterprise Security Architecture Frameworks

SABSA (Sherwood Applied Business Security Architecture) là framework duy nhất được thiết kế riêng cho security architecture. SABSA sử dụng mô hình ma trận 6 lớp (tương tự Zachman) nhưng đặt business risk làm trung tâm. Sáu lớp SABSA: Contextual (Business — "Why?"), Conceptual (Architect — "What?"), Logical (Designer — "How?"), Physical (Builder — "With what?"), Component (Tradesman — "Where & when?"), Operational (Manager — "Who?"). Mỗi lớp được xem xét theo 6 chiều: Assets, Motivation, Process, People, Location, Time.

TOGAF ADM (Architecture Development Method) cung cấp 9 phase (Preliminary → A: Architecture Vision → B: Business → C: Information Systems → D: Technology → E: Opportunities → F: Migration Planning → G: Implementation Governance → H: Architecture Change Management) kèm Requirements Management ở trung tâm. Khi tích hợp security vào TOGAF, security architect tham gia từ Phase A và duy trì Security Architecture Repository bao gồm Architecture Principles, Reference Models, và Standards.

1.2. Risk-Driven Architecture Decisions & Threat Modeling at Enterprise Scale

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) được áp dụng ở cấp architecture để phân tích threat per component trên Data Flow Diagram (DFD). Ở enterprise scale, mỗi trust boundary trên DFD phải được phân tích STRIDE — kết quả được ghi vào Architecture Risk Register.

PASTA (Process for Attack Simulation and Threat Analysis) gồm 7 stage: I) Define Objectives → II) Define Technical Scope → III) Application Decomposition → IV) Threat Analysis → V) Vulnerability & Weakness Analysis → VI) Attack Modeling → VII) Risk & Impact Analysis. PASTA phù hợp hơn STRIDE ở cấp enterprise vì tích hợp business context vào quá trình threat modeling.

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) — phiên bản OCTAVE Allegro — tập trung vào information assets và tác động lên mission của tổ chức, phù hợp với enterprise risk assessment khi cần ưu tiên bảo vệ dựa trên business impact.

1.3. Compliance Architecture — Embedding Regulatory Requirements

Compliance architecture là nghệ thuật tích hợp yêu cầu pháp lý vào security controls mà không tạo ra control silos. Phương pháp Unified Controls Framework (UCF) ánh xạ nhiều regulation về một control set chung: ví dụ một control "Mã hóa dữ liệu lưu trữ với AES-256" đồng thời thỏa mãn GDPR Article 32, PCI-DSS Requirement 3.4, và HIPAA §164.312(a)(2)(iv).

• GDPR (EU 2016/679): Article 25 — Privacy by Design & by Default yêu cầu security được tích hợp vào architecture, không phải thêm vào sau. Article 32 yêu cầu "appropriate technical and organisational measures".
• PCI-DSS v4.0: 12 Requirements tổ chức thành 6 goals. Requirement 1 & 2 (Network Security) trực tiếp ảnh hưởng đến network security architecture — phân đoạn CDE (Cardholder Data Environment) là yêu cầu bắt buộc.
• HIPAA Security Rule (45 CFR Part 164): §164.312 Technical Safeguards yêu cầu Access Control, Audit Controls, Integrity Controls, và Transmission Security — mỗi safeguard phải được map vào architecture component.

1.4. Security Policy Hierarchy

Kiến trúc bảo mật cần xây dựng policy stack có tính phân cấp rõ ràng: Enterprise Policy (mức cao nhất — CEO/Board phê duyệt, dài 1-2 trang, không đổi thường xuyên) → Domain Policy (ví dụ: "Acceptable Use Policy", "Remote Access Policy" — CISO phê duyệt) → Standard (định nghĩa cụ thể — ví dụ "Password Standard: tối thiểu 14 ký tự, MFA bắt buộc cho privileged accounts") → Procedure (hướng dẫn từng bước thực hiện) → Guideline (khuyến nghị, không bắt buộc). Security architect phải đảm bảo architecture artifacts có thể traceability ngược lên policy stack.

2. Domain 2 — Security Architecture Modeling / Mô hình hóa kiến trúc bảo mật

2.1. UML Security Extensions & Architecture Views

UML (Unified Modeling Language) được mở rộng cho security modeling thông qua stereotypes và tagged values. Các diagram quan trọng nhất cho security architect: Sequence Diagram để model authentication flows (ví dụ SAML 2.0 SP-initiated SSO — 9 bước trao đổi message giữa User Agent, Service Provider, Identity Provider); Component Diagram để thể hiện trust boundaries bằng đường kẻ nét đứt (dashed line) phân tách security zones; Deployment Diagram cho physical security topology.

Năm architecture views cho security overlay: Business View (security use cases, risk appetite statement) → Application View (ứng dụng nào trust ứng dụng nào, data flow giữa apps) → Data View (data classification scheme, encryption at rest/in transit per data class) → Technology View (infrastructure components, OS/middleware hardening) → Security Overlay (ánh xạ security controls lên tất cả 4 view trên).

2.2. Zero Trust Architecture — NIST SP 800-207

NIST SP 800-207 định nghĩa Zero Trust dựa trên 7 tenets: (1) Tất cả data sources và computing services đều là resources. (2) Mọi communication được bảo mật bất kể vị trí mạng. (3) Access to individual enterprise resources được cấp theo từng session. (4) Access to resources được quyết định bởi dynamic policy. (5) Enterprise giám sát và đo lường tính toàn vẹn của tất cả assets. (6) Tất cả resource authentication và authorization là dynamic và strict. (7) Enterprise thu thập thông tin về state hiện tại của assets và sử dụng để cải thiện posture.

Micro-segmentation patterns: (1) Host-based — agent trên từng endpoint enforce policy (ví dụ Illumio, Guardicore); (2) Hypervisor-based — VMware NSX enforce policy ở vSwitch layer; (3) Network-based — SDN controller phân đoạn theo VLAN/VxLAN với dynamic ACL. Security architect phải chọn pattern dựa trên: density of lateral movement risk, existing infrastructure, và operational overhead.

2.3. Security Architecture Patterns

Defense-in-Depth: Xếp chồng nhiều lớp kiểm soát độc lập — nếu lớp ngoài bị breach, lớp trong vẫn bảo vệ. Architect phải đảm bảo mỗi lớp sử dụng cơ chế khác nhau (diversity of mechanisms) để tránh common-mode failure. Ví dụ: Perimeter Firewall → IPS → WAF → Application Authentication → Database Encryption.

Fail-Safe Defaults: Default action phải là "deny" — chỉ grant access khi có explicit permission. Áp dụng cho: firewall rules (default deny all), IAM (deny unless explicitly allowed), API gateway (block unknown endpoints). Nguyên lý này cũng áp dụng cho fail-secure trong trường hợp system failure — ví dụ khi authentication service down, system không nên cho phép anonymous access.

Least Privilege by Design: Không phải chỉ là configuration — phải được tích hợp vào architecture. Ví dụ: microservices chỉ có quyền đọc/ghi database table của mình (không phải toàn bộ DB); Lambda function chỉ có IAM role với quyền tối thiểu; service account không có interactive login.

3. Domain 3 — Infrastructure Security Architecture / Kiến trúc bảo mật hạ tầng

3.1. Network Security Architecture — DMZ & Jump Server Patterns

DMZ (Demilitarized Zone) truyền thống sử dụng hai firewall (dual-firewall DMZ): Firewall ngoài (Internet-facing) chỉ cho phép traffic đến DMZ hosts trên specific ports; Firewall trong (internal-facing) chỉ cho phép traffic từ DMZ đến internal network trên specific ports. DMZ hosts (web server, mail relay, reverse proxy) không bao giờ initiate connection vào internal network.

Jump Server / Bastion Host Pattern: Tất cả administrative access vào production systems phải đi qua jump server. Jump server được hardened: không có user data, không browse internet, session recording bắt buộc, MFA required. Kiến trúc hiện đại thay thế jump server bằng Privileged Access Workstation (PAW) kết hợp với Just-in-Time (JIT) access — không có standing privileged access.

Out-of-Band (OOB) Management: Management network vật lý tách biệt hoàn toàn với production network. IPMI/iDRAC/ILO interfaces chỉ accessible qua OOB network — không bao giờ expose management interfaces ra internet hoặc production VLAN. Điều này ngăn attacker đã compromise production network từ pivoting sang management.

3.2. Cloud Security Architecture — Landing Zone Design

AWS Control Tower Landing Zone: Tự động hóa multi-account AWS setup với security baseline. Cấu trúc OU (Organizational Unit): Root OU → Security OU (Log Archive account, Audit account) → Infrastructure OU → Workloads OU (Production, Non-Production). AWS Control Tower enforce Guardrails — preventive guardrails (SCPs ngăn actions không phù hợp) và detective guardrails (AWS Config rules phát hiện drift).

Azure Landing Zone (ALZ): Theo Cloud Adoption Framework (CAF), ALZ gồm: Management Groups hierarchy (Root → Tenant Root Group → Platform → Landing Zones → Sandbox/Decommissioned), Subscriptions theo workload/environment, Policy Assignments ở management group level (ví dụ policy "Require encryption on Storage Accounts" assigned at Landing Zones management group). Security baseline bao gồm: Microsoft Defender for Cloud (plan selection), Azure Policy assignments theo CIS Benchmark, Log Analytics Workspace centralization.

3.3. Hybrid Architecture Security

Site-to-Site VPN: IPSec IKEv2 với AES-256-GCM encryption, SHA-384 integrity, DH Group 20 (ECDH P-384) cho key exchange. Dead Peer Detection (DPD) và Perfect Forward Secrecy (PFS) bắt buộc. Split tunneling phải được đánh giá cẩn thận — thường disable để all traffic đi qua VPN và được inspect.

SD-WAN Security: SD-WAN segmentation dựa trên application-aware routing — security policy theo application identifier thay vì chỉ IP/port. Tích hợp Next-Generation Firewall (NGFW) vào SD-WAN fabric để local breakout traffic được inspect. Zero Trust Network Access (ZTNA) thay thế dần VPN cho remote access — application-specific access thay vì network-level access.

4. Domain 4 — Identity & Access Management Architecture / Kiến trúc IAM

4.1. IAM Architecture Patterns & LDAP Hierarchy Design

Centralized IAM (ví dụ Active Directory, Okta, Azure AD) — single authoritative source cho identity. Ưu điểm: consistent policy enforcement, single audit trail. Nhược điểm: single point of failure (phải có HA design), khó scale cho multi-cloud.

Federated IAM — nhiều IdP tin tưởng lẫn nhau. Mô hình Hub-and-Spoke Federation: một Identity Broker (ví dụ PingFederate, Keycloak) là hub nhận assertions từ nhiều IdP và issue tokens cho nhiều SP — giảm N² federation relationships xuống 2N. LDAP directory hierarchy cho enterprise: dc=company,dc=com → ou=People, ou=Groups, ou=ServiceAccounts, ou=Computers. Naming convention quan trọng — OU structure nên phản ánh administrative boundary, không phải organizational chart (vì org chart thay đổi thường xuyên hơn).

4.2. SSO Federation — SAML 2.0, OAuth 2.1, OIDC Architecture Flows

SAML 2.0 SP-Initiated SSO Flow: (1) User truy cập SP → (2) SP generate AuthnRequest, redirect user đến IdP → (3) IdP authenticate user → (4) IdP generate signed SAML Assertion (XML) → (5) IdP POST Assertion về SP's Assertion Consumer Service (ACS) URL → (6) SP validate signature, extract attributes → (7) SP establish session. Security considerations: Assertion phải signed (RSA-SHA256 minimum), phải validate Recipient và NotOnOrAfter để ngăn replay attack, phải validate InResponseTo cho SP-initiated flow.

OAuth 2.1 + OIDC: OAuth 2.1 (consolidation của OAuth 2.0 RFCs) loại bỏ Implicit Grant và Resource Owner Password Credentials Grant — chỉ giữ Authorization Code (với PKCE bắt buộc) và Client Credentials. OIDC thêm ID Token (JWT chứa user identity claims) lên trên OAuth 2.1. Architecture pattern: BFF (Backend-For-Frontend) — frontend không bao giờ nhận Access Token; thay vào đó Backend-For-Frontend nhận và lưu token, frontend chỉ có session cookie — giảm attack surface cho token theft.

4.3. Privileged Access Management (PAM) Architecture

PAM Vault Architecture: Password vault (ví dụ CyberArk, Delinea, HashiCorp Vault) lưu trữ privileged credentials được mã hóa, automatic rotation, và check-out/check-in workflow. Integration points: LDAP/AD sync để discover accounts, SIEM integration để audit privileged sessions, ticketing system integration để require change ticket trước khi check-out credential.

Just-in-Time (JIT) Access: Không có standing privileged access — accounts chỉ được grant elevated permissions khi cần và tự động revoke sau time window. Implementation: Azure AD PIM (Privileged Identity Management) cho Azure resources; AWS IAM Identity Center (SSO) với time-bound permission sets; CyberArk Conjur cho Kubernetes workload identity.

Session Recording: Tất cả privileged sessions phải được record (keystrokes + screen recording) và lưu trữ tối thiểu 1 năm. Session recording phải được protect khỏi tampering — lưu trên separate system ngoài tầm kiểm soát của privileged user. Playback phải qua authenticated access với audit trail.

4.4. Zero Trust Identity — Continuous Verification & Conditional Access

Device Health Signals: Trong ZTA, identity alone không đủ — device posture phải được kiểm tra liên tục. Signals: OS patch level, EDR agent status, disk encryption enabled, compliance policy status từ MDM (Microsoft Intune, Jamf). Signal được feed vào Conditional Access policies (Azure AD) hoặc Access Context Manager (Google BeyondCorp).

Conditional Access Policy Design: Named Locations, Device Compliance State, User Risk (Azure AD Identity Protection — ML-based), Sign-in Risk được kết hợp để tạo dynamic policy. Ví dụ policy: "Nếu User Risk = High → Block access và require password reset; nếu Sign-in Risk = Medium và accessing sensitive app → require MFA; nếu device not compliant → restrict to limited access only." Architect phải design Conditional Access policies theo principle of "least permissive to achieve business need."

5. Domain 5 — Application Security Architecture / Kiến trúc bảo mật ứng dụng

5.1. Secure SDLC Integration & Security Gates

Security phải được tích hợp vào SDLC từ sớm (shift-left security) không phải scan cuối pipeline. Threat Modeling in Design Phase: Mỗi feature/sprint phải có threat model review trước khi implementation. Security architect review Data Flow Diagrams, identify threats theo STRIDE, và xác định required mitigations. Kết quả ghi vào threat model document và track trong backlog.

Security Gates trong CI/CD: (1) Pre-commit: Secret scanning (git-secrets, truffleHog) ngăn commit credentials. (2) Build stage: SAST (Semgrep, SonarQube, Checkmarx) — fail build nếu có Critical/High severity findings. (3) Test stage: DAST (OWASP ZAP, Burp Suite Enterprise) chạy automated scan. (4) Pre-deploy: SCA/SBOM (Snyk, Trivy) check open source vulnerabilities. (5) Production: RASP (Runtime Application Self-Protection) monitor và block attacks in real-time.

5.2. API Security Architecture

API Gateway Patterns: API Gateway là security enforcement point cho tất cả API traffic. Security functions: Authentication (validate JWT, API Key, mTLS), Rate Limiting (prevent DoS/DDoS), Input Validation (reject malformed requests), Logging & Monitoring, TLS Termination. Internal microservices không expose trực tiếp ra internet — phải qua API Gateway.

mTLS (Mutual TLS): Không chỉ server authenticate đến client — client cũng authenticate đến server bằng client certificate. Trong microservices, mTLS đảm bảo chỉ authorized services có thể call nhau. Service Mesh (Istio) tự động inject Envoy sidecar proxy handle mTLS — developer không cần implement ở application layer.

5.3. Microservices & Container Security Architecture

Service Mesh Security (Istio): Istio Citadel (component của istiod) issue và rotate workload certificates (SPIFFE/SPIRE standard). PeerAuthentication policy enforce mTLS mode (STRICT → tất cả traffic phải mTLS, PERMISSIVE → mixed). AuthorizationPolicy define which service can call which service trên which path/method — zero trust giữa microservices.

Secrets Management (HashiCorp Vault): Vault cung cấp Dynamic Secrets — thay vì static DB password, ứng dụng request temporary credentials từ Vault, Vault tạo account trên DB, return credentials với TTL (ví dụ 1h). Sau TTL, account tự động bị revoke. Vault Agent Injector inject secrets vào Kubernetes pods dưới dạng files — không expose trong environment variables. AppRole authentication cho machine-to-machine, Kubernetes Auth Method cho pod authentication.

OPA (Open Policy Agent) Policies: OPA là general-purpose policy engine — viết policy bằng Rego language. Trong Kubernetes: OPA Gatekeeper enforce admission policies (ví dụ "Không cho phép deploy image không có vulnerability scan"; "Tất cả pods phải có resource limits"). Rego policy được store trong ConfigMap và dynamically loaded — no restart required.

6. Domain 6 — Security Operations Architecture / Kiến trúc vận hành bảo mật

6.1. SOC Architecture — Tiered Model & SIEM/SOAR Integration

Tiered SOC Model: Tier 1 (Alert Triage) — junior analysts monitor dashboard, triage alerts, escalate; Tier 2 (Incident Investigation) — senior analysts investigate, correlate events, contain; Tier 3 (Threat Hunting & Forensics) — expert analysts proactive hunting, malware reverse engineering, forensics. Phân lớp phải được hỗ trợ bởi playbook automation — Tier 1 tasks được SOAR handle phần lớn.

SIEM Architecture: Data collection từ nhiều sources (firewalls, EDR, AD, cloud logs) → Log Aggregation (Logstash, Fluentd) → SIEM Engine (Splunk, Microsoft Sentinel, IBM QRadar) → Correlation Rules & ML-based detection → Alert queue. Log volume management: data tiering — hot (last 30 days, SSD), warm (31-90 days), cold (91+ days, object storage). Tính toán EPS (Events Per Second) để size SIEM license và storage.

SOAR (Security Orchestration, Automation, and Response): SOAR (Palo Alto XSOAR, Splunk SOAR, Microsoft Sentinel Playbooks) tự động hóa repetitive tasks: phishing triage (extract IOCs → check threat intel → auto-contain if malicious), account lockout (verify with HR → auto-unlock if legitimate). Architect phải define human-in-the-loop checkpoints cho actions có risk cao (ví dụ block production firewall rule phải require human approval).

Threat Intelligence Platform (TIP): TIP (ThreatConnect, MISP, Anomali) aggregate threat intel từ nhiều feeds (commercial, ISAC, open source), normalize thành STIX format, enrich với internal context, và distribute sang SIEM/SOAR/Firewall via TAXII. Intel lifecycle: Collection → Processing → Analysis → Dissemination → Feedback.

6.2. Resilience Architecture — BC/DR & Chaos Engineering

RTO/RPO Engineering: RTO (Recovery Time Objective) — thời gian tối đa hệ thống downtime chấp nhận được. RPO (Recovery Point Objective) — lượng data loss tối đa chấp nhận được (tính bằng thời gian). Từ RTO/RPO, architect chọn DR strategy: Backup & Restore (RTO: hours, RPO: hours) → Pilot Light (RTO: minutes, RPO: minutes) → Warm Standby (RTO: minutes, RPO: seconds) → Multi-site Active/Active (RTO: seconds, RPO: near-zero). Mỗi tier có chi phí khác nhau — architect phải justify dựa trên BIA (Business Impact Analysis).

Chaos Engineering for Security: Áp dụng nguyên lý chaos engineering vào security validation: (1) Fault injection — disable security control (ví dụ turn off IPS) và verify detection/alerting hoạt động. (2) Tabletop simulation — simulate attack scenario và measure SOC response time. (3) Purple teaming — Red team và Blue team cùng chạy attack scenario real-time để validate detection capability. Chaos engineering for security không phải về breaking systems — mà về validating resilience of security controls.

7. Bài thực hành / Hands-on labs

Lab 1 — Thiết kế Zero Trust Network Architecture bằng Mermaid

OS: Ubuntu 22.04 · Tool: Mermaid CLI (mmdc). Mục tiêu: Tạo architecture diagram thể hiện ZTA components (PE, PA, PEP) và trust boundaries.

1. Cài đặt Mermaid CLI:

   npm install -g @mermaid-js/mermaid-cli
   mmdc --version

2. Tạo file diagram zta-architecture.mmd:

   graph TB
       subgraph Internet["Internet Zone (Untrusted)"]
           U[👤 Remote User]
           D[💻 Managed Device]
       end
       subgraph ZTA["Zero Trust Control Plane"]
           PE["Policy Engine (PE)\nThreat Intel + CDM"]
           PA["Policy Administrator (PA)"]
           CDP["CDM System\nDevice Health"]
           TI["Threat Intel Platform"]
       end
       subgraph DataPlane["Data Plane"]
           PEP["Policy Enforcement Point\n(ZTNA Gateway)"]
       end
       subgraph Resources["Enterprise Resources (Protected)"]
           APP1[Web App]
           APP2[API Service]
           DB[(Database)]
       end
   
       U -->|"HTTPS + Device Certificate"| PEP
       D -->|"Device Health Signals"| CDP
       CDP --> PE
       TI --> PE
       PE -->|"Grant/Deny Decision"| PA
       PA -->|"Configure Policy"| PEP
       PEP -->|"Authorized Traffic Only"| APP1
       PEP -->|"Authorized Traffic Only"| APP2
       APP1 --> DB
       APP2 --> DB

3. Render diagram thành PNG:

   mmdc -i zta-architecture.mmd -o zta-architecture.png -w 1400 -H 900
   # Xem file
   xdg-open zta-architecture.png

Lab 2 — Xây dựng SABSA Security Architecture Template

OS: Ubuntu 22.04 · Tool: Bash + CSV/Markdown. Mục tiêu: Tạo SABSA matrix template cho tổ chức tài chính với 3 lớp đầu (Contextual, Conceptual, Logical).

1. Tạo SABSA matrix script:

   cat > sabsa-template.sh <<'EOF'
   #!/bin/bash
   OUTPUT="sabsa-financial-org.md"
   
   cat > "$OUTPUT" <<'MARKDOWN'
   # SABSA Security Architecture — Financial Organization
   **Organization:** VN Bank Corp | **Date:** 2026-05-24 | **Architect:** Senior Security Architect
   
   ## Layer 1: Contextual (Business View)
   | Attribute | What (Assets) | Why (Motivation) | How (Process) | Who (People) | Where (Location) | When (Time) |
   |-----------|---------------|------------------|---------------|--------------|-----------------|-------------|
   | **Business** | Customer financial data, transaction records | Protect brand & comply with Thông tư 09/2020 NHNN | Core banking operations | Board, CISO, BU heads | HQ + 100 branches + cloud | 24/7 operations |
   
   ## Layer 2: Conceptual (Architect View)
   | Attribute | What (Assets) | Why (Risk) | How (Controls) | Who (Roles) | Where (Domains) | When (Lifecycle) |
   |-----------|---------------|------------|----------------|-------------|----------------|-----------------|
   | **Security Concepts** | Data classification: PII, Financial records | Fraud, data breach, regulatory fine | Defence-in-depth, Zero Trust | CISO, Security Architects | Internet, DMZ, Internal, Core Banking | Design → Build → Operate → Retire |
   
   ## Layer 3: Logical (Designer View)
   | Attribute | What (Data Models) | Why (Policies) | How (Services) | Who (Identities) | Where (Infrastructure) | When (Events) |
   |-----------|-------------------|----------------|----------------|-----------------|----------------------|---------------|
   | **Security Design** | Data flow diagrams, DLP rules | AUP, Remote Access Policy, Encryption Standard | IAM/PAM, SIEM, WAF, IPS | AD users, Service accounts, PAM vaults | On-prem DC + AWS ap-southeast-1 | Login, Transaction, Incident triggers |
   MARKDOWN
   
   echo "SABSA template created: $OUTPUT"
   wc -l "$OUTPUT"
   EOF
   chmod +x sabsa-template.sh
   bash sabsa-template.sh

2. Xem kết quả:

   cat sabsa-financial-org.md

Lab 3 — Triển khai Azure Landing Zone với Security Controls

OS: Ubuntu 22.04 / Windows 11 · Tool: Azure CLI · Yêu cầu: Azure subscription (Free tier đủ cho lab này).

1. Login Azure và kiểm tra subscription:

   az login
   az account show --query "{Name:name, SubscriptionId:id, State:state}" -o table

2. Tạo Management Group hierarchy:

   # Tạo top-level management group cho Landing Zone
   az account management-group create \
     --name "htlab-platform" \
     --display-name "HoaTranLab Platform MG"
   
   az account management-group create \
     --name "htlab-landingzones" \
     --display-name "HoaTranLab Landing Zones MG"
   
   # Liệt kê management groups
   az account management-group list --query "[].{Name:name, DisplayName:displayName}" -o table

3. Assign built-in Security policy (Azure Security Benchmark):

   # Lấy subscription ID
   SUB_ID=$(az account show --query id -o tsv)
   
   # Assign Azure Security Benchmark initiative
   az policy assignment create \
     --name "AzureSecurityBenchmark" \
     --display-name "Azure Security Benchmark - Phase 6 Lab" \
     --policy-set-definition "1f3afdf9-d0c9-4c3d-847f-89da613e70a8" \
     --scope "/subscriptions/$SUB_ID"
   
   # Verify assignment
   az policy assignment list --scope "/subscriptions/$SUB_ID" \
     --query "[].{Name:name, DisplayName:displayName}" -o table

4. Enable Microsoft Defender for Cloud (Free tier):

   # Enable Defender for Cloud - Free tier cho Servers
   az security pricing create \
     --name "VirtualMachines" \
     --tier "Free"
   
   # Xem security score
   az security secure-score-controls list \
     --query "[0:5].{Name:displayName, Score:score.current}" -o table

Lab 4 — Thiết kế IAM Conditional Access với PowerShell + Azure AD

OS: Windows 11 / Ubuntu 22.04 · Tool: PowerShell 7 + Microsoft.Graph module · Yêu cầu: Azure AD (Microsoft Entra ID) tenant, quyền Global Admin hoặc Conditional Access Admin.

1. Cài đặt và connect Microsoft Graph:

   # Cài module
   Install-Module Microsoft.Graph -Scope CurrentUser -Force
   
   # Connect với scope cần thiết
   Connect-MgGraph -Scopes "Policy.Read.All", "Policy.ReadWrite.ConditionalAccess", "Application.Read.All"
   
   # Kiểm tra connection
   Get-MgContext | Select-Object Account, TenantId, Scopes

2. Xem các Conditional Access policies hiện tại:

   # List tất cả CA policies và trạng thái
   $policies = Get-MgIdentityConditionalAccessPolicy
   $policies | Select-Object DisplayName, State, CreatedDateTime | Format-Table -AutoSize
   
   # Xem chi tiết một policy (nếu có)
   if ($policies) {
       $p = $policies[0]
       Write-Host "Policy: $($p.DisplayName)"
       Write-Host "Conditions - Users: $($p.Conditions.Users | ConvertTo-Json -Depth 2)"
   }

3. Tạo Conditional Access policy mẫu (Report-Only mode — an toàn, không block):

   $params = @{
       DisplayName = "Phase6-Lab: Require MFA for Admins"
       State = "enabledForReportingButNotEnforced"  # Report-Only mode
       Conditions = @{
           Users = @{
               IncludeRoles = @("62e90394-69f5-4237-9190-012177145e10")  # Global Admin role ID
           }
           Applications = @{
               IncludeApplications = @("All")
           }
       }
       GrantControls = @{
           Operator = "OR"
           BuiltInControls = @("mfa")
       }
   }
   $newPolicy = New-MgIdentityConditionalAccessPolicy -BodyParameter $params
   Write-Host "Created policy: $($newPolicy.DisplayName) [ID: $($newPolicy.Id)]"

8. Tình huống doanh nghiệp / Real-world scenario

9. Tự kiểm tra / Knowledge check

1. SABSA có mấy lớp (layers) và mấy chiều (attributes)? Lớp nào là entry point khi bắt đầu một security architecture engagement?
2. NIST SP 800-207 định nghĩa 3 logical components của ZTA — hãy mô tả vai trò của Policy Engine, Policy Administrator, và Policy Enforcement Point. Policy nào được thực thi bởi PEP?
3. Phân biệt SAML 2.0 SP-Initiated SSO và IdP-Initiated SSO. Tại sao IdP-Initiated flow có nguy cơ bảo mật cao hơn và làm thế nào để mitigate?
4. Trong thiết kế PAM, tại sao "Just-in-Time access" được coi là superior hơn "standing privileged access" từ góc nhìn Zero Trust? Enumerate ít nhất 3 security benefits cụ thể.
5. Một tổ chức có RTO = 15 phút và RPO = 5 phút cho core banking system. DR strategy nào phù hợp nhất (Backup/Restore, Pilot Light, Warm Standby, hay Multi-site Active/Active)? Justify và estimate cost trade-off.
6. OPA Gatekeeper trong Kubernetes enforce policy ở admission webhook — giải thích cơ chế này và cho ví dụ một Rego policy ngăn deploy container với privileged: true.
7. Trong SIEM architecture, phân biệt giữa "correlation rule" và "ML-based behavioral detection". Loại nào phù hợp cho known threat patterns và loại nào cho unknown/zero-day threats?