Требования по обеспечению информационной безопасности к системе



Скачать 80.67 Kb.
Дата05.08.2018
Размер80.67 Kb.
#42502


Приложение 3

ТРЕБОВАНИЯ ПО ОБЕЧПЕЧЕНИЮ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ К СИСТЕМЕ АВТОМАЗИРОВАННОГО ФОРМИРОВАНИЯ КРЕДИТНОЙ ДОКУМЕНТАЦИИ В СБЕРБАНКЕ РОССИИ

Оглавление


Оглавление 2

1.Общие требования к системе 3

2.Требования к управления правами доступа 3

3.Требования к механизмам идентификации и аутентификации 4

4.Требования к защите от несанкционированного доступа 4

5.Требования к криптографической защите 5

6.Требования к аудиту 5

7.Требования к документации 7



8.Требования к реализации Web-приложении 7



  1. Общие требования к системе





  1. Возможность удаления пользователей из Системы путем перевода их в разряд заблокированных без возможности совершения операций под их именами и без возможности отмены этого статуса.

  2. Возможность блокирования работы отдельных пользователей с возможностью снятия блокировки:

  1. на некоторый промежуток времени;

  2. начиная с некоторого момента времени;

  3. автоматически после превышения задаваемого настройкой Системы периода неактивности пользователя (отсутствия успешных входов в Систему).

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

  2. Исключение возможности доступа администратора системы к “боевым” паролям пользователей.

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

  4. Отсутствие возможности выполнения администраторами прямого соединения с базой данных в обход подсистемы администрирования.

  5. Выполнение административных функций Системы, в том числе управление правами пользователей на прикладном уровне в виде отдельной роли.

  6. Территориальная распределенность Системы может потребовать реализации иерархического администрирования с возможностью делегирования прав нижестоящим администраторам.
  1. Требования к управления правами доступа


  1. Распределение прав доступа к функциям и экранам Системы (предоставление пользователям прав, минимально необходимых для выполнения их функциональных обязанностей).

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

  3. Наличие механизма разграничения прав доступа, реализованного на основе создания ролей в прикладной системе. Доступ к объектам Системы в явном виде разрешается или запрещается на основе атрибутов безопасности пользователя.

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

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


  1. Возможность предоставления пользователю закрепленных за ним прав доступа к информации, экранным формам и функциям Системы.

  2. Возможность регистрации действий пользователя средствами подсистемы аудита.

  3. Возможность предоставления пользователю доступа к информации, экранным формам и функциям Системы только после предъявления уникального персонифицированного идентификатора (имени) пользователя и проведения процедуры аутентификации на основе некоторой вводимой пользователем информации (пароль, ключи).

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

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

  1. длина пароля не менее восьми символов;

  2. периодическая принудительная смена паролей не реже, чем раз в месяц;

  3. возможность установки администратором признака принудительной смены пароля пользователя при следующем входе пользователя в Систему;

  4. возможность самостоятельного изменения пользователями своего пароля в любое время;

  5. автоматическая установка новому пользователю пароля, задаваемого администратором Системы;

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

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

  8. выполнение анализа качества выбираемых пользователями паролей;

  9. при вводе пароля пользователем на запрос Системы символы пароля на экране не отображаются (отображается только число введенных символов);

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

  11. перехваченная передаваемая по каналу связи аутентифицирующая информация не должна позволять осуществлять вход в Систему через прикладную систему.
  1. Требования к защите от несанкционированного доступа


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

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

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

  4. Обеспечение защиты от НСД рабочего места, оставленного пользователем без надзора во время работы банковских программ, с помощью программы “хранителя” экрана, активизирующейся через некоторый интервал неактивности пользователя или по нажатию “горячих” клавиш и требующей ввода пароля при попытке доступа в Систему.
  1. Требования к криптографической защите


  1. Возможность применения криптографических алгоритмов, отвечающих требованиям российских стандартов шифрования ГОСТ 28147-89 и ЭЦП ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94.

  2. Возможность применения процедур электронной цифровой подписи (ЭЦП) с использованием СКЗИ «Бикрипт-КСБ».

  3. Возможность подписывать ЭЦП файлы/сообщения с данными, выгружаемые во внешние системы.

  4. Возможность проведения процедуры проверки ЭЦП при загрузке в АС файлов/сообщений с данными, НСИ и т.д. (в Систему должны загружаться только файлы/сообщения, имеющие корректную ЭЦП).

  5. Возможность использования в качестве носителя секретного ключа ЭЦП носителя типа Touch Memory.

  6. Невозможность хранения секретных ключей ЭЦП в открытом виде на жестких и виртуальных дисках.

  7. Непринятие файла/сообщения в обработку при получении отрицательного результата проверки ЭЦП поступившего файла/сообщения («ЭЦП не корректна», «ЭЦП не зарегистрирована», «ЭЦП отсутствует»). Возникновение данной ситуации должно отражаться в журнале аудита.
  1. Требования к аудиту


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

  2. Обеспечение фиксации в журнале аудита всех действий администратора системы по управлению журналом (очистка за определенный промежуток времени, настройка списка протоколируемых операций и т.д.).

  3. Исключение возможности несанкционированной модификации журналов подсистемы аудита.

  4. Представление информации в журналах аудита в структурированном виде в терминах предметной области.

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

  6. Исключение возможности редактирования, отключения и удаления журнала аудита средствами Системы, а также его импортирования в Систему из какого-либо источника с заменой текущего.

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

  8. Наличие средств Системы для очистки журнала аудита за определенный промежуток времени (но не включая в него 2-3 последних месяца) с фиксацией данного события в журнале аудита.

  9. Исключение возможности очистки средствами Системы журнала аудита до его архивирования или распечатки.

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

  11. Отражение результата проверки ЭЦП в журнале аудита.

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

  1. событию;

  2. действиям конкретного пользователя;

  3. действиям над конкретным пользователем;

  4. действиям над конкретным объектом;

  5. дате (периоду дат);

  6. времени (периоду времени);

  7. комбинации вышеперечисленных параметров.

  1. Возможность фиксации при загрузке/выгрузке данных в/из Систему в журнале аудита имени файла, из/в которого производилась загрузка/выгрузка, идентификатора ЭЦП (которой подписаны данные), а также результат проверки ЭЦП.

  2. Возможность протоколирования в журнале аудита следующих действий администратора Системы и событий безопасности:

  1. создание нового пользователя;

  2. время создания и все атрибуты создаваемого пользователя;

  3. назначение пользователю прав доступа к данным и функциям Системы, а также изменение прав доступа;

  4. время события и полная информация по назначаемым или изменяемым правам;

  5. блокирование пользователя;

  6. время блокирования и все атрибуты блокируемого пользователя;

  7. входы/выходы пользователей в/из Системы;

  8. попытки совершения НСД;

  9. использование специальных полномочий (редактирование информации в базе данных, изменение настроек и т.д.);

  10. изменения параметров и системных настроек АБС с указанием старых и новых параметров и настроек;

  11. отрицательные результаты проверок целостности данных в Системе.
  1. Требования к документации


  1. Наличие документации по настройкам (необходимые сервисы, права пользователей, права доступа к файлам и каталогам, аудит и т.п.).

  2. Наличие руководства администратора Системы (предоставление прав пользователям, включая описание запрещенных комбинаций прав и ролей пользователей в Системе; перечень критичных операций, совершение которых одним лицом должно быть исключено).

  3. Наличие описания ключевой системы и правил работы с ней.
  1. Требования к реализации Web-приложении


  1. Обеспечение защиты автоматизированной системы, построенной на основе Web-технологий, от наиболее распространенных типов атак на данный класс приложений (SQL-injection, cross-site scripting, buffer overflow и т.д.).




Москва, 2010

Каталог: common -> img -> uploaded -> files -> tender
files -> Состояние репродуктивной системы у девочек-подростков при нервной анорексии 14. 00. 01 акушерство и гинекология
tender -> На выполнение работ для выполнения работ по разработке проекта Организации парковки и комплексному ремонту подземного паркинга комплекса зданий Центрального аппарата Сбербанка России ОАО по адресу: г. Москва, ул
tender -> К порядку проведения открытого конкурса по выбору подрядной организации для выполнения работ по ремонту фасада
tender -> Требования по обеспечению информационной безопасности к системе
tender -> Порядок проведения конкурса по
tender -> Технические и эксплуатационные требования
tender -> Расшифровка ас, Система

Скачать 80.67 Kb.

Поделитесь с Вашими друзьями:




База данных защищена авторским правом ©vossta.ru 2022
обратиться к администрации

    Главная страница