PAM Privileged Access Management (PAM) - Part 1: Kiến Trúc, Threat Model và Các Thành Phần Cốt Lõi

Hãy tưởng tượng bạn là System Administrator của một công ty tài chính. Bạn có tài khoản root trên toàn bộ máy chủ Linux, tài khoản sa trên SQL Server chứa dữ liệu giao dịch, và quyền Domain Admin trên Active Directory của toàn công ty. Nếu bất kỳ tài khoản nào trong số này bị kẻ tấn công chiếm được, thiệt hại có thể xảy ra trong vài phút - và không thể đảo ngược.​

​

Đây không phải kịch bản giả định. Target (2013), SolarWinds (2020), Colonial Pipeline (2021) - điểm chung của tất cả là kẻ tấn công đã leo thang đặc quyền và di chuyển ngang qua mạng bằng tài khoản đặc quyền bị compromise. Trong trường hợp SolarWinds, kẻ tấn công tồn tại trong môi trường suốt nhiều tháng mà không bị phát hiện, một phần vì không có cơ chế giám sát phiên làm việc đặc quyền đủ mạnh.​

Sự khác biệt không chỉ là "quyền nhiều hơn". Một User Account thông thường có phạm vi ảnh hưởng giới hạn - nếu bị compromise, thiệt hại thường chỉ ở cấp độ cá nhân. Một Privileged Account có khả năng thay đổi cấu hình hệ thống, tạo/xóa tài khoản khác, truy cập dữ liệu nhạy cảm của toàn tổ chức, hoặc tắt toàn bộ hạ tầng.​

​

Bảng dưới đây liệt kê các loại tài khoản đặc quyền phổ biến và phạm vi ảnh hưởng thực tế của chúng:​

PAM - Privileged Access Management (Quản lý Truy cập Đặc quyền) là tập hợp các công nghệ, quy trình và chính sách nhằm kiểm soát, giám sát và bảo vệ tất cả các tài khoản đặc quyền trong một tổ chức.​

​

PAM không phải là một phần mềm lưu mật khẩu, cũng không phải bastion host. PAM là một lớp kiểm soát trung gian toàn diện - đứng giữa người dùng đặc quyền và hệ thống đích, kiểm soát mọi bước từ xác thực danh tính, phê duyệt yêu cầu, inject credential vào phiên làm việc, giám sát real-time, ghi lại toàn bộ hành động, đến xoay vòng mật khẩu sau mỗi phiên. PAM quản lý toàn bộ vòng đời của một phiên truy cập đặc quyền.​

Trước khi đi sâu vào PAM, cần đặt nó vào đúng vị trí trong bức tranh lớn hơn - Identity Security.​

​

Identity Security là chiến lược bảo mật tập trung vào việc bảo vệ danh tính (identity) như tài sản cốt lõi, thay vì chỉ bảo vệ vành đai mạng. Trong chiến lược Zero Trust hiện đại, identity là "perimeter mới" - mọi yêu cầu truy cập đều phải được xác thực và ủy quyền, bất kể nguồn gốc từ đâu.​

​

Identity Security bao gồm nhiều thành phần, trong đó PAM chỉ là một nhánh chuyên biệt:​

​

Identity Security:​

Trong khi IAM quản lý toàn bộ danh tính - từ nhân viên văn phòng đến khách hàng. PAM là lớp chuyên biệt cho tập con đặc biệt nguy hiểm nhất: tài khoản đặc quyền. IAM trả lời câu hỏi "ai được vào hệ thống nào", còn PAM đi xa hơn với câu hỏi "ai được làm gì cụ thể trong phiên đó, và toàn bộ hành động đó được ghi lại như thế nào".​

​

Trong triển khai thực tế, PAM không hoạt động độc lập. Nó lấy thông tin danh tính từ IAM (AD, LDAP, Entra ID), tích hợp MFA để xác thực người dùng, dùng SSO/SAML để liên kết với Identity Provider của doanh nghiệp, nhận danh sách quyền từ IGA để quyết định ai được access gì, và đẩy toàn bộ audit log sang SIEM để tương quan sự kiện.​

​

Hiểu PAM trong hệ sinh thái Identity Security giúp bạn biết PAM nằm ở đâu. Nhưng để hiểu tại sao PAM tồn tại, cần đặt câu hỏi từ phía đối diện: kẻ tấn công đang tìm gì - và credential đặc quyền đóng vai trò như thế nào trong chuỗi tấn công thực tế?​

