Шифрование дисков на рабочих местах госоргана

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

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

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

Сначала фиксируют данные, контур и угрозу

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

Полное шифрование диска прежде всего снижает риск чтения данных вне штатной загрузки: при краже устройства, снятии накопителя, передаче компьютера в ремонт без подготовки или ошибочном выводе носителя из эксплуатации. Оно не останавливает пользователя, который уже вошел в систему, вредоносную программу в его сеансе, копирование файла в разрешенное облако или съемку экрана. В обосновании эту границу надо написать прямо. Иначе комиссия начнет ожидать от одной меры функций DLP, антивируса и контроля доступа.

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

В постановлении Правительства Республики Казахстан № 832 об Единых требованиях отдельно закреплены учет рабочих станций и носителей с уникальными идентификаторами, правила выноса рабочих станций, защита мобильных пользователей и гарантированное уничтожение информации при повторном использовании или выводе носителей. Там же служебная информация ограниченного доступа привязана к рабочим станциям внутреннего контура без подключения к Интернету. Эти нормы не произносят за заказчика название продукта, зато задают контекст, который должен попасть в модель угроз и техническую документацию.

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

Нормативное требование переводят в проверяемое свойство

Регуляторное основание работает, когда рядом с каждым требованием указаны реализация, доказательство и приемочный тест. Простая формула выглядит так: «пункт документа требует X, средство и процесс обеспечивают Y, комиссия проверяет Z». Эта связка лучше длинного перечня нормативных актов без объяснения.

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

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

Удобная таблица обоснования содержит пять столбцов:

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

Полное шифрование не заменяет защиту файлов

Для типового рабочего места базовым вариантом обычно становится полное шифрование системного и фиксированных томов. Оно прозрачно для приложений и закрывает чтение данных со снятого накопителя. NIST SP 800-111 разделяет полное шифрование диска, шифрование томов и виртуальных дисков, а также шифрование файлов и каталогов. Руководство предлагает выбирать вид защиты по носителю, объему данных, среде и угрозам. Это полезнее спора о продукте до описания задачи.

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

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

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

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

Алгоритм оценивают вместе с режимом и реализацией

В техническом задании указывают разрешенные алгоритмы, режимы, длины ключей и версии средства, но не превращают число 256 в оценку всей защиты. Для шифрования дисков нужен режим, рассчитанный на секторные данные. В распространенных реализациях Windows это XTS-AES с ключами 128 или 256 бит. Режим XTS решает задачу шифрования блоков на накопителе, но сам по себе не дает аутентификацию каждого сектора как сетевой протокол с AEAD. Это нормальная граница конструкции, которую надо учитывать вместе с контролем целостности загрузки и операционной системы.

Microsoft в документации BitLocker указывает XTS-AES 128 как стандартный метод автоматического шифрования устройства. Там же сказано, что после уже выполненного шифрования смена метода требует сначала расшифровать диск, а затем зашифровать его заново. Следствие для проекта простое: политику алгоритма надо применить до массового включения, иначе исправление потребует времени, свободного места, электропитания и нового окна риска.

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

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

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

Предзагрузочная защита определяет реальную границу

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

Microsoft рекомендует сочетать BitLocker с TPM и описывает дополнительный PIN или стартовый ключ как способ остановить обычную загрузку до предъявления еще одного фактора. Без TPM системный диск можно шифровать, но стартовый ключ придется хранить на съемном носителе, а парольный вариант не дает проверки целостности предзагрузки и подвержен перебору. Для государственного органа это не запрет по умолчанию, а основание потребовать отдельное обоснование исключений.

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

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

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

Ключи принадлежат процессу, а не администратору

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

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

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

В доменной среде сведения BitLocker можно автоматически сохранять в Active Directory Domain Services до включения защиты. Документация Microsoft предупреждает, что доступ к паролю восстановления открывает весь том, и рекомендует централизованное хранение отдельно от устройства. AD DS сохраняет историю паролей для объекта компьютера, а старые записи автоматически не исчезают. Значит, техническое задание должно требовать проверку успешного резервирования до активации, ограничение чтения, правила ротации и срок хранения устаревших записей.

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

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

Восстановление проверяют до массового шифрования

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

Минимальный сценарий выглядит так:

1. Оператор находит тестовое устройство по инвентарному идентификатору и сверяет показанный идентификатор восстановления.
2. Служба поддержки идентифицирует заявителя, проверяет его право на устройство и регистрирует причину запроса.
3. Уполномоченный оператор получает нужный секрет, не раскрывая другие записи, и передает его по утвержденному каналу.
4. После входа администратор устраняет причину, меняет скомпрометированный защитник при необходимости и подтверждает новую резервную копию.
5. Проверяющий сопоставляет заявку, запись выдачи и конечный статус защиты, а затем закрывает событие.

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

manage-bde -status C:

Ожидаемый вывод содержит как минимум строки Conversion Status, Percentage Encrypted, Encryption Method, Protection Status, Lock Status и Key Protectors. Для принятого тома комиссия ожидает 100 процентов шифрования, утвержденный метод, состояние Protection On и согласованный набор защитников, например TPM и числовой пароль восстановления. Состояние Waiting for Activation или приостановленная защита не равно защищенному диску, даже если интерфейс показывает, что том зашифрован.

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

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

Пилот выявляет то, чего нет в паспорте продукта

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

В выборку включают каждый аппаратный профиль, редакцию операционной системы, тип накопителя и вариант аутентификации. Проверяют чистую установку, устройство с заполненным диском, обновление операционной системы, обновление UEFI, сон, гибернацию, аварийное выключение, замену системной платы и перенос диска. Отдельно измеряют начальное шифрование на питании и от батареи, потому что клиент может откладывать операцию при активности пользователя или экономии энергии.

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

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

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

Техническое задание описывает результат и границы

Хорошее техническое задание не привязывает закупку к одному интерфейсу, но и не прячется за общими словами. Оно задает область, обязательные функции, совместимость, управление, доказательства и порядок приемки. Участник должен понимать, какой результат поставлять, а комиссия должна суметь отказать результату, который только похож на требуемый.

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

Раздел управления должен требовать централизованную политику, автоматическое резервирование до включения, ролевой доступ, журналирование и отчет об отклонениях. Для изолированного контура прямо запрещают неоговоренную зависимость от Интернета или личной учетной записи пользователя. Для съемных носителей задают отдельные правила либо явный запрет.

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

В приемочные испытания стоит включить не больше, а точнее сформулированные проверки:

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

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

Решение принимают по доказательствам жизненного цикла

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

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

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

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

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