Многофакторная аутентификация: чем контейнеры Linux лучше контейнеров Windows?

Аватар пользователя Pavel Virtuozzo
Автор: Емельянов Павел, Virtuozzo
(0)
()
Опубликовано в:

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

Криптографические токены

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

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

Linux и Windows

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

И здесь еще раз становится очевидным преимущество контейнеров на базе Linux. Дело в том, что дистрибутивы Linux уже содержат стандартный механизм многофакторной аутентификации: pam_pkcs11. Этот модуль использует криптографические токены для выполнения аутентификации на локальном хосте, а стандартный клиент openssh поддерживает возможность использования закрытого ключа, хранящегося на токене. Но что более важно в данной ситуации, клиент стандартного протокола Spice поддерживает «проброс» USB-устройств на сервер, где последний передается контейнеру или виртуальной машине. Таким образом, в Linux многофакторная аутентификация доступна "из коробки" для всех способов входа: локального или удаленного, через командную строку или через графический интерфейс.

Впрочем, под Windows эта проблема тоже решаема при помощи вполне стандартного дополнительного ПО. На данный момент все современные протоколы терминального доступа (RemoteFX, Citrix ICA и т.д.) поддерживают «проброс» USB-устройств с клиента на сервер. При такой структуре последний считает, что токен подключен к нему напрямую и взаимодействует с ним, как и с обычным локальным устройством, а это позволяет эффективно вести авторизацию в контейнерах Windows, работающих на данном сервере.

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

План Б

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

 

 

 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.