Threat model của Privileged Access Management (PAM) được xây dựng dựa trên cách thức hoạt động của các cuộc tấn công hiện đại, trong đó mục tiêu chính của kẻ tấn công không chỉ là xâm nhập hệ thống mà còn chiếm được credential đặc quyền để leo thang đặc quyền và mở rộng phạm vi kiểm soát. Sau khi có initial access thông qua phishing, VPN hoặc RDP bị khai thác, attacker thường thực hiện credential dumping, privilege escalation và lateral movement để tiến tới chiếm quyền Domain Admin. Khi đạt được quyền này, chúng có thể truy cập toàn bộ tài nguyên trong domain, đánh cắp dữ liệu Active Directory, tạo cơ chế duy trì quyền truy cập hoặc triển khai ransomware trên quy mô lớn.​

​

PAM không được thiết kế để ngăn chặn giai đoạn xâm nhập ban đầu mà tập trung bảo vệ các giai đoạn liên quan đến việc sử dụng và lạm dụng tài khoản đặc quyền. Các cơ chế như Credential Vault và Password Rotation giúp ngăn chặn việc đánh cắp và tái sử dụng credential; Just-in-Time (JIT) Access và Least Privilege loại bỏ standing privilege, chỉ cấp quyền khi cần thiết và trong thời gian giới hạn; Session Broker, MFA và Approval Workflow đảm bảo mọi phiên truy cập đặc quyền đều được xác thực và kiểm soát thông qua PAM thay vì kết nối trực tiếp đến hệ thống đích.​

​

Bên cạnh việc hạn chế khả năng attacker mở rộng quyền truy cập, PAM còn cung cấp Session Recording, Keystroke Logging và Audit Log để ghi lại toàn bộ hoạt động của các phiên đặc quyền, hỗ trợ phát hiện bất thường, điều tra và truy vết sau sự cố. Nhờ đó, PAM giúp cắt đứt các bước quan trọng trong chuỗi tấn công, giảm phạm vi ảnh hưởng nếu credential bị lộ và tăng khả năng ứng phó sự cố. Tuy nhiên, PAM không thay thế các giải pháp bảo vệ lớp đầu như Email Security, EDR hay Network Security mà đóng vai trò là lớp phòng thủ chuyên biệt nhằm bảo vệ tài khoản đặc quyền trong môi trường doanh nghiệp.​

​

Trước khi triển khai Privileged Access Management (PAM), nhiều doanh nghiệp quản lý tài khoản đặc quyền theo cách thủ công, dẫn đến nhiều rủi ro về bảo mật, khả năng truy vết và tuân thủ. Những vấn đề phổ biến bao gồm:​

PAM được thiết kế để giải quyết các vấn đề trên bằng cách cung cấp một lớp kiểm soát tập trung giữa người dùng và hệ thống đích. Thông qua các cơ chế như Credential Vault, Password Rotation, Just-in-Time Access, Least Privilege, MFA và Session Recording, PAM giúp giảm thiểu rủi ro từ tài khoản đặc quyền, tăng khả năng truy vết và hỗ trợ đáp ứng các yêu cầu tuân thủ.​

Ba khái niệm cốt lõi cần nắm trước khi đi vào kiến trúc:​

​

Privileged Account là bất kỳ tài khoản nào có quyền vượt trội so với người dùng thông thường - đủ để ảnh hưởng đến tính bảo mật (confidentiality), tính toàn vẹn (integrity) hoặc tính sẵn sàng (availability) của hệ thống. Điều quan trọng cần nhớ: tài khoản đặc quyền không chỉ là tài khoản của người dùng. Service account, application credential, API key, SSH key - tất cả đều thuộc phạm vi quản lý của PAM nếu chúng có quyền đặc biệt.​

​

Least Privilege (Nguyên tắc Đặc quyền Tối thiểu) là nguyên tắc mỗi người dùng, tiến trình hay hệ thống chỉ được cấp đúng quyền cần thiết để hoàn thành nhiệm vụ cụ thể - không hơn, không kém, và chỉ trong thời gian cần thiết. Trong thực tế, nguyên tắc này thường bị vi phạm vì tính tiện lợi: cấp nhiều quyền hơn để tránh phải cấp lại sau. PAM giúp thực thi Least Privilege một cách tự động và nhất quán.​

​

Just-in-Time (JIT) Access là hiện thực hoá thực tế nhất của Least Privilege theo chiều thời gian. Thay vì cấp quyền admin thường trực cho một người, PAM chỉ cấp quyền khi có yêu cầu cụ thể, trong khoảng thời gian giới hạn (ví dụ: 2 giờ), và tự động thu hồi khi hết hạn. Nếu tài khoản bị compromise trong khoảng thời gian không có quyền, kẻ tấn công không có gì để khai thác.​

