Аналитика и комментарии

10 июля 2018

Обеспечение безопасности денежных средств и данных клиентов – неотъемлемая задача для сохранения технологического лидерства компании. Несмотря на это, количество скомпрометированных данных растет из года в год

Финансовая отрасль при этом не становится исключением 24% утечек, (по данным компании Verizon, в 2017 году), и это неудивительно. Как следует из отчета Insider thread report 2016, базы данных – более ценный источник конфиденциальной информации, чем файловые серверы, веб/email-серверы, «оконечные» устройства (персональные компьютеры, мобильные устройства), приложения и облачная инфраструктура вместе взятые. Согласно статистике, более половины баз данных содержат конфиденциальную информацию.
 
Угрозы информационной безопасности
Самыми актуальными угрозами для баз данных являются излишние привилегии пользователей, злоупотребление правами доступа и недостаточный аудит действий пользователей.
Эти угрозы напрямую связаны с увеличением количества инсайдерских атак. Как правило, корпоративная сеть считается защищенной межсетевыми экранами и прочими сетевыми средствами защиты периметра. Однако такой подход к защите не позволяет обнаружить атаки на данные легитимного пользователя-инсайдера, который успешно авторизовался в базе данных.
Согласно статистике в отчете Insider thread report 2016, 74% организаций пострадали от инсайдерских угроз, что привело к возникновению целого ряда как финансовых, так и рисков нарушения конфиденциальности, целостности и доступности обрабатываемой в базах данных информации.
Сбербанк, как крупнейший банк страны, также сталкивается с такими угрозами. Как минимизировать риски от них? Это комплексная задача, включающая постоянный анализ привилегий пользователей баз данных, настройку аудита и мониторинг действий пользователей в базах данных. Анализ привилегий позволяет минимизировать доступ пользователей к базе данных, а аудит и мониторинг – увеличить эффективность расследования инцидентов по фактам мошенничества и предотвратить аналогичные инциденты и реализацию мошеннических схем. 
Рассмотрим подробнее использование решения по аудиту и мониторингу действий пользователей в базах данных на основе опыта Сбербанка. 
На первый взгляд, решение этих задач не представляет большой сложности, так как во всех базах данных есть встроенные функции аудита, также существует аудит на уровне приложения. Ниже указаны проблемы, с которыми столкнулся Сбербанк, и их решение при построении системы аудита действий пользователей.
 
Снижение производительности
Встроенный механизм аудита базы данных существенно влияет на производительность сервера, что вынуждает многие организации минимизировать или полностью отключить аудит. При тестировании аудита DML-операций (действий пользователей по чтению, изменению, удалению данных в таблицах и представлениях) выявлена существенная деградация производительности сервера БД, так как каждая операция на уровне БД выполняется после записи соответствующего события аудита. Принято решение по использованию встроенного аудита только DDL- и DCL-операций (выдача привилегий, изменение структуры данных и т.п.). 
 
Разнородные базы данных
Большинство собственных механизмов аудита уникальны для платформы сервера баз данных. Например, журналы Oracle не такие как MS-SQL, а журналы MS-SQL отличаются от DB2. Для Сбербанка с его гетерогенными средами баз данных это создает существенное препятствие для реализации единых масштабируемых процессов аудита, мониторинга и отчетности.
 
Контроль администраторов
Пользователи, имеющие административный доступ к базе данных, либо законно, либо злонамеренно (чтобы скрыть мошеннические действия) могут отключить встроенный аудит базы данных, поэтому нужна система независимого аудита действий пользователей баз данных.
 
Аудит пассивных операций
Использования прикладного аудита недостаточно для борьбы с инсайдерами. Объекты прикладного аудита – это бизнес-объекты приложения, поэтому такой аудит непригоден в случае изменения 
инсайдером объектов базы данных напрямую. Прикладной аудит также не позволяет отслеживать операции «пассивного» просмотра пользователями конфиденциальной информации в базах данных, а это, по опыту Сбербанка, является одной из основных составляющих в мошеннических операциях. К «пассивным» операциям относится просмотр остатков по счетам VIP-клиентов и организаций, данных по учредителям и тому подобной ценной информации, используемой инсайдерами в дальнейшем для перепродажи или для вступления в сговор с преступными группировками.
 
Необходимость выявления аномалий
Для выявления мошеннических схем требуется корреляция данных встроенного аудита баз данных. К примеру, события аудита, интерпретируемые как разблокировка банковских карт клиентов, осуществление по ним операций, блокировка банковской карты, движение средств с «малоподвижных» счетов, сами по себе не сигнализируют о угрозе кражи денежных средств со счетов клиентов, но если эти события анализировать во времени и с привязкой к другим событиям, то мошенническая схема будет раскрыта. 
 
