Postman Vault — quản lý secret

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng một buổi chiều thứ Sáu tại một công ty fintech ở Quận 1, TP.HCM. Một bạn QA junior vừa hoàn thành bộ test cho API thanh toán, hào hứng export collection ra file JSON rồi đẩy lên kênh chat của team để nhờ review. Ba mươi giây sau, một anh senior nhắn riêng: "Em ơi, xoá tin nhắn đó ngay đi." Lý do? Trong file JSON export có nguyên một api_secret_key của môi trường staging nằm chình ình ở phần environment. Cả nhóm 15 người trong kênh, kể cả mấy bạn intern chưa ký NDA đầy đủ, đều đã nhìn thấy.

Đây không phải câu chuyện hiếm. Rò rỉ secret (khoá bí mật, token, mật khẩu) qua Postman là một trong những nguyên nhân phổ biến nhất khiến credential lọt ra ngoài trong các team QA. Và nghịch lý là: chính những tính năng tiện lợi của Postman — chia sẻ collection, đồng bộ lên cloud, export/import — lại là con đường ngắn nhất để secret đi lạc.

Postman Vault ra đời để giải quyết đúng bài toán này. Nó là một kho lưu trữ secret cục bộ (local), chỉ nằm trên máy bạn, không bao giờ đồng bộ lên cloud, và không đi kèm khi bạn export hay share collection. Bài học này sẽ giúp bạn hiểu Vault hoạt động ra sao, khi nào dùng nó thay cho environment variable thông thường, và cách tích hợp Vault vào workflow test hàng ngày để không bao giờ phải nghe câu "xoá tin nhắn đó ngay đi" một lần nào nữa.

Khái niệm cốt lõi

Vấn đề gốc: "Current Value" vẫn không đủ an toàn

Nếu bạn đã học các bài trước về Environments và Variables, bạn biết rằng mỗi biến trong Postman có hai cột giá trị: Initial Value và Current Value.

• Initial Value: giá trị được đồng bộ lên cloud và đi kèm khi bạn share hoặc export. Ai cũng thấy được.
• Current Value: giá trị chỉ nằm local trên máy bạn, không sync, không share.

Nhiều người nghĩ: "Vậy mình cứ để secret vào Current Value là an toàn rồi, đúng không?" Câu trả lời là: an toàn hơn nhưng vẫn có lỗ hổng.

Vấn đề nằm ở ba chỗ:

• Dễ nhầm cột. Trong lúc gõ vội, rất nhiều người dán secret vào Initial Value thay vì Current Value. Chỉ một lần nhầm là secret bay lên cloud và đi vào lịch sử đồng bộ. Ngay cả khi bạn xoá sau đó, nó có thể đã kịp sync sang các thiết bị khác hoặc bị người khác đồng bộ về.
• Export lộ Current Value. Khi bạn export environment ra file JSON để backup hoặc chia sẻ thủ công, Postman ghi cả Current Value vào file. Đây chính xác là cái bẫy trong câu chuyện mở đầu.
• Secret hiện dạng plaintext khi share màn hình. Trong buổi họp review qua Google Meet, chỉ cần bạn mở tab Environment ra là secret hiện nguyên trên màn hình chia sẻ.

Nói cách khác, Current Value là một cơ chế phân tách hiển thị, chứ không phải một cơ chế bảo mật secret thực thụ.

Vault là gì?

Postman Vault là một kho secret riêng biệt, tách hoàn toàn khỏi hệ thống environment và variable thông thường. Bạn có thể hình dung nó như một két sắt cá nhân gắn liền với thiết bị của bạn. Đặc điểm cốt lõi:

• Local-only: Vault secret được lưu mã hoá (encrypted) ngay trên máy bạn và không bao giờ rời khỏi máy. Không lên cloud, không sync giữa các thiết bị.
• Không đi kèm khi share/export: Khi bạn chia sẻ collection hay export environment, các Vault secret không được đóng gói theo. Người nhận sẽ thấy tham chiếu đến secret nhưng không thấy giá trị.
• Được bảo vệ bằng khoá: Lần đầu mở Vault, Postman yêu cầu bạn tạo một Vault key (hoặc dùng cơ chế bảo mật của hệ điều hành). Đây là lớp khoá thêm cho két sắt.
• Tham chiếu qua cú pháp riêng: Bạn dùng secret trong request qua cú pháp {{vault:tên_secret}}, phân biệt rõ với biến thường {{tên_biến}}.

Vault khác gì với Environment Variable?

