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

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

Первое, с чем сталкивается пользователь (а значит, и злоумышленник) при доступе к любому сколь-нибудь значимому сервису, — это аутентификация. Именно это действие позволяет определить, что пользователь, обращающийся за информацией или желающий произвести какие-то действия, — тот самый, за которого он себя выдает. Без проверки подлинности пользователя невозможно произвести авторизацию, то есть предоставить определённые права. Если злоумышленник может пройти аутентификацию от лица пользователя, обладающего необходимыми полномочиями в целевой системе, то дальше он получает эти полномочия и его задача с высокой степенью вероятности будет выполнена. Проверка подлинности в информационной системе — как проверка заграничного паспорта на паспортном контроле при пресечении границы. Если человек предъявляет поддельный или чужой заграничный паспорт, то он не должен пройти паспортный контроль. Для того чтобы это обеспечить, производится ряд проверок, направленных на выявление подделок и сверку соответствия владельца заграничного паспорта и его предъявителя. Если бы паспорт представлял собой произвольного вида бумажку без водяных знаков с написанными от руки данными, то подделать такой документ не составило бы труда. Но в действительности заграничный паспорт имеет большое количество степеней защиты и не позволяет подделать его подручными средствами. Так же и с аутентификацией в информационных системах. Учётную запись пользователя, осуществляющего вход по логину и паролю в веб-интерфейс электронной почты без использования протокола HTTPS, несложно скомпрометировать. Если же проверять подлинность пользователя по сертификату, записанному на смарт-карте, — задача существенно усложняется.

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

— корпоративный портал,

— электронная почта,

— CRM-система,

— удаленный VPN-доступ,

— Wi-Fi.

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

Самое неприятное начинается, когда внутри компании решают, что необходимо обеспечить защиту, например, электронной почты. Помимо настройки TLS-шифрования, конечно, вспоминают о двухфакторной аутентификации, или, сокращенно, 2FA. Если почтовый сервер поддерживает 2FA «из коробки», то используют эту возможность. Если же такого функционала нет — компания может решить «допилить» его самостоятельно. Даже не буду углубляться в особенности доморощенных модулей аутентификации. Главное, что теперь у пользователя есть какой-то способ строгой аутентификации при входе в почтовый ящик: аппаратный или программный токен, смарт-карта или что-то еще.

Через какое-то время компания решает, что VPN-доступ по связке логин — пароль небезопасен, так что нужно использовать 2FA и для этой задачи. Но ведь первый токен, выданный пользователю, невозможно применить для чего-то еще, кроме доступа к почте. Так появляется второй токен, а вместе с ним и еще один модуль для двухфакторной аутентификации. Не будем забывать об администраторах, которым теперь нужно управлять всеми этими средствами аутентификации в удвоенном размере.

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

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

Сервер аутентификации — это единый центр администрирования всех процессов проверки подлинности сразу для всех приложений/сервисов/ресурсов. Промышленные такие серверы поддерживают целый набор методов аутентификации. Как правило, это OATH HOTP, TOTP, OCRA, PKI-сертификаты, RADIUS, LDAP, обычный пароль, SMS, CAP/DPA и многие другие. Каждый ресурс, использующий сервер аутентификации, может использовать метод, который требуется именно ему.

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

Теперь добавление второго фактора для проверки подлинности не потребует от компании создания нового «костыля» для приложения и закупки новых токенов. Вообще добавление нового метода аутентификации — стандартная задача для подобных систем. Приведу пример. Банк А проверял подлинность владельцев дебетовых или кредитных карт в клиент-банке по сертификатам на USB-токенах. Его платежные карты были исключительно с магнитной полосой, но в какой-то момент банк наладил выпуск карт с EMV-чипом, который, по сути, является микрокомпьютером. Карту с EMV-чипом можно использовать для аутентификации по алгоритму Master Card Chip Authentication Program (CAP). То есть теперь банк А может отказаться от применения для каждого пользователя дорогостоящих PKI-токенов и сменить этот метод аутентификации на CAP, для которого требуется только недорогой криптокалькулятор. Через некоторое время банк А начинает выпуск платежных карт с дисплеем и реализованным алгоритмом OATH TOTP и для того, чтобы избавить пользователя от использования дополнительного криптокалькулятора, настраивает аутентификацию TOTP для клиент-банка. Следует понимать, что помимо дистанционного банковского обслуживания в банке А есть множество других сервисов, как внутренних, так и предназначенных для клиентов или партнеров, требующих аутентификации. Для каждого приложения служба информационной безопасности может выдвинуть свои требования по необходимым методам проверки подлинности пользователей. Вся аутентификация банка А может производиться на сервере аутентификации. Нет никакой необходимости заниматься разработками для каждого приложения отдельно.

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

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

Некоторые промышленные серверы аутентификации поддерживают использование Hardware Security Module (HSM). Это обеспечивает сохранность всей чувствительной информации путем шифрования. Ключи шифрования при таком подходе хранятся в аппаратном модуле HSM. Их невозможно извлечь, и даже все операции с этими ключами производятся только внутри HSM. Так достигаются высочайший уровень защищенности аутентификационных данных и высокая скорость работы криптографических алгоритмов, выполняемых внутри аппаратных модулей HSM.

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

Автор статьи — инженер по информационной безопасности компании «Пауэр Секьюрити».