Мандатный доступ в Dallas Lock 8.0-C - Форум по вопросам информационной безопасности

to pl
Крутые расчеты, ничего не скажешь :)
Попробуйте так: на 1 "тестовой" машине настраиваете все ПО для 1 уч. записи. Далее под парой-тройкой других учеток выполняете только вход. После, из-под администратора копируете профили настроенной учетки в профили "входивших" пользователей (в Win7 это C:\Users\AppData\Local и Roaming). Заходите под любую ранее настроенную учетку и проверяете. Если заработает, то это все можно автоматизировать слегка - у вас же домен? - за счет перенаправления профилей пользователей на сервер AD. Короче, варианты оптимизации задачи все-таки есть. С недельку поковырять, но добиться результата можно...
И вообще, при 100+ пользователях уже имеет смысл групповую систему доступа настроить. Т.е. делите весь софт на группы применимости. Заводите соразмерное число уч. записей. И далее уже настраиваете только их. Если многопользовательская с одинаковыми правами (2А) - это полный выход. Если же каждому сотруднику нужен свой личный каталог, то... да, тут групповая система не катит, увы...

Добрый день!
Господа, есть опыт переноса учетных записей - профилей, со всеми сформированными папками, из win7 на win10. Стандартными средствами виндовс. Как сказывается, дальнейшая настройка далласа?

to Александр
Если перенос ДО установки Далласа, то никак не сказывается. Далласу наплевать, у него своя база данных (условно), в которой фиксируются пути к файлам и каталогам, на которые установлены соответствующие права средствами Далласа. Т.е. перенесли - проверили работоспособность - поставили Даллас - настроили - будет работать...
В других случаях... хмм... возможны варианты (вплоть до отказа системы, ага)...

to oko

Попробовал предложенный Вами вариант, обыграл его по разному, прогресс конечно был, но увы, проблему не решило.
По поводу того что выход есть - возможно.
Но это не НИР что бы было время на изучение проблемы и т.д. :)
Первоначально задача была контролировать действия всех пользователей за всеми АРМами и не мучаться с журналами учета и прочей РСОшной и ЗГТшной бумажной волокитой.
Но, в связи с тем что настройка 1000 учеток на 100 арм была признана не реализуемой (если интересно могу привести аргументы), был предложен альтернативный вариант который пока становится компромиссом.
У нас 100 АРМ, по 2 учетные записи (С и СС) на каждые АРМ и по 2 токена (т.е. 200 пользователей и 200 токенов). Всего физически 1000 работников. Работник приходит в офис, попадает в режимный сектор, получает в 1ом отделе токен, расписывается за него, получает пароль и логин от учетки, так же расписывается в журнале учета рабочего времени, и идет работать. АБ для расследования инцидента достаточно посмотреть №АРМ и время по журналу на СБ и свериться с журналом учета машинного времени. Т.к. запуск АРМа возможен только с предъявлением токена, исключается возможность пользователя зайти с иного АРМ в другое время (или минуя журнал учета).

Вот кстати точные (финальные) расчеты, исходя из 1 привлекаемого работника:
Среднее (эталонное) время на 1 итерацию = 4 минуты.
Создание 1000 рабочих столов на 80 АРМ (80000 рабочих столов)
- 223 суток или 669 рабочих дней по 7 активных часов
Запуск (в среднем) 15 программ на каждом из 80 АРМ на каждом рабочем столе (1307610 запусков)
- 3334 суток или 13336 рабочих дней по 7 активных часов
Итог: 3557 суток или 14005 рабочих дней или 38.5 лет.

Даже если за каждый АРМ посадить по 1 человеку (80 работников) задача будет решена (эталонно) только через 5 месяцев.

to pl
Без обид, но вы тем самым реализовали классическую схему групповой политики доступа, когда уч.записи ОС не привязаны к сотрудникам, а доступ контролируется по выдаче ключевой ИАФ-информации в РСП/РСО/спецчасти. Хороший, стабильный вариант...
Только траббла в том, что при АС 1 класса (с разграничением прав) и необходимости ввода принципа "1 сотрудник = 1 собственный каталог хранения документов" такая модель не работает. В вашем случае понадобится минимум клиент-серверная архитектура АС (для упрощения, снижения затрат, повышения отказоустойчивости и проч.) с промежуточным участником - доп.ПО, в котором авторизация сотрудника производится после авторизации в ОС и Далласе по токену и паролю. И работа идет внутри этого доп.ПО, либо оно уже предоставляет доступ к разграниченным ресурсам...
Опять-таки, все сотрудники у вас со 2 формой допуска (все 1000 человек)? Иначе придется делать токены только под С и токены под С+СС. Что усложняет схему...

