Построение инфраструктуры безопасности при миграции с MS Windows на ОС Linux

«Механик заводит машину. Хирург открывает капот и говорит механику: «Вот видишь, двигатель работает, поменяй!»

Введение

Задача миграции с одной операционной системы на другую, на первый взгляд, кажется понятной. Удаляем Windows, устанавливаем понравившийся отечественный дистрибутив на базе Linux, ставим офисный пакет, почтовый клиент, выбираем браузер и антивирус (кому нужно), настраиваем средство электронной подписи (ЭП), подключаем принтеры – всё, задача решена. Отчитываемся об успешном импортозамещении, получаем благодарность от руководства и уважение коллег.

Именно такой подход мы видели все прошлые годы. Это сугубо лоскутное замещение, которого абсолютно недостаточно, чтобы говорить о технологической независимости, устойчивости и достижении итоговой цели – кибербезопасности. Как можно рассуждать о независимости, если у нас около 90% информационных систем (ИС) построены на базе Windows Server Active Directorу (AD) и глубоко интегрированного с ними центра сертификации Microsoft Certificate Services? Кто может быть уверен в том, что эти сервисы просто не остановятся по внешним командам? Многие отвечают, что «выключим обновления, спрячем за firewall». Нет, это не работает, уже есть прецеденты с отключением оплаченных западных продуктов. А ведь на серверной стороне сосредоточены все информационные активы организации – от списка объектов самой ИС (учетных данных пользователей, компьютеров, серверов, сервисов) до критических для функционирования данных, сосредоточенных в СУБД бизнес-приложений.

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

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

Последний раздел (3) посвящен уже обзору самой задачи и методов ее реализации.

Раздел 1. Обзор способов аутентификации

Если говорить о домене безопасности как о цельной структуре с единой политикой безопасности, то стоит упомянуть про стандарт де-факто для организации пространства доверия и применения встроенных механизмов и протоколов, единых для всех компонентов домена безопасности, — это, конечно же, протокол аутентификации Kerberos и реализация технологии единого входа (Single Sign-On, SSO). SSO – это метод аутентификации, который позволяет пользователям, приложениям и сервисам безопасно аутентифицировать друг друга при взаимодействии внутри домена безопасности. Он применим в различных вариантах, например «один к одному» или «один ко многим», то есть в нескольких приложениях и сайтах сразу, используя один набор учетных данных. Также немаловажно понимание технологий аутентификации, применяемых в связке с Kerberos.

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

Итак, всего 7 минут. А ведь именно такие требования стандартно применяются администраторами для парольной политики в домене. При этом смена пароля обычно регламентируется раз в 42 дня. Кто-то еще добавляет спецсимволы. Всё это существенно увеличивает время аутентификации вплоть до 39 минут. Однако при смене пароля раз в ~40 дней это роли не играет, но сильно раздражает пользователей – им приходится помнить сложные пароли.

Вы возразите, что у вас в организации используются сильные хэши и достать их так просто не получится, плюс блокировка при вводе неверного пароля и т. д. Но задумайтесь вот над чем: чтобы пользователю запомнить пароль с большой энтропией от доменного ПК, он обычно или его куда-то записывает, или использует, чтобы не забыть, еще и при заказах в интернет-магазинах. Какая там защита? Верно, никто не знает, и обычно она там почти отсутствует. https://haveibeenpwned.com/ – полезный сервис, который позволяет посмотреть, не хакнули ли еще ваши логин/пароль и нет ли их в базах даркнета. Если ваш пароль уже утек, то табличка будет выглядеть вот так:

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

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

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

