Vietnamese Professional - CLOUD COMPUTING

Vietnamese Professional - CLOUD COMPUTING https://www.forum.vnpro.org/ vi Thu, 23 Apr 2026 04:06:55 GMT vBulletin 60 images/misc/rss.png Vietnamese Professional - CLOUD COMPUTING https://www.forum.vnpro.org/ SPF và DKIM https://www.forum.vnpro.org/forum/cloud-computing/mcsa/439713-spf-và-dkim Wed, 22 Apr 2026 13:37:05 GMT SPF và DKIM — Hai Trụ Cột Xác Thực Email Hiện Đại. Khi nói đến bảo mật email hiện đại, chỉ lọc spam hay quét malware là chưa đủ. Một trong những... SPF và DKIM — Hai Trụ Cột Xác Thực Email Hiện Đại.

Khi nói đến bảo mật email hiện đại, chỉ lọc spam hay quét malware là chưa đủ. Một trong những thách thức lớn nhất hiện nay là email spoofing — giả mạo địa chỉ người gửi để phục vụ phishing, BEC (Business Email Compromise) hoặc lừa đảo.

Đó là lý do các cơ chế xác thực email như SPF và DKIM trở thành nền tảng trong kiến trúc Email Security, đồng thời là thành phần quan trọng trong Cisco Secure Email.

1. Sender Policy Framework (SPF)

SPF là gì?

SPF (Sender Policy Framework) là tiêu chuẩn công nghiệp được định nghĩa trong RFC 4408, cho phép máy chủ nhận email xác minh xem địa chỉ IP gửi mail có được phép gửi thay mặt cho domain đó hay không.

Hiểu đơn giản:

SPF giúp trả lời câu hỏi:

Máy chủ này có được quyền gửi email cho domain này không?

SPF hoạt động thế nào?

SPF sử dụng DNS TXT Records để công bố danh sách các mail gateway hợp lệ.

Ví dụ:
example.com TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com -all"

Giải thích:

v=spf1 → phiên bản SPF
ip4:192.0.2.10 → IP được phép gửi mail
include:_spf.google.com → cho phép mail server của Google
-all → từ chối tất cả nguồn khác

Luồng kiểm tra SPF

Khi email đến:

Recipient mail gateway nhận kết nối SMTP
Kiểm tra địa chỉ IP nguồn
Tra cứu DNS TXT SPF record của domain người gửi
So sánh IP gửi thực tế với IP được phép
Pass hoặc Fail

Cisco Secure Email hỗ trợ SPF ra sao?

Cisco Secure Email có thể dùng SPF để xác minh:

HELO/EHLO identity
MAIL FROM identity
FQDN của sender

Đây là hai điểm rất quan trọng trong SMTP transaction:
HELO mail.attacker.com
MAIL FROM: ceo@company.com

Nếu IP gửi không thuộc SPF của company.com → nghi ngờ spoofing.

Cisco Secure Email thêm intelligence vào header

Khi bật SPF, Cisco Secure Email có thể thêm header:
Received-SPF: Pass
Authentication-Results: spf=pass

Hoặc:
spf=fail

Điều này rất hữu ích cho:

Threat hunting
Mail forensics
SIEM correlation
Incident response

Điểm yếu của SPF

SPF không hoàn hảo. 1. Phụ thuộc mức độ tham gia

Nếu domain không publish SPF → không kiểm tra được.

2. SPF phải cập nhật liên tục

Nếu thay đổi mail provider mà quên sửa SPF:

Legitimate mail có thể fail
Hoặc lỗ hổng mở ra cho spoofing

3. SPF có thể vỡ khi forwarding

Mail forward qua bên thứ ba có thể làm IP nguồn thay đổi, gây SPF fail.

Đây là lý do SPF thường kết hợp với DKIM và DMARC.

2. DomainKeys Identified Mail (DKIM)

DKIM là gì?

DKIM (DomainKeys Identified Mail) là tiêu chuẩn định nghĩa trong RFC 5585.

Khác SPF xác minh nguồn gửi, DKIM xác minh:

Tính toàn vẹn nội dung
Tính xác thực domain ký email

Nó trả lời:

Email này có thật do domain đó phát hành và chưa bị sửa đổi không?

DKIM hoạt động ra sao?

DKIM dùng chữ ký số.

Mail gateway outbound ký email bằng private key.

Ví dụ header:
DKIM-Signature:
v=1;
d=example.com;
s=selector1;
bh=base64hash;
b=signaturedata

Recipient kiểm tra như thế nào?

Mail receiver:

Đọc DKIM header
Lấy selector:

s=selector1

Tra DNS TXT:

selector1._domainkey.example.com

Lấy public key
Verify chữ ký

DNS TXT chứa public key

Ví dụ:
selector1._domainkey.example.com

TXT "v=DKIM1; p=MIGfMA0GCSq..."

p= là public key.

Nếu nội dung bị sửa?

Nếu ai đó sửa:

Body
Subject
Một số header

Hash không khớp → DKIM fail.

SPF vs DKIM khác nhau gì?

Nhiều kỹ sư mới học thường nhầm hai thứ này.

SPF xác minh:

Ai được quyền gửi

DKIM xác minh:

Email có bị chỉnh sửa không

Một cái kiểm tra source authenticity

Một cái kiểm tra message integrity

Hai thứ bổ sung cho nhau.

Tại sao SPF + DKIM cực quan trọng cho chống Phishing?

Giả sử attacker gửi:
From: ceo@company.com

Nhưng:

IP không hợp lệ → SPF fail

Hoặc

Không có chữ ký đúng → DKIM fail

Mail gateway có thể:

Quarantine
Reject
Tăng spam score
Kích hoạt anti-phishing policy

Vai trò trong Cisco Secure Email

Cisco Secure Email dùng SPF/DKIM để:

Anti-spoofing enforcement
Reputation scoring
Mail policy decisions
DMARC evaluation
Header intelligence enrichment

Đây không chỉ là “check box feature”.

Đây là nền tảng trust model của email security.

Thực chiến: SPF + DKIM + DMARC

Trong thực tế nên luôn triển khai bộ ba:

SPF → xác minh nguồn gửi
DKIM → xác minh chữ ký và integrity
DMARC → chính sách xử lý nếu fail

Ba thứ này thường được gọi là:

Email Authentication Trinity

Một ví dụ DMARC policy

_dmarc.example.com TXT

"v=DMARC1; p=reject"

Nếu SPF hoặc DKIM fail:

→ reject mail.

Đây là mức chống spoofing mạnh nhất.

Góc nhìn Security Architecture

Từ góc nhìn CISSP / CCSP:

SPF cung cấp:

Source validation

DKIM cung cấp:

Message integrity
Non-repudiation (ở mức logic)

DMARC cung cấp:

Policy enforcement

Đây là defense-in-depth cho email.

Kết luận

Nếu không có SPF và DKIM:

Domain dễ bị spoof
Phishing detection yếu
BEC risk tăng mạnh

Đó là lý do hầu hết các nhà cung cấp lớn hiện nay:

Microsoft 365
Google Workspace
Cisco Secure Email

đều xem SPF/DKIM gần như bắt buộc.

Email security ngày nay không chỉ là lọc spam.

Mà là xây dựng trust architecture for messaging.
]]> MCSA dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/mcsa/439713-spf-và-dkim Hành trình hiện đại hóa Identity Management diễn ra như thế nào? https://www.forum.vnpro.org/forum/cloud-computing/azure/439708-hành-trình-hiện-đại-hóa-identity-management-diễn-ra-như-thế-nào Wed, 22 Apr 2026 10:30:59 GMT Từ Active Directory đến Microsoft Entra ID: Hành trình hiện đại hóa Identity Management diễn ra như thế nào? Rất nhiều doanh nghiệp đang hỏi: Có... Từ Active Directory đến Microsoft Entra ID: Hành trình hiện đại hóa Identity Management diễn ra như thế nào?

