В современных корпоративных системах безопасность данных стоит на первом месте. Одной из критических уязвимостей является возможность входа в систему 1С под чужими учетными данными (по паролю), даже если в компании настроена доменная аутентификация. Рассмотрим, как программно проверить, что текущий пользователь 1С действительно является тем лицом, под чьей учетной записью была загружена операционная система, и разберем способы получения информации о доменных группах пользователя.
Стандартные механизмы 1С позволяют настроить Аутентификацию ОС, однако это не закрывает все лазейки. Если у пользователя в карточке оставлена возможность входа по паролю (например, для административных целей или удаленного доступа), злоумышленник или коллега может войти в базу под чужим именем, зная пароль. Наша задача — программно убедиться, что логин в 1С совпадает с UserName в Windows, и при необходимости заблокировать работу.
Это один из самых простых и популярных способов получения информации о текущем пользователе Windows. Данный метод отлично работает на стороне тонкого и толстого клиента под управлением операционных систем семейства Windows. Проанализируем пример кода для получения имени пользователя и домена:
// Создаем объект для работы с сетевыми функциями Windows
Попытка
СетевойОбъект = Новый COMОбъект("WScript.Network");
ИмяПользователяОС = СетевойОбъект.UserName;
ДоменОС = СетевойОбъект.UserDomain;
КомпьютерОС = СетевойОбъект.ComputerName;
Сообщить("Текущий пользователь ОС: " + ИмяПользователяОС);
Сообщить("Домен: " + ДоменОС);
Исключение
Сообщить("Не удалось инициализировать WScript.Network. Возможно, выполнение кода происходит не на Windows-клиенте.");
КонецПопытки;
Важный нюанс: этот метод возвращает данные того пользователя, в контексте которого запущен процесс 1cv8.exe. Если вы запустите этот код на сервере (в фоновом задании), вы получите имя учетной записи, под которой работает служба сервера 1С (например, USR1CV8), а не имя инициатора задания.
Если нам требуется более детальная информация, например, SID пользователя или проверка вхождения в группы без прямого обращения к контроллеру домена, рассмотрим использование WMI (Windows Management Instrumentation). Этот инструмент позволяет извлекать практически любые данные о системе.
// Пример получения информации о залогиненном пользователе через WMI
Локатор = Новый COMОбъект("WbemScripting.SWbemLocator");
СервисWMI = Локатор.ConnectServer(".", "root\cimv2");
РезультатЗапроса = СервисWMI.ExecQuery("SELECT * FROM Win32_ComputerSystem");
Для каждого Объект Из РезультатЗапроса Цикл
// Возвращает строку вида "DOMAIN\USER"
ПолноеИмя = Объект.UserName;
Сообщить("Активный сеанс: " + ПолноеИмя);
КонецЦикла;
Преимущество WMI заключается в том, что он позволяет работать с системными объектами напрямую, однако стоит помнить, что в высоконагруженных системах частое обращение к WMI может потреблять значительные ресурсы сервера и подгружать дополнительные системные библиотеки в адресное пространство процесса rphost.
Когда стоит задача проверить не просто имя, а вхождение пользователя в определенную группу безопасности домена (например, группа «Бухгалтерия_Доступ»), лучше всего использовать LDAP-запрос. Это самый надежный способ интеграции с корпоративной политикой безопасности. Разберем логику построения такого запроса:
// Настройка подключения к Active Directory
Connection = Новый COMОбъект("ADODB.Connection");
Connection.Provider = "ADSDSOObject";
Connection.Open("Active Directory Provider");
Command = Новый COMОбъект("ADODB.Command");
Command.ActiveConnection = Connection;
// Запрос на поиск пользователя по его логину
ЛогинДляПоиска = "ivanov_ii";
Command.CommandText = "SELECT memberOf FROM 'LDAP://DC=yourdomain,DC=com' WHERE sAMAccountName = '" + ЛогинДляПоиска + "'";
RecordSet = Command.Execute();
Пока НЕ RecordSet.EOF Цикл
СписокГрупп = RecordSet.Fields("memberOf").Value;
// СписокГрупп содержит массив строк с путями доменных групп
RecordSet.MoveNext();
КонецЦикла;
Используя этот подход, мы можем на лету определять права доступа пользователя в 1С, основываясь на его актуальных правах в домене Windows. Это избавляет администратора от двойной работы по ведению списков доступа.
Рассмотрим ситуацию, когда проверка должна выполняться в фоновом задании. Как мы уже выяснили, функции ИмяПользователяОС() на сервере бесполезны для идентификации человека. Чтобы решить эту задачу, необходимо:
Если использование COM-объектов ограничено политиками безопасности, можно прибегнуть к косвенным методам. Проанализируем путь к временным файлам пользователя или его рабочему каталогу. Обычно путь содержит имя учетной записи Windows:
// Косвенная проверка через путь к профилю
ПутьКПрофилю = КаталогВременныхФайлов();
// Результат будет примерно: C:\Users\Ivanov\AppData\Local\Temp\
// Мы можем сравнить вхождение подстроки "Ivanov" с текущим пользователем 1С
Внимание: этот метод не является стопроцентно надежным, так как пути могут быть переопределены системным администратором, но он может служить дополнительным фактором в системе аудита.
Выясним причину, почему одной доменной проверки часто недостаточно. Если пользователь Маша отошла от компьютера, не заблокировав сессию (Win + L), а за её стол сел Вася, то любые проверки WHOAMI или WScript.Network подтвердят, что за компьютером сидит «Маша». Для борьбы с этим рекомендуется:
ПриНачалеРаботыСистемы для жесткого сравнения: если в базе 1С у пользователя указано АутентификацияОС, но он вошел по паролю — немедленно вызывать ЗавершитьРаботуСистемы().Таким образом, сочетание доменной проверки через COM/LDAP и строгой настройки прав в самой 1С позволяет создать защищенный контур, минимизирующий риски человеческого фактора и утечки паролей.