NIST SP 800-207 описывает архитектуру нулевого доверия вокруг двух логических компонентов: движок политики, который принимает решение, и администратор политики, который устанавливает или разрывает соединение. Раздел 5.1 формулирует их положение прямо: «Никакое взаимодействие между корпоративными ресурсами не происходит, если оно не одобрено и, возможно, не сконфигурировано движком и администратором политики».
Эта фраза — вся архитектура в одном предложении, и она же проблема для всего, что работает без сети. Банкомат, киоск, устройство в подсобке магазина проверяет человека, стоящего перед ним. Пути к движку политики в этот момент нет — не потому, что что-то сломалось, а потому, что устройство так развёрнуто.
Формулировки ниже даны в нашем переводе: документ издан на английском, оригинал по ссылке в конце.
Что документ говорит о недоступности
Он её разбирает, и здесь важнее не факт, а рамка, в которую он её ставит.
Раздел 5.2, «Отказ в обслуживании или разрыв сети»:
Если атакующий нарушает или блокирует доступ к точкам применения политики либо к движку и администратору политики (то есть DoS-атакой или перехватом маршрута), это может неблагоприятно сказаться на работе организации. Организации могут снизить эту угрозу, разместив применение политики в должным образом защищённой облачной среде или реплицировав его в нескольких местах согласно руководству по киберустойчивости.
И сразу следом — оговорка, которую легко пролистать:
Это снижает риск, но не устраняет его.
Заканчивается раздел замечанием, что операционная ошибка у хостинг-провайдера «может лишить работоспособности всю организацию, если движок или администратор политики станут недоступны по сети».
Все предлагаемые меры — инженерия доступности: разместить компоненты понадёжнее, реплицировать, следовать руководству по киберустойчивости. Это верный ответ, когда недоступность — отказ. И это не ответ, когда недоступность заложена в конструкцию.
Дальше документ идёт ещё честнее. В приложении B перечислено то, что авторы считали незакрытым. Пункт B.4.7 называется «Устойчивость архитектуры нулевого доверия к разрывам в организации и сети» и входит в список, представленный как «серые зоны в знаниях об эксплуатируемых средах нулевого доверия», которые являются «направлениями будущей работы для исследователей». Пример там — облачный движок политики, который переживает распределённую атаку, но не может достучаться до точек применения, стоящих рядом с ресурсами.
Итог честный: SP 800-207 знает про этот случай, предлагает для него инженерию доступности, признаёт, что она пробел не закрывает, и относит остаток к исследованиям. Тот, у кого устройства действительно без связи, не найдёт там рецепта — и это не его недоработка. Рецепта нет.
Принцип, который действительно мешает
Неудобно не требование связи как таковое. Неудобен принцип 6:
Аутентификация и авторизация для всех ресурсов динамические и строго применяются до предоставления доступа. Это постоянный цикл получения доступа, поиска и оценки угроз, адаптации и непрерывной переоценки доверия в ходе взаимодействия.
Постоянному циклу нужно то, относительно чего он крутится. На устройстве, которое видит сеть изредка или никогда, непрерывная переоценка недоступна ни за какие деньги. Как и непрерывная диагностика состояния актива из принципа 5, и сбор текущего состояния для обратной связи в политику из принципа 7.
Здесь многие вендорские тексты незаметно передёргивают: описывают схему, удовлетворяющую принципам, и прикладывают её к устройствам, которые этим принципам удовлетворять не могут. Точнее будет сказать иначе: на устройстве без связи эти принципы не выполняются. Выполняется то, что важнее всего для решения о входе, — доверие оценивается на каждую сессию, положение в сети не даёт ничего, и актив не считается доверенным просто потому, что он внутри периметра.
Перенос решения во времени, а не в пространстве
Жить с этим можно по-разному. Устройство может кэшировать последнее полученное решение и действовать по нему, пока оно не устарело. Движок политики можно реплицировать до отделения или до самого устройства — это совет раздела 5.2, доведённый до предела. Доступ можно выдавать локально, а сверяться с центром задним числом. Каждый вариант разменивает своё: свежесть решения, эксплуатационную поверхность или возможность разобраться, что произошло в промежутке.
Прочтение, из которого исходим мы, состоит в том, что решение по политике не обязано приниматься в тот же момент, что и запрос доступа. Оно должно быть принято до него, под контролем организации, с результатом, который устройство умеет проверить само.
На практике это означает, что оценка проходит при выпуске удостоверения — личность, открываемая роль, устройства, на которых она действует, и срок, — а результат запечатывается подписью. Точка применения остаётся на устройстве и проверяет локально подпись, срок, область действия и список отзыва. Связь нужна для управления парком, а не для того, чтобы открыть дверь. Как это выглядит на Linux послойно, разобрано в статье про Zero Trust в Linux-парке.
Стоит назвать и то, что при этом теряется. Непрерывная переоценка сжимается до двух более грубых инструментов: короткого срока действия, чтобы решение истекало само, и списка отзыва, который доходит до конкретного устройства по своему расписанию, а не мгновенно. В промежутке между тем, как решение изменилось в центре, и тем, как устройство об этом узнало, оно действует по устаревшей политике. Промежуток ограничен и измерим, а сокращается он ценой срока жизни удостоверения и частоты рассылки — это явный размен, а не решённая задача.
Честные границы
SP 800-207 — руководство, а не стандарт соответствия. В нём нет ни сертификации, ни методики проверки, поэтому «соответствует 800-207» не может заявить никто, включая нас. Документ поддерживает не заявление, а разбор: какие принципы схема выполняет, какие приближает и какие на данном классе устройств выполнить не может.
Для устройств самообслуживания этот разбор имеет ясную форму. Оценка на каждую сессию, отсутствие доверия по положению в сети, отсутствие доверия к активу по умолчанию — выполняется. Непрерывная переоценка, постоянный мониторинг состояния, контекст в реальном времени — не выполняется и заменяется ограниченным сроком действия и отзывом с названным окном распространения. Если кто-то предлагает более сильное утверждение, к нему стоит отнестись настороженно.
Источники
- NIST SP 800-207, Zero Trust Architecture (август 2020; выше приведены разделы 2.1, 5.1, 5.2 и B.4.7)
- Zero Trust в Linux-парке: карта подходов и где в ней дыры — послойный обзор, который здесь сужен до одного документа
- Требование 8 PCI DSS на офлайн-устройствах — та же структурная проблема в стандарте, где соответствие определено