Блог системного интегратора

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

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

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

Используя диссидентский телеграмм, нашел продавца, у него было все, от баз банков «Сбербанк», ВТБ, «Тинькофф Банк» до данных автовладельцев и иммигрантов.

И это не тысячи, а сотни тысяч записей. Естественно, покупать ничего не стал, но процедура проста, и продавцу было все равно для чего мне это.

Тут возникает вопрос- кто же именно сливает все эти данные в таких объемах?

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

На сколько я осведомлен, и даже уверен, просто так не переслать документ Excel из системы банка. Банковская сфера революционер в сфере информационной безопасности, и уж если у банка есть лицензия, то он точно исполняет требования ЦБ РФ по информационной безопасности, а они стремятся чуть ли не к гостайне.

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

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

Все эти данные злоумышленник может использовать, притворившись легитимным сотрудником банка, ведь остаток чаще всего знает только владелец и банк, а значит 3 стороны быть не может (наивный…).

А в некоторых банковских базах фигурирует даже кодовое слово.

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

Одна запись клиента крупной организации стоит 80р., менее крупной 40р., но это больше зависит от жадности продавца. Есть дисконтная политика, к примеру, за 400 тысяч записей продавец может попросить всего 35 т.р., что значит одна запись стоит дешевле 10 копеек.

Так же есть сайты, на которых можно произвести расчет базы, там же стоимость была в два раза дороже, видимо нужно доплачивать за сервис. Так же были и критерии увеличения цены по целевой аудитории (бизнесмены, гос. служащие). Но что самое интересное, старые базы можно приобрести за каких-нибудь 50-100 рублей. Как давно вы меняли свой номер телефона?

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

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

Согласно закону «О персональных данных», те организации, которые обрабатывают информацию граждан РФ, не имеют права распространять и передавать третьим лицам, без их согласия (но кто спрашивает?).

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

Как же все-таки защитить данные?

Здесь должны быть вовлечены две стороны, оператор обработки данных и лицо, предоставляющее данные (субъект).

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

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

С технической стороны должны быть внедрены SIEM и DLP, и другие подобные системы контроля действий сотрудников, потоков информации и событий системы.

UPD:

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

·        Федеральный закон "Об информации, информационных технологиях и о защите информации" от 27.07.2006 № 149-ФЗ

·        Федеральный закон "О персональных данных" от 27.07.2006 № 152-ФЗ

·        Федеральный закон "О коммерческой тайне" от 29.07.2004 № 98-ФЗ

Короткий пост.

Для одной факультативной задачи, потребовалось сделать средство программного управления уровнями целостности (Integrity Level) файловых объектов в операционной системе.

Уровни целостности - технология довольно экзотическая и малоизученная, появились в Windows Vista/2008, используются в них и во всех более поздних версиях клиентских и серверных ОС как один из встроенных механизмов защиты. Пример описания на MSDN – “Windows Integrity Mechanism Design”, https://msdn.microsoft.com/en-us/library/bb625963.aspx.

В итоге не придумал ничего лучше, чем тряхнуть стариной, и написать мини-утилиту командной строки на старом добром Си. Выкладываю как есть, исходный текст совсем не велик, и интуитивно понятен. Библиотеки классов не используются вовсе, стандартные функции тоже по минимуму, хватает Windows API. MIL – это “Manage integrity levels”.

Компилируется в любой современной версии Visual Studio (я использовал Visual Studio Community 2017) как консольное приложение.

Для примера рассмотрим следующий сценарий, близкий к реальным условиям клиента. Имеется четыре приложения – 1C, Directum, CRM, Invest, для поддержки которых необходимо организовать доступ разных групп службы ТП.

Глобальные группы доступа пользователей к приложениям: DOMAIN\Access_1C, DOMAIN\Access_Directum, DOMAIN\CRM_Access, DOMAIN\Access_Invest;  

Соответствующие (создаваемые в рамках решения) коллекции компьютеров в SCCM: 1C, Directum_5_3, PC_Remote_control_CRM, PC_Remote_control_Invest;

Соответствующие глобальные группы учетных записей пользователей ТП, которым предоставляется доступ к Remote Control для

компьютеров в целевых коллекциях: DOMAIN\SCCM-RC_Access_1C, DOMAIN\SCCM-RC_Access_Directum, DOMAIN\SCCM-RC_Access_CRM, DOMAIN\SCCM-RC_Access_Invest.

Решение строим для этих условий.

3.    Формирование коллекций компьютеров

Механизм сопоставления User Device Affinity требует требует включения в политиках домена параметров аудита Audit account logon events и Audit logon events, как описано в статье “How Automatic User Device Affinity Works in SCCM 2012”, https://blogs.technet.microsoft.com/sudheesn/2015/03/05/how-automatic-user-device-affinity-works-in-sccm-2012. Сбор данных из журналов безопасности осуществляется SCCM автоматически. Порог срабатывания (время работы пользователя в системе, по прошествии которого он становится “Primary User”), контролируется через политику клиента SCCM, раздел “Сопоставление пользователей и устройств”, например, так:


Приступаем к созданию коллекций. Пример для коллекции для компьютеров с CRM:

