Аппаратная безопасность в закупке ПК: формулировки требований

Зачем вообще нужны требования к аппаратной безопасности

Если в закупке ПК не описать аппаратную безопасность, вы получите просто «железо, которое включается», но не обязательно защищает загрузку, учетные данные и ключевые настройки. Исправлять это после поставки почти всегда дороже: меняются процедуры, докупаются средства защиты, растет число инцидентов и спорных ситуаций на эксплуатации.

В ТЗ обычно встречаются две крайности:

• слишком общие фразы вроде «должна быть высокая безопасность» или «поддержка современных технологий защиты». Их нельзя проверить на приемке.
• излишняя конкретика: бренд, модель чипа, «TPM версии X.Y от производителя Z». Такие требования легко оспорить, и часто они не дают практической пользы.

Рабочий подход - описывать не «что именно купить», а «что должно уметь устройство» и «как это подтвердить». Тогда требования становятся проверяемыми: вы заранее понимаете, что будет видно в UEFI/BIOS, что покажет ОС и какие действия приемки это подтверждают.

Обычно заказчик пытается защитить четыре вещи: цепочку загрузки, ключи и учетные данные, доступ к настройкам UEFI/BIOS и управление этими настройками (чтобы ИТ-служба могла вводить политики и восстанавливать доступ по регламенту).

Представьте школу или поликлинику: ПК стоят в общих кабинетах, доступ есть у десятков людей. Без требований к Secure Boot и паролям UEFI достаточно одной флешки и нескольких минут, чтобы попробовать загрузить стороннюю среду, сбросить локальные пароли или отключить защиту. Хорошо сформулированные требования не мешают работе, но резко сокращают такие «быстрые атаки» и упрощают приемку: либо функция есть и включается по политике, либо нет.

Принципы корректных формулировок в ТЗ без лишней конкретики

Хороший раздел про аппаратную безопасность в закупке ПК читается как набор условий, которые можно проверить: что должно быть включено, как это проверяется при приемке и чем подтверждается. Это экономит время на согласованиях и снижает риск получить «формально подходящее», но неудобное решение.

Удобный шаблон для каждого пункта одинаковый: требование - критерий проверки - подтверждающий документ. Тогда у закупки, ИБ и ИТ-эксплуатации появляется общий язык, а не спор о трактовках.

Пишите про функцию и результат, а не про реализацию

Излишняя конкретика ломает конкуренцию и вынуждает участников искать обходные пути. Вместо «TPM версии X только такого-то типа» описывайте результат: наличие функции, возможность включения, измеримость состояния и управляемость.

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

Разделяйте обязательное и желательное

В ТЗ лучше сразу отделить то, без чего оборудование не принимается, от того, что дает удобство и может оцениваться баллами. На практике удобно держать три группы: обязательные требования, желательные требования и требования к управлению (то, что нужно для сопровождения: учет, удаленное администрирование, политика доступа).

Сразу думайте, кто администратор и как это будет жить в парке

Формулировки должны учитывать эксплуатацию: кто задает политики, где хранятся пароли и ключи восстановления, как меняются настройки при переводе ПК между подразделениями, что происходит при ремонте или замене платы.

Простой «жизненный» вариант: «Администратор заказчика должен иметь возможность централизованно включать и контролировать ключевые настройки безопасности, а доступ в настройки прошивки должен быть защищен паролем с процедурой смены и документированием». Это не диктует конкретный инструмент, но фиксирует управляемость.

Просите подтверждение не «на словах», а в понятном виде: паспорт/спецификация, декларация соответствия требованиям ТЗ и чек-лист приемки с шагами проверки. Если поставка идет от производителя или системного интегратора, заранее согласуйте, какие документы и выгрузки будут приложены к партии. Так приемка проходит без сюрпризов.

TPM: примеры требований, которые реально проверить

TPM в техническом задании лучше описывать не через бренд и модель, а через функцию и проверяемый результат. Это снижает риск, что поставщик привезет ПК, но нужная функция окажется отключенной в UEFI или недоступной для ОС.

Базовая формулировка для ТЗ: «В составе ПК должен быть модуль доверенной платформы TPM версии 2.0 (дискретный или встроенный), поддерживаемый UEFI и доступный операционной системе для стандартных механизмов защиты».

Дальше важно зафиксировать не только наличие, но и состояние. Например:

• TPM 2.0 включается и инициализируется средствами UEFI, без специализированных сервисных утилит.
• После поставки TPM доступен ОС и отображается как готовый к использованию (Ready/Activated/Enabled или эквивалентный статус).
• Поддерживается работа функций шифрования диска и защиты ключей на уровне ОС с использованием TPM.

Чтобы это принималось без споров, заранее укажите подтверждение: акт проверки и вывод системной информации (скриншоты или текстовый отчет), плюс фиксация параметров UEFI, связанных с TPM. На приемке обычно достаточно показать раздел UEFI с настройками TPM, системный отчет ОС со статусом TPM и запуск тестового сценария шифрования диска в режиме проверки (без обязательного шифрования всех ПК).

Граница разумного: не требуйте редкие лабораторные режимы, «внутренние идентификаторы» и конкретные названия пунктов меню UEFI. У разных платформ они различаются и часто не влияют на безопасность, зато создают формальные основания для отказа.

Если закупается партия для госоргана или крупной организации, попросите на одном образце продемонстрировать включенный TPM и его видимость в ОС, а затем закрепите в акте, что такие же настройки применены ко всей партии.

Secure Boot: корректные формулировки для закупки

Secure Boot нужен, чтобы ПК запускался только по доверенной цепочке загрузки. Это снижает риск загрузочных вирусов и подмены загрузчика. В требования Secure Boot лучше закладывать ожидаемый результат и признаки проверки, а не детали про ключи и «внутренности» прошивки.

Проверяемый минимум звучит просто: функция есть, ее можно включить, и при включении она не допускает загрузку неподписанных компонентов.

Примеры требований, которые обычно легко принять:

• ПК поддерживает UEFI Secure Boot с возможностью включения и отключения в UEFI.
• При включенном Secure Boot ОС загружается только при наличии действительной цифровой подписи загрузочных компонентов.
• Secure Boot совместим с современными ОС и стандартными корпоративными сценариями развертывания без необходимости постоянного отключения.
• Если для корпоративного образа ОС или драйверов нужно добавление доверенных сертификатов, должна быть документированная процедура управления ключами (кто делает, как фиксируется, как откатывается).

Важно учесть корпоративные сценарии. Иногда используется свой загрузчик, агент шифрования диска или подписанные драйверы. Цель здесь не «запретить любые изменения», а обеспечить управляемость: изменения ключей допускаются только по согласованной процедуре, с фиксацией и возможностью восстановления штатного набора.

На приемке требуйте понятные подтверждения:

• страница UEFI со статусом Secure Boot (Enabled/Disabled);
• отчет из ОС о состоянии Secure Boot;
• проверка, что изменение доступно только после входа под администратором UEFI;
• отметка в акте, включен ли Secure Boot (если это политика заказчика).

Чего лучше избегать: «ключи нельзя менять никогда» или «Secure Boot всегда включен без исключений». Такие запреты ломают обслуживание и восстановление. Практичнее: включено по умолчанию, изменения только по утвержденной процедуре и с ответственными лицами.

Пароли BIOS/UEFI и доступ к настройкам: как описать управление

Пароли BIOS/UEFI часто прописывают одной строкой, а потом выясняется, что пароль стоит только «для галочки». Важно различать два механизма: пароль администратора (защищает вход в настройки и изменение параметров) и пароль на загрузку (запрашивается при включении ПК).

Если цель - защитить конфигурацию и цепочку загрузки, ключевым обычно является пароль администратора UEFI. Пароль на загрузку полезен в отдельных сценариях (например, ПК в открытом помещении), но он не заменяет ограничения доступа к настройкам.

Для раздела «управление паролями BIOS UEFI» подойдут формулировки, которые проверяются на приемке:

• На каждом ПК поддерживается защита доступа к настройкам BIOS/UEFI паролем администратора (Setup/Administrator Password). Без ввода пароля изменение параметров невозможно.
• Поддерживается пароль на загрузку (Power-on/Boot Password) с возможностью включения/отключения по решению заказчика.
• Есть разделение прав: пользователь без административного пароля не может менять Secure Boot, TPM, порядок загрузки и включать загрузку с внешних носителей.
• Поддерживается применение политики заказчика по управлению настройками UEFI/BIOS (без требования конкретного ПО).

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

Отдельно пропишите, как допускается сброс пароля. Это снижает риск «универсальных» мастер-кодов. Нормальный вариант: сброс возможен только через сервисную процедуру по регламенту организации, с подтверждением полномочий и фиксацией факта работ.

На приемке достаточно нескольких действий: убедиться, что без админ-пароля параметры не меняются; включить пароль на загрузку и проверить запрос при старте; попытаться изменить порядок загрузки без прав и зафиксировать отказ.