Rất nhiều doanh nghiệp đang hỏi: Có thể “di cư” hoàn toàn từ Active Directory (AD) on-premise lên Microsoft Entra ID (Azure AD trước đây) không?
Câu trả lời là có, nhưng thường không phải kiểu “big bang migration”, mà là một lộ trình nhiều giai đoạn, đúng như góc nhìn Microsoft mô tả trong hình này.

Đây không đơn thuần là migrate directory, mà là chuyển dịch mô hình quản trị danh tính (Identity Operating Model). Giai đoạn 1 — AD vẫn là nguồn quyền lực chính (Authoritative Source)

Ban đầu, mọi hoạt động quản trị định danh CRUD đều diễn ra trong Active Directory:

Create user
Read / tra cứu đối tượng
Update thuộc tính, nhóm, policy
Delete / deprovision tài khoản

AD on-prem đóng vai trò source of truth.

Microsoft Entra Connect (trước đây Azure AD Connect) chỉ làm nhiệm vụ đồng bộ:

User objects
Groups
Password Hash Sync / Pass-through Authentication
Hybrid Identity federation nếu dùng ADFS

Ở giai đoạn này:

Identity vẫn “on-prem first”
Cloud chủ yếu là phần mở rộng (extension)
Mô hình phổ biến là Hybrid Identity

Đây là trạng thái của rất nhiều enterprise hiện nay.

Giai đoạn 2 — Chuyển CRUD sang Entra ID

Đây là bước quan trọng nhất.

Doanh nghiệp bắt đầu dịch chuyển tác vụ quản trị danh tính sang cloud:

Provision user trực tiếp trên Entra ID
Quản trị lifecycle trên cloud
Dùng Conditional Access thay GPO cho nhiều use case hiện đại
Chuyển authentication từ Kerberos/NTLM sang SAML, OIDC, OAuth
Áp dụng Zero Trust access model

Lúc này AD vẫn còn tồn tại, nhưng thường chỉ phục vụ:

Legacy applications
Legacy LDAP dependencies
Kerberos constrained workloads
Domain-joined systems cũ

Điểm đáng chú ý trong hình:

Có những user chỉ tồn tại trên cloud và không còn hiện diện on-prem.

Đây là bước chuyển từ:

Hybrid Directory
sang
Cloud-first Identity

Thường giai đoạn này sẽ đi kèm các dịch vụ:

Microsoft Entra ID Governance
Privileged Identity Management (PIM)
Passwordless (FIDO2, Windows Hello, Passkeys)
Identity Protection
SCIM provisioning cho SaaS apps

Lúc này Identity bắt đầu giống một control plane hiện đại.

Giai đoạn 3 — Không còn Active Directory on-prem

Đây là trạng thái “cloud-native identity”.

Không còn Domain Controller on-prem.

Entra ID trở thành hệ thống danh tính chính thức cho:

Authentication
Authorization
Policy
Governance
Lifecycle management

AD biến mất.

Điều này chỉ khả thi khi đã xử lý hết:

Legacy applications phụ thuộc LDAP/Kerberos
Domain Join truyền thống
GPO dependencies
File shares / legacy SMB auth
Service accounts cũ

Thông thường đi kèm:

Entra Joined devices
Intune thay Group Policy
SaaS-first application model
Zero Trust architecture trưởng thành

Đây thực ra là lộ trình “Identity Modernization”

Nhiều người nghĩ đây chỉ là migrate directory.

Thực chất đây là chuyển dịch:

Từ Perimeter Security → Zero Trust
Từ On-prem IAM → Cloud IAM
Từ Domain-centric → Identity-centric Security

Identity trở thành security control plane.

Góc nhìn kiến trúc đáng lưu ý

Mô hình này giống cách nhiều tổ chức đang làm:

Step 1
AD-centric Hybrid

Step 2
Entra-centric Hybrid

Step 3
Cloud-native Identity

Không nhảy thẳng Step 1 → Step 3.

Phần lớn enterprise đi qua Step 2 trong nhiều năm.

Đây cũng là xu hướng DevSecOps cần quan tâm

Khi Identity dịch chuyển lên cloud, automation cũng thay đổi:

Terraform quản trị Entra objects
Microsoft Graph API cho identity automation
Policy as Code cho Conditional Access
CI/CD cho IAM changes
JIT / PIM workflows tự động hóa

Identity bắt đầu được quản lý như code.

Đó chính là hướng của Identity as Code (IaC cho IAM).

Một câu đáng suy nghĩ

“Cloud migration” nhiều khi không bắt đầu từ server hay network…

…mà bắt đầu từ identity.

Và trong rất nhiều kiến trúc Zero Trust, Identity chính là perimeter mới.
]]> AZURE dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/azure/439708-hành-trình-hiện-đại-hóa-identity-management-diễn-ra-như-thế-nào 4 giao thức dùng trong xác định danh tính https://www.forum.vnpro.org/forum/cloud-computing/mcsa/439703-4-giao-thức-dùng-trong-xác-định-danh-tính Tue, 21 Apr 2026 13:45:49 GMT Trong các hệ thống hiện đại, đặc biệt là môi trường Cloud như Azure, AWS hay các kiến trúc SaaS, việc quản lý danh tính (Identity Management) không...
Bốn giao thức quan trọng mà bất kỳ kỹ sư hệ thống hoặc cloud nào cũng cần nắm vững bao gồm: SAML, OAuth, SCIM và OpenID Connect.

1. SAML – Nền tảng cho Single Sign-On (SSO)

SAML là một trong những giao thức lâu đời nhưng vẫn rất phổ biến trong doanh nghiệp.

Về bản chất, SAML cho phép truyền thông tin xác thực giữa:

Identity Provider (IdP) – ví dụ: Azure AD
Service Provider (SP) – ví dụ: Salesforce, AWS Console

Khi user đăng nhập một lần (SSO), IdP sẽ gửi một “assertion” (chứng thực) đến SP để xác nhận danh tính.

Ứng dụng thực tế:

Đăng nhập một lần vào nhiều ứng dụng SaaS
Tích hợp Azure AD với các ứng dụng doanh nghiệp

2. OAuth – Chuẩn ủy quyền hiện đại

OAuth không dùng để xác thực user, mà dùng để ủy quyền truy cập tài nguyên.

Ví dụ:
Bạn đăng nhập vào một ứng dụng bằng Google, và ứng dụng đó xin quyền đọc email → đây là OAuth.

OAuth hoạt động dựa trên:

Access Token
Authorization Server
Resource Server

Ứng dụng thực tế:

API security
Microservices
Mobile App / Web App truy cập backend

3. OpenID Connect – Xác thực trên nền OAuth

OAuth chỉ xử lý “quyền truy cập”, nhưng không xác định rõ “user là ai”.

OpenID Connect (OIDC) giải quyết vấn đề đó bằng cách:

Thêm ID Token (JWT)
Cung cấp thông tin user (claims)

Hiểu đơn giản:

OAuth = “Bạn được phép làm gì”
OpenID Connect = “Bạn là ai”

Ứng dụng thực tế:

Login bằng Google / Microsoft / Facebook
Azure AD Authentication cho ứng dụng web

4. SCIM – Tự động hóa quản lý user

