В современных информационных системах уже нет того прочного периметра, который бы ограждал корпоративную инфраструктуру от атак из Интернета. О размывании периметра сегодня говорят практически все, кроме компаний, выпускающих традиционные средства защиты данных. Тем не менее до сих пор нет ясности в том, как же в отсутствие периметра организована безопасность информационных активов предприятий и почему он вообще перестал существовать. В первую очередь — из-за консолидации вычислительных ресурсов и появления облаков: устройства сотрудников оказались за пределами периметра корпоративной информационной системы, сконцентрировавшейся теперь в стойках хорошо защищенного ЦОД. Однако вряд ли корректно считать периметром шлюз на входе в ЦОД (см. рисунок) — на персональных устройствах пользователей собирается значительная часть корпоративной информации, которую также нужно защищать. Для этого предлагается использовать антивирусное программное обеспечение, контролируемое из корпоративного центра, что инициировало появление класса продуктов обеспечения шифрованной связи между персональными устройствами и шлюзом — персональные VPN-решения. Кроме того, появились технологии распределенных вычислений, которые предполагают наличие нескольких ЦОД, объединенных зашифрованными каналами связи. В таких системах (облаках) организовано перераспределение вычислительных ресурсов и единого периметра нет, а есть несколько точек входа, защищенных шлюзами.

Типичная схема защиты информационной системы
Типичная схема защиты информационной системы

 

Одновременно с перестройкой архитектуры корпоративной сети появились мобильные устройства, которые сами информации практически не сохраняют, но как минимум обладают идентификационными данными для доступа к корпоративной системе. Для таких устройств были выпущены системы класса MDM [1], а традиционный периметр превратился в шлюзовую защиту облака, совмещенную с корпоративной VPN-сетью персональных компьютеров и MDM-решением для мобильных устройств. Такая система безопасности имеет уже другую конфигурацию, работа которой регламентируется иными правилами доступа к ресурсам корпоративного ЦОД.

Сдвиг парадигмы

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

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

По приложениям. Наиболее популярный метод адаптивной безопасности как раз и заключается в разделении ресурсов по приложениям — уровни доступа определяются в зависимости от того, к каким ресурсам хочет обратиться пользователь. Например, к корпоративному порталу вполне можно подключиться с помощью пароля по каналу SSL, а доступ к внутренним корпоративным ресурсам можно разрешать только компьютерам с сертифицированными компанией средствами защиты при условии применения одноразовых паролей. А если пользователь дополнительно запросил права администратора, то тогда без специального устройства и, возможно, биометрической аутентификации уже не обойтись. Подобные правила разделения предлагают сегодня производители, взявшие на вооружение концепцию адаптивной безопасности: RSA, Microsoft, Cisco и др. Такие средства достаточно просты в применении, однако настроить их сложно — в частности, проблемы возникают из-за того, что в одном приложении может обрабатываться информация разных уровней конфиденциальности: от личной переписки до корпоративных секретов. Например, по почте может передаваться договор с данными о компании, а корпоративный телефонный справочник, который хранится в более секретной системе CRM, может потребоваться на чтение и с не сильно защищенного устройства. Таким образом, разделение прав доступа по приложениям — это достаточно грубый метод, который уже не соответствует современным требованиям к организации доступа.