Одноразовые пароли (One Time Password, OTP) – это технология, позволяющая обеспечить защиту доступа по периметру сети и домена безопасности, ее удобно использовать на мобильных устройствах, как правило, нет проблем с логистикой. ОТР обычно применяются совместно со связкой логин/пароль, но срок действия ОТР – только один-единственный раз, поэтому взламывать значение ОТР бессмысленно. У ОТР есть несколько минусов. Во-первых, это более низкий уровень безопасности, требующий как повышенной защиты первого шага при инициализации генератора ОТР, так и защиты секрета на серверной стороне. Во-вторых, это по большей части периметровая защита на границе сети. Например, доступ к порталам из внешней сети или же аутентификация в VPN-сессиях, как правило, работает через протокол RADIUS. Это очень популярная технология для B2B- или В2С-сервисов, а также для организации доступа пользователей к опубликованным в Интернете корпоративным сервисам.

Если говорить про цифровые сертификаты, то эта технология на текущий момент обеспечивает максимальный уровень безопасности при доступе к различным информационным системам, а также позволяет закрыть как периметровые, так и внутренние задачи аутентификации с реализацией SSO. То есть она поддерживается как при аутентификации вне сети в различных веб-приложениях, VPN-шлюзах, VDI-решениях, так и внутри домена в рамках Kerberos-аутентификации. Единственная особенность – наличие аппаратной части, что требует решения логистических вопросов.

Раздел 2. Выбор средств аутентификации

Если ваш выбор – использование ОТР, то популярным инфраструктурным решением от «Аладдин Р.Д.» является автономный высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS). Это наш лидер продаж, так как позволяет быстро заместить западные ОТР-решения. Решение поддерживает генерацию ОТР-значения с помощью приложения на смартфоне, передачи через СМС или Push, а также поддерживает все известные «железные» токены-брелоки с кнопкой или экраном для генерации OTP по стандартам RFC 4226 (HOTP) и RFC 6238 (TOTP), в том числе наш собственный токен JaCarta WebPass. Основные отличия от западных конкурентов – простота внедрения, поддержка самых распространенных прикладных сервисов, удобный и понятный «личный кабинет» для пользователя, универсальное мобильное приложение Aladdin 2FA. Также несомненно большим плюсом является наличие у JAS сертификата ФСТЭК России, соответствующего уже новым требованиям на УД-4. JAS обеспечивает безопасные механизмы передачи секрета для инициализации генератора ОТР в приложении Aladdin 2FA, при этом позволяет работать и с любыми другими приложениями типа Google Authenticator, «Яндекс. Ключ» в стандартном режиме. Сейчас многие, кто использовал для таких целей импортные решения, уже столкнулись с проблемами блокирования этих сервисов.

Читайте также

Импортозамещение в облаках: российский рынок после ухода западных провайдеров

Еще совсем недавно от западных облачных сервисов зависело 30% крупных российских компаний. Их отключение, порой внезапное, должно было поставить рынок перед сложными вызовами. Но оказалось, что российские облака готовы предложить рынку вполне зрелые решения. Это и многое другое обсудили участники круглого стола IT-World «Импортозамещение в облаках».

Построение отечественной инфраструктуры открытых ключей (PKI)

В отличие от домена на базе Microsoft AD DS, в отечественных решениях для построения доменов нет встроенного центра сертификатов, такого как Microsoft CS. Несколько лет назад мы начали работу с производителями отечественных операционных систем и достигли больших успехов в построении комплексной экосистемы. Коллеги фокусировались на замещении каталога пользователей, контроллера домена и СУБД такими решениями, как Samba DC или FreeIPA, СУБД Postgres Pro или Jatoba, а мы сосредоточились на замещении средств аутентификации, инфраструктуры PKI и организации SSO. Эта работа велась на уровне проектирования и разработки решений, то есть так же, как и у Microsoft, мы ставили задачу тесной интеграции служб организации домена и центра сертификации и разработали отечественный корпоративный центр выдачи и обслуживания сертификатов доступа Aladdin Enterprise Certificate Authority (Aladdin eCA), способный заменить импортный Microsoft CS.

