Cách bảo mật credentials và API key trong n8n tự host

n8n mã hóa mọi credential trong database bằng khóa N8N_ENCRYPTION_KEY, nên việc đầu tiên khi tự host là đặt khóa riêng, sao lưu khóa tách khỏi máy chủ và không dán API key thẳng vào node. Sau đó giới hạn ai được xem credential, bật 2FA và xoay vòng key định kỳ. Kho bí mật ngoài như Vault chỉ có ở gói trả phí.

Credential là thông tin xác thực (API key, Client ID/Secret, token, mật khẩu) mà node n8n dùng để gọi dịch vụ khác. Bài áp dụng cho n8n tự host, ví dụ sau khi cài n8n trên VPS; các mục về khóa mã hóa không áp dụng cho n8n Cloud.

Vì sao cần bảo mật credentials và API key trong n8n?

Một n8n tự host thường giữ cùng lúc khóa của Google, CRM, cổng thanh toán, AI, nên lộ credential ở n8n có thể mở đường vào nhiều hệ thống cùng lúc. Rủi ro gồm mất quyền kiểm soát, phát sinh chi phí và rắc rối pháp lý.

Rủi ro thường gặp khi lộ credential

• Mất quyền kiểm soát: người có API key truy cập thẳng tài khoản dịch vụ, đọc hoặc sửa dữ liệu; lộ API key của n8n thì họ sửa được cả workflow.
• Chi phí phát sinh: API key bị lạm dụng để gửi hàng nghìn request, đẩy hóa đơn cloud hoặc AI tăng vọt, hoặc tài khoản bị khóa vì vượt giới hạn.
• Lan sang hệ thống khác: workflow nối nhiều ứng dụng, nên một credential lộ có thể là điểm vào toàn hệ thống.
• Uy tín: sự cố rò rỉ dữ liệu khách hàng lan nhanh và khó gỡ.

Ảnh hưởng đến dữ liệu doanh nghiệp

• Mất dữ liệu: dữ liệu khách hàng, báo cáo, tài chính bị đánh cắp hoặc xóa.
• Gián đoạn: phải thu hồi key gấp làm workflow dừng, chậm việc vận hành.
• Chi phí khắc phục: tốn công điều tra, khôi phục và tăng cường bảo mật sau sự cố.
• Pháp lý: lộ dữ liệu cá nhân có thể vi phạm quy định bảo vệ dữ liệu như GDPR và luật Việt Nam về bảo vệ dữ liệu cá nhân.

n8n lưu và mã hóa credential như thế nào?

n8n lưu credential trong database (SQLite hoặc PostgreSQL) ở dạng đã mã hóa. Khóa mã hóa được tạo ngẫu nhiên ở lần chạy đầu và ghi vào file config trong thư mục .n8n, trừ khi bạn đặt sẵn biến N8N_ENCRYPTION_KEY (Set a custom encryption key). Không có file credential riêng nào cần mã hóa thêm; thứ cần giữ là database và khóa.

5 cấp độ bảo mật credentials và API key trong n8n

Năm cấp độ dưới đi từ việc mọi bản tự host đều nên làm đến các lớp chỉ cần cho đội lớn: đặt bí mật đúng chỗ, giữ khóa mã hóa, dùng kho bí mật ngoài, phân quyền và xoay vòng key.

Cấp độ 1 (cơ bản): Lưu API key trong Credentials, không dán vào node

Mọi API key dùng trong workflow nên nằm trong mục Credentials của n8n: chọn credential có sẵn của node, hoặc với node HTTP Request chọn Authentication là Generic Credential Type (Header Auth, Bearer Auth…). Từ n8n 2.0, biến N8N_BLOCK_ENV_ACCESS_IN_NODE mặc định là true nên biểu thức và Code node không đọc được $env nữa (v2.0 breaking changes, Security environment variables).

File .env vẫn dùng cho cấu hình của chính n8n (mật khẩu database, khóa mã hóa), không phải nơi để API key của workflow. Trong compose.yaml, khai báo env_file: .env và giới hạn quyền đọc file:

# .env (cùng thư mục compose.yaml)
N8N_ENCRYPTION_KEY=chuoi-ngau-nhien-dai-it-nhat-32-ky-tu
DB_POSTGRESDB_PASSWORD=mat-khau-database

