Credential n8n lưu ở đâu và bảo vệ thế nào cho an toàn

Gõ API key của phần mềm kế toán vào node HTTP Request, bấm lưu, workflow chạy. Đoạn đó mất ba giây. Nhưng từ giây thứ tư, chuỗi ký tự đó đã rời tay bạn và bắt đầu một hành trình qua ba nơi khác nhau: bộ nhớ tạm lúc nhập, cơ chế mã hoá của n8n, rồi bảng credentials trong database. Biết đường đi này mới biết chỗ nào cần khoá.

Credential n8n lưu ở đâu sau khi bạn nhập vào form

Credential n8n lưu trong database chính của n8n, ở dạng đã mã hoá, chung nơi với bảng workflow và execution log. Không có kho lưu trữ riêng cho phần bí mật. Mã hoá và giải mã đều xảy ra ngay trên máy chủ chạy n8n.

Bạn điền API key vào ô credential rồi bấm lưu. n8n mã hoá chuỗi đó bằng khoá N8N_ENCRYPTION_KEY trước khi ghi xuống database. Theo tài liệu chính thức của n8n, thuật toán dùng là AES-256-GCM. Bản mã hoá nằm trong cột data của bảng credentials_entity. Mở database bằng công cụ quản trị thông thường chỉ thấy một chuỗi ký tự vô nghĩa, không đọc được key gốc nếu thiếu khoá giải mã.

Điểm dễ bỏ qua: file database và bản sao lưu của nó vẫn là một tệp bình thường trên đĩa. Ai đọc được thư mục dữ liệu, dù không biết khoá mã hoá, vẫn lấy được toàn bộ bảng credentials đã mã hoá về máy mình. Giới hạn quyền đọc thư mục đó cho đúng một tài khoản chạy n8n là việc cần làm ở tầng hệ điều hành, trước cả khoá mã hoá. Đây là phần quản trị máy chủ thường xử lý. Giải mã ngoại tuyến khi có thời gian là bước tiếp theo họ thử.

N8N_ENCRYPTION_KEY giữ vai trò gì trong toàn bộ chuỗi bảo vệ

N8N_ENCRYPTION_KEY là biến môi trường duy nhất đứng giữa credential đã mã hoá và credential đọc được. Mất khoá này, mọi API key trong database coi như khoá vĩnh viễn. Chính bạn cũng không mở lại được.

Không đặt biến này, n8n tự sinh một khoá ngẫu nhiên lúc khởi động lần đầu rồi ghi vào file cấu hình cục bộ. Cài lại container hoặc dựng máy mới mà quên chép file đó theo, khoá cũ biến mất. Toàn bộ credential trong database export sang trở thành chuỗi mã hoá không ai đọc được nữa, kể cả n8n. Vì vậy khoá phải đặt tường minh qua biến môi trường, lưu một bản riêng tách khỏi máy chủ chạy workflow.

Ba nơi không nên cất bản sao khoá: file cấu hình đẩy lên Git, tin nhắn nội bộ nhóm, ổ đĩa dùng chung không phân quyền. Một trình quản lý mật khẩu có kiểm soát truy cập hợp lý hơn cả ba.

Ai xem được credential và cách lưu nào rủi ro nhất

Ba nhóm nhìn thấy credential ở dạng đọc được: người có quyền chỉnh sửa credential đó trong n8n, tiến trình n8n lúc thực thi node gọi dịch vụ ngoài, và bất kỳ ai đọc được biến môi trường của container. Ngoài ba nhóm này, không ai đọc được nội dung gốc nếu thiếu khoá mã hoá.

Giao diện n8n che giá trị credential sau khi lưu, ô nhập chỉ hiện dấu chấm. Nhưng che trên giao diện không ngăn được ai đó gọi credential trong node Function rồi log giá trị ra execution history. Log thực thi lưu cùng database. Ai vô tình in credential ra log, dữ liệu nhạy cảm đó nằm y nguyên ở một chỗ khác, không được mã hoá theo cùng cơ chế với bảng credentials_entity.

Không phải mọi cách cấu hình credential rủi ro như nhau. Bảng dưới xếp theo mức lộ dữ liệu nếu máy chủ hoặc tài khoản bị chiếm quyền, tính trên một kịch bản chung: kẻ tấn công đã vào được server.

Hàng cuối là lỗi hay gặp khi đội kỹ thuật muốn tiết kiệm bước cấu hình: gán API key thẳng vào biến môi trường container thay vì tạo credential qua giao diện n8n. Cách này bỏ qua lớp mã hoá AES-256-GCM, biến chuỗi bí mật thành một dòng cấu hình mà tiến trình nào đọc được biến môi trường cũng đọc được.

