Khi một doanh nghiệp phát hiện dữ liệu nội bộ của mình có thể truy cập được từ Internet, phản ứng đầu tiên thường là tìm kẻ tấn công. Trong nhiều trường hợp, không có kẻ tấn công nào cả, ít nhất là chưa. Dữ liệu đơn giản là đã ở trạng thái công khai kể từ ngày nó được tạo ra, vì một hộp chọn được để nguyên, một dải địa chỉ được mở tạm rồi quên đóng, hoặc một chính sách truy cập được sao chép từ tài liệu hướng dẫn dành cho môi trường thử nghiệm.

Đây là điểm khác biệt căn bản giữa an toàn trên cloud và an toàn trong trung tâm dữ liệu truyền thống. Trong mô hình cũ, để một dịch vụ nội bộ ra được Internet cần nhiều bước chủ động: mở cổng trên tường lửa, cấu hình NAT, xin phê duyệt. Trên cloud, khoảng cách giữa nội bộ và công khai đôi khi chỉ là một tham số trong một tệp cấu hình mà người viết không nhận ra ý nghĩa của nó.

Bài viết này liệt kê các nhóm cấu hình sơ hở thường gặp nhất và cách rà soát chúng trong chính hạ tầng của bạn. Trọng tâm là phát hiện và khắc phục, không phải tìm kiếm hệ thống của người khác.

Kho lưu trữ đối tượng ở chế độ công khai

Đây là nhóm phổ biến nhất, và cũng là nhóm gây hậu quả nghiêm trọng nhất, vì kho đối tượng thường chứa bản 备份 cơ sở dữ liệu, tệp tải lên của người dùng, báo cáo xuất ra và nhật ký ứng dụng.

Trạng thái công khai có thể phát sinh theo nhiều đường khác nhau, và việc kiểm tra một đường không đủ:

Chính sách truy cập cấp bucket cho phép truy cập ẩn danh.
Danh sách kiểm soát truy cập ở cấp từng đối tượng, có thể công khai ngay cả khi bucket không công khai.
Cấu hình lưu trữ trang tĩnh, biến toàn bộ nội dung thành nội dung web.
Liên kết chia sẻ có chữ ký với thời hạn quá dài hoặc không thời hạn.
Mạng phân phối nội dung đặt trước bucket, trong đó bucket được cấu hình riêng tư nhưng lớp phân phối lại phục vụ công khai toàn bộ đường dẫn.

Cách rà soát: dùng chức năng chặn truy cập công khai ở cấp tài khoản của nhà cung cấp, đây là công tắc mạnh nhất vì nó áp dụng bất kể cấu hình ở cấp bucket. Sau đó rà từng bucket còn được miễn trừ và ghi lại lý do. Bật báo cáo phân tích quyền truy cập nếu nền tảng có hỗ trợ, vì nó phát hiện cả các đường truy cập gián tiếp qua tài khoản bên ngoài. Với dữ liệu nhạy cảm, bật mã hóa bằng khóa do khách hàng quản lý, để một cấu hình công khai vô ý không tự động đồng nghĩa với việc đọc được nội dung.

Chính sách IAM quá rộng và ký tự đại diện

Một chính sách cho phép mọi hành động trên mọi tài nguyên là dạng dễ nhận ra. Các dạng khó nhận ra hơn thường nguy hiểm hơn vì chúng trông có vẻ đã được giới hạn:

Giới hạn hành động nhưng để nguyên phạm vi tài nguyên, ví dụ cho phép mọi thao tác đọc trên toàn bộ tài khoản.
Nhóm hành động quản trị danh tính bị lẫn vào chính sách ứng dụng, cho phép một dịch vụ tự sửa quyền của chính nó.
Chính sách tin cậy cho phép danh tính từ tài khoản bên ngoài đảm nhận vai trò mà không có điều kiện định danh bổ sung.
Quyền được cấp gián tiếp qua việc cho phép chuyển vai trò sang một dịch vụ tính toán, tạo đường vòng quanh mọi giới hạn phía trên.

Cách rà soát: đừng đọc chính sách, hãy đánh giá quyền hiệu lực. Các nền tảng đều có công cụ mô phỏng để trả lời câu hỏi danh tính này có thực hiện được hành động này trên tài nguyên này hay không, sau khi tính cả các lớp chồng lên nhau. Đặc biệt chú ý các chính sách cho phép tài khoản bên ngoài truy cập, và luôn yêu cầu điều kiện định danh bổ sung khi cấp quyền cho bên thứ ba.

Nhóm bảo mật và quy tắc mạng mở rộng

