Cuộc tấn công tiếp theo của Crypto có thể không nằm ở mã.
Nó có thể là cấu hình giả dạng như quản trị.
Kiến trúc PolicyClient của Newton Protocol đặt ra một câu hỏi bảo mật khó hơn: không phải liệu logic chính sách có đúng hay không, mà là ai nắm quyền định nghĩa logic đó được phép mang ý nghĩa như thế nào.
Chính sách Rego có thể vẫn công khai, tất định, tái sử dụng và không thay đổi. Tuy nhiên, chu vi thực thi của nó được viết lại bằng các giá trị JSON phẳng được truyền qua data.params mà không cần đụng chạm đến code.
Điều đó có nghĩa là cùng một mã chính sách có thể tạo ra các chế độ quyền khác nhau một cách triệt để giữa các ứng dụng.
Một chủ sở hữu có thể áp đặt các ngưỡng giao dịch hẹp, các trần mức phơi bày nghiêm ngặt và các danh sách cho phép địa chỉ được tuyển chọn kỹ càng. Một chủ sở hữu khác có thể triển khai cùng Rego với các tham số linh hoạt và gọi hệ thống đó là “đã được bảo mật theo chính sách”.
Cùng logic. Khác chủ quyền.
expireAfter không xoay vòng, không làm mới hoặc không vô hiệu hóa các tham số đó. Nó chỉ xác định khung thời gian thực thi của một bản chứng thực.
Gọi setPolicy(PolicyConfig) sẽ tạo một policyId mới. ID trước đó trở nên lỗi thời, và quá trình xác thực sẽ từ chối mọi bản chứng thực nếu policyId không còn khớp với cấu hình đang hoạt động của PolicyClient.
Điều này khiến các thay đổi cấu hình trở nên nhìn thấy một cách có thể kiểm chứng bằng mật mã.
Nhưng nhìn thấy không đồng nghĩa với hiểu rõ.
Mặt điều khiển đã chuyển từ logic hợp đồng sang các thiết lập do chủ sở hữu kiểm soát, quyền cập nhật và việc lựa chọn tham số.
Vậy bảo mật có thể cấu hình thực sự mạnh hơn—hay quản trị chỉ đơn giản bị nén vào các trường JSON mà đa số người dùng, kiểm toán viên và thị trường sẽ không bao giờ xem?
@NewtonProtocol
#newt $NEWT
Nó có thể là cấu hình giả dạng như quản trị.
Kiến trúc PolicyClient của Newton Protocol đặt ra một câu hỏi bảo mật khó hơn: không phải liệu logic chính sách có đúng hay không, mà là ai nắm quyền định nghĩa logic đó được phép mang ý nghĩa như thế nào.
Chính sách Rego có thể vẫn công khai, tất định, tái sử dụng và không thay đổi. Tuy nhiên, chu vi thực thi của nó được viết lại bằng các giá trị JSON phẳng được truyền qua data.params mà không cần đụng chạm đến code.
Điều đó có nghĩa là cùng một mã chính sách có thể tạo ra các chế độ quyền khác nhau một cách triệt để giữa các ứng dụng.
Một chủ sở hữu có thể áp đặt các ngưỡng giao dịch hẹp, các trần mức phơi bày nghiêm ngặt và các danh sách cho phép địa chỉ được tuyển chọn kỹ càng. Một chủ sở hữu khác có thể triển khai cùng Rego với các tham số linh hoạt và gọi hệ thống đó là “đã được bảo mật theo chính sách”.
Cùng logic. Khác chủ quyền.
expireAfter không xoay vòng, không làm mới hoặc không vô hiệu hóa các tham số đó. Nó chỉ xác định khung thời gian thực thi của một bản chứng thực.
Gọi setPolicy(PolicyConfig) sẽ tạo một policyId mới. ID trước đó trở nên lỗi thời, và quá trình xác thực sẽ từ chối mọi bản chứng thực nếu policyId không còn khớp với cấu hình đang hoạt động của PolicyClient.
Điều này khiến các thay đổi cấu hình trở nên nhìn thấy một cách có thể kiểm chứng bằng mật mã.
Nhưng nhìn thấy không đồng nghĩa với hiểu rõ.
Mặt điều khiển đã chuyển từ logic hợp đồng sang các thiết lập do chủ sở hữu kiểm soát, quyền cập nhật và việc lựa chọn tham số.
Vậy bảo mật có thể cấu hình thực sự mạnh hơn—hay quản trị chỉ đơn giản bị nén vào các trường JSON mà đa số người dùng, kiểm toán viên và thị trường sẽ không bao giờ xem?
@NewtonProtocol
#newt $NEWT