Đánh giá an toàn hạ tầng cloud: phạm vi khảo sát, thời gian và báo cáo bàn giao

Một đợt đánh giá an toàn hạ tầng cloud chỉ có giá trị khi trả lời được ba câu hỏi: hệ thống đang có rủi ro nào, rủi ro nào phải xử lý trước, và ai làm gì trong bao lâu. Bài viết mô tả phạm vi khảo sát, hình dạng của một bản ghi phát hiện, cách xếp hạng mức độ nghiêm trọng, khung thời gian và bộ tài liệu bàn giao.

Khi nào nên đặt lịch đánh giá

Hạ tầng cloud hiếm khi sai từ đầu; nó lệch dần. Một quy tắc firewall mở tạm rồi không đóng lại, một service account được cấp quyền rộng cho kịp deadline, một môi trường staging dựng từ ảnh máy cũ. Sau vài quý, không còn ai nắm được bức tranh tổng thể. Thời điểm thường thấy: sau một đợt migration hoặc gộp nhiều tài khoản; khi thay đổi nhân sự vận hành chủ chốt; khi đối tác gửi bộ câu hỏi rà soát mà nội bộ không trả lời được bằng bằng chứng; và trước khi đưa dữ liệu nhạy cảm hơn lên môi trường dùng chung.

Cần phân biệt rõ: đây không phải kiểm thử xâm nhập, cũng không phải một lần quét cấu hình tự động, mà là khảo sát có cấu trúc trên toàn bộ hạ tầng bằng quyền đọc có kiểm soát, kết thúc bằng danh sách việc đã xếp thứ tự và có chủ sở hữu.

Phạm vi khảo sát

Phạm vi phải chốt bằng văn bản trước khi cấp quyền, liệt kê tài khoản, project, vùng và workload nằm trong và nằm ngoài. Chín nhóm dưới đây là khung thường dùng cho AWS, Google Cloud hoặc mô hình lai.

身份与访问权限

Đối chiếu quyền được cấp với công việc thực tế của từng chủ thể.

• Tài khoản quản trị cấp cao nhất: bao nhiêu, ai giữ, có 身份验证 đa yếu tố không; chính sách IAM dùng ký tự đại diện; khóa lập trình chưa từng xoay vòng.
• Nhân viên bị vô hiệu hóa trong thư mục nội bộ thì quyền trên cloud có mất theo không.

Phơi nhiễm mạng và bề mặt public

Nhìn từ Internet thì ai thấy được gì, và lệch bao nhiêu so với danh mục đội vận hành tin là đang mở.

• Cơ sở dữ liệu và cổng quản trị như SSH hay RDP mở ra dải địa chỉ rộng; kho lưu trữ đối tượng cho phép đọc hoặc ghi ẩn danh.
• Bản ghi DNS trỏ tới tài nguyên đã xóa; môi trường phi sản xuất chứa dữ liệu thật.

Mã hóa và quyền giữ khóa

Mã hóa khi lưu trữ nay là mặc định, nên câu hỏi khó hơn là ai kiểm soát khóa.

• Khóa do nhà cung cấp quản lý hay tổ chức tự quản lý; ai được dùng khóa và ai được lên lịch xóa khóa.
• Chính sách xoay vòng; mã hóa trên đường truyền nội bộ; nơi lưu khóa riêng của chứng chỉ TLS.

Logging và độ phủ phát hiện

Nhật ký chỉ có ích nếu tồn tại đúng lúc và đủ để dựng lại một chuỗi sự việc.

• Nhật ký control plane, truy cập dữ liệu, DNS và luồng mạng: loại nào có, giữ bao lâu, nơi lưu có ngoài tầm với của tài khoản quản trị bị chiếm quyền không.
• Thử dựng lại một hành động quản trị đã xảy ra: có truy được ai làm, lúc nào, từ đâu.

Backup và kiểm chứng restore

Khảo sát tìm bằng chứng phục hồi chứ không tìm lịch chạy sao lưu.

• Danh mục hệ thống có backup đối chiếu danh mục hệ thống quan trọng; bản sao có ở tài khoản hoặc vùng khác không, có bản nào immutable không, ai có quyền xóa.
• Lần gần nhất phục hồi thành công một hệ thống hoàn chỉnh là khi nào và mất bao lâu.

Vá lỗi và trạng thái lỗ hổng

Quan tâm tới quy trình hơn là danh sách lỗ hổng tại một thời điểm.

• Tỷ lệ máy chủ và container trong phạm vi quét; ảnh máy và ảnh container gốc do ai dựng và có quét trước khi phát hành không.
• Thời gian từ khi có bản vá nghiêm trọng tới khi triển khai xong; thành phần hết vòng đời hỗ trợ; thư viện phụ thuộc của ứng dụng.