SCIM là giao thức ít được nhắc đến hơn, nhưng cực kỳ quan trọng trong doanh nghiệp.

SCIM giúp:

Tự động tạo user (provisioning)
Đồng bộ user giữa các hệ thống
Xóa user khi nghỉ việc (deprovisioning)

Ví dụ:

Khi tạo user trong Azure AD → tự động tạo tài khoản trong Salesforce
Khi disable user → tự động revoke access

Góc nhìn thực tế cho Cloud Engineer

Trong Azure:

SAML / OIDC dùng cho SSO
OAuth / OIDC dùng cho API và App authentication
SCIM dùng cho provisioning user vào SaaS

Trong AWS:

SAML dùng để federate login vào AWS Console
OIDC dùng cho workload identity (EKS, IAM roles)

Kết luận

Nếu bạn đang làm hệ thống, cloud, hoặc security, thì hiểu rõ 4 giao thức này là nền tảng bắt buộc:

SAML → SSO truyền thống
OAuth → Ủy quyền API
OpenID Connect → Xác thực hiện đại
SCIM → Tự động hóa quản lý danh tính

Đây chính là “xương sống” của các hệ thống Identity trong kỷ nguyên Cloud và Zero Trust.

Nếu bạn đang học Azure, AWS hoặc chuẩn bị thi các chứng chỉ như AZ-104, AZ-500, SC-300… thì đây là nhóm kiến thức cần nắm rất chắc.
]]> MCSA dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/mcsa/439703-4-giao-thức-dùng-trong-xác-định-danh-tính Container là gì? https://www.forum.vnpro.org/forum/cloud-computing/azure/439665-container-là-gì Sun, 19 Apr 2026 02:03:38 GMT 1. Container là gì? Container là một môi trường cô lập (isolated environment) nơi các ứng dụng được đóng gói và chạy. Bên trong container sẽ bao... 1. Container là gì?

Container là một môi trường cô lập (isolated environment) nơi các ứng dụng được đóng gói và chạy. Bên trong container sẽ bao gồm:

Application (ứng dụng)
Dependencies (các thư viện, binary cần thiết để chạy)

Nghe qua thì khá giống với Virtual Machine (VM), nhưng có một điểm quan trọng:

👉 Container KHÔNG phải là “lightweight VM”
Đây là một hiểu lầm rất phổ biến trong cộng đồng IT.

2. So sánh kiến trúc: VM vs Container

Virtual Machine (VM)

VM hoạt động như một server ảo hoàn chỉnh:

Mỗi VM có:
- Guest OS riêng (Linux, Windows…)
- Libraries, binaries đầy đủ
- Application
Chạy trên:
- Hypervisor (Type 1 hoặc Type 2)
- Hardware vật lý

👉 Tức là mỗi VM giống như một máy chủ độc lập thu nhỏ

Nhược điểm:

Nặng (vì có OS riêng)
Tốn tài nguyên (CPU, RAM, storage)
Startup chậm (thường vài phút)

Container

Container có cách tiếp cận hoàn toàn khác:

KHÔNG có Guest OS
Tất cả container:
- Chia sẻ kernel của host OS
Mỗi container chỉ chứa:
- Application
- Dependencies cần thiết (bin/libs)

👉 Container không ảo hóa cả server → chỉ trừu tượng hóa ứng dụng

Ưu điểm:

Nhẹ (small footprint)
Khởi động nhanh (vài giây)
Scale cực nhanh (rất phù hợp cloud & microservices)

3. Container Image – nền tảng của container

Container không tự nhiên sinh ra, nó được tạo từ:

👉 Container Image

Container Image là một file chứa:

Application code
Thư viện (libraries)
Binary dependencies

Khi chạy bằng container engine (ví dụ Docker), image → trở thành container. Điểm cực kỳ quan trọng:

✔ Image chứa tất cả những gì ứng dụng cần để chạy
✔ Không phụ thuộc môi trường bên ngoài

👉 Điều này giải quyết triệt để vấn đề kinh điển:

“Chạy trên máy dev OK, lên production lỗi”
“Thiếu library”
“Version conflict”

4. Tính portable – sức mạnh thực sự của container

Vì container image đóng gói đầy đủ môi trường:

👉 Bạn có thể chạy container ở bất kỳ đâu:

Laptop dev
Data Center
Cloud (AWS, Azure, GCP)
Kubernetes cluster

💡 Ví dụ thực tế:

Bạn build một container chạy Python app với:

Python 3.11
Flask
Specific library version

→ Đem container đó deploy sang server khác → vẫn chạy y chang
→ Không cần cài lại Python, không lo lệch version

5. Khác biệt lớn về thời gian khởi động

Đây là điểm cực kỳ quan trọng trong thực tế vận hành: VM:

Boot OS → Load services → Start application
⏱ Mất: vài phút

Container:

Dùng luôn kernel của host OS
Chỉ cần start process của app
⏱ Mất: vài giây

👉 Vì vậy:

Container rất phù hợp cho:
- Auto scaling
- Microservices
- CI/CD pipeline

6. Container Engine – “bộ não” vận hành container

Để chạy container, cần có container engine.

Phổ biến nhất:

Docker Engine (de facto standard)

Ngoài ra còn có:

rkt (rocket)
Open Container Initiative (OCI)
LXD (Canonical)
Linux-VServer
Windows Containers

7. Góc nhìn CCIE / Architect: Khi nào dùng VM, khi nào dùng Container?

Dùng VM khi:

Cần full OS isolation
Chạy legacy applications
Yêu cầu bảo mật ở mức OS-level isolation mạnh

Dùng Container khi:

Microservices architecture
DevOps / CI-CD
Cloud-native application
Scale nhanh, deploy nhanh

8. Tóm lại (rất quan trọng)

👉 VM = Virtualize entire server
👉 Container = Abstract application

👉 VM:

Nặng
Chậm
Isolation mạnh

👉 Container:

Nhẹ
Nhanh
Portable

9. Một cách hiểu cực dễ nhớ

VM = mỗi app một “máy tính riêng”
Container = nhiều app dùng chung “hệ điều hành”, nhưng vẫn cách ly

Nếu bạn đang đi theo hướng:

Cloud
DevOps
Kubernetes
AI Infrastructure

👉 Hiểu đúng container vs VM là nền tảng bắt buộc.
]]> AZURE dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/azure/439665-container-là-gì Di chuyển máy ảo (VM Mobility) https://www.forum.vnpro.org/forum/cloud-computing/mcsa/439663-di-chuyển-máy-ảo-vm-mobility Sun, 19 Apr 2026 01:50:52 GMT Một trong những giá trị cốt lõi nhất của ảo hóa (Virtualization) – và cũng là lý do khiến Cloud phát triển mạnh mẽ – chính là khả năng di chuyển máy... di chuyển máy ảo (VM Mobility).

Trước đây, trong mô hình hạ tầng truyền thống (bare-metal), ứng dụng gắn chặt với phần cứng. Khi server cần bảo trì hoặc gặp sự cố, downtime gần như là không tránh khỏi.

Nhưng với VM, mọi thứ thay đổi hoàn toàn.

1. Live Migration – “di chuyển không gián đoạn”

Các nền tảng như VMware vSphere, Microsoft Hyper-V, hay KVM đều hỗ trợ kỹ thuật live migration:

VM đang chạy vẫn tiếp tục xử lý workload
Bộ nhớ (RAM), trạng thái CPU, session… được chuyển sang host khác
Người dùng và ứng dụng gần như không nhận ra sự thay đổi

Trong môi trường Azure hay AWS, cơ chế này được abstract hóa và vận hành tự động bên dưới, giúp Cloud đạt được SLA rất cao.

