Cách ly nhiều người thuê: Những thay đổi nào của Azure Cobalt 200

Quyết định của Microsoft về việc tích hợp tính năng bảo vệ Rowhammer vào bộ điều khiển bộ nhớ tùy chỉnh của Azure Cobalt 200 đã bộc lộ một vấn đề khó khăn đối với việc cách ly nhiều người thuê: sự thay đổi bit trong DRAM vật lý có thể làm suy yếu sự tin cậy của các nhóm đám mây về giới hạn bộ ảo hóa và vùng chứa. Hướng dẫn này giải thích những gì Cobalt 200 thay đổi, những gì nó không giải quyết được và những gì người mua nên hỏi về ranh giới tin cậy phần cứng, điện toán bí mật, chứng thực và bảo vệ chuyên sâu, bằng cách sử dụng các cổng bằng chứng và ánh xạ kiểm soát cách ly mà Van Data Team áp dụng trong các đánh giá sản xuất.

Thiết kế Azure Cobalt 200 Rowhammer của Microsoft tăng cường khả năng cách ly nhiều bên thuê bằng cách chuyển tính năng bảo vệ vào bộ điều khiển bộ nhớ tùy chỉnh, bên dưới ranh giới phần mềm mà hầu hết các nhóm đám mây đều kiểm tra. Đối với các kiến ​​trúc sư bảo mật và kỹ sư nền tảng, vấn đề của người mua không còn chỉ là liệu các chính sách bộ ảo hóa và vùng chứa có được định cấu hình chính xác hay không. Vấn đề là liệu lớp bộ nhớ vật lý có thể vi phạm các chính sách đó hay không, biện pháp kiểm soát nào cản trở và khách hàng có thể thu được bằng chứng gì.

Tại Van Data Team, chúng tôi xử lý vấn đề đó. Chúng tôi ánh xạ từng đảm bảo cách ly bắt buộc tới lớp thực thi, nhà cung cấp, bằng chứng, cổng đánh giá, tín hiệu giám sát và dự phòng. Hướng dẫn này biến Cobalt 200 thành bản đánh giá trước khi sản xuất có thể tái sử dụng. Bắt đầu với bản đồ kiểm soát bên dưới, sau đó sử dụng các câu hỏi của nhà cung cấp để thu hẹp khoảng cách bằng chứng.

Bài học chính

Kết luận thực tế là việc tăng cường phần cứng sẽ cải thiện ranh giới tin cậy của đám mây nhưng không thay thế các biện pháp kiểm soát ở trên ranh giới đó.

Để 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 quá trình phân phối.

• Rowhammer là một cuộc tấn công toàn vẹn bộ nhớ vật lý có thể làm hỏng dữ liệu nằm ngoài sự phân bổ của kẻ tấn công và làm suy yếu khả năng cô lập phần mềm.
• Cobalt 200 đưa tính năng bảo vệ Rowhammer vào bộ điều khiển bộ nhớ tùy chỉnh của Microsoft, với tính năng mã hóa bộ nhớ được bật theo mặc định và hỗ trợ Arm CCA.
• Giảm thiểu Rowhammer, mã hóa bộ nhớ, điện toán bí mật và cách ly bộ điều khiển ảo hóa giải quyết các mối đe dọa khác nhau; không ai có thể thay thế cho những người khác.
• Kiến trúc không tin cậy ở lớp phần cứng có nghĩa là đặt tên cho sự phụ thuộc không thể tránh khỏi, yêu cầu bằng chứng phù hợp và lên kế hoạch cho sự thất bại.
• Người mua nên phê duyệt cấu hình dịch vụ chính xác và đường dẫn bằng chứng chứ không phải tính năng của bộ xử lý trong bản tóm tắt.

Microsoft đã chuyển tính năng bảo vệ Rowhammer vào bộ điều khiển bộ nhớ

Microsoft đặt bộ điều khiển Rowhammer gần với DRAM, nơi có thể quan sát và quản lý hành vi truy cập bộ nhớ tạo ra mối đe dọa. Tài khoản kỹ thuật Cobalt 200 tuyên bố rằng hệ thống bảo vệ được tích hợp vào bộ điều khiển bộ nhớ tùy chỉnh của bộ xử lý.

