Quản lý mật khẩu và SSH key cho team kỹ thuật: mô hình an toàn

Hãy tưởng tượng: một nhân viên cũ vẫn còn SSH key truy cập vào server production — và không ai nhớ đã cấp từ khi nào. Hầu hết sự cố bảo mật liên quan đến máy chủ đều bắt nguồn từ việc quản lý SSH key team lỏng lẻo: key dùng chung, key không bao giờ thu hồi, mật khẩu root dán trong file chat nội bộ.

Bài viết này trình bày mô hình quản lý mật khẩu và SSH key an toàn, áp dụng được từ team 3 người đến vài chục kỹ sư — chỉ cần kỷ luật và quy trình đúng.

Quản lý ssh key team: vì sao SSH key và mật khẩu là điểm yếu của mọi team kỹ thuật?

SSH key và mật khẩu là "chìa khóa" vào toàn bộ hạ tầng: server, database, CI/CD, cloud console. Kẻ tấn công không cần khai thác lỗ hổng phức tạp nếu có trong tay một key hợp lệ — họ đơn giản "đi cửa chính".

Ba vấn đề phổ biến nhất:

Key dùng chung. Cả team dùng một cặp key để SSH vào server. Khi có sự cố, không ai biết ai đã đăng nhập và làm gì. Khi một người nghỉ việc, cả team phải đổi key — việc mà thực tế chẳng ai làm triệt để.

Key không có vòng đời. Key tạo một lần rồi dùng nhiều năm không đổi, không passphrase, private key nằm rải rác trên laptop cá nhân, USB, thậm chí commit nhầm lên GitHub public.

Mật khẩu trong kênh chat. Mật khẩu database, API token gửi qua chat nhóm "cho nhanh", rồi nằm đó vĩnh viễn trong lịch sử trò chuyện.

Hệ quả: bạn không trả lời được ba câu hỏi cơ bản — ai đang có quyền vào đâu, quyền đó còn cần thiết không, và làm sao thu hồi trong vài phút khi có sự cố.

Quản lý ssh key team: nguyên tắc vàng: mỗi người một key, không dùng chung

Nguyên tắc nền tảng: mỗi người một cặp key duy nhất, không bao giờ dùng chung, mỗi key gắn với một danh tính có thể truy vết.

Vì sao không dùng chung? Vì dùng chung là mất khả năng kiểm toán: log SSH chỉ ghi "key deploy đã đăng nhập" — vô dụng khi điều tra sự cố. Với key riêng, mỗi dòng log gắn với một con người cụ thể.

Quy tắc thực hành:

• Mỗi thành viên tự tạo một cặp key cá nhân trên máy của mình; private key không bao giờ rời khỏi máy đó.
• Mỗi server chỉ lưu public key của những người được phép — public key không phải bí mật, có thể chia sẻ tự do.
• Key cho mục đích khác nhau thì tách riêng: key cá nhân để SSH, key riêng cho CI/CD (deploy key giới hạn quyền).
• Đặt tên key có ý nghĩa (ví dụ id_ed25519_laptop-cong-ty) để khi thu hồi, biết chính xác key nào của ai.

Nghe có vẻ phiền hơn "một key xài chung cho nhanh", nhưng đây là cái giá rẻ nhất của bảo mật.

Quản lý ssh key team: tạo và bảo vệ SSH key đúng chuẩn

Chuẩn hiện đại là Ed25519: ngắn gọn, nhanh và an toàn. Cách tạo trên Linux/macOS:

ssh-keygen -t ed25519 -C "ten.ban@cong-ty.vn" -f ~/.ssh/id_ed25519

Ba điểm bắt buộc:

1. Đặt passphrase cho private key — "mật khẩu của chìa khóa": nếu laptop bị mất, kẻ nhặt được vẫn không dùng được key.
2. Comment (-C) ghi rõ danh tính để quản trị viên biết key này của ai khi nhìn vào authorized_keys.
3. Quyền file đúng chuẩn: private key chmod 600, thư mục .ssh là 700. SSH sẽ từ chối key có quyền quá mở.

Trên server, tắt hoàn toàn đăng nhập bằng mật khẩu (PasswordAuthentication no trong sshd_config) và chỉ cho phép key — mật khẩu có thể bị dò brute-force, key Ed25519 thì không.

Cuối cùng: xoay vòng key định kỳ (ví dụ 12 tháng/lần) và ngay lập tức khi nghi ngờ lộ.

SSH Certificate Authority: thay thế việc copy key thủ công

Khi team có 50 server và 30 người, việc copy public key thủ công vào từng authorized_keys thành ác mộng: thêm người mới phải đụng vào 50 server, thu hồi quyền cũng vậy — và chắc chắn sẽ sót.

SSH Certificate Authority (SSH CA) giải quyết triệt để: thay vì server tin từng public key riêng lẻ, server chỉ cần tin một chữ ký của CA. Quy trình:

1. Dựng một CA nội bộ (cặp key đặc biệt được bảo vệ nghiêm ngặt).
2. Mỗi server cấu hình TrustedUserCAKeys trỏ đến public key của CA — làm một lần duy nhất.
3. Khi nhân viên cần truy cập, CA ký public key của họ thành "chứng chỉ SSH" có thời hạn (vài giờ đến vài ngày), ghi rõ được vào những server nào.
4. Nhân viên dùng chứng chỉ để đăng nhập — server xác thực chữ ký CA thay vì tra danh sách key.

Lợi ích lớn nhất: quyền tự hết hạn. Nhân viên nghỉ việc? Đơn giản là không cấp chứng chỉ mới — chứng chỉ cũ tự hết hiệu lực sau vài giờ. Không còn cảnh "quên xóa key" trên server thứ 47.

OpenSSH có sẵn hỗ trợ đầy đủ (ssh-keygen -s), hoặc dùng các giải pháp đóng gói như Smallstep.

Quản lý mật khẩu team: password manager và vault

Ngoài SSH key, team còn hàng chục loại "bí mật": mật khẩu database, API token, key cloud console, tài khoản dịch vụ bên thứ ba. Quy tắc: không bí mật nào nằm trong chat, email hay file text không mã hóa.

Hai tầng công cụ cho hai nhu cầu:

Password manager cho con người (Bitwarden, 1Password, KeePass): lưu mật khẩu các tài khoản mà con người trực tiếp dùng. Tính năng quan trọng nhất là chia sẻ có kiểm soát: tạo vault chung của team, phân quyền ai được xem mục nào.

Secrets manager cho máy móc (HashiCorp Vault hoặc biến môi trường được mã hóa trên server): nơi ứng dụng và script lấy mật khẩu database, API key lúc chạy. Nguyên tắc: ứng dụng đọc secret lúc runtime từ vault, không bao giờ hard-code trong source code hay file cấu hình commit lên Git.

Một thói quen cần xây dựng: mật khẩu mạnh do máy tạo, không do người nghĩ ra. Mọi password manager đều có trình tạo mật khẩu ngẫu nhiên 20+ ký tự — hãy dùng nó cho mọi tài khoản.

Secrets trên server: đừng để mật khẩu nằm trong code

Cách lộ bí mật phổ biến nhất: developer hard-code mật khẩu database vào source code rồi push lên Git — kể cả repo private. Chỉ cần một tài khoản Git bị lộ, hoặc repo bị public nhầm một phút, là toàn bộ credentials "lên sóng".

Quy tắc xử lý secrets trên server:

• Biến môi trường cho cấu hình đơn giản: ứng dụng đọc DB_PASSWORD từ môi trường, giá trị nạp lúc deploy từ vault hoặc file mã hóa chỉ root đọc được.
• File cấu hình riêng ngoài repo: file .env chứa secret nằm trên server, không bao giờ commit — thêm vào .gitignore ngay từ ngày đầu.
• Quét lịch sử Git: dùng git-secrets hoặc GitHub secret scanning để phát hiện secret đã lỡ commit. Nếu đã lộ, đổi ngay — xóa khỏi Git không đủ vì lịch sử vẫn còn.
• Tài khoản database riêng: mỗi ứng dụng một tài khoản với quyền tối thiểu (chỉ thao tác trên đúng schema của nó, không quyền admin). Một ứng dụng bị xâm nhập thì thiệt hại bị nhốt trong phạm vi của nó.

Thu hồi quyền khi nhân sự nghỉ việc: quy trình offboarding

Thời điểm nguy hiểm nhất là khi nhân sự rời đi. Mô hình an toàn đòi hỏi checklist offboarding thực thi ngay trong ngày cuối cùng:

1. Thu hồi SSH: xóa public key khỏi mọi server (hoặc với SSH CA: chỉ cần ngừng cấp chứng chỉ mới). Vô hiệu hóa tài khoản hệ thống của người đó.
2. Thu hồi vault: xóa khỏi password manager chung, xoay vòng các mật khẩu nhạy cảm mà người đó từng thấy.
3. Thu hồi cloud và dịch vụ: xóa khỏi IAM của cloud provider, Git hosting, CI/CD, VPN.
4. Thu hồi vật lý: đổi mã cửa, thu thẻ từ, thu hồi laptop.
5. Rà soát token: thu hồi API token, deploy key mà người đó từng tạo cho công việc.

Điểm mấu chốt: offboarding phải là quy trình có checklist và người chịu trách nhiệm, không phải "nhớ thì làm". Gắn nó vào quy trình nghỉ việc của phòng nhân sự: ticket offboarding phải được tạo ngay khi có quyết định nghỉ việc, không đợi đến ngày cuối cùng.

Với SSH CA + vault tập trung, checklist này chỉ mất vài phút thay vì vài giờ rà soát từng server.

