Cách ly multi-tenant: Azure Cobalt 200 thay đổi điều gì

Việc Microsoft tích hợp cơ chế bảo vệ Rowhammer vào bộ điều khiển bộ nhớ tùy chỉnh của Azure Cobalt 200 phơi bày một bài toán khó của cách ly multi-tenant: hiện tượng lật bit trong DRAM vật lý có thể làm lung lay ranh giới hypervisor và container mà các đội cloud vẫn tin cậy. Bài viết này giải thích Cobalt 200 thay đổi điều gì, chưa giải quyết được điều gì và bên mua nên hỏi gì về ranh giới tin cậy ở tầng phần cứng, confidential computing, attestation và phòng thủ nhiều lớp, dựa trên cách lập bản đồ kiểm soát cách ly và các cổng bằng chứng mà Van Data Team áp dụng khi rà soát hệ thống production.

Thiết kế Azure Cobalt 200 Rowhammer của Microsoft tăng cường cách ly multi-tenant bằng cách đưa cơ chế bảo vệ vào một bộ điều khiển bộ nhớ tùy chỉnh, nằm bên dưới các ranh giới phần mềm mà phần lớn đội cloud vẫn kiểm tra. Với kiến trúc sư bảo mật và kỹ sư nền tảng, câu hỏi của bên mua không còn chỉ là chính sách hypervisor và container đã được cấu hình đúng hay chưa. Câu hỏi là tầng bộ nhớ vật lý có thể phá vỡ các chính sách đó hay không, cơ chế kiểm soát nào đang chặn điều đó và khách hàng có thể lấy được bằng chứng gì.

Tại Van Data Team, chúng tôi biến vấn đề đó thành việc vận hành cụ thể. Chúng tôi gắn từng bảo đảm cách ly cần có với lớp thực thi, bên cung cấp, bằng chứng, cổng review, tín hiệu giám sát và phương án dự phòng tương ứng. Hướng dẫn này biến Cobalt 200 thành một bài rà soát trước production có thể dùng lại. Hãy bắt đầu với bản đồ kiểm soát bên dưới, rồi dùng bộ câu hỏi dành cho nhà cung cấp để lấp các khoảng trống về bằng chứng.

Bài học chính

Kết luận thực tế là gia cố phần cứng giúp cải thiện ranh giới tin cậy của cloud, nhưng không thay thế các cơ chế kiểm soát ở những tầng phía trên.

Để biết bối cảnh triển khai có liên quan, hãy xem giảm chi phí AWS mà không làm chậm tiến độ bàn giao.

• Rowhammer là kiểu tấn công vào tính toàn vẹn của bộ nhớ vật lý, có thể làm hỏng dữ liệu nằm ngoài vùng nhớ được cấp cho kẻ tấn công và phá vỡ cách ly ở tầng phần mềm.
• Cobalt 200 đặt cơ chế bảo vệ Rowhammer trong bộ điều khiển bộ nhớ tùy chỉnh của Microsoft, với mã hóa bộ nhớ được bật mặc định và hỗ trợ Arm CCA.
• Giảm thiểu Rowhammer, mã hóa bộ nhớ, confidential computing và cách ly hypervisor xử lý những mối đe dọa khác nhau; không cơ chế nào thay thế được cơ chế nào.
• Kiến trúc zero trust ở tầng phần cứng nghĩa là gọi tên rõ phụ thuộc không thể tránh khỏi, đòi hỏi bằng chứng phù hợp và lên kế hoạch cho tình huống thất bại.
• Bên mua nên phê duyệt đúng cấu hình dịch vụ và quy trình thu thập bằng chứng cụ thể, chứ không phải một tính năng bộ xử lý nói chung chung.

Microsoft đưa cơ chế bảo vệ Rowhammer vào bộ điều khiển bộ nhớ

