Tôi đang đọc qua tài liệu chính sách danh tính của @NewtonProtocol và một dòng đã khiến tôi dừng lại: bất kỳ lỗi nào trong một quy tắc Rego đều khiến quy tắc đó được đánh giá là không xác định (undefined). Và giá trị undefined sẽ được coi như là bị từ chối.
Nghe có vẻ an toàn. Nhưng thực ra đó là toàn bộ câu chuyện ở đây.
Yêu cầu
Các built-in về danh tính của Newton (newton.identity.kyc.*) được thiết kế theo cơ chế fail-closed. Nếu không thể phân tích cú pháp một ngày, hoặc mã quốc gia bị sai định dạng, hoặc một mảng rỗng, thì chính sách không báo lỗi ầm ĩ. Nó chỉ lặng lẽ từ chối. Không có ngoại lệ, không có crash, không có thông báo "hãy kiểm tra dữ liệu của bạn". Chỉ đơn giản là: không được ủy quyền.
Đó là tư thế tuân thủ chủ đích. Nhưng điều đó cũng có nghĩa là dữ liệu đầu vào sai và một vi phạm chính sách thực sự trông giống hệt nhau từ bên ngoài.
Tài liệu thực sự hiển thị
age_gte(min_age) đối chiếu ngày sinh với một reference_date. Nếu chuỗi ngày sinh không thể phân tích được, hoặc số được cung cấp là số âm, hàm sẽ lỗi và toàn bộ rule sẽ sụp về undefined.
address_in_countries(), address_in_subdivision(), và address_not_in_subdivision() đều thất bại theo cùng một cách nếu bạn truyền tên quốc gia đầy đủ thay vì mã ISO, hoặc lỡ truyền một mảng rỗng.
not_expired() và valid_for(min_days) đều phụ thuộc expiration_date phải tồn tại và có thể phân tích. Thiếu trường đó không phải là "bỏ qua kiểm tra này", mà là một điều cấm đoán cứng.
address_not_in_subdivision() khá thú vị. Nó được thiết kế để loại trừ một vài bang (ví dụ: US-NY, US-HI) thay vì cho phép 48 bang khác. Hiệu quả. Nhưng nó cũng có nghĩa là chỉ một mã ISO sai sẽ âm thầm chặn những người dùng thực tế đủ điều kiện.
Không gì trong số này là một lỗi. Newton đang chọn denial-by-default thay vì permissive-by-default. Với KYC, điều đó có thể nói là đúng đắn. Hầu hết hệ thống tuân thủ sẽ thà từ chối một người dùng tốt còn hơn là phê duyệt một người dùng tệ.
Sự căng thẳng
Đoạn này khiến tôi hơi khó chịu.
Nếu pipeline tích hợp của bạn cung cấp #Newt a ngày issue_date bị định dạng hơi sai, hoặc nhà cung cấp KYC của bạn trả về một address_subdivision rỗng, thì người đó sẽ bị từ chối, giống như khi họ bị dưới tuổi hoặc đến từ một vùng bị chặn. Không có lỗi ở cấp trường được trả về cho lớp ứng dụng mà tôi thấy trong tài liệu này. Chỉ là một boolean false, không thể phân biệt với một lần thất bại chính sách thật sự.
Với một nhà phát triển đang gỡ lỗi "vì sao người dùng này bị từ chối", đây là một điểm bắt đầu thật sự gây bực bội. Bạn không thể biết chỉ từ kết quả chính sách, rằng:
người dùng thực sự đã fail kiểm tra, hay
pipeline dữ liệu của bạn đã đưa rác vào Newton
Cùng một kết quả. Cách sửa thì rất khác.
Tôi sẽ xác minh điều này trước khi dựa vào nó
Không phải là một lời chỉ trích, chỉ là danh sách mà tôi thực sự sẽ chạy qua nếu tôi tích hợp Newton:
Trước khi dữ liệu identity đi vào engine chính sách, nó được xác thực ở đâu, có kiểm tra schema ở upstream không, hay Newton nhìn trực tiếp output thô từ nhà cung cấp KYC?
Các lệnh gọi built-in bị lỗi có được ghi log ở đâu đó có thể phân biệt với các lần denial hợp lệ không, hay mọi thứ chỉ hiện như "not authorized" trong audit trail?
Định dạng mã ISO (quốc gia, subdivision) có được bắt buộc tại thời điểm nạp dữ liệu hay chỉ được kiểm tra khi một rule chính sách chạy?
Điều gì xảy ra với age_gte nếu birthdate có mặt nhưng ở một định dạng ngày hơi khác so với mong đợi, lỗi phân tích ngầm, hoặc lỗi được nêu rõ?
Có cách nào để phân biệt "bị từ chối vì dưới tuổi" với "bị từ chối vì trường ngày bị định dạng sai" trong bất kỳ dashboard hoặc log nào mà Newton hiển thị không?
Với address_not_in_subdivision, có giới hạn kích thước cho mảng exclusion không, và mảng rỗng mặc định là cho phép tất cả hay từ chối tất cả?
Nếu câu trả lời cho hầu hết các câu hỏi này là "không có khả năng quan sát", thì điều đó không làm thay đổi rằng fail-closed vẫn là mặc định đúng cho identity. Nhưng nó có nghĩa là công việc tích hợp không thật sự xoay quanh việc viết các rule Rego. Mà là đảm bảo dữ liệu sạch được đưa tới Newton trước khi chính sách chạy. Lớp chính sách chỉ đáng tin cậy như những gì đưa vào nó.
Ghi chú rủi ro, thẳng thắn
Fail-closed che giấu lỗi về chất lượng dữ liệu. Một lệnh từ chối không cho bạn biết bạn đang rơi vào chế độ lỗi nào. Đó là rủi ro vận hành, không phải rủi ro bảo mật, nhưng nó sẽ khiến bạn tốn thêm vé hỗ trợ.
Không thấy có đường dẫn thử lại hoặc ghi đè trong tài liệu. Nếu một người dùng hợp lệ bị từ chối do lỗi không khớp định dạng ở upstream, thì không có gì ở đây mô tả việc nó được sửa như thế nào nếu không phải gửi lại thủ công.
Danh sách loại trừ làm thay đổi rủi ro về phía downstream. address_not_in_subdivision tiện lợi, nhưng nó có nghĩa là gánh nặng cập nhật danh sách loại trừ đó nằm hoàn toàn ở người viết policy chứ không phải ở Newton.
Sự thật vs ý kiến, vì điều đó quan trọng ở đây
Sự thật: tài liệu nói rằng một lỗi built-in khiến rule chứa nó được đánh giá thành undefined, và Newton coi undefined như một lần denial.
Ý kiến: điều này tạo ra một lỗ hổng trong gỡ lỗi cho bên tích hợp, vì cùng một boolean được hiển thị dù người dùng bị fail kiểm tra hay dữ liệu chỉ đơn giản là sai.
Tôi không nghĩ đây là một lỗi trong thiết kế của Newton. Fail-closed là lựa chọn đúng cho chính sách nhận diện. Tôi chỉ nghĩ tài liệu đã đánh giá thấp mức độ công việc tích hợp thực tế sẽ là làm sạch dữ liệu trước khi Rego chạy, chứ không phải bản thân Rego.
Dù sao. Vẫn đang đọc qua tài liệu tham chiếu của SDK để xem có phần hiển thị lỗi mà tôi đang bỏ sót không_