Mô hình an toàn đề xuất theo quy mô team

Đây là lộ trình, không phải "phải làm ngay tất cả". Team nhỏ hãy bắt đầu từ cột đầu tiên — chỉ riêng "mỗi người một key + password manager + checklist offboarding" đã loại bỏ phần lớn rủi ro.

Checklist triển khai trong 1 tuần

Ngày 1 — Kiểm kê: liệt kê toàn bộ server, ai đang có quyền vào đâu (quét authorized_keys từng server), toàn bộ tài khoản dùng chung và mật khẩu đang lưu ở đâu.

Ngày 2 — Dọn dẹp: xóa key của người đã nghỉ, vô hiệu hóa tài khoản không còn dùng, đổi mật khẩu các tài khoản dùng chung quan trọng nhất.

Ngày 3 — Chuẩn hóa key: mọi thành viên tạo key Ed25519 mới có passphrase; cấu hình server tắt đăng nhập mật khẩu, chỉ cho phép key.

Ngày 4 — Dựng vault: triển khai password manager cho team, chuyển toàn bộ mật khẩu dùng chung từ chat/file text vào vault, phân quyền theo nhóm.

Ngày 5 — Quy trình: ban hành checklist onboarding/offboarding bằng văn bản, chỉ định người chịu trách nhiệm, lên lịch rà soát quyền định kỳ 6 tháng/lần.

Sau 1 tuần, team bạn đã ở mức an toàn cao hơn hẳn mặt bằng chung. Các bước nâng cao (SSH CA, secrets manager, bastion host) triển khai dần khi team lớn lên.

Kết luận

Quản lý SSH key team an toàn không phải là mua công cụ đắt tiền, mà là kỷ luật trên 5 trụ cột: mỗi người một key riêng, key đạt chuẩn có passphrase, bí mật nằm trong vault thay vì chat, secrets tách khỏi source code, và offboarding được thực thi nghiêm túc.

Điểm chung của mọi sự cố lộ lọt truy cập là "quyền tồn tại lâu hơn nhu cầu". Mô hình trong bài — từ key cá nhân, password manager đến SSH CA với chứng chỉ ngắn hạn — đều hướng đến một mục tiêu: quyền truy cập chỉ tồn tại đúng lúc cần.

Nếu hạ tầng của bạn đang chạy trên cloud hoặc VPS và bạn muốn nền tảng có sẵn các thực hành bảo mật tốt — đội ngũ SunCloud sẵn sàng tư vấn. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để được hỗ trợ.

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

Dùng chung một SSH key cho cả team có sao không?

Có, và rất nhiều. Key dùng chung khiến bạn mất khả năng truy vết ai đã làm gì trên server, và khi một người nghỉ việc bạn buộc phải đổi key trên toàn bộ hệ thống — việc hiếm khi được làm triệt để. Hãy dùng một key riêng cho mỗi người.

Passphrase của SSH key khác gì mật khẩu đăng nhập server?

Passphrase là "mật khẩu bảo vệ private key" trên máy của bạn — nó mã hóa file key để nếu laptop bị mất, kẻ khác không dùng được key. Mô hình an toàn dùng cả hai lớp: passphrase bảo vệ key lúc "nằm yên", key bảo vệ phiên đăng nhập lúc "di chuyển".

SSH CA có quá phức tạp với team nhỏ không?

Không nhất thiết. Team dưới 10 người với chục server hoàn toàn quản lý tốt bằng key cá nhân + checklist thủ công. SSH CA phát huy giá trị khi số server và nhân sự tăng đến mức copy/thu hồi key thủ công bắt đầu sót — thường từ 20–30 server trở lên.

Nên chọn password manager nào cho team?

Tiêu chí quan trọng hơn thương hiệu: vault chia sẻ theo nhóm với phân quyền chi tiết, có xác thực hai yếu tố (2FA), thu hồi quyền thành viên nhanh, và có nhật ký truy cập. Cả bản self-host lẫn bản cloud đều ổn — hãy chọn theo chính sách bảo mật dữ liệu của công ty bạn.

Phát hiện private key bị lộ lên GitHub thì xử lý thế nào?

Thu hồi ngay key đó trên mọi server, tạo cặp key mới, rà soát log truy cập trong khoảng thời gian key bị lộ để phát hiện đăng nhập bất thường, và đổi các bí mật khác có thể đã bị truy cập qua key đó. Đừng chỉ xóa commit — lịch sử Git vẫn lưu key cũ, nên key cũ phải được coi là đã chết vĩnh viễn.

Có nên bật 2FA cho SSH không?

Nên, với các hệ thống quan trọng (production, database, bastion host). SSH hỗ trợ kết hợp key + mã xác thực hai yếu tố qua PAM với TOTP. Đánh đổi là mỗi lần đăng nhập thêm một bước nhập mã — vì vậy hãy áp dụng 2FA cho các server nhạy cảm nhất trước.