Một hệ thống PAM hiện đại không phải là một ứng dụng đơn lẻ mà là nhiều lớp (layer) phối hợp với nhau. Hiểu kiến trúc giúp bạn hiểu vì sao PAM hoạt động được, và quan trọng hơn - vì sao không thể dùng một công cụ đơn giản để thay thế.​

​

Luồng kết nối cốt lõi: Người dùng truy cập PAM Portal qua HTTPS → xác thực danh tính (Authentication layer) và kiểm tra quyền (Authorization + Policy Engine) → nếu được phép, Credential Vault giải mã credential vào bộ nhớ → Session Broker mở kết nối đến hệ thống đích thay mặt người dùng, inject credential - người dùng không bao giờ thấy mật khẩu thật → Session Monitor ghi lại toàn bộ phiên → khi phiên kết thúc, Password Rotation Engine tự động đổi mật khẩu → toàn bộ sự kiện được ghi vào Audit Log và đẩy sang SIEM.​

​

Điểm then chốt của kiến trúc này: người dùng không bao giờ kết nối trực tiếp đến hệ thống đích. Session Broker là điểm kiểm soát duy nhất - và đó là lý do tại sao PAM có thể ghi lại, lọc và ngắt kết nối bất kỳ lúc nào.​

Kiến trúc lớp ở trên mô tả những gì PAM làm - nhưng cách nó được triển khai trong thực tế phụ thuộc vào môi trường và yêu cầu của từng tổ chức. Không có mô hình nào tốt nhất cho mọi trường hợp, các sản phẩm PAM doanh nghiệp hiện đại thường kết hợp nhiều mô hình thay vì chỉ dùng một.​

​

Jump Server / Bastion Host (truyền thống)​

​

Admin SSH hoặc RDP đến một server trung gian (bastion host), sau đó từ đó kết nối đến server đích. Đây là mô hình đơn giản nhất: không cần agent, không cần credential injection phức tạp. Nhược điểm: admin vẫn biết password của server đích, không có session recording cấp độ lệnh, và bastion host trở thành single point of failure. Phù hợp với môi trường nhỏ chưa có ngân sách PAM enterprise.​

​

Agentless PAM (Session Broker / Transparent Proxy)​

​

Mô hình phổ biến nhất trong PAM enterprise hiện đại. Session Broker đứng giữa người dùng và server đích, proxy toàn bộ traffic mà không cần cài software trên server đích. PAM lấy credential từ Vault, inject vào connection, ghi lại phiên tại tầng proxy. Ưu điểm: không ảnh hưởng đến server production, dễ triển khai trên hệ thống legacy. Nhược điểm: cần mở port từ PAM server đến server đích, một số tính năng (như application-level audit) bị giới hạn. Đây là mô hình mà Alex dùng trong tình huống xuyên suốt bài viết.​

​

Agent-based PAM​

​

Một agent nhẹ được cài trên server đích để ghi lại hành động tại local, kiểm soát quyền ở cấp độ OS, và báo cáo về PAM server trung tâm. Ưu điểm: audit sâu hơn (ví dụ: biết chính xác process nào chạy lệnh gì), không phụ thuộc vào network path giữa PAM và server. Nhược điểm: phải quản lý agent trên từng server (lifecycle, update, compatibility), không phải lựa chọn tốt cho server legacy hoặc môi trường không cho phép cài thêm software.​

​

SaaS PAM (Cloud-hosted)​

​

PAM server được vận hành bởi vendor trên cloud, tổ chức chỉ cấu hình và sử dụng. Credential Vault và Session Broker chạy trên infrastructure của vendor. Ưu điểm: không cần quản lý infrastructure, update tự động, phù hợp với tổ chức cloud-first. Nhược điểm: dữ liệu credential được lưu ở bên thứ ba (cần đánh giá kỹ data residency và compliance), latency có thể ảnh hưởng đến session quality nếu server đích ở on-premises.​

​

Nhiều sản phẩm PAM enterprise (CyberArk, Delinea, BeyondTrust, Wallix) hỗ trợ cả agentless lẫn agent-based trong cùng một deployment, cho phép chọn mode phù hợp theo từng loại hệ thống đích.​

​

Phần này tập trung vào vai trò kiến trúc của từng thành phần - chúng làm gì và phối hợp với nhau như thế nào.​

​

5.1 Identity Source - Nguồn Định Danh​