2. Bảo trì hạ tầng không downtime

Một use case rất thực tế:

Bạn cần nâng cấp RAM cho một host
Hoặc patch hệ điều hành hypervisor

Trong môi trường truyền thống: phải tắt server → downtime

Trong môi trường ảo hóa:

Migrate toàn bộ VM sang host khác
Thực hiện bảo trì
Sau đó migrate VM trở lại

Toàn bộ quá trình gần như zero downtime

3. High Availability (HA) – nền tảng của Cloud

Một trong những lợi ích quan trọng nhất:

Nếu một host bị lỗi (hardware failure, power failure…)
Hệ thống HA sẽ tự động restart VM trên host khác

Trong các hệ thống lớn:

VMware HA / DRS
Hyper-V Failover Cluster
Azure Availability Set / Availability Zone
AWS Auto Recovery / EC2 placement group

Điểm chung là:
Workload không còn phụ thuộc vào một server duy nhất

4. Tư duy thiết kế hệ thống hiện đại

Khi làm việc với Cloud hoặc Data Center hiện đại, cần thay đổi mindset:

Không còn “server-centric”
Mà là “workload-centric”

Điều quan trọng không phải là server sống hay chết, mà là:

Ứng dụng có còn chạy không?
Dịch vụ có còn sẵn sàng không?

VM migration + HA chính là nền tảng để xây dựng:

Zero downtime architecture
Fault-tolerant systems
Cloud-native design

Kết luận

VM không chỉ giúp tối ưu tài nguyên, mà còn mở ra một khả năng cực kỳ quan trọng:

Tách rời ứng dụng khỏi phần cứng

Chính điều này là nền tảng cho:

High Availability
Disaster Recovery
Cloud Computing

]]> MCSA dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/mcsa/439663-di-chuyển-máy-ảo-vm-mobility Cloud có thay thế kỹ sư mạng không? https://www.forum.vnpro.org/forum/cloud-computing/aws/439652-cloud-có-thay-thế-kỹ-sư-mạng-không Sat, 18 Apr 2026 12:41:30 GMT Cloud có thay thế Network Engineer không? Hay là cơ hội lớn nhất của nghề mạng? Đây là một trong những hiểu lầm phổ biến nhất khi doanh nghiệp... Cloud có thay thế Network Engineer không? Hay là cơ hội lớn nhất của nghề mạng?

Đây là một trong những hiểu lầm phổ biến nhất khi doanh nghiệp chuyển lên cloud.

Rất nhiều người nghĩ rằng:
“Lên cloud rồi thì đâu còn cần network engineer nữa, vì AWS/Azure đã lo hết rồi.”

Thực tế:
Cloud không loại bỏ network engineer.
Cloud làm cho network engineer trở nên quan trọng hơn.

1. CSP chỉ quản lý phần “physical”, không quản lý “design”

Đúng là trên cloud, bạn không còn phải:

Đi dây mạng
Cấu hình switch vật lý
Nâng cấp firmware thiết bị

Nhưng cái CSP không làm thay bạn là:

Thiết kế kiến trúc mạng (architecture)
Phân chia subnet, VNet, VPC
Kiểm soát routing, security, segmentation
Đảm bảo performance và troubleshooting

Nói cách khác:
Cloud loại bỏ “manual work”, nhưng giữ lại toàn bộ “brain work”.

2. Những kiến thức network cốt lõi vẫn giữ nguyên

Dù bạn dùng Azure, AWS hay on-prem, các thứ sau vẫn không thay đổi:

DNS: sai 1 record có thể làm sập cả hệ thống
IP Planning: thiết kế sai CIDR là “toang từ đầu”
Routing (BGP): backbone của hybrid/multi-cloud
Troubleshooting: user chậm → luôn bị đổ lỗi cho network

Cloud không thay thế các kiến thức này.
Cloud yêu cầu bạn hiểu sâu hơn.

3. Network Engineer trong cloud = làm việc ở quy mô lớn hơn

So sánh đơn giản:

On-prem: cấu hình mạng cho 1 building
Cloud: thiết kế mạng cho nhiều region, nhiều quốc gia

Cùng 1 skillset, nhưng:

Impact lớn hơn
Scale lớn hơn
Giá trị mang lại cho doanh nghiệp cao hơn

Đây chính là điểm khác biệt lớn nhất.

4. Cloud là “career leverage” cho Network Engineer

Cloud giúp bạn:

Từ Network Engineer → Cloud Network Architect
Từ cấu hình thiết bị → thiết kế hệ thống
Từ local network → global infrastructure

Nếu đi đúng hướng, bạn không bị thay thế.
Bạn được “nâng cấp”.

5. Góc nhìn thực tế cho anh em đang học Azure / AWS

Nếu bạn đang:

Học AZ-104, AZ-700
Làm CCNA/CCNP
Hoặc đang làm sysadmin/network

Thì nên hiểu rõ:

Cloud Networking không phải là “optional skill”
Nó là “core skill” trong 5–10 năm tới.

Kết luận

Cloud không giết nghề network.
Cloud chọn lọc lại network engineer.

Người chỉ biết cấu hình → sẽ gặp khó khăn
Người hiểu design, routing, system → sẽ phát triển rất nhanh

Nếu bạn đang làm networking, đây không phải là thời điểm lo lắng.
Đây là thời điểm để nâng cấp bản thân.
]]> AWS dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/aws/439652-cloud-có-thay-thế-kỹ-sư-mạng-không 🚨 Một sự thật “ngược đời” trong IT: Làm quá giỏi… có thể khiến bạn KHÔNG được thăng tiến https://www.forum.vnpro.org/forum/cloud-computing/aws/439639-🚨-một-sự-thật-“ngược-đời”-trong-it-làm-quá-giỏi…-có-thể-khiến-bạn-không-được-thăng-tiến Fri, 17 Apr 2026 12:12:06 GMT 🚨 Một sự thật “ngược đời” trong IT: Làm quá giỏi… có thể khiến bạn KHÔNG được thăng tiến Nghe có vẻ sai sai, nhưng nếu bạn đang: ✔ Là người xử lý... Một sự thật “ngược đời” trong IT: Làm quá giỏi… có thể khiến bạn KHÔNG được thăng tiến

Nghe có vẻ sai sai, nhưng nếu bạn đang:
✔ Là người xử lý mọi vấn đề khó nhất
✔ Là “key person” không thể thay thế
✔ Luôn được giao thêm việc vì làm quá tốt

… thì rất có thể bạn đang rơi vào “bẫy hiệu suất cao”.

❗ Vì sao điều này xảy ra?

1. Bạn bị “đóng khung” bởi kỹ năng quá chuyên biệt

Bạn giỏi một hệ thống nội bộ, một tool đặc thù… nhưng ra ngoài thị trường thì ít nơi dùng.
➡️ Kết quả: khó chuyển job, khó tăng lương.

2. Công ty không có đường thăng tiến

Team nhỏ → không có vị trí cao hơn
Sếp không hiểu kỹ thuật → không đánh giá đúng
Hoặc đơn giản: muốn giữ bạn ở vị trí hiện tại

➡️ Bạn càng giỏi → càng bị “giữ lại”

3. Làm tốt = bị giao thêm việc

Không phải lúc nào cũng là:
👉 Làm tốt → thăng chức

Mà nhiều khi là:
👉 Làm tốt → việc nhiều hơn → không còn thời gian phát triển

4. Bạn trở thành “người không thể thay thế”

Nghe có vẻ tốt… nhưng thực ra rất nguy hiểm.