chmod 600 .env

Biến cấu hình của n8n còn nhận hậu tố _FILE để đọc giá trị từ một file riêng, ví dụ DB_POSTGRESDB_PASSWORD_FILE trỏ tới Docker secret, giúp mật khẩu không nằm trong biến môi trường.

Cấp độ 2 (nâng cao): Đặt và giữ khóa N8N_ENCRYPTION_KEY

• Tạo chuỗi ngẫu nhiên dài, ví dụ openssl rand -hex 32.
• Thêm vào .env trước lần chạy đầu: N8N_ENCRYPTION_KEY=.... Nếu n8n đã chạy, khóa đang dùng nằm trong file config của .n8n; giữ nguyên khóa đó.
• Không đổi khóa sau khi đã lưu credential: n8n sẽ không giải mã được dữ liệu cũ.
• Cất khóa trong trình quản lý mật khẩu, tách khỏi bản sao lưu database.

Muốn thay khóa định kỳ mà không đụng khóa gốc, n8n có tính năng xoay khóa dữ liệu (encryption key rotation) cho mọi bản tự host: bật mặc định từ n8n 3.0, ở 2.x bật bằng biến N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION, rồi xoay ở Settings > Data Encryption Keys. Sao lưu database trước khi bật và không hạ phiên bản n8n sau đó (Rotate encryption keys).

Cấp độ 3 (doanh nghiệp): Dùng External secrets với Vault hoặc kho bí mật đám mây

External secrets cho phép n8n đọc bí mật từ kho ngoài thay vì lưu trong database: 1Password (Connect Server), AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault và Infisical. Tính năng này cấu hình trong Settings > External Secrets và theo trang tài liệu chỉ có ở gói Enterprise, cả n8n Cloud lẫn tự host (Use external secret stores).

• Thêm kho ở Settings > External Secrets > Add secrets vault, đặt tên kho và nhập thông tin truy cập.
• Trong ô credential, gọi bí mật bằng biểu thức {{ $secrets.<tên-kho>.<tên-bí-mật> }}. Biểu thức này chỉ chạy trong trường của credential.
• Biến môi trường liên quan chỉ là N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL, N8N_EXTERNAL_SECRETS_CONNECT_TIMEOUT, N8N_EXTERNAL_SECRETS_REFRESH_TIMEOUT (External secrets environment variables). Không có biến dạng N8N_CREDENTIALS_VAULT_URL.

Bản Community không có External secrets. Với dự án nhỏ, Credentials được mã hóa cộng khóa giữ cẩn thận là đủ.

Cấp độ 4 (quản lý truy cập): Phân quyền user

Áp dụng nguyên tắc quyền tối thiểu: chỉ người cần mới được dùng credential. Ở bản Community, chỉ Owner và người tạo truy cập được một credential, không chia sẻ cho user khác (Community edition features). Owner xem và sửa được mọi credential, nên n8n khuyên Owner dùng thêm một tài khoản Member cho việc hằng ngày (Understand instance roles).

Ở gói trả phí, bạn chia sẻ credential cho user hoặc project để họ dùng trong node mà không xem được giá trị. Cách thêm user, đổi vai trò, bật 2FA: thêm, xóa và phân quyền user trong n8n.

Cấp độ 5 (giám sát): Kiểm tra và xoay vòng API key định kỳ

Xoay vòng key (tạo key mới, thay vào credential, xóa key cũ) giảm thiệt hại nếu một key bị lộ mà bạn không biết. Key chỉ sống 90 ngày thì thiệt hại ít hơn nhiều so với key không bao giờ hết hạn.

• Mỗi quý rà soát danh sách Credentials, xóa credential không còn workflow nào dùng.
• Xoay key cho dịch vụ quan trọng (thanh toán, AWS, Google Cloud, AI).
• Đặt Expiration cho API key của chính n8n khi tạo ở Settings > n8n API; ở gói Enterprise, giới hạn scope cho từng key (n8n API Authentication).
• Chạy n8n audit để n8n tự liệt kê rủi ro như credential không dùng, node nguy hiểm, webhook công khai (Use the command line).

