Как защитить интернет-банкинг

[Friend]

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

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

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

Защита динамическими методами

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

К динамическим методам можно отнести одноразовые пароли (OTP, one-time password) и методы, работающие в режиме запрос-ответ (challenge-response). К первым относятся: пароли по SMS, таблица паролей, аппаратные генераторы одноразовых паролей, программные генераторы одноразовых паролей.

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

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

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

Алгоритмы генерации паролей

Аппаратные генераторы одноразовых паролей, в отличие от скретч-карт имеют значительно больший период использования (до 8 лет) и кроме того, могут быть защищены PIN-кодом (проверяемым самим устройством), что образует дополнительный уровень защиты.

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

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

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

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

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

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

Усиление системы аутентификации может быть выполнено с использованием методов, реализующие систему «запрос-ответ». Простейший вариант сводится к следующему: сервер генерирует запрос, пользователь вводит его в устройство, которое выдает ответ. Ответ формируется по алгоритму с использованием общего секрета, известного серверу и пользователю (устройству). Простейший и наиболее распространенный вариант — алгоритм HMAC , как одна из реализаций MAC (message authentication code)

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

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

К аппаратным генераторам можно отнести и чипованные банковские EMV-карты, реализующие технологию CAP (chip authentication program, MasterCard) или DPA (Dynamic Passcode Authentification, Visa). С помощью простого в использовании устройства, не подключаемого к компьютеру, можно сгенерировать одноразовый пароль для аутентификации пользователя (алгоритмы основаны только на счетчике событий). Стоит отметить, что системы EMV-аутентификации взаимодействуют с процессингом, поэтому они должны быть сертифицированы самой платежной системой MasterCard или EMV.

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

Авторизация транзакций

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

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

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

Подпись транзакций с использованием PKI, то есть формирование электронно-цифровой подписи в классическом понимании этого слова — наиболее надежное решение с точки зрения используемых алгоритмов. Опасность здесь заключается в том, что в большинстве случаев пользователь не контролирует, какие и сколько именно данных подписываются. . В ходе проведения целевых атак происходит инфицирование пользовательских компонентов системы, в результате чего прокси-элемент, во-первых, может менять параметры транзакций, а во-вторых, выполнять дополнительные транзакции. В ряде случае риски угроз второго типа можно минимизировать за счет полного отключения кеширования PIN-кода. Однако в этом случае каждая операция с ключевым материалом будет требовать ввода PIN-кода, иногда несколько раз за одну операцию (зависит от реализации носителя и системы). Это в свою очередь внесет путаницу: вроде как транзакция одна, а PIN запрашивается дважды…. или все же прошло две транзакции? В любом случае, уверенности в том, что подписываются правильные параметры нет. Такой метод востребован и применим в корпоративной среде по двум причинам. Во-первых, необходимо соблюсти юридическую значимость подписи, что накладывает жесткие требования на используемые методы и алгоритмы (что не требуется при работе с физическими лицами). Во-вторых, существует штат высококвалифицированных администраторов, призванных решать все возникающие вопросы.

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

Предпочтение метода

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

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

При рассмотрении методов стоит затронуть вопрос, который, как правило, ускользает от внимания: чем обусловлена надежность тех или иных методов? Рассуждения о надежности базируются на нашем текущем представлении и знаниях в области математики, логики и общем технологическом развитии. Наиболее яркий пример: стойкость алгоритмов шифрования. Здесь важную роль играет длина ключа. Сейчас длина ключа в 128 бит не является надежной, а 20 лет назад 56 бит были гарантией надежного сокрытия секретов.

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

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

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

Отдельным пунктом можно выделить функционал управления жизненным циклом аутентификаторов. Вполне понятно, что каждый из них проходит определенные этапы: Генерация (для скретч-карты), загрузка конфигурационного файла (для генераторов); Регистрация не пользователя; Блокировка; Разблокировка; Приостановка; Управление PIN (задание, смена, разблокировка); «Отвязка» от пользователя; Замена.

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

Критерии выбора платформы

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

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

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

В-третьих, возможность добавлять новые методы и типы устройств, предусмотренная на уровне ядра платформы, — важный момент, позволяющий уверенно смотреть в будущее.

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

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

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

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

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

Оценка эффективности защиты

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

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

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

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

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

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

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

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

