ПОСТАНОВЛЕНИЕ ПРАВЛЕНИЯ НАЦИОНАЛЬНОГО БАНКА РЕСПУБЛИКИ БЕЛАРУСЬ
31 декабря 2019 г. № 552
Об утверждении стандартов проведения расчетов
Изменения и дополнения:
Постановление Правления Национального банка Республики Беларусь от 9 июля 2021 г. № 199 (Национальный правовой Интернет-портал Республики Беларусь, 13.08.2021, 8/37038) <B22137038p>;
Постановление Правления Национального банка Республики Беларусь от 6 сентября 2021 г. № 256 (Национальный правовой Интернет-портал Республики Беларусь, 15.10.2021, 8/37220) <B22137220p>;
Постановление Правления Национального банка Республики Беларусь от 8 сентября 2022 г. № 335 (Национальный правовой Интернет-портал Республики Беларусь, 22.11.2022, 8/38996) <B22238996p>;
Постановление Правления Национального банка Республики Беларусь от 8 августа 2023 г. № 285 (Национальный правовой Интернет-портал Республики Беларусь, 20.10.2023, 8/40508) <B22340508p>
На основании абзаца шестьдесят пятого статьи 26 и части первой статьи 39 Банковского кодекса Республики Беларусь Правление Национального банка Республики Беларусь ПОСТАНОВЛЯЕТ:
1. Утвердить:
стандарт проведения расчетов СПР 6.01-2020 «Банковская деятельность. Информационные технологии. Открытые банковские API. Регламент взаимодействия поставщиков API и пользователей API» (прилагается);
стандарт проведения расчетов СПР 7.01-2020 «Деятельность в области платежных систем и платежных услуг. Информационные технологии. Обеспечение непрерывной работы и восстановления работоспособности участника платежного рынка Республики Беларусь. Общие требования» (прилагается).
2. Настоящее постановление вступает в силу после его официального опубликования, за исключением абзаца второго пункта 1 настоящего постановления, который вступает в силу с 1 июля 2020 г.
Председатель Правления | П.В.Каллаур |
| УТВЕРЖДЕНО Постановление Правления 31.12.2019 № 552 |
СТАНДАРТ ПРОВЕДЕНИЯ РАСЧЕТОВ
СПР 6.01-2020 «Банковская деятельность. Информационные технологии. Открытые банковские API. Регламент взаимодействия поставщиков API и пользователей API»
РАЗДЕЛ I
ОБЩИЕ ПОЛОЖЕНИЯ
1. Настоящий стандарт проведения расчетов (далее – стандарт) определяет регламент взаимодействия банков, небанковских кредитно-финансовых организаций, открытого акционерного общества «Банк развития Республики Беларусь», открытого акционерного общества «Белорусская валютно-фондовая биржа» (далее – банки), являющихся поставщиками открытого интерфейса программирования приложений (интерфейс прикладного программирования) (далее – API), и пользователей API.
2. Настоящий стандарт предназначен для поставщиков API и пользователей API и применяется при разработке приложений, использующих открытые API, и в процессах предоставления API их поставщиками.
3. В настоящем стандарте используются следующие термины и их определения:
API – набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних по отношению к данному приложению (библиотеке, сервису) программных продуктах;
информационный API – API к общедоступной информации по операциям и услугам банков;
клиент – юридическое лицо, в том числе банк, нотариус, физическое лицо, в том числе индивидуальный предприниматель, обслуживаемые банком;
открытый API – API, открытый доступ к которому предоставляется его поставщиком при выполнении пользователем API требований, установленных Национальным банком и (или) поставщиком API;
платежный API – API, который используется для предоставления банком пользователю API информации о состоянии счета клиента, наличии на счете необходимой суммы денежных средств и их движении, другой информации по счету клиента, для инициирования платежей между счетами, а также подключения, изменения и отключения услуг с использованием приложения пользователя API;
пользователь API – клиент, который использует API в собственных целях не для коммерческого использования (пользователь API первого типа) либо в коммерческих интересах (пользователь API второго типа);
поставщик API – банк, предоставляющий открытый API;
статистический API – API, предоставляющий доступ к информации первичных учетных документов по операциям в банках, о первичных операциях в банках;
тестовая среда API – совокупность программных и (или) программно-технических средств и (или) специальный режим функционирования API с использованием тестовых данных.
4. Открытые API делятся на следующие типы:
информационные;
платежные;
статистические.
5. Персональные данные клиента, информация по его счету, информация первичных учетных документов по операциям в банках, о первичных операциях в банках являются информацией ограниченного распространения. Предоставление и хранение указанных сведений осуществляются в соответствии с законодательством.
6. При каждом запросе (сеансе связи) на предоставление информации по счету клиента, информации первичных учетных документов по операциям в банках, о первичных операциях в банках пользователь API должен быть однозначно авторизован поставщиком API.
7. Запрос информации о наличии на счете необходимой суммы денежных средств не является авторизацией на блокировку указанной суммы денежных средств на счете.
8. В состав общедоступной информации, предоставляемой посредством информационных API, входит:
информация о курсах валют (при проведении операций с наличными и (или) безналичными денежными средствами, в том числе с использованием банковских платежных карточек, систем дистанционного банковского обслуживания, программно-технической инфраструктуры с использованием банковских платежных карточек);
информация о пунктах обслуживания клиентов банка (отделения, филиалы, обменные пункты, пункты самообслуживания с использованием программно-технической инфраструктуры с использованием банковских платежных карточек) с указанием адреса и времени работы, контактных телефонов, адресов электронной почты, списком оказываемых услуг и иная информация о каждом пункте обслуживания;
информация о банковских операциях и услугах (об открытии и ведении банковских счетов, предоставлении кредитов, привлечении денежных средств во вклады (депозиты), выпуске в обращение (эмиссии) банковских платежных карточек, привлечении драгоценных металлов во вклады (депозиты), условиях осуществления денежных переводов, включая переводы без открытия счета, и иная информация).
9. Для тестирования API может быть создана общедоступная тестовая среда API, с помощью которой потенциальные пользователи API второго типа, и, при необходимости, пользователи первого типа, смогут протестировать свои приложения на соответствие предъявляемым требования API без необходимости подключаться к локальным тестовым средам поставщиков API.
Общедоступная тестовая среда API может быть реализована в виде скачиваемого контейнера (виртуальной машины), которую потенциальный пользователь API может скачать и запустить локально, чтобы не было необходимости создавать и поддерживать постоянно работающую инфраструктуру.
РАЗДЕЛ II
РЕГЛАМЕНТ ВЗАИМОДЕЙСТВИЯ ПОСТАВЩИКОВ API И ПОЛЬЗОВАТЕЛЕЙ API
ГЛАВА 1
ОБЩИЕ ТРЕБОВАНИЯ
10. Предоставление поставщиками API доступа к API осуществляется на основании публичного договора, в который рекомендуется включать следующие положения:
10.1. пользователь API второго типа получает доступ к общедоступной информации после идентификации и авторизации его поставщиком API;
10.2. пользователь API второго типа имеет право на обработку информации, получаемой посредством платежных или статистических API для предоставления клиенту, и отвечает за корректность такой обработки;
10.3. предоставление пользователю услуг пользователя API второго типа общедоступной информации, полученной посредством информационных API, предоставляется клиенту в неизменном виде;
10.4. при нарушении пользователем API второго типа требований, согласованных поставщиком API и пользователем API в публичном договоре, поставщик API имеет право прекратить доступ к API такому пользователю API в случае:
искажения пользователем API второго типа данных поставщика API;
деструктивного действия со стороны пользователя API второго типа;
невыполнения пользователем API второго типа условий договора с поставщиком API;
10.5. информация по счету клиента может быть предоставлена поставщиком платежных API:
пользователю платежных API первого типа в целях получения указанной информации по счетам, владельцем которых он является;
пользователю платежных API второго типа в целях предоставления (обеспечения предоставления) данным поставщиком указанной информации пользователю своих услуг по счетам, владельцем которых такой пользователь является;
10.6. согласие клиента на предоставление пользователю API своих персональных данных и информации по его счету может быть отозвано клиентом;
10.7. ответственность пользователя API за ненадлежащую обработку, передачу, хранение, защиту и обеспечение безопасности полученных посредством API персональных данных пользователя его услуг и информации по его счету.
11. Правоотношения между поставщиком API и пользователем API в части использования информационных и платежных API, как правило, оформляются в виде договора присоединения.
В случае предоставления информационных API его поставщиком на основании публичного договора с офертой поставщик API предоставляет информационные API по принципу «как есть» и не гарантирует бесперебойную и безошибочную работу API.
При необходимости поставщик API и пользователь API могут заключить договор другого вида с необходимыми коммерческими условиями, степенью ответственности и уровнем оказания услуг.
12. Правоотношения между пользователем API второго типа и пользователем его услуг определяются договором либо соглашением, заключенным между ними.
13. С целью систематизации работ, возникающих при взаимодействии поставщика API и пользователя API второго типа, могут использоваться следующие формы взаимодействия, которые согласовываются поставщиком API и пользователем API второго типа в публичном договоре:
публикация API;
подписка на API;
тестирование API;
использование API и прекращение доступа к API;
мониторинг использования API и развитие API.
ГЛАВА 2
ПУБЛИКАЦИЯ API
14. Поставщик API ведет и публикует перечень своих открытых API согласно стандартам API.
Поставщик API публикует в открытом доступе регламент подключения и использования открытого API, а также параметры подключения к тестовой среде.
15. Поставщик API классифицирует среды API следующим образом:
тестовая;
производственная.
16. Поставщик API предоставляет следующие сведения:
16.1. описание API, включая описание форматов, ограничения, известные ошибки, примеры, в том случае, если есть расширения по отношению к стандарту API;
16.2. соглашение об уровне оказываемой ИТ-услуги, в том числе:
параметры гарантии (уровень доступности и производительности);
описание стандартных процедур и шаблоны документов, включая временные параметры (например, получение доступа);
формализованные каналы коммуникации (например, телефонный номер, адрес электронной почты, форма обратной связи на сайте);
16.3. параметры подключения к тестовой среде поставщика API (в случае ее наличия).
17. Поставщик API информирует пользователей API второго типа о новой версии API и планируемых датах ее выхода, размещая сведения на своем сайте в глобальной компьютерной сети Интернет или с использованием других средств коммуникации.
В случае публикации новой версии API поставщик API обеспечивает доступность предыдущей версии API на протяжении не менее 90 календарных дней.
Поставщик API включает в сведения о новой версии API перечень изменений по сравнению с предыдущей версией.
Поставщик API отражает версию и среду API в URL (например: https://api.v2143.sandbox.bank.by).
18. Поставщик API информирует пользователей API второго типа о статусах опубликованных версий API.
Рекомендуемый перечень статусов:
находящиеся в эксплуатации (Release) – полностью описанные и поддерживаемые, доступные всем текущим и новым пользователям API второго типа;
ограниченно эксплуатируемые (Limited release) – полностью описанные и поддерживаемые, но доступные не всем пользователям API второго типа (доступ может быть ограничен по принципу участия в бета-тестировании, присутствия в определенном сегменте рынка и т.д.);
устаревшие (Deprecated) – полностью описанные и поддерживаемые, включая обратно-совместимые исправления ошибок, но недоступные для новых пользователей API второго типа;
выведенные из эксплуатации (Retired) – полностью описанные, но не поддерживаемые и недоступные всем пользователям API второго типа.
ГЛАВА 3
ПОДПИСКА НА API
19. Пользователь API второго типа для предоставления своим клиентам информации и (или) услуг может подключиться к любому количеству поставщиков API.
20. Поставщик API осуществляет регистрацию в своей автоматизированной системе пользователя API второго типа. Процесс регистрации пользователя API второго типа включает следующие этапы:
20.1. направление пользователем API второго типа поставщику API заявки на регистрацию.
Примерный перечень реквизитов заявки на регистрацию:
наименование организации;
учетный номер плательщика (УНП);
адрес места нахождения;
почтовый адрес;
адрес сайта в глобальной компьютерной сети Интернет;
фамилия, собственное имя и отчество (если таковое имеется) представителя;
телефон представителя;
адрес электронной почты представителя;
тип API (согласно пункту 4);
20.2. согласование поставщиком API заявки на регистрацию с предоставлением параметров для подключения к тестовой среде или направление пользователю API второго типа мотивированного отказа по заявке на подписку на API.
ГЛАВА 4
ТЕСТИРОВАНИЕ API
21. Пользователь API второго типа тестирует свое программное решение в тестовой среде поставщика API в соответствии с требованиями поставщика API.
22. Поставщик API может организовать тестирование взаимодействия с API на базе собственной тестовой среды API.
23. После того, как пользователем API второго типа подтверждено завершение процесса тестирования API, поставщик API предоставляет параметры подключения к производственной среде и пользователь API второго типа может к ней подключиться.
ГЛАВА 5
ИСПОЛЬЗОВАНИЕ API И ПРЕКРАЩЕНИЕ ДОСТУПА К API
24. Поставщик API обеспечивает работоспособность открытого API в соответствии со стандартом API.
25. Пользователь API второго типа может в добровольном порядке отказаться от доступа к API. Процедура добровольного отказа определяется поставщиком API.
26. В случае инцидента (например, нарушение информационной безопасности) полное или частичное прекращение доступа пользователя API второго типа к API может быть осуществлено без предварительного уведомления.
27. Уведомление о прекращении доступа может публиковаться поставщиком API на его официальном сайте в глобальной компьютерной сети Интернет или передаваться по другим каналам коммуникации с пользователем API второго типа.
ГЛАВА 6
МОНИТОРИНГ ИСПОЛЬЗОВАНИЯ API И РАЗВИТИЕ API
28. С целью отслеживания использования API, а также последующего анализа и развития API поставщик API накапливает показатели и аналитическую информацию по использованию открытого API, в том числе:
периоды простоя;
общее количество запросов;
среднее количество запросов в час, день, месяц;
топ-5 запросов.
Поставщик API обеспечивает хранение указанной в части первой настоящего пункта информации в течение не менее одного года.
29. С целью отслеживания использования API, а также последующего анализа и развития API пользователь API второго типа накапливает показатели и аналитическую информацию по использованию API, в том числе:
количество запросов к конкретному поставщику API;
среднее количество запросов по всем поставщикам API.
Пользователь API второго типа обеспечивает хранение данной информации в течение не менее 1 года.
30. Поставщик API и пользователь API второго типа могут разрабатывать расширения к стандарту API в рамках двусторонних отношений.
ГЛАВА 7
ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
31. Открытые API используют стандарты информационной безопасности и защищенные открытые протоколы (например, TLS, OAuth и OpenID Connect и иные).
32. Система защиты информации информационной системы пользователя платежного API второго типа должна соответствовать требованиям законодательства в области безопасности и защиты информации.
33. Для информационных API в качестве стандартов информационной безопасности используются стандарты, основанные на серии стандартов ISO 27000, с многоуровневым подходом, который основывается на принципе рискориентированного подхода.
34. Система управления риском безопасности, в том числе киберриском, пользователя API предусматривает:
тестирование на проникновение, брандмауэры, системы обнаружения вторжений, модули аппаратной безопасности, политики обновления операционных систем и т.д.;
реализацию жизненного цикла разработки программного обеспечения (например, OpenSAMM, Security Development Lifecycle и иные);
тестирование программного обеспечения пользователя API второго типа на проникновение, в том числе автоматическое или полуавтоматическое, заключающееся в передаче программному приложению, использующему открытые API, на вход неправильных, неожиданных или случайных данных, или анализ исходного кода.
35. Соединения между клиентом и пользователем API, а также между пользователем API и поставщиком API выполняются только с использованием HTTPS и протокола TLS v1.2+.
36. В случае, если персональные данные анонимизируются для публикации в качестве общедоступной информации, необходимо обеспечить невозможность их деанонимизации (в том числе посредством комбинации нескольких открытых наборов данных).
ГЛАВА 8
ОБМЕН ИНФОРМАЦИЕЙ И ОБРАБОТКА ИНЦИДЕНТОВ
37. Пользователь API сообщает поставщику API о любых инцидентах и проблемах, имеющих значение для информационной безопасности, принимает формальные процедуры для подтверждения и расследования таких случаев, устранения любых обнаруженных уязвимостей информационной безопасности.
38. Пользователи API и поставщики API сообщают о любых нарушениях информационной безопасности, которые влияют на данные или функциональные возможности API, всем затронутым нарушениями клиентам. В случае нарушения информационной безопасности, которые влияют на данные, полученные от поставщика API, пользователь API также уведомляет поставщика API.
39. С целью поддержки расследования потенциальных случаев мошенничества или нарушений безопасности между поставщиками и пользователями API обеспечивается обмен информацией в режиме реального времени.
ГЛАВА 9
ПРОТОКОЛИРОВАНИЕ ИСПОЛЬЗОВАНИЯ API
40. С целью облегчения выявления подозрительных случаев реализации риска безопасности, в том числе киберриска, поставщиками API и пользователями API второго типа ведутся журналы запросов открытых API.
41. Журналы запросов открытых API автоматически формируются поставщиком API и пользователем API второго типа и включают следующие параметры:
дата и время вызова;
IP адрес вызывающей стороны;
URL вызова;
заголовки HTTP;
содержимое запроса;
дата и время ответа;
содержимое ответа.
42. Поставщик API и пользователи API второго типа обеспечивают хранение журналов запросов открытых API в течение не менее 3 лет.
| УТВЕРЖДЕНО Постановление |
СТАНДАРТ ПРОВЕДЕНИЯ РАСЧЕТОВ
СПР 7.01-2020 «Деятельность в области платежных систем и платежных услуг. Информационные технологии. Обеспечение непрерывной работы и восстановления работоспособности участника платежного рынка Республики Беларусь. Общие требования»
ГЛАВА 1
ОБЩИЕ ПОЛОЖЕНИЯ
1. Настоящий стандарт проведения расчетов (далее – стандарт):
описывает общие подходы к обеспечению непрерывности деятельности в области платежных систем и платежных услуг (далее – платежная деятельность), непрерывной работы и восстановления работоспособности участника платежного рынка Республики Беларусь (далее – участник платежного рынка);
устанавливает перечень обязательных требований по обеспечению непрерывной работы и восстановления работоспособности участника платежного рынка согласно приложению.
2. При оказании участником платежного рынка, являющимся поставщиком платежных услуг, более одной платежной услуги одновременно и при наличии требований по обеспечению непрерывной работы и восстановления работоспособности участника платежного рынка разного уровня следует выполнять все требования, являющиеся обязательными к выполнению соответствующим участником платежного рынка согласно приложению.
3. Требования по обеспечению непрерывной работы и восстановления работоспособности участника платежного рынка применяются к оператору платежной системы, расчетному центру, платежному агрегатору (в случае участия в платежной системе) в зависимости от типа значимости платежной системы согласно приложению.
4. Оператор платежной системы устанавливает в правилах платежной системы и (или) договоре с участником платежной системы об участии в платежной системе требования по обеспечению непрерывной работы и восстановления работоспособности участника платежной системы с учетом требований, применимых к данному оператору платежной системы, и в зависимости от функций, осуществляемых участником платежной системы, и типа значимости платежной системы, и принимает меры по выполнению установленных требований участником своей платежной системы.
Поставщик платежных услуг, поставщик технологических услуг, являющийся участником платежной системы, обеспечивает выполнение установленных в правилах платежной системы и (или) договоре с участником платежной системы об участии в платежной системе требований по обеспечению непрерывной работы и восстановления работоспособности участника платежной системы.
5. Поставщик платежных услуг устанавливает в платежном соглашении (договоре на оказание платежных услуг), договоре аутсорсинга и (или) ином договоре с иным поставщиком платежных услуг, поставщиком технологических услуг требования по обеспечению непрерывной работы и восстановления работоспособности участника платежного рынка с учетом требований, применимых к данному поставщику платежных услуг, и принимает меры по выполнению установленных требований поставщиком платежных услуг, поставщиком технологических услуг, оказывающим ему услугу (услуги).
Поставщик платежных услуг, поставщик технологических услуг обеспечивает выполнение установленных в платежном соглашении (договоре на оказание платежных услуг), договоре аутсорсинга и (или) иных договорах требований по обеспечению непрерывной работы и восстановления работоспособности участника платежного рынка.
6. В настоящем стандарте применяются термины в значениях, установленных Законом Республики Беларусь от 10 ноября 2008 г. № 455-З «Об информации, информатизации и защите информации» и Законом Республики Беларусь от 19 апреля 2022 г. № 164-З «О платежных системах и платежных услугах», а также следующие термины и их определения:
аварийный режим – режим работы участника платежного рынка во время кризисной (сбойной) ситуации;
автоматизированная система (далее, если не указано иное, – АС) – система, реализующая информационную технологию выполнения установленных задач и состоящая из персонала и комплекса средств автоматизации его деятельности, включающих программные средства, технические средства, программно-технические средства, программно-технические комплексы и средства телекоммуникаций;
безотказность – свойство объекта программно-технической инфраструктуры непрерывно сохранять работоспособное состояние в течение некоторого времени;
восстановление – процесс перевода объекта программно-технической инфраструктуры в работоспособное состояние из неработоспособного состояния;
данные – информация, представленная в виде, пригодном для автоматизированной обработки техническими средствами при возможном участии человека;
кризисная (сбойная) ситуация – чрезвычайное происшествие, приводящее к невозможности осуществления в полном объеме участником платежного рынка платежной деятельности и (или) невозможности персонала выполнять свои должностные обязанности вследствие нарушения работоспособности критичных ресурсов участника платежного рынка (участника платежной системы, поставщика платежных услуг, не являющегося участником платежной системы, либо поставщика платежных услуг, поставщика технологических услуг, оказывающего им услуги);
критичные ресурсы – минимальный набор ресурсов, необходимый для обеспечения надежного, безопасного и эффективного осуществления платежной деятельности, непрерывной работы и восстановления работоспособности участника платежного рынка;
носитель данных – материальный объект, предназначенный для записи и хранения данных;
обеспечивающие системы – системы, предназначенные для обеспечения физической и технической защиты, безопасных условий работы персонала в зданиях и помещениях, в которых расположена программно-техническая инфраструктура;
основной вычислительный центр – здания и помещения, в которых размещена программно-техническая инфраструктура, используемая для осуществления платежной деятельности участника платежного рынка;
основной канал связи – система технических средств и среда распространения сигналов, предназначенные для организации передачи данных между участником платежного рынка и оператором платежной системы, участниками платежной системы в рамках осуществления платежной деятельности участника платежного рынка;
отказ – событие, заключающееся в нарушении работоспособного состояния объекта программно-технической инфраструктуры, обеспечивающих систем, систем жизнеобеспечения;
план обеспечения непрерывной работы и восстановления работоспособности участника платежного рынка (далее – ПОНРВ) – документ или совокупность документов, содержащие комплекс организационных мероприятий и программно-технических решений, которые должны выполняться до, во время и после возникновения кризисной (сбойной) ситуации;
подлинник организационно-методического документа, технической документации, эксплуатационной документации – первый или единственный экземпляр документа, используемый для изготовления рабочих экземпляров документа;
подлинник программного средства – программное средство, удостоверенное в соответствии со стандартами Республики Беларусь и используемое для изготовления учтенных копий программного средства;
программно-техническая инфраструктура – совокупность объектов, используемых для осуществления платежной деятельности участника платежного рынка и включающих в себя АС, а также технические средства, программные средства и (или) программно-технические средства, и (или) программно-технические комплексы, средства телекоммуникаций, не входящие в состав АС;
программное средство (далее – ПС) – объект, состоящий из программ, процедур, правил, а также при необходимости сопутствующих им документации и данных, относящихся к функционированию ПС;
программно-технический комплекс (далее – ПТК) – программно-технические средства, объединенные в комплекс для реализации задач АС;
программно-техническое средство (далее – ПТС) – совокупность ПС и технических средств;
работоспособное состояние – состояние объекта программно-технической инфраструктуры, при котором значения всех параметров, характеризующих его способность выполнять заданные функции, соответствуют требованиям технической и (или) конструкторской (проектной) документации;
резервирование – способ обеспечения надежности объекта программно-технической инфраструктуры за счет использования дополнительных средств и (или) возможностей, избыточных по отношению к минимально необходимым для выполнения требуемых функций;
резервный вычислительный центр – здания и помещения, в которых размещены резервные объекты программно-технической инфраструктуры, используемые для осуществления платежной деятельности участника платежного рынка в случае невозможности осуществления платежной деятельности в полном объеме с использованием основного вычислительного центра;
резервный канал связи – система технических средств и среда распространения сигналов, предназначенные для организации передачи данных между участником платежного рынка и оператором платежной системы, участниками платежной системы в рамках осуществления платежной деятельности участника платежного рынка в случае невозможности осуществления платежной деятельности в полном объеме с использованием основного канала связи;
системы жизнеобеспечения – системы и процессы создания и поддержания условий пригодности среды в зданиях и помещениях для безотказного функционирования объектов программно-технической инфраструктуры и работы персонала;
средства телекоммуникаций (далее – СТ) – совокупность ПС, технических средств, ПТС и каналов связи, предназначенных для приема и передачи данных;
техническая документация – совокупность документов, необходимая и достаточная для использования на каждой стадии жизненного цикла объекта программно-технической инфраструктуры;
техническое средство (далее, если не указано иное, – ТС) – оборудование, включая носители данных, предназначенное для автоматизированной обработки данных;
учтенная копия ПС – копия, взятая на учет держателем подлинников ПС для внесения изменений в подлинник ПС при проведении модернизации ПС, выполненная способом, обеспечивающим ее идентичность с подлинником ПС, и предназначенная для непосредственного использования;
штатный режим – режим работы участника платежного рынка, при котором все критичные ресурсы участника платежного рынка находятся в работоспособном состоянии, для каждого критичного ресурса обеспечивается работоспособный резерв, обеспечивается возможность выполнения персоналом своих должностных обязанностей в полном объеме;
эксплуатационная документация – документация, предназначенная для использования при эксплуатации, обслуживании и сопровождении объекта программно-технической инфраструктуры.
ГЛАВА 2
ОБЕСПЕЧЕНИЕ НЕПРЕРЫВНОСТИ ПЛАТЕЖНОЙ ДЕЯТЕЛЬНОСТИ, НЕПРЕРЫВНОЙ РАБОТЫ И ВОССТАНОВЛЕНИЯ РАБОТОСПОСОБНОСТИ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
7. Участник платежного рынка в своей деятельности руководствуется требованиями законодательства, в том числе нормативных правовых актов Национального банка, технических нормативных правовых актов Национального банка, условиями договоров, соглашений, локальными правовыми актами.
8. Непрерывность платежной деятельности участника платежного рынка заключается в выполнении установленных качественных и (или) количественных параметров работы, уровней оказания платежных услуг, согласованных с пользователями платежных услуг в платежных соглашениях (договорах на оказание платежных услуг).
9. Непрерывность платежной деятельности участника платежного рынка достигается выполнением мероприятий по обеспечению непрерывной работы и восстановления работоспособности участника платежного рынка и поддержания работоспособности критичных ресурсов участника платежного рынка.
10. К критичным ресурсам участника платежного рынка относятся:
10.1. организационно-методическое и документационное обеспечение, включающее в себя:
организационно-методические документы, локальные правовые акты, иные документы, утвержденные руководителем (уполномоченным работником) участника платежного рынка, определяющие порядок осуществления платежной деятельности участника платежного рынка, обеспечения управления, использования и взаимодействия объектов программно-технической инфраструктуры;
техническую и эксплуатационную документацию (в том числе входящую в комплект разрабатываемых (поставляемых) ПС) на объекты программно-технической инфраструктуры (далее – техническая и эксплуатационная документация);
10.2. объекты программно-технической инфраструктуры;
10.3. информационные ресурсы АС (далее – информационные ресурсы), используемые при осуществлении платежной деятельности участника платежного рынка и подлежащие хранению, включающие в себя:
базы данных, входные и выходные данные АС, другие совокупности взаимосвязанной информации в АС, обеспечивающей осуществление платежной деятельности;
структуры баз данных;
протоколы обработки информации, включая действия персонала;
10.4. обеспечивающие системы, включающие в себя:
технические средства и системы охраны зданий и помещений;
автоматизированную систему контроля и управления доступом в здания и помещения;
систему видеонаблюдения;
10.5. системы жизнеобеспечения, включающие в себя:
системы электроснабжения;
кабельные системы вычислительных сетей, связи и автоматизации;
системы вентиляции и кондиционирования;
системы теплоснабжения, водоснабжения и канализации;
системы оповещения о пожаре, пожарной сигнализации, автоматического пожаротушения, мониторинга за техническими средствами противопожарной защиты;
10.6. персонал, осуществляющий эксплуатацию, обслуживание и сопровождение объектов программно-технической инфраструктуры, обслуживание обеспечивающих систем и систем жизнеобеспечения, а также использующий информационные ресурсы при выполнении своих должностных обязанностей (далее – персонал);
10.7. здания и помещения, в которых расположены объекты программно-технической инфраструктуры и выполняет свои должностные обязанности персонал.
11. Ответственность за обеспечение непрерывности платежной деятельности участника платежного рынка возлагается на руководителя участника платежного рынка и (или) заместителя руководителя, курирующего платежную деятельность (при его наличии).
12. Мероприятия по обеспечению непрерывной работы и восстановления работоспособности участника платежного рынка выполняются до, во время и после возникновения кризисной (сбойной) ситуации и включают в себя:
мероприятия, направленные на предотвращение возникновения или минимизацию вероятности возникновения кризисной (сбойной) ситуации;
мероприятия, направленные на устранение кризисной (сбойной) ситуации и восстановление работоспособности, минимизацию времени восстановления работоспособности.
ГЛАВА 3
ОРГАНИЗАЦИОННО-МЕТОДИЧЕСКОЕ И ДОКУМЕНТАЦИОННОЕ ОБЕСПЕЧЕНИЕ
13. К организационно-методическим документам, регулирующим процесс обеспечения непрерывной работы и восстановления работоспособности участника платежного рынка, относятся:
13.1. ПОНРВ;
13.2. документ, устанавливающий порядок обеспечения управления, использования и взаимодействия объектов программно-технической инфраструктуры, перечень работ по сопровождению, обслуживанию и эксплуатации АС;
13.3. документ, устанавливающий порядок разработки, сопровождения (внесения изменений), хранения и эксплуатации ПС;
13.4. документ, устанавливающий порядок проведения технического обслуживания и тестирования объектов программно-технической инфраструктуры;
13.5. документ, устанавливающий разграничение доступа к объектам программно-технической инфраструктуры, в здания и помещения, где они расположены, к информационным ресурсам, техническому архиву ПС;
13.6. документ, устанавливающий порядок учета ПТК и оборудования СТ, используемых при осуществлении платежной деятельности участника платежного рынка;
13.7. документ, устанавливающий порядок учета и хранения ПС (подлинников технической и эксплуатационной документации на ПС, подлинников ПС, дубликатов и рабочих копий на носителях данных) и их использования участником платежного рынка;
13.8. документ, устанавливающий политику, процедуры резервного копирования и архивирования ПС и данных;
13.9. документ, устанавливающий порядок восстановления информационных ресурсов в случае нарушения их целостности;
13.10. иные документы, определяемые участником платежного рынка.
14. В комплект технической и эксплуатационной документации СТ включаются схемы подключения и расположения СТ (с указанием мест хранения информации об актуальных сетевых адресах, параметрах маршрутизации и конфигурационных файлах).
15. Для поддержания организационно-методических документов, технической и эксплуатационной документации в актуальном состоянии выполняются мероприятия по их регулярному пересмотру и, по мере необходимости, актуализации.
Результаты пересмотра, включая заключение о необходимости актуализации, фиксируются участником платежного рынка в установленном участником платежного рынка порядке (в журнале пересмотра, протоколе пересмотра и (или) иных формах).
Актуализация организационно-методических документов, технической и эксплуатационной документации по результатам пересмотра (в случае заключения о необходимости актуализации) в зависимости от степени планируемых изменений может осуществляться путем внесения изменений в действующие организационно-методические документы, техническую и эксплуатационную документацию, разработки и утверждения новых редакций и (или) новых организационно-методических документов, технической и эксплуатационной документации.
ГЛАВА 4
ПОНРВ
16. Участник платежного рынка организует проведение мероприятий по восстановлению работоспособности в случае возникновения кризисных (сбойных) ситуаций в соответствии с ПОНРВ.
ПОНРВ может быть оформлен в виде одного или нескольких иерархически упорядоченных организационно-методических документов участника платежного рынка. Отдельные положения, относящиеся к ПОНРВ, могут быть закреплены участником платежного рынка в платежных соглашениях (договорах на оказание платежных услуг), договорах аутсорсинга и (или) иных договорах с поставщиками платежных услуг, поставщиками технологических услуг, иных документах, регулирующих порядок обеспечения непрерывной работы участника платежного рынка, а также восстановление в установленные сроки его работоспособности в случае возникновения кризисной (сбойной) ситуации.
ПОНРВ верхнего уровня утверждается участником платежного рынка и содержит ссылки на иные документы, относящиеся к ПОНРВ.
17. При разработке ПОНРВ участник платежного рынка включает в него:
17.1. перечень объектов ПОНРВ.
Перечень объектов ПОНРВ включает в себя все критические ресурсы участника платежного рынка, а также их резерв, в том числе состав основного персонала и состав резервного персонала, схемы замещения персонала, обеспечивающего эксплуатацию, сопровождение и обслуживание объектов программно-технической инфраструктуры, и ПТК, обеспечивающие:
функционирование АС участника платежного рынка, используемых для осуществления деятельности участника платежного рынка;
взаимодействие участника платежного рынка с обслуживаемыми клиентами и пользователями информации;
резерв для восстановления функционирования основных ПТК;
17.2. категорирование кризисных (сбойных) ситуаций.
При категорировании кризисных (сбойных) ситуаций количество категорий, их обозначения (наименования), признаки определяются участником платежного рынка самостоятельно.
Присвоение категорий кризисной (сбойной) ситуации может осуществляться по одному или нескольким из следующих признаков:
характер кризисной (сбойной) ситуации. По своему характеру выделяются кризисные (сбойные) ситуации умышленные (возникающие в результате выполнения злоумышленниками в определенные промежутки времени заранее обдуманных и спланированных действий) и случайные (возникающие как результат объективных причин случайного характера, халатности, небрежности и форс-мажорных обстоятельств);
масштаб кризисной (сбойной) ситуации, отражающий степень влияния кризисной (сбойной) ситуации на платежную деятельность участника платежного рынка, степень нарушения договорных обязательств, требований законодательства, объем финансовых и материальных затрат, человеческих ресурсов, необходимых для устранения кризисной (сбойной) ситуации и восстановления работоспособности участника платежного рынка;
финансовые и иные потери (убытки, дополнительные затраты) участника платежного рынка при возникновении и устранении кризисной (сбойной) ситуации;
причины возникновения кризисной (сбойной) ситуации, основными из которых являются:
чрезвычайные ситуации техногенного характера (пожары, неспровоцированные взрывы или их угроза, аварии с выбросом (угрозой выброса) опасных химических, радиоактивных, биологических веществ, внезапное разрушение сооружений и зданий, аварии на инженерных сетях и сооружениях жизнеобеспечения и иные);
чрезвычайные ситуации природного характера (опасные геологические, метеорологические, гидрологические явления, природные пожары, инфекционная заболеваемость людей и иные);
военные действия, акты терроризма, угроза их совершения;
технологические ошибки;
отказы объектов программно-технической инфраструктуры;
ошибки в системных, специальных и (или) прикладных ПС;
отказы обеспечивающих систем;
отказы систем жизнеобеспечения;
ошибки персонала, вызванные неправильными действиями случайного или умышленного характера;
атаки со стороны злоумышленников с использованием ПС и (или) ПТС;
нарушение требований к информационной безопасности, установленных законодательством и локальными правовыми актами участника платежного рынка;
время реагирования на возникновение кризисной (сбойной) ситуации, учитывающее:
время, затраченное на поиск и обнаружение места либо возможной причины кризисной (сбойной) ситуации;
уровень оповещения руководства и (или) принятия им решений, включающий в себя схему оповещения при возникновении кризисной (сбойной) ситуации и схему принятия решений по устранению кризисной (сбойной) ситуации и восстановлению работоспособности участника платежного рынка (далее – схема оповещения и принятия решений);
время, необходимое на оповещение персонала и руководства участника платежного рынка, поставщиков платежных услуг, поставщиков технологических услуг и иных заинтересованных лиц, организаций, задействованных в осуществлении платежной деятельности участника платежного рынка и (или) привлекаемых к устранению кризисной (сбойной) ситуации, в соответствии со схемой оповещения и принятия решений;
время, необходимое на принятие решений по устранению кризисной (сбойной) ситуации и восстановлению работоспособности участника платежного рынка;
время восстановления работоспособности участника платежного рынка, учитывающее время, затраченное на устранение кризисной (сбойной) ситуации и проведение восстановительных работ, и время, необходимое для возврата к штатному режиму работы;
17.3. порядок работы участника платежного рынка в штатном режиме.
Описание порядка работы участника платежного рынка в штатном режиме учитывает объекты ПОНРВ, используемые для осуществления платежной деятельности участника платежного рынка в штатном режиме, состав основного персонала, обеспечивающего штатный режим работы участника платежного рынка и подлежащего обязательному резервированию, и выполняемые в штатном режиме функции и процедуры;
17.4. порядок работы участника платежного рынка в аварийном режиме.
Описание порядка работы участника платежного рынка в аварийном режиме учитывает объекты программно-технической инфраструктуры, которые должны быть использованы в качестве резерва для осуществления платежной деятельности участника платежного рынка в аварийном режиме в случае возникновения кризисной (сбойной) ситуации, состав персонала, который отвечает за восстановление работоспособности участника платежного рынка, а также состав резервного персонала, временно обеспечивающего эксплуатацию, сопровождение и обслуживание объектов программно-технической инфраструктуры в случае временной нетрудоспособности и (или) недоступности основного персонала, порядок замещения персонала, и выполняемые в аварийном режиме функции и процедуры;
17.5. сценарии возникновения и развития кризисных (сбойных) ситуаций в различные промежутки времени.
Сценарии возникновения и развития кризисных (сбойных) ситуаций учитывают способы, время восстановления работоспособности участника платежного рынка в случае возникновения кризисных (сбойных) ситуаций различных категорий и возможный переход кризисных (сбойных) ситуаций из одной категории в другую, оценку возможных потерь (ущерба) в результате возникновения кризисной (сбойной) ситуации (при наличии возможности предварительного расчета возможных потерь (ущерба);
17.6. схема (схемы) оповещения и принятия решений.
Схемы оповещения и принятия решений предусматривают распределение обязанностей по оповещению заинтересованных лиц и принятию решений по устранению кризисной (сбойной) ситуации и восстановлению работоспособности участника платежного рынка, способы оповещения, сроки оповещения, объем представляемой информации о кризисной (сбойной) ситуации и иной информации.
К заинтересованным лицам, подлежащим оповещению, относится персонал и руководство участника платежного рынка, поставщики платежных услуг, поставщики технологических услуг и иные заинтересованные лица, организации, задействованные в осуществлении платежной деятельности участника платежного рынка и (или) привлекаемые к устранению кризисной (сбойной) ситуации, а также пользователи платежных услуг (в том числе пользователи платежных инструментов), иные лица по решению участника платежного рынка.
Схемы оповещения и принятия решений предусматривают представление следующей информации:
информацию о возникновении кризисной (сбойной) ситуации, включая дату и время возникновения, предварительные причины, предварительную оценку последствий кризисной (сбойной) ситуации и иные сведения;
информацию о способе восстановления работоспособности участника платежного рынка, о ходе устранения кризисной (сбойной) ситуации, включая информацию о предпринятых и запланированных действиях по восстановлению работоспособности участника платежного рынка, о планируемых сроках восстановления работоспособности участника платежного рынка, возможных альтернативных способах осуществления платежной деятельности участника платежного рынка и иные сведения;
информацию об устранении кризисной (сбойной) ситуации, восстановлении работоспособности участника платежного рынка и возврате в штатный режим работы;
иную информацию по решению участника платежного рынка.
Схемы оповещения и принятия решений могут предусматривать автоматизированное информирование заинтересованных лиц с использованием различных каналов связи для своевременного принятия необходимых мер по минимизации ущерба, вызванного кризисной (сбойной) ситуацией;
17.7. описание процедур восстановления работоспособности объектов ПОНРВ и возврата работы участника платежного рынка в штатный режим.
Описание включает определенные участником платежного рынка способы восстановления работоспособности объектов ПОНРВ (с учетом планов гражданской обороны, предупреждения и ликвидации чрезвычайных ситуаций, имеющихся у участника платежного рынка), временные рамки выполнения мероприятий по восстановлению работоспособности участника платежного рынка, действия и порядок взаимодействия персонала, обслуживающего и сопровождающего объекты программно-технической инфраструктуры, в случае возникновения кризисных (сбойных) ситуаций различных категорий;
17.8. мероприятия, выполняемые после устранения кризисной (сбойной) ситуации, восстановления работоспособности участника платежного рынка и возврата к работе в штатном режиме.
К мероприятиям, выполняемым после устранения кризисной (сбойной) ситуации, восстановления работоспособности участника платежного рынка и возврата к работе в штатном режиме, относятся:
выявление и рассмотрение причин и последствий кризисной (сбойной) ситуации, мероприятий по восстановлению работоспособности участника платежного рынка;
документирование информации в виде акта анализа кризисной (сбойной) ситуации, акта перехода в режим аварийного функционирования и (или) иных документов;
планирование мер для предотвращения или минимизации вероятности возникновения аналогичных кризисных (сбойных) ситуаций в дальнейшей деятельности участника платежного рынка;
оценка предпринятых мер по восстановлению работоспособности участника платежного рынка на соответствие ПОНРВ, контроль исполнения ПОНРВ;
17.9. распределение ответственности при обеспечении непрерывной работы и восстановления работоспособности участника платежного рынка.
Участник платежного рынка обеспечивает распределение ответственности между персоналом и руководством участника платежного рынка, поставщиками платежных услуг, поставщиками технологических услуг и иными заинтересованными лицами, организациями, задействованными в осуществлении платежной деятельности участника платежного рынка и (или) привлекаемыми к устранению кризисной (сбойной) ситуации;
17.10. порядок перехода с основного вычислительного центра на резервный вычислительный центр и обратно (в случае организации участником платежного рынка резервного вычислительного центра), включающий порядок принятия решения о переходе с основного вычислительного центра на резервный вычислительный центр и обратно, процедуры перехода в случае возникновения кризисной (сбойной) ситуации.
Переход с основного вычислительного центра на резервный вычислительный центр и обратно осуществляется в соответствии с графиком перехода, утверждаемым руководителем (уполномоченным работником) участника платежного рынка;
17.11. порядок ознакомления персонала с ПОНРВ и проведения тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ.
Участник платежного рынка обеспечивает проведение на регулярной основе мероприятий, направленных на ознакомление персонала с ПОНРВ (в том числе после пересмотра ПОНРВ), повышение уровня знаний персонала в части действий, предусмотренных ПОНРВ. Данные мероприятия могут проводиться в рамках тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ.
Порядок проведения тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ, составляется с учетом вовлечения основного и резервного персонала, основных и резервных объектов программно-технической инфраструктуры, различных вероятных сценариев возникновения и развития кризисной (сбойной) ситуации в функционировании участника платежного рынка.
Результаты тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ, документируются в протоколе (акте) тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ. Протокол (акт) тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ, утверждается руководителем (уполномоченным работником) участника платежного рынка.
В протокол (акт) тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ, включается следующая информация:
заключение об успешности проведения тренировки (тестирования, контроля);
оценка полноты выполнения плана тренировки (тестирования, контроля), оценка соответствия действий персонала действиям, предусмотренным ПОНРВ;
описание установленных несоответствий, нарушений (в случае их наличия);
предложения по проведению корректирующих мероприятий и внесению изменений в ПОНРВ и (или) иные организационно-методические документы участника платежного рынка (в случае выявления необходимости внесения изменений);
17.12. порядок пересмотра ПОНРВ.
Полный пересмотр ПОНРВ проводится в следующих случаях:
при изменении перечня решаемых задач или конфигурации ПТК, обеспечивающих осуществление платежной деятельности участника платежного рынка, приводящем к изменению технологии обработки информации;
при получении неудовлетворительных (отрицательных) результатов тренировок (тестирования, контроля) действий, предусмотренных ПОНРВ;
после устранения кризисных (сбойных) ситуаций при выявлении недостатков ПОНРВ.
Частичный пересмотр ПОНРВ проводится при изменении конфигурации ПТК, обеспечивающих осуществление деятельности участника платежного рынка, не изменяющей технологии обработки информации, изменении состава персонала и (или) его должностных обязанностей.
Профилактический пересмотр ПОНРВ проводится на регулярной основе для поддержания ПОНРВ участника платежного рынка в актуальном состоянии или для оценки эффективности и корректности ПОНРВ в случае необходимости (в соответствии с критериями, определяемыми участником платежного рынка).
Результаты пересмотра документируются в протоколе (акте) пересмотра ПОНРВ или путем утверждения новой редакции ПОНРВ. Протокол (акт) пересмотра ПОНРВ утверждается руководителем (уполномоченным работником) участника платежного рынка.
18. В ПОНРВ включаются ссылки на организационно-методические документы, техническую и эксплуатационную документацию участника платежного рынка и (или) поставщика технологических услуг, оказывающего ему технологические услуги, в которых установлены требования к:
обеспечению информационной безопасности объектов программно-технической инфраструктуры;
структуре используемых информационных ресурсов, включая состав и конфигурацию объектов программно-технической инфраструктуры, описание функционирования ПТК, а также схемы их взаимодействия;
схемам технологического процесса взаимодействия объектов программно-технической инфраструктуры при осуществлении платежной деятельности;
техническому обслуживанию и тестированию объектов программно-технической инфраструктуры и составу работ, выполняемых в процессе его проведения;
мероприятиям по обеспечению непрерывной работы и восстановления работоспособности отдельных ПТК участника платежного рынка;
составу персонала и руководства участника платежного рынка, поставщиков платежных услуг, поставщиков технологических услуг и иных заинтересованных лиц, организаций, задействованных в осуществлении платежной деятельности участника платежного рынка и (или) привлекаемых к устранению кризисной (сбойной) ситуации, и способам их оповещения;
обеспечивающим системам и системам жизнеобеспечения;
наличию подлинников и рабочих экземпляров организационно-методических документов, технической и эксплуатационной документации для их целевого применения персоналом участника платежного рынка;
обеспечению персонала участника платежного рынка необходимыми актуальными организационно-методическими документами и ПОНРВ на своих рабочих местах;
распределению обязанностей по приобретению, сопровождению, эксплуатации и архивированию ПС.
19. Участник платежного рынка обеспечивает возможность осуществлять работы по восстановлению функционирования объектов программно-технической инфраструктуры, предусмотренные ПОНРВ, адекватные источнику и масштабам кризисной (сбойной) ситуации, затратам времени и видам ресурсов на восстановление работоспособности, включающие (учитывающие):
использование соответствующих схем оповещения и принятия решений в отношении заинтересованных лиц в обеспечении непрерывной работы и восстановления работоспособности участника платежного рынка;
использование нескольких технологий (систем) передачи информации (система передачи финансовой информации Национального банка, факс, электронная почта, мобильная связь);
использование резервных вычислительных центров, резервных центров обработки данных на случай невозможности восстановления работоспособности участника платежного рынка на основном вычислительном центре;
резервирование объектов программно-технической инфраструктуры;
резервирование СТ, наличие резервного канала связи для основного канала связи;
резервное копирование используемых участником платежного рынка лицензионных и сертифицированных ПС;
резервное копирование информационных ресурсов;
обеспечение бесперебойного электроснабжения критически значимых объектов программно-технической инфраструктуры;
защищенность силовых линий и каналов связи;
обеспечение разграничения доступа к информационным ресурсам (их составным частям);
использование средств и систем защиты информации;
определение и поддержание в актуальном состоянии состава и порядка взаимозаменяемости персонала.
ГЛАВА 5
ОБЕСПЕЧЕНИЕ БЕЗОТКАЗНОСТИ РАБОТЫ ОБЪЕКТОВ ПРОГРАММНО-ТЕХНИЧЕСКОЙ ИНФРАСТРУКТУРЫ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
20. Безотказность работы объектов программно-технической инфраструктуры участника платежного рынка достигается путем проведения мероприятий, направленных на предотвращение или минимизацию вероятности возникновения кризисных (сбойных) ситуаций и сокращение времени восстановления объектов программно-технической инфраструктуры в случае возникновения кризисных (сбойных) ситуаций.
21. Участник платежного рынка обеспечивает возможность резервного электроснабжения объектов программно-технической инфраструктуры и временную защиту от сбоев в работе электрической сети с целью завершения технологического этапа их работы и сохранения данных.
22. Для минимизации времени восстановления объектов программно-технической инфраструктуры обеспечивается проведение их технического обслуживания и тестирования в соответствии с разработанным участником платежного рынка порядком.
При разработке порядка проведения технического обслуживания и тестирования объектов программно-технической инфраструктуры предусматриваются:
выполнение требований технической документации производителя соответствующих объектов программно-технической инфраструктуры;
процедуры документирования результатов проведенного технического обслуживания и тестирования объектов программно-технической инфраструктуры и учета дефектов, обнаруженных в ходе выполнения работ;
процедуры внешнего и внутреннего осмотра объектов программно-технической инфраструктуры1;
проверка параметров настроек работоспособности объектов программно-технической инфраструктуры;
тестирование взаимодействия объектов программно-технической инфраструктуры2;
плановые проверки сертифицированными антивирусными средствами с соблюдением частоты и содержания проводимых проверок в соответствии с применяемой политикой информационной безопасности3.
______________________________
1 Внутренний осмотр отдельных объектов программно-технической инфраструктуры может не проводиться, если это влечет нарушение порядка их гарантийного обслуживания или не предусмотрено технической документацией производителя.
2 Тестирование взаимодействия отдельных объектов программно-технической инфраструктуры может не проводиться в случае, если режим работы данных объектов программно-технической инфраструктуры не предполагает остановку их работы.
3 Плановые проверки сертифицированными антивирусными средствами могут не осуществляться при отсутствии технической возможности проверки объектов программно-технической инфраструктуры и наличии постоянной защиты ПС сертифицированными антивирусными средствами.
23. Участник платежного рынка проводит анализ кризисных (сбойных) ситуаций, возникших в ходе осуществления им платежной деятельности, и дефектов, обнаруженных в ходе технического обслуживания и тестирования объектов программно-технической инфраструктуры.
Результаты проведенного анализа документируются в соответствии с порядком, закрепленным в ПОНРВ.
На основании результатов проведенного анализа участник платежного рынка формирует план корректирующих мероприятий для предотвращения возникновения или минимизации вероятности возникновения аналогичных кризисных (сбойных) ситуаций в дальнейшей платежной деятельности участника платежного рынка и устранения причин выявленных дефектов, а также минимизации времени восстановления при возникновении кризисных (сбойных) ситуаций.
24. Участник разрабатывает порядок учета ПТК и оборудования СТ, используемых для осуществления платежной деятельности.
При проведении мероприятий по учету ПТК и оборудования СТ, используемых при осуществлении платежной деятельности, документируется следующая информация:
наименование ПТК или оборудования СТ;
дата ввода в эксплуатацию ПТК или оборудования СТ;
данные персонала, ответственного за эксплуатацию ПТК или оборудования СТ;
данные персонала, ответственного за техническую поддержку ПТК или оборудования СТ (при наличии информации);
состав ТС и их размещение;
состав ПС;
перечень технической и эксплуатационной документации;
основной и резервный каналы связи (для СТ);
перечень резервного оборудования с указанием места его размещения.
ГЛАВА 6
ВОССТАНОВЛЕНИЕ РАБОТОСПОСОБНОСТИ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
25. В штатном режиме работы участника платежного рынка все критичные ресурсы находятся в работоспособном состоянии, для каждого критичного ресурса обеспечивается работоспособный резерв, обеспечивается возможность выполнения персоналом своих должностных обязанностей в полном объеме.
26. Кризисная (сбойная) ситуация обнаруживается дежурным персоналом (иными ответственными работниками). Дежурным персоналом, обнаружившим кризисную (сбойную) ситуацию, обеспечивается оповещение о возникшей кризисной (сбойной) ситуации в соответствии со схемой оповещения и принятия решений, утвержденной в ПОНРВ.
27. После обнаружения кризисной (сбойной) ситуации в соответствии со схемой оповещения и принятия решений по устранению кризисной (сбойной) ситуации и при наличии дополнительной информации о кризисной (сбойной) ситуации от поставщиков платежных услуг и поставщиков технологических услуг, задействованных в осуществлении платежной деятельности участника платежного рынка, участником платежного рынка принимается решение о способе восстановления работоспособности участника платежного рынка и при необходимости о переходе в аварийный режим работы. Обеспечивается оповещение заинтересованных лиц о способе восстановления работоспособности участника платежного рынка, о ходе устранения кризисной (сбойной) ситуации в соответствии со схемой оповещения и принятия решений.
В аварийном режиме работы платежная деятельность участника платежного рынка организуется на основном вычислительном центре и (или) резервном вычислительном центре (в случае организации участником платежного рынка резервного вычислительного центра), основным и (или) резервным персоналом в соответствии с порядком, установленным в ПОНРВ.
28. Мероприятия по устранению кризисной (сбойной) ситуации и восстановлению работоспособности участника платежного рынка начинаются в пределах календарного дня, когда была обнаружена кризисная (сбойная) ситуация, в соответствии с временными рамками, установленными в ПОНРВ.
В случае возникновения кризисной (сбойной) ситуации в функционировании объектов программно-технической инфраструктуры восстановление работоспособности участника платежного рынка проводится в соответствии с технической документацией производителя объектов программно-технической инфраструктуры (поставщика телекоммуникационных услуг) и (или) соответствующими документами участника платежного рынка.
Для устранения кризисной (сбойной) ситуации в функционировании ТС, ПТС могут привлекаться на договорной основе специалисты производителя или поставщика ТС, ПТС и (или) организации, обеспечивающей техническое обслуживание ТС, ПТС.
Для устранения кризисной (сбойной) ситуации могут привлекаться на договорной основе специалисты разработчика (поставщика) ПС и (или) сопровождающей данные ПС организации.
29. После устранения кризисной (сбойной) ситуации и восстановления работоспособности участника платежного рынка проводится тестирование объектов программно-технической инфраструктуры, работоспособность которых была нарушена вследствие возникновения кризисной (сбойной) ситуации, на предмет готовности к функционированию в штатном режиме (при необходимости).
После получения положительных результатов тестирования объектов программно-технической инфраструктуры, работоспособность которых была нарушена вследствие возникновения кризисной (сбойной) ситуации (в случае проведения тестирования), организуется возврат к штатному режиму работы.
30. Мероприятия по восстановлению работоспособности участника платежного рынка фиксируются в соответствии с локальными правовыми актами участника платежного рынка.
31. Факт кризисной (сбойной) ситуации и основная информация о ней (дата и время возникновения и устранения, причины возникновения, мероприятия по восстановлению работоспособности, иные сведения) фиксируется в соответствии с разработанным участником платежного рынка порядком. Учету подлежат все случаи кризисных (сбойных) ситуаций.
32. Участник платежного рынка проводит анализ кризисных (сбойных) ситуаций и на основании результатов проведенного анализа формирует план корректирующих мероприятий для предотвращения возникновения или минимизации вероятности возникновения аналогичных кризисных (сбойных) ситуаций в дальнейшей платежной деятельности участника платежного рынка, а также минимизации времени восстановления при возникновении аналогичных кризисных (сбойных) ситуаций.
| Приложение к стандарту проведения расчетов |
ПЕРЕЧЕНЬ
обязательных требований по обеспечению непрерывной работы и восстановления работоспособности участника платежного рынка
Для целей настоящего приложения используются следующие сокращения наименований поставщиков платежных услуг:
КЦ – клиринговый центр;
ОПС – оператор платежной системы;
ПА – платежный агрегатор;
ПИП – поставщик информационных платежных услуг;
ПК – платежный курьер;
ППИ – поставщик платежных инструментов;
ППУ ИП – поставщик платежных услуг инициирования платежа;
ПЦ – процессинговый центр;
ПЭД – поставщик электронных денег;
РЦ – расчетный центр.
Для целей настоящего приложения используются следующие обозначения типов значимости платежных систем:
Иная – платежная система, которая не отнесена к значимым платежным системам;
ПтЗ – платежная система, которой присвоен тип значимости «потенциально значимая платежная система»;
СтЗ – платежная система, которой присвоен тип значимости «системно значимая платежная система»;
СцЗ – платежная система, которой присвоен тип значимости «социально значимая платежная система».
Требование | Условие об обязательности выполнения требования по обеспечению непрерывной работы и восстановления работоспособности участника платежного рынка1 | |||||||||||
ОПС, РЦ, ПА (в случае участия в платежной системе) в зависимости от типа значимости платежной системы | ППУ ИП | ПА, кроме ПК | ПК | ППИ | ПЭД | КЦ | ПЦ | ПИП | ||||
СтЗ | ПтЗ | СцЗ | Иная | |||||||||
1. Требования к организационно-методическому и документационному обеспечению участника платежного рынка | ||||||||||||
1.1. Разделение подлинников и рабочих экземпляров организационно-методических документов, технической и эксплуатационной документации | + | + | + | + | + | + | + | + | + | + | + | + |
1.2. Обеспечение персонала рабочими экземплярами организационно-методических документов, технической и эксплуатационной документации в достаточном количестве, определяемом участником платежного рынка | + | + | + | + | + | + | + | + | + | + | + | + |
1.3. Хранение подлинников организационно-методических документов, технической и эксплуатационной документации отдельно от рабочих экземпляров | + | + | + | + | + | + | + | + | + | + | + | + |
1.4. Разграничение доступа к подлинникам и рабочим экземплярам организационно-методических документов, технической и эксплуатационной документации | + | + | + | + | + | + | + | + | + | + | + | + |
1.5. Принятие мер по обеспечению сохранности организационно-методических документов, технической и эксплуатационной документации | + | + | + | + | + | + | + | + | + | + | + | + |
1.6. Проведение пересмотра организационно-методических документов, технической и эксплуатационной документации и их актуализации (при необходимости) на регулярной основе | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год |
2. Требования к ПОНРВ участника платежного рынка | ||||||||||||
2.1. Наличие ПОНРВ, утвержденного участником платежного рынка | + | + | + | + | + | + | + | + | + | + | + | + |
2.2. Наличие в ПОНРВ перечня объектов ПОНРВ | + | + | + | + | + | + | + | + | + | + | + | + |
2.3. Наличие в ПОНРВ категорирования кризисных (сбойных) ситуаций | + | + | + | + | + | + | + | + | + | + | + | + |
2.4. Наличие в ПОНРВ описания порядка работы участника платежного рынка в штатном режиме | + | + | + | + | + | + | + | + | + | + | + | + |
2.5. Наличие в ПОНРВ описания порядка работы участника платежного рынка в аварийном режиме | + | + | + | + | + | + | + | + | + | + | + | + |
2.6. Наличие в ПОНРВ сценариев возникновения и развития кризисных (сбойных) ситуаций в различные промежутки времени | + | + | + | + | + | + | + | + | + | + | + | + |
2.7. Наличие в ПОНРВ схемы (схем) оповещения и принятия решений | + | + | + | + | + | + | + | + | + | + | + | + |
2.8. Наличие в ПОНРВ описания процедур восстановления работоспособности объектов ПОНРВ участника платежного рынка и возврата работы участника платежного рынка в штатный режим | + | + | + | + | + | + | + | + | + | + | + | + |
2.9. Наличие в ПОНРВ описания мероприятий, выполняемых после устранения кризисной (сбойной) ситуации, восстановления работоспособности участника платежного рынка и возврата к работе в штатном режиме | + | + | + | + | + | + | + | + | + | + | + | + |
2.10. Наличие в ПОНРВ описания распределения ответственности при обеспечении непрерывной работы и восстановления работоспособности участника платежного рынка | + | + | + | + | + | + | + | + | + | + | + | + |
2.11. Наличие в ПОНРВ порядка ознакомления персонала с ПОНРВ и проведения тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ | + | + | + | + | + | + | + | + | + | + | + | + |
2.12. Наличие в ПОНРВ порядка пересмотра ПОНРВ | + | + | + | + | + | + | + | + | + | + | + | + |
2.13. Проведение тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ, на регулярной основе в соответствии с утвержденными участником платежного рынка графиком и программой (методикой) | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | – | не реже 1 раз в год | не реже 1 раз в год | не реже 1 раза в год | не реже 1 раза в год | – |
2.14. Выявление необходимости и проведение полного пересмотра ПОНРВ и его актуализации (при необходимости) | + | + | + | + | + | + | + | + | + | + | + | + |
2.15. Выявление необходимости и проведение частичного пересмотра ПОНРВ и его актуализации (при необходимости) | + | + | + | + | + | + | + | + | + | + | + | + |
2.16. Проведение профилактического пересмотра ПОНРВ и его актуализации (при необходимости) на регулярной основе2 | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год |
3. Требования к обеспечению безотказности работы объектов программно-технической инфраструктуры участника платежного рынка | ||||||||||||
3.1. Соблюдение правил и процедур эксплуатации объектов программно-технической инфраструктуры, установленных в технической и эксплуатационной документации производителя | + | + | + | + | + | + | + | + | + | + | + | + |
3.2. Определение необходимости и организация дежурства специалистов по техническому сопровождению объектов программно-технической инфраструктуры | + | + | + | – | – | – | – | – | – | знач. | знач. | – |
3.3. Резервирование объектов программно-технической инфраструктуры, включая комплектующие изделия и детали, достаточные для восстановления их работоспособности | + | + | + | + | + | + | – | – | – | + | + | – |
3.4. Обеспечение доступности резервных объектов программно-технической инфраструктуры, комплектующих изделий и деталей к использованию в течение времени, предусмотренного графиком работы объектов программно-технической инфраструктуры, персоналу и руководству участника платежного рынка, поставщиков платежных услуг, поставщиков технологических услуг и иных заинтересованных лиц, организаций, задействованных в осуществлении платежной деятельности участника платежного рынка и (или) привлекаемых к устранению кризисной (сбойной) ситуации | + | + | + | + | + | + | – | – | – | + | + | – |
3.5. Контроль работоспособности объектов программно-технической инфраструктуры (в том числе резервных) | + | + | + | + | + | + | – | + | + | + | + | – |
3.6. Разграничение доступа к объектам программно-технической инфраструктуры в соответствии с применяемой политикой информационной безопасности | + | + | + | + | + | + | + | + | + | + | + | + |
3.7. Проведение технического обслуживания и тестирования объектов программно-технической инфраструктуры (в том числе резервных) на регулярной основе | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | – | – | – | не реже 1 раза в год | не реже 1 раза в год | – |
3.8. Проведение анализа кризисных (сбойных) ситуаций в функционировании объектов программно-технической инфраструктуры и дефектов, обнаруженных в ходе их технического обслуживания и тестирования, на регулярной основе | + | + | + | + | + | + | – | – | – | + | + | – |
4. Требования к организации каналов связи участника платежного рынка | ||||||||||||
4.1. Организация резервного канала связи в дополнение к основному каналу связи | + | + | + | + | + | + | – | – | – | + | + | – |
4.2. Аренда резервного канала связи у поставщика технологических услуг, отличного от поставщика, предоставляющего основной канал связи (в случае отсутствия собственных каналов связи и их аренды у поставщика технологических услуг) | + | + | – | – | + | + | – | – | – | знач. | знач. | – |
4.3. Автоматическое переключение между основным и резервным каналами связи в случае возникновения кризисной (сбойной) ситуации | + | + | + | – | – | + | – | – | – | знач. | знач. | – |
4.4. Мониторинг доступности каналов связи | + | + | + | + | + | + | + | + | + | + | + | + |
4.5. Мониторинг загрузки каналов связи | + | + | + | + | – | – | – | – | + | + | + | + |
4.6. Оценка средней и пиковой величины пропускной способности оборудования СТ, необходимой для осуществления платежной деятельности | + | + | + | – | – | – | – | – | – | знач. | знач. | – |
4.7. Обеспечение пропускной способности основного канала связи в объеме не менее 120 % от пиковой величины пропускной способности оборудования СТ, необходимой для осуществления платежной деятельности | + | + | + | – | – | – | – | – | – | знач. | знач. | – |
4.8. Обеспечение пропускной способности резервного канала связи в объеме не менее 100 % от средней величины пропускной способности оборудования СТ, необходимой для осуществления платежной деятельности | + | + | + | – | – | – | – | – | – | знач. | знач. | – |
4.9. Наличие у персонала контактных данных службы технической поддержки поставщика технологических услуг, предоставляющего каналы связи (в случае отсутствия собственных каналов связи и их аренды у поставщика технологических услуг) | + | + | + | + | + | + | + | + | + | + | + | + |
5. Требования к обеспечению работоспособности ПС участника платежного рынка | ||||||||||||
5.1. Использование ПС, соответствующих требованиям стандартов проведения расчетов (при наличии стандартов проведения расчетов, устанавливающих требования к соответствующим ПС) | + | + | + | + | + | + | + | + | + | + | + | + |
5.2. Резервирование ПС и создание учтенных копий ПС (рабочих и резервных) | + | + | + | + | + | – | – | – | – | + | + | – |
5.3. Хранение резервных учтенных копий ПС отдельно от рабочих | + | + | + | + | + | – | – | – | – | + | + | – |
5.4. Проведение приемочных испытаний и проверки работоспособности разрабатываемых (поставляемых) ПС и документирования результатов проверки в соответствии с разработанным участником платежного рынка порядком (либо обеспечение получения соответствующего документального подтверждения от производителя (поставщика) ПС) | + | + | + | + | + | – | – | – | – | + | + | – |
5.5. Проведение проверки ПС сертифицированными антивирусными средствами перед вводом в эксплуатацию разрабатываемых (поставляемых) ПС и документирования результатов проверки в соответствии с разработанным участником платежного рынка порядком и применяемой политикой информационной безопасности (либо обеспечение получения соответствующего документального подтверждения от производителя (поставщика) ПС) | + | + | + | + | + | – | – | – | – | + | + | – |
5.6. Учет и хранение ПС (учтенных копий ПС, подлинников технической и эксплуатационной документации на ПС, дубликатов и рабочих копий на носителях данных) в соответствии с разработанным участником платежного рынка порядком до введения ПС в эксплуатацию | + | + | + | + | + | – | – | – | – | + | + | – |
5.7. Проверка носителя данных с ПС на работоспособность и проверка сертифицированными антивирусными средствами на оборудовании, используемом для тестирования ПС, перед передачей ПС из технического архива в эксплуатацию в соответствии с применяемой политикой информационной безопасности | + | + | + | + | + | – | – | – | – | + | + | – |
5.8. Обеспечение доступности рабочих копий ПС на носителях данных, технической и эксплуатационной документации, документации по восстановлению работоспособности ПС персоналу, обеспечивающему эксплуатацию ПС | + | + | + | + | + | – | – | – | – | + | + | – |
6. Требования к организации работы с информационными ресурсами участника платежного рынка и обеспечению их сохранности | ||||||||||||
6.1. Использование для работы с информационными ресурсами лицензионных и сертифицированных ПС (в случае если ПС подлежит обязательной сертификации на территории Республики Беларусь) | + | + | + | + | + | + | + | + | + | + | + | + |
6.2. Идентификация, классификация и документированный учет информационных ресурсов | + | + | + | + | + | + | + | + | + | + | + | + |
6.3. Разделение информационных ресурсов по среде использования (среда разработки, среда тестирования, производственная среда) | + | + | + | + | + | + | – | – | – | + | + | – |
6.4. Распределение зон ответственности при эксплуатации, сопровождении и обслуживании информационных ресурсов | + | + | + | + | – | – | – | – | – | + | + | – |
6.5. Управление процедурами создания эталонных и рабочих копий информационных ресурсов, а также их резерва с соблюдением принципа территориального разделения при хранении эталонных и резервных копий информационных ресурсов | + | + | + | + | – | – | – | – | – | + | + | – |
6.6. Соблюдение установленного участником платежного рынка порядка ввода и вывода информационных ресурсов из эксплуатации и последующего уничтожения информации и ПС с устройств их хранения, физического уничтожения носителей данных | + | + | + | + | + | + | + | + | + | + | + | + |
6.7. Хранение информационных ресурсов, подлежащих хранению, в создаваемом архиве либо с привлечением соответствующего поставщика технологических услуг (в случае если требования платежной системы позволяют привлечение поставщика технологических услуг для указанных целей) | + | + | + | + | – | + | – | – | – | + | + | – |
6.8. Обеспечение доступности архивов, организационно-методических документов, технической и эксплуатационной документации по восстановлению целостности информационных ресурсов персоналу, обеспечивающему функционирование АС, в течение времени, предусмотренного графиком работы АС | + | + | + | + | + | + | – | – | – | + | + | – |
6.9. Восстановление информационных ресурсов в случае нарушения их целостности из резервных копий информационных ресурсов в соответствии с разработанным участником платежного рынка порядком | + | + | + | + | – | + | – | – | – | + | + | + |
6.10. Разграничение доступа к информационным ресурсам (их составным частям) в соответствии с применяемой политикой информационной безопасности | + | + | + | + | + | + | + | + | + | + | + | + |
6.11. Защита резервных копий информационных ресурсов во время их передачи и хранения в соответствии с применяемой политикой информационной безопасности | + | + | + | + | + | + | + | + | + | + | + | + |
6.12. Контроль над процессом создания резервных копий информационных ресурсов в целях выявления систематических ошибок и иных проблем резервного копирования | + | + | + | + | – | + | – | – | – | + | + | + |
6.13. Проведение восстановления данных из резервных копий информационных ресурсов и контроля корректности копий на регулярной основе3 | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | – | – | – | – | – | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год |
7. Требования к организации обеспечивающих систем участника платежного рынка | ||||||||||||
7.1. Соблюдение правил и процедур эксплуатации обеспечивающих систем, установленных в технической и эксплуатационной документации производителя | + | + | + | + | + | + | + | + | + | + | + | + |
7.2. Принятие мер по обеспечению безопасности персонала при организации работы и эксплуатации обеспечивающих систем | + | + | + | + | + | + | + | + | + | + | + | + |
7.3. Принятие мер по обеспечению безопасности зданий и помещений, в которых размещены объекты программно-технической инфраструктуры | + | + | + | + | + | + | + | + | + | + | + | + |
7.4. Разграничение доступа в помещения, в которых размещены объекты программно-технической инфраструктуры, в соответствии с применяемой политикой информационной безопасности | + | + | + | + | + | + | + | + | + | + | + | + |
7.5. Недопущение несанкционированного доступа к обеспечивающим системам | + | + | + | + | + | + | + | + | + | + | + | + |
7.6. Проведение профилактических мероприятий по поддержанию обеспечивающих систем в работоспособном состоянии на регулярной основе в соответствии с утвержденным участником платежного рынка графиком | + | + | + | + | + | + | + | + | + | + | + | + |
8. Требования к организации систем жизнеобеспечения участника платежного рынка | ||||||||||||
8.1. Соблюдение правил и процедур эксплуатации систем жизнеобеспечения, установленных в технической и эксплуатационной документации производителя | + | + | + | + | + | + | + | + | + | + | + | + |
8.2. Поддержание в помещениях, в которых размещены ТС, температурно-влажностного режима, установленного в технической документации производителя соответствующих ТС | + | + | + | + | + | + | + | + | + | + | + | + |
8.3. Контроль за использованием местных нагревательных и отопительных приборов, питаемых теплоносителями, в соответствии с требованиями производителя по их использованию | + | + | + | + | + | + | + | + | + | + | + | + |
8.4. Организация системы отопления, вентиляции, кондиционирования воздуха и пожарной безопасности зданий участника платежного рынка в соответствии с требованиями, предъявляемыми для их проектирования и модернизации | + | + | + | + | + | + | + | + | + | + | + | + |
8.5. Обеспечение зданий участника платежного рынка системами холодного и горячего водоснабжения, канализации и водостоков, противопожарного водоснабжения | + | + | + | + | + | + | + | + | + | + | + | + |
8.6. Использование выделенной линии питания, защищенной от перенапряжения специальными устройствами и не связанной с системой электропитания осветительного и другого электрооборудования, для электроснабжения объектов программно-технической инфраструктуры | + | + | + | + | + | + | – | + | + | + | + | – |
8.7. Использование источников бесперебойного питания достаточной мощности для электроснабжения объектов программно-технической инфраструктуры в случае временных сбоев в работе электрической сети | не менее 45 минут | не менее 30 минут | не менее 30 минут | – | – | – | – | знач. | знач. | знач. | знач. | – |
8.8. Организация двух независимых входов подачи электроэнергии в здания участника платежного рынка от двух подстанций | + | + | + | + | – | – | – | – | – | + | + | – |
8.9. Наладка и периодическая проверка работоспособности автономной дизель-генераторной установки (при ее наличии) | + | + | + | + | – | + | – | – | – | + | + | – |
8.10. Проведение профилактических мероприятий по поддержанию систем жизнеобеспечения в работоспособном состоянии на регулярной основе в соответствии с утвержденным участником платежного рынка графиком | + | + | + | + | + | + | – | – | – | + | + | – |
8.11. Проведение периодической проверки резервного электроснабжения объектов программно-технической инфраструктуры4 | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | не реже 1 раза в год | – | – | – | не реже 1 раза в год | не реже 1 раза в год | – |
9. Требования к персоналу участника платежного рынка, не являющегося индивидуальным предпринимателем | ||||||||||||
9.1. Проведение мероприятий по подбору и подготовке персонала с необходимой квалификацией и образованием, соответствующим профилю выполняемых обязанностей | + | + | + | + | + | + | + | + | + | + | + | + |
9.2. Проведение подготовки (инструктажа) персонала по вопросам использования объектов программно-технической инфраструктуры, информационных ресурсов | + | + | + | + | + | + | + | + | + | + | + | + |
9.3. Проведение аттестации персонала и выполнения рекомендаций по результатам аттестации | + | + | + | + | + | + | + | + | + | + | + | + |
9.4. Прохождение медицинского осмотра персонала (медицинского освидетельствования) и выполнение рекомендаций по его результатам в соответствии с требованиями законодательства | + | + | + | + | + | + | + | + | + | + | + | + |
9.5. Проведение мероприятий по учету мотивации персонала к положительным результатам работы | + | + | + | + | – | – | – | + | + | + | + | – |
9.6. Проведение мероприятий по снижению текучести кадров | + | + | + | + | + | + | + | + | + | + | + | + |
9.7. Фиксирование должностных обязанностей, ответственности и прав персонала в должностных инструкциях, достаточных для технического обеспечения осуществления платежной деятельности участника платежного рынка | + | + | + | + | + | + | + | + | + | + | + | + |
9.8. Доведение должностных инструкций до персонала под роспись | + | + | + | + | + | + | + | + | + | + | + | + |
9.9. Назначение основного персонала, обеспечивающего эксплуатацию, сопровождение и обслуживание объектов программно-технической инфраструктуры, на постоянной основе согласно своим должностным обязанностям | + | + | + | + | + | + | + | + | + | + | + | + |
9.10. Назначение резервного персонала, временно обеспечивающего эксплуатацию, сопровождение и обслуживание объектов программно-технической инфраструктуры, в случае временной нетрудоспособности и (или) недоступности (в том числе по причине возникновения кризисной (сбойной) ситуации) основного персонала, выполняющего данные функции на постоянной основе согласно своим должностным обязанностям | + | + | + | + | – | – | – | – | – | + | + | – |
10. Требования к организации резервного вычислительного центра участника платежного рынка | ||||||||||||
10.1. Организация резервного вычислительного центра5 | + | + | + | – | – | – | – | – | – | – | – | – |
10.2. Обеспечение информационной и технической совместимости объектов программно-технической инфраструктуры основного и резервного вычислительных центров, обеспечивающей их полную взаимозаменяемость | + | + | + | – | – | – | – | – | – | – | – | – |
10.3. Обеспечение персонала участника платежного рынка рабочими экземплярами организационно-методических документов, технической и эксплуатационной документации в достаточном количестве на рабочих местах в резервном вычислительном центре | + | + | + | – | – | – | – | – | – | – | – | – |
10.4. Обеспечение доступа персонала участника платежного рынка к информационным ресурсам с резервного вычислительного центра (в соответствии с применяемой политикой информационной безопасности) | + | + | + | – | – | – | – | – | – | – | – | – |
10.5. Оборудование помещений резервного вычислительного центра участника платежного рынка системами жизнеобеспечения, обеспечивающими системами | + | + | + | – | – | – | – | – | – | – | – | – |
10.6. Организация системы электроснабжения резервного вычислительного центра, обеспечивающей функционирование объектов программно-технической инфраструктуры с использованием выделенной линии питания, защищенной от перенапряжения специальными устройствами и не связанной с системой электропитания осветительного и другого электрооборудования | + | + | + | – | – | – | – | – | – | – | – | – |
10.7. Организация двух независимых входов подачи электроэнергии от двух разных подстанций в здание резервного вычислительного центра | + | + | + | – | – | – | – | – | – | – | – | – |
10.8. Использование выделенной линии питания, защищенной от перенапряжения специальными устройствами и не связанной с системой электропитания осветительного и другого электрооборудования, для электроснабжения объектов программно-технической инфраструктуры резервного вычислительного центра | + | + | + | – | – | – | – | – | – | – | – | – |
10.9. Использование источников бесперебойного питания достаточной мощности для электроснабжения объектов программно-технической инфраструктуры резервного вычислительного центра в случае временных сбоев в работе электрической сети | не менее 45 минут | не менее 30 минут | не менее 30 минут | – | – | – | – | – | – | – | – | – |
10.10. Обеспечение территориальной удаленности резервного вычислительного центра участника платежного рынка от основного вычислительного центра участника платежного рынка | не менее 5 км | не менее 3 км | не менее 3 км | – | – | – | – | – | – | – | – | – |
10.11. Организация передачи данных между резервным вычислительным центром участника платежного рынка и основным или резервным вычислительным центром платежной системы с использованием отдельного канала связи6 | + | + | + | – | – | – | – | – | – | – | – | – |
10.12. Организация передачи данных между основным и резервным вычислительными центрами участника платежного рынка без использования физических каналов связи с основным и резервным вычислительными центрами платежной системы | + | + | + | – | – | – | – | – | – | – | – | – |
10.13. Наличие в ПОНРВ порядка перехода с основного вычислительного центра на резервный вычислительный центр и обратно (в случае организации участником платежного рынка резервного вычислительного центра) | + | + | + | – | – | – | – | – | – | – | – | – |
10.14. Обеспечение контроля работоспособности резервного вычислительного центра путем планового перехода на его использование вместо основного вычислительного центра в соответствии с утвержденным участником платежного рынка графиком7 | не реже 2 раз в год | не реже 1 раза в год | не реже 1 раза в год | – | – | – | – | – | – | – | – | – |
11. Требования к центру обработки данных, используемому участником платежного рынка для осуществления платежной деятельности (в случае использования услуг предоставления площадей центров обработки данных и иных услуг, основанных на облачных технологиях) | ||||||||||||
11.1. Защита информации, распространение и (или) предоставление которой ограничено, наличие аттестации и использование средств защиты информации в соответствии с требованиями законодательства об информации, информатизации и защите информации | + | + | + | + | + | + | + | + | + | + | + | + |
11.2. Наличие серверного оборудования и оборудования хранения данных, удовлетворяющего требованиям по надежности и резервированию ТС на уровне не ниже 2 (N+1) | + | + | + | + | + | – | – | – | – | + | + | – |
11.3. Наличие (предоставление) защищенных каналов связи для удаленного администрирования, а также для соединения с иными защищаемыми (аттестованными) объектами (при их наличии), которые организованы с использованием средств защиты информации (средств криптографической защиты информации), соответствующих требованиям законодательства об информации, информатизации и защите информации | + | + | + | + | + | + | – | – | + | + | + | + |
11.4. Наличие внедренной системы управления (менеджмента) информационной безопасности, имеющей сертификат соответствия требованиям ISO/IEC 27001 «Information technology – Security techniques – Information security management systems – Requirements» и (или) государственного стандарта Республики Беларусь СТБ ISO/IEC 27001-2016 «Информационные технологии. Методы обеспечения безопасности. Системы менеджмента информационной безопасности. Требования», утвержденного постановлением Государственного комитета по стандартизации Республики Беларусь от 1 апреля 2016 г. № 27 | + | + | + | + | + | + | – | – | – | + | + | – |
11.5. Соответствие требованиям стандарта безопасности данных индустрии банковских платежных карточек PCI DSS для среды банковских платежных карточек (в случае приема и передачи на исполнение платежных указаний (платежных инструкций) посредством платежных инструментов) | + | + | + | + | + | + | – | – | – | + | + | – |
11.6. Наличие платформы виртуализации и компонентов виртуализации сети, имеющей сертификат соответствия и поддерживающей функции: | + | + | + | + | + | – | – | – | – | + | + | – |
12. Требования к информированию о кризисной (сбойной) ситуации | ||||||||||||
12.1. Информирование в случае плановых перерывов или возникновения кризисных (сбойных) ситуаций, повлекших нарушение работоспособности объектов программно-технической инфраструктуры, обеспечивающих обслуживание пользователей платежных инструментов, пользователей платежных инструментов о невозможности осуществления операций при использовании платежных инструментов и планируемых сроках восстановления работоспособности объектов программно-технической инфраструктуры, обеспечивающих обслуживание пользователей платежных инструментов, с использованием не менее двух электронных каналов информирования (официальный сайт участника платежного рынка в глобальной компьютерной сети Интернет; страница, аккаунт, канал участника платежного рынка в социальных сетях, мессенджерах; SMS-сообщение; иные электронные каналы информирования из доступных участнику платежного рынка) | + | + | + | + | + | + | + | + | + | + | + | + |
12.2. Информирование Национального банка о кризисных (сбойных) ситуациях в соответствии с установленным Национальным банком порядком представления отчетности и иной информации | + | + | + | + | + | + | + | + | + | + | + | + |
12.3. Закрепление порядка взаимодействия (информирование, оповещение) участника платежного рынка с поставщиком платежных услуг, поставщиком технологических услуг, оказывающим услуги данному участнику платежного рынка в случае возникновения кризисных (сбойных) ситуаций, в договорах, соглашениях, иных документах | + | + | + | + | + | + | + | + | + | + | + | + |
______________________________
1 Условие об обязательности выполнения требования может принимать следующие значения:
«+», если требование является обязательным к выполнению соответствующим участником платежного рынка;
«–», если требование не является обязательным к выполнению либо неприменимо к соответствующему участнику платежного рынка;
«знач.», если обязательность выполнения требования устанавливается в зависимости от типа значимости платежной системы, участником которой является соответствующий участник платежного рынка;
иные значения, детализирующие требование, которое является обязательным к выполнению соответствующим участником платежного рынка.
2 Профилактический пересмотр ПОНРВ может не проводиться, если участником платежного рынка в течение установленной периодичности проведения профилактического пересмотра проводился полный либо частичный пересмотр ПОНРВ и актуализация ПОНРВ (в случае заключения о необходимости актуализации).
3 Восстановление данных из резервных копий и контроль корректности копий может проводиться в рамках тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ.
4 Проверка резервного электроснабжения объектов программно-технической инфраструктуры может проводиться в рамках тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ.
5 Допускается объединение основного вычислительного центра и резервного вычислительного центра в единую логическую структуру, в том числе с обеспечением возможности динамического перераспределения компонентов АС между ними.
6 Допускается использование данного канала связи в качестве резервного канала связи для основных объектов программно-технической инфраструктуры.
7 Восстановление данных из резервных копий и контроль корректности копий может проводиться в рамках тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ.