Secret Management Architectures: Finding the balance between security and complexity

Slalom Build · 2017 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bài của một công ty tư vấn: khung ba mức và hai kiến trúc đã dựng cho khách hàng (không nêu tên). Mọi nhận định ở đây là theo Slalom.

Bối cảnh

• Nhiều team để secret dạng plain text trong code hoặc file cấu hình, chỉ dựa vào việc repo là private. Slalom đề nghị tự hỏi: nhân viên nghỉ thì rotate secret có dễ không, bị lộ thì mất bao lâu để khoanh vùng, có audit được ai đọc secret tháng trước không, tách quyền dev/prod được không, nhiều cloud và ứng dụng có đọc được không.

Thay đổi chính

• Ba mức phức tạp, đi dần theo nhu cầu: (1) giới hạn truy cập (repo private); (2) mã hoá secret trước khi lưu; (3) quản lý (ứng dụng điều khiển ai đọc được, audit log, TTL).
• Các mảnh ghép:
  • git-crypt: mã hoá file theo .gitattributes qua git hook; nhiều key cho một repo nên dev và prod nằm chung chỗ mà quyền giải mã tách riêng. Nhược điểm: conflict trên file mã hoá không hiện dấu merge, nên tách repo chỉ chứa secret để ít người sửa.
  • AWS KMS: mã hoá chính key mã hoá rồi lưu bản đã mã hoá cạnh secret, trả lời câu "key mã hoá thì cất ở đâu" bằng cách tin AWS; phụ thuộc vào độ sẵn sàng của KMS.
  • Chef Vault: node đang provision lấy secret từ Chef Server theo query; danh sách quyền là tĩnh, node mới đăng ký sau không đọc được cho tới khi chạy lại query bằng tay.
  • HashiCorp Vault: ACL, audit, TTL, nhiều backend xác thực và lưu trữ; cái giá là cần người vận hành server và danh sách quyền.
• Kiến trúc 1 (khách đang ở mức 1, ít người và kỹ năng): secret trong repo riêng mã hoá bằng git-crypt; Jenkins giải mã và đẩy lên Chef Server qua Chef Vault, kèm một job 5 phút một lần làm mới danh sách quyền để vá nhược điểm danh sách tĩnh. Chưa giải quyết rotation và quản lý key git-crypt.
• Kiến trúc 2 (cần ACL và cho cả ứng dụng ngoài Chef): EC2 user-data tải một ứng dụng nhỏ từ S3 để xác thực với Vault và lưu token trước khi Chef chạy; chef-client dùng token đó đọc secret. Khách muốn "vá" instance tại chỗ thay vì tạo lại, nên phải thêm cron làm mới token trước khi TTL hết.

Vì sao

• Theo Slalom, mục tiêu là mức an toàn chấp nhận được cho dự án; đến một điểm, độ phức tạp của lớp bảo vệ thêm lớn hơn lợi ích. Cho team làm quen công cụ rồi mới nâng mức.

Bài học cho SWE

• Mỗi lớp mã hoá sinh ra một secret mới (key); câu hỏi là neo niềm tin vào đâu (KMS, Vault), không phải thêm lớp mãi.
• Danh sách quyền tĩnh hay token có TTL đều buộc phải có tiến trình làm mới; instance sống lâu (vá tại chỗ) làm bài toán secret khó hơn instance dùng một lần.
• Kiến trúc trung gian (git-crypt + Chef) vẫn có giá trị nếu nó là bậc để lên mức tiếp theo.

Liên quan

• Bảo mật hạ tầng và quản lý secret
• Cùng công ty: Slalom Build 2018 · Slalom Build 2016 · Slalom Build 2019
• Cùng bài toán: Monzo 2019 · Uber 2025 · GoCardless 2020