(с) Андрей Тархов

 

[Friend]

Как защитить удаленный банкинг?

Олег Глебов:

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

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

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

Мобильный банкинг

Хакеров особенно привлекает возможность онлайн-доступа к банковским сервисам с мобильных устройств (смартфонов, КПК, нетбуков). Помимо традиционных способов мошенничества в сотовых сетях (с помощью SMS-ловушек) и в Интернете, сегодня широко распространены атаки на определенные модели устройств, версии операционных систем и программного обеспечения, направленные на манипуляцию данными на стороне клиента. Невозможность использования в мобильных устройствах аппаратных средств, предлагаемых ранее (USB), обусловила большую уязвимость онлайн-услуг. Предоставляя конечным клиентам программные средства защиты (ЭЦП, сертификаты и ключи под управлением middleware), банкам приходится полагаться на добросовестность пользователей, так как у них нет уверенности в том, что ОС устройств не заражены. Это обстоятельство ведет к тому, что злоумышленник может заранее подготовить вирусную или иную атаку и дожидаться лишь момента, когда владелец устройства воспользуется услугами банка.

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

К таким решениям относятся средства аппаратной защиты мобильных формфакторов: Compact Flash, Secure Digital и micro Secure Digital. Эти устройства, отличающиеся безотказностью, высоким быстродействием и длительным сроком службы, могут служить одновременно токеном, мобильным хранилищем данных и средством защиты программных продуктов. Тесная интеграция решений на основе карт SD и microSD с мобильными платформами Windows (а в будущем также Android и Apple iOS) может стать стимулом к применению методов защиты, в которых отдельное ПО хранится на карте памяти. А интеграция в PKI-решения, поддержка сертификатов и цифровых подписей позволит предоставить конечным пользователям значительно более высокий уровень безопасности при работе с веб-клиентом банка.

«Банк-клиент»

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

Аппаратные средства на рынке контроля цифровых прав совмещают в себе классический функционал хранилища сертификатов и ключей (токен) с возможностью защиты программных продуктов на базе комплексного шифрования AES. Поставляя конечному пользователю аппаратный ключ (в формфакторах USB, PCMCIA, CF, SD или microSD) взамен USB-токена, банковская служба безопасности получает на стороне конечного пользователя комплекс, который обеспечит стопроцентную надежность передачи данных и целостность компонентов, поскольку внешнее устройство полностью защищено от нелегального доступа, модификации или подмены данных.

Банкоматы

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

Применение карт промышленного стандарта Compact Flash позволяет защитить ПО банкомата одним устройством. Новые поколения ключей защиты надежно хранят сертификаты, ЭЦП и ключи шифрования, участвуя в процессе защиты передаваемых данных как безопасное внешнее устройство и исполняя роль токена. Установка ОС на дополнительную флэш-память ключа позволяет контролировать отдельные файлы системы и целостное выполнение самой операционной системы непосредственно крипточипом ключа. Расширенный диапазон рабочих температур, средства самодиагностики для увеличения срока службы, высокая скорость чтения и записи (23–24 Mбайт/с) для повышения производительности – эти характеристики решения на основе карт CF обеспечивают уверенность в его безотказности. Работающее в банкомате ПО может быть полностью защищено шифрованием, надежно храниться на флэш-памяти и контролироваться крипточипом (контрольные суммы хранятся локально в устройстве)


Андрей Тархов:

В первую очередь необхо*димо обеспечить доступ к документам, почте и уда*ленному рабочему столу через VPN-соединение, т. е. организовать работу по защищенному зашифрованному каналу связи. VPN*-соединение устанавливается через специализированные программные или аппаратные решения , т. н. VPN-*шлюзы. Программное решение — это программа, которая устанавливается на сервер, должным образом сопрово*ждается и поддерживается.
Аппаратное решение (appliance), ко*торое монтируется в стойку, содержит предустановленное и сконфигурирован*ное программное обеспечение. Размеры аппаратных решений по высоте состав*ляют 1–2 U. Их модификаций масса, но главная особенность в том, что вы получаете готовое преднастроенное, предустановленное оборудование, и все, что с ним нужно сделать, — это провести интеграцию в существующую среду.
На мой взгляд, у аппаратных реше*ний есть несколько значительных пре*имуществ над программными, и здесь в первую очередь стоит говорить о гаран*тийном обслуживании. Гарантия и техни*ческая поддержка носят комплексный ха*рактер и выполняются одной компанией, то же самое происходит и с обновлением систем. При этом системный администра*тор получает «готовое обновление», и ему не надо задумываться о том, будет ли обновленное программное обеспечение совместимо с текущей версией операци*онной системы и не возникнут ли между ними конфликты. Как правило, произ*водители аппаратных решений постав*ляют платформу , которая оптимальным образом подходит для решения постав*ленных задач. Соответственно, заказчик, покупая аппаратное решение , не будет задумываться над тем, что произойдет в случае использования программного решения , какую серверную платформу , какое « железо » необходимо выбрать .

