Vì sao việc này cứ bị hoãn

Rà soát quyền truy cập nằm trong mọi khung kiểm soát an toàn thông tin, và ở hầu hết tổ chức nó cũng nằm trong danh sách những việc sẽ làm khi rảnh. Lý do không phải là nó khó, mà là nó nghe như một dự án: liệt kê toàn bộ danh tính, đối chiếu với nhân sự, dựng ma trận vai trò, xin phê duyệt của từng chủ sở hữu hệ thống. Đặt bài toán như vậy thì đúng là mất vài tuần, nên nó không bao giờ bắt đầu.

Bài viết này đặt bài toán khác: mục tiêu không phải hoàn hảo mà là tìm ra những rủi ro lớn nhất trong thời gian ngắn nhất. Tám hạng mục dưới đây xếp theo tỷ lệ giữa rủi ro và công sức, tổng cộng khoảng ba tiếng cho một môi trường cỡ vừa.

Chuẩn bị mười lăm phút

Chuẩn bị ba thứ. Thứ nhất, danh sách toàn bộ tài khoản cloud, project hoặc subscription tổ chức đang dùng. Việc này khó hơn vẻ ngoài, vì thường có tài khoản do một bộ phận tự mở bằng thẻ tín dụng, hoặc tài khoản dự án cũ chưa đóng. Đối chiếu với kế toán về các khoản chi cho nhà cung cấp cloud là cách nhanh nhất để tìm ra chúng.

Thứ hai, một bản xuất danh tính. Trên AWS, báo cáo thông tin xác thực cho bạn gần như mọi thứ cần cho ba hạng mục đầu tiên trong một file:

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > creds.csv

Trên Google Cloud, xuất chính sách IAM của từng project:

gcloud projects get-iam-policy PROJECT_ID --format=json

Thứ ba, một bảng tính trống với các cột: hạng mục, phát hiện, mức độ, người chịu trách nhiệm, hành động, hạn xử lý. Nếu không ghi lại, buổi rà soát chỉ tạo ra cảm giác đã làm gì đó.

1. Tài khoản root và tài khoản đặc quyền (20 phút)

Đây là hạng mục quan trọng nhất và cũng nhanh nhất, nên luôn làm đầu tiên.

Kiểm tra gì: tài khoản root hoặc owner của từng tài khoản cloud, danh sách người có quyền quản trị toàn phần, và thời điểm đăng nhập gần nhất của tài khoản root. Với AWS, đó là các danh tính gắn policy quyền quản trị đầy đủ; với Google Cloud, đó là các vai trò owner và các vai trò admin ở cấp tổ chức.

Thế nào là đạt: tài khoản root không có access key hoạt động, được bảo vệ bằng MFA, và không có lần đăng nhập nào trong kỳ ngoài trường hợp đã ghi nhận. Số người có quyền quản trị toàn phần đếm được trên một bàn tay, đều còn làm việc và thực sự cần quyền đó.

Làm gì với phát hiện: access key của root phải bị xóa ngay trong buổi rà soát. Quyền quản trị cấp cho người không còn cần thì thu hồi. Nếu ai đó cần quyền cao nhưng không thường xuyên, chuyển sang nâng quyền tạm thời có phê duyệt thay vì quyền thường trực.

2. Độ phủ MFA (15 phút)

Kiểm tra gì: tỷ lệ tài khoản người dùng có bật xác thực đa yếu tố, và quan trọng hơn là danh sách cụ thể những tài khoản chưa bật. Nếu tổ chức dùng nhà cung cấp danh tính tập trung thì kiểm tra ở đó, đồng thời kiểm tra xem có tài khoản cục bộ nào trên cloud đi vòng qua nhà cung cấp danh tính hay không.

Thế nào là đạt: mọi tài khoản người dùng đăng nhập được bằng mật khẩu đều có MFA, không có ngoại lệ theo phòng ban hay theo cấp bậc. Các tài khoản dùng chung, nếu buộc phải tồn tại, có MFA gắn với thiết bị do tổ chức quản lý chứ không phải điện thoại cá nhân của một người.

Làm gì với phát hiện: đặt hạn cụ thể và ngắn cho việc bật MFA, thường là trong tuần. Sau hạn đó, vô hiệu hóa khả năng đăng nhập bằng mật khẩu thay vì tiếp tục nhắc. Nếu có thể, áp dụng chính sách bắt buộc MFA ở cấp tổ chức để lần sau không phải kiểm tra thủ công.

