Как защититься от действий недобросовестных администраторов? Пожалуй, этот вопрос задавал себе каждый владелец бизнеса. В статье рассматриваются вопросы, связанные с проблемами контроля действий системных администраторов, имеющих практически неограниченный доступ к обслуживаемым системам, а также перспективные подходы к их решению на примере Wallix AdminBastion.
2. Можно ли доверять привилегированным пользователям?
3. Существующие решения для контроля привилегированных пользователей и их проблемы
4. Перспективные решения для контроля привилегированных пользователей
Введение
Многие компании вынуждены открывать доступ к своим корпоративным системам для внешних специалистов. Это относится к всевозможным провайдерам ИТ-услуг и аутсорсерам. Преимущественно это продиктовано желанием сэкономить на вынесении непрофильных функций за пределы штата организации, а также желанием иметь возможность быстрого внедрения новых ИТ-сервисов и их технической поддержки.
Например, к числу типовых функций, который могут отдаваться на откуп внешним ИТ-специалистам, можно отнести:
- поддержку со стороны производителей ПО или программно-аппаратных комплексов;
- техническое обслуживание оборудования сторонними специалистами;
- техническая поддержка со стороны ИТ-интеграторов или поставщиков ИТ-услуг;
- работу консультантов по настройке систем ERP, CRM или специфических бизнес-приложений.
Подобная практика привносит дополнительные риски с точки зрения информационной безопасности. В основном они связаны с фактической потерей контроля над информационной инфраструктурой предприятия, доступом к ней широкого круга лиц, зачастую никак и никем не контролируемого.
Давайте разберемся в этих рисках подробнее.
Можно ли доверять привилегированным пользователям?
Согласно опросу западных аналитических агентств, в 2012 году среди 820 системных администраторов, 42% их них когда-либо использовали свое служебное положение (административный аккаунт) для несанкционированного доступа к конфиденциальным и важным данным своей организации.
При этом 74% системных администраторов признались, что они с легкостью обходят меры безопасности, предпринятые для защиты конфиденциальных данных в организации.
Значительная часть системных администраторов призналась, что, в случае увольнения, охотно прихватят с собой эти самые конфиденциальные данные, – будь то база клиентов, административные аккаунты, планы компании по разработке, слиянию и поглощению и т.п. (см. таблицу 1).
Таблица 1. Какую информацию прихватят системные администраторы в случае увольнения
|
Вид конфиденциальных данных |
2012 |
|
Клиентская база |
8% |
|
Административный аккаунт к почтовому серверу |
4% |
|
Планы по слиянию и поглощению |
4% |
|
Планы по разработке и исследованиям |
5% |
|
Финансовые отчеты компании |
5% |
|
Список паролей привилегированных пользователей |
8% |
|
Другое |
12% |
|
Не возьму ничего |
54% |
Иными словами, риски утечки конфиденциальных данных через системных администраторов в случае их вынужденного увольнения и/или замены составляют чуть менее 50%. При этом указанные риски существенно увеличиваются в периоды неблагоприятной экономической ситуации.
В денежном выражении риски выглядят еще более устрашающе. Так, если компания потеряет даже 10% текущих клиентов из-за утечки базы клиентов, то ущерб может исчисляться сотнями миллионов рублей уже в первый год после утечки данных. Возможный ущерб, который может возникнуть по причине утечки планов разработки или слияний, и вовсе может привести к катастрофическим последствиям вплоть до закрытия бизнеса.
Если речь идет о своих собственном ИТ-персонале, то он «известен нам в лицо», а, значит, к нему, в случае подозрений, можно применить различные меры административного или судебного воздействия. В случае аутсорсеров мы точно не можем контролировать круг лиц, имеющих доступ к нашим конфиденциальным данным и критически важным системам. Права доступа к аккаунтам могут делегироваться внутри аутсорсинговой компании, что очень часто происходит на практике. Поэтому и риски в этом случае заметно выше.
В подобных условиях становится очевидна необходимость внешнего контроля системных администраторов и их действий, независимого от них самих. Далее рассмотрим кратко существующие и перспективные подходы к решению этой проблемы.
Существующие решения для контроля привилегированных пользователей и их проблемы
Доступ к конфиденциальным данным, сам по себе, является предметом жестких политик безопасности. Каждое действие по созданию административного аккаунта, изменению его атрибутов или удалению обычно сопровождается процессуальной и бюрократической волокитой, в которую вовлекаются люди из различных подразделений компании. Тратится немало времени на согласования, учет и контроль выполнения политик по контролю привилегированных пользователей.
На регулярной основе необходимо проверять выполнение принятых политик безопасности правильность выдачи административных прав и контролировать, что действия администраторов не выходят за рамки должностных обязанностей. Для этого должен проводиться внутренний аудит, что выливается в значительные временные и финансовые затраты.
В случае с внешним привилегированным доступом возникает дополнительная проблема создания для них специальных ролей, бизнес-процессов и регулярного мониторинга их действий.
Чаще всего для административного доступа внешних специалистов используются различные средства, такие как IPSEC VPN, SSL VPN или SSH. Чаще всего шлюз устанавливают в DMZ и делают промежуточным звеном между сервис-провайдером и внутренней сетью организации. Такие решения должны иметь функции записи выполняемых действий, необходимые для соответствия стандартам ISO 27001, PCI DSS, Basel II и.т.д., но далеко не все отвечают этим требованиям.
Но, помимо отчетов о подключении внешних привилегированных пользователей, большую озабоченность вызывает необходимость выдачи им реальных административных паролей для целевой системы или даже класса систем (например, аккаунт root для Unix/Linux систем или аккаунт администратора для Windows Server).
Но главной проблемой, с моей точки зрения, является даже не это. Даже если вы правильно настроили отчетность на шлюзе удаленного доступа и отчетность на целевой системе, то невозможно в реальном времени сопоставить одни данные с другими.
Зная данные о том кто, когда и откуда подключился к вашей сети (отчет о соединении) или даже какие команды он выполнял в течение сессии, вы не сможете оперативно посмотреть действия этого человека на целевой системе. К тому же никто не мешает администратору зачистить все следы на целевой системе. И, наоборот, по отчетам целевой системы вы не сможете понять, кто и откуда это делал. Проще говоря, в лучшем случае вы будете иметь на руках несколько типов отчетов, которые придется как-то сопоставлять друг другу.
Если даже вы решили сопоставить данные из нескольких журналов постфактум, то это станет далеко непростой задачей. Время в системах не синхронизировано. При большом потоке данных журналы становятся огромны. Физически работа по анализу логов вручную превращается в ад, и поэтому практически не используется при анализе действий пользователей.
Проблема усугубляется, если мы начинаем рассматривать не внешних администраторов, а внутренних. Внутренние привилегированные пользователи, в большинстве случаев, никак не контролируются. Сложность здесь состоит в том, что они имеют прямой доступ к целевым системам из внутреннего, серверного сегмента, при этом – абсолютно бесконтрольного. В такой ситуации администратор может просто зайти в серверную, напрямую подключиться к серверу, совершить несанкционированные действия и остаться незамеченным для внешних систем контроля. Журналы доступа на самом сервере после всех манипуляций затираются.
Таким образом, нужен какой-то совершенно иной подход к проблеме, универсальный и подходящий для контроля действия любых привилегированных пользователей. Этот новый подход к тому же должен быть недорогим и минимизировать бюрократические процедуры в компании.
Перспективные решения для контроля привилегированных пользователей на примере Wallix AdminBastion
Рынок решений для контроля привилегированных пользователей сейчас активно развивается, о чем я писал в своей предыдущей статье. Существует много решений и подходов к решению этой проблемы, но для примера я остановлюсь на одном из них – Wallix AdminBastion (WAB).
Решение прекрасно дополняет существующие решения SSL VPN или IPSEC VPN, а также может использоваться для замены SSH и RDP шлюзов. Также решение контролирует подключения через TELNET, SFTP, rsh, RLOGIN, а также Windows Terminal Server (RDP) и может использовать для аутентификации сертификат Х509 V3.
Wallix AdminBastion предоставляет информацию о выполняемых внутренними или внешними привилегированными пользователями операциях, как в режиме реального времени, так и ретроспективно. Таким образом, для поиска подозрительных действий не нужно анализировать и сопоставлять отчеты о работе пользователей в различных системах.
Рисунок 1. Схема работы Wallix AdminBastion
При помощи Wallix AdminBastion можно записывать рабочие сеансы привилегированных пользователей и при необходимости просматривать их (аудит, управление инцидентами и т. д.). Решение не делает различий для внешних и внутренних пользователей, имеющих привилегированный доступ. Действия, выполняемые ими на целевых устройствах, непрерывно записываются для последующего просмотра в формате Flash Video (для графических сеансов Windows Terminal Server (RDP) и (VNC)) и в текстовом формате (для сеансов командной строки SSH и Telnet). Примеры записи сеансов можно посмотреть здесь.
Wallix AdminBastion работает как шлюз и не требует установки агентов на администрируемых устройствах или рабочих станциях, что обеспечивает его быстрое развертывание.
Рисунок 2. Пример отчета о действиях администраторов в Wallix AdminBastion
Контроль доступа привилегированных пользователей к корпоративным ресурсам в Wallix AdminBastion осуществляется на основании правил по различным критериям, таких как IP-адрес, имя пользователя, интервал времени, протокол или тип сеанса SSH (X11, Shell, Remote exec, и т.д.). При этом все вводимые команды (Shell, exec, SCP и т.д.) анализируются в реальном времени. При обнаружении запрещенных строк можно отправить предупреждение или прервать подключение SSH.
Например, в Wallix AdminBastion можно настроить правила таким образом, что внешний администратор сможет только перезагрузить удаленный сервер в корпоративной сети, но не сможет выполнить какую-либо другую команду или скачать файл.
Каждый привилегированный пользователь входит в Wallix AdminBastion, используя свои учетные данные, и получает доступ к разрешенным устройствам без выполнения второй процедуры входа (принцип SSO - Single Sign-On). Сами пароли для целевых устройств хранятся в WAB, поэтому нет нужды сообщать их кому-либо, а сеансы могут открываться автоматически. Процедура смены паролей доступа к корпоративным ресурсам становится простым делом, так как теперь не нужно сообщать их всем пользователям в отдельности.
Не будем подробно останавливаться сейчас на всех функциях конкретного продукта, т. к. это выходит за рамки данной статьи. Важно показать непосредственно подход к решению проблемы контроля привилегированных пользователей. Функции Wallix AdminBastion мы подробно рассмотрели в специальном обзоре.
Выводы
Риски утечки важных конфиденциальных данных через системных администраторов в случае их вынужденного увольнения или замены составляют чуть меньше 50%. Закрытие глаз на эти риски может привести к самым пагубным последствиям для бизнеса. Поэтому вопрос заключается не в том, нужно ли контролировать привилегированных пользователей, а в том, как это лучше делать.
В большинстве предприятий меры контроля привилегированных пользователей или отсутствую вовсе или применяются в ограниченном виде для контроля внешних специалистов. Современные решения позволяют:
- Централизованно управлять административными учетными записями для внешних и внутренних сотрудников, проверять правильность выдачи прав.
- Иметь возможность создания политик доступа для администраторов к корпоративным ресурсам (типы сеансов, протоколы доступа, время доступа и.т.п.). Администратор получает только необходимый и достаточный доступ к обслуживаемым ИТ-системам.
- Централизованно записывать все действия администраторов и, при необходимости, иметь возможность провести полный аудит их действий во всех обслуживаемых ими системах.
- Не дать возможности администраторам бесследно манипулировать данными в обслуживаемых ими системах.
- В режиме реального времени контролировать действия администраторов в обслуживаемых системах, а также иметь возможность вернуться назад во времени и посмотреть предшествующие события и их источник.
- Администратор не будет знать данные аккаунтов в обслуживаемых системах, а использовать только свой персональный аккаунт SSO. Не нужно передавать кому-либо важные пароли за пределы организации, а изменение паролей становится простой рутинной операцией.
В целом, прекрасный практический пример народной мудрости «Доверяй, но проверяй!»