➡️ Vì nếu bạn rời đi, hệ thống có thể “toang”
➡️ Nên công ty sẽ KHÔNG muốn bạn lên vị trí khác

5. Bạn giỏi kỹ thuật… nhưng thiếu kỹ năng lãnh đạo

Từ Engineer → Lead → Manager là một bước chuyển hoàn toàn khác:

Ít code hơn
Nhiều giao tiếp hơn
Nhiều quyết định hơn

➡️ Nếu không chuẩn bị sớm, bạn sẽ bị “kẹt” ở technical role

🎯 Vậy phải làm gì?

✔ Đừng chỉ giỏi việc hiện tại → hãy giỏi “việc tiếp theo”
✔ Luôn học kỹ năng có thể transfer (networking, automation, cloud, AI…)
✔ Chủ động hỏi về career path (đừng chờ công ty vẽ sẵn)
✔ Xây dựng network bên ngoài
✔ Và đôi khi… phải dám rời đi

🔥 Góc nhìn thực tế

Trong IT, vấn đề không phải là bạn giỏi hay không.
👉 Mà là bạn đang giỏi cái gì
👉 Và nó có giúp bạn đi xa hơn hay không]]> AWS dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/aws/439639-🚨-một-sự-thật-“ngược-đời”-trong-it-làm-quá-giỏi…-có-thể-khiến-bạn-không-được-thăng-tiến Group trong Azure AD https://www.forum.vnpro.org/forum/cloud-computing/azure/439600-group-trong-azure-ad Thu, 16 Apr 2026 11:27:33 GMT Trong Azure Active Directory (Azure AD), Group (nhóm) là một trong những thành phần quan trọng nhất để quản lý người dùng, quyền truy cập và tài... Trong Azure Active Directory (Azure AD), Group (nhóm) là một trong những thành phần quan trọng nhất để quản lý người dùng, quyền truy cập và tài nguyên một cách hiệu quả. Nếu bạn đang làm việc trong môi trường Cloud hoặc chuẩn bị thi các chứng chỉ như AZ-900, AZ-104 thì đây là kiến thức nền tảng bắt buộc phải nắm.

1. Tại sao cần sử dụng Group trong Azure AD?

Trong thực tế doanh nghiệp, bạn không thể:

Gán quyền từng user cho từng tài nguyên
Quản lý hàng trăm hoặc hàng ngàn user thủ công

Thay vào đó, mô hình chuẩn là:

Gán quyền cho Group
Thêm user vào Group

Ví dụ:

Nhóm Virtual Machine Administrators → có quyền quản lý VM
Nhóm Virtual Network Administrators → có quyền quản lý VNet

Khi có nhân viên mới:

Chỉ cần add vào Group tương ứng → tự động có quyền

Đây chính là nguyên tắc:
Role-Based Access Control (RBAC) + Group-based management

2. Các loại Group trong Azure AD

Security Group

Dùng để:

Gán quyền truy cập tài nguyên (VM, Storage, Network…)
Áp dụng policy (Conditional Access, Intune…)

Đây là loại dùng nhiều nhất trong hệ thống IT.

Microsoft 365 Group

Dùng cho:

Collaboration (Teams, SharePoint, Outlook…)
Làm việc nhóm

Khác với Security Group:

Không dùng chủ yếu để gán quyền hạ tầng
Tập trung vào user productivity

3. Các kiểu Membership (cách thêm thành viên)

Assigned (Thủ công)

Admin tự thêm user vào group
Đơn giản, dễ kiểm soát
Phù hợp với môi trường nhỏ

Dynamic User (Tự động theo rule)

Azure AD sẽ tự động add user vào group dựa trên điều kiện.

Ví dụ:

department = "IT"
jobTitle = "Network Engineer"

Khi user thỏa điều kiện → tự vào group

Ưu điểm:

Tự động hóa
Giảm lỗi vận hành

Dynamic Device

Áp dụng cho thiết bị (device)
Ví dụ:
- Tất cả máy join Azure AD
- Hoặc máy thuộc một OU / naming convention

Chỉ dùng cho Security Group

4. Best Practice trong thực tế

Khi triển khai hệ thống Azure / Hybrid:

Không gán quyền trực tiếp cho user
Luôn đi theo mô hình:
User → Group → Role → Resource
Sử dụng Dynamic Group khi:
- Hệ thống lớn
- Có HR data chuẩn (department, title…)
Đặt tên group rõ ràng:
- AZ-VM-Admins
- AZ-Network-Admins
- AZ-ReadOnly

5. Góc nhìn System & Cloud Architect

Azure AD Group không chỉ là một tính năng đơn giản, mà là nền tảng cho:

Identity & Access Management (IAM)
Zero Trust Architecture
Automation & Governance

Trong các hệ thống lớn:

Group = abstraction layer
Giúp tách biệt user và quyền truy cập
Dễ audit, dễ scale, dễ automate

Kết luận

Nếu bạn đang học Azure hoặc làm việc trong môi trường Cloud:

Hiểu rõ Azure AD Group là bước đầu để:

Thi AZ-104
Triển khai RBAC đúng chuẩn
Xây dựng hệ thống bảo mật và scalable

]]> AZURE dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/azure/439600-group-trong-azure-ad Mạng SAN https://www.forum.vnpro.org/forum/cloud-computing/azure/439578-mạng-san Wed, 15 Apr 2026 08:10:44 GMT Trong thế giới hạ tầng hiện đại, SAN không chỉ là một giải pháp lưu trữ — mà là nền tảng cốt lõi cho Data Center và Cloud. Nếu bạn đang học hoặc...
Nếu bạn đang học hoặc làm việc với VMware, Hyper-V, Azure Stack hoặc các hệ thống private cloud, thì SAN gần như là một thành phần bắt buộc phải hiểu.

1. SAN là gì dưới góc nhìn thực tế?

Khác với NAS (truy cập file qua mạng), SAN hoạt động ở mức block-level. Điều này có nghĩa là:

Server thấy storage như một ổ đĩa local (disk gắn trực tiếp)
OS có thể format, partition, mount như ổ cứng thật
Hypervisor (ESXi, Hyper-V) sử dụng SAN để chạy VM cực kỳ hiệu quả

Đây chính là lý do SAN được dùng trong:

Data Center
Virtualization (VMware vSphere, Hyper-V)
Database lớn (Oracle, SQL Server)
Hệ thống cần HA và performance cao

2. Các công nghệ SAN phổ biến

Trong thực tế triển khai, bạn sẽ gặp:

Fibre Channel (FC)
Chuẩn truyền thống, hiệu năng cao, độ trễ thấp, nhưng chi phí rất cao
iSCSI
Chạy trên TCP/IP → tận dụng hạ tầng Ethernet
Đây là lựa chọn phổ biến nhất trong SMB và lab
FCoE
Kết hợp FC và Ethernet → giảm số lượng hạ tầng vật lý
InfiniBand
Dùng trong AI, HPC, Data Center hiệu năng cực cao

3. Vì sao SAN quan trọng trong Cloud và Virtualization?

Một số concept quan trọng:

Storage Shared → nhiều host truy cập cùng storage
→ enable vMotion / Live Migration
Multipathing (MPIO)
→ nhiều đường đi đến storage → tăng HA + performance
Centralized Storage
→ quản lý tập trung, snapshot, backup, replication

Trong Azure hoặc AWS, bạn không thấy SAN trực tiếp, nhưng:

Azure Managed Disk / AWS EBS
→ bản chất là abstract từ SAN backend

4. SAN vs NAS – hiểu đúng để không nhầm

Rất nhiều bạn mới học bị nhầm:

NAS → File-level (SMB, NFS)
SAN → Block-level (iSCSI, FC)

Hiểu đơn giản:

NAS = share folder
SAN = đưa raw disk cho server

5. Khi nào nên dùng SAN?

SAN phù hợp khi:

Cần hiệu năng cao (IOPS lớn)
Cần HA (failover, clustering)
Chạy nhiều VM
Database critical

Không phải lúc nào SAN cũng là lựa chọn tốt, vì:

Chi phí cao
Triển khai phức tạp
Cần kỹ năng chuyên sâu

6. Góc nhìn thực chiến

Trong các hệ thống doanh nghiệp:

SAN thường đi kèm với:
- VMware vSphere + vCenter
- Storage vendor: Dell EMC, NetApp, HPE
- Multipath + zoning + LUN masking
Lỗi phổ biến:
- Misconfiguration zoning (FC)
- iSCSI network không tách VLAN
- Không cấu hình MPIO → bottleneck

Kết luận

SAN là một trong những nền tảng quan trọng nhất của hạ tầng hiện đại. Nếu bạn muốn đi sâu vào:

System Engineer
Cloud Engineer
Virtualization
Data Center

thì việc hiểu SAN không còn là “optional” mà là “must-have”.]]> AZURE dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/azure/439578-mạng-san Quản lý User trong Azure AD (Microsoft Entra ID) – Những điều cơ bản nhưng cực kỳ quan trọng https://www.forum.vnpro.org/forum/cloud-computing/azure/439569-quản-lý-user-trong-azure-ad-microsoft-entra-id-–-những-điều-cơ-bản-nhưng-cực-kỳ-quan-trọng Tue, 14 Apr 2026 12:32:51 GMT Trong bất kỳ hệ thống Cloud nào, đặc biệt là Azure, quản lý danh tính (Identity Management) luôn là nền tảng cốt lõi. Và Azure AD chính là “trái tim”...
Một trong những tác vụ đầu tiên mà bất kỳ admin nào cũng phải làm quen chính là quản lý tài khoản người dùng.

Hai loại user phổ biến trong Azure AD

Azure AD hỗ trợ hai loại user chính:

User nội bộ (Member)
Đây là tài khoản thuộc tổ chức, được tạo trực tiếp trong Azure AD. Ví dụ: user@company.com

User khách (Guest)
Dùng để mời người ngoài (đối tác, vendor, khách hàng) vào hệ thống. Đây là nền tảng của mô hình B2B collaboration trong Azure.

Điểm quan trọng: Guest user không cần nằm trong domain của bạn nhưng vẫn có thể truy cập tài nguyên theo quyền được cấp.

Quản lý user ở quy mô lớn

Trong môi trường enterprise, bạn sẽ không tạo từng user thủ công.

Azure hỗ trợ:

Bulk create (tạo hàng loạt bằng file CSV)
Bulk invite (mời nhiều guest cùng lúc)
Bulk delete

Điều này cực kỳ quan trọng khi:

Onboarding nhân sự mới
Migration hệ thống
Tích hợp với HR system

Phân quyền quản trị – không phải ai cũng làm được

Không phải user nào cũng có thể quản lý user khác.

Bạn cần một trong các role sau:

Global Administrator
User Administrator

Đây là một phần của mô hình RBAC (Role-Based Access Control) trong Azure.

Best Practice:
Không nên dùng Global Admin cho mọi tác vụ hằng ngày. Nên tách role để giảm rủi ro bảo mật.

Vòng đời của user trong Azure

Một điểm rất hay trong Azure AD:

User bị xóa không mất ngay lập tức.

Có thể restore trong vòng 30 ngày
Sau 30 ngày sẽ bị xóa vĩnh viễn

Điều này giúp:

Tránh mất dữ liệu do thao tác nhầm
Hỗ trợ audit và compliance

Audit và theo dõi đăng nhập

Azure cung cấp đầy đủ:

Sign-in logs (ai đăng nhập, từ đâu, lúc nào)
Audit logs (ai tạo user, xóa user, thay đổi quyền)

Đây là nền tảng cho:

SOC monitoring
Incident response
Compliance (ISO, GDPR, v.v.)

Bảo mật không thể thiếu: MFA

Multi-Factor Authentication là bắt buộc trong môi trường hiện đại.

Một user chỉ dùng password là chưa đủ.
MFA giúp giảm thiểu:

Phishing
Credential theft
Account takeover

Kết luận

Quản lý user trong Azure AD không chỉ là tạo tài khoản, mà là quản lý toàn bộ vòng đời danh tính:

Tạo đúng loại user
Phân quyền hợp lý
Theo dõi hoạt động
Áp dụng bảo mật (MFA)

]]> AZURE dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/azure/439569-quản-lý-user-trong-azure-ad-microsoft-entra-id-–-những-điều-cơ-bản-nhưng-cực-kỳ-quan-trọng <![CDATA[Azure ID - "User Account"]]> https://www.forum.vnpro.org/forum/cloud-computing/azure/439546-azure-id-user-account Mon, 13 Apr 2026 11:00:10 GMT [Azure Identity] Vì sao “User Account” là nền tảng quan trọng nhất trong Azure AD?

Khi bắt đầu với Azure hoặc bất kỳ hệ thống Cloud nào, có một khái niệm tưởng đơn giản nhưng lại là “gốc rễ” của toàn bộ hệ thống: User Account (tài khoản người dùng).

Trong Azure Active Directory (Azure AD), mọi thứ đều xoay quanh Identity.

1. Mọi người dùng đều phải có tài khoản

Không có tài khoản → không thể truy cập hệ thống.

Trong môi trường Azure:

User có thể là nhân viên nội bộ (Member)
Hoặc người bên ngoài (Guest – B2B collaboration)

Điều này rất quan trọng khi làm việc trong môi trường doanh nghiệp:

Nhân viên công ty → Member
Đối tác, vendor → Guest

Đây chính là nền tảng cho mô hình Identity-based Security trong Cloud.

2. User Account = Authentication + Authorization

Một tài khoản không chỉ để đăng nhập.

Nó phục vụ 2 mục tiêu cốt lõi:

Authentication (Xác thực)
→ Bạn là ai?
Ví dụ:

Username/password
MFA (Multi-Factor Authentication)

Authorization (Phân quyền)
→ Bạn được làm gì?
Ví dụ:

Có quyền truy cập VM hay không
Có được tạo Resource Group không
Có quyền đọc hay ghi dữ liệu

Trong Azure, phần này được quản lý thông qua:

RBAC (Role-Based Access Control)
Conditional Access
Identity Protection

3. User Account có rất nhiều thuộc tính (Properties)

Một user trong Azure AD không chỉ có username.

Nó có rất nhiều thông tin quan trọng:

User Principal Name (UPN)
Email
Department
Job title
Group membership
Role assignments
MFA status
Licensing (E3, E5, v.v.)

Những thuộc tính này được sử dụng để:

Áp policy (Conditional Access)
Phân quyền tự động
Tích hợp với hệ thống HR / IAM

4. Phân biệt nhanh các loại User trong Azure

Member

Người dùng nội bộ
Thuộc tenant
Có quyền đầy đủ theo RBAC

Guest

Người dùng từ tenant khác
Dùng trong B2B collaboration
Quyền hạn bị giới hạn

5. Đồng bộ với Active Directory (Hybrid Identity)

Trong thực tế doanh nghiệp:

User thường được tạo trong On-Prem AD
Sau đó sync lên Azure AD bằng Azure AD Connect

Cột “Directory synced = Yes” thể hiện:
→ User này đến từ hệ thống on-prem