По ролям и привилегиям. Аналитики Gartner предложили концепцию межсетевых экранов нового поколения Next Generation Firewall [2], в которой предполагается, что шлюзовые решения организуют доступ к корпоративным ресурсам в зависимости от исполняемой роли пользователя. В этом случае получается более гранулярная настройка правил доступа, поскольку в современных корпоративных решениях уже предусмотрены механизмы управления доступом на уровне ролей и имеется возможность предоставлять доступ к приложениям по правилам, определенным для роли. Если у пользователя возникает потребность в получении более сильных полномочий, он должен аутентифицировать себя как представителя другой роли. В крупных системах и быстро меняющихся компаниях сложно предусмотреть универсальные роли и часто возникает потребность в определении для конкретных сотрудников дополнительных временных или постоянных прав доступа. Для этого хорошо подходит механизм привилегий, который дается не на штатную единицу, а на конкретного пользователя для совершения конкретных действий. О разработке продуктов, соответствующих концепции NGFW, заявили основные производители межсетевых экранов: Check Point, Cisco, StoneSoft/McAfee и др. Однако из концепции видно, что нужно не просто контролировать доступ по ролевым правилам, а интегрировать эти правила с прикладными системами, чтобы шлюз умел прозрачно передавать данные о роли и уровне доступа в корпоративное решение, не требуя от пользователя прохождения дополнительной процедуры аутентификации. Однако часто пользователю приходится аутентифицироваться несколько раз — сначала на шлюзе, а потом в приложении для доступа к полномочиям конкретной роли. Правда, при этом приложение теряет часть данных о репутации устройства, с которого пользователь подключается к системе, и не в состоянии определить, насколько можно доверять пройденной на шлюзе процедуре аутентификации. В то же время интегрировать права доступа к приложениям и роли в них можно с помощью решений для управления учетными записями IDM, таких как Oracle IDM, IBM Tivoli Identity Manager, «Аванпост», «Куб» компании Trustwerse и Jet inView Identity Manager. Они, как правило, имеют ролевую модель управления правами доступа, интегрируемую с приложениями, а также предусматривающую различные способы аутентификации, которые можно выполнять на шлюзе. При этом они вполне могут учитывать и репутацию устройств, и сетевое окружение, откуда пользователь пытается получить доступ. В результате можно организовать достаточно гибкое управление правами доступа уже не на уровне отдельных приложений, но по ролям и привилегиям. Однако в некоторых случаях даже и для такой гранулярности правил доступа может возникнуть проблема. Например, в банковской сфере троянец, работающий на устройстве пользователя, может подменить реквизиты транзакции и совершить несанкционированное действие, хотя все процедуры аутентификации пользователь проходит честно.

По операциям. Для отраслей с очень ответственными операциями (финансовая сфера и биржевая торговля) возникает потребность в аутентификации пользователей для выполнения не только функций в соответствии с определенной ролью, но и отдельных наиболее ценных операций. При этом в банках для подтверждения крупных транзакций операторы уточняют у клиента его намерение провести операцию. В этом случае приходится предусматривать еще более гибкий механизм обеспечения безопасности на уровне отдельных операций, позволяющий выявлять подобные ответственные операции для их блокировки или запуска дополнительной процедуры аутентификации. Причем такие процедуры должны быть, как правило, уже юридически значимы, чтобы в дальнейшем можно было доказать факт проведения операции в суде. Сам же механизм выявления подобных ответственных операций, скорее всего, должен представлять собой систему защиты от мошенничества, собирающую сведения об устройствах, пользователях, их операциях и определяющую вероятность мошенничества в той или иной конкретной ситуации. Для выявления критических операций традиционно используется метод определения шаблона мошенничества. Решений для автоматизации этого процесса достаточно много — от отраслевых антифрод-систем до универсальных продуктов для обработки событий безопасности SIEM [3]. Есть также и сервисы, которые предоставляют сведения о шаблонах мошенничества, например в банковской сфере. Такой сервис, в частности, предоставляет компания Experian.

Последствия

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

***

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

Литература

  1. Михаил Савушкин. MDM на страже безопасности // Открытые системы.СУБД. — 2012. — № 3. — С. 20–21.  URL:http://www.osp.ru/os/2012/03/13015151 (дата обращения: 18.04.2014). 
  2. Леонид Черняк. Битва за информацию // Открытые системы.СУБД. — 2012. — № 8. — С.44–47. URL:http://www.osp.ru/os/2012/08/13019240 (дата обращения: 18.04.2014).
  3. Валерий Коржов. Хранители облаков // Открытые системы.СУБД. — 2013. — № 1. — С.34–35. URL: http://www.osp.ru/os/2013/01/13033983 (дата обращения: 18.04.2014).

Валерий Коржов (osmag@osp.ru) — обозреватель, Computerworld Россия (Москва).