3. Tài khoản người dùng tồn đọng (20 phút)

Kiểm tra gì: tài khoản chưa từng đăng nhập, tài khoản không đăng nhập trong chín mươi ngày trở lên, và tài khoản thuộc về người đã nghỉ việc hoặc chuyển bộ phận. Đối chiếu danh sách danh tính với danh sách nhân sự đang làm việc do bộ phận nhân sự cung cấp.

Thế nào là đạt: mọi tài khoản trong hệ thống ứng với một người đang làm việc và đang cần truy cập. Không có tài khoản nào chưa từng dùng tồn tại quá vài tuần kể từ khi tạo.

Làm gì với phát hiện: vô hiệu hóa trước, xóa sau. Vô hiệu hóa ngay là an toàn và có thể đảo ngược nếu bạn nhầm; xóa hẳn sau ba mươi ngày nếu không ai phản hồi. Quan trọng hơn phần dọn dẹp là phần nguyên nhân: nếu tìm thấy tài khoản của người đã nghỉ, quy trình offboarding có lỗ hổng và cần sửa, nếu không thì quý sau bạn sẽ tìm thấy đúng những vấn đề như vậy.

4. Service account và key dài hạn (25 phút)

Hạng mục cho ra nhiều phát hiện nhất, vì danh tính máy không có ai nghỉ việc để kích hoạt quy trình dọn dẹp.

Kiểm tra gì: toàn bộ access key, service account key và token dài hạn, kèm ngày tạo và ngày dùng gần nhất. Chú ý ba nhóm: key trên một năm tuổi, key chưa từng dùng, và key gắn với danh tính quyền cao.

Thế nào là đạt: không có key tĩnh cho workload chạy bên trong cloud, vì chúng nên dùng danh tính gắn với tài nguyên như instance role hoặc workload identity. Các key còn lại, dành cho hệ thống bên ngoài hoặc CI/CD, đều có chủ sở hữu xác định, phạm vi quyền hẹp và lịch xoay vòng.

Làm gì với phát hiện: key chưa từng dùng thì vô hiệu hóa ngay, rủi ro gần như bằng không. Key có dùng nhưng không rõ chủ sở hữu thì tra log để xem nguồn gọi đến từ đâu trước khi động vào. Key cũ đang dùng thật thì lên lịch xoay vòng thay vì tắt đột ngột. Ngoài ra hãy kiểm tra xem có key nào từng bị đưa vào repository mã nguồn không, vì key đã lộ trong lịch sử git vẫn còn nguyên giá trị với người tìm được nó.

5. Policy wildcard quá rộng (20 phút)

Kiểm tra gì: các policy tự viết có dấu sao ở phần hành động hoặc tài nguyên. Đặc biệt chú ý policy cho phép mọi hành động trên mọi tài nguyên, và policy cho phép các hành động liên quan tới quyền hạn như tạo người dùng, gắn policy, tạo access key hoặc đóng vai trò khác. Một danh tính có thể tự sửa quyền của chính nó thực chất là quản trị viên.

Thế nào là đạt: policy cấp cho ứng dụng chỉ liệt kê các hành động ứng dụng thực sự dùng, và giới hạn trên các tài nguyên cụ thể. Quyền sửa đổi phân quyền chỉ nằm ở nhóm quản trị.

Làm gì với phát hiện: đừng sửa policy production ngay trong buổi rà soát, vì siết quyền là cách nhanh nhất làm hỏng một dịch vụ đang chạy. Ghi lại, giao cho đội sở hữu ứng dụng thay bằng policy hẹp hơn dựa trên nhật ký sử dụng thật. Policy cho phép leo thang quyền là ngoại lệ đáng xử lý sớm hơn.

6. Cross-account trust và federation (15 phút)

Kiểm tra gì: các vai trò cho phép danh tính từ tài khoản khác đóng vai, liên kết federation với nhà cung cấp danh tính bên ngoài, và quyền cấp cho nhà cung cấp dịch vụ hoặc đối tác. Đọc kỹ điều kiện tin cậy: bên kia là ai, có ràng buộc thêm không.