Варианты удаленного доступа

Обычно удаленный пользователь по*лучает доступ к корпоративным инфор*мационным ресурсам с корпоративного ноутбука, когда находится в команди*ровке, или со своего домашнего ком*пьютера. Механизм таков, что в режиме работы VPN-соединения фактически про*исходит объединение двух сетей: поль*зовательской и корпоративной. В рамках формирования этого VPN-соединения можно построить определенное ограни*чение на предоставление доступа к тем или иным ресурсам. При этом не всегда есть уверенность, что рабочее место пользователя защищено, есть ли там антивирусы, локальный файрвол и т. д. На мой взгляд, целесообразно работать не просто в режиме VPN-соединения, то есть по защищенному каналу, но и кон*тролировать информационные потоки, попадающие в «офис», на предмет чи*стоты. Таким образом, устройство, кото*рое по своей сути является VPN-шлюзом, выполняет комплексные функции: межсе*тевое экранирование, антивирус и пр.
На выходе мы получаем комплекс*ное аппаратное решение , которое может осуществить и защищенный удаленный доступ на базе VPN, и вы*полнить функции шлюзового антиви*руса для фильтрации как входящего интернет-трафика, так и всей инфор*мации, которая циркулирует между внутренней сетью и удаленными ком*пьютерами пользователей. Соответ*ственно, речь идет о консолидации всевозможных функций в одно уни*версальное устройство, которое будет предоставлять заказчику практически все существующие на сегодняшний день сервисы безопасности.
Следующий случай, касающийся за*щищенного удаленного доступа, — это объединение по защищенному каналу двух и более офисов. Многие компании сегодня имеют разветвленную инфра*структуру, и практически всегда прак*тикуется централизованный подход использования ресурсов, например, по*чтовый сервер расположен в централь*ном офисе, и пользователи, находящи*еся в региональных, дочерних офисах с меньшим количеством сотрудников, работают фактически в удаленном режиме. Те же задачи, которые были упомянуты ранее, возникают и в слу*чае защиты канала типа «офис-офис». В этом случае мы говорим о построении VPN-соединений не между VPN-шлюзом и компьютером пользователя, а между двумя VPN-шлюзами. Используются раз*ные термины для обозначения соедине*ний таких типов, самое распространен*ное из них — Branch Office VPN.


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

Аутентификация удаленного пользователя

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

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


Отдельно стоит упомянуть комби*нированные технологии. Наиболее ин*тересная реализация — ActivIdentity DisplaySmartCard. Чем она примеча*тельна? По своей сути это комбинация двух устройств. Первое — чипованная смарт-карта, на которой хранится циф*ровой сертификат пользователя. Эта часть является контактной и может ис*пользоваться для PKI-аутентификации, ЭЦП и прочих PKI-задач. Вторая часть, которая является бесконтактной, — это генератор одноразовых паролей. Она более проста в эксплуатации, не требует подключения к компьютеру и использу*ется при получении удаленного доступа, когда пользователь работает, например, со своего компьютера. При этом уста*новки дополнительного программного
обеспечения не требуется. В рамках одного устройства мы можем выполнять не только разные типы аутентификации, но и дополнительные задачи.
Если мы заговорили об аутентифика*ции по одноразовым паролям в контек*сте получения уделенного доступа, то нужно рассмотреть и серверную компо*ненту. Вопрос заключается в интеграции VPN-шлюза и сервера аутентификации. Наиболее очевидный вариант — это ис*пользование стандартных протоколов аутентификации, например, RADIUS.

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

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