Рис. 1. Важнейшие направления обеспечения информационной безопасности РАБИС-НП

Обеспечение информационной безопасности рабочих подсистем РАБИС-НП в процессе их эксплуатации является сферой ответственности администраторов программного обеспечения и, в первую очередь, администраторов информационной безопасности этих подсистем, выполняющих свои функции с помощью соответствующих АРМ подсистемы. Важнейшими функциями администраторов программного обеспечения являются: настройка АРМ и параметров программного комплекса, применение пакетов модификации ТПК «РАБИС-НП», запуск, мониторинг и остановку серверных процессов, и т.п. Важнейшими функциями администраторов информационной безопасности являются: управление пользователями подсистемы, управление их доступом к ресурсам РАБИС-НП, контроль целостности программного обеспечения подсистемы, анализ регистрационных журналов программного комплекса.

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

3.  ТРЕБОВАНИЯ К ЗАЩИТЕ АППАРАТНЫХ И СИСТЕМНЫХ СРЕДСТВ подсистем РАБИС-НП

3.1. Требования к организационно-техническим мероприятиям по обеспечению защиты инфраструктуры локальных сетей, телекоммуникаций и серверов подсистем РАБИС-НП

Безопасность автоматизированной системы в значительной степени определяется конфигурацией системных средств объектов автоматизации – операционных систем, СУБД и сетевых сервисов. Чем сильнее «закрыты» локальные сети, операционные системы и СУБД вычислительных установок УБР, ТЦОИ и КЦОИ для неиспользуемых в РАБИС-НП и ИСУ ТИР сервисов и приложений, тем выше уровень информационной безопасности.

На объектах автоматизации должны выполняться следующие требования:

–       cерверные вычислительные установки (центральные серверы подсистем обработки информации КЦОИ, серверы доступа, серверы контроля, серверы подсистем УБР и ТУ, серверы средств телекоммуникаций и т.п.) должны располагаться в отдельных помещениях, доступ в которые должен быть максимально ограничен организационно-техническими мерами;

–       для регламентации сетевого доступа к серверам и рабочим станциям подсистем РАБИС-НП должна использоваться сегментация локальных вычислительных сетей соответствующих учреждений и подразделений Банка России (рекомендации по отделению платежных сегментов от других сегментов ЛВС УБР, ТУ, ТЦОИ и КЦОИ);

–       средства управления маршрутизацией должны быть сконфигурированы для маршрутизации только необходимых для функционирования приложений РАБИС-НП и РЗ ИСУ ТИР сетевых сервисов; сетевые пакеты других сетевых служб и протоколов должны отвергаться;

–       работа пользователей, имеющих особые привилегии (администраторов операционной системы, администраторов СУБД, администратора ПО - пользователя «xpress», администратора информационной безопасности – пользователя «security») должна организационно допускаться только с определенных рабочих станций, защищенных средствами защиты информации от НСД с активизированными средствами регистрации;

–       доступ к консолям серверов должен быть ограничен организационно-техническими мерами;

–       на рабочих станциях пользователей, работающих со средствами криптографической защиты информации, должны использоваться средства защиты информации от НСД;

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

Администраторы ОС USS zOS вычислительных установок, на которых функционируют подсистемы ОИТУ КЦОИ должны обеспечивать выполнение следующих требований:

–       использование служб управления паролями операционной системы и СУБД с обеспечением установленных Банком России требований к парольной защите (длина пароля на менее 8 символов, обязательное наличие букв нижнего и верхнего регистров, цифр и специальных символов, проверка вновь устанавливаемого значения пароля на отличие от ранее использованных значений, срок действительности не более 1 месяца, и т.д.);

–       ограничение списка каталогов, включаемых в переменную окружения PATH, и периодическую проверку всех программ, доступных по этому пути. Особенно тщательно должны быть проверены программы, использующие s-бит. Наличие доступных пользователям прикладных suid- программ, владельцем которых является root, является абсолютно недопустимым;

–       настройку операционной системы UNIX для разграничения доступа групп пользователей в стиле Berkeley;

–       использование в файлах настройки (профайлах) пользователей АРМ КЦОИ, функционирующих в терминальном режиме, маски прав доступа для вновь создаваемых файлов (permission mask) со значением umask=006;

–       ограничение списка «доверенных хостов» сети (в файлы host-эквивалентности: $HOME/.rhosts, /etc/hosts.equiv могут включаться только установки тестового и технологического комплексов сопровождения ПО);

–       предотвращение возможности выхода пользователя в режим командной строки и возможности одновременной работы двух и более пользователей с одним и тем же именем в операционной системе (обеспечивается включением процедуры singlelogin.sh, поставляемой в составе ТПК РАБИС-НП, в профайлы пользователей терминальных АРМ в качестве последней процедуры, выполняемой при входе пользователя в систему).

При эксплуатации подсистемы КЦОИ следует также учитывать рекомендации, изложенные в отчетных материалах по НИР «Применение инструментальных средств управления доступом RACF для построения защищенной среды эксплуатации технико-программного комплекса РАБИС-НП, функционирующего на платформе IBM MP 3000 H50/OS390/Oracle в ГУ Банка России по Нижегородской области», выполненной Институтом проблем информатизации Российской Академии Наук в 2002 году.

3.2. Применение средств защиты информации от НСД на рабочих станциях пользователей и серверах РАБИС-НП

Для защиты от несанкционированного доступа к ПЭВМ рабочих станций и Intel- серверов подсистем РАБИС-НП, должны использоваться СЗИ от НСД типов: "Аккорд" (ОКБ САПР), "Dallas Lock" (Конфидент) или "Secret Net" (АО Информзащита), или иных, при наличии у них сертификатов, подтверждающих соответствие классу защищенности не ниже четвертого для средств вычислительной техники в среде используемой операционной системы, выданных сертифицирующими органами ФСТЭК России.

В связи с тем, что различные типы СЗИ от НСД используют отличающиеся механизмы реализации сервисов защиты и разные способы администрирования этих сервисов, в настоящем разделе приводятся лишь общие рекомендации по использованию важнейших сервисов защиты, которые предоставляются всеми из указанных выше типов СЗИ от НСД. Конкретные требования к настройке применяемых на объектах автоматизации типов СЗИ от НСД должны разрабатываться подразделениями технической защиты информации региональных УБиЗИ.

В минимальной конфигурации СЗИ от НСД должны обеспечивать:

–       аутентификацию пользователя и предоставление доступа к ресурсам компьютера только по предъявлению его личного идентификатора (Touch-memory или Smart-card), с дополнительным вводом пароля;

–       контроль целостности операционной системы до ее загрузки;

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

–       создание изолированной программной среды для каждого пользователя (обеспечивающей запуск только определенного администратором информационной безопасности набора программ или процессов).

Дополнительно, СЗИ от НСД могут быть использованы в следующих целях:

–       для контроля целостности важнейших системных и прикладных файлов программ и данных, размещаемых локально (например, ПО и ключевых справочников средств подписи и т.п.);

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

Установка и настройка СЗИ от НСД на рабочих станциях и Intel- серверах подсистем РАБИС-НП выполняется администраторами информационной безопасности объектов автоматизации в соответствии с эксплуатационной документацией на СЗИ от НСД и требованиями, разработанными подразделением технической защиты информации. Рекомендуется установку и настройку СЗИ от НСД выполнять на завершающем этапе настройки программного обеспечения подсистемы.

В перечень файлов, целостность которых контролируется СЗИ от НСД, рекомендуется включать исполняемые, библиотечные и конфигурационные файлы средств подписи, файлы справочника сертификатов открытых ключей подписи, а также конфигурационные файлы прикладного ПО РАБИС-НП, размещаемые локально на рабочей станции.

Рекомендуется включать конфигурационные файлы средств подписи и прикладного ПО, а также файлы справочника сертификатов открытых ключей подписи, в перечень файлов, попытки доступа к которым по записи регистрируются в журнале СЗИ от НСД.

Для предварительного конфигурирования СЗИ от НСД с целью создания замкнутой программной среды на рабочих станциях и Intel- серверах подсистем РАБИС-НП, могут быть использованы перечни исполняемых модулей прикладного (ПК «РКЦ РАБИС-НП») и системного ПО, приведенные в Приложении 1. В этом приложении приведены отдельные перечни модулей, исполняемых на серверных установках подсистем РАБИС-НП и исполняемых на рабочих станциях пользователей. Однако следует учитывать, что приведенные перечни не могут претендовать на актуальность и исчерпываемость, поскольку они определялись в конкретных условиях определенной аппаратной и системной конфигурации и конкретных версий прикладного и системного программного обеспечения. Кроме того, порядок взаимодействия компонентов операционных систем Windows, а также, остального применяемого системного ПО в значительной степени недокументирован и может изменяться с выходом новых версий или после применения сервисных пакетов. В связи с этим, настройка замкнутой программной среды на рабочих станциях и серверах подсистем РАБИС-НП в отношении системных исполняемых модулей может быть рекомендована только при применении СЗИ от НСД, предоставляющих возможность предварительного тестирования функционального программного обеспечения в режиме т.н. «мягкого разграничения доступа». Включение рабочего режима разграничения доступа по отношению к системным компонентам ПО может допускаться только после тщательного анализа журналов СЗИ от НСД, полученных по результатам полнофункционального тестирования защищаемой установки в режиме «мягкого разграничения доступа». Предварительное тестирование в режиме «мягкого разграничения доступа» СЗИ от НСД должно также выполняться после любого изменения аппаратной или системной конфигурации защищаемой установки.

4.  ОБЕСПЕЧЕНИЕ ЦЕЛОСТНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РАБИС-НП В ПРОЦЕССЕ СОПРОВОЖДЕНИЯ

4.1. Обеспечение целостности дистрибутивов и пакетов модификации ТПК «РАБИС-НП»

Обеспечение целостности дистрибутивов и пакетов модификации (ПМ) ТПК «РАБИС-НП» является сферой ответственности разработчика программного обеспечения.

Процедуры, применяемые в системе сопровождения ТПК «РАБИС-НП» для формирования файлов дистрибутивов и ПМ, обеспечивают формирование электронных цифровых подписей этих файлов с использованием личных ключей подписи сотрудников ООО «МЕБИУС-КОМ», ответственных за их тестирование перед тиражированием в регионы. В свою очередь, процедуры, с помощью которых на объектах сопровождения ТПК «РАБИС-НП» осуществляется применение ПМ, выполняют контроль целостности дистрибутивов и ПМ проверкой их цифровых подписей. При этом, по подписям всегда можно персонально идентифицировать сотрудника ООО «МЕБИУС-КОМ» выпустившего конкретный ПМ (как правило, это сотрудник отдела тестирования и сопровождения, выполнявший тестирование данного ПМ).

Для обеспечения возможности контроля целостности и идентификации версий исполняемых модулей ПК РКЦ «РАБИС-НП», модифицируемых в процессе сопровождения средствами xdelta.exe (“дельтами” исполняемых модулей), в master- файле каждого пакета модификации указываются контрольные значения хэш- функции для каждого модифицируемого этим пакетом файла (контрольные значения приводятся для файлов, которые должны быть получены в результате применения данного ПМ) исполняемой системы. Сам master- файл также подписывается сотрудником ООО «МЕБИУС-КОМ», выпускающим данный ПМ. Аналогичным образом, с дистрибутивом версии программного обеспечения ПК РКЦ РАБИС-НП поставляется подписанный файл с контрольными значениями хэш-функции для всех файлов исполняемой системы этой версии. Программы, выполняющие установку и сопровождение ПК РКЦ «РАБИС-НП», обеспечивают контроль целостности получаемых в результате инсталляции или модификации файлов исполняемой системы по контрольным значениям хэш-функции. Администраторы программного обеспечения и информационной безопасности подсистем УБР со своих АРМ могут получить версию и текущее значение хэш- функции любого файла исполняемой системы, и сравнить их с контрольными значениями дистрибутива или пакетов модификации.

Для непосредственной работы с цифровыми подписями файлов используется специально разработанное программное обеспечение, состоящее из программ формирования цифровой подписи (fixint), проверки цифровой подписи (tstint), и программы – менеджера ключевой системы idmng.exe. Программы реализованы на основе российских стандартов криптоалгоритмов на хэш-функцию (ГОСТ Р 34.11-94), цифровую подпись (ГОСТ Р 34.10-94) и шифрование (ГОСТ 28147-89). Ключевая система этих средств ЭЦП специально разработана для использования в системе сопровождения ТПК «РАБИС-НП» и позволяет предельно упростить процедуры распределения ключей проверки ЭЦП за счет использования сертификатов. Цифровая подпись файла формируется в виде отдельного файла, в котором к подписи присоединяются и все сертификаты публичного ключа автора подписи.

Программы fixint и tstint предназначены для работы непосредственно в среде сопровождаемого программного обеспечения и, соответственно, реализуются в виде отдельных исполнимых модулей для каждой из поддерживаемых системно-технических платформ ПК ЦОИ «РАБИС-НП». Менеджер ключевой системы – программа idmng.exe предназначена для создания и сопровождения файлов ключевой системы ЭЦП в среде операционных систем Windows 9x/NT/2000/XP/2003. Сформированные этой программой файлы ключевой системы могут использоваться для любой поддерживаемой системно-технической платформы без всяких дополнительных преобразований.

Формат командной строки для вызова программы fixint:

FIXINT <имя подписываемого файла> <имя файла подписи> <имя ID-файла подписывающего пользователя> [<имя парольного файла>]

ID- файл – это файл, в котором хранится личный ключ подписи пользователя, защищенный паролем.