Выбор системы защиты баз данных
Аудит и мониторинг баз данных в Сбербанке осуществляется с помощью решений класса DAM, Database Activity Monitoring. Для высоконагруженных автоматизированных процессинговых систем, когда недопустимо малейшее влияние на вычислительные ресурсы серверов, используется безагентское решение, основанное на анализе копии трафика с сетевого оборудования. Для остальных систем применяется агентское решение, позволяющее дополнительно отслеживать локальные подключения к базе данных, тем самым регулируя задачу контроля администраторов. Используемые DAM-решения позволяют анализировать все используемые сетевые протоколы СУБД для обмена между клиентами и серверами баз данных, используемые в банке. Для корреляции событий баз данных между собой и с другими источниками используется система SIEM и инструменты поведенческого анализа.  
Подробнее остановимся на аспекте применимости системы аудита к конкретному приложению. При выборе системы DAM важно понимать архитектуру приложения, аудит которой проводится. От этого напрямую зависит результат внедрения систем такого класса. Различают двух- и трехзвенные архитектуры приложения. Давайте рассмотрим, в чем их различие и почему это имеет важное значение при внедрении системы DAM.
Двухзвенные приложения работают по принципу толстого клиента, т.е. соединение с базой данных происходит непосредственно с рабочего места сотрудника с помощью установленного клиента. Каждый сотрудник при этом обладает выделенной учетной записью в базе данных. Такая схема применяется в банке в части legacy-систем, когда бизнес-логика работы приложения находится частично на клиенте и базе данных. У данного подхода множество минусов с точки зрения гибкости разработки, масштабируемости, также есть недостатки, связанные с обеспечением безопасности:
 
1. Требуется создавать пользователю учетную запись для каждого нового приложения, к которому нужен доступ.
2. Необходимо отдельно следить за требованиями к учетным записям в базе данных относительно парольной политики (например, для соответствия требованиям PCI DSS).
Современные приложения, работающие с базами данных, строят свою работу по принципу трехзвенных подключений, где между клиентом (в большинстве случаев используется тонкий клиент в виде веб-браузера) и сервером БД используется дополнительное звено – сервер приложений.
 
С точки зрения безопасности пользовательского доступа есть несомненные плюсы:
1. В данном подходе мы минимизируем количество учетных записей, которые могут осуществить доступ к СУБД.
2. Разграничение прав доступа к данным переносится на уровень приложения, что добавляет гибкости для их настройки. 
При этом, если говорить про мониторинг сетевого доступа к базам данных, основанный на анализе SQL-трафика, возникает одна важная проблема. В случае с двухзвенной архитектурой DAM-система обеспечивает полноценный аудит пользовательских действий с определением всех параметров доступа, в том числе имени пользователя в базе данных, который соответствует конкретному сотруднику банка. При трехзвенной архитектуре приложения все подключения к базе данных совершаются от технологических учетных записей, так как соединение с базой данных устанавливает не клиент, а сервер приложения. По этой причине, анализируя только SQL-трафик к базе данных, возможность определить пользователя, инициировавшего запрос в тонком клиенте, существует далеко не всегда.
 Для решения задачи персонификации действий пользователей в трехзвенных приложениях можно использовать разные подходы, зависящие от логики работы приложения:
1. Выделение информации о конечном пользователе исключительно из SQL-трафика. Такая возможность будет в том случае, когда сервер приложения передаст информацию о конечном пользователе в SQL-трафике. Это может быть передача учетной записи в инициализирующем запросе, в переменных или же возвращение с ответами на запрос. Логика работы большинства используемых в Сбербанке приложений не позволяет использовать данный подход.
2. Корреляция HTTP- и SQL-трафика. Данный способ требует подачи на DAM-систему сегмента HTTP-трафика, из которого выделяется учетная запись пользователя. 
При этом стопроцентный результат при персонификации будет только в случае передачи сервером приложения некоторого уникального идентификатора сессии пользователя в SQL-трафик. Данное решение требует повышенных затрат, так как в разы увеличивается контролируемый трафик.
3. Использование только сегмента HTTP-трафика для задач персонификации и аудита доступа и проведения расследований. Этот подход применяется в Сбербанке для нескольких критичных систем, так как, помимо определения пользователя, он позволяет вести аудит всех ответов на запросы, то есть той информации, которую пользователь получает в веб-браузере.
Сбербанком совместно с сотрудниками компании «Гарда Технологии» проведены работы по доработке DAM-системы «Гарда БД» для анализа HTTP-трафика и решения задачи персонификации событий в нескольких трехзвенных приложениях. «Гарда БД» – полностью отечественное DAM-решение, не уступающее ведущим мировым аналогам, а в части производительности и превосходящее их.  
При первичной авторизации пользователя в системе на сервер приложений передается учетная запись пользователя, где проверяется наличие прав доступа. В случае успеха на клиентское приложение передается присвоенный уникальный SESSION_ID, который потом отправляется внутри cookies при каждом последующем запросе к веб-серверу. DAM-система «Гарда БД» была настроена таким образом, что учетные записи в первую очередь корректно выделяются для каждого события авторизации, а также однозначно «привязываются» ко всем последующим запросам данного пользователя. Также осуществлен парсинг ответов из формата XML в табличный вид для удобства последующей работы внутри системы.
В результате построена система, которая позволяет вести практически полный архив действий сотрудников. При этом не нужно вносить изменения в архитектуру приложения, устанавливать агентские решения на сервера приложений либо же на пользовательские машины, а главное, не оказывать никакого влияния на работу самого приложения. За время эксплуатации системы значительно повышена эффективность проведения расследований по фактам мошенничества с участием персонала банка, а также независимых экспертиз действий ИТ-персонала при возникновении инцидентов в ИТ-инфраструктуре банка.
Таким образом, несмотря на огромное количество обрабатываемой информации в автоматизированных системах Сбербанка, разнородную инфраструктуру с высоконагруженным оборудованием, учитывая большую команду из более чем 260 тыс. сотрудников, задача по аудиту и мониторингу пользователей в базах данных является важной составляющей процесса обеспечения защиты данных в компании. И, что актуально в существующих реалиях, она может быть решена на основе полностью отечественного решения, не уступающего ведущим мировым аналогам.     
текст Владлен Шубин, руководитель направления Центра киберзащиты Сбербанка
Поделиться:
 

Возврат к списку