Microsoft đặt cơ chế kiểm soát Rowhammer ngay sát DRAM, nơi có thể quan sát và quản lý chính hành vi truy cập bộ nhớ gây ra mối đe dọa. Bài mô tả kỹ thuật về Cobalt 200 cho biết cơ chế phòng thủ được tích hợp vào bộ điều khiển bộ nhớ tùy chỉnh của bộ xử lý.

Thông số của bộ xử lý cung cấp bối cảnh hữu ích, nhưng tự chúng không phải là bằng chứng bảo đảm an ninh.

Hiệu năng của bộ xử lý không chứng minh được hiệu quả bảo mật. Hãy ghi nhận riêng hiệu năng, cơ chế và mức độ bảo đảm.

Microsoft cố ý dùng từ ngữ chừng mực khi nói về hiệu năng

Microsoft mô tả mục tiêu thiết kế cơ chế chống Rowhammer trong bài viết kỹ thuật như sau:

"không tạo ra mức tổn thất hiệu năng thường thấy"

Ở một nguồn khác, thông báo sản phẩm của Azure cho biết mã hóa bộ nhớ mặc định có "tác động không đáng kể đến hiệu năng". Không phát biểu nào nói rằng các cơ chế này hoàn toàn không tốn chi phí. Một phát biểu mô tả mục tiêu thiết kế chống Rowhammer; phát biểu còn lại mô tả hành vi của mã hóa theo số liệu do nhà cung cấp công bố. Bên mua vẫn nên tự đo thông lượng, tail latency, hành vi lỗi và chi phí với đúng workload dự kiến và cấu hình bảo mật sẽ dùng.

Cơ chế vẫn chỉ dựa trên mô tả kỹ thuật của Microsoft

Theo Microsoft, cách tiếp cận của họ dùng telemetry có giới hạn chặt hơn để phát hiện hành vi bất thường trên toàn bộ hạ tầng, đồng thời vẫn tuân theo các nguyên tắc của confidential computing. Microsoft cũng so sánh thiết kế này với các giải pháp giảm thiểu DRAM độc quyền đời cũ, vốn bị hãng mô tả là chỉ gần đúng, khó kiểm tra và dễ rơi vào kiểu "bảo mật nhờ che giấu".

Những phát biểu đó giải thích lý do thiết kế của nhà cung cấp. Chúng không thay thế cho đánh giá độc lập, cam kết cách ly trong hợp đồng, attestation mà khách hàng tự kiểm tra được hay việc kiểm thử trên chính cấu hình dịch vụ bạn định chạy.

Vì sao Rowhammer đe dọa cách ly multi-tenant

Hình minh họa sau tóm tắt việc cuộc tấn công bắt đầu từ bên dưới sandbox:

Rowhammer đe dọa việc tách biệt tenant vì nó có thể thay đổi bộ nhớ mà không đi qua các quyền ghi logic mà hypervisor, hệ điều hành hay ứng dụng vẫn kỳ vọng sẽ kiểm soát. Theo bài mô tả kỹ thuật về Cobalt của Microsoft, việc truy cập lặp đi lặp lại vào một số hàng DRAM có thể gây nhiễu các hàng nằm sát cạnh về mặt vật lý và làm lật bit ở vùng nhớ không thuộc về kẻ tấn công.

Một bit bị thay đổi ở tầng dưới có thể làm hỏng dữ liệu workload, trạng thái thực thi hoặc metadata nhạy cảm về bảo mật mà các tầng trên mặc định là đáng tin. Luồng kiểm soát truy cập thông thường có thể không bao giờ ghi nhận một lần ghi trái phép nào, vì lỗi phát sinh từ chính hành vi của bộ nhớ vật lý.

Đó là lý do câu "chúng tôi đã cấu hình sandbox đúng" là một câu trả lời chưa đầy đủ. Kiểm soát truy cập logic trả lời câu hỏi ai được phép yêu cầu ghi. Tính toàn vẹn của bộ nhớ phần cứng trả lời câu hỏi bộ nhớ có thể bị tác động mà không cần lần ghi được ủy quyền đó hay không.