Các thông số kỹ thuật của bộ xử lý cung cấp bối cảnh hữu ích nhưng bản thân chúng không phải là bằng chứng đảm bảo an ninh.

Hiệu suất xử lý không chứng minh được hiệu quả bảo mật. Ghi lại hiệu suất, cơ chế và sự đảm bảo một cách riêng biệt.

Từ ngữ hiệu suất của Microsoft bị giới hạn có chủ ý

Microsoft mô tả mục tiêu thiết kế Rowhammer của mình trong bài đăng kỹ thuật theo cách này:

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

Riêng biệt, thông báo về sản phẩm Azure cho biết tính năng mã hóa bộ nhớ mặc định có "tác động không đáng kể đến hiệu suất". Không có tuyên bố nào nói rằng quyền kiểm soát là miễn phí. Một mô tả mục tiêu thiết kế Rowhammer; cái còn lại mô tả hành vi mã hóa do nhà cung cấp báo cáo. Người mua vẫn phải đo lường thông lượng, độ trễ cuối, hành vi lỗi và chi phí với khối lượng công việc dự kiến ​​và cấu hình bảo mật.

Cơ chế vẫn là tài khoản kỹ thuật của Microsoft

Theo Microsoft, phương pháp tiếp cận của họ sử dụng phép đo từ xa hạn chế hơn để phát hiện hành vi bất thường trên toàn nhóm đồng thời tuân thủ các nguyên tắc điện toán bí mật. Microsoft cũng đối lập thiết kế của mình với các giải pháp giảm thiểu DRAM độc quyền cũ hơn mà hãng mô tả là gần đúng, khó kiểm tra và dễ bị "bảo mật do che khuất".

Những tuyên bố đó giải thích lý do thiết kế của nhà cung cấp. Chúng không thay thế đánh giá độc lập, cam kết tách biệt theo hợp đồng, chứng thực mà khách hàng có thể nhìn thấy hoặc thử nghiệm cấu hình dịch vụ mà bạn dự định chạy.

Tại sao Rowhammer đe dọa sự cô lập của nhiều người thuê nhà

Hình minh họa sau đây tóm tắt cuộc tấn công bắt đầu bên dưới hộp cát:

Rowhammer đe dọa việc tách đối tượng thuê vì nó có thể thay đổi bộ nhớ mà không thông qua các quyền ghi logic mà bộ ảo hóa, hệ điều hành hoặc ứng dụng mong muốn thực thi. Theo tài khoản kỹ thuật Cobalt của Microsoft, việc truy cập nhiều lần vào các hàng DRAM đã chọn có thể làm xáo trộn các hàng vật lý gần đó và gây ra hiện tượng lật bit DRAM trong bộ nhớ mà kẻ tấn công không sở hữu.

Thay đổi bit ở lớp thấp hơn có thể làm hỏng dữ liệu khối lượng công việc, trạng thái thực thi hoặc siêu dữ liệu nhạy cảm về bảo mật mà các lớp trên cho là đáng tin cậy. Đường dẫn kiểm soát truy cập thông thường có thể không bao giờ quan sát thấy việc ghi trái phép vì lỗi phát sinh từ hoạt động của bộ nhớ vật lý.

Đây là lý do tại sao "chúng tôi đã định cấu hình hộp cát chính xác" là câu trả lời không đầy đủ. Kiểm soát truy cập hợp lý trả lời những người có thể yêu cầu viết. Tính toàn vẹn của bộ nhớ phần cứng trả lời liệu bộ nhớ có thể bị ảnh hưởng nếu không được phép ghi hay không.

Hãy xem xét một đánh giá 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. Mô hình mối đe dọa của cô ấy cho biết một đối tượng thuê không đáng tin cậy không thể viết các trang của đối tượng thuê khác vì trình ảo hóa sở hữu ánh xạ. Rowhammer thay đổi câu hỏi đánh giá: người cùng thuê nhà có thể tác động đến một bit vật lý mà không cần sử dụng đường dẫn ánh xạ đó không? Maya không loại bỏ sự kiểm soát của bộ ảo hóa. 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 sẵn có và đường dẫn 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: tìm lớp thực thi bảo đảm mà bạn thực sự cần. Nếu yêu cầu là "một đối tượng thuê không thể làm hỏng trạng thái khối lượng công việc của đối tượng thuê khác", thì chỉ riêng chính sách vùng chứa không thể đóng đối số.

Cobalt 200 thay đổi những gì và không thay đổi những gì

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

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

Việc chuyển biện pháp giảm nhẹ vào bộ điều khiển bộ nhớ rất quan trọng vì việc thực thi nằm bên dưới phần mềm phụ thuộc vào bộ nhớ chính xác. Nó cũng chuyển nhiều ranh giới tin cậy hơn sang hoạt động của nhà cung cấp và silicon. Hầu hết khách hàng không thể kiểm tra từng dòng thực hiện đó.

Không tin cậy không có nghĩa là có thể loại bỏ phần cứng giả vờ khỏi mô hình tin cậy. Nó có nghĩa là làm cho sự phụ thuộc trở nên rõ ràng và kết hợp nó với bằng chứng. Nhà cung cấp kiểm soát thiết kế silicon, chương trình cơ sở, đo từ xa nhóm, vòng đời phần cứng và phản hồi của nền tảng. Khách hàng kiểm soát danh tính khối lượng công việc, đặc quyền tối thiểu, bí mật, lựa chọn triển khai, cách ly ứng dụng, ghi nhật ký và leo thang. Tài liệu, chứng thực, tài liệu kiểm toán, hợp đồng, tư vấn và thử nghiệm của khách hàng tạo thành lớp bằng chứng được chia sẻ.

Hỗ trợ bộ xử lý không giống như đảm bảo dịch vụ. Hỗ trợ CCA của Arm chỉ trở nên hữu ích đối với người mua khi dịch vụ liên quan hiển thị chế độ điện toán bí mật được ghi lại, cấu hình có thể lặp lại và bằng chứng chứng thực trả lời mô hình mối đe dọa của người mua.

Rowhammer cũng vẫn là một vấn đề nghiên cứu tích cực. Bài viết nghiên cứu MINT giải thích rằng các trình theo dõi trong DRAM chi phí thấp hiện có đã bị phá vỡ bởi các mẫu truy cập thủ công trong khi các nhà nghiên cứu tiếp tục phát triển các thiết kế giảm thiểu mới. Bài viết đó không đánh giá Cobalt 200 hoặc tiết lộ cấu tạo bên trong của nó. Nó ủng hộ kết luận thận trọng: giảm thiểu rủi ro; nó không kết thúc lớp tấn công.

Do đó, khả năng phòng thủ theo chiều sâu vẫn được giữ nguyên. Duy trì sự tách biệt của trình ảo hóa, đặc quyền tối thiểu, quản lý bí mật, giám sát khối lượng công việc, ứng phó sự cố và xem xét thay đổi. Nếu bằng chứng của nhà cung cấp không đủ về tác động của khối lượng công việc, hãy thu hẹp phạm vi khối lượng công việc hoặc chọn cách ly vị trí mạnh mẽ hơn thay vì âm thầm chuyển đổi điều chưa biết thành sự đảm bảo.

Quy trình làm việc của người mua để có được niềm tin được hỗ trợ bằng phần cứng

Người mua đám mây nên phê duyệt cách ly được hỗ trợ bằng phần cứng thông qua quy trình làm việc bằng chứng có thể lặp lại chứ không phải thông qua danh sách kiểm tra tính năng. Quy trình làm việc bắt đầu với kết quả được yêu cầu và kết thúc bằng phản hồi lỗi sở hữu.

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

Các câu hỏi đầu tiên của nhà cung cấp cần xác định những gì được bảo vệ:

• Kiểm soát Rowhammer được thiết kế để ngăn chặn hành vi thuê chung chính xác nào?
• Dịch vụ, dòng phiên bản, bản sửa đổi phần cứng, trạng thái chương trình cơ sở và cấu hình nào nhận được nó?
• Cam kết cách ly có mang tính hợp đồng, được ghi lại dưới dạng 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 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 khả năng kiểm soát như thế nào khi các kỹ thuật tấn công phát triển?

Hỏi những gì người thuê có thể xác minh

Một cuộc thảo luận hữu ích về điện toán bí mật phải đạt được đường dẫn bằng chứng:

• Đối tượng thuê có thể chứng thực điều gì về bộ xử lý, chương trình cơ sở, chế độ bí mật và trạng thái khởi chạy khối lượng công việc?
• Hỗ trợ CCA có chuyển thành cấu hình dịch vụ có sẵn cho khu vực và khối lượng công việc dự định không?
• Những phép đo nào khách hàng có thể nhìn thấy và phép đo nào chỉ dành cho nhà cung cấp?
• Nguồn gốc chứng thực, chứng thực, thu hồi, lưu giữ bằng chứng và xác minh không thành công được xử lý như thế nào?
• Thông báo thay đổi nào được đưa ra khi phần cứng, chương trình cơ sở hoặc chuỗi chứng thực thay đổi?

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

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

Hỏi cách phát hiện trở thành phản hồi

Khả năng quan sát chỉ quan trọng khi nó kích hoạt một hành động sở hữu. Hỏi xem nhà cung cấp có thể phát hiện hành vi bất thường nào mà không tiết lộ dữ liệu khối lượng công việc bí mật, thông báo nào khách hàng nhận được và cách phần cứng bị nghi ngờ được chứa hoặc ngừng hoạt động. Lộ trình sự cố phải bao gồm việc bảo quản bằng chứng, di dời khối lượng công việc, xử lý bí mật, phục hồi và xem xét sau sự cố.

Yêu cầu về hiệu suất cần có kỷ luật tương tự. Kiểm tra khối lượng công việc dự kiến ​​ở chế độ bảo mật dự định. Đo độ trễ, thông lượng, số lần thử lại, tỷ lệ lỗi, hành vi khôi phục và chi phí cơ sở hạ tầng. Giữ riêng biệt các kết quả giảm thiểu Rowhammer, mã hóa bộ nhớ và tính toán bí mật để kết quả thuận lợi cho một điều khiển không được sử dụng lại làm bằng chứng cho điều khiển khác.

Xây dựng 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 về kiến trúc thành một tạo phẩm sản xuất có thể kiểm tra được. Sao chép cấu trúc này vào bản ghi quyết định kiến ​​trúc, sổ đăng ký rủi ro hoặc danh mục kiểm soát nền tảng.

Phân loại bằng chứng thay vì trộn lẫn chúng lại với nhau. 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 hiển thị, kết quả chứng thực, cam kết hợp đồng, đánh giá độc lập và kiểm tra của khách hàng sẽ trả lời các câu hỏi khác nhau. Không có sự kiểm soát nào nhất thiết sẽ cung cấp mọi hình thức, nhưng phải nhìn thấy được khoảng cách.

Tại Van Data Team, sai sót mà chúng tôi thấy là đánh giá đặt tên cho các điều khiển nhưng không đặt tên cho cổng. Sử 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 sót lại, cổng nền tảng cho cấu hình lặp lại và thu thập bằng chứng cũng như cổng sản xuất để giám sát, báo cáo, dự phòng và quyền sở hữu. Một thay đổi về phần cứng, chương trình cơ sở, hành vi dịch vụ hoặc nghiên cứu mối đe dọa sẽ đưa ra quyết định lại.

Ghi lại những điều chưa biết thay vì rửa chúng thành niềm tin

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

Gán từng ẩn số cho một chủ sở hữu và tạo phẩm đóng. Kỹ thuật nền tảng phải thu được ma trận dịch vụ và phần cứng. Bộ phận 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 chứng thực và ngôn ngữ hợp đồng. Kỹ thuật hiệu suất nên kiểm tra khối lượng công việc thực tế. Chủ sở hữu rủi ro nên chấp nhận, bù đắp hoặc từ chối khoảng cách còn lại.

Một đánh giá độ tin cậy phần cứng do người sáng lập thực hiện có phạm vi với Van Data Team tạo ra bản đồ phụ thuộc cách ly, bảng câu hỏi của nhà cung cấp, sổ đăng ký khoảng cách bằng chứng, thiết kế cổng đánh giá, sổ tay giám sát và báo cáo cũng như phạm vi triển khai. Đầu ra hữu ích không phải là điểm chung chung về bảo mật đám mây. Đây là gói quyết định mà các nhóm bảo mật, nền tảng, mua sắm và sự cố của bạn có thể vận hành.

Nhóm Van Data thực hiện hoạt động này như thế nào

Tại Van Data Team, chúng tôi biến việc cách ly nhiều người thuê thành một quy trình vận hành. Chúng tôi ánh xạ các chuyển giao hiện tại giữa bảo mật, nền tảng, mua sắm và ứng phó sự cố, sau đó kết nối từng bảo đảm cần thiết với hệ thống nguồn, lớp thực thi, chủ sở hữu, điểm quyết định, cổng xem xét và đường dẫn khôi phục.

Đối với Cobalt 200, điều đó có nghĩa là tách biệt các biện pháp kiểm soát đã nêu của Microsoft, giảm thiểu Rowhammer của bộ điều khiển bộ nhớ, mã hóa bộ nhớ mặc định và hỗ trợ Arm CCA, khỏi các bằng chứng được xem xét độc lập và các đảm bảo dành riêng cho dịch vụ. Chứng thực có thể xác minh các thuộc tính được tiết lộ và trạng thái cấu hình; nó không được coi là bằng chứng về phần bên trong silicon mà nhà cung cấp không tiết lộ.

Kế hoạch phân phối kết quả xác định:

• Những tín hiệu nào cần thu thập, chẳng hạn như nhận dạng phần cứng, kết quả chứng thực, sai lệch chính sách, tư vấn của nhà cung cấp và các sự cố liên quan đến cách ly.
• Những khoảng trống nào yêu cầu quyền sở hữu rõ ràng, làm rõ hợp đồng, kiểm tra khối lượng công việc hoặc đường dẫn lưu trữ thay thế.
• Việc thu thập bằng chứng và cảnh báo nào có thể được tự động hóa, với sự chấp thuận của con người đối với các thay đổi và ngoại lệ trong ranh giới tin cậy.
• Bảng thông tin và sổ tay hướng dẫn hành động nào khi bằng chứng hết hạn, sai lệch cấu hình hoặc 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ể thực hiện được chứ không phải một tuyên bố chung chung rằng phần cứng giúp khối lượng công việc trở nên an toàn. Nó giúp giảm thiểu phần cứng bên trong hệ thống phòng thủ một cách chuyên sâu, đồng thời cung cấp cho nhóm cơ sở có thể lặp lại để phê duyệt, giám sát và xem xét lại niềm tin của 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 sự cô lập nhiều bên thuê: việc tách phần mềm phụ thuộc vào tính toàn vẹn của bộ nhớ bên dưới bộ ảo hóa, hệ điều hành và bộ chứa. Tính năng bảo vệ Rowhammer ở ​​cấp độ bộ điều khiển của Microsoft củng cố nền tảng đó, trong khi mã hóa bộ nhớ mặc định và Arm CCA bổ sung các điều khiển riêng biệt 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.

Hành động lâu dài của người mua mang tính kiến trúc. Lập bản đồ bảo đảm, lớp thực thi, nhà cung cấp, bằng chứng, cổng đánh giá, tín hiệu giám sát và phản hồi lỗi. Giữ những điều chưa biết rõ ràng. Xác thực cấu hình dịch vụ và khối lượng công việc chính xác thay vì chuyển yêu cầu cấp bộ xử lý thành phê duyệt sản xuất.

Đánh giá độ tin cậy phần cứng của Van Data Team có thể biến bản đồ đó thành bộ câu hỏi của nhà cung cấp, sổ đăng ký bằng chứng, cổng sản xuất, quy trình chứng thực và sổ ghi chép sự cố. Mục tiêu không phải là tin tưởng phần cứng một cách mù quáng hoặc từ chối nó một cách rõ ràng. Đó là làm cho mọi quyết định tin cậy không thể tránh khỏi được hiển thị, có thể xem xét và phục hồi được.