Quản lý secrets

Xem theo vòng đời: sinh ra ở đâu, đi qua đâu, ai đọc được, thu hồi thế nào.

• Quét toàn bộ lịch sử mã nguồn; biến môi trường trong hệ thống CI; tệp cấu hình nằm trong ảnh container.
• Có kho secrets tập trung không, tỷ lệ ứng dụng dùng nó, và mất bao lâu để xoay vòng toàn bộ.

Truy cập của bên thứ ba và CI/CD

Đường ngắn nhất vào sản xuất thường đi qua chuỗi công cụ phát hành và các nhà cung cấp đã được cấp quyền.

• Danh mục tích hợp bên ngoài đang giữ quyền, và quyền đó có giới hạn phạm vi cùng ràng buộc nguồn gọi không.
• Ai được sửa pipeline và có cần người thứ hai duyệt không; runner tự dựng chạy bằng quyền gì; quyền của nhà thầu có thời hạn không.

Trôi cấu hình

Hạ tầng đang chạy có khớp với mô tả trong mã nguồn không, và lệch bao lâu thì bị phát hiện.

• Tỷ lệ tài nguyên tạo bằng infrastructure as code; số thay đổi thủ công trên sản xuất trong quý gần nhất.
• Có cơ chế phát hiện lệch trạng thái không; quy tắc bảo vệ cấp tổ chức; tài nguyên không có nhãn chủ sở hữu.

Một bản ghi phát hiện gồm những gì

Một phát hiện chỉ dùng được khi người nhận tự kiểm chứng và tự sửa được mà không cần gọi lại người khảo sát. Cấu trúc tối thiểu gồm: mã phát hiện cố định; tiêu đề mô tả sự việc quan sát được; tài nguyên bị ảnh hưởng; bằng chứng kèm thời điểm thu thập; tác động; điều kiện khai thác; mức độ nghiêm trọng kèm lý do xếp mức; khuyến nghị và phương án giảm thiểu tạm thời; cách kiểm chứng sau khi sửa; và ô chủ sở hữu cùng hạn xử lý.

Dưới đây là một bản ghi minh họa; tên tài nguyên và tình huống là giả định:

• Mã: IAM-04
• Tiêu đề: Khóa truy cập lập trình của service account dùng cho pipeline phát hành chưa từng xoay vòng và có quyền ghi trên toàn bộ kho lưu trữ đối tượng của môi trường sản xuất.
• Bằng chứng: danh sách khóa kèm thời điểm tạo và lần dùng gần nhất; nội dung chính sách.
• Tác động và điều kiện khai thác: chỉ cần giá trị khóa vì chính sách không ràng buộc nguồn gọi; người giữ khóa ghi đè hoặc xóa được dữ liệu ở mọi kho sản xuất.
• Mức: Nghiêm trọng, vì quyền rộng, không giới hạn nguồn gọi và đối tượng ảnh hưởng là dữ liệu sản xuất.
• Khuyến nghị: thay khóa dài hạn bằng danh tính liên kết cấp thông tin xác thực ngắn hạn; thu hẹp chính sách; bổ sung ràng buộc nguồn gọi.
• Kiểm chứng: service account không còn khóa dài hạn; ghi thử vào kho ngoài phạm vi bị từ chối.

Xếp hạng mức độ nghiêm trọng

Mức nên dựa trên ba yếu tố có thể tranh luận công khai: mức độ dễ khai thác, phạm vi ảnh hưởng và độ nhạy cảm của dữ liệu liên quan. Mức được gán cho bối cảnh cụ thể chứ không cho loại lỗi nói chung: một kho mở công khai chứa tài liệu tiếp thị và một kho chứa bản xuất cơ sở dữ liệu không thể cùng một mức.

级别	Ý nghĩa	Dạng phát hiện thường gặp	Kỳ vọng xử lý
严重	Dẫn tới truy cập trái phép vào dữ liệu hoặc quyền quản trị, không cần điều kiện đặc biệt	Thông tin xác thực quản trị nằm trong mã nguồn	Xử lý ngay
Cao	Cần thêm một điều kiện nhưng hệ quả vẫn rộng	Cổng quản trị mở ra Internet với xác thực yếu	Đợt phát hành gần nhất
平均	Làm tăng thiệt hại khi một sự cố khác xảy ra	Thiếu nhật ký truy cập dữ liệu	Kế hoạch quý
低	Lệch so với thực hành tốt, tác động trực tiếp hạn chế	Thiếu nhãn chủ sở hữu	Dọn dẹp định kỳ