PAM không tự quản lý danh tính người dùng mà kết nối đến các hệ thống directory hiện có của tổ chức: Active Directory (AD), LDAP server, Microsoft Entra ID (Azure AD), hoặc các Identity Provider cloud khác. Đây là nguồn sự thật duy nhất (single source of truth) về người dùng và nhóm.​

​

Kết nối này cho phép PAM tự động đồng bộ: khi một nhân viên được thêm vào group PAM_DBAdmins trong AD, họ ngay lập tức có quyền yêu cầu truy cập vào các database system trong PAM. Quan trọng hơn, khi tài khoản AD bị vô hiệu hoá (khi nhân viên nghỉ việc), PAM lập tức chặn mọi đăng nhập - không cần can thiệp thủ công vào từng hệ thống.​

​

5.2 Authentication Layer - Xác Thực Danh Tính​

Authentication trong PAM xác minh "bạn là ai" trước khi cho phép vào portal. PAM thường hỗ trợ nhiều phương thức và kết hợp chúng: mật khẩu AD + MFA (TOTP, push notification, hardware token FIDO2), hoặc SAML/OIDC SSO từ Identity Provider của doanh nghiệp.​

​

Trong các triển khai PAM doanh nghiệp, MFA được coi là yêu cầu tối thiểu cho mọi đăng nhập - không chỉ vì best practice mà vì các tiêu chuẩn compliance như PCI DSS v4.0 (Requirement 8.4) và NIST SP 800-63B (AAL2) đều yêu cầu xác thực đa yếu tố cho tài khoản đặc quyền. Trong tình huống của Alex, MFA push notification là bước xác thực bắt buộc trước khi vào PAM Portal.​

​

5.3 Authorization & Policy Engine - Phân Quyền và Chính Sách​

Sau khi xác thực thành công, Authorization Engine kiểm tra "bạn được phép làm gì". PAM sử dụng RBAC (Role-Based Access Control) làm nền tảng, nhưng Policy Engine cho phép áp dụng các điều kiện phức tạp hơn nhiều.​

​

Một policy điển hình có thể là: "Developer chỉ được SSH vào server Dev và Staging, không được vào Production, nếu request vào Production, cần approval từ Team Lead và ghi rõ Change Ticket, nếu request đến từ IP ngoài mạng công ty ngoài giờ hành chính, cần thêm approval từ Security Manager". Policy Engine đánh giá tất cả các điều kiện này đồng thời và đưa ra quyết định tự động.​

​

5.4 Credential Vault - Kho Lưu Trữ Thông Tin Xác Thực​

Vault là thành phần lưu trữ toàn bộ credential đặc quyền: mật khẩu, SSH private key, API key, certificate, connection string, token. Đa số giải pháp PAM enterprise mã hoá dữ liệu tại rest bằng AES-256 hoặc tương đương, với master encryption key thường được bảo vệ bởi HSM (Hardware Security Module) - thiết bị phần cứng chuyên dụng giúp cô lập key material khỏi phần mềm.​

​

Credential trong Credential Vault không được trả về dưới dạng plaintext cho người dùng cuối. Khi cần sử dụng, credential được giải mã trong bộ nhớ (in-memory) của PAM server, dùng để thiết lập kết nối đến server đích, sau đó được xóa khỏi memory. Người dùng không có cách trực tiếp đọc giá trị thực của credential.​

​

5.5 Session Broker / Proxy - Trung Gian Phiên Làm Việc​

Session Broker là thành phần trung tâm trong kiến trúc PAM, hoạt động như một transparent proxy: duy trì hai kết nối riêng biệt - một với người dùng, một với server đích - và ghép chúng lại theo thời gian thực.​

​

Cơ chế proxy cơ bản: Khi User SSH đến PAM, một process trên PAM server nhận connection từ phía User (connection A). Đồng thời, PAM mở một connection SSH độc lập đến Destination Server (connection B) bằng SSH key lấy từ Vault. Session Broker ghép A ↔ B: mọi keystroke từ User được forward đến server, mọi output từ Server được forward về User. Từ góc nhìn của User, trải nghiệm giống SSH trực tiếp - nhưng Session Broker ngồi giữa, đọc và ghi lại mọi thứ trước khi forward.​

​

SSH Proxy là mode phổ biến nhất cho Linux/Unix server và thiết bị mạng. Session Broker terminate connection tại PAM server và inspect protocol stream ở tầng application, cho phép filter từng lệnh.​

​