Quy tắc cho phép truy cập từ toàn bộ Internet vào cổng quản trị là trường hợp kinh điển. Nó gần như luôn được tạo ra với ý định tạm thời: một kỹ sư cần truy cập từ nhà, đường truyền VPN đang hỏng, một nhà thầu cần vào gấp trong đêm.

Ngoài cổng quản trị, các trường hợp thường bị bỏ qua gồm: cổng cơ sở dữ liệu mở ra ngoài để một công cụ báo cáo kết nối được; nhóm bảo mật tham chiếu lẫn nhau tạo thành chuỗi cho phép rộng hơn dự kiến; quy tắc mở toàn dải cổng thay vì cổng cụ thể; và địa chỉ IP công khai được gán cho tài nguyên đáng lẽ chỉ nằm trong mạng riêng.

Cách rà soát: liệt kê toàn bộ quy tắc cho phép nguồn là toàn bộ Internet, phân loại theo cổng đích và gán hạn chót xử lý. Thay thế truy cập quản trị trực tiếp bằng dịch vụ phiên quản trị của nhà cung cấp hoặc máy chủ trung gian có ghi nhật ký, để không cần mở cổng quản trị ra ngoài. Dùng công cụ phân tích khả năng tiếp cận mạng để xác nhận đường đi thực tế, vì một quy tắc trông chặt vẫn có thể bị vô hiệu bởi một bảng định tuyến hoặc một cân bằng tải phía trước.

Giao diện quản trị và cơ sở dữ liệu lộ ra ngoài

Nhóm này không chỉ là cổng mở mà là dịch vụ thực sự đang lắng nghe và trả lời từ Internet. Các dạng thường gặp:

Bảng điều khiển quản trị của ứng dụng, hệ quản trị nội dung hoặc công cụ nội bộ được triển khai kèm theo ứng dụng chính.
Cơ sở dữ liệu và bộ nhớ đệm được tạo với cấu hình mặc định cho phép truy cập công khai, đôi khi không bật 身份验证.
Giao diện quản lý cụm và bảng điều khiển giám sát, vốn thường chứa nhiều thông tin về cấu trúc hệ thống.
Điểm cuối chẩn đoán của khung phát triển bị để lại trong bản triển khai sản xuất.
Máy chủ tệp và giao thức chia sẻ nội bộ được bật trên tài nguyên có địa chỉ công khai.

Cách rà soát: lập danh sách toàn bộ địa chỉ IP công khai, tên miền và bộ cân bằng tải thuộc quyền sở hữu của doanh nghiệp, rồi đối chiếu với danh sách dịch vụ được phép công khai. Mọi thứ không nằm trong danh sách cho phép cần có chủ sở hữu giải trình. Đặt các thành phần quản trị sau mạng riêng, yêu cầu xác thực tập trung, và tách môi trường thử nghiệm khỏi môi trường sản xuất ở cấp tài khoản để một bản triển khai thử không vô tình được công khai kèm dữ liệu thật.

Khóa truy cập dài hạn

Thông tin xác thực tĩnh không tự làm lộ dữ liệu, nhưng nó là thứ biến một sơ hở nhỏ thành quyền truy cập lâu dài. Khóa dài hạn có xu hướng lan ra ngoài phạm vi dự kiến: vào kho mã nguồn, vào biến môi trường của hệ thống tích hợp liên tục, vào tệp cấu hình trên máy cá nhân, vào ảnh chụp màn hình trong tài liệu nội bộ.

Cách rà soát: báo cáo thông tin xác thực của nền tảng cho biết khóa nào tồn tại, được tạo khi nào và lần cuối sử dụng khi nào. Xóa khóa không dùng. Với khóa còn dùng, chuyển dần sang thông tin xác thực tạm thời thông qua vai trò gắn với tài nguyên tính toán hoặc liên kết danh tính từ hệ thống nhận dạng của doanh nghiệp. Bật quét bí mật trên kho mã nguồn và trong quy trình xây dựng. Xây dựng sẵn quy trình xoay khóa và diễn tập nó, vì việc xoay khóa lần đầu trong lúc đang có sự cố là tình huống tệ nhất để phát hiện ra rằng có bốn dịch vụ khác đang dùng chung khóa đó.

Nhật ký bị tắt hoặc không đầy đủ

Đây là nhóm cấu hình không trực tiếp làm lộ dữ liệu, nhưng nó quyết định việc bạn có thể trả lời được câu hỏi quan trọng nhất sau sự cố hay không: dữ liệu có thực sự bị truy cập không, bởi ai, và những gì đã bị lấy đi.

