ПОСТАНОВЛЕНИЕ ПРАВЛЕНИЯ НАЦИОНАЛЬНОГО БАНКА РЕСПУБЛИКИ БЕЛАРУСЬ
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>
На основании абзаца шестьдесят шестого статьи 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. В настоящем стандарте используются следующие термины и их определения:
аварийный режим – режим работы участника платежного рынка во время кризисной (сбойной) ситуации;
автоматизированная система (далее – АС) – система, реализующая информационную технологию выполнения установленных задач и состоящая из персонала и комплекса средств автоматизации его деятельности, включающих программные средства, технические средства, программно-технические средства, программно-технические комплексы и средства телекоммуникаций;
безотказность – свойство объекта программно-технической инфраструктуры непрерывно сохранять работоспособное состояние в течение некоторого времени;
восстановление – процесс перевода объекта программно-технической инфраструктуры в работоспособное состояние из неработоспособного состояния;
данные – информация, представленная в виде, пригодном для обработки автоматическими средствами при возможном участии человека;
кризисная (сбойная) ситуация – чрезвычайное происшествие, приводящее к нарушению возможности осуществления участником платежного рынка своей деятельности вследствие нарушения работоспособности критичных ресурсов участника платежного рынка и (или) невозможности персонала выполнять свои должностные обязанности в полном объеме;
критичные ресурсы – ресурсы, необходимые для обеспечения надежного, непрерывного, безопасного и эффективного осуществления деятельности участника платежного рынка;
носитель данных – материальный объект, предназначенный для записи и хранения данных;
обеспечивающие системы – системы, предназначенные для обеспечения физической и технической защиты, безопасных условий работы персонала в зданиях и помещениях, в которых расположена программно-техническая инфраструктура;
основной вычислительный центр – здания и помещения, в которых размещена программно-техническая инфраструктура;
основной канал связи – канал связи, используемый для осуществления деятельности участника платежного рынка;
отказ – событие, заключающееся в нарушении работоспособного состояния объекта программно-технической инфраструктуры;
план обеспечения непрерывной работы и восстановления работоспособности участника платежного рынка (далее – ПОНРВ) – документ, содержащий комплекс организационных мероприятий и программно-технических решений, которые должны выполняться до, во время и после возникновения кризисной (сбойной) ситуации;
подлинник – первый или единственный экземпляр документа;
программно-техническая инфраструктура – совокупность объектов, включающих в себя АС, технические средства, программные средства, программно-технические средства, программно-технические комплексы, средства телекоммуникаций и используемых для осуществления деятельности участника платежного рынка;
программное средство (далее – ПС) – объект, состоящий из программ, процедур, правил, а также при необходимости сопутствующих им документации и данных, относящихся к функционированию ПС;
программно-технический комплекс (далее – ПТК) – программно-технические средства, объединенные в комплекс для реализации задач автоматизированной системы;
программно-техническое средство (далее – ПТС) – совокупность ПС и технических средств;
работоспособное состояние – состояние объекта программно-технической инфраструктуры, при котором значения всех параметров, характеризующих его способность выполнять заданные функции, соответствуют требованиям нормативно-технической и (или) конструкторской (проектной) документации;
резервирование – способ обеспечения надежности объекта программно-технической инфраструктуры за счет использования дополнительных средств и (или) возможностей, избыточных по отношению к минимально необходимым для выполнения требуемых функций;
резервный вычислительный центр – здания и помещения, в которых размещены резервные объекты программно-технической инфраструктуры для осуществления деятельности участника платежного рынка в случае невозможности осуществления его деятельности в полном объеме с использованием основного вычислительного центра;
резервный канал связи – канал связи, используемый для осуществления деятельности участника платежного рынка в случае невозможности осуществления его деятельности в полном объеме с использованием основного канала связи;
системы жизнеобеспечения – системы и процессы создания и поддержания условий пригодности среды в зданиях и помещениях для безотказного функционирования объектов программно-технической инфраструктуры и работы персонала;
средства телекоммуникаций (далее – СТ) – совокупность ПС, технических средств, ПТС и каналов связи, предназначенных для приема и передачи данных;
техническая документация – документация на объекты программно-технической инфраструктуры, определяющая технические требования к ним, технические и организационные решения по созданию (развитию) и функционированию объектов программно-технической инфраструктуры;
техническое средство (далее, если не указано иное, – ТС) – оборудование, включая носители данных, предназначенное для автоматизированной обработки данных;
учтенная копия ПС, технической документации – копия, взятая на учет держателем подлинников ПС и (или) технической документации для внесения изменений в подлинники при проведении модернизации ПС и (или) технической документации;
штатный режим – режим работы участника платежного рынка, при котором все критичные ресурсы участника платежного рынка находятся в работоспособном состоянии, для каждого критичного ресурса обеспечивается работоспособный резерв, обеспечивается возможность выполнения персоналом своих должностных обязанностей в полном объеме;
эксплуатационная документация – документация, предназначенная для использования при эксплуатации, обслуживании и сопровождении АС, определяющая правила и порядок действий пользователей при ее функционировании.
Термин «информационный ресурс» используется в значении, определенном в абзаце девятнадцатом части первой статьи 1 Закона Республики Беларусь от 10 ноября 2008 г. № 455-З «Об информации, информатизации и защите информации».
Термины «аутсорсинг технологических услуг», «поставщик платежных услуг», «технологические услуги», «участник платежной системы», «участник платежного рынка» используются в значениях, определенных соответственно в подпунктах 1.5, 1.30, 1.38, 1.43 пункта 1, подпункте 2.4 пункта 2 статьи 2 Закона Республики Беларусь от 19 апреля 2022 г. № 164-З «О платежных системах и платежных услугах».
5. Мероприятия по обеспечению непрерывной работы участника платежного рынка и восстановлению его работоспособности применяются в отношении критичных ресурсов участника платежного рынка.
6. К критичным ресурсам участника платежного рынка, на которые направлены мероприятия по обеспечению непрерывной работы участника платежного рынка и восстановлению его работоспособности, относятся:
организационно-методическое и документационное обеспечение;
объекты программно-технической инфраструктуры;
информационные ресурсы АС, используемые при осуществлении деятельности участника платежного рынка (далее – информационные ресурсы);
обеспечивающие системы: технические средства и системы охраны зданий и помещений; автоматизированная система контроля и управления доступом в здания и помещения; система видеонаблюдения;
системы жизнеобеспечения: электроснабжения; кабельные системы вычислительных сетей, связи и автоматизации; вентиляции и кондиционирования; теплоснабжения, водоснабжения и канализации; оповещения о пожаре, пожарной сигнализации, автоматического пожаротушения, мониторинга за техническими средствами противопожарной защиты;
персонал, осуществляющий эксплуатацию, обслуживание и сопровождение объектов программно-технической инфраструктуры, обслуживание обеспечивающих систем и систем жизнеобеспечения, а также использующий информационные ресурсы при выполнении своих должностных обязанностей (далее – персонал);
здания и помещения, в которых расположены объекты программно-технической инфраструктуры и работает персонал.
7. Непрерывная работа участника платежного рынка достигается выполнением всех установленных качественных и (или) количественных параметров работы участника платежного рынка, уровней оказания услуг, осуществлением деятельности участника платежного рынка в полном объеме, в том числе в случае возникновения кризисной (сбойной) ситуации.
8. Мероприятия по обеспечению непрерывной работы участника платежного рынка и восстановлению его работоспособности выполняются до, во время и после возникновения кризисной (сбойной) ситуации и включают в себя:
мероприятия, направленные на предотвращение возникновения кризисной (сбойной) ситуации;
мероприятия, направленные на устранение кризисной (сбойной) ситуации и восстановление работоспособности участника платежного рынка, минимизацию времени восстановления работоспособности участника платежного рынка.
9. В случае возникновения кризисной (сбойной) ситуации участник платежного рынка организует переход на аварийный режим работы, выполнение мероприятий по устранению кризисной (сбойной) ситуации и восстановлению работоспособности участника платежного рынка и возврат к штатному режиму работы.
ГЛАВА 2
ОБЩИЕ ТРЕБОВАНИЯ К ОБЕСПЕЧЕНИЮ НЕПРЕРЫВНОЙ РАБОТЫ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА И ВОССТАНОВЛЕНИЮ ЕГО РАБОТОСПОСОБНОСТИ
10. В целях обеспечения надежного, безопасного функционирования, а также минимизации негативного воздействия кризисной (сбойной) ситуации участник платежного рынка разрабатывает и утверждает ПОНРВ.
ПОНРВ участника платежного рынка может быть оформлен в виде иерархически упорядоченных организационно-методических документов, регулирующих обеспечение непрерывной работы участника платежного рынка, а также восстановление в установленные сроки его работоспособности в случае возникновения кризисной (сбойной) ситуации.
11. При разработке ПОНРВ участник платежного рынка выполняет категорирование кризисных (сбойных) ситуаций. Количество категорий кризисных (сбойных) ситуаций и их обозначения (наименования) участник платежного рынка определяет самостоятельно.
Присвоение категорий кризисной (сбойной) ситуации осуществляется по одному или нескольким признакам:
характер кризисной (сбойной) ситуации;
масштаб кризисной (сбойной) ситуации;
ущерб от кризисной (сбойной) ситуации;
причины возникновения кризисной (сбойной) ситуации;
время реагирования на возникновение кризисной (сбойной) ситуации;
уровень оповещения руководства и (или) принятия им решений;
время восстановления работоспособности участника платежного рынка.
Характер кризисной (сбойной) ситуации: умышленная (возникает в результате выполнения злоумышленниками в определенные промежутки времени заранее обдуманных и спланированных действий) или случайная (возникает как результат объективных причин случайного характера, халатности, небрежности и форс-мажорных обстоятельств).
Масштаб кризисной (сбойной) ситуации отражает степень влияния кризисной (сбойной) ситуации на деятельность участника платежного рынка в случае ее возникновения.
Ущерб от кризисной (сбойной) ситуации отражает величину финансовых и иных потерь (убытков, дополнительных затрат) участника платежного рынка при устранении кризисной (сбойной) ситуации.
Основными причинами возникновения кризисной (сбойной) ситуации являются:
стихийные бедствия (землетрясение, наводнение, ураган и т.д.);
чрезвычайные ситуации (пожар, затопление, отравление ядовитыми веществами и т.д., включая террористический акт или его угрозу, возникновение, распространение и объявление в Республике Беларусь эпидемии смертельно опасного заболевания);
технологические ошибки;
отказ объектов программно-технической инфраструктуры;
ошибки в системных, специальных и (или) прикладных ПС;
отказ обеспечивающих систем;
отказ систем жизнеобеспечения;
ошибки персонала, вызванные неправильными действиями случайного или умышленного характера;
атаки со стороны злоумышленников с использованием ПС и (или) ПТС;
нарушение требований к информационной безопасности, установленных законодательством и локальными правовыми актами участника платежного рынка.
Время реагирования на возникновение кризисной (сбойной) ситуации включает в себя время, затраченное на поиск и обнаружение места либо возможной причины кризисной (сбойной) ситуации, оповещение, принятие решений по устранению кризисной (сбойной) ситуации и восстановлению работоспособности участника платежного рынка.
Уровень оповещения руководства и (или) принятия им решений включает в себя схему оповещения при возникновении кризисной (сбойной) ситуации и принятия решений по устранению кризисной (сбойной) ситуации.
Время восстановления работоспособности участника платежного рынка включает в себя время устранения кризисной (сбойной) ситуации, восстановления работоспособности участника платежного рынка и возврата к штатному режиму работы.
12. Мероприятия по восстановлению работоспособности участника платежного рынка начинаются в пределах календарного дня, когда была обнаружена кризисная (сбойная) ситуация.
13. Временные рамки выполнения мероприятий по восстановлению работоспособности участника платежного рынка устанавливаются в ПОНРВ.
14. Мероприятия по восстановлению работоспособности участника платежного рынка фиксируются в соответствии с локальными правовыми актами участника платежного рынка.
15. Участник платежного рынка организует резервный вычислительный центр, территориально удаленный от основного вычислительного центра, в целях обеспечения непрерывной работы в случае возникновения кризисной (сбойной) ситуации.
Необходимость выполнения требования об организации резервного вычислительного центра для участников платежного рынка установлена согласно приложению.
16. Участник платежного рынка организует самостоятельно либо с привлечением соответствующего поставщика технологических услуг каналы связи, включая основной канал связи и резервный канал связи, организованный с использованием отдельного физического канала связи, для осуществления своей деятельности при необходимости в случае возникновения кризисной (сбойной) ситуации.
Необходимость выполнения требования об организации резервного канала связи для участников платежного рынка установлена согласно приложению.
ГЛАВА 3
ОБЩИЕ ТРЕБОВАНИЯ К ОРГАНИЗАЦИОННО-МЕТОДИЧЕСКОМУ И ДОКУМЕНТАЦИОННОМУ ОБЕСПЕЧЕНИЮ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
17. Организационно-методическое и документационное обеспечение участника платежного рынка включает в себя локальные правовые акты участника платежного рынка и эксплуатационную документацию, описывающую технологический процесс осуществления деятельности участника платежного рынка (в том числе входящую в комплект разрабатываемых (поставляемых) ПС).
18. В комплект технической и эксплуатационной документации СТ включаются схемы подключения и расположения (с указанием мест хранения информации об актуальных сетевых адресах, параметрах маршрутизации и конфигурационных файлах).
19. При организации работы с организационно-методическим и документационным обеспечением участник платежного рынка обеспечивает:
наличие подлинников и рабочих экземпляров организационно-методических документов и эксплуатационной документации;
обеспечение персонала рабочими экземплярами организационно-методических документов и эксплуатационной документации в достаточном количестве, в том числе на резервных рабочих местах и (или) в резервных вычислительных центрах;
хранение подлинников организационно-методических документов и эксплуатационной документации отдельно от рабочих экземпляров;
разграничение доступа к подлинникам и рабочим экземплярам организационно-методических документов и эксплуатационной документации;
сохранность организационно-методических документов и эксплуатационной документации;
поддержание организационно-методических документов и эксплуатационной документации в актуальном состоянии.
20. Участник платежного рынка разрабатывает локальные правовые акты, определяющие порядок обеспечения управления, использования и взаимодействия объектов программно-технической инфраструктуры, в которых также определяет перечень работ по сопровождению, обслуживанию и эксплуатации АС.
21. Участник платежного рынка определяет и утверждает перечень объектов программно-технической инфраструктуры, используемых для осуществления деятельности участника платежного рынка и функционирования каналов связи в штатном режиме работы участника платежного рынка, и обеспечивает актуализацию перечня по мере изменения состава объектов программно-технической инфраструктуры.
22. Участник платежного рынка обеспечивает выполнение мероприятий по поддержанию организационно-методического и документационного обеспечения в актуальном состоянии путем разработки новых локальных правовых актов, документов, пересмотра и внесения изменений (утверждения новых редакций) в действующие локальные правовые акты, документы по мере необходимости.
ГЛАВА 4
ОБЩИЕ ТРЕБОВАНИЯ К ОБЕСПЕЧЕНИЮ БЕЗОТКАЗНОСТИ РАБОТЫ ОБЪЕКТОВ ПРОГРАММНО-ТЕХНИЧЕСКОЙ ИНФРАСТРУКТУРЫ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
23. Участник платежного рынка обеспечивает безотказность работы объектов программно-технической инфраструктуры путем проведения мероприятий, направленных на предотвращение возникновения кризисных (сбойных) ситуаций и сокращение времени их восстановления в случае возникновения кризисных (сбойных) ситуаций.
24. Для сокращения времени восстановления работоспособности участника платежного рынка при организации работы объектов программно-технической инфраструктуры обеспечивается:
разработка и поддержание в актуальном состоянии описания технологического процесса функционирования объектов программно-технической инфраструктуры;
наличие учтенных копий ПС, технической документации (рабочих и резервных);
хранение резервных учтенных копий ПС, технической документации в территориально удаленных зданиях и помещениях;
организация резервного вычислительного центра;
использование ПС, соответствующих требованиям, установленным в стандартах проведения расчетов;
установление порядка разработки, сопровождения (внесения изменений), хранения и эксплуатации ПС;
управление порядком функционирования и восстановления объектов программно-технической инфраструктуры;
определение критически значимых объектов программно-технической инфраструктуры;
резервирование критически значимых объектов программно-технической инфраструктуры;
контроль работоспособности резервных объектов программно-технической инфраструктуры;
техническое обслуживание объектов программно-технической инфраструктуры (в том числе резервных) на постоянной основе (комплекс работ по поддержанию ТС в работоспособном состоянии);
организация дежурства специалистов по техническому сопровождению (при необходимости).
25. Участник платежного рынка создает резерв объектов программно-технической инфраструктуры, используемых для осуществления деятельности участника платежного рынка и функционирования каналов связи и обеспечивает доступность резервных объектов программно-технической инфраструктуры в течение всего рабочего дня персоналу участника платежного рынка и специалистам, задействованным в устранении кризисной (сбойной) ситуации и проведении восстановительных работ.
26. Участник платежного рынка обеспечивает временную защиту объектов программно-технической инфраструктуры от сбоев в работе электрической сети путем использования источников бесперебойного питания, резервирования питания и (или) использования автономного генератора мощностью, достаточной для поддержания работоспособности объектов программно-технической инфраструктуры, в течение не менее 45 минут с целью завершения технологического этапа их работы и сохранения данных.
27. Для защиты ТС от воздействия окружающей среды участник платежного рынка обеспечивает поддержание температурно-влажностного режима, установленного в технической документации производителя соответствующих ТС.
28. Повышение уровня безотказности объектов программно-технической инфраструктуры обеспечивается за счет проведения периодического технического обслуживания и тестирования объектов программно-технической инфраструктуры (в том числе резервных), проведения периодического контроля (проверки) резервных объектов программно-технической инфраструктуры и параметров их настроек.
29. При организации проведения периодического технического обслуживания и тестирования объектов программно-технической инфраструктуры (в том числе резервных) участник платежного рынка:
разрабатывает и использует порядок проведения периодического технического обслуживания и тестирования объектов программно-технической инфраструктуры с учетом требований технической документации производителя соответствующих объектов программно-технической инфраструктуры, документирования результатов проведенного периодического технического обслуживания и тестирования объектов программно-технической инфраструктуры и учета дефектов, обнаруженных в ходе выполнения работ;
проводит периодическое техническое обслуживание и тестирование объектов программно-технической инфраструктуры в соответствии с разработанным порядком проведения периодического технического обслуживания и тестирования объектов программно-технической инфраструктуры, но не реже одного раза в год;
включает в порядок проведения периодического технического обслуживания и тестирования объектов программно-технической инфраструктуры:
внешний и внутренний осмотр объектов программно-технической инфраструктуры. Внутренний осмотр отдельных объектов программно-технической инфраструктуры может не проводиться, если это влечет нарушение порядка их гарантийного обслуживания или не предусмотрено технической документацией производителя;
проверку параметров настроек работоспособности объектов программно-технической инфраструктуры;
тестирование взаимодействия объектов программно-технической инфраструктуры. Тестирование взаимодействия отдельных объектов программно-технической инфраструктуры может не проводиться в случае, если режим работы данных объектов программно-технической инфраструктуры не предполагает остановку их работы;
плановые проверки сертифицированными антивирусными средствами с соблюдением частоты и содержания проводимых проверок в соответствии с применяемой политикой информационной безопасности. Плановые проверки сертифицированными антивирусными средствами осуществляются при наличии технической возможности проверки объектов программно-технической инфраструктуры и отсутствии постоянной защиты ПС сертифицированными антивирусными средствами.
30. В случае возникновения кризисной (сбойной) ситуации в функционировании объектов программно-технической инфраструктуры восстановление работоспособности участника платежного рынка проводится в соответствии с технической документацией производителя объектов программно-технической инфраструктуры (поставщика телекоммуникационных услуг) и (или) документами участника платежного рынка по восстановлению работоспособности объектов программно-технической инфраструктуры.
31. После восстановления работоспособности участника платежного рынка проводится тестирование объектов программно-технической инфраструктуры, работоспособность которых была нарушена вследствие возникновения кризисной (сбойной) ситуации.
32. Факт кризисной (сбойной) ситуации в функционировании объектов программно-технической инфраструктуры (дата и время возникновения и устранения, причины возникновения, меры по предотвращению в дальнейшем и т.д.) фиксируется в соответствии с разработанным участником платежного рынка порядком. Учету подлежат все факты кризисной (сбойной) ситуации в функционировании объектов программно-технической инфраструктуры.
33. В случае плановых перерывов или возникновения кризисных (сбойных) ситуаций, повлекших неработоспособность ПТС, обеспечивающих обслуживание держателей банковских платежных карточек, участник платежного рынка информирует держателей банковских платежных карточек о невозможности осуществления операций при использовании банковских платежных карточек и планируемых сроках восстановления работоспособности ПТС, обеспечивающих обслуживание держателей банковских платежных карточек. При этом информирование держателей банковских платежных карточек – физических лиц должно осуществляться с использованием не менее двух электронных каналов информирования (официальный сайт участника платежного рынка в глобальной компьютерной сети Интернет, страница, аккаунт, канал участника платежного рынка в социальных сетях, мессенджерах, иные электронные каналы информирования).
34. Участник платежного рынка проводит регулярный анализ кризисных (сбойных) ситуаций в функционировании объектов программно-технической инфраструктуры и обнаруженных в ходе их периодического технического обслуживания и тестирования объектов программно-технической инфраструктуры дефектов и документирует результаты проведенного анализа в соответствии с разработанным им порядком.
35. На основании результатов проведенного анализа участник платежного рынка формирует план корректирующих мероприятий для предотвращения возникновения аналогичных кризисных (сбойных) ситуаций в дальнейшей деятельности участника платежного рынка и устранения причин выявленных дефектов, а также минимизацию времени восстановления при возникновении кризисных (сбойных) ситуаций.
36. Доступ к объектам программно-технической инфраструктуры и в помещения, где они расположены, а также к техническому архиву ПС, ограничивается в соответствии с локальными правовыми актами участника платежного рынка.
37. Участник платежного рынка разрабатывает порядок учета ПТК и оборудования СТ, используемых при осуществлении деятельности участника платежного рынка.
При проведении мероприятий по учету ПТК и оборудования СТ, используемых при осуществлении деятельности участника платежного рынка, документируется следующая информация:
наименование ПТК или оборудования СТ;
дата ввода в эксплуатацию ПТК или оборудования СТ;
данные персонала, ответственного за эксплуатацию ПТК или оборудования СТ;
данные персонала, ответственного за техническую поддержку ПТК или оборудования СТ (при наличии информации);
состав ТС и их размещение;
состав ПС;
перечень технической и эксплуатационной документации;
основной и резервный каналы связи (для СТ);
перечень резервного оборудования с указанием места его размещения.
38. Перед вводом в эксплуатацию разрабатываемых (поставляемых) ПС участник платежного рынка проводит проверку их работоспособности, обеспечивает их проверку сертифицированными антивирусными средствами и документирует результаты проверки в соответствии с разработанным им порядком либо производитель (поставщик) ПС документально подтверждает участнику платежного рынка их работоспособность (самостоятельно или в составе ПТК) и выполнение их проверки сертифицированными антивирусными средствами.
39. Участник платежного рынка определяет порядок учета и хранения ПС (подлинников эксплуатационной документации, дубликатов и рабочих копий на носителях данных) и их использования в производстве. Данные процедуры выполняются участником платежного рынка до введения ПС в эксплуатацию.
Перед передачей ПС из технического архива в эксплуатацию носитель данных с ПС проверяется на работоспособность на оборудовании, используемом для тестирования ПС, проверяется сертифицированными антивирусными средствами.
40. Участник платежного рынка в течение всего рабочего дня обеспечивает доступность персоналу, обеспечивающему функционирование указанных ПС, рабочих копий ПС на носителях данных, эксплуатационной документации, а также документации по восстановлению работоспособности ПС.
41. В случае использования услуг предоставления площадей центров обработки данных и иных услуг, основанных на облачных технологиях, в рамках аутсорсинга технологических услуг участник платежного рынка обеспечивает наличие документов, подтверждающих, что используемый для оказания услуги центр обработки данных:
обеспечивает защиту информации, распространение и (или) предоставление которой ограничено, имеет аттестацию и использует сертифицированные средства защиты информации в соответствии с требованиями законодательства об информации, информатизации и защите информации;
имеет серверное оборудование и оборудование хранения данных, удовлетворяющее требованиям по надежности и резервированию технических средств на уровне не ниже 2 (N + 1);
имеет (предоставляет) защищенные каналы связи для удаленного администрирования, а также для соединения с иными защищаемыми (аттестованными) объектами (при их наличии). Защищенные каналы связи организовываются с использованием сертифицированных средств защиты информации (средств криптографической защиты информации), соответствующих требованиям законодательства об информации, информатизации и защите информации;
имеет внедренную систему управления (менеджмента) информационной безопасности, имеющую сертификат соответствия требованиям ISO/IEC 27001 «Information technology – Security techniques – Information security management systems – Requirements» и (или) государственного стандарта Республики Беларусь СТБ ISO/IEC 27001-2016 «Информационные технологии. Методы обеспечения безопасности. Системы менеджмента информационной безопасности. Требования», утвержденного постановлением Государственного комитета по стандартизации Республики Беларусь от 1 апреля 2016 г. № 27;
соответствует требованиям стандарта безопасности данных индустрии банковских платежных карточек PCI DSS для среды банковских платежных карточек;
имеет платформу виртуализации и компоненты виртуализации сети, имеющей сертификат соответствия и поддерживающей функции:
контроля и разделения доступа к ресурсам системы виртуализации и физическим ресурсам;
разделения системы управления и обработки данных;
разделения потоков данных виртуальных машин;
ограничения на использование физических ресурсов;
регистрации событий информационной безопасности;
использования (встраивания) систем защиты информации производителей, отличных от производителя системы виртуализации.
42. Участник платежного рынка самостоятельно или с привлечением соответствующего поставщика технологических услуг осуществляет контроль доступности и мониторинг загрузки каналов связи, а также при необходимости обеспечивает автоматическое переключение между основным и резервным каналами связи в случае возникновения кризисной (сбойной) ситуации.
43. Участник платежного рынка оценивает среднюю и пиковую величину пропускной способности оборудования СТ, необходимую для осуществления его деятельности.
44. Участник платежного рынка обеспечивает пропускную способность:
основного канала связи – в объеме не менее 120 % от пиковой величины пропускной способности оборудования СТ, необходимой для осуществления его деятельности;
резервного канала связи – в объеме не менее 100 % от средней величины пропускной способности оборудования СТ, необходимой для осуществления его деятельности.
45. В случае привлечения поставщика технологических услуг для организации каналов связи, участник платежного рынка обеспечивает наличие у своего персонала контактных данных службы технической поддержки поставщика технологических услуг.
ГЛАВА 5
ОБЩИЕ ТРЕБОВАНИЯ К ОБЕСПЕЧЕНИЮ СОХРАННОСТИ ИНФОРМАЦИОННЫХ РЕСУРСОВ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
46. Участник платежного рынка обеспечивает хранение следующих информационных ресурсов:
базы данных, информация о структуре баз данных, другие совокупности взаимосвязанной информации в АС;
протоколы обработки информации, включая действия персонала;
входные и выходные данные АС.
47. Для хранения информационных ресурсов, подлежащих хранению, участник платежного рынка создает архив либо привлекает соответствующего поставщика технологических услуг.
48. При организации работы с информационными ресурсами участник платежного рынка обеспечивает выполнение следующих требований:
проведение классификации, идентификации и документированного учета всех информационных ресурсов;
использование лицензионных и сертифицированных ПС для работы с информационными ресурсами;
разделение информационных ресурсов по среде использования (среда разработки, среда тестирования, производственная среда);
распределение зон ответственности при эксплуатации, сопровождении и обслуживании информационных ресурсов;
управление процедурами создания эталонных и рабочих копий информационных ресурсов, а также их резерва с соблюдением принципа территориального разделения при хранении эталонных и резервных копий информационных ресурсов;
соблюдение порядка ввода и вывода информационных ресурсов из эксплуатации и их последующего уничтожения;
соблюдение порядка гарантированного уничтожения информации и ПС с устройств их хранения;
соблюдение порядка физического уничтожения носителей данных при выведении информационных ресурсов из эксплуатации.
49. Участник платежного рынка обеспечивает резервное копирование данных, входящих в состав информационных ресурсов. Для этого выполняются следующие мероприятия:
разработка политики резервного копирования данных;
защита резервных копий во время их передачи и хранения, в том числе путем шифрования резервных копий;
контроль над процессом создания резервных копий в целях выявления систематических ошибок и своевременного выявления проблем резервного копирования;
проведение периодического восстановления данных из резервных копий в рамках отработки действий персонала и контроля корректности копий.
50. Участник платежного рынка разрабатывает порядок восстановления информационных ресурсов в случае нарушения их целостности.
51. Участник платежного рынка обеспечивает доступность персоналу, обеспечивающему функционирование АС, архивов, эксплуатационной документации и локальных правовых актов по восстановлению целостности информационных ресурсов в течение всего рабочего дня.
52. С целью исключения возможности несанкционированного доступа к информационным ресурсам участник платежного рынка проводит мероприятия по ограничению доступа к информационным ресурсам в соответствии с применяемой политикой информационной безопасности.
ГЛАВА 6
ОБЩИЕ ТРЕБОВАНИЯ К ОБЕСПЕЧЕНИЮ БЕЗОТКАЗНОСТИ РАБОТЫ ОБЕСПЕЧИВАЮЩИХ СИСТЕМ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
53. Участник платежного рынка определяет перечень процедур, необходимых для восстановления работоспособности обеспечивающих систем в случае возникновения кризисных (сбойных) ситуаций.
54. Для сокращения времени восстановления работоспособности участника платежного рынка при организации работы обеспечивающих систем выполняются следующие требования:
соблюдение установленных правил и процедур эксплуатации обеспечивающих систем;
проведение профилактических мероприятий по поддержанию обеспечивающих систем в работоспособном состоянии.
55. Действия, выполняемые персоналом, по восстановлению работоспособности обеспечивающих систем, описываются в локальных правовых актах участника платежного рынка (с учетом планов гражданской обороны, предупреждения и ликвидации чрезвычайных ситуаций).
56. Использование обеспечивающих систем участника платежного рынка проводится с соблюдением требований по:
обеспечению безопасности работы персонала;
обеспечению безопасности зданий и помещений, в которых размещены объекты программно-технической инфраструктуры;
обеспечению ограничения доступа в помещения, в которых размещены объекты программно-технической инфраструктуры, включая видеосъемку и хранение информации о посещении данных помещений, в соответствии с применяемой политикой информационной безопасности;
недопущению несанкционированного доступа к обеспечивающим системам.
ГЛАВА 7
ОБЩИЕ ТРЕБОВАНИЯ К ОБЕСПЕЧЕНИЮ БЕЗОТКАЗНОСТИ РАБОТЫ СИСТЕМ ЖИЗНЕОБЕСПЕЧЕНИЯ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
57. Участник платежного рынка определяет перечень процедур, необходимых для восстановления работоспособности систем жизнеобеспечения, выполняемых при возникновении кризисных (сбойных) ситуаций.
58. Для сокращения времени восстановления работоспособности участника платежного рынка при организации работы систем жизнеобеспечения выполняются следующие требования:
соблюдение установленных правил и процедур эксплуатации систем жизнеобеспечения;
проведение профилактических мероприятий по поддержанию систем жизнеобеспечения в работоспособном состоянии с учетом сезонных нагрузок.
59. Действия, выполняемые персоналом по восстановлению работоспособности систем жизнеобеспечения, описываются в локальных правовых актах участника платежного рынка (с учетом планов гражданской обороны, предупреждения и ликвидации чрезвычайных ситуаций), в том числе в относящихся к ПОНРВ и детализирующих его локальных правовых актах по переходу систем жизнеобеспечения в аварийный режим работы и возврату в штатный режим работы.
60. Участник платежного рынка организует систему электроснабжения, обеспечивающую функционирование объектов программно-технической инфраструктуры с использованием выделенной линии питания, защищенной от перенапряжения специальными устройствами и не связанной с системой электропитания осветительного и другого электрооборудования.
Использование местных нагревательных и отопительных приборов, питаемых теплоносителями, выполняется в соответствии с требованиями изготовителя по их использованию.
61. Участник платежного рынка проводит мероприятия, направленные на бесперебойное обеспечение электричеством критичных ресурсов:
оборудование объектов программно-технической инфраструктуры источниками бесперебойного питания достаточной мощности для обеспечения их работы в течение не менее 45 минут;
организация двух независимых входов подачи электроэнергии от двух разных подстанций в основной вычислительный центр, резервный вычислительный центр;
установка, наладка и периодическая проверка работоспособности автономной дизель-генераторной установки (при ее наличии).
62. Выбор здания для основного вычислительного центра, резервного вычислительного центра производится с учетом обязательного обеспечения системами холодного и горячего водоснабжения, канализации и водостоков, противопожарного водоснабжения.
63. Системы отопления, вентиляции, кондиционирования воздуха и пожарной безопасности зданий участника платежного рынка организуются в соответствии с требованиями, предъявляемыми для их проектирования и модернизации.
ГЛАВА 8
ОБЩИЕ ТРЕБОВАНИЯ К ПЕРСОНАЛУ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
64. Надежное, безопасное осуществление деятельности участника платежного рынка обеспечивается достаточным количеством персонала с соответствующим уровнем квалификации. При этом личная безопасность персонала, а также установленный порядок обеспечения принятия решений и использования эффективных схем оповещения в кризисных (сбойных) ситуациях имеют степень первостепенной важности.
65. Для сокращения времени восстановления работоспособности участника платежного рынка при организации работы персонала обеспечивается:
резервирование персонала;
разработка схем замещения персонала и организация замещения персонала;
разработка схем оповещения при возникновении кризисных (сбойных) ситуаций;
тренировка (тестирование, контроль) действий персонала, предусмотренных ПОНРВ.
66. К мероприятиям по работе с персоналом участника платежного рынка относятся мероприятия по:
подбору и подготовке персонала необходимой квалификации;
учету мотивации персонала к положительным результатам работы;
управлению переподготовкой и повышением квалификации персонала;
проведению аттестации персонала и выполнению рекомендаций по результатам аттестации;
организации прохождения медицинского осмотра персонала (медицинское освидетельствование) и выполнению рекомендаций по его результатам в соответствии с требованиями законодательства;
обеспечению снижения текучести кадров.
67. Техническое обеспечение непрерывной работы объектов программно-технической инфраструктуры, а также доступ к информационным ресурсам, используемым при возникновении кризисных (сбойных) ситуаций для восстановления работоспособности объектов программно-технической инфраструктуры, осуществляется персоналом в соответствии с возложенными на него должностными обязанностями.
68. Мероприятия по техническому обеспечению процесса осуществления деятельности участника платежного рынка в соответствии с должностными обязанностями выполняются персоналом участника, обладающим достаточной для их выполнения квалификацией и имеющим образование, соответствующее профилю выполняемых обязанностей.
69. Участник платежного рынка определяет резервный персонал, временно обеспечивающий эксплуатацию, сопровождение и обслуживание объектов программно-технической инфраструктуры, в случае нетрудоспособности и (или) недоступности персонала, выполняющего данные функции на постоянной основе согласно своим должностным обязанностям.
70. Участник платежного рынка разрабатывает и утверждает схему замещения персонала, обеспечивающего эксплуатацию, сопровождение и обслуживание объектов программно-технической инфраструктуры.
71. Участник платежного рынка организует проведение подготовки (инструктажа) персонала по вопросам использования объектов программно-технической инфраструктуры, информационных ресурсов.
72. Проведение переподготовки (повышение квалификации), подготовки (инструктажа) персонала, осуществляющего техническое обеспечение процесса осуществления деятельности участника платежного рынка, обеспечивается при изменении состава объектов программно-технической инфраструктуры, но не реже одного раза в три года.
73. Сведения о подготовке (инструктаже) и переподготовке (повышении квалификации) персонала, обеспечивающего эксплуатацию, сопровождение и обслуживание объектов программно-технической инфраструктуры, учитываются в соответствии с локальными правовыми актами участника платежного рынка.
ГЛАВА 9
ОБЩИЕ ТРЕБОВАНИЯ К ПЛАНУ ОБЕСПЕЧЕНИЯ НЕПРЕРЫВНОЙ РАБОТЫ И ВОССТАНОВЛЕНИЯ РАБОТОСПОСОБНОСТИ УЧАСТНИКА ПЛАТЕЖНОГО РЫНКА
74. Участник платежного рынка организует проведение мероприятий по восстановлению непрерывной работы, связанных с возникновением кризисных (сбойных) ситуаций, в соответствии с ПОНРВ, утвержденным локальным правовым актом.
75. Участник платежного рынка включает в ПОНРВ ссылки на локальные правовые акты, техническую и эксплуатационную документацию, в которых установлены требования к:
обеспечению информационной безопасности объектов программно-технической инфраструктуры;
структуре используемых информационных ресурсов, включая состав и конфигурацию объектов программно-технической инфраструктуры, и описание функционирования ПТК, а также схемы их взаимодействия;
схемам технологического процесса взаимодействия объектов программно-технической инфраструктуры при осуществлении деятельности участника платежного рынка;
периодическому техническому обслуживанию и тестированию объектов программно-технической инфраструктуры и составу работ, выполняемых в процессе его проведения;
процедурам обеспечения непрерывной работы и восстановления работоспособности отдельных ПТК и альтернативных вариантов (мест) деятельности участника платежного рынка;
перечню персонала участника платежного рынка и работникам сторонних организаций, привлекаемых к устранению кризисных (сбойных) ситуаций, и способам их оповещения;
процедурам перехода к осуществлению деятельности участника платежного рынка в резервном режиме;
обеспечивающим системам и системам жизнеобеспечения;
персоналу участника платежного рынка;
наличию подлинников и рабочих экземпляров организационно-методических документов для их целевого применения персоналом;
обеспечению персонала участника платежного рынка необходимыми актуальными организационно-методическими документами и ПОНРВ на своих рабочих местах;
распределению обязанностей по приобретению, сопровождению, эксплуатации и архивированию ПС.
76. Участник платежного рынка может включать в ПОНРВ положения (документы), описывающие мероприятия по:
ограничению доступа к информационным ресурсам участника;
проведению копирования и архивирования ПС и данных;
осуществлению контроля исполнения ПОНРВ.
77. Участник платежного рынка определяет порядок осуществления контроля исполнения ПОНРВ, включая процедуры и периодичность проведения контроля, а также определяет персонал, ответственный за проведение контроля исполнения ПОНРВ.
78. При разработке ПОНРВ участник платежного рынка включает в него:
перечень объектов ПОНРВ участника платежного рынка;
определение и категорирование кризисных (сбойных) ситуаций;
описание порядка работы участника платежного рынка в штатном режиме;
описание порядка работы участника платежного рынка в аварийном режиме;
сценарии возникновения и развития кризисных (сбойных) ситуаций в различные промежутки времени;
оценку возможных потерь (ущерба) в результате возникновения кризисной (сбойной) ситуации (при наличии возможности предварительного расчета возможных потерь (ущерба));
схемы оповещения и принятия решений;
описание действий по восстановлению работоспособности участника платежного рынка по возврату работы участника в штатный режим;
описание мероприятий, выполняемых после возврата к работе в штатном режиме;
порядок учета и рассмотрения кризисной (сбойной) ситуации;
распределение ответственности персонала участника платежного рынка;
порядок тестирования (испытаний) и пересмотра ПОНРВ участника платежного рынка.
79. В ПОНРВ может включаться документ, содержащий требования к порядку взаимодействия персонала участника платежного рынка, обслуживающего и сопровождающего объекты программно-технической инфраструктуры при возникновении кризисных (сбойных) ситуаций, в котором взаимоувязаны вопросы классификации кризисных (сбойных) ситуаций, причины их возникновения и учтены требования настоящего стандарта.
80. Участник платежного рынка определяет и поддерживает в актуальном состоянии перечень объектов ПОНРВ, который охватывает все критически значимые ПТК, используемые для осуществления деятельности участника платежного рынка, включая ПТК, обеспечивающие:
функционирование АС участника платежного рынка, используемых для осуществления деятельности участника платежного рынка;
взаимодействие участника платежного рынка с обслуживаемыми клиентами и пользователями информации;
резерв для восстановления функционирования основных ПТК.
81. Участник платежного рынка определяет порядок работы в штатном режиме с указанием:
перечня объектов программно-технической инфраструктуры, используемых для осуществления деятельности участника платежного рынка в штатном режиме;
состава персонала, подлежащего обязательному резервированию и обеспечивающего штатный режим работы участника платежного рынка.
82. Участник платежного рынка определяет порядок работы участника платежного рынка в аварийном режиме с указанием:
перечня объектов программно-технической инфраструктуры, которые могут быть использованы в качестве резерва в случае возникновения кризисной (сбойной) ситуации для осуществления деятельности участника платежного рынка в аварийном режиме;
состава персонала, который отвечает за восстановление работоспособности участника платежного рынка;
состава резервного персонала, временно обеспечивающего эксплуатацию, сопровождение и обслуживание объектов программно-технической инфраструктуры, в случае нетрудоспособности и (или) недоступности основного персонала.
83. Участник платежного рынка определяет схему оповещения и предусматривает в ней:
обязанности по оповещению персонала участника платежного рынка, руководства участника платежного рынка и иных заинтересованных лиц о возникновении кризисной (сбойной) ситуации, действий по восстановлению работоспособности участника платежного рынка и возврату в штатный режим работы;
возможность автоматизированного информирования всех заинтересованных лиц с использованием различных каналов связи для своевременного принятия необходимых мер по минимизации ущерба, вызванного кризисной (сбойной) ситуацией;
требования к срокам и способам информирования потребителей услуг участника платежного рынка о возникновении кризисной (сбойной) ситуации и планируемых сроках восстановления работоспособности участника платежного рынка, а также о возможных альтернативных способах осуществления деятельности участника платежного рынка.
84. Участник платежного рынка обеспечивает возможность осуществлять работы по восстановлению функционирования объектов программно-технической инфраструктуры, предусмотренные ПОНРВ, адекватные источнику и масштабам кризисной (сбойной) ситуации, затратам времени и видам ресурсов на восстановление работоспособности, включающие:
использование соответствующих схем оповещения заинтересованных в обеспечении непрерывной работы участника платежного рынка и восстановления его работоспособности;
использование нескольких технологий передачи информации (система передачи финансовой информации Национального банка, факс, электронная почта, мобильная связь);
использование резервных вычислительных центров, резервных центров обработки данных на случай невозможности восстановления работоспособности участника платежного рынка на основном вычислительном центре;
осуществление деятельности участника платежного рынка в резервном режиме;
резервирование критически значимых объектов программно-технической инфраструктуры;
резервирование СТ, наличие резервного канала связи для основного канала связи;
резервное копирование и хранение на разных территориях используемых участником платежного рынка лицензионных и сертифицированных ПС;
резервное копирование и хранение на разных территориях информационных ресурсов;
обеспечение бесперебойного электроснабжения критически значимых объектов программно-технической инфраструктуры;
защищенность силовых линий и каналов связи;
обеспечение ограничения доступа к информационным ресурсам;
использование средств информационной безопасности;
определение и поддержание в актуальном состоянии перечня и порядка взаимозаменяемости персонала.
85. Участник платежного рынка определяет порядок возврата в штатный режим работы, включая проведение работ, направленных на устранение причин кризисной (сбойной) ситуации и предотвращение возникновения аналогичных кризисных (сбойных) ситуаций в дальнейшей деятельности участника платежного рынка, и проверку готовности участника платежного рынка к работе в штатном режиме (при необходимости).
86. По завершении ликвидации кризисной (сбойной) ситуации участник платежного рынка обеспечивает проведение мероприятий по анализу кризисной (сбойной) ситуации и выявлению ее причин, результаты анализа документирует в соответствии с разработанным порядком.
87. Участник платежного рынка определяет порядок распределения между персоналом полномочий по принятию решений и ответственности за их выполнение, при организации проводимых мероприятий в кризисных (сбойных) ситуациях (возможно несколько сценариев с описанием организационных мероприятий).
88. Участник платежного рынка обеспечивает проведение регулярных тренировок (тестирования, контроля) действий, предусмотренных ПОНРВ, но не реже одного раза в год в соответствии с утвержденным графиком и регламентом проведения тренировок (тестирования, контроля) действий, предусмотренных ПОНРВ, с учетом вовлечения основного и резервного персонала, основных и резервных объектов программно-технической инфраструктуры, различных типовых сценариев возникновения и развития кризисной (сбойной) ситуации в функционировании участника платежного рынка.
89. Информация по результатам тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ, отражается в утверждаемом участником платежного рынка акте с указанием полученных итогов, сделанных выводов, результатов оценки действий персонала, установленных несоответствий, предложений по проведению корректирующих мероприятий и внесению изменений в ПОНРВ и локальные правовые акты участника платежного рынка.
90. Участник платежного рынка обеспечивает проведение на регулярной основе мероприятий, направленных на ознакомление персонала с ПОНРВ (в том числе после пересмотра ПОНРВ), повышение уровня знаний персонала в части действий, предусмотренных ПОНРВ. Данные мероприятия могут проводиться в рамках тренировки (тестирования, контроля) действий, предусмотренных ПОНРВ.
91. Участник платежного рынка обеспечивает выполнение работ по регулярному пересмотру ПОНРВ и документирование результатов пересмотра в протоколе пересмотра ПОНРВ или путем утверждения новой редакции ПОНРВ.
Полный пересмотр ПОНРВ проводится в следующих случаях:
при изменении перечня решаемых задач или конфигурации ПТК, обеспечивающих осуществление деятельности участника платежного рынка, приводящем к изменению технологии обработки информации;
при получении неудовлетворительных (отрицательных) результатов тренировок (тестирования, контроля);
после устранения кризисных (сбойных) ситуаций при выявлении недостатков ПОНРВ.
Частичный пересмотр ПОНРВ проводится при изменении конфигурации ПТК, обеспечивающих осуществление деятельности участника платежного рынка, не изменяющей технологии обработки информации, изменении состава персонала и (или) его должностных обязанностей.
Профилактический пересмотр ПОНРВ проводится не реже одного раза в год для поддержания ПОНРВ участника платежного рынка в актуальном состоянии или для оценки эффективности и корректности ПОНРВ в случае необходимости.
ГЛАВА 10
ОБЩИЕ ТРЕБОВАНИЯ К ОРГАНИЗАЦИИ РЕЗЕРВНЫХ ВЫЧИСЛИТЕЛЬНЫХ ЦЕНТРОВ
92. Участник платежного рынка обеспечивает информационную и техническую совместимость объектов программно-технической инфраструктуры основного и резервного вычислительных центров, обеспечивающую их полную взаимозаменяемость.
Допускается объединение основного вычислительного центра и резервного вычислительного центра в единую логическую структуру, в том числе с обеспечением возможности динамического перераспределения компонентов АС между ними.
93. Территориальная удаленность помещений резервного вычислительного центра участника платежного рынка от помещений основного вычислительного центра участника платежного рынка должна составлять не менее трех километров.
94. Помещения резервного вычислительного центра участника платежного рынка оборудуются системами жизнеобеспечения. Энергопитание резервного вычислительного центра участника платежного рынка обеспечивается с использованием резервирования энерговвода, источников бесперебойного питания, дизель-генераторов.
95. При организации резервного вычислительного центра участник платежного рынка обеспечивает выполнение требований к:
организации непрерывной работы и восстановлению работоспособности;
обеспечению безопасности работы с информационными ресурсами;
обеспечению работоспособности обеспечивающих систем и систем жизнеобеспечения;
обеспечению сохранности информационных ресурсов.
При организации резервного вычислительного центра участника платежного рынка также выполняются следующие требования:
между резервным вычислительным центром участника платежного рынка и основным или резервным вычислительным центром платежной системы организуется отдельный канал связи. Допускается использование данного канала связи в качестве резервного канала связи для основных объектов программно-технической инфраструктуры;
между основным и резервным вычислительными центрами участника платежного рынка связь организуется без использования физических каналов связи с основным и резервным вычислительными центрами платежной системы.
96. При размещении резервных объектов программно-технической инфраструктуры на резервном вычислительном центре участника платежного рынка обеспечивается доступ к информационным ресурсам в соответствии с применяемой политикой информационной безопасности, а также минимизируется вероятность их уничтожения вследствие кризисных (сбойных) ситуаций.
97. Участник платежного рынка контролирует работоспособность резервного вычислительного центра путем планового перехода на его использование вместо основного вычислительного центра не реже одного раза в полгода согласно утвержденному графику.
98. Процедуры перехода с основного на резервный вычислительный центр и обратно участник платежного рынка определяет в ПОНРВ.
| Приложение к стандарту проведения расчетов |
НЕОБХОДИМОСТЬ ВЫПОЛНЕНИЯ ТРЕБОВАНИЙ ДЛЯ УЧАСТНИКОВ ПЛАТЕЖНОГО РЫНКА
Требование | Пункт | Участники системно значимой платежной системы | Участники потенциально значимой платежной системы | Участники социально значимой платежной системы | Участники иной платежной системы | Поставщики платежных услуг, не являющиеся участниками платежной системы | Поставщики технологических услуг |
Организация резервного вычислительного центра | 15 | + | + | + | +/– | +/– | +/– |
Организация резервного канала связи | 16 | + | + | + | +/– | +/– | +/– |
+ требование обязательно к соблюдению
+/– требование не обязательно к соблюдению