Удаленка на «МАРШ!е». Решение ОКБ САПР

Хотя все нормальные люди уже осознали, что жить в физическом мире гораздо интереснее, чем в виртуальном, и поняли, что труд на своем рабочем месте многократно эффективнее, чем на удаленке, все же бывают случаи, когда выбирать не приходится (каламбур какой-то неожиданно получился).

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

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

Опишем, как может выглядеть доверенный сеанс связи, организованный с помощью средства обеспечения доверенного сеанса связи «МАРШ!».

«МАРШ!» – это загрузочное устройство, на котором хранится доверенная вычислительная среда, из которой пользователь должен подключаться к ресурсам информационной системы. При начале доверенного сеанса связи пользователь загружается с «МАРШ!а», обеспечивая тем самым доверенную среду. Далее стартует терминальный клиент (или виртуальный клиент, или браузер – смотря как именно организована удаленная работа в ИС) и начинается сессия.

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

После загрузки ОС с «МАРШ!а» на произвольный домашний компьютер сотрудника и старта браузера устанавливается доверенный сеанс связи с VPN-шлюзом центральной ИС, закрытые ключи и сертификаты для которого хранятся в защищённой памяти «МАРШ!», и доступ к ним возможен только из ОС «МАРШ!а», поэтому подключиться к ИС со своего компьютера, загруженного не с «МАРШ!а», а с жесткого диска, и использовать ключи VPN, хранящиеся на «МАРШ!е», пользователь не сможет.

В случае, если работать планируется в режиме web-доступа, через браузер, МЭ из состава ПО в загружаемой ОС позволит задать единственно возможный адрес соединения, чтобы пользователь по ошибке не зашел в рамках доверенного сеанса связи на какой-то небезопасный ресурс. Плюс решения еще и в том, что пользователю не придется вообще никак изменять привычный уклад жизни – отключил «МАРШ!», перезагрузился – и используешь домашний компьютер по его прямому назначению.

Условиями организации доверенного сеанса можно считать следующие:

• состояние критичных компонентов зафиксировано,
• вирусы блокированы,
• ключи неизвлекаемые,
• перехват управления невозможен,
• управление отчуждено от клиента.

Рассмотрим некоторые особенности реализации носителя для организации доверенного сеанса. Поставим перед собой всего один вопрос – может ли носитель доверенной среды и СКЗИ быть обычной флешкой, токеном или оптическим диском.

На носителе должна быть записана ОС с необходимым для удаленной работы программным обеспечением, а именно:

• браузер,
• СКЗИ,
• МЭ,
• VPN,
• средство подключения к системе (терминальный клиент RDP, ICA,
• клиент PCoIP, Horizon View Client или другие),
• драйвера подключаемый устройств (при необходимости).

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

Организовывать удаленный сеанс связи с использованием флешек нецелесообразно.

А можно ли вообще удаленный сеанс сделать безопасным?

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

При этом к средству организации доверенного сеанса (СОДС) можно предъявить требования:

• ОС хранится в разделе памяти с доступом RO – это обеспечит невозможность ее изменения ни пользователем, ни вирусами или хакерами;
• журналы ведутся в разделе памяти с доступом Add Only – то есть могут добавляться, но не редактироваться и не удаляться (после окончания периода удаленной работы можно будет увидеть журналы точно за весь период);
• место для ключей – раздел с доступом RW Hidden – с тем чтобы при подключении устройства к уже загруженному недоверенной (то есть опасной) средой компьютеру, было невозможно получить доступ к ключам VPN и подключиться к ресурсам системы из незащищенной среды.

Известные зарубежные (да и отечественные) устройства памяти не обладают такими развитыми возможностями управления памятью. Ими обладает только контроллер СОДС «МАРШ!». Именно поэтому мы и предлагаем использовать действительно безопасное решение на этой платформе.