Cột kỳ vọng xử lý là điểm khởi đầu để thương lượng chứ không phải quy định. Trong buổi bàn giao, từng mức được rà lại cùng đội vận hành; nếu đã có biện pháp bù trừ, mức có thể được hạ và lý do được ghi ngay trong bản ghi.

Từ phát hiện tới kế hoạch khắc phục

Một báo cáo hàng trăm dòng không kèm kế hoạch sẽ nằm yên trong thư mục chia sẻ. Bước chuyển nên diễn ra như sau:

1. Rà soát kỹ thuật cùng đội vận hành để loại dương tính giả và bổ sung bối cảnh.
2. Gộp các phát hiện cùng nguyên nhân gốc; ba mươi bản ghi về quyền quá rộng thường chỉ là một vấn đề về cách cấp quyền.
3. Gán chủ sở hữu theo tên người, không theo tên phòng ban.
4. Chia thành ba đợt: sửa ngay bằng thay đổi cấu hình, làm trong chu kỳ phát hành tới, và thay đổi kiến trúc cần dự án riêng.
5. Đánh dấu thay đổi cần cửa sổ bảo trì kèm phương án quay lui, rồi chốt cách kiểm chứng và lịch tái kiểm tra.

Khung thời gian

Thời lượng phụ thuộc vào số tài khoản, số môi trường và tốc độ cấp quyền đọc. Tiến trình thường đi qua các giai đoạn: chuẩn bị, gồm chốt phạm vi và cấp quyền đọc; thu thập cấu hình, chính sách, nhật ký kèm phỏng vấn ngắn các đội liên quan; phân tích và kiểm chứng lại từng nghi vấn trước khi ghi thành phát hiện; rà soát sơ bộ với bản nháp các phát hiện mức cao; bàn giao và thống nhất mức độ, chủ sở hữu, kế hoạch theo đợt; và tái kiểm tra sau khắc phục. Riêng phát hiện nghiêm trọng được thông báo ngay khi tìm ra.

Bộ tài liệu bàn giao

Đầu ra nên đủ dùng cho ba nhóm người: ban lãnh đạo, kỹ sư thực thi và người theo dõi tiến độ.

• Báo cáo tóm tắt ngắn, không thuật ngữ, nêu rủi ro chính bằng ngôn ngữ tác động kinh doanh.
• Báo cáo kỹ thuật đầy đủ theo cấu trúc bản ghi đã nêu, kèm phụ lục bằng chứng, vốn là dữ liệu nhạy cảm.
• Bảng theo dõi dạng bảng tính hoặc vé công việc, và sơ đồ hiện trạng tài khoản, mạng, luồng dữ liệu chính.
• Kế hoạch khắc phục theo đợt và danh sách câu hỏi mở nằm ngoài phạm vi.

Những giới hạn cần nói rõ

Đánh giá là ảnh chụp tại một thời điểm, giới hạn trong phạm vi đã thống nhất và trong dữ liệu mà tổ chức cấp quyền truy cập. Nó không chứng minh hệ thống chưa từng bị xâm nhập, không thay thế kiểm thử xâm nhập hay rà soát mã nguồn, và không phải một cuộc kiểm toán chứng nhận.

Với các nghĩa vụ pháp lý liên quan tới dữ liệu, nơi lưu trữ và thời hạn lưu giữ, cách làm phù hợp là ghi vào báo cáo dưới dạng câu hỏi cần luật sư có chuyên môn trả lời. Đội kỹ thuật mô tả hiện trạng; kết luận pháp lý thuộc về người có thẩm quyền.

HiTechCloud có thể hỗ trợ gì

HiTechCloud là đối tác của AWS và Google Premier Partner, có hạ tầng đặt trong nước và đội kỹ thuật tại Việt Nam. Trong phạm vi chủ đề này, chúng tôi có thể tham gia ở:

• Khảo sát hiện trạng theo chín nhóm hạng mục nêu trên, trên AWS, Google Cloud hoặc mô hình lai.
• Bàn giao báo cáo theo đúng cấu trúc bản ghi phát hiện, kèm bằng chứng và cách kiểm chứng lại sau khi sửa.
• Cùng đội vận hành của khách hàng lập kế hoạch khắc phục theo đợt và triển khai các hạng mục kỹ thuật.
• Tái kiểm tra sau khắc phục và thiết lập cơ chế theo dõi để hiện trạng không lệch trở lại.

Hãy liên hệ để trao đổi về phạm vi phù hợp với quy mô hệ thống hiện tại.