Vì sao cấp quyền admin đại trà là rủi ro lớn nhất trong hạ tầng cloud

Trong hầu hết các đợt rà soát hạ tầng cloud mà một doanh nghiệp tự thực hiện, phát hiện gây khó chịu nhất hiếm khi là một lỗ hổng phần mềm. Nó thường là một danh sách: danh sách những người, và những chương trình, đang giữ quyền quản trị toàn phần trên tài khoản cloud mà không ai còn nhớ lý do. Một lập trình viên đã chuyển bộ phận từ năm ngoái. Một tài khoản dùng cho đợt di chuyển dữ liệu đã kết thúc. Một khóa truy cập được sinh ra để thử nghiệm rồi nằm lại trong một biến môi trường. Từng mục riêng lẻ đều có vẻ vô hại. Cộng lại, chúng là bề mặt tấn công lớn nhất mà tổ chức đang tự tạo ra cho mình.

Quyền quản trị không nguy hiểm vì nó mạnh. Nó nguy hiểm vì nó xóa bỏ mọi ranh giới còn lại. Khi một danh tính có quyền toàn phần, hệ thống không còn cách nào phân biệt giữa một thao tác vận hành bình thường và một thao tác phá hoại. Mọi biện pháp kiểm soát khác mà bạn đã đầu tư, từ phân vùng mạng, mã hóa, đến nhật ký kiểm toán, đều nằm trong tầm với của chính danh tính đó.

Vì sao quyền admin trở thành mặc định

Rất ít tổ chức chủ động quyết định phát quyền admin cho tất cả. Tình trạng đó hình thành dần, và luôn vì những lý do hợp lý tại thời điểm phát sinh.

• Tốc độ trong giai đoạn đầu. Khi mới chuyển lên cloud, đội kỹ thuật cần thử nghiệm nhanh. Cấp quyền rộng là cách nhanh nhất để không bị chặn. Giai đoạn thử nghiệm kết thúc, nhưng quyền thì không được thu hồi.
• Không ai biết chính xác cần quyền gì. Một dịch vụ cần ghi vào kho đối tượng, đọc từ hàng đợi và gửi chỉ số giám sát. Xác định đúng tập quyền tối thiểu mất vài giờ; cấp quyền quản trị mất ba mươi giây. Áp lực tiến độ luôn chọn phương án ba mươi giây.
• Sợ gây gián đoạn. Khi hệ thống đã chạy, việc thu hẹp quyền bị coi là hành động rủi ro. Không ai muốn là người khiến hệ thống thanh toán dừng vào chiều thứ Sáu.
• Quyền được sao chép theo mẫu. Người mới được cấp quyền bằng cách nhân bản tài khoản của một đồng nghiệp cũ. Tập quyền của người cũ vốn đã quá rộng, và nó được nhân lên theo mỗi lần tuyển dụng.

Kết quả là một trạng thái mà nhiều tổ chức chỉ nhận ra khi đã ở trong đó: số lượng danh tính có thể xóa toàn bộ môi trường sản xuất lớn hơn nhiều so với số người thực sự cần khả năng đó.

Bán kính thiệt hại: lập luận mà cấp quản lý chấp nhận

Trình bày least privilege như một yêu cầu kỹ thuật thường thất bại ở cấp phê duyệt ngân sách. Trình bày nó như một bài toán bán kính thiệt hại thì hiệu quả hơn nhiều, vì đó là ngôn ngữ mà ban lãnh đạo vốn đã dùng cho rủi ro vận hành.

Câu hỏi cần đặt không phải là ai đáng tin. Câu hỏi là: nếu một danh tính bất kỳ trong danh sách này bị chiếm quyền vào lúc hai giờ sáng, phạm vi tổn thất tối đa là gì và mất bao lâu để khôi phục? Với một tài khoản quyền hẹp, câu trả lời có thể là một dịch vụ trong một môi trường, khôi phục trong một giờ. Với một tài khoản quyền toàn phần, câu trả lời là toàn bộ hạ tầng, bao gồm cả các bản 备份 và nhật ký chứng minh điều gì đã xảy ra.