Các thiếu sót thường gặp: nhật ký hoạt động chỉ bật ở một vùng trong khi tài nguyên trải trên nhiều vùng; nhật ký truy cập dữ liệu không được bật vì lý do chi phí; thời gian lưu trữ ngắn hơn thời gian một sự cố thường bị phát hiện; nhật ký được lưu trong cùng tài khoản với hệ thống được giám sát, nên một danh tính bị chiếm quyền có thể xóa cả bằng chứng; và không có cảnh báo nào khi nhật ký bị tắt.

Cách rà soát: bật ghi nhật ký ở cấp tổ chức, áp dụng cho mọi tài khoản và vùng, bao gồm cả vùng không sử dụng. Ghi vào một tài khoản riêng chỉ dùng cho lưu trữ nhật ký, với quyền ghi thêm nhưng không cho phép sửa hoặc xóa. Đặt thời gian lưu tối thiểu đủ dài để phục vụ điều tra. Quan trọng nhất, tạo cảnh báo cho chính hành động tắt nhật ký hoặc thay đổi cấu hình lưu trữ nhật ký.

Ảnh chụp, bản sao lưu và ảnh máy ảo được chia sẻ công khai

Nhóm này ít được nhắc tới nhưng có mức độ nghiêm trọng cao, vì một ảnh chụp ổ đĩa hoặc ảnh máy ảo thường chứa toàn bộ nội dung của một hệ thống, bao gồm cả tệp cấu hình có thông tin xác thực.

Các trường hợp cần kiểm tra: ảnh chụp ổ đĩa và ảnh chụp cơ sở dữ liệu có thuộc tính chia sẻ công khai; ảnh máy ảo tùy chỉnh được chia sẻ để phục vụ một dự án hợp tác rồi không thu hồi; bản sao lưu được sao chép sang vùng khác nhưng chính sách truy cập không đi kèm; và kho chứa ảnh vùng chứa được đặt ở chế độ công khai để đơn giản hóa quá trình triển khai.

Cách rà soát: liệt kê toàn bộ ảnh chụp và ảnh máy ảo có thuộc tính chia sẻ ra ngoài tài khoản, ở tất cả các vùng. Thiết lập chính sách ở cấp tổ chức ngăn việc chia sẻ công khai. Với các ảnh cần chia sẻ với đối tác, chia sẻ trực tiếp tới tài khoản cụ thể thay vì đặt công khai, và ghi lại thời hạn thu hồi.

Vì sao khắc phục một lần là không đủ

Một đợt rà soát thủ công sẽ sạch trong khoảng vài tuần. Sau đó hạ tầng tiếp tục thay đổi, và các cấu hình sơ hở quay lại theo đúng những con đường cũ. Ba biện pháp giúp trạng thái sạch tồn tại lâu hơn:

Ngăn chặn ở tầng cao hơn tài khoản. Các chính sách ở cấp tổ chức, chặn truy cập công khai ở cấp tài khoản, và giới hạn vùng được phép sử dụng là những biện pháp không bị vô hiệu bởi một thay đổi cục bộ.
Kiểm tra trong quy trình triển khai. Nếu hạ tầng được mô tả bằng mã, hãy quét cấu hình trước khi triển khai. Chi phí sửa một dòng trong yêu cầu thay đổi thấp hơn nhiều so với chi phí xử lý một tài nguyên đã chạy trong môi trường sản xuất.
Giám sát liên tục và phát hiện lệch chuẩn. Bật dịch vụ đánh giá cấu hình của nhà cung cấp, đặt quy tắc cho các trạng thái không được phép, và đưa cảnh báo vào cùng kênh mà đội vận hành đã theo dõi hằng ngày. Cảnh báo gửi vào một hộp thư không ai mở thì tương đương với không có cảnh báo.

Cuối cùng, hãy phân biệt rõ hai hoạt động: rà soát cấu hình trong hạ tầng của chính doanh nghiệp là hoạt động vận hành bình thường và nên làm định kỳ. Việc dò quét hệ thống không thuộc quyền sở hữu hoặc không được ủy quyền bằng văn bản là chuyện hoàn toàn khác, và không nằm trong phạm vi bài viết này.

HiTechCloud có thể hỗ trợ gì

HiTechCloud là đối tác của AWS và Google Premier Partner, đồng thời vận hành hạ tầng đặt trong nước. Chúng tôi hỗ trợ doanh nghiệp rà soát cấu hình hiện trạng trên tài khoản cloud, thiết lập các biện pháp ngăn chặn ở cấp tổ chức, đưa bước kiểm tra cấu hình vào quy trình triển khai, và cấu hình hệ thống ghi nhật ký tách biệt phục vụ điều tra. Nếu doanh nghiệp của bạn cần một đợt rà soát có phạm vi rõ ràng, hãy liên hệ để trao đổi về hiện trạng cụ thể.