И не забывайте про жизненный цикл: при вводе в эксплуатацию пароли передаются ответственному лицу заказчика по акту, а при списании выполняется процедура удаления/сброса настроек по внутреннему регламенту.

Как составить раздел ИБ в ТЗ: пошаговый шаблон

Хороший раздел ИБ начинается не с названий технологий, а с того, где и как будут работать компьютеры. Одни и те же требования по-разному выглядят для офисных ПК, учебного класса, серверной стойки и удаленных филиалов.

Шаблон из 5 шагов

Сначала зафиксируйте контекст: тип пользователей, уровень доступа, есть ли удаленное администрирование, нужны ли стандартные образы ОС.

Дальше двигайтесь по шагам:

1. Сценарии использования: офис, аудитории, пункты обслуживания, стойка/ЦОД, удаленные площадки.

2. Обязательные функции: минимум, который реально нужен. Обычно это TPM, Secure Boot и защита настроек UEFI/BIOS.

3. Критерии приемки: что проверяют при поставке и кто это делает. Формулировка должна быть проверяемой: «включено по умолчанию», «доступ к настройкам защищен», «статус считывается штатными средствами ОС».

4. Документация и поддержка: краткая инструкция по проверке настроек, порядок сброса паролей через сервис, требования к поддержке.

5. Согласование: перед публикацией прогоните текст через ИБ и ИТ. Уберите спорные вещи вроде «только такой-то чип» или «поддержка всех версий ОС», если это не критично.

Чтобы требования Secure Boot, TPM и паролей не превратились в лозунги, добавьте пример приемки: «при выборочной проверке 10% партии подтверждается наличие TPM и включенный Secure Boot, а вход в BIOS/UEFI возможен только после ввода пароля администратора».

Документы и приемка: чем подтверждать выполнение требований

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

Какие документы запросить у поставщика

Обычно достаточно стандартного комплекта. Зафиксируйте, что документы относятся к предлагаемой конфигурации и предоставляются на русском или с переводом.

Нужный минимум: паспорт изделия или формуляр (модель, серийный номер, комплектность), спецификация поставки (в том числе наличие TPM и поддержка Secure Boot как функции платформы), руководство пользователя или краткая инструкция по UEFI/BIOS (как проверить TPM/Secure Boot, как назначить пароли), письмо о соответствии заявленным функциям с указанием модели.

Если поставщик также выполняет интеграцию и поддержку, полезно запросить описание типового профиля настроек безопасности, который применят при подготовке партии.

Что проверить на одном-двух образцах

Приемку удобно описывать как визуальную и функциональную проверку в UEFI/BIOS и в ОС, без спецоборудования. В ТЗ можно указать выборку, например 1-2 устройства на модель из партии.

Проверяйте то, что можно однозначно увидеть:

• TPM: наличие и состояние «включен/готов к использованию» без требований к производителю чипа.
• Secure Boot: поддержка, возможность включения, а при преднастройке - включенное состояние.
• Защита настроек: админ-пароль UEFI/BIOS и невозможность менять критичные параметры без него.
• Доступ к загрузке: запрет или управление загрузкой с внешних носителей (если это требуется вашей политике).

Как описать единообразие настроек в партии

Нейтральная формулировка: «Все устройства в партии поставляются с единым профилем настроек безопасности, согласованным с заказчиком, с возможностью подтверждения параметров на выборочной проверке». Это дает повторяемый результат без привязки к конкретным моделям.

Когда уместна демонстрация или пилот

Если это первая закупка у нового поставщика или требования критичны (госорган, банк, медицина), добавьте пункт: «По запросу заказчика поставщик предоставляет демонстрационный образец или пилотную поставку для проверки настроек TPM, Secure Boot и управления доступом к UEFI/BIOS до поставки основной партии».

Типичные ошибки в требованиях про TPM, Secure Boot и пароли

Проблема таких требований обычно не в количестве, а в том, что их трудно выполнить или проверить. В итоге выигрывает тот, кто «согласен на словах», а на приемке начинаются споры.

Первая ошибка - излишняя конкретика: «TPM только такого-то производителя, чип такой-то ревизии». Это почти никогда не усиливает защиту, но привязывает закупку к одному варианту.

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

Третья ошибка - требования, которые нельзя принять. Если не указан способ проверки, приемка превращается в переписку. Для TPM, Secure Boot и паролей почти всегда можно описать проверку через UEFI и штатные средства ОС.