Cách diễn đạt này chuyển cuộc thảo luận khỏi vấn đề lòng tin cá nhân, vốn luôn gây căng thẳng nội bộ. Không ai bị nghi ngờ. Điều được thừa nhận đơn giản là: danh tính có thể bị chiếm quyền mà chủ sở hữu không hay biết, và tổ chức nên thiết kế sao cho một sự cố như vậy không đồng nghĩa với việc mất tất cả.

Least privilege trong thực tế

Nguyên tắc thì ai cũng biết. Phần khó nằm ở cách triển khai mà không làm tê liệt đội kỹ thuật.

Bắt đầu từ dữ liệu sử dụng thực tế, không từ sơ đồ tổ chức

Cách tiếp cận sai là ngồi họp và tự hỏi mỗi vai trò nên có quyền gì. Cách tiếp cận đúng là bật nhật ký hoạt động của nền tảng và quan sát các danh tính thực sự gọi những API nào trong vòng ba mươi đến chín mươi ngày. Các nhà cung cấp cloud lớn đều có công cụ tạo chính sách từ lịch sử truy cập. Kết quả sinh ra không nên được áp dụng nguyên trạng, nhưng nó cho bạn một điểm khởi đầu dựa trên bằng chứng thay vì phỏng đoán.

Thu hẹp theo từng bước, có thể quay lui

Đừng chuyển thẳng từ quyền toàn phần sang quyền tối thiểu. Hãy đi qua các nấc: bỏ quyền xóa trước, sau đó bỏ quyền thay đổi cấu hình danh tính, rồi giới hạn theo môi trường, cuối cùng mới giới hạn theo tài nguyên cụ thể. Mỗi nấc nên chạy ở chế độ chỉ ghi nhật ký cảnh báo trong một khoảng thời gian trước khi thực thi chặn.

Gắn quyền vào vai trò, không vào con người

Khi quyền được gắn trực tiếp vào từng người dùng, tập quyền sẽ chỉ tăng và không bao giờ giảm, vì không ai chủ động xin bị thu quyền. Khi quyền gắn vào vai trò và người dùng được gán vai trò, việc chuyển bộ phận hoặc rời công ty sẽ tự động điều chỉnh quyền. Đây cũng là điều kiện tiên quyết để rà soát định kỳ có ý nghĩa: rà soát hai mươi vai trò là khả thi, rà soát bốn trăm chính sách cá nhân thì không.

Dùng ranh giới cứng thay vì chỉ dùng chính sách

Chính sách quyền có thể bị chỉnh sửa bởi người có quyền chỉnh sửa chính sách. Vì vậy, các biện pháp kiểm soát quan trọng nhất nên nằm ở tầng cao hơn: tách môi trường sản xuất sang tài khoản cloud riêng, đặt chính sách ở cấp tổ chức mà tài khoản con không thể tự gỡ, và giới hạn vùng địa lý được phép tạo tài nguyên. Ranh giới ở tầng tổ chức là thứ mà một danh tính bị chiếm quyền bên trong một tài khoản con không tự vượt qua được.

Break-glass thay cho quyền admin thường trực

Mọi tổ chức đều cần khả năng can thiệp toàn phần khi có sự cố nghiêm trọng. Điều không cần thiết là khả năng đó tồn tại thường trực trong tay nhiều người.

Mô hình break-glass tách hai thứ này ra. Tổ chức duy trì một số rất ít tài khoản khẩn cấp có quyền cao, thường là hai đến ba, đủ để tránh tình huống người giữ tài khoản duy nhất không liên lạc được. Các tài khoản này không dùng cho công việc hằng ngày, không gắn với hộp thư cá nhân, được bảo vệ bằng phương thức 身份验证 mạnh với yếu tố vật lý, và thông tin xác thực được lưu tách biệt khỏi hệ thống mà chúng dùng để đăng nhập.

Điều làm cho mô hình này có giá trị không phải là bản thân tài khoản, mà là hệ thống cảnh báo quanh nó. Mỗi lần một tài khoản break-glass được sử dụng, cảnh báo phải đi thẳng đến nhiều người theo kênh độc lập, kèm theo yêu cầu giải trình sau sự cố. Một lần đăng nhập break-glass không có sự cố tương ứng là tín hiệu điều tra ưu tiên cao nhất mà hệ thống của bạn có thể tạo ra.

Một chi tiết thường bị bỏ sót: các tài khoản này cần được kiểm tra định kỳ. Thông tin xác thực hết hạn, yếu tố xác thực vật lý bị thất lạc, quy trình được ghi trong một tài liệu nằm trên chính hệ thống đang gặp sự cố. Hãy diễn tập việc mở tài khoản khẩn cấp ít nhất mỗi năm, giống như diễn tập khôi phục dữ liệu.

Nâng quyền có thời hạn

Giữa quyền tối thiểu hằng ngày và tài khoản khẩn cấp có một khoảng trống lớn: những tác vụ hợp lệ, có kế hoạch, cần quyền cao hơn bình thường. Đây là nơi nâng quyền có thời hạn phát huy tác dụng.

Cơ chế rất đơn giản. Kỹ sư làm việc hằng ngày với quyền đọc và quyền vận hành hạn chế. Khi cần thực hiện thay đổi lớn, họ yêu cầu nâng quyền, nêu lý do và thời lượng. Yêu cầu được duyệt bởi người khác, quyền được cấp trong khoảng thời gian giới hạn, và tự động hết hiệu lực. Không cần ai nhớ thu hồi.

Ba yếu tố quyết định mô hình này thành công hay bị vô hiệu hóa trong thực tế:

• Độ trễ phê duyệt phải thấp. Nếu việc nâng quyền mất bốn tiếng, đội kỹ thuật sẽ tìm đường vòng, thường là một tài khoản dùng chung không ai giám sát. Quy trình duyệt cần tính bằng phút và phải hoạt động ngoài giờ hành chính.
• Lý do phải được ghi lại và liên kết với công việc. Gắn yêu cầu nâng quyền với mã sự cố hoặc mã thay đổi tương ứng biến nhật ký quyền thành hồ sơ có thể kiểm tra được, thay vì một danh sách sự kiện không ngữ cảnh.
• Thời hạn phải ngắn và không tự gia hạn. Một phiên nâng quyền kéo dài cả ngày làm việc về bản chất chỉ là quyền thường trực với thêm vài bước thủ tục.

Service account: nhóm admin bị lãng quên

Khi một tổ chức nói rằng họ đã siết quyền admin, điều họ thường muốn nói là họ đã siết quyền cho nhân viên. Trong khi đó, số lượng danh tính phi con người trong một hạ tầng cloud trưởng thành thường vượt xa số nhân viên: vai trò cho máy chủ ứng dụng, hệ thống tích hợp liên tục, công cụ hạ tầng dưới dạng mã, tác nhân giám sát, dịch vụ sao lưu, các tích hợp bên thứ ba.

Nhóm này nguy hiểm hơn theo nhiều cách. Nó không dùng xác thực đa yếu tố. Nó thường xác thực bằng khóa dài hạn thay vì thông tin xác thực tạm thời. Nó chạy liên tục, nên hành vi bất thường khó bị nhận ra hơn so với một nhân viên đăng nhập lúc ba giờ sáng. Và không ai rời công ty, nên không có sự kiện tự nhiên nào kích hoạt việc thu hồi.

Những việc cần làm với nhóm này:

• Lập danh sách đầy đủ và gán chủ sở hữu. Mỗi danh tính phi con người phải có một đội chịu trách nhiệm. Danh tính không có chủ sở hữu là ứng viên đầu tiên để vô hiệu hóa.
• Loại bỏ khóa truy cập dài hạn ở nơi có thể. Ưu tiên vai trò gắn với tài nguyên tính toán và cơ chế liên kết danh tính, để thông tin xác thực được cấp phát tạm thời và tự hết hạn thay vì nằm trong tệp cấu hình.
• Giới hạn theo điều kiện, không chỉ theo hành động. Một vai trò chỉ nên dùng được từ nguồn mạng dự kiến, trên tài nguyên có nhãn dự kiến, trong môi trường dự kiến.
• Theo dõi thời điểm sử dụng cuối cùng. Danh tính và khóa không được dùng trong chín mươi ngày nên được vô hiệu hóa trước, xóa sau. Vô hiệu hóa trước cho phép khôi phục nhanh nếu hóa ra nó vẫn cần thiết.
• Tách quyền của hệ thống triển khai. Hệ thống tích hợp liên tục thường là danh tính mạnh nhất trong toàn bộ hạ tầng. Nó nên có vai trò riêng cho từng môi trường, và vai trò triển khai vào môi trường sản xuất không nên nằm cùng chỗ với vai trò dùng cho nhánh phát triển.

Đo lường tiến độ bằng chỉ số vận hành

Không thể quản lý thứ không đo được. Một vài chỉ số đơn giản đủ để biết tổ chức đang đi đúng hướng.

指标	Ý nghĩa
Số danh tính có quyền quản trị thường trực	Mục tiêu là tiến gần về không, ngoài các tài khoản break-glass
Tỷ lệ tác vụ quyền cao đi qua nâng quyền có thời hạn	Cho biết quy trình đang được dùng hay bị đi vòng
Số khóa truy cập dài hạn còn hiệu lực	Phản ánh mức độ phụ thuộc vào thông tin xác thực tĩnh
Số danh tính phi con người không có chủ sở hữu	Đo phần hạ tầng không ai chịu trách nhiệm
Thời gian trung bình để thu hồi quyền khi nhân sự rời đi	Kiểm chứng quy trình offboarding có thực sự chạm tới cloud không

Lộ trình thực tế cho ba tháng đầu

Một chương trình quá tham vọng sẽ chết trong quý đầu tiên. Trình tự sau giữ được rủi ro thấp và tạo kết quả nhìn thấy được.

1. Tháng thứ nhất: nhìn rõ hiện trạng. Xuất danh sách toàn bộ danh tính con người và phi con người kèm quyền hiệu lực. Bật đầy đủ nhật ký hoạt động ở mọi tài khoản và mọi vùng, ghi vào nơi lưu trữ tách biệt.
2. Tháng thứ hai: xử lý phần dễ và rủi ro cao. Vô hiệu hóa danh tính không hoạt động, thu hồi khóa dài hạn không còn dùng, bật xác thực đa yếu tố bắt buộc cho mọi người dùng, thiết lập tài khoản break-glass và cảnh báo đi kèm.
3. Tháng thứ ba: đưa quy trình vào vận hành. Triển khai nâng quyền có thời hạn cho một đội thử nghiệm, chuyển quyền cá nhân sang vai trò, đặt ranh giới ở cấp tổ chức cho các hành vi không bao giờ được phép, chẳng hạn tắt nhật ký kiểm toán hoặc xóa cấu hình sao lưu.

Sau đó, việc rà soát quyền nên trở thành hoạt động định kỳ có lịch cố định, do chủ sở hữu hệ thống xác nhận, chứ không phải một dự án được khởi động lại mỗi khi có sự cố.

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 hiện trạng phân quyền trên tài khoản cloud, xây dựng mô hình vai trò và ranh giới ở cấp tổ chức, thiết lập tài khoản break-glass cùng cảnh báo tương ứng, triển khai nâng quyền có thời hạn, và kiểm kê nhóm danh tính phi con người thường bị bỏ sót. Nếu doanh nghiệp của bạn đang cần xác định điểm bắt đầu, hãy liên hệ để trao đổi về hiện trạng cụ thể của hệ thống.