ЗЫ Дело тут не в НИР. 100 АРМ, 1000 юзеров и Даллас (+-токены) были, как я понимаю, изначально, на этапе "задумки" (эскиза)? Вот тогда и надо было, извиняюсь, думать. Потому как АС получается огроменных масштабов + высокие требования (ибо ГТ), т.е. любая ошибка может оказаться фатальной и "по-быстрому" действовать нельзя. И явно не Даллас (раз такой разномастный "тяжелый" софт), imho, вы еще с учетом каждого носителя намучаетесь (особенно, когда flash начнут форматировать, а CD надо будет "вот прямо сейчас срочно записать")...

Да, она классическая, без обид тут и так понятно - примитивно и без вкуса. Зато работает.
По поводу второй авторизации. Тут есть централизованная парольная защита папок пользователей на сервере, и карта паролей пользователей. На сервере грубо говоря 2 папки - С и СС. Там мандатный доступ. Внутри этих директорий папки юзеров, на каждой индивидуальный пароль.
Информация для работы на АРМ поступает только через сервер и только через АБ. Все порты и привод отрублены (кроме 1го под токены, ну и собственно они прописаны, кроме этих токенов там ничего не заработает).
2 набора токенов, верно. для С и С+СС сессий. Всего 160.
Эскиза, увы, не было) Была архитектура, были требования, в виду закрытого типа объекта ТЗ разрабатывал Заказчик и только он. В общем, тут было 2 варианта. Реализовать как есть (как хочет Заказчик) или разработать компромисс с которым он согласится. На стадии заключения по ТЗ даже поработать не удалось, ибо оно было написано заказчиком без учета корректировок. Ибо не предусмотрено.

to pl
Понимаю. Особенно под конец года...
Решение с паролями каталогов тоже любопытное и в целом рабочее. Удачного вам внедрения тогда. И для полноты картины (чтобы юзерам жизнь медом не казалась, ага) не забудьте еще про маркировку печати :)

В продолжение темы.
С самого начала реализации проекта узнав исходные данные я подумал - " Ну, если есть контроллер домена, то папки юзеров будут цепляться при первом входе, который в виду доменной организации можно делать после настройки ДЛ и после организации мандатного доступа".
Товарищи их Конфидента со мной не согласились, и твердо сказали - открыть все рабочие столы и программы до настройки. Везде. Иначе не заработает.
Поверил естественно, производитель как ни как, вот и родились все те идеи что есть выше.
Но тут при очередном размышлении решил я все-таки проверить теорию с доменом.
И как бы удивительно не было - работает. Просто работает.
У нас ни разу не загружался рабочий стол, не открывалось ПО и не создавались файлы в AppData. Но Офис заработал в секретной сессии у юзера после тупого применения шаблона на машине.
Вопрос о корректности дальнейшей работы - открытый. Об остальном ПО - тоже.
Накатал очередное письмецо в Конфидент по этому поводу, жду ответа.
Но тут есть своя логика.
1. Папка "Пользователи" на каждом ПК должна быть разделяемая, и все что в ней создается наследует параметры родителя даже после настройки мандатного доступа (но ведь с активным СЗИ такого быть не должно, и каждой новой папке надо присваивать отдельно разделяемый параметр либо отсутствует наследование (до сих пор точно не понял работает ли оно, когда как).
2. Но при тесте я ее (папку Пользователи) не делал разделяемой, грешил на некорректную работу манатки, но остальное ПО (кроме Офиса) было без доступа. Значит все работало. Не знаю в общем, жду ответ Конфидента.

to oko
Спасибо :)
Аудит печати - да, но маркировка, увы, портит документы (формат не только А4 и А3), лезет на содержимое, а фонарик Заказчик исключил.