Требования по обеспечению информационной безопасности
|
Предложения участника конкурса
|
|
Подтверждаем («ДА»)
|
Не подтверждаем («НЕТ»)
|
Дополнительные условия
|
1. Администрирование
|
|
|
|
Система должна содержать подсистему администрирования, которая предназначена для обеспечения выполнения следующих функций:
|
|
|
|
обеспечение регламентных работ, предусмотренных эксплуатационной документацией на Систему и ее подсистемы;
|
|
|
|
разрешение проблем, возникающих при эксплуатации Системы и ее функциональных подсистем;
|
|
|
|
ликвидация нештатных ситуаций (инцидентов), возникающих при эксплуатации Системы и ее функциональных подсистем;
|
|
|
|
ликвидация последствий известных (выявленных при эксплуатации, но не устраненных) ошибок программного обеспечения Системы, связанных с функционированием Системы, ее подсистем и их взаимодействием;
|
|
|
|
мониторинг параметров функционирования Системы и ее подсистем;
|
|
|
|
процедуры управления функционированием Системы и ее подсистем;
|
|
|
|
просмотр журнала аудита;
|
|
|
|
ведение “Административного журнала”.
|
|
|
|
Должна быть исключена возможность доступа администратора к “боевым” паролям пользователей. Процедура сброса администратором пароля пользователя должна сопровождаться рядом организационных мероприятий.
|
|
|
|
Должна быть исключена возможность изменения (модификации) демо-данных (фамилия, имя, отчество) заведенных пользователей.
|
|
|
|
Реализация механизма администрирования должна исключать возможность выполнения администраторами прямого соединения с базой данных в обход подсистемы администрирования.
|
|
|
|
АРМ “Администрирования” должен:
|
|
|
|
Пользователи, не обладающие бизнес-ролями (Администратор, Оператор, Аудитор и пр.), не должны иметь возможность изменения бизнес-данных Системы.
|
|
|
|
2. Управление правами доступа
|
|
|
|
Реализация механизма управления правами доступа в Системе должна удовлетворять следующим требованиям:
|
|
|
|
механизм распределения прав доступа к функциям Системы должен позволять предоставление пользователям прав, минимально необходимых для выполнения их функциональных обязанностей;
|
|
|
|
механизм распределения прав доступа должен охватывать все операции пользователей над объектами системы. Все объекты системы и операции над ними должны охватываться механизмом распределения прав доступа;
|
|
|
|
механизм разграничения прав доступа должен обеспечивать возможность запуска сотрудником только разрешенных ему функций.
|
|
|
|
3. Механизмы идентификации и аутентификации
|
|
|
|
Реализация механизмов идентификации и аутентификации должна удовлетворять следующим требованиям:
|
|
|
|
доступ к информации и функциям Системы должен предоставляться пользователю только после предъявления уникального персонифицированного идентификатора (имени) пользователя и проведения процедуры аутентификации на основе некоторой вводимой пользователем информации (пароль, ключи);
|
|
|
|
должны быть обеспечены возможность определения авторства каждой операции в Системе и отсутствие неавторизованных операций на основе уникальных персонифицированных идентификаторов каждого пользователя, процедуры аутентификации и протоколирования действий пользователей в журналах аудита;
|
|
|
|
должны иметься развитая система управления аутентификационной информацией пользователей (паролями, ключами) и механизмы контроля за ее качеством и использованием, обладающие следующими характеристиками:
|
|
|
|
длина пароля не менее 6 символов;
|
|
|
|
периодическая принудительная смена паролей не реже, чем раз в месяц;
|
|
|
|
возможность установки администратором признака принудительной смены пароля пользователя при следующем входе пользователя в систему;
|
|
|
|
возможность самостоятельного изменения пользователями своего пароля в любое время;
|
|
|
|
предоставление доступа к информации при первом входе пользователя в Системе только после смены им пароля, установленного администратором, на его личный (“боевой”) пароль;
|
|
|
|
хранение парольной “истории” пользователя, т.е. списка контрольных значений (сумм) нескольких предыдущих паролей пользователя (рекомендуется хранить пять паролей), и невозможность при смене пароля выбора пароля из этого списка;
|
|
|
|
проводится анализ качества выбираемых пользователями паролей, либо система должна сама назначать пользователям легко запоминающиеся пароли с хорошими характеристиками;
|
|
|
|
при вводе пароля пользователем на запрос системы символы пароля на экране не отображаются (отображается только число введенных символов);
|
|
|
|
пароли передаются по каналу связи от клиента серверу по протоколу SSL
|
|
|
|
Взаимодействие со внешними системами должно поддерживать защиту интерфейсов взаимодействия с помощью технологии двухстороннего SSL (с контролем клиентского и серверного сертификата).
|
|
|
|
При взаимодействии со внешними системами должна поддерживаться возможность контроля доступа к собственным интерфейсам на уровне сервисов и конкретных операций, реализуемых сервисом.
|
|
|
|
4. Защита от НСД
|
|
|
|
При попытке подбора паролей при входе в Систему (неправильный набор пароля три раза подряд) система должна блокировать работу пользователя, и данное событие должно регистрироваться в журнале аудита
|
|
|
|
5. Аудит
|
|
|
|
В Системе должен быть реализован недоступный на редактирование администратору и пользователям механизм аудита.
|
|
|
|
Реализация механизма аудита должна удовлетворять следующим требованиям:
|
|
|
|
информация в журналах должна представляться в структурированном виде в терминах предметной области;
|
|
|
|
при протоколировании событий в журналах должно фиксироваться время прикладного сервера;
|
|
|
|
должна быть исключена возможность редактирования, отключения и удаления журнала аудита средствами системы;
|
|
|
|
должна быть исключена возможность очистки средствами системы журнала аудита до его архивирования или распечатки;
|
|
|
|
Должны быть предусмотрены средства АС с удобным пользовательским интерфейсом для просмотра и вывода на печать журнала аудита с фильтрацией по любой комбинации атрибутов регистрации (различным категориям пользователей или событиям, для просмотра могут быть доступны различные его подмножества).
|
|
|
|
В журнале аудита также должны протоколироваться следующие действия администратора системы и события безопасности:
|
|
|
|
создание нового пользователя (должны фиксироваться время создания и все атрибуты создаваемого пользователя);
|
|
|
|
назначение пользователю прав доступа к данным и функциям системы, а также изменение прав доступа (должны фиксироваться время события и полная информация по назначаемым или изменяемым правам);
|
|
|
|
блокирование пользователя (должны фиксироваться время блокирования и все атрибуты блокируемого пользователя);
|
|
|
|
входы/выходы пользователей в/из системы;
|
|
|
|
попытки совершения НСД;
|
|
|
|
использование специальных полномочий (редактирование информации в базе данных, изменение настроек и т.д.);
|
|
|
|
изменения параметров и системных настроек АБС с указанием старых и новых параметров и настроек;
|
|
|
|
отрицательные результаты проверок целостности данных в системе.
|
|
|
|
6. Web-приложения
|
|
|
|
Система должна быть защищена от наиболее распространенных типов атак на данный класс приложений (SQL-injection, cross-site scripting, buffer overflow и т.д.).
|
|
|
|