Điều này cực kỳ quan trọng trong mô hình:
Hybrid Identity (AD + Azure AD)

Kết luận

Nếu bạn học Azure mà chưa hiểu rõ User Account, thì gần như:
→ Bạn chưa thực sự hiểu Azure.

User Account chính là:

Điểm bắt đầu của bảo mật
Trung tâm của quản trị
Nền tảng của Zero Trust

Nếu bạn đang học MCSA / Azure / Cloud:
Hãy bắt đầu từ Identity trước, rồi mới đi tiếp sang VM, Network hay Security.

Vì trong Cloud:
Không phải Server là trung tâm — mà Identity mới là trung tâm.
]]> AZURE dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/azure/439546-azure-id-user-account Bạn muốn thử sức làm kỹ sư hệ thống? - XỬ LÝ NGAY CẤU HÌNH LAB NÀY! 🤔🌐 https://www.forum.vnpro.org/forum/cloud-computing/mcsa/439544-bạn-muốn-thử-sức-làm-kỹ-sư-hệ-thống-xử-lý-ngay-cấu-hình-lab-này-🤔🌐 Mon, 13 Apr 2026 08:18:19 GMT Bạn muốn thử sức làm kỹ sư hệ thống - XỬ LÝ NGAY HỆ THỐNG NÀY! 🤔🌐

Admin vừa "thả xích" mô hình Lab MCSA cực gắt cho anh em thực hành đây.
Nhìn sơ qua là thấy "mùi" của:
✅ VPN Site-to-Site.
✅ Active Directory Replication.
✅ Troubleshooting mệt nghỉ nhưng cực phê!

Anh em nào tự tin giải quyết gọn ghẽ sơ đồ này trong 1 buổi thì điểm danh cái nhẹ nào! 👇
👉 Muốn thử sức làm kỹ sư hệ thống chuyên nghiệp?
📩 Kết nối với chúng mình tại: marketing@vnpro.org]]> MCSA KhanhHa https://www.forum.vnpro.org/forum/cloud-computing/mcsa/439544-bạn-muốn-thử-sức-làm-kỹ-sư-hệ-thống-xử-lý-ngay-cấu-hình-lab-này-🤔🌐 Self-Service Password Reset (SSPR) trong Azure AD – Giải pháp giảm tải IT Helpdesk https://www.forum.vnpro.org/forum/cloud-computing/azure/439523-self-service-password-reset-sspr-trong-azure-ad-–-giải-pháp-giảm-tải-it-helpdesk Sun, 12 Apr 2026 08:12:31 GMT Trong môi trường doanh nghiệp hiện đại, một trong những vấn đề phổ biến nhất là người dùng quên mật khẩu. Nếu mọi yêu cầu reset password đều phải...
Microsoft Azure Active Directory cung cấp một tính năng rất quan trọng: Self-Service Password Reset (SSPR) – cho phép người dùng tự đặt lại mật khẩu một cách an toàn mà không cần liên hệ IT.

1. Xác định đối tượng được sử dụng SSPR

Không phải lúc nào bạn cũng bật SSPR cho toàn bộ tổ chức ngay từ đầu. Best practice:

Triển khai thử nghiệm (pilot) cho một nhóm nhỏ
Sau đó mở rộng dần ra toàn bộ người dùng
Có thể áp dụng theo nhóm (Group-based) trong Azure AD

Điều này giúp kiểm soát rủi ro và đánh giá trải nghiệm người dùng trước khi rollout toàn hệ thống.

2. Cấu hình phương thức xác thực

Đây là phần quan trọng nhất quyết định mức độ bảo mật của SSPR.

Bạn cần xác định:

Số lượng phương thức xác thực yêu cầu (1 hoặc 2)
Các phương thức cho phép:
- Email
- Mobile phone (SMS hoặc call)
- Microsoft Authenticator
- Security questions

Ví dụ thực tế:

Nếu chọn 1 phương thức → tiện lợi nhưng bảo mật thấp hơn
Nếu chọn 2 phương thức → an toàn hơn, phù hợp môi trường doanh nghiệp

Khuyến nghị:

Không nên chỉ dùng security questions vì dễ bị đoán
Ưu tiên Mobile + Authenticator App

3. Yêu cầu người dùng đăng ký SSPR

Trước khi sử dụng SSPR, người dùng cần đăng ký thông tin xác thực.

Điểm quan trọng:

Quy trình này giống với MFA registration
Người dùng sẽ khai báo:
- Số điện thoại
- Email dự phòng
- Câu hỏi bảo mật (nếu dùng)

Bạn có thể cấu hình:

Bắt buộc đăng ký khi đăng nhập lần đầu
Hoặc yêu cầu cập nhật định kỳ

Góc nhìn thực tế khi triển khai

Trong các dự án Azure thực tế, SSPR mang lại nhiều lợi ích rõ rệt:

Giảm 60–80% ticket reset password cho IT
Tăng trải nghiệm người dùng
Kết hợp tốt với MFA và Zero Trust

Tuy nhiên, cần lưu ý:

Chính sách xác thực phải đủ mạnh
Tránh cấu hình quá dễ (ví dụ chỉ cần email)
Theo dõi audit log để phát hiện hành vi bất thường

Kết luận

SSPR không chỉ là một tính năng tiện lợi mà còn là một phần quan trọng trong chiến lược Identity Security trên Azure.

Nếu triển khai đúng cách, bạn sẽ:

Giảm tải vận hành
Tăng bảo mật
Chuẩn hóa theo mô hình Zero Trust

]]> AZURE dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/azure/439523-self-service-password-reset-sspr-trong-azure-ad-–-giải-pháp-giảm-tải-it-helpdesk Azure AD Device Indentities https://www.forum.vnpro.org/forum/cloud-computing/azure/439461-azure-ad-device-indentities Fri, 10 Apr 2026 08:19:22 GMT Azure AD Device Identities Trong quá trình triển khai Azure AD (nay là Microsoft Entra ID), một trong những chủ đề quan trọng nhưng rất dễ bị nhầm... Azure AD Device Identities

Trong quá trình triển khai Azure AD (nay là Microsoft Entra ID), một trong những chủ đề quan trọng nhưng rất dễ bị nhầm lẫn chính là Device Identity – cách thiết bị được nhận diện và quản lý trong hệ thống.

Microsoft chia thành 3 mô hình chính:

Azure AD Registered
Azure AD Joined
Hybrid Azure AD Joined

Việc chọn sai mô hình sẽ ảnh hưởng trực tiếp đến: bảo mật, quản lý thiết bị, trải nghiệm người dùng và cả chiến lược chuyển đổi cloud.

1. Azure AD Registered – Dành cho BYOD

Đây là mô hình nhẹ nhất.

Hiểu đơn giản:
Thiết bị không thuộc công ty, nhưng được “đăng ký” để truy cập tài nguyên.

Ví dụ thực tế:
Nhân viên dùng điện thoại cá nhân để truy cập email công ty (Outlook, Teams).

Đặc điểm kỹ thuật:

Không join domain
Không kiểm soát toàn bộ thiết bị
Chủ yếu quản lý ở mức ứng dụng (App-level control)
Kết hợp với Intune (MDM/MAM)

Khi nào dùng:

BYOD
Mobile workforce
Không muốn can thiệp sâu vào thiết bị cá nhân

2. Azure AD Joined – Cloud Native

Đây là mô hình dành cho tổ chức hiện đại.

Hiểu đơn giản:
Thiết bị thuộc công ty và join trực tiếp vào Azure AD, không cần on-prem AD.