Отдельная боль - конфликт с эксплуатацией. Запреты вида «запретить любые изменения в BIOS/UEFI навсегда» ломают обслуживание: обновления прошивок, замену накопителей, восстановление после отказов. Нужен баланс: кто имеет доступ, как фиксируются изменения, как сбрасываются пароли по регламенту.

Проверяйте каждое требование по трем вопросам:

• Что именно должно быть включено или запрещено?
• Как это проверить на приемке?
• Как это будет жить в эксплуатации?

Пример сценария закупки и набор формулировок для ТЗ

Школа или поликлиника закупает партию ПК для общих рабочих мест: один кабинет, несколько смен, разные сотрудники. Типовой риск простой: кто-то меняет загрузку, приносит флешку, отключает защиту или оставляет «общий» админ-пароль.

Ниже - набор требований, который закрывает базовые риски и не привязывает к брендам и моделям.

Набор формулировок (5-7 требований)

• ПК поддерживает TPM 2.0, доступный для включения в UEFI/BIOS и распознаваемый операционной системой.
• Поддерживается Secure Boot в режиме UEFI с возможностью включения. Поставка выполняется с включенной проверкой подписи загрузчика, если это не противоречит выбранной ОС и корпоративному образу.
• Доступна установка пароля администратора UEFI/BIOS и отдельного контроля изменений параметров загрузки. Без админ-пароля изменение порядка загрузки и отключение Secure Boot недоступны.
• Поддерживается запрет загрузки с внешних носителей (USB, оптические приводы) или управление приоритетом загрузки с них на уровне UEFI/BIOS.
• Сброс конфигурации UEFI/BIOS возможен только при физическом доступе к устройству, без удаленного обхода паролей.
• Поставщик не изменяет и не устанавливает сторонние ключи Secure Boot без согласования с заказчиком.
• В комплекте поставки есть инструкции производителя (или официальные руководства) по включению TPM, Secure Boot и управлению паролями UEFI/BIOS.

Как описать приемку и проверку партии

Чтобы требования были проверяемыми, опишите приемку так, чтобы хватило одной единицы и выборки:

• Приемка 1 единицы: на одном ПК заказчик проверяет наличие TPM 2.0 в ОС, состояние Secure Boot, попытку изменить порядок загрузки без пароля (должно быть запрещено) и факт установки админ-пароля.
• Выборочная проверка партии: не менее 10% устройств (но не менее 2 шт.) проверяются по тем же пунктам. При несоответствии хотя бы одного устройства проводится расширенная проверка по согласованному правилу.

Передача админ-доступов и поддержка

Зафиксируйте порядок так, чтобы у заказчика был контроль, но обслуживание не оказалось заблокировано:

• На этапе ввода в эксплуатацию админ-пароль UEFI/BIOS задает представитель заказчика (в присутствии поставщика) или пароль передается заказчику по регламентированному каналу.
• Поставщик не хранит админ-пароли после сдачи работ, если иное не согласовано регламентом заказчика.

Быстрые проверки и следующие шаги перед закупкой

Перед публикацией ТЗ сделайте короткую самопроверку:

• Вы описали цель, а не бренд или модель: «наличие TPM 2.0 и проверяемый статус» вместо «TPM такого-то производителя».
• Каждое требование проверяется на приемке: экран UEFI/BIOS, штатные средства ОС, отчет инвентаризации или акт настроек.
• Разделены «наличие функции» и «состояние настройки».
• Управление доступом описано простыми словами: кто меняет настройки, как защищен вход, что делать при сбросе.
• Спорные пункты вынесены в приложение: таблица «требование - проверка - подтверждение».

Минимальный набор для типового офиса обычно включает TPM 2.0, включенный Secure Boot, пароль администратора UEFI/BIOS и запрет загрузки с внешних носителей без разрешения. Для повышенных требований чаще добавляют контроль обновлений прошивок, фиксацию изменений и более строгие правила сброса.

Если вы закупаете ПК у локального производителя или через интегратора и хотите, чтобы партия пришла в одинаковом состоянии, заранее согласуйте «профиль безопасности поставки» (что включено, какие параметры фиксируются, как проходит проверка). На практике это удобно обсуждать с поставщиком, который отвечает и за железо, и за внедрение. Например, GSE.kz как производитель и системный интегратор в Казахстане обычно может согласовать проверяемые формулировки под приемку и подготовить единый профиль настроек для партии на сериях L200 или M200.