Стандарт, предписывающий механизмы, рано или поздно предпишет тот, который устройство без связи выполнить не может. ISO/IEC 27002:2022 написан иначе: каждая мера формулирует результат и цель, а руководство под ней предлагает средства, а не обязывает к ним. Для устройства, которое проверяет инженера без доступной сети, это меняет характер задачи — спорить почти не о чем, и трудность переезжает в свидетельства: что показать аудитору, если машина простояла весь проверяемый период отключённой.

Формулировки ниже даны в нашем переводе: стандарт издан на английском, ссылка на оригинал в конце.

Где ISO терпимее предписывающего стандарта

Яснее всего это на отзыве доступа. PCI DSS укладывает его в одну строку — доступ уволенного отзывается немедленно, — а на офлайн-парке буквально выполнить это трудно. ISO требует того же результата с другим допуском. Мера 5.18 говорит, что права доступа «предоставляются, пересматриваются, изменяются и снимаются в соответствии с политикой организации и правилами управления доступом», а руководство просит обеспечить

снятие прав доступа, когда они человеку больше не нужны, и в особенности снятие прав доступа сотрудников, покинувших организацию, в разумные сроки

«Разумные сроки» — это оценка риска, а не срок в часах. Список отзыва, доходящий до устройства по заданному расписанию, укладывается в формулировку, если интервал назван, обоснован и пересматривается. Дальше та же мера описывает короткоживущие удостоверения прямым текстом, предлагая рассмотреть

предоставление временных прав доступа на ограниченный период с отзывом по истечении срока, в особенности для временного персонала или временного доступа, потребовавшегося сотрудникам

и перечисляет среди способов снятия доступа «отзыв или замену ключей, аутентификационной информации, идентификационных карт или подписок». Истекающее само по себе удостоверение здесь не обходной манёвр, а один из предусмотренных стандартом механизмов.

Стандарт называет механизм по имени

Мера 8.5 о безопасной аутентификации в руководстве необычно пряма:

Там, где требуется сильная аутентификация и подтверждение личности, следует использовать методы аутентификации, альтернативные паролям, — такие как цифровые сертификаты, смарт-карты, токены или биометрические средства.

Сертификат на токене не приходится обосновывать против правила, написанного под пароль: это названная альтернатива. А парольная машинерия в других местах обусловлена в самом тексте стандарта. Требования меры 5.17 к системе управления паролями открываются словами «когда пароли используются в качестве аутентификационной информации» — там, где паролей нет, разделу не за что зацепиться, и доказывать ничего не нужно.

Личность, учётная запись и человек за обеими

Мера 5.16 требует управлять полным жизненным циклом идентичностей, и её руководство проводит границу, о которой офлайн-устройству приходится думать:

для идентичностей, назначенных людям, конкретная идентичность связывается только с одним человеком, чтобы можно было привлечь его к ответственности за действия, выполненные под этой идентичностью

и сразу следом допускает, что идентичности, назначенные нескольким людям, «разрешаются только там, где они необходимы по деловым или эксплуатационным причинам, и подлежат отдельному утверждению и документированию».

На устройстве самообслуживания учётная запись в операционной системе — это обычно роль: оператор, обслуживание, администратор, — общая для всех, кто эту роль исполняет. Личность не совпадает с учётной записью. Если человек устанавливается криптографически при входе и его имя попадает в запись об этом входе, ответственность привязывается к человеку, а учётная запись остаётся ролью. Деловое обоснование и утверждение остаются документами, которые организация должна оформить, — ровно как сказано в руководстве.

Свидетельства придётся снимать с устройства

Вот здесь офлайн-парк действительно стоит работы. Мера 8.15 требует, чтобы журналы «фиксировали действия, исключения, сбои и другие значимые события», и перечисляет, что должно быть в записи: идентификаторы пользователей, даты и время значимых событий, включая вход и выход, идентичность устройства и его расположение, системные действия. Среди событий, которые следует рассмотреть для журналирования, — успешные и отклонённые попытки доступа, использование привилегий, создание, изменение и удаление идентичностей.

Ничего из этого не требует связи, чтобы быть произведённым, — но всё должно быть произведено локально и дожить до того, кто это соберёт. На связанном парке такие записи копятся в центре как побочный эффект того, что аутентификация происходит в центре. На отключённом устройстве не копится нигде, если устройство само не записывает. Аудитор, просящий историю входов на конкретную машину за год, просит то, что устройство либо сохранило, либо нет.

Та же мера 5.18 просит «вести централизованную запись прав доступа, предоставленных идентификатору пользователя» и «запись изменений логических и физических прав доступа». Там, где удостоверения выпускаются централизованно, а применяются локально, этой записью становится журнал выпуска — единственное место, которое видит всё, потому что выпуск и есть шаг, который никогда не офлайн.

Чему такая схема не помогает

Руководство меры 8.5 о процедурах входа включает

завершение простаивающих сессий по истечении заданного периода бездействия, в особенности в зонах повышенного риска — публичных или внешних, находящихся вне управления безопасностью организации

Это описание подходит устройству самообслуживания точнее, чем большинство формулировок в стандартах, — и к тому, как именно вошёл инженер, отношения не имеет. Завершение простаивающей сессии определяется настройками сессии и блокировки экрана в операционной системе; его нужно настроить на устройстве и подтверждать отдельно. Механизм входа, приписывающий себе эту меру, приписывал бы чужую работу.

То же верно для мер, соседствующих с доступом: физическая защита корпуса, целостность программного обеспечения на машине, синхронизация времени, без которой журналы не сопоставить. Мера 8.15 отмечает, что синхронные источники времени важны именно потому, что позволяют сопоставлять журналы разных систем, — а на устройствах, которые сверяются с центральными часами редко, это вопрос, требующий ответа, а не умолчания.

Честные границы

ISO/IEC 27001 сертифицирует систему менеджмента организации, а не продукт. Никакое средство не бывает «сертифицированным по ISO 27001» так, чтобы это переходило к покупателю, и у Tessera такой сертификации нет. Что схема действительно может — облегчить подтверждение конкретных мер и сделать свидетельства доступными с машины, простоявшей год без связи.

Источники