Работа средств парольной аутентификации пользователей подсистемы УБР РАБИС-НП основана на использовании прикладного сервиса аутентификации в качестве единственного средства получения прикладными программами АРМ необходимых для их функционирования конфигурационных данных о подсистеме и пользователе. Сервис аутентификации (исполняемый модуль task807.exe) функционирует на сервере подсистемы с полномочиями специального пользователя «mservice» и обеспечивает:
защиту (изоляцию) конфигурационных данных подсистемы и аутентификационных данных пользователей от прикладных пользовательских процессов;
парольную аутентификацию и авторизацию пользователей подсистемы;
предоставление необходимых конфигурационных данных о подсистеме и полномочиях авторизованного пользователя для процессов (прикладных программ) АРМ;
предоставление процессам авторизованного пользователя дополнительной части парольной информации для подключения к используемым этими процессами базам данных (в СУБД MS SQL);
разграничение доступа пользователей к функциям АРМ;
разграничение доступа к модификации конфигурационных данных подсистемы и аутентификационных данных пользователей для процессов авторизованных пользователей, в соответствии с правилами разграничения доступа подсистемы.
На первом этапе взаимодействия организующей или прикладной программы АРМ («клиент») с сервисом аутентификации («сервер») выполняется процедура аутентификации пользователя:
клиент получает из переменной окружения SERVICES_FILE полный путь к файлу с параметрами подключения к прикладным сервисам РАБИС-НП, выбирает параметры для подключения к сервису аутентификации (секция AUTHSERVER, после чего устанавливает сетевое соединение с этим сервисом и согласовывает с ним протокол обмена данными;
сервис аутентификации генерирует случайную маску, ассоциирует ее с данным клиентским соединением и передает ее клиенту;
клиент запрашивает ввод параметров аутентификации (идентификатор и пароль) у пользователя, вычисляет хэш от связки имени и пароля пользователя, маскирует этот хэш полученной от сервера маской и передает маскированный хэш сервису аутентификации;
сервис аутентификации, используя ассоциированную с данным соединением маску, восстанавливает значение клиентского хэша; выполняет аутентификацию клиента (сравнивает полученное значение клиентского хэша с зарегистрированным аутентификационным значением); в случае успеха, создает контекст пользователя (ассоциированный с данным клиентским соединением) и сообщает клиенту об успешной его аутентификации.
Примечание. Прикладные программы ТПК РАБИС-НП могут также использовать параметры аутентификации, полученные от родительского процесса (например, от организующей программы xpress.exe).
После получения от сервиса аутентификации сообщения об успешной аутентификации клиентский процесс может использовать установленное соединение для обращения к сервису аутентификации с запросами на получение необходимых конфигурационных данных или на их модификации. Обработка этих запросов выполняется в соответствии с правилами разграничения доступа с учетом зарегистрированной категории (роли) аутентифицированного в данном соединении пользователя.
При первом входе пользователя в систему, либо при наличии признака аннулирования пароля, в качестве значения пароля пользователя принимается значение, равное идентификатору пользователя.
Принудительная смена пароля инициируется при выполнении одного из следующих условий: первый вход пользователя в систему; установлен признак аннулирования пароля пользователя; истек срок действительности пароля.
Признаки аннулирования пароля пользователя и признаки необходимости смены пароля для пользователей могут устанавливаться администраторами информационной безопасности.
Количество попыток ввода пользователем корректного пароля программно ограничено тремя неудачными попытками (для противодействия средствам автоматизированного подбора паролей), после которых процедура входа в АРМ завершает работу.
При попытках установки пользователем нового значения пароля программно проверяется выполнение следующих требований к «качеству» пароля:
длина пароля должна быть не менее 8 символов;
в пароле должны присутствовать хотя бы один алфавитный символ, хотя бы один цифровой и хотя бы один специальный;
хотя бы один из алфавитных символов должен отличаться регистром (SHIFT) от остальных;
пароль не должен совпадать с идентификатором пользователя;
вновь устанавливаемое значение пароля не должно совпадать с пятью предыдущими значениями пароля.
При невыполнении этих условий, на экран выводятся соответствующие комментарии и подсказки.
Для функционирующих в непрерывном автоматическом режиме АРМ оператора СД КЦОИ, АРМ оператора ВЭО и МЭР, а также АРМ контролера ЭС подсистем ОИТУ КЦОИ, реализована возможность т.н. «группового режима» работы их операторов, учитывающего специфику работы персонала дежурных смен КЦОИ. В «групповом режиме» автоматическая работа АРМ производится от имени оператора, первым запустившего АРМ, а требующие вмешательства оператора управляющие функции могут выполняться свободным оператором дежурной смены, если он зарегистрирован для работы на этом АРМ с соответствующей категорией (ролью). Выполнение критичных управляющих воздействий операторами этих АРМ регистрируется в регистрационном журнале с указанием имени конкретного оператора, для чего каждая такая операция предваряется запросом имени и пароля оператора АРМ для выполнения его аутентификации и авторизации. При отрицательных результатах аутентификации или авторизации пользователя, выполнение данной операции блокируется, с регистрацией попытки НСД в журнале.
«Групповой режим» работы пользователей указанных АРМ может устанавливаться администраторами ИБ подсистем ОИТУ КЦОИ, с учётом политики безопасности и организационно-технических мер защиты, реализуемых в КЦОИ. По умолчанию действует «индивидуальный» режим работы этих АРМ, при котором смена пользователей должна сопровождаться перезапуском АРМ (с повторным коннектом к БД и инициализацией ключевой информации).
5.4. Регистрация действий пользователей подсистем
В подсистемах УБР, ТУ, ТЦОИ, ОИТУ КЦОИ РАБИС-НП регистрация действий пользователей выполняется специальным сервисом регистрации, функционирующим на сервере подсистемы. Прикладные процессы, обрабатывая события, подлежащие регистрации, вызывают функцию регистрации, передавая ей необходимые атрибуты. Функция регистрации обращается к сервису регистрации, который осуществляет буферизацию поступающих к нему обращений и их запись в файл оперативного регистрационного журнала.
Сервис регистрации обеспечивает:
информирование прикладных процессов о работоспособности сервиса регистрации;
уникальную идентификацию файлов регистрационных журналов;
запись регистрационных сообщений в файл оперативного регистрационного журнала с формированием защитных контрольных сумм;
очистку оперативного журнала с переносом его данных в архивный журнал по команде администратора ИБ, или по наступлению предварительно сконфигурированных событий (по смене дат или по достижению оперативным журналом определенного размера).
Имя файла оперативного регистрационного журнала фиксированное: «syslog.tk». Имена файлов архивных журналов строятся следующим образом
DDMMYYYY_hh-mm_BBBBB_EEEEE.tk,
где:
DDMMYYYY - календарная дата первой записи журнала;
hh-mm - время в часах и минутах первой записи журнала;
BBBBB - контрольная сумма первой записи журнала;
EEEEE - контрольная сумма последней записи журнала.
В состав каждой регистрационной записи включаются:
дата (число, месяц, год);
время;
имя вычислительной установки (HostName);
уровень приоритета события (2 - «критическое», 4 - «важное», 6 - «информационное»);
имя пользователя в операционной системе (UserName);
номер пользователя по таблице пользователей подсистемы;
идентификатор задачи, выполнившей регистрацию события;
идентификатор класса события;
идентификатор (код) события;
текстовая строка с параметрами сообщения;
значение контрольной суммы (CRC), вычисленное от значения контрольной суммы предыдущей записи и содержимого текущей записи (без учета поля самой CRC).
Последнее поле регистрационной записи используется для контроля целостности и непрерывности регистрационного журнала. Для первого регистрационного журнала (запуск сервиса регистрации в условиях отсутствия в каталоге файла syslog.tk) контрольная сумма «нулевой» записи принимается равной нулю. При закрытии текущего журнала и открытии нового, последнюю регистрационную запись (которой будет запись об открытии нового файла регистрационного журнала) - сформирует сам сервис регистрации. Эта же запись дублируется (с той же контрольной суммой) в качестве первой записи вновь открываемого оперативного журнала.
Необходимым условием работы прикладных средств регистрации являются функционирование процесса «сервис регистрации». Этот процесс организуется программой task808.ovl, запускаемой в режиме сервиса операционной системы с правами специального пользователя «mservice». Файлы регистрационного журнала ведутся в специально выделяемом каталоге %pathxpress%\syslog\ (путь к нему указывается при конфигурировании сервиса).
Наличие и работоспособность сервиса регистрации проверяется программным обеспечением ПК РКЦ РАБИС-НП при запуске АРМ и отдельных программ. Запуск АРМ и программ блокируется при отсутствии или неработоспособности этого процесса с выдачей соответствующего сообщения. Для корректного обращения процессов АРМ к сервису регистрации, на каждой рабочей станции должна быть определена переменная окружения SERVICES_FILE, указывающая полный путь к файлу, в котором в секции REGSERVER описывается имя серверной установки и номер порта, на которых функционирует сервис регистрации подсистемы.
Отдельная функция проверки работоспособности сервиса регистрации включена в состав АРМ администратора информационной безопасности.
Работа с регистрационным журналом осуществляется на АРМ администратора информационной безопасности подсистемы.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9