Парольный файл – это файл определенного формата, в котором спрятан (замаскирован) пароль защиты ID-файла пользователя. Парольный файл может быть создан программой IDMNG.EXE.

Если четвертый параметр отсутствует, программа запрашивает пароль защиты ID-файла интерактивно.

Возвращаемые программой FIXINT коды ошибок



0=OK – успешное завершение подписи файла;

1=MEMALLOCERROR – ошибка выделения памяти;

2=IDNOTACCESSIBLE – ошибка открытия ID-файла;

3=IDREADERROR – ошибка чтения ID-файла;

8=STATUSFAULT – некорректный статус класса - ошибка приложения;

9=IDSTRUCTWRONG – некорректная структура ID-файла;

11=IDINTEGRWRONG – нарушена целостность ID-файла;

13=IDPASSWRONG – неверный пароль доступа к ID-файлу;

23=DATAFILEREADERROR – ошибка чтения файла данных;

24=ZERODATALENGTH – файл данных имеет нулевую длину;

26=DATAFILEOPENERROR – ошибка открытия файла данных;

64=SIGNFILEOPENERROR – ошибка открытия файла подписи;

65=SIGNFILEWRITEERROR – ошибка записи файла подписи;

67=PASSWFILEOPENERROR – ошибка открытия файла пароля;

68=PASSWFILEREADERROR – ошибка чтения файла пароля;

69=COMSTRINGWRONGFORMAT – неверный формат командной строки;

77=SIGNINGERROR – ошибка выполнения процедуры подписывания;

80=IDPARMSNOTSUPPORTED – неподдерживаемые криптографические параметры ID-файла;

81=IDINITERROR – ошибка инициализации ID-структуры;

106=PASSWMASKINTEGRWRONG – нарушена целостность парольного файла;

108=PASSWFILESTRUCTWRONG – некорректная структура парольного файла.



Формат командной строки для вызова программы tstint



TSTINT <имя проверяемого файла> <имя файла подписи> <имя файла базы самоподписанных сертификатов> <имя файла базы отозванных сертификатов>

Возвращаемые программой TSTINT коды ошибок:

0=OK – успешное (положительное) завершение проверки подписи файла;

1=MEMALLOCERROR – ошибка выделения памяти;

8=STATUSFAULT – некорректный статус класса - ошибка приложения;

23=DATAFILEREADERROR – ошибка чтения файла данных;

24=ZERODATALENGTH – файл данных имеет нулевую длину;

26=DATAFILEOPENERROR – ошибка открытия файла данных;

55=PKISINBLACKLOG – автор подписи присутствует в «черном списке» отозванных сертификатов;

64=SIGNFILEOPENERROR – ошибка открытия файла подписи;

67=SIGNFILEREADERROR – ошибка чтения файла подписи;

69=COMSTRINGWRONGFORMAT – неверный формат командной строки;

70=SIGNFILESTRUCTWRONG – некорректная структура файла подписи;

71=WRONGSIGN – нарушена целостность подписи;

72=WRONGDATAORSIGN – нарушена целостность данных или подписи;

78=TESTINGSIGNERROR – ошибка выполнения процедуры проверки подписи;

82=SIGNFILEOUTCERT – файл подписи не имеет сертификатов;

83=NOSIGNS – подпись отсутствует;

84=SUSPICIOUSTIMESTAMP – подозрительные дата и время подписи;

91=SIGNSTRUCTWRONG – некорректная структура подписи;

92=SIGNCRSTYPEWRONG – неподдерживаемые криптографические параметры подписи;

95=VALIDCERTNOTFOUND – не найдено ни одного действительного сертификата в файле подписи.



Программное обеспечение применяемых в системе сопровождения ПО средств контроля целостности (программы fixint, tstint, idmng.exe, файл базы доверенных сертификатов mebius.acb с самоподписанным сертификатом главного сертификатора ООО «МЕБИУС-КОМ», и файл «черного списка» - базы отозванных сертификатов mebius.blb) включено в состав тиражируемых инструментальных средств сопровождения.

В соответствии с требованиями нормативных документов Банка России, при передаче разработчиком дистрибутивов и ПМ на объекты сопровождения по телекоммуникационной системе РЕМАРТ, они подвергаются дополнительной защите с помощью специального архиватора электронных документов САЭД. С этой целью у разработчика ПО на рабочем месте оператора РЕМАРТ оборудован абонентский пункт специального абонента САЭД; для взаимодействия разработчика ПО с объектами сопровождения ПО используются два персональных идентификатора абонентов (ПИА): MEBIUSCB («МЕБИУС-КОМ» - разработчик ПО для ЦБ РФ) и CBMEBIUS (ЦБ РФ - получатель ПО от «МЕБИУС-КОМ»), предоставляемых ЦБ РФ. ПИА MEBIUSCB предоставлен только «МЕБИУС-КОМ», а ПИА CBMEBIUS предоставляется всем первичным объектам сопровождения ТПК «РАБИС-НП».

Сопровождение программного обеспечения ПК ЦОИ «РАБИС-НП» (для ОС UNIX), осуществляется по одноуровневой схеме, охватывающей первичные объекты сопровождения (региональные центры информатизации территориальных управлений Банка России). Сопровождение программного обеспечения ПК РКЦ «РАБИС-НП» (для ОС Windows) осуществляется по двухуровневой схеме, охватывающей как первичные объекты сопровождения, так и вторичные объекты сопровождения (РКЦ, ГРКЦ, ТУ). Разработчик ТПК «РАБИС-НП» обеспечивает целостность дистрибутивов и ПМ, используемых первичными объектами сопровождения. Настоятельно рекомендуется использование тех же средств обеспечения целостности дистрибутивов и ПМ (включенных в технологический инструментарий сопровождения ТПК) и на втором уровне системы сопровождения.

4.2. Защита подсистем сопровождения ТПК «РАБИС-НП»

Защита технологических и тестовых подсистем сопровождения ТПК «РАБИС-НП» должна обеспечиваться в первую очередь с помощью организационно-технических мер, направленных на максимальное ограничение доступа к этим подсистемам. Вычислительные средства этих подсистем должны размещаться в отдельных сегментах локальной сети, защищаемых с помощью межсетевых экранов, и использоваться исключительно по своему прямому назначению. Работа с этими подсистемами должна производиться ограниченным кругом сотрудников службы информатизации, непосредственно отвечающих за сопровождение программного обеспечения. Разработчики программного обеспечения или пользователи рабочих подсистем РАБИС-НП не должны иметь доступа к технологическим и тестовым подсистемам сопровождения ТПК «РАБИС-НП». Пользователи технологических и тестовых подсистем сопровождения и разработчики программного обеспечения не должны иметь доступа к рабочим подсистемам РАБИС-НП.

5.  ПРИКЛАДНЫЕ СРЕДСТВА ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ В ПОДСИСТЕМАХ УБР, ТУ, ОИТУ РАБИС-НП