Quyền truy cập credential nên chia theo vai trò nào

n8n bản có phân quyền cho phép gán credential theo người dùng hoặc theo project. Không phải ai đăng nhập cũng thấy toàn bộ danh sách API key của công ty. Chia nhỏ quyền này cắt phạm vi thiệt hại khi một tài khoản bị lộ mật khẩu đăng nhập.

Nguyên tắc thực tế: người dựng workflow marketing không cần quyền đọc credential kết nối phần mềm kế toán. Gộp chung một tài khoản admin cho cả đội, một mật khẩu lộ kéo theo toàn bộ API key công ty lộ theo, kể cả những cái không liên quan gì tới người bị lộ tài khoản.

Tài khoản chạy workflow, không phải tài khoản cá nhân

Workflow chạy theo lịch cron nên đứng dưới một credential dịch vụ riêng, tách khỏi tài khoản cá nhân của người từng tạo ra nó. Người đó nghỉ việc, đổi phòng ban, workflow vẫn chạy bình thường vì không phụ thuộc credential cá nhân của họ.

Xem lại danh sách người có quyền định kỳ

Danh sách quyền credential nên rà lại mỗi khi có người rời đội automation, không đợi tới lúc phát sinh sự cố mới lục lại ai còn quyền gì. Một tài khoản cũ còn quyền đọc credential là một cửa mở không ai để ý.

Xoay khoá API định kỳ có thật sự cần thiết không

Xoay khoá API nghĩa là tạo API key mới ở phía dịch vụ ngoài, cập nhật credential trong n8n, rồi vô hiệu hoá key cũ. Cần thiết với credential có quyền ghi hoặc xoá dữ liệu. Ít cấp thiết hơn với key chỉ đọc dữ liệu công khai.

Không phải dịch vụ nào cũng hỗ trợ tạo nhiều key song song cho cùng một tài khoản. Trước khi xoay khoá, kiểm tra dịch vụ đó có giữ key cũ hoạt động trong lúc key mới đã áp dụng hay không. Không thì workflow đứng hình ngay khoảnh khắc chuyển đổi. Credential kết nối phần mềm kế toán hoặc CRM đang chạy nhiều workflow phụ thuộc thì đổi khoá vào giờ thấp điểm, kiểm tra execution log ngay sau đó.

Tần suất xoay khoá hợp lý phụ thuộc mức nhạy cảm của dữ liệu credential đó chạm tới. Không có một con số áp dụng chung cho mọi API. Ưu tiên xoay trước với credential có quyền ghi hoặc xoá dữ liệu, để sau với key chỉ đọc dữ liệu công khai.

Biến môi trường có phải chỗ an toàn để giấu credential

Biến môi trường an toàn hơn hardcode trong workflow, nhưng không phải nơi ẩn tuyệt đối. Bất kỳ tiến trình chạy cùng quyền với n8n trên máy chủ đó đều đọc được toàn bộ biến môi trường của nó, kể cả N8N_ENCRYPTION_KEY.

Điều này đặt ra một ranh giới rõ. Bảo vệ credential trong database bằng mã hoá là một lớp. Bảo vệ chính máy chủ chạy n8n khỏi bị truy cập trái phép là lớp khác, không thay thế cho nhau được. Giới hạn SSH theo IP, khoá quyền đọc file cấu hình chỉ cho tài khoản chạy n8n, cập nhật vá lỗi hệ điều hành đều nằm ở lớp thứ hai này. Máy chủ để cổng SSH mở cho mọi IP thì lớp mã hoá credential ở trên gần như hết nghĩa lý bảo vệ thực tế.

Câu hỏi thường gặp về credential n8n

Điều cần nhớ

• Credential mã hoá bằng AES-256-GCM trước khi ghi vào database, khoá là N8N_ENCRYPTION_KEY đặt riêng qua biến môi trường.
• Mất khoá mã hoá là mất vĩnh viễn, không có cách khôi phục ngược lại từ bản mã hoá.
• Bảo vệ chính máy chủ chạy n8n quan trọng ngang bảo vệ khoá, vì ai đọc được biến môi trường thì đọc được khoá.
• Chia quyền credential theo vai trò, không gộp một tài khoản admin cho cả đội automation.
• Ưu tiên xoay khoá API trước với credential có quyền ghi hoặc xoá dữ liệu.

Dựng lại từ đầu trên VPS quản lý được cả biến môi trường lẫn database là cách kiểm soát trọn chuỗi này. Đội quản trị máy chủ BizMaC hỗ trợ phần vá lỗi hệ điều hành và giới hạn truy cập ở lớp hạ tầng, phần còn lại là cấu hình N8N_ENCRYPTION_KEY và phân quyền credential đúng theo vai trò trong đội bạn.