Залог безопасности удаленной работы – это «обнуление» среды при разрыве сеанса, возвращение ее в исходное состояние. Именно это не дает возможности злоумышленнику накопить результаты воздействий на среду, подготовить условия для проведения атаки. В случае с СОДС это обеспечивается тем, что доверенная среда взаимодействия загружается из раздела памяти ReadOnly.

«Подготовка» хакером компьютера пользователя для осуществления атаки на «МАРШ!» – бесполезна, с «МАРШ!а» загрузится его собственная ОС. Даже если атака состоялась, например, в доверенную среду попал вирус или была осуществлена попытка «инъекции кода», то после отключения «МАРШ!» от компьютера среда вернется в исходное состояние, так как вирус не сможет записаться в память RO. А вот с флешкой эта атака завершится успешно – флешка, в строгом соответствии с принципами фон-Неймана, перезапишет доверенную ОС той, что была модифицирована злоумышленником, и с этого момента пользователь будет работать во вредоносной среде, думая, что он в безопасности.

Поэтому использовать загрузочные флешки в качестве средства обеспечения доверенной среды – нельзя.

Однако фиксированность среды – это еще не все. После того как мы обнародовали концепцию доверенного сеанса, стали популярны предложения решений, в которых фиксация среды обеспечивается загрузкой ОС и исполняемой задачи с носителя, на котором неизменность записанных программ обеспечивается технологически (CD-диски, специальные загрузочные флешки, работающие в режиме ReadOnly). Это отчасти надежные и дешевые решения, но совершенно неудобные и некомплексные. Для каждого компьютера такой носитель нужно изготавливать отдельно, ведь его невозможно настроить, во всяком случае, невозможно сохранить настройки, а каждый раз производить настройки заново удаленному сотруднику никто не будет – нет у него дома системного администратора. А ведь еще отдельно нужно хранить ключи подписи и другую важную информацию.

Использовать оптический диски в качестве носителей ПО доверенного сеанса связи неудобно и нецелесообразно. «МАРШ!» лишен этих недостатков.

Управление памятью является совершенно принципиальным свойством с точки зрения ключевых (во всех смыслах) возможностей устройства. На перемещении акцента с этого важнейшего аспекта построены попытки использования вместо СОДС так называемых «аналогов», представляющих собой «токен с памятью». Идея совмещения флешки и токена, исключающая, казалось бы, самое главное ограничение фиксации среды – невозможность корректной работы с ключами, стала естественным продолжением идеи «удешевления» СОДС путем использования CD-дисков или загрузочных RO-флешек.

Рассмотрим «МАРШ!» в сравнении с получившими сегодня некоторое распространение устройствами, совмещающими в едином конструктиве токен и флешку.

Рис. 1. Архитектура аппаратных средств
(ДСЧ – датчик случайных чисел, ПК – память кода, МК – микроконтроллер, М – память; hub –USB-хаб, Т – токен)

На рис. 1 затенена зона компьютера, а красной линией показано движение критичных для безопасности данных. Видно, что во втором случае критичные данные проходят через память компьютера. Это не опасно, если среда доверенная, но доверенной ее можно считать в том случае, если контрольные процедуры выполнены ДО ЗАГРУЗКИ, и это возможно для архитектуры, показанной в левой части рисунка, и невозможно для альтернативной архитектуры. Объясним, почему.

«Токен с флешкой» – это два разных устройства, объединенных hub’ом в единый конструктив. Значит, данные между ними передаются через ПК, прямой связи между ними нет, они передаются наружу, и оттуда – внутрь. В этом, казалось бы, нет ничего плохого, потому что с флешки, входящей в состав устройства, загружается фиксированная среда, которую признаем доверенной, стало быть, совершенно допустимо и нормально получить ключи из токена через посредство этой самой доверенной среды.

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

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

Доверенный сеанс связи может быть организован с соблюдением требований безопасности только на специализированной платформе «МАРШ!».

Стандартные АРМ на этой базе ориентированы на использование наиболее популярных СКЗИ и средств взаимодействия.

По заказу могут быть подготовлены АРМ с любым составом резидентного ПО.