Коллекция формируется на основе запроса WQL:

Сам запрос WQL:

Идея запроса взята отсюда: “ConfigMgr User Device Affinity (UDA) Collection Query”, https://deploymentramblings.wordpress.com/2017/05/22/configmgr-user-device-affinity-uda-collection-query/. При выполнении этого запроса формируется коллекция компьютеров, основные пользователи (Primary Users в терминологии SCCM) входят в доменную группу DOMAIN\CRM_Access.

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

4. Контроль доступа к Remote Control

Доступ к функции SCCM Remote Control на управляемой системе, в общем случае, контролируется членством в локальной группе "Пользователи удаленного управления Configuration Manager" (в русской версии SCCM). В нее попадают объекты безопасности, прописанные в политике клиента SCCM в разделе “Средства удаленного управления”, параметр “Пользователи средств удаленного управления и удаленного помощника”. При установке значения этого параметра, перечисленные в нем пользователи и группы попадают в локальную группу "Пользователи удаленного управления Configuration Manager" на компьютере, к которому применяется политика. Но, как уже говорилось, эффективная политика – только одна, поэтому нам стандартный механизм помочь не может.

Однако, опытным путем установлено, что если параметр “Пользователи средств удаленного управления и удаленного помощника” в политике клиента SCCM оставить пустым, вот так:

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

Именно такое решение и было применено – скрипт на WSH с помощью подсистемы WMI подключается к локальным экземплярам классов клиента SCCM, и динамически проверяет принадлежность системы к каждой из анализируемых коллекций, при необходимости добавляя в локальную группу "Пользователи удаленного управления Configuration Manager" операционной системы десктопа требуемую глобальную группу доступа для Help Desk.

“Подводный камень” заключается в том, что простого способа проверить список коллекций, к которым принадлежит компьютер, с помощью локальной подсистемы WMI - нет (по крайней мере, я пока не придумал). Такая проверка возможна только, если подсоединиться по сети к подсистеме WMI самого сервера SCCM. Но очень хочется исполнять скрипт с правами локальной системы, а не сетевой учетной записи - ведь если подсоединяться к SCCM с локальной системы с помощью сетевой УЗ с паролем, это почти наверняка так или иначе приведет к ослаблению системы безопасности. Учетная же запись системы по сети подсоединиться к SCCM для проверки списка коллекций не может - для такого запроса у нее не хватает прав на уровне DCOM, а ослаблять защиту DCOM без крайней необходимости не стоит, по той же причине.

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

То есть, для каждой проверяемой коллекции (и только для нее одной в рамках инсталляции SCCM), мы дополнительно определяем специальную переменную с префиксом Collection_RC_, с именем и значением, соответствующим имени самой коллекции. Переменные коллекции, в отличие от самого списка коллекций, “спускаются” в локальный WMI клиента при каждом обновлении политики; наличие их в репозитарии WMI мы проверяем программным способом.

Скрипт ManageSCCMRCAccess.vbs приведен в приложении к статье, предоставляется AS IS. Работоспособность проверена на всех версиях Windows, содержащих подсистему WMI, то есть, он гарантированно работает на Windows XP и выше - иначе говоря, на всех системах Windows, для которых существует клиент SCCM. Логика скрипта отражает условия нашей задачи (имена коллекций и групп), но он может быть адаптирован по потребностям для любого количества комбинаций “коллекция-группа доступа”. Для запроса данных SCCM используются классы и методы WMI, для управления локальной группой – интерфейс ADSI. Перед каждой проверкой коллекций производится предварительная чистка группы "Пользователи удаленного управления Configuration Manager". Это сделано для отработки ситуации, когда приложение более не используется (компьютер пропадает из коллекции), это приводит к отзыву права подключения у соответствующей группы ТП. Установка константы DEBUGLOG=True задает протоколирование работы скрипта в простой текстовый лог C:\SCCM_RC_Config.log – включить отладку полезно на случай, если что-то пошло не так.

5. Запуск скрипта

Скрипт размещается в сетевой папке с правами только для чтения для группы Domain Computers, запускается планировщиком Task Scheduler операционной системы раз в час, обнаруженные изменения вступают в силу немедленно. Этого оказалось достаточно, чтобы построить систему управления правами доступа к Remote Control, практически не требующую вмешательства администратора. Единственное, что нужно – добавлять пользователей в глобальные группы доступа к приложениям DOMAIN\Access*, но это как раз та операция, которая контролируется персоналом ИТ.

Никто, кстати, не мешает использовать любые другие способы периодического запуска скрипта, например, с помощью самого SCCM.

Скриншоты задания планировщика приведены ниже, они тривиальны. Задача назначается на целевые рабочие станции с помощью доменного GPO, раздел “Preferences”:

• Все ссылки на реальную инфраструктуру клиента в скрипте и скриншотах изменены;
  
• Решение тестировалось в среде SCCM 2012 R2, но оно полностью применимо и к SCCM 2016 – основные подсистемы в новой версии почти не поменялись;
  
• Для анализа объектов WMI в системе Windows, из известных мне средств, удобнее всего использовать утилиту WMI Explorer от CodePlex, см. https://archive.codeplex.com/?p=wmie.