Thế nào là đạt: mỗi quan hệ tin cậy tương ứng với một hợp đồng hoặc dự án đang hoạt động mà bạn biết. Vai trò cấp cho bên thứ ba có điều kiện ràng buộc bổ sung và phạm vi quyền tối thiểu.

Làm gì với phát hiện: quan hệ tin cậy không giải thích được là mức độ cao, phải truy nguồn ngay. Quan hệ với đối tác đã kết thúc hợp đồng thì gỡ bỏ. Nếu bạn không xác định được ai đã tạo, hãy kiểm tra nhật ký hoạt động quản trị quanh thời điểm tạo.

7. Phơi bày ra Internet (20 phút)

Kiểm tra gì: bucket lưu trữ đối tượng cho phép truy cập ẩn danh, snapshot hoặc image chia sẻ công khai, cơ sở dữ liệu có địa chỉ công khai, và các nhóm bảo mật mở cổng quản trị ra toàn Internet. Cổng SSH và RDP mở với nguồn không giới hạn là trường hợp đáng tìm đầu tiên.

Thế nào là đạt: không có lưu trữ công khai ngoài nội dung cố ý công khai và đã ghi nhận, như tài nguyên tĩnh của website. Không có cổng quản trị mở ra Internet; truy cập quản trị đi qua VPN hoặc bastion.

Làm gì với phát hiện: hạng mục này nên xử lý ngay trong buổi rà soát, vì rủi ro cao mà tác động vận hành thường thấp. Với dữ liệu đã công khai, ngoài việc đóng lại còn phải xem nhật ký truy cập để đánh giá đã có ai lấy chưa, và báo cáo lên quản lý nếu có dấu hiệu.

8. Quyền được cấp nhưng không dùng (15 phút)

Kiểm tra gì: khoảng cách giữa quyền được cấp và quyền thực sự dùng. Các nhà cung cấp cloud lớn đều có công cụ phân tích truy cập cho biết dịch vụ nào chưa từng được một danh tính gọi tới trong khoảng thời gian quan sát.

Thế nào là đạt: với các danh tính quan trọng, tập quyền được cấp gần với tập quyền thực dùng. Danh tính chưa từng chạm tới một dịch vụ trong sáu tháng thì không cần quyền trên dịch vụ đó.

Làm gì với phát hiện: đây là hạng mục cải tiến dần chứ không phải xử lý gấp. Chọn ra ba đến năm danh tính có quyền rộng nhất, giao việc thu hẹp cho chu kỳ tới, và bỏ qua phần đuôi dài. Cắt quyền theo dữ liệu sử dụng cần cửa sổ quan sát đủ dài để không cắt nhầm những việc chỉ chạy theo tháng hoặc theo quý.

Xử lý phát hiện

Kết thúc buổi rà soát, bạn có một danh sách. Hãy phân loại thành ba mức để không rơi vào tình trạng mọi thứ đều khẩn cấp và vì thế không việc nào được làm.

Mức	Ví dụ	Hành động
Xử lý ngay	Access key của root, dữ liệu công khai ngoài ý muốn, cổng quản trị mở ra Internet, tài khoản của người đã nghỉ vẫn hoạt động	Sửa trong ngày, ghi lại thời điểm và người thực hiện
Xử lý trong kỳ	Thiếu MFA, key dài hạn chưa xoay vòng, quan hệ tin cậy không rõ nguồn gốc	Giao người chịu trách nhiệm, hạn trong hai tuần
Cải tiến dần	Policy wildcard, quyền thừa, tài khoản dùng chung	Đưa vào kế hoạch quý, theo dõi qua các kỳ rà soát

Hai việc cuối làm cho lần sau nhanh hơn hẳn: ghi lại các lệnh và bộ lọc đã dùng vào một tài liệu ngắn, và với mỗi phát hiện lặp lại giữa hai kỳ, hỏi xem có thể chuyển nó thành cảnh báo tự động hay không. Rà soát định kỳ là để bắt những gì tự động hóa chưa bắt được.

HiTechCloud có thể hỗ trợ gì

HiTechCloud hỗ trợ doanh nghiệp tại Việt Nam rà soát cấu hình quyền truy cập trên AWS và Google Cloud, thiết lập chính sách MFA và quản lý danh tính tập trung, chuyển workload từ key tĩnh sang danh tính gắn với tài nguyên, và dựng cảnh báo tự động cho thay đổi phân quyền. Chúng tôi 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.