Aladdin eCA позволяет «из коробки», без дополнительных настроек, разворачивать домены безопасности и обслуживать цифровыми сертификатами контроллеры доменов, серверы, сетевое и IoT/M2M-оборудование, пользователей, обеспечить непрерывность и связанность сервисов при миграции с Windows на Linux. Решение является корнем доверия, без которого невозможно получить действительно санкционно независимую базовую инфраструктуру ИТ-организации. С учетом глубокой проработки методики миграции Aladdin eCA, интегрируясь с контроллерами доменов как на базе AD, так и на базе Linux, данное решение позволяет одновременно поддерживать работу старой PKI на Microsoft CS и новой на базе Aladdin eCA. Это дает возможность плавно перенести пользователей в новые домены с выпуском новых цифровых сертификатов с отечественного центра сертификации Aladdin eCA и не требует одномоментного выключения старой работающей инфраструктуры.

Но и это не всё. Для корректной работы SSO нами было разработано клиентское ПО Aladdin SecurLogon, которое позволяет добавить недостающие компоненты на клиентские версии любой сертифицированной ОС и автоматически сконфигурировать клиентские АРМ для задач единого входа в различных вариантах построения доменов – как на базе Samba DC, FreeIPA, так и на базе Microsoft AD, если требуется временно сохранить AD. Aladdin SecurLogon также позволяет добавить аутентификацию по цифровым сертификатам в такие распространенные протоколы и сервисы, как SSH, RDP, почтовые клиенты, браузеры, подпись и доступ в СЭД. Для больших инсталляций остро стоит задача автоматической централизованной конфигурации клиентских АРМ, так как привычных групповых политик в Linux пока еще нет. Для этого мы реализовали отдельный мастер групповой настройки, который позволяет легко настроить тысячи АРМ за минуты: установить ПО, сконфигурировать ОС, добавить корневые сертификаты в список доверенных, распространить информацию о CRL, настроить SSH и т. д.

Раздел 3. Процесс миграции

При планировании процесса миграции необходимо:

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

2. Предусмотреть возможность модернизации систем аутентификации предприятия и процессов в соответствии с актуальными угрозами.

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

Компанией «Аладдин Р.Д.» проработаны несколько типовых вариантов миграции доменных сервисов в связке с миграцией PKI. Конечная выбранная методика будет определяться особенностями конкретной информационной системы с учетом многих параметров: текущих версий ПО доменной инфраструктуры, структуры связанных доменов организации, планов по миграции АРМ, планов по миграции сервисов информационной системы, сроков действия сертификатов, выбранных средств по организации новой доменной инфраструктуры и др. Среди типовых рассмотрим три методики.

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

Второй вариант основан на том, что производителями ОС ведутся работы по модернизации Samba DC в части поддержки действующей схемы леса AD. Это самая удобная с точки зрения миграции схема, где новые контроллеры домена на базе Samba DC вводятся в действующий домен AD DS с репликацией пользователей на новые контроллеры. Таким образом, в ИС одновременно присутствуют контроллеры домена (и AD DS, и Samba DC), поддерживающие функционирование как старой PKI на базе Microsoft CS, так и новой, на базе Aladdin eCA. Это позволяет без единовременного перевыпуска всех сертификатов постепенно выводить из эксплуатации сертификаты с истекшим сроком действия, генерируя новые на базе отечественного Aladdin eCA. С учетом того, что домены также реплицируются, получаем бесшовный переход на полностью отечественное ПО.

Третья методика основана на механизме «доверительных отношений» (Active Directory Trust Relationship). Разворачивается новый целевой домен, который интегрируется с Aladdin eCA. Настраиваются доверительные отношения, и далее осуществляется перенос учетных записей пользователей. Возможно проводить эти работы совместно с миграцией ОС на АРМ сотрудников. Это актуально как для Samba DC, так и для каталогов, построенных на базе FreeIPA и ALD PRO. В этом случае реализуется построение новой параллельной инфраструктуры.

*    *    *

Выше описаны только три «книжных» способа, как провести миграцию. Но теория, как обычно, отличается от практики. В зависимости от текущих особенностей архитектуры и/или накопленного ИТ-«наследства» могут применяться другие проектные варианты. «Аладдин Р.Д.» обладает большим опытом командной работы с владельцами ИС и разработчиками операционных систем, что помогает в решении задач миграции любого уровня сложности.