Hãy xét một ví dụ rà soát minh họa. Maya, một kiến trúc sư bảo mật, đang phê duyệt một nền tảng phân tích dùng chung. Threat model của cô cho rằng một tenant không đáng tin không thể ghi vào page của tenant khác, vì hypervisor nắm quyền ánh xạ bộ nhớ. Rowhammer làm thay đổi câu hỏi rà soát: một tenant dùng chung phần cứng có thể tác động tới một bit vật lý mà không cần đi qua đường ánh xạ đó không? Maya không bỏ cơ chế kiểm soát của hypervisor. Cô bổ sung bộ điều khiển bộ nhớ, biện pháp giảm thiểu của nhà cung cấp, bằng chứng hiện có và quy trình xử lý sự cố vào cùng một bản đồ phụ thuộc.

Bài học vận hành rất đơn giản: hãy tìm đúng lớp đang thực thi bảo đảm mà bạn thực sự cần. Nếu yêu cầu là "một tenant không thể làm hỏng trạng thái workload của tenant khác", thì chỉ riêng chính sách container không đủ để khép lại lập luận.

Cobalt 200 thay đổi điều gì, và không thay đổi điều gì

Cobalt 200 củng cố nền tảng phần cứng bằng các cơ chế kiểm soát có liên quan nhưng không thay thế được cho nhau: bảo vệ Rowhammer ở cấp bộ điều khiển, mã hóa bộ nhớ mặc định và hỗ trợ Arm Confidential Compute Architecture. Mỗi cơ chế đảm nhận một nhiệm vụ khác nhau.

Để biết bối cảnh triển khai có liên quan, hãy xem phát triển AI agent.

Việc đưa biện pháp giảm thiểu vào bộ điều khiển bộ nhớ có ý nghĩa vì điểm thực thi nằm bên dưới chính phần mềm vốn phụ thuộc vào việc bộ nhớ hoạt động đúng. Nó cũng đẩy thêm một phần ranh giới tin cậy vào silicon và hoạt động vận hành của nhà cung cấp. Phần lớn khách hàng không thể kiểm tra từng chi tiết của phần triển khai đó.

Zero trust không có nghĩa là giả vờ có thể loại phần cứng ra khỏi mô hình tin cậy. Nó có nghĩa là làm rõ sự phụ thuộc đó và đối chiếu nó với bằng chứng. Nhà cung cấp kiểm soát thiết kế silicon, firmware, telemetry trên toàn hạ tầng, vòng đời phần cứng và cách nền tảng phản ứng. Khách hàng kiểm soát danh tính của workload, nguyên tắc đặc quyền tối thiểu, secret, lựa chọn triển khai, cách ly ứng dụng, logging và chuyển cấp. Tài liệu, attestation, tài liệu kiểm toán, hợp đồng, bản tin bảo mật và kiểm thử của khách hàng tạo thành lớp bằng chứng dùng chung.

Bộ xử lý có hỗ trợ không đồng nghĩa với dịch vụ có bảo đảm. Hỗ trợ Arm CCA chỉ thực sự hữu ích với bên mua khi dịch vụ liên quan cung cấp một chế độ confidential computing có tài liệu rõ ràng, cấu hình có thể lặp lại, và bằng chứng attestation trả lời được threat model của bên mua.

Rowhammer cũng vẫn là một chủ đề nghiên cứu sôi động. Bài báo nghiên cứu MINT giải thích rằng các bộ theo dõi in-DRAM chi phí thấp hiện có đã bị vượt qua bằng các mẫu truy cập được dựng có chủ đích, trong khi giới nghiên cứu vẫn tiếp tục phát triển thiết kế giảm thiểu mới. Bài báo đó không đánh giá Cobalt 200 và cũng không tiết lộ cấu tạo bên trong của nó. Nó củng cố một kết luận thận trọng: giảm thiểu chỉ làm giảm rủi ro, không chấm dứt cả lớp tấn công này.

Vì vậy, phòng thủ nhiều lớp vẫn phải được giữ nguyên. Hãy duy trì cách ly ở hypervisor, đặc quyền tối thiểu, quản lý secret, giám sát workload, ứng phó sự cố và review thay đổi. Nếu bằng chứng của nhà cung cấp chưa đủ so với mức tác động của workload, hãy thu hẹp phạm vi workload hoặc chọn cách bố trí cách ly mạnh hơn, thay vì âm thầm biến một điều chưa biết thành sự bảo đảm.

Quy trình cho bên mua để đánh giá niềm tin dựa trên phần cứng

Bên mua dịch vụ cloud nên phê duyệt cơ chế cách ly dựa trên phần cứng thông qua một quy trình thu thập bằng chứng có thể lặp lại, chứ không phải qua một checklist tính năng. Quy trình bắt đầu từ kết quả cần đạt và kết thúc bằng phương án xử lý lỗi có người chịu trách nhiệm.

Hỏi về phạm vi trước khi hỏi về cơ chế

Những câu hỏi đầu tiên dành cho nhà cung cấp cần xác định rõ những gì được bảo vệ:

• Cơ chế kiểm soát Rowhammer được thiết kế để ngăn chính xác hành vi xuyên tenant nào?
• Dịch vụ, dòng instance, phiên bản phần cứng, trạng thái firmware và cấu hình nào được áp dụng cơ chế này?
• Cam kết cách ly có nằm trong hợp đồng, được ghi nhận là hành vi của sản phẩm, hay chỉ được mô tả trong tài liệu kỹ thuật?
• Những biến thể Rowhammer, giả định về truy cập hoặc điều kiện triển khai nào vẫn nằm ngoài phạm vi?
• Nhà cung cấp đánh giá lại cơ chế kiểm soát ra sao khi kỹ thuật tấn công thay đổi?

Hỏi xem tenant có thể tự xác minh những gì

Một cuộc trao đổi hữu ích về confidential computing phải đi tới được quy trình bằng chứng:

• Tenant có thể attest những gì về bộ xử lý, firmware, chế độ confidential và trạng thái khởi chạy của workload?
• Hỗ trợ CCA có thực sự trở thành một cấu hình dịch vụ dùng được cho region và workload dự kiến không?
• Những phép đo nào khách hàng xem được, và phép đo nào chỉ nhà cung cấp nắm?
• Attestation root, endorsement, thu hồi, lưu giữ bằng chứng và các lần xác minh thất bại được xử lý ra sao?
• Thông báo thay đổi nào được phát ra khi phần cứng, firmware hoặc chuỗi attestation thay đổi?

Trong một đợt rà soát mua sắm giả định, Luis, một kỹ sư nền tảng, thấy dòng "hỗ trợ CCA" trong tài liệu bộ xử lý nhưng không tìm thấy quy trình attestation nào mà tenant có thể dùng cho dịch vụ dự kiến. Anh ghi nhận năng lực của chip là đã xác minh, còn bảo đảm cho bản triển khai là vẫn để ngỏ. Tính năng đó có thật, nhưng việc phê duyệt cho production phải chờ cấu hình và bằng chứng riêng cho dịch vụ.

Nếu câu trả lời là "nhà cung cấp có giám sát", hãy hỏi khách hàng nhận được gì. Tín hiệu nội bộ từ hạ tầng của nhà cung cấp có thể có giá trị vận hành, nhưng không phải là bằng chứng mà khách hàng tự xác minh được.

Hỏi xem việc phát hiện được chuyển thành hành động ứng phó ra sao

Observability chỉ có giá trị khi nó kích hoạt một hành động có người chịu trách nhiệm. Hãy hỏi nhà cung cấp có thể phát hiện hành vi bất thường nào mà không làm lộ dữ liệu bí mật của workload, khách hàng nhận được thông báo gì, và phần cứng bị nghi ngờ được cô lập hoặc loại khỏi vận hành như thế nào. Quy trình xử lý sự cố phải bao gồm lưu giữ bằng chứng, di dời workload, xử lý secret, khôi phục và review sau sự cố.

Các tuyên bố về hiệu năng cũng cần kỷ luật tương tự. Hãy kiểm thử đúng workload dự kiến ở đúng chế độ bảo mật sẽ dùng. Đo độ trễ, thông lượng, số lần retry, tỷ lệ lỗi, hành vi khôi phục và chi phí hạ tầng. Tách riêng kết quả của giảm thiểu Rowhammer, mã hóa bộ nhớ và confidential computing, để kết quả tốt của cơ chế này không bị dùng lại làm bằng chứng cho cơ chế khác.

Xây sổ đăng ký ranh giới tin cậy

Sổ đăng ký ranh giới tin cậy biến cuộc thảo luận kiến trúc thành một artifact production có thể audit. Hãy chép cấu trúc này vào architecture decision record, sổ đăng ký rủi ro hoặc danh mục kiểm soát của nền tảng.

Hãy phân loại bằng chứng thay vì gộp chung. Thông báo của nhà cung cấp, mô tả kỹ thuật, tài liệu sản phẩm, cấu hình xem được, kết quả attestation, cam kết hợp đồng, đánh giá độc lập và kiểm thử của khách hàng trả lời những câu hỏi khác nhau. Không phải cơ chế kiểm soát nào cũng có đủ mọi loại bằng chứng, nhưng khoảng trống thì phải được nhìn thấy rõ.

Tại Van Data Team, sai lầm chúng tôi hay gặp là các bài rà soát liệt kê cơ chế kiểm soát nhưng không xác định cổng duyệt. Hãy dùng cổng kiến trúc cho bản đồ phụ thuộc, cổng bảo mật cho phạm vi mối đe dọa và rủi ro còn lại, cổng nền tảng cho cấu hình lặp lại được và việc thu thập bằng chứng, và cổng production cho giám sát, chuyển cấp, phương án dự phòng và quyền sở hữu. Bất kỳ thay đổi nào về phần cứng, firmware, hành vi dịch vụ hoặc nghiên cứu mối đe dọa đều phải khiến quyết định được xem xét lại.

Ghi nhận điều chưa biết thay vì "tẩy trắng" chúng thành niềm tin

Các nguồn hiện có không cho biết thiết kế cơ chế theo dõi bên trong một cách chính xác, cũng không có đánh giá độc lập về cơ chế phòng thủ Rowhammer của Cobalt 200, phạm vi trong hợp đồng, attestation mà khách hàng tự kiểm tra được cho mọi dịch vụ liên quan, hay hiệu năng với workload cụ thể trong cấu hình bảo mật của bạn.

Gán mỗi điều chưa biết cho một người phụ trách và một artifact cần có để khép lại. Đội platform engineering cần lấy được ma trận dịch vụ và phần cứng. Đội bảo mật nên yêu cầu phạm vi mối đe dọa, bằng chứng kiểm toán, chi tiết attestation và điều khoản hợp đồng. Đội performance engineering nên kiểm thử workload thực tế. Người chịu trách nhiệm rủi ro quyết định chấp nhận, bù đắp hay từ chối phần khoảng trống còn lại.

Một đợt rà soát niềm tin phần cứng do founder trực tiếp dẫn dắt cùng Van Data Team, với phạm vi rõ ràng, sẽ cho ra bản đồ phụ thuộc cách ly, bộ câu hỏi cho nhà cung cấp, sổ đăng ký khoảng trống bằng chứng, thiết kế cổng review, runbook giám sát và chuyển cấp, cùng phạm vi triển khai. Đầu ra hữu ích không phải là một điểm số bảo mật cloud chung chung, mà là một gói quyết định mà các đội bảo mật, nền tảng, mua sắm và ứng phó sự cố của bạn có thể vận hành.

Cách Van Data Team đưa việc này vào vận hành

Tại Van Data Team, chúng tôi biến cách ly multi-tenant thành một workflow vận hành. Chúng tôi lập bản đồ các điểm bàn giao hiện tại giữa bảo mật, nền tảng, mua sắm và ứng phó sự cố, rồi gắn từng bảo đảm cần có với hệ thống nguồn, lớp thực thi, người phụ trách, điểm ra quyết định, cổng review và đường khôi phục.

Với Cobalt 200, điều đó có nghĩa là tách các cơ chế kiểm soát mà Microsoft công bố (giảm thiểu Rowhammer ở bộ điều khiển bộ nhớ, mã hóa bộ nhớ mặc định và hỗ trợ Arm CCA) khỏi những bằng chứng đã được rà soát độc lập và các bảo đảm riêng cho từng dịch vụ. Attestation có thể xác minh các thuộc tính đã được công bố và trạng thái cấu hình; không nên coi nó là bằng chứng về cấu tạo bên trong của silicon mà nhà cung cấp không công khai.

Kế hoạch triển khai sau đó sẽ xác định:

• Những tín hiệu cần thu thập, chẳng hạn như định danh phần cứng, kết quả attestation, policy drift, bản tin bảo mật của nhà cung cấp và các sự cố liên quan đến cách ly.
• Những khoảng trống cần có người phụ trách rõ ràng, cần làm rõ hợp đồng, kiểm thử workload hoặc một phương án hosting thay thế.
• Việc thu thập bằng chứng và cảnh báo nào có thể tự động hóa, trong khi vẫn giữ bước phê duyệt của con người với các thay đổi và ngoại lệ liên quan tới ranh giới tin cậy.
• Dashboard và runbook nào định hướng hành động khi bằng chứng hết hạn, cấu hình bị lệch hoặc một biến thể Rowhammer mới làm thay đổi đánh giá rủi ro.

Kết quả là một bản đồ kiểm soát có thể hành động được, chứ không phải một tuyên bố chung chung rằng phần cứng làm workload trở nên an toàn. Nó giữ biện pháp giảm thiểu ở tầng phần cứng trong khuôn khổ phòng thủ nhiều lớp, đồng thời cho đội ngũ một cơ sở lặp lại được để phê duyệt, giám sát và xem xét lại mức độ tin cậy dành cho nhà cung cấp.

Kết luận

Azure Cobalt 200 quan trọng vì nó cho thấy chiều sâu thực sự của cách ly multi-tenant: việc tách biệt ở tầng phần mềm phụ thuộc vào tính toàn vẹn của bộ nhớ nằm bên dưới hypervisor, hệ điều hành và container. Cơ chế bảo vệ Rowhammer ở cấp bộ điều khiển của Microsoft gia cố nền móng đó, còn mã hóa bộ nhớ mặc định và Arm CCA bổ sung những cơ chế kiểm soát riêng cho các mục đích khác nhau.

Để biết bối cảnh triển khai có liên quan, hãy xem Kỹ thuật dữ liệu tại Việt Nam.

Việc bên mua cần làm về lâu dài mang tính kiến trúc. Hãy lập bản đồ bảo đảm, lớp thực thi, bên cung cấp, bằng chứng, cổng review, tín hiệu giám sát và phương án xử lý lỗi. Ghi rõ những điều chưa biết. Kiểm chứng đúng cấu hình dịch vụ và workload thực tế, thay vì biến một tuyên bố ở cấp bộ xử lý thành phê duyệt cho production.

Một đợt rà soát niềm tin phần cứng của Van Data Team có thể biến bản đồ đó thành bộ câu hỏi cho nhà cung cấp, sổ đăng ký bằng chứng, cổng production, quy trình attestation và runbook xử lý sự cố. Mục tiêu không phải là tin phần cứng một cách mù quáng hay bác bỏ nó hoàn toàn, mà là làm cho mọi quyết định tin cậy không thể tránh khỏi đều minh bạch, có thể rà soát và có thể khôi phục.