5.1. Порядок администрирования АРМ и пользователей

Создание АРМ и «заведение» пользователей в подсистемах УБР, ТУ и ОИТУ КЦОИ РАБИС-НП требует согласованных действий администраторов различных уровней (операционной системы сервера УБР, СЗИ НСД, транспортной станции УТП, прикладного программного комплекса, ключевой системы средств ЭЦП/КА и т.д.).

АРМ администратора ПО, АРМ администратора информационной безопасности и АРМ оператора ЛТС являются системными: присутствуют в каждой подсистеме сразу после её инсталляции, и не могут быть из неё удалены. Для выполнения первоначальной настройки подсистемы после установки ПО, а также регистрации персональных учетных записей реальных администраторов ПО и администраторов информационной безопасности подсистемы – в подсистеме предусмотрены две системных учетных записи: «xpress» – администратора ПО, и «security» – администратора информационной безопасности. Эти учетные записи подсистемы также не могут быть удалены, однако их использование должно ограничиваться первоначальной настройкой комплекса и нештатными ситуациями, в которых «вход» или работа с использованием персональных пользовательских учетных записей оказываются невозможными.

АРМ оператора сервера доступа также является системным для подсистемы ОИТУ КЦОИ. Установка сервера доступа подсистемы ОИТУ является сервером этой подсистемы. Работа на АРМ оператора сервера доступа выполняется с консоли установки сервера доступа.

Остальные АРМ подсистем УБР, ТУ и ОИТУ КЦОИ конфигурируются администраторами ПО подсистемы из имеющихся в составе ПК РКЦ РАБИС-НП программ («задач», функций). Администраторы ПО выполняют также настройку параметров подсистемы и применение пакетов модификации программного обеспечения ПК РКЦ на сервере подсистемы.

Регистрация пользователей подсистем выполняется администраторами информационной безопасности. Регистрируемый пользователь закрепляется за одним из предварительно сконфигурированных в подсистеме АРМ и ему назначается набор прикладных ролей (категорий), в соответствии с выполняемыми обязанностями по штатному расписанию учреждения.

Для АРМ с целью выгрузки копий ЭС из архивов ЭС для разбора конфликтных ситуаций технически необходимо наличие сменных носителей информации. В качестве сменных носителей информации для АРМ рекомендуется использование floppy-дисков (ГМД).

Регистрация пользователя выполняется в два этапа. На этапе предварительной регистрации производится ввод первичных атрибутов регистрируемого пользователя, закрепление его за конкретным АРМ, назначение ролей и распечатка предписаний: системному администратору сервера подсистемы, администратору транспортной станции УТП, администратору ключевой системы ЭЦП/КА, администратору информационной безопасности ТЦОИ - на регистрацию пользователя в подсистемах их сферы ответственности. После получения подтверждений о выполнении администраторами смежных подсистем предписанных действий, администратор ИБ выполняет окончательную регистрацию пользователя с предоставлением возможности работы на АРМ подсистемы.

После завершения регистрации пользователя, администратор информационной безопасности сообщает ему первоначальные пароли: для входа в операционную систему сервера УБР и для входа в АРМ подсистемы, предупреждая пользователя о том, что программное обеспечение АРМ потребует смены пароля при первом входе в АРМ.

Если пользователь забыл свой пароль для входа в АРМ, он должен обратиться к администратору информационной безопасности, который может установить для него признак аннулирования забытого пароля. После установки этого признака пароль пользователя совпадает с его идентификатором, но при первой же попытке входа пользователя в АРМ с таким паролем будет вызвана процедура принудительной смены пароля до загрузки главного меню АРМ.

5.2. Реализация разграничения доступа пользователей к объектам подсистем УБР, ТУ и ОИТУ КЦОИ

Субъектами доступа к объектам подсистем УБР, ТУ и ОИТУ КЦОИ РАБИС-НП выступают ее пользователи.

Важнейшими типами объектов разграничения доступа в подсистемах УБР РАБИС-НП являются:

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

–       объекты (каталоги и файлы), управляемые операционной системой сервера подсистемы УБР;

–       АРМ подсистемы;

–       функции АРМ;

–       объекты баз данных подсистемы;

–       запросы (электронные сообщения) в КЦОИ.

Разграничение доступа пользователей к объектам рабочих станций реализуется СЗИ НСД, функционирующими на рабочих станциях пользователей.

Разграничение доступа пользователей к объектам серверов подсистем реализуется прикладными средствами ТПК РАБИС-НП, средствами разграничения доступа операционной системы и СУБД.

Для каждого пользователя подсистемы в файловой системе сервера подсистемы создается индивидуальный каталог (%pathxpress%\home\%username%\, где %username% – идентификатор пользователя) для размещения временных файлов данных.

Разграничение доступа пользователей к файловым данным должно обеспечиваться средствами разграничения доступа для пользователей и групп пользователей операционной системы WindowsNT/2000/2003 сервера подсистемы. На сервере должна использоваться файловая система NTFS. Владельцем всех объектов файловой структуры каталогов с прикладным программным обеспечением ПК РКЦ (с правами доступа «Full Control» к этим объектам) должен быть системный администратор Windows. В операционной системе сервера создаются группы пользователей «mebius» (группа пользователей РАБИС-НП), «softadms» (группа пользователей – администраторов программного обеспечения подсистемы) и «secadms» (группа пользователей – администраторов информационной безопасности подсистемы). Все пользователи регистрируются в операционной системе сервера под персональными идентификаторами и включаются в указанные группы пользователей в соответствии со своими функциональными обязанностями.

Для запуска прикладных сервисов подсистемы (сервиса регистрационного журнала, сервиса имен, сервиса уникальных идентификаторов и т.д.), в операционной системе сервера подсистемы дополнительно регистрируется отдельная учётная запись специального пользователя «mservice», включаемая в группу пользователей «mebius». Прикладные сервисы ПК РКЦ РАБИС-НП функционируют от имени и с полномочиями пользователя «mservice». Для него должен быть также создан отдельный home- каталог (%pathxpress%\home\mservice\).

По завершении установки и настройки программного обеспечения ПК РКЦ на сервере учреждения администратор операционной системы сервера должен установить и в дальнейшем поддерживать (в процессе сопровождения ПО) атрибуты разграничения доступа к объектам файловой структуры ПК РКЦ

На прикладном уровне дополнительно обеспечивается разграничение доступа пользователей к АРМ и функциям АРМ (включая создание ЭС- запросов к КЦОИ). Для упрощения администрирования полномочий пользователей, в подсистеме УБР используется механизм назначения пользователям типовых категорий (ролей). В настоящее время используются следующие типовые категории пользователей подсистем УБР РАБИС-НП:

А) для всех подсистем (РКЦ, ГРКЦ, ТУ, ОИТУ КЦОИ):

–       «Пользователь РАБИС-НП»;

