Сотрудник банка не может самостоятельно увеличить лимит перевода денег самому себе
Есть одна вещь, которую я однажды нашёл довольно интересной, когда проходил процедуру в банке.
Сотрудник может обрабатывать транзакции для клиентов весь день.
Можно проверить документы.
Можно одобрить несколько этапов в процессе.
Но если именно их аккаунту нужно увеличить лимит перевода денег, они не могут изменить это самостоятельно.
Это должно пройти через другого человека.
Сначала мне показалось довольно неудобным.
Если система уже знает, что это сотрудник банка, почему бы не разрешить сразу?
Только потом, обдумав это, понимаешь: возможно, банк защищает не лимит.
Они защищают границу между исполнителем и тем, кто пишет правила, для осуществления выполнения.
Это заставило меня довольно много задуматься, когда я читал о том, как @NewtonProtocol строят authorization.
Меня интересует не вопрос о том, есть ли у агента право выполнять действие.
Это вопрос, который возникает раньше.
Кто решает, что можно или нельзя?
Это очень существенная разница.
В самых разных системах мы обычно тратим много времени на проверку исполнителей.
Действие законно?
Permission верный?
Execution находится в пределах?
Но, похоже, Ньютон интересуется ещё более глубоким слоем.
Кому разрешено изменять именно эти ограничения?
Если исполнитель также является тем, кто может редактировать policy, то любые последующие проверки становятся крайне хрупкими.
Тогда проблема уже не в execution.
Проблема в том, что игрок тоже может сам переписать правила игры.
Вот почему я считаю, что разделение на автора policy и исполнителя policy — это не просто вопрос делегирования прав.
Это архитектурное решение.
Решение, которое позволяет policy сохранять смысл даже тогда, когда execution происходит полностью автоматически.
Самоопровержение.
Но разделение полномочий всегда имеет свою цену.
Вернёмся к банку.
Иногда клиентам нужно срочно увеличить лимит.
Сотрудник хорошо знал, что документы полные.
Знать, что сделка полностью законна.
Но им всё равно нужно дождаться подтверждения от другого, потому что система не позволяет самостоятельно менять собственные ограничения.
Этот опыт наверняка был медленнее.
Причём иногда это даже заставляет пользователей чувствовать, что процесс слишком негибкий.
Но если вообще убрать эту границу ради того, чтобы всё работало быстрее, то весь механизм контроля теряет смысл.
Исполнитель больше не ограничен policy.
Они могут сначала изменить политику, а затем выполнить действие.
Тогда было сломано не одну сделку.
И это — доверие самой системе.
То, что мне хочется яснее увидеть из @NewtonProtocol , — это не то, сколько существует типов policy.
Не то, как система сохраняет дистанцию между тем, кто определяет policy, и тем, кому разрешено действовать внутри этой policy.
Для меня authorization layer по-настоящему заслуживает доверия только тогда, когда у того, кто имеет право исполнять, нет одновременно права переписывать правила, чтобы узаконить собственные действия.
Если протокол Newton сохраняет эту границу чётко и прозрачно, то его ценность не будет заключаться в том, что система проверяет больше.
А именно в том месте, где никто не может незаметно изменить правила и затем извлечь выгоду лично из этого изменения.