Đây là điểm nhiều học viên hay lẫn. Tôi tóm gọn sự khác biệt bằng cách trả lời câu hỏi "dữ liệu này có nên sang máy người khác không?":

Quy tắc vàng để nhớ: cái gì là secret thật thì bỏ vào Vault; cái gì chỉ là cấu hình để cả team dùng chung thì để ở environment. Base URL của staging không phải secret — cứ để environment. Nhưng khoá ký request thanh toán thì bắt buộc phải vào Vault.

Vault Integrations — lấy secret từ nơi khác

Một tính năng nâng cao đáng chú ý: Vault có thể tích hợp với các hệ thống quản lý secret bên ngoài như HashiCorp Vault, AWS Secrets Manager, hoặc Azure Key Vault. Thay vì bạn tự gõ secret vào, Postman kéo trực tiếp từ nguồn secret trung tâm của công ty. Điều này cực kỳ hữu ích với team lớn: secret được quản lý tập trung, khi rotate (đổi định kỳ) thì Postman tự lấy giá trị mới, và cá nhân QA không bao giờ phải "cầm" secret trong tay.

Tình huống thực tế

Tình huống 1: Team fintech và vụ export nhầm ở TP.HCM

Quay lại câu chuyện mở đầu. Công ty fintech (ta gọi là PayFast) có 8 QA làm việc trên cùng một workspace Postman. Trước đây họ để payment_signing_key của môi trường sandbox trong Current Value của environment "Staging". Về lý thuyết Current Value không sync, nhưng khi cần backup, một bạn export environment ra file staging.postman_environment.json rồi commit lên repo Git nội bộ để "team ai cũng có thể setup nhanh".

Kết quả: file JSON chứa nguyên payment_signing_key nằm trong lịch sử Git. Sáu tháng sau khi một bạn nghỉ việc, security team audit repo và phát hiện secret bị commit. Họ buộc phải rotate toàn bộ key sandbox, rà soát log xem key có bị lạm dụng không, và mất gần hai ngày công.

Cách Vault giải quyết: Nếu payment_signing_key được đặt trong Vault với cú pháp {{vault:payment_signing_key}}, thì khi export environment, file JSON chỉ chứa tham chiếu {{vault:payment_signing_key}} chứ không có giá trị thật. Commit lên Git bao nhiêu lần cũng không rò rỉ. Mỗi thành viên tự nhập giá trị vào Vault của riêng mình một lần.

Bài học: Bất kỳ giá trị nào có nguy cơ đi vào Git, file backup, hay kênh chat đều phải nằm trong Vault, không phải environment — kể cả Current Value.

Tình huống 2: Agency và bài toán "một máy, nhiều khách hàng"

Một agency test dịch vụ ở Đà Nẵng (gọi là QAHub) nhận outsource kiểm thử API cho ba khách hàng cùng lúc: một sàn thương mại điện tử, một app giao đồ ăn, và một ví điện tử. Mỗi khách cung cấp một bộ API key riêng. Bạn QA tên Linh làm cả ba dự án trên cùng một laptop.

Trước khi dùng Vault, Linh phải tạo ba environment với các Current Value chứa key của từng khách. Rắc rối lớn: khi Linh cần demo test case cho khách A qua màn hình chia sẻ, chỉ cần lỡ tay bấm sang tab environment của khách B là key của khách B hiện ra trước mặt khách A. Trong hợp đồng outsource, đây là vi phạm bảo mật nghiêm trọng.

Cách Vault giải quyết: Linh chuyển toàn bộ key của cả ba khách vào Vault, đặt tên rõ ràng: clientA_api_key, clientB_api_key, clientC_api_key. Trong tab Vault, các giá trị hiển thị mặc định dưới dạng che (masked, hiện dấu chấm). Khi demo cho khách A, dù có mở nhầm gì đi nữa, giá trị secret vẫn ở trạng thái che. Ngoài ra Vault còn cho phép gắn secret với domain cụ thể, nên clientA_api_key chỉ tự động khả dụng khi request bắn tới domain của khách A — giảm nguy cơ vô tình gửi key của khách này sang server của khách kia.

Bài học: Với người làm nhiều dự án trên một máy, Vault vừa là lớp che hiển thị, vừa là hàng rào ngăn secret "đi lạc" sang sai đích.

Tình huống 3: Startup Đông Nam Á và quy trình onboarding

Một startup SaaS phục vụ thị trường Đông Nam Á (gọi là GrowKit) có team QA phân tán ở Việt Nam, Philippines và Indonesia. Họ dùng HashiCorp Vault làm hệ thống secret trung tâm cho toàn công ty. Vấn đề: mỗi khi có QA mới, việc phát secret test qua email hay chat vừa mất thời gian vừa rủi ro.