–       «Администратор ПО»;

–       «Администратор ИБ»;

–       «Оператор ЛТС»;

–       «Администратор подсистемы»;

–       «Исполнитель по расчетам с авизо»;

Б) для подсистем РКЦ и ГРКЦ:

–       «Оператор ввода ЭПД» (ответисполнитель);

–       «Контролер ввода ЭПД»;

–       «Администратор операционного отдела»;

В) для подсистемы ГРКЦ:

–       «Ответисполнитель по МЭР»;

Г) для подсистемы ТУ:

–       «Исполнитель ИАС»;

Д) для подсистемы ОИТУ КЦОИ:

–       «Оператор контура обработки» (в настоящее время эта категория назначается операторам сервера доступа);

–       «Оператор контура контроля» (в настоящее время эта категория назначается операторам АРМ контролера ЭС).

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

Разграничение доступа к функциям АРМ пользователя на основе категорий (ролей) пользователя реализовано следующим образом:

–       разработчиком ТПК «РАБИС-НП» поддерживается системный справочник функций («задач») ПК «РКЦ РАБИС-НП», в котором для каждой функции определены перечни подсистем и категорий пользователей, для которых эти функции вправе выполняться;

–       состав функций, доступных из главного меню АРМ пользователя, конфигурируется администраторами ПО подсистемы при настройке АРМ;

–       при регистрации пользователя подсистемы администратор информационной безопасности закрепляет его за конкретным (предварительно сконфигурированным администратором ПО) АРМ, и назначает этому пользователю одну или несколько категорий;

–       при запуске АРМ, организующая программа (xpress.exe) выполняет аутентификацию пользователя (по имени и паролю), определяет пользователя и закрепленный за ним АРМ, набор функций главного меню АРМ и набор категорий, назначенных данному пользователю. Перед выводом главного меню АРМ пользователю, организующая программа выполняет по системному справочнику функций проверку соответствия функций, включенных в состав АРМ, назначенным категориям пользователя. Функций, для выполнения которых у пользователя отсутствуют необходимые категории, показываются в меню АРМ как неактивные, и их запуск пользователем блокируется.

Пользовательские программы АРМ работают с серверной (общей для всей подсистемы) и пользовательскими базами данных, функционирующими на сервере подсистемы под управлением СУБД MS SQL.

Разграничение доступа при подключении пользовательских процессов АРМ к базам данных подсистемы УБР обеспечивается штатными средствами парольной аутентификации СУБД. Для предотвращения возможности подключения пользователей к базам данных в обход приложений ПК РКЦ РАБИС-НП, реальный пароль для подключения пользователя подсистемы к СУБД вычисляется приложением по определенному алгоритму из двух частей. Первая часть пароля (пользовательская) соответствует значению пароля пользователя для входа в АРМ. Другая часть пароля (системная) представляет собой псевдослучайную маску, хранимую и предоставляемую приложениям РАБИС-НП сервисом аутентификации.

Для разграничения доступа пользователей подсистемы к транспортным сервисам УТП, при конфигурировании транспортного канала подключения пользователя «оператор ЛТС» к транспортной станции УТП должны использоваться средства взаимной аутентификации клиента и транспортной станции УТП, в соответствии с документацией на УТП БР.

5.3. Реализация средств парольной аутентификации пользователей и разграничения их доступа к функциям АРМ

Вход пользователя в АРМ подсистемы УБР РАБИС-НП производится с помощью bat- файла запуска АРМ, выполняющего:

–     формирование необходимого окружения;

–     вызов организующей программы АРМ xpress.exe.

Формирование окружения состоит в присвоении значений необходимым переменным окружения.