RDP Gateway là mode tương đương cho Windows. PAM đóng vai RDP Gateway, nhận kết nối RDP từ admin qua HTTPS/443 (RDP over TLS), sau đó mở kết nối RDP thực đến Windows Server đích. Video recording được thực hiện tại tầng gateway bằng cách capture pixel stream - không cần cài agent trên server đích.​

​

Database Proxy hoạt động ở tầng ứng dụng của từng database protocol. DBA kết nối đến PAM DB Proxy (pam-db-proxy:1433) thay vì database server trực tiếp. PAM parse SQL statement, log nội dung query, và có thể block DDL statement nguy hiểm theo policy.​

​

Những gì Session Broker kiểm soát được:​

Giới hạn cần lưu ý: Session Broker không thể kiểm soát những gì xảy ra bên trong ứng dụng nếu ứng dụng chạy qua kết nối được mã hoá end-to-end mà PAM không thể decrypt (ví dụ: VPN tunnel lồng bên trong SSH). Đây là lý do tại sao Command Filter cho VNC hoặc SSH tunnel bị hạn chế - PAM chỉ thấy traffic được mã hoá, không thấy nội dung.​

​

5.6 Credential Injection – Cơ Chế Cốt Lõi Của PAM​

​

Credential Injection là cơ chế khác biệt giữa PAM và password manager thông thường. Thay vì hiển thị mật khẩu cho người dùng, PAM sử dụng credential để thiết lập kết nối trực tiếp đến hệ thống đích mà người dùng không bao giờ nhìn thấy hoặc sở hữu credential.​

​

Quy trình Credential Injection​

Vòng đời của Credential​

So sánh với Password Manager​

Password manager vẫn hiển thị hoặc sao chép (copy) credential để người dùng nhập vào hệ thống, do đó credential vẫn xuất hiện trên thiết bị đầu cuối. Ngược lại, PAM inject credential trực tiếp vào kết nối, giúp người dùng không bao giờ biết hoặc sở hữu mật khẩu thật, giảm đáng kể nguy cơ rò rỉ và tái sử dụng credential.​

​

5.7 Session Monitoring & Recording - Giám Sát và Ghi Lại Phiên​

Session Monitor thực hiện hai nhiệm vụ song song: recording (ghi lại để xem sau) và monitoring (phân tích real-time).​

​

Recording với SSH session là text log được index - có thể tìm kiếm "ai đã chạy lệnh useradd trong tuần qua trên server nào" mà không cần xem thủ công từng session. Với RDP/VNC session, nhiều giải pháp PAM hỗ trợ video recording - có thể playback với timestamp và metadata đầy đủ. Retention policy thường được cấu hình theo yêu cầu compliance của tổ chức.​

​

Real-time Monitoring cho phép Security Analyst theo dõi một phiên đang diễn ra, nhận alert khi có lệnh thuộc danh sách cần cảnh báo, hoặc terminate session từ Security console - tùy theo quyền và workflow được cấu hình.​

​

5.8 Password Rotation Engine - Xoay Vòng Mật Khẩu Tự Động​

Password Rotation Engine giải quyết bài toán static password bằng cách tự động thay đổi credential sau mỗi phiên hoặc theo lịch định kỳ - tùy theo chính sách được cấu hình. Engine kết nối đến server đích bằng quyền quản trị và cập nhật mật khẩu của tài khoản đặc quyền thành một giá trị mới, sau đó lưu vào Credential Vault.​

​

Kết quả thực tế: ngay cả khi credential bị lộ trong quá trình phiên làm việc, giá trị đó sẽ không còn hiệu lực sau khi rotation diễn ra. Đây là lý do rotation theo session là best practice với các tài khoản đặc quyền cao nhất như Domain Admin hay Database SA.​

​

5.9 Audit & Logging - Kiểm Toán và Ghi Log​

Audit là lớp nền cho toàn bộ hệ thống. PAM ghi lại các sự kiện với đầy đủ context: thời gian, người dùng, hệ thống đích, lý do truy cập, kết quả approval, lệnh thực thi, kết quả password rotation. Trong môi trường compliance nghiêm ngặt, log thường được thiết kế immutable và replicate ra ngoài PAM server để ngăn chặn tampering - cấu hình cụ thể phụ thuộc vào sản phẩm và yêu cầu tổ chức.​

​

Trong thực tế, log PAM thường được đẩy sang SIEM (Splunk, Microsoft Sentinel, IBM QRadar) để tương quan với các event khác: ví dụ, phát hiện một admin đăng nhập PAM lúc 3 giờ sáng từ IP bất thường - ngay cả khi MFA pass, SIEM có thể raise alert dựa trên anomaly behavior.​