Cách Vault Integrations giải quyết: GrowKit cấu hình Postman Vault Integration trỏ tới HashiCorp Vault. QA mới chỉ cần được cấp quyền trên HashiCorp Vault, sau đó trong Postman họ tham chiếu secret qua integration mà không ai phải copy-paste giá trị thật. Khi công ty rotate secret hàng quý, không cần thông báo cho từng QA — lần chạy tiếp theo Postman tự kéo giá trị mới.

Bài học: Ở quy mô team lớn hoặc phân tán địa lý, Vault Integration biến việc quản lý secret từ "phát tay từng người" thành "cấp quyền tập trung", giảm cả rủi ro lẫn chi phí vận hành.

Hướng dẫn từng bước

Dưới đây là quy trình đưa một API secret vào Vault và dùng nó trong request.

Bước 1 — Mở Vault. Ở góc dưới bên phải cửa sổ Postman (desktop app), bạn tìm biểu tượng Vault (hình chiếc két/ổ khoá) trên thanh footer. Bấm vào đó. Lần đầu tiên, Postman yêu cầu bạn thiết lập Vault key để bảo vệ kho. Hãy chọn một passphrase đủ mạnh và lưu lại an toàn — nếu mất, bạn sẽ phải reset và nhập lại toàn bộ secret.

Bước 2 — Thêm secret mới. Trong panel Vault, bấm "Add secret" (hoặc dấu +). Bạn nhập:

• Name: tên tham chiếu, ví dụ payment_signing_key. Nên đặt theo quy ước rõ ràng, dễ đoán.
• Value: dán giá trị secret thật vào đây.
• Domain (tuỳ chọn): giới hạn secret chỉ dùng cho các domain nhất định, ví dụ api-sandbox.payfast.vn. Đây là lớp an toàn thêm, nên tận dụng.

Bước 3 — Tham chiếu secret trong request. Ở bất kỳ đâu bạn dùng được biến — URL, header, body, query param — bạn gõ cú pháp:

Authorization: Bearer {{vault:payment_signing_key}}

Postman sẽ tự resolve {{vault:...}} thành giá trị thật lúc gửi request, y như cách nó xử lý biến environment.

Bước 4 — Dùng Vault trong script (nếu cần). Trong pre-request hoặc test script, bạn truy cập Vault qua API bất đồng bộ:

const signingKey = await pm.vault.get("payment_signing_key");
// dùng signingKey để tính chữ ký, ví dụ HMAC

Lưu ý pm.vault.get() trả về Promise, nên phải dùng await (và mặc định script cần được cho phép truy cập Vault — Postman sẽ hỏi quyền lần đầu).

Bước 5 — Kiểm tra secret không rò rỉ. Export thử environment và collection của bạn ra file JSON, mở file bằng trình soạn thảo và tìm chuỗi giá trị secret thật. Nếu bạn chỉ thấy {{vault:payment_signing_key}} mà không thấy giá trị thật — nghĩa là bạn đã làm đúng.

Bước 6 — Chia sẻ cho đồng đội đúng cách. Vì Vault không sync, đồng đội nhận collection của bạn sẽ thấy tham chiếu {{vault:...}} rỗng. Bạn cần hướng dẫn họ tự thêm secret cùng tên vào Vault của họ (hoặc trỏ tới Vault Integration chung). Đây là điểm đánh đổi: an toàn hơn nhưng cần một bước setup thủ công cho mỗi người.

Lỗi thường gặp & mẹo

Lỗi 1: Nhầm giữa Vault và Current Value và nghĩ chúng như nhau. Current Value vẫn bị export ra file; Vault thì không. Nếu mục tiêu của bạn là secret không bao giờ lọt ra file/Git, phải dùng Vault, không được dựa vào Current Value.

Lỗi 2: Quên rằng Vault không sync nên chạy trên máy khác thì request fail. Rất nhiều người bối rối khi collection chạy tốt trên máy mình nhưng đồng đội chạy lại lỗi 401. Nguyên nhân: đồng đội chưa nhập secret vào Vault của họ. Đây là hành vi đúng của Vault, không phải bug. Mẹo: viết một dòng ghi chú trong description của collection liệt kê các Vault secret cần thiết và tên chính xác của chúng.