Работа средств парольной аутентификации пользователей подсистемы УБР РАБИС-НП основана на использовании прикладного сервиса аутентификации в качестве единственного средства получения прикладными программами АРМ необходимых для их функционирования конфигурационных данных о подсистеме и пользователе. Сервис аутентификации (исполняемый модуль 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 описывается имя серверной установки и номер порта, на которых функционирует сервис регистрации подсистемы.

Отдельная функция проверки работоспособности сервиса регистрации включена в состав АРМ администратора информационной безопасности.

Работа с регистрационным журналом осуществляется на АРМ администратора информационной безопасности подсистемы.

В процессе загрузки файла регистрационного журнала на просмотр выполняется контроль его целостности по контрольным суммам записей. Результат контроля целостности регистрационного журнала выводится на экран («Регистрационный журнал целостен!», или «Целостность регистрационного журнала нарушена, начиная с записи №ХХХ»).

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

В качестве сервисных функций администратора информационной безопасности при работе с регистрационными журналами предусмотрены:

–       проверка работоспособности сервера регистрации;

–       очистка оперативного регистрационного журнала с переносом его данных в файл архивного регистрационного журнала;

–       загрузка на просмотр файла архивного регистрационного журнала.

–       контроль целостности регистрационного журнала.

Наряду с ведением прикладного регистрационного журнала, сервис регистрации может выполнять параллельную запись прикладных событий РАБИС-НП в журнал ApplicationLog операционной системы сервера подсистемы (передается текстовая строка в формате регистрационной записи РАБИС-НП, но без контрольной суммы). Необходимость и степень детальности регистрации в системном журнале операционной системы конфигурируются при настройке сервиса регистрации.

5.5. Средства контроля целостности прикладного программного обеспечения подсистем в процессе сопровождения. Паспорта прикладного программного обеспечения АРМ

Концепция контроля целостности прикладного программного обеспечения подсистем УБР, ТУ, ТЦОИ и ОИТУ КЦОИ в процессе сопровождения ТПК РАБИС-НП основана на следующих принципах:

–       разработчик ТПК РАБИС-НП предоставляет сведения о составе и характеристиках тиражируемых файлов ПК РКЦ РАБИС-НП непосредственно в составе дистрибутивных материалов и пакетов модификаций (в защищенном технологической подписью разработчика виде);

–       штатный инструментарий, используемый администраторами программного обеспечения для модификации программных модулей ПК РКЦ РАБИС-НП, обеспечивает ведение файла контрольного списка (эталонного состояния) исполняемых и ресурсных модулей подсистемы, защищаемого подписью (КА) администратора программного обеспечения;

–       штатный инструментарий сопровождения ПК РКЦ РАБИС-НП обеспечивает контроль происхождения и целостности новых версий модифицируемых в процессе сопровождения модулей программного обеспечения по контрольным данным разработчика, и соответствующую актуализацию контрольного списка исполняемых и ресурсных модулей подсистем;

–       администраторы программного обеспечения подсистем ответственны за использование штатных средств сопровождения ПК РКЦ и, соответственно, за состояние исполняемых и ресурсных модулей ПК РКЦ РАБИС-НП подсистем, фиксируемое в контрольном списке, защищаемом их подписями (КА);

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

Дистрибутивные материалы ПК РКЦ РАБИС-НП, помимо собственно инсталляционных модулей, включают инструментарий контроля целостности, а также контрольный файл distr_files_V.lst (V – номер версии дистрибутива). Контрольный файл содержит описание состава и контрольных характеристик, исполняемых и ресурсных файлов, которые должны быть получены в результате корректной инсталляции дистрибутивных материалов ПК РКЦ РАБИС-НП. Контрольный файл защищен технологической подписью (в отдельном файле distr_files_V.sgn) разработчика ПК РКЦ (средства технологической подписи, используемые для сопровождения ТПК РАБИС-НП).

В процессе инсталляции сервера подсистемы из дистрибутивных материалов ПК РКЦ РАБИС-НП формируется ядро исполняемой системы ПК РКЦ РАБИС-НП («дерево» подкаталогов и файлов от «корневого» каталога %kernel%) и технологический инструментарий сопровождения ПК РКЦ (в каталоге tools). На завершающем этапе инсталляции выполняется проверка целостности контрольного файла, и целостности сформированных файлов ядра исполняемой системы и инструментария сопровождения по контрольному файлу. Сам контрольный файл дистрибутива вместе с файлом его технологической подписи сохраняются для дальнейшего использования в каталоге %kernel%/control_files/.

Для первого (после установки ПО сервера подсистемы) формирования файла контрольного списка исполняемых и ресурсных модулей подсистемы, должны быть предварительно подготовлены следующие условия:

–       должна быть выполнена настройка подсистемы для работы со средствами подписи (КА), применяемыми для защиты электронных сообщений на региональном уровне;

–       в подсистеме должен быть зарегистрирован хотя бы один реальный пользователь - администратор ПО,

–       на рабочей станции администратора ПО должно быть установлено ПО средств подписи (КА), применяемых для защиты электронных сообщений на региональном уровне;

–       для администратора ПО должны быть настроены все необходимые параметры для работы с указанными средствами подписи (КА);

–       администратор ПО должен иметь личный ключ подписи (КА), а соответствующий ему открытый ключ (или сертификат открытого ключа) подписи (КА) должен быть включен, по крайней мере, в справочники открытых ключей (или сертификатов открытых ключей), используемые на рабочих станциях всех администраторов ПО и администраторов ИБ данной подсистемы.

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

Первое формирование файла контрольного списка исполняемых и ресурсных модулей подсистемы выполняется администратором ПО с помощью программы task835.exe «Применение пакетов модификации», в автоматическом (если программа самостоятельно может установить происхождение, корректность состава и целостность всех программных модулей), или «ручном» (с принятием администратором ПО решений для каждой обнаруживаемой проблемной ситуации) режимах. Сформированный файл контрольного списка исполняемых и ресурсных модулей подсистемы защищается подписью (КА) администратора ПО. Для защиты контрольного файла используются средства подписи (КА), применяемые для защиты электронных сообщений на региональном уровне. Сформированный и подписанный файл контрольного списка исполняемых и ресурсных модулей подсистемы kernel_files.lst размещается в каталоге %kernel%/control_files/. Там же сохраняется его резервная копия с именем kernel_files.cpy.

Пакеты модификации (ПМ) ПК РКЦ РАБИС-НП содержат описание состава модифицируемых программных модулей и важнейшие характеристики (версия, контрольные суммы и значения хэш-функций) их новых версий в мастер-файле ПМ. Каждый мастер файл ПМ защищен технологической подписью разработчика.

Применение пакетов модификаций ПК РКЦ РАБИС-НП в подсистеме выполняется администраторами ПО с использованием штатного инструментария сопровождения ПО - программы task835.ovl, и сопровождается контролем целостности мастер-файла ПМ по технологической подписи и контролем целостности подготовленных к замене новых версий программных модулей по контрольным характеристикам мастер- файла ПМ. Только при успешном результате контроля целостности выполняется окончательная замена модифицируемых модулей, актуализация контрольного файла и его подпись администратором ПО, выполняющим применение ПМ.

Откаты пакетов модификации, выполняемые администраторами ПО в некоторых ситуациях с помощью программы task835.ovl, также сопровождаются контролем целостности восстанавливаемых модулей прежних версий (замененные в процессе сопровождения ПО программные модули прежних версий сохраняются в каталоге %kernel%/save/»), и актуализацией контрольного файла подсистемы.

Контроль целостности исполняемых и ресурсных модулей подсистемы может выполняться администраторами ПО и администраторами ИБ с помощью программы task834.ovl «Контроль целостности исполняемой системы», включаемой в состав их АРМ. Для обеспечения возможности проверки подписи (КА) файла контрольного списка исполняемых и ресурсных модулей подсистемы УБР, для пользователей, выполняющих указанную программу, в подсистеме должны быть настроены все необходимые параметры для работы со средствами подписи (КА).

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

Пользователям подсистемы, обладающим ролью «администратор ПО», программа контроля целостности task834.ovl позволяет, при необходимости, дополнительно выполнять корректировку контрольного файла подсистемы с добавлением новых или удалением существующих описаний программных модулей.

Пользователи подсистемы, обладающие ролью «администратор информационной безопасности», имеют возможность из той же программы контроля целостности (task834.ovl) формировать в доступном только для них каталоге (%xpress%/integrty/) отдельный и защищаемый их подписями контрольный файл (kernel.fix). С помощью этого контрольного файла администраторы ИБ могут выполнять независимый от действий администраторов ПО подсистемы контроль целостности ядра исполняемых и ресурсных модулей подсистемы. Процедуры контроля целостности должны выполняться администраторами информационной безопасности по регламенту, а также после проведении плановых модификаций ПК РКЦ РАБИС-НП администраторами ПО. После применения администраторами ПО пакетов модификаций, администратор информационной безопасности должен выполнить контроль целостности и сравнить полученный протокол контроля целостности с протоколом изменений ПО, формируемым администратором ПО при выполнении функции «Применение пакетов модификаций» (программа task835.ovl). В случае их полного соответствия, администратором ИБ может быть выполнена процедура фиксации модифицированного состояния ПО, в противном случае должно инициироваться служебное расследование причин несанкционированного нарушения целостности.

Имеющиеся в составе АРМ администраторов ПО подсистем средства автоматизированного формирования паспортов ПО АРМ позволяют формировать и выводить на печать паспорта ПО для каждого АРМ подсистемы, содержащие актуальные данные о составе и контрольных характеристиках используемых модулей прикладного ПО ПК РКЦ РАБИС-НП.

Поскольку в формируемые средствами АРМ администратора ПО паспорта включаются только прикладные модули ПК РКЦ РАБИС-НП, для контроля целостности и ведения паспортов остального программного обеспечения, установленного локально на рабочих станциях АРМ, рекомендуется дополнительное использование типового программного комплекса «Паспорт АРМ» разработки ГУ Банка России по Тульской области.

6.  Общие принципы защиты электронного документооборота РАБИС-НП

Подсистема ОИТУ КЦОИ вместе с подсистемой «сервер доступа ТУ» может рассматриваться как «черный ящик», организованный по принципам электронного документооборота. Этот «черный ящик» ведет свою внутреннюю учетно-операционную информационную базу, но «общение» этого «черного ящика» со всеми потребителями его услуг организовано исключительно посредством обмена электронными документами (в качестве которых выступают файлы и электронные сообщения поддерживаемых интерфейсов обмена).

Защита файлов и сообщений, обеспечивающая возможность их аутентификации (контроля целостности и происхождения) и придающая им статус электронного документа обеспечивается средствами электронной цифровой подписи (ЭЦП/КА/ЗК).

Электронные сообщения РАБИС-НП подразделяются на две категории:

–       Электронные сообщения (документы), не требующие дополнительного технологического контроля другим исполнителем (контролером) или контуром контроля (ЭСИС/ЭСИД);

–       Электронные сообщения (документы), требующие дополнительного технологического контроля другим исполнителем (контролером) или контуром контроля; успешный результат контроля такого ЭС/ЭД подтверждается наличием подписи контролера или контура контроля (ЭПС/ЭПД и ЭСИС/ЭСИД-подтверждения по операциям, изменяющим состояние банковских счетов).

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

Средства электронной цифровой подписи (ЭЦП/КА/ЗК) в РАБИС-НП являются основным средством защиты электронных сообщений РАБИС-НП.

В настоящее время все функциональные компоненты подсистем ОИТУ КЦОИ, выполняющие защиту и аутентификацию электронных сообщений, реализованы для работы на отдельных Intel- установках под управлением ОС Windows.

Для защиты электронных сообщений и файлов ВЭР на региональном уровне, уровне КЦОИ и уровне АС «БЭСП» в ТПК РАБИС-НП используются программные библиотеки СКАД «Сигнатура», разработки ООО «Валидата». При этом должны применяться правила заполнения сертификатов ключей для системы ВЭР РАБИС-НП и для системы «БЭСП» соответственно.

Для защиты файлов ЭС системы МЭР используются программные библиотеки СКАД «Сигнатура», разработки ООО «Валидата», с использованием ключей и справочников сертификатов для системы МЭР, управляемых ГЦКИ ГУБиЗИ Банка России.

На серверах доступа и АРМ контролера ЭС подсистем ОИТУ КЦОИ вместо программных библиотек СКАД «Сигнатура» возможно применение программных библиотек и криптосерверной подсистемы СКЗИ «Янтарь АСБР», разработки ООО «Валидата».

Структура региональной ключевой системы ЭЦП/КА/ЗК для РАБИС-НП предполагает наличие ключей подписи (не считая резервных) для следующих субъектов:

–       Для каждого пользователя каждой из подсистем УБР (РКЦ, ГРКЦ) и ТУ региона;

–       Для каждого регионального участника электронного обмена;

–       Для контуров обработки и контуров контроля каждого полевого учреждения региона;

–       Для контура обработки и контура контроля сервера доступа ТУ.

Структура ключевой системы КА/ЗК уровня КЦОИ для РАБИС-НП предполагает наличие ключей для следующих субъектов:

–       Для контура обработки и контура контроля КЦОИ;

–       Для пользователей АРМ подсистем ОИТУ КЦОИ (взаимодействующих с подсистемой ОИТУ обменом сообщениями);

–       Для контуров обработки и контуров контроля каждого из серверов доступа ТУ.

Структура ключевой системы КА/ЗК АС «БЭСП» для узлов РАБИС-НП предполагает наличие ключей для следующих субъектов:

–       Для контура обработки и контура контроля КЦОИ;

–       Для контуров обработки и контуров контроля каждого из серверов доступа ТУ.

Создание пользовательских ключей КА/ЗК должно выполняться пользователями, в присутствии администратора информационной безопасности, на специальных АРМ ключевой системы. При первом создании пользовательского ключа должен использоваться сертификат регистрации, полученный из Центра регистрации ключевой системы (ЦУКС). После создания, открытые ключи пользователей должны направляться в составе запросов на сертификацию в Центр регистрации (ЦУКС).

Справочники сертификатов, устанавливаемые на рабочие станции и сервера подсистем РАБИС-НП, конфигурируются администраторами информационной безопасности подсистем во взаимодействии с ЦУКС.

Правила применения сертификатов ключей подписи СКАД «Сигнатура» в системе внутрирегиональных электронных расчетов РАБИС-НП приведены в документе МБТД.001.ИБ.02.2.М «РАБИС-НП. Правила применения сертификатов СКАД «Сигнатура» в системе внутрирегиональных электронных расчетов».

Защита и аутентификация ЭС интерфейсов обмена ПУР и КЦОИ с ЦОиР АС «БЭСП» при использовании СКАД «Сигнатура» обеспечивается при соблюдении в ключевой системе АС «БЭСП» формата сертификатов ключей, установленного документом МБТД.002.ИБ.02.2.М «Система «БЭСП». Правила заполнения полей сертификатов СКАД «Сигнатура» и применения сертификатов СКАД «Сигнатура»».

Ключевыми системой подписи (ЭЦП, КА, ЗК) СКАД «Сигнатура» регионального уровня управляют Центры управления ключевыми системами (ЦУКС) УБиЗИ территориальных Управлений Банка России. Ключевой системой подписи (КА, ЗК) СКАД «Сигнатура» уровня КЦОИ управляет ЦУКС территориального Управления Банка России, эксплуатирующего КЦОИ (ГУ Банка России по Нижегородской области). Ключевой системой АС «БЭСП» управляет ГЦКИ ГУБиЗИ Банка России.

Необходимыми компонентами любой системы электронного документооборота являются архивы электронных документов. В РАБИС-НП ведение оперативных архивов электронных документов предусмотрено во всех подсистемах (подсистемах УБР и ТУ, подсистемах «Сервер доступа ТУ» и подсистемах ОИТУ КЦОИ). Архивные подсистемы долговременного хранения ЭС для регламентного переноса в них электронных документов из оперативных архивов подсистем РАБИС-НП на долговременное хранение должны быть организованы в подсистемах ТЦОИ и подсистемах ОИТУ КЦОИ.

7.  ТРЕБОВАНИЯ К АДМИНИСТРАТИВНЫМ И ОРГАНИЗАЦИОННО-ТЕХНИЧЕСКИМ МЕРАМ ЗАЩИТЫ НА ОБЪЕКТАХ АВТОМАТИЗАЦИИ

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

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

–       помещения должны быть оборудованы сигнализацией, и по окончании рабочего дня опечатываться и сдаваться под охрану;

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

Право доступа в выделенные помещения должно предоставляться только лицам, непосредственно участвующим в технологическом процессе. Для обеспечения данного требования составляются списки сотрудников, имеющих право входа в данное помещение, утверждаемые руководителем учреждения. Лица, не включенные в данный список, могут находиться в помещении только в присутствии, по крайней мере, одного из сотрудников учреждения, включенных в список. Обслуживающий персонал (уборщицы, электрики и т.п.) должны допускаться в помещения только для выполнения их непосредственных обязанностей, в сопровождении лица, ответственного за помещение.

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

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

Исходные тексты программного обеспечения банковской автоматизированной системы не должны быть доступны пользователям системы. Для обеспечения целостности программного обеспечения при передаче в Фонд алгоритмов и программ Банка России, а также, при тиражировании регионам – пользователям, должны использоваться средства защиты информации, рекомендованные ГУБиЗИ Банка России.

Для каждого автоматизированного рабочего места автоматизированной системы, должен вестись паспорт программного обеспечения АРМ, оформленный в соответствии с «Временным требованиям по обеспечению безопасности технологий обработки электронных платежных документов в системе Центрального банка Российской Федерации» от 03.0497 г. №60.

Операторы АРМ обязаны следить за тем, чтобы в паспорт заносились сведения о всех изменениях, вносимых в аппаратное или программное обеспечение АРМ (записи должны производиться лицом, осуществляющим изменения).

Каждое автоматизированное рабочее место, подключенное к автоматизированной расчетной системе, должно быть обеспечено инструктивными и методическими материалами, содержащими:

–       руководство пользователя АРМ;

–       описание технологии работы на АРМ;

–       описание работы со средствами защиты ПЭВМ АРМ от НСД;

–       порядок проведения антивирусного контроля и профилактики на АРМ;

–       порядок использования криптографических средств и ключевых носителей (если данный АРМ предполагает использование средств криптографической защиты информации).

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

На объекте автоматизации должна быть разработана следующая нормативно-методическая документация:

–       положение о порядке обработки и контроля информации при совершении электронных платежей;

–       положение по обеспечению безопасности электронных платежей;

–       положение о совершении электронного обмена платежными документами между учреждениями ЦБ РФ и кредитными организациями;

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

–       методические материалы по управлению ключевой системой используемых в региональной системе ЦБ РФ средств криптографической защиты информации;

–       инструктивные материалы по организации работы со средствами криптографической защиты информации и носителями ключевой информации в учреждениях ЦБ РФ региона;

–       инструктивные материалы по организации работы со средствами защиты информации от НСД и средствами парольной защиты в учреждениях ЦБ РФ региона;

–       положение о порядке восстановления банковской автоматизированной системы после сбоев и отказов;

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

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

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




ЗАКЛЮЧЕНИЕ
Из рассмотренного становится очевидно, что обеспечение информационной безопасности является комплексной задачей. Это обусловлено тем, что информационная среда является сложным многоплановым механизмом, в котором действуют такие компоненты, как электронное оборудование, программное обеспечение, персонал.

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




СПИСОК ЛИТЕРАТУРЫ
1.       РЕГИОНАЛЬНАЯ АВТОМАТИЗИРОВАННАЯ БАНКОВСКАЯ ИНФОРМАЦИОННАЯ СИСТЕМА («РАБИС-НП»), Описание подсистемы информационной безопасности МБТД.001.ИБ.01.2.М Листов 193




ПРИЛОЖЕНИЕ 1



ПЕРЕЧЕНЬ ИСПОЛНИМЫХ МОДУЛЕЙ ПРИКЛАДНОГО И СИСТЕМНОГО ПО ПК РКЦ РАБИС-НП ДЛЯ ПРЕДВАРИТЕЛЬНОЙ НАСТРОЙКИ СЗИ НСД С ЦЕЛЬЮ ОРГАНИЗАЦИИ ЗАМКНУТОЙ ПРОГРАММНОЙ СРЕДЫ
Перечень исполнимых модулей функционирующих под управлением операционной системы Windows 2000/2003 на серверах подсистем РАБИС НП приведен в таблице 1.




Таблица 1

А. Прикладные исполнимые модули ПК РКЦ РАБИС-НП (%pathkernel%\)
omniNamesSvc.exe Srvany.exe Xpress.exe Task202.exe Task203.exe Task204.exe Task205.exe	Task296.exe Task297.exe Task807.ovl task808.ovl task873.exe task842.exe task845.exe		task846.exe task847.exe task873.ovl task999s.exe task999p.exe task7000.exe UniqIdset.exe
Б. Исполнимые модули динамических библиотек, поставляемые в составе ПК РКЦ РАБИС-НП (%pathkernel%\BPLDLL\)
Adm850t.dll Authclient.dll authmodule.dll bcbsmp50.bpl boom10_mtc.dll borlndmm.dll cc3250mt.dll cfgmodule.dll clstools.dll CM_LIBW.dll Coom12_mtc.dll Corbasensors.dll cspmanager.dll cspproxy.dll cspsignatura.dll dllcache.dll dllcachelist.dll Evntview.dll Execcli.dll Ftplocal.dll Ftpmebius.dll ftpmodule.dll ftpwininet.dll hr.dll	inetsock.dll intconfig.dll iprof.dll MebiusControls2.bpl mebiusevents2.bpl moddict.dll omniDynamic3_rt.dll omniorb3_rt.dll omnithread_rt.dll proctun.dll qoom14_mtc.dll quest1_mtc.dll questvclado_mtc.dll questvclbde_mtc.dll rar.exe regdict.dll regview.dll regwrite.dll room610_mtc.dll rpctools.dll Sensorjrn.dll Sensorslot.dll Servtu.dll	Support.dll task850t.dll Thrguard.dll Thrguard_mtc.dll Toomco_mtc.dll Toomem_mtc.dll Toomim_mtc.dll Toomut_mtc.dll Toom_mtc.dll Toomvc_mtc.dll TUTIL32.DLL Tvcrypto.dll Types10_mtc.dll uniqid.dll vcl50.bpl vclado50.bpl vcldb50.bpl vclbde50.bpl vclx50.dll wboth.dll ylog_mtc.dll zlibc.dll
В. Исполнимые модули динамических библиотек операционной системы (WINNT\SYSTEM32\)
ntdll.dll USER32.dll KERNEL32.dll GDI32.dll Gds.dll ADVAPI32.dll RPCRT4.dll Msafd.dll MSVCRT.dll Samlib.dll SHELL32.dll	COMCTL32.dll WINMM.dll WINSPOOL.DRV WS2_32.dll WS2HELP.dll WSOCK32.dll MSVCIRT.dll MSVCRT40.dll VERSION.dll LZ32.dll oleaut32.dll	ole32.dll mpr.dll comdlg32.dll odbs32.dll odbcint.dll oledlg.dll ntlanman.dll netapi32.dll netui0.dll netui1.dll

Перечень исполнимых модулей функционирующих под управлением операционной системы Windows 98/2000/XP на рабочих станциях ПК РКЦ РАБИС-НП приведен в табл. 2.




Таблица 2