Đặc điểm kỹ thuật:

Không cần Domain Controller on-prem
Quản lý bằng Intune (Endpoint Manager)
Hỗ trợ Conditional Access
Tích hợp tốt với Zero Trust

Khi nào dùng:

Doanh nghiệp cloud-first / cloud-only
Startup hoặc hệ thống mới
Triển khai Windows 10/11 hiện đại

Điểm quan trọng:
Đây là nền tảng cho:

Zero Trust Architecture
Modern Workplace
Passwordless / MFA / Conditional Access

3. Hybrid Azure AD Joined – Mô hình chuyển tiếp

Đây là mô hình phổ biến nhất hiện nay trong doanh nghiệp lớn.

Hiểu đơn giản:
Thiết bị vừa join on-prem AD, vừa được sync lên Azure AD.

Đặc điểm kỹ thuật:

Vẫn dùng Domain Controller
Vẫn dùng Group Policy (GPO)
Đồng bộ qua Azure AD Connect
Hỗ trợ cả legacy apps (Win32)

Khi nào dùng:

Doanh nghiệp đã có hạ tầng AD truyền thống
Chưa thể migrate toàn bộ lên cloud
Còn phụ thuộc vào GPO, Kerberos, NTLM

So sánh nhanh để nhớ

Registered → BYOD, nhẹ, ít kiểm soát
Joined → Cloud-native, hiện đại, bảo mật cao
Hybrid → Legacy + Cloud, dùng trong giai đoạn chuyển đổi

Góc nhìn kiến trúc (Architect View)

Một chiến lược phổ biến:

Giai đoạn 1: Hybrid (giữ hệ thống cũ hoạt động)
Giai đoạn 2: Song song Hybrid + Azure AD Join
Giai đoạn 3: Cloud-only (Azure AD Join)

Đây chính là hành trình:
Traditional IT → Modern IT → Zero Trust

Tips thực chiến

Đừng dùng Hybrid nếu không thật sự cần GPO
Nếu triển khai mới → chọn Azure AD Join ngay từ đầu
BYOD → luôn kết hợp Intune + Conditional Access
Kiểm tra kỹ licensing (Azure AD P1/P2, Intune)

Kết luận

Device Identity không chỉ là “join domain” như trước đây nữa.
Nó là nền tảng cho:

Bảo mật (Zero Trust)
Quản lý thiết bị (MDM/MAM)
Trải nghiệm người dùng (SSO, Conditional Access)

Hiểu rõ 3 mô hình này sẽ giúp bạn thiết kế đúng kiến trúc Azure ngay từ đầu, tránh phải “refactor” toàn bộ hệ thống sau này.]]> AZURE dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/azure/439461-azure-ad-device-indentities So sánh Azure AD và AD DS https://www.forum.vnpro.org/forum/cloud-computing/azure/439446-so-sánh-azure-ad-và-ad-ds Thu, 09 Apr 2026 11:10:56 GMT So sánh AD DS và Azure AD – Hiểu đúng để triển khai đúng Đây là một trong những câu hỏi mà rất nhiều anh em khi học Azure hay gặp: “Azure AD có... So sánh AD DS và Azure AD – Hiểu đúng để triển khai đúng

Đây là một trong những câu hỏi mà rất nhiều anh em khi học Azure hay gặp:
“Azure AD có phải là bản cloud của Active Directory không?”

Câu trả lời ngắn gọn là: Không hoàn toàn đúng.
Hai hệ thống này phục vụ hai mục tiêu khác nhau, dù đều xoay quanh identity.

1. Sự khác biệt cốt lõi: On-Prem vs Cloud Identity

AD DS (Active Directory Domain Services):

Được thiết kế cho môi trường on-premises
Quản lý máy tính, user, domain trong mạng nội bộ
Dựa vào các giao thức truyền thống:
- LDAP (directory query)
- Kerberos / NTLM (authentication)
Có các thành phần quen thuộc:
- Domain Controller
- OU (Organizational Unit)
- Group Policy (GPO)

Azure AD:

Là dịch vụ identity trên cloud (IDaaS – Identity as a Service)
Thiết kế cho:
- SaaS (Office 365, Salesforce…)
- Web app, API
Sử dụng:
- REST API
- HTTP/HTTPS
- OAuth2, OpenID Connect, SAML
Không có:
- OU
- GPO
- Domain join theo kiểu truyền thống (trừ Azure AD Join)

2. Khác biệt về cách quản lý (Điểm rất quan trọng trong thực tế)

AD DS trên VM (IaaS):

Khi bạn triển khai AD DS trên Azure VM:

Bạn phải tự quản lý:
- OS (Windows Server)
- Patch
- Backup
- Replication
- Domain Controller
Đây vẫn là mô hình truyền thống, chỉ chuyển lên cloud

Azure AD:

Là managed service của Microsoft
Bạn chỉ cần quản lý:
- User
- Group
- Policy (Conditional Access, MFA…)
Microsoft lo:
- High availability
- Patch
- Security nền tảng

Đây chính là sự khác biệt giữa:

IaaS mindset (AD DS trên VM)
SaaS/PaaS mindset (Azure AD)

3. Khác biệt về giao thức và tích hợp

AD DS:

LDAP để query
Kerberos để authenticate
Chủ yếu dùng trong:
- Domain-joined machine
- Internal apps

Azure AD:

REST API + token-based auth
OAuth2 / OpenID Connect
Tích hợp cực mạnh với:
- SaaS apps (Google, Facebook, GitHub…)
- API, Microservices
- Mobile / Web apps

Nói đơn giản:

AD DS → “Network-centric identity”
Azure AD → “Internet-centric identity”

4. Cấu trúc và quản lý

AD DS:

Có OU để phân cấp quản lý
GPO để áp policy xuống máy
Phù hợp môi trường doanh nghiệp truyền thống

Azure AD:

Cấu trúc flat
Không có OU/GPO
Thay vào đó dùng:
- RBAC
- Conditional Access
- Intune (MDM/MAM)

5. Vậy chúng giống nhau ở điểm nào?

Dù khác nhau, nhưng có một điểm chung quan trọng:

Cả hai đều là Identity Provider (IdP)
Đều quản lý:
- User
- Group
- Authentication
Đều có thể:
- Kết hợp với nhau qua Azure AD Connect
- Tạo mô hình Hybrid Identity

6. Khi nào dùng cái nào? (Kinh nghiệm thực tế)

Bạn nên dùng AD DS khi:

Có hệ thống legacy
Có ứng dụng cần LDAP/Kerberos
Quản lý domain-joined machine

Bạn nên dùng Azure AD khi:

Làm việc với:
- Office 365
- SaaS
- Cloud-native app
Cần:
- SSO
- MFA
- Zero Trust

Trong thực tế doanh nghiệp:

90% sẽ đi theo hướng Hybrid Identity
- AD DS + Azure AD + Azure AD Connect

Kết luận

Azure AD không phải là “AD trên cloud”
Mà là một hệ thống identity hoàn toàn mới, thiết kế cho:

Internet
Cloud
API
Zero Trust

Hiểu rõ sự khác biệt này sẽ giúp bạn:

Thiết kế hệ thống đúng ngay từ đầu
Tránh triển khai sai kiến trúc
Tận dụng đúng sức mạnh của Azure

Nếu anh em đang học AZ-900, AZ-104 hoặc làm System/Cloud, đây là một trong những concept bắt buộc phải nắm thật chắc.
]]> AZURE dangquangminh https://www.forum.vnpro.org/forum/cloud-computing/azure/439446-so-sánh-azure-ad-và-ad-ds