Lỗi 3: Kỳ vọng Vault chạy được với Newman/CI. Đây là điểm quan trọng cần nhớ. Vault là kho local của Postman desktop app, nó không có mặt khi bạn chạy collection bằng Newman trên CI/CD. Trên môi trường CI, bạn phải truyền secret qua biến môi trường của hệ thống CI (như GitHub Actions secrets) và inject vào Newman qua environment variable, chứ không phải qua Vault. Đừng thiết kế collection kiểu chỉ chạy được nhờ Vault rồi ngạc nhiên khi pipeline đỏ.

Lỗi 4: Đặt tên secret lộn xộn. Khi có 20 secret trong Vault, tên kiểu key1, test_token, abc sẽ khiến bạn không biết cái nào của dự án nào. Hãy đặt theo quy ước <dự_án>_<mục_đích>_<môi_trường>, ví dụ payfast_signing_sandbox.

Mẹo: dùng Domain để "khoá" secret theo đích đến. Gắn domain cho từng secret giúp Postman chỉ gợi ý và cho phép dùng secret khi request bắn tới đúng domain — cực kỳ hữu ích khi bạn quản lý nhiều khách hàng như tình huống agency ở trên.

Mẹo: quên Vault key thì không khôi phục được giá trị. Vault key bảo vệ kho theo cơ chế mã hoá; mất key đồng nghĩa mất quyền giải mã. Hãy lưu Vault key vào một password manager cá nhân đáng tin cậy.

Mẹo: định kỳ rà soát Vault. Cứ mỗi quý, mở Vault và xoá những secret của dự án đã kết thúc. Két sắt gọn gàng thì rủi ro cũng ít đi.

Bài tập thực hành

• Thiết lập Vault đầu tiên. Mở Vault trong Postman, thiết lập Vault key, và thêm một secret tên demo_api_key với giá trị bất kỳ. Tạo một request tới https://postman-echo.com/get và thêm header X-Api-Key: {{vault:demo_api_key}}. Gửi request và xác nhận trong response (postman-echo phản chiếu header) rằng giá trị đã được resolve đúng.

• Chứng minh Vault không rò rỉ. Export environment và collection bạn vừa tạo ra file JSON. Mở file bằng trình soạn thảo văn bản, tìm giá trị secret thật của demo_api_key. Ghi lại nhận xét: bạn có tìm thấy giá trị thật không, và điều đó chứng minh điều gì?

• So sánh với Current Value. Tạo thêm một biến environment demo_current với giá trị đặt ở Current Value. Export lại environment ra file JSON. Tìm giá trị của demo_current trong file. So sánh kết quả với bài tập 2 và viết một đoạn 3–4 câu giải thích vì sao Vault an toàn hơn Current Value cho việc lưu secret.

• Tình huống nhiều khách hàng. Giả lập kịch bản agency: thêm ba secret clientA_key, clientB_key, clientC_key vào Vault, mỗi cái gắn một domain khác nhau. Tạo request tới domain của khách A và thử tham chiếu {{vault:clientB_key}}. Quan sát hành vi và ghi lại việc gắn domain giúp giảm rủi ro như thế nào.

• Suy nghĩ về CI. Viết một đoạn ngắn (5–7 câu) mô tả: nếu collection ở bài tập 1 cần chạy trên GitHub Actions bằng Newman, bạn sẽ cung cấp demo_api_key cho pipeline bằng cách nào (gợi ý: không thể dùng Vault). Bài tập này giúp bạn chuẩn bị cho các bài về Newman và CI/CD.

Tóm tắt

Postman Vault là kho secret cục bộ, mã hoá, không sync lên cloud và không đi kèm khi share/export — chính là mảnh ghép còn thiếu để đóng lại lỗ hổng mà Current Value không xử lý triệt để. Quy tắc cốt lõi cần khắc ghi: cấu hình dùng chung thì để environment, secret thật thì bỏ vào Vault với cú pháp {{vault:tên_secret}}.

Qua ba tình huống — vụ export nhầm ở công ty fintech, bài toán một-máy-nhiều-khách của agency, và mô hình secret trung tâm của startup phân tán — ta thấy Vault không chỉ bảo vệ giá trị mà còn định hình lại cách team làm việc với secret: từ "phát tay và cầu mong không ai lỡ tay" sang "an toàn theo thiết kế".

Đừng quên hai giới hạn quan trọng: Vault không có mặt trên Newman/CI (secret ở đó phải truyền qua biến môi trường của hệ thống CI), và vì không sync nên mỗi đồng đội phải tự thiết lập secret của mình. Nắm chắc Vault, bạn đã có một thói quen bảo mật mà rất nhiều QA có kinh nghiệm vẫn còn thiếu — và bạn sẽ không bao giờ phải nghe câu "xoá tin nhắn đó ngay đi" nữa.