Những nguyên tắc cần nhớ khi làm việc với credential trong n8n

Bảo mật credential là việc làm đều đặn, không phải làm một lần. Danh sách dưới dùng như checklist định kỳ cho mọi dự án n8n.

1. Không hard-code credential trong workflow

Hard-code là dán thẳng API key, mật khẩu, token vào trường của node, ví dụ ô Header của HTTP Request. Đây là lỗi cơ bản nhưng nguy hiểm:

• Ai xem được workflow cũng thấy và sao chép được key.
• Khi export workflow để chia sẻ hoặc sao lưu, key đi kèm ở dạng chữ thường trong file JSON.
• Khi xoay key, bạn phải dò sửa từng node, dễ sót.

Cách làm đúng: tạo credential (hoặc Generic credential cho HTTP Request) rồi chọn nó trong node. Workflow export ra chỉ chứa tên và ID của credential, không chứa giá trị.

2. Đặt lịch xoay vòng API key

Đừng coi API key là vĩnh viễn. Ghi lịch (ví dụ mỗi 90 ngày hoặc 6 tháng) để rà soát và xoay các key quan trọng, biến việc này thành quy trình chuẩn của nhóm.

3. Cấp quyền tối thiểu trước khi tạo credential

Trước khi tạo API key ở AWS, Google Cloud hay dịch vụ khác, hỏi: workflow này thực sự cần làm gì?

• Không nên: tạo key quyền admin cho tiện vì “biết đâu sau này cần”.
• Nên: chỉ cấp quyền hẹp nhất. Workflow chỉ đọc một bảng thì tạo user database chỉ có quyền SELECT trên bảng đó; chỉ gửi email thì key chỉ có quyền gửi.

4. Đặt tên credential có quy tắc

Khi số credential tăng, tên như “My Google API”, “Stripe Key”, “Test Credential” không cho biết gì. Dùng cấu trúc [Dịch vụ]_[Mục đích]_[Môi trường], ví dụ:

• Stripe_PaymentProcessing_Production
• GoogleSheets_ReadOnly_SalesReports
• AWS_S3Upload_Development

Nhìn tên là biết credential dùng làm gì, cho dự án nào và nhạy cảm đến đâu.

5. Hạn chế dùng chung một credential cho nhiều workflow

Coi mỗi workflow hoặc nhóm chức năng là một ứng dụng riêng với credential riêng, kể cả khi cùng kết nối một dịch vụ. Khi workflow A bị nghi có lỗ hổng, bạn thu hồi credential của A mà không làm dừng B và C.

6. Kiểm tra bảo mật định kỳ

Dành 30 phút mỗi quý để mở danh sách Credentials, xóa credential không dùng, xem key nào sắp hết hạn hoặc đến kỳ xoay, và rà lại quyền của từng user.

7. Chia sẻ credential an toàn trong nhóm

• Không gửi API key qua Slack, email hay chat.
• Dùng trình quản lý mật khẩu (Bitwarden, 1Password) để trao thông tin.
• Ở gói n8n trả phí, chia sẻ quyền dùng credential ngay trong n8n mà không lộ giá trị.

8. Tách credential giữa các môi trường

Credential của môi trường phát triển không được dùng cho môi trường thật. Môi trường dev thường ít được bảo vệ, nhiều người truy cập; dùng chung key là mở đường vào hệ thống thật. Dùng key riêng, ví dụ Stripe test key cho dev và live key cho production.

9. Bật cảnh báo khi API key bị dùng bất thường

• Đặt cảnh báo ngân sách trên AWS Billing khi chi phí tăng đột ngột.
• Đặt cảnh báo trên Google Cloud khi API key được gọi từ IP lạ.

Đây là lớp phòng thủ chủ động, giúp phát hiện sự cố sớm. Cuối cùng, sao lưu credential cùng khóa theo hướng dẫn backup và restore workflow, credential n8n.

Muốn chạy n8n 24/7 mà không tự cài? VPS n8n của Tino cài sẵn n8n trên VPS NVMe đặt tại Việt Nam; bạn vẫn có quyền root để cấu hình. Xem cấu hình và giá trên trang sản phẩm.

Câu hỏi thường gặp