Khung bảo mật của Microsoft Azure đang phải đối mặt với sự giám sát chặt chẽ sau khi các nhà nghiên cứu phát hiện ra những lỗ hổng nghiêm trọng cho phép kẻ tấn công xâm phạm khóa VPN và xâm nhập vào mạng doanh nghiệp. Những phát hiện này, được công bố bởi Wiz Research Team , tiết lộ cách thức các vai trò có quá nhiều quyền và điểm yếu API tạo ra nhiều đường tấn công cho các đối tượng độc hại.
Lỗ hổng tập trung xung quanh dịch vụ REACT của Azure , thành phần nội bộ của Microsoft quản lý việc phân quyền vai trò và chuyển đổi chúng thành định nghĩa vai trò. Mặc dù được thiết kế để bảo mật với bề mặt tấn công nhỏ, các nhà nghiên cứu đã tìm ra cách thức để thao túng các vai trò này và có được quyền truy cập trái phép vào các tài nguyên quan trọng.
Đường tấn công VPN Azure:
- Kẻ tấn công giành được quyền truy cập đặc quyền vào Azure Connectors
- Liệt kê tất cả các cổng mạng ảo (có thể thực hiện mà không cần quyền đọc subscription)
- Gọi lệnh GET trên các tài nguyên kết nối cổng mạng ảo
- Lấy được các khóa chia sẻ để truy cập VPN
- Có được khả năng xâm nhập mạng
 |
|---|
| Khám phá Azure Role Roulette: Phân tích cách các lỗ hổng làm lộ mạng lưới doanh nghiệp |
Kiến Trúc Phức Tạp Tạo Ra Điểm Mù Bảo Mật
Phương pháp phát triển phân tán của Azure đã tạo ra một mê cung các dịch vụ kết nối với nhau mà ngay cả các kỹ sư có kinh nghiệm cũng gặp khó khăn trong việc điều hướng. Tài liệu của nền tảng này nổi tiếng là phân mảnh, với thông tin thiết yếu được rải rác trên nhiều bài viết. Sự phức tạp này không chỉ là vấn đề về khả năng sử dụng - nó đang trở thành mối quan ngại nghiêm trọng về bảo mật.
Nghiên cứu nhấn mạnh cách thức hệ thống kiểm soát truy cập dựa trên vai trò của Azure có thể bị khai thác thông qua các quyền tưởng chừng vô hại. Kẻ tấn công với quyền nâng cao có thể liệt kê các cổng mạng ảo, truy xuất khóa chia sẻ, và cuối cùng có được quyền truy cập VPN vào mạng doanh nghiệp. Đường tấn công bao gồm việc gọi các yêu cầu GET trên tài nguyên kết nối cổng mạng ảo, làm lộ các khóa chia sẻ cần thiết cho xác thực VPN .
 |
|---|
| Hiểu về quy trình lấy khóa chia sẻ thông qua các hoạt động API của Azure |
Trải Nghiệm Nhà Phát Triển Phản Ánh Những Vấn Đề Sâu Xa Hơn
Sự thất vọng của cộng đồng với Azure vượt ra ngoài các vấn đề bảo mật đến những lựa chọn thiết kế cơ bản. Nhiều nhà phát triển báo cáo rằng Azure cảm thấy như một tập hợp các dịch vụ được xây dựng bởi các nhóm khác nhau với ít sự phối hợp, thay vì một nền tảng gắn kết. Sự phân mảnh này thể hiện trong mọi thứ từ sự chồng chéo dịch vụ gây nhầm lẫn đến các quy trình triển khai phức tạp không cần thiết.
Khá rõ ràng nếu bạn kiểm tra github rằng các dịch vụ và tài liệu của Azure được viết bởi các nhóm phân tán với ít sự phối hợp. Chúng tôi có một câu nói nội bộ rằng thông tin đều có trong tài liệu của họ, nhưng các câu và đoạn văn ngay cả cho những thứ tầm thường cũng được chia tách trên mười hoặc mười lăm bài viết.
Cách tiếp cận của nền tảng đối với điện toán serverless đặc biệt làm thất vọng các nhà phát triển. Không giống như AWS Lambda , cho phép triển khai hàm trực tiếp, Azure yêu cầu người dùng cung cấp các kế hoạch dịch vụ, ứng dụng hàm, và tài khoản lưu trữ ngay cả cho các hàm serverless đơn giản. Sự phức tạp này tạo ra nhiều cơ hội hơn cho việc cấu hình sai có thể dẫn đến lỗ hổng bảo mật.
Độ phức tạp Serverless của Azure so với AWS:
- AWS Lambda: Triển khai function trực tiếp
- Azure Functions: Yêu cầu cung cấp service plan + function app + storage account + resource group
- Azure cung cấp nhiều loại plan (Consumption, Flex Consumption, App Service Plan)
- Độ phức tạp bổ sung mà không có lợi ích rõ ràng cho các trường hợp sử dụng đơn giản
Việc Áp Dụng Doanh Nghiệp Bất Chấp Những Thiếu Sót Kỹ Thuật
Bất chấp những vấn đề này, Azure tiếp tục thu hút khách hàng doanh nghiệp, thường thông qua các mối quan hệ kinh doanh hơn là giá trị kỹ thuật. Nhiều tổ chức chọn Azure do các quan hệ đối tác Microsoft hiện có, yêu cầu cư trú dữ liệu, hoặc giảm giá khối lượng thay vì sở thích kỹ thuật. Động lực này có nghĩa là Microsoft phải đối mặt với ít áp lực hơn để giải quyết các mối quan ngại về khả năng sử dụng và bảo mật so với các đối thủ cạnh tranh như AWS .
Nghiên cứu khuyến nghị một số chiến lược giảm thiểu, bao gồm thúc đẩy cập nhật cho các vai trò có vấn đề, thực hiện các nguyên tắc đặc quyền tối thiểu, và kiểm toán các vai trò tùy chỉnh để tìm quyền quá mức. Tuy nhiên, vấn đề cơ bản vẫn còn: kiến trúc phức tạp của Azure khiến các tổ chức khó có thể bảo mật đúng cách môi trường đám mây của họ.
Các Biện Pháp Bảo Mật Được Khuyến Nghị:
- Kiểm tra và thay thế các vai trò có đặc quyền quá cao bằng các lựa chọn thay thế có đặc quyền tối thiểu
- Triển khai các hạn chế phạm vi phù hợp trên việc phân công vai trò
- Thường xuyên xem xét các vai trò tùy chỉnh để phát hiện quyền hạn quá mức
- Thúc đẩy cập nhật cho các vai trò Azure Connector có vấn đề
- Cân nhắc các tích hợp thay thế khi có thể
 |
|---|
| Kiểm thử các API của Azure: Quan trọng cho việc triển khai các biện pháp bảo mật chống lại các lỗ hổng |
Kết Luận
Những lỗ hổng này làm nổi bật một vấn đề rộng lớn hơn với tư thế bảo mật và độ phức tạp kiến trúc của Azure . Mặc dù Microsoft có tài nguyên để giải quyết những vấn đề này, phương pháp phát triển phân mảnh của nền tảng tiếp tục tạo ra các bề mặt tấn công mới. Các tổ chức sử dụng Azure nên kiểm toán cẩn thận việc phân quyền vai trò của họ và xem xét thực hiện các biện pháp bảo mật bổ sung để bảo vệ chống lại những vector tấn công mới được phát hiện này.
Lưu ý: REACT - Dịch vụ nội bộ của Microsoft để quản lý phân quyền vai trò và định nghĩa trong Azure Resource Manager
Tham khảo: Azure's Role Renderers: How Over-Privileged Roles and API Vulnerabilities Expose Enterprise Networks