Следующая поверхность атаки в крипто может быть не кодом.
Возможно, это конфигурация, замаскированная под управление.
Архитектура PolicyClient протокола Newton ставит более сложный вопрос безопасности: не в том, корректна ли логика политики, а в том, кто обладает полномочиями определять, что эта логика разрешено означать.
Политика Rego может оставаться публичной, детерминированной, переиспользуемой и неизменной. Но периметр ее применения переписывается плоскими значениями JSON, передаваемыми через data.params, без изменения кода.
Это означает, что один и тот же код политики может порождать радикально разные режимы прав в разных приложениях.
Один владелец может навязать узкие пороги торговли, строгие ограничения по экспозиции и тщательно подобранные allowlist-ы адресов. Другой может развернуть ту же Rego с разрешающими параметрами и назвать систему «политика защищена».
Та же логика. Разная суверенность.
expireAfter не выполняет ротацию, обновление или инвалидирование этих параметров. Он лишь определяет окно выполнения для аттестации.
Вызов setPolicy(PolicyConfig) создает новый policyId. Предыдущий идентификатор становится устаревшим, а валидация отклоняет любую аттестацию, чья policyId больше не соответствует активной конфигурации PolicyClient.
Так изменения конфигурации становятся криптографически видимыми.
Но видимость — не понимание.
Плоскость управления переместилась из логики контракта в настройки, контролируемые владельцем, права на обновления и выбор параметров.
Так является ли конфигурируемая безопасность действительно сильнее — или управление просто сжато в поля JSON, которые большинство пользователей, аудиторов и рынков никогда не будут рассматривать?
@NewtonProtocol
#newt $NEWT
Возможно, это конфигурация, замаскированная под управление.
Архитектура PolicyClient протокола Newton ставит более сложный вопрос безопасности: не в том, корректна ли логика политики, а в том, кто обладает полномочиями определять, что эта логика разрешено означать.
Политика Rego может оставаться публичной, детерминированной, переиспользуемой и неизменной. Но периметр ее применения переписывается плоскими значениями JSON, передаваемыми через data.params, без изменения кода.
Это означает, что один и тот же код политики может порождать радикально разные режимы прав в разных приложениях.
Один владелец может навязать узкие пороги торговли, строгие ограничения по экспозиции и тщательно подобранные allowlist-ы адресов. Другой может развернуть ту же Rego с разрешающими параметрами и назвать систему «политика защищена».
Та же логика. Разная суверенность.
expireAfter не выполняет ротацию, обновление или инвалидирование этих параметров. Он лишь определяет окно выполнения для аттестации.
Вызов setPolicy(PolicyConfig) создает новый policyId. Предыдущий идентификатор становится устаревшим, а валидация отклоняет любую аттестацию, чья policyId больше не соответствует активной конфигурации PolicyClient.
Так изменения конфигурации становятся криптографически видимыми.
Но видимость — не понимание.
Плоскость управления переместилась из логики контракта в настройки, контролируемые владельцем, права на обновления и выбор параметров.
Так является ли конфигурируемая безопасность действительно сильнее — или управление просто сжато в поля JSON, которые большинство пользователей, аудиторов и рынков никогда не будут рассматривать?
@NewtonProtocol
#newt $NEWT