НАЦІОНАЛЬНИЙ БАНК УКРАЇНИ

ЛИСТ

від 12.04.2012 р. N 57-009/784

Департамент інформаційних технологій
Центральна розрахункова палата

Головному управлінню НБУ в Автономній Республіці Крим, Головному управлінню НБУ по м. Києву та області, територіальним управлінням НБУ, структурним одиницям та навчальним закладам НБУ, ОПЕРУ НБУ, ОПЕРУ Державного казначейства України, Центральній розрахунковій палаті, банкам України та їх філіям - безпосереднім учасникам системи електронних платежів,
органам Держказначейства - безпосереднім учасникам системи електронних платежів
ПрАТ "Всеукраїнський депозитарій цінних паперів"

Тема: СЕП 

Повідомляємо, що Департаментом інформаційних технологій та Центральною розрахунковою палатою здійснено аналіз нештатних ситуацій в роботі банків у СЕП, які відбулися останнім часом. Надаємо детальний розгляд причин, які викликали ці ситуації, та рекомендації з їх усунення.

1. Для роботи АРМ-СЕП необхідною умовою є наявність актуального таємного ключа програмної системи захисту інформації. Нагадуємо, що цей ключ є необхідним, незалежно від того, що в штатному режимі АРМ-СЕП працює з апаратурою криптографічного захисту інформації.

У разі відсутності такого ключа АРМ-СЕП не зможе ініціювати систему захисту інформації, а отже, взагалі виявиться неспроможним приймати-передавати платежі та технологічну інформацію.

Причинами втрати цього таємного ключа у учасників були:

• нерозуміння того, що цей ключ є необхідним ("адже АРМ-СЕП працює з апаратурою");

• відсутність резервної копії ключа і псування єдиного його екземпляру;

• незважаючи на те, що дисковод на комп'ютері з АРМ-СЕП виявився зіпсованим і фізично пошкодив дискету з ключем, персонал негайно вставив у цей дисковод і резервну дискету (яку дисковод також одразу зіпсував);

• "людський фактор" - "забули" вчасно згенерувати ключ, незважаючи на те, що АРМ-СЕП починає попереджати про вичерпання строку його дії за тиждень.

Рекомендуємо:

1) забезпечувати належну кількість копій таємного ключа для роботи АРМ-СЕП;

2) приділити увагу переходу установи на роботу з апаратними носіями таємного ключа, взявши за мету відмовитись від дискет, як застарілого та менш надійного носія;

3) вчасно виконувати оновлення таємного ключа, тобто генерувати та відправляти на сертифікацію новий ключ, не очікуючи повного вичерпання строку дії попереднього.

2. Виявлено учасників, які, всупереч рекомендаціям НБУ щодо встановлення та настройки АРМ-СЕП, розмістили каталоги (папки) обміну АРМ-СЕП з САБ та з СЕП на мережевому диску.

Нагадуємо, що рекомендація розміщувати папки обміну АРМ-СЕП (вхідні і вихідні папки з/до САБ і СЕП) на локальному диску комп'ютера, на якому розміщено АРМ-СЕП, міститься в експлуатаційній документації АРМ-СЕП ("Автоматизоване робоче місце АРМ-НБУ учасника системи електронних платежів Національного банку України", наданій листом 23.03.2007 N 24-112/522).

Недотримання цієї вимоги може призвести до некоректної роботи АРМ-СЕП та/або САБ, причому сутність наслідків широко варіюється залежно від алгоритмів формування вихідних файлів у САБ, версії мережевого програмного забезпечення тощо. Зокрема, якщо САБ не закінчила формування файлу на мережевому диску, але цей файл доступний для АРМ-СЕП, то даний файл може бути спочатку відбракований АРМом-СЕП, а після закінчення формування - взятий в оброблення як "новий, виправлений" варіант.

Рекомендуємо:

ретельно дотримуватися рекомендацій щодо настройки операційної системи та АРМ-СЕП, викладених в експлуатаційній документації. Зокрема, розміщувати вхідні і вихідні папки з/до САБ і СЕП на локальному диску комп'ютера, на якому розміщено АРМ-СЕП, і переміщувати туди файли для обробки з мережевих папок, наприклад, відповідними командами операційної системи в файлах mail_in.bat та mail_out.bat.

3. Просимо звернути увагу на пункти і 4.3.2.3 і 9.3 документа "Система електронних платежів Національного банку України. Опис інтерфейсу між САБ банку і СЕП НБУ" (файли struct_1.doc і struct_4.doc відповідно), на докладний опис в них реквізиту "Місце формування пакета-відповіді" і процедури з'ясування долі пакетів-запитів, на які не отримано достовірної відповіді від ЦОСЕП.

Якщо в реквізиті "Місце формування пакета-відповіді" зазначено, що цей пакет сформував АРМ-СЕП унаслідок того, що не зміг прийняти пакета-відповіді від ЦОСЕП, то це свідчить про відбраковку пакета-відповіді на АРМ-СЕП, а отже, про відсутність інформації про результати виконання пакета-запиту.

Наприклад, розглянемо ситуацію: пакет-запит 1.08 на виконання платежу відправлено до ЦОСЕП, там його оброблено успішно, платіж прийнято до СЕП, ЦОСЕП формує пакет-відповідь з нульовим кодом помилки. Проте, якщо до отримання пакета-відповіді зникає зв'язок між АРМ-СЕП і ЦОСЕП, або під час отримання пакета-відповіді на АРМ-СЕП діагностується помилка (наприклад, пакет-відповідь не розшифрувався), то АРМ-СЕП формує для САБ пакет-відповідь з ненульовим кодом помилки, який описує негативні результати приймання пакета-відповіді від ЦОСЕП, і з вказанням "S" у реквізиті "Місце формування пакета-відповіді".

Ті САБ1, які не беруть до уваги реквізит "Місце формування пакета-відповіді", а орієнтуються виключно на ненульовий код помилки в пакеті-відповіді, у такій ситуації зроблять хибний висновок про те, що пакет-запит забраковано, платіж не пройшов, і, відповідно, будуть намагатися передати його в новому пакеті он-лайнового режиму або в файловому режимі, що призведе до подвоєння платежів.


1 Усе викладене в цьому листі щодо САБ стосується також і внутрішньобанківської міжфілійної платіжної системи (ВМПС) щодо її взаємодії з СЕП та організації безперебійного функціонування.

Рекомендуємо:

1) під час оброблення в САБ пакетів-відповідей режиму реального часу з ненульовим кодом помилки реалізувати алгоритм з урахуванням інформації, викладеної в пункті 9.3 "Опису інтерфейсу", а саме:

• якщо реквізит "Місце формування пакета-відповіді" дорівнює "пробілу", то вважати, що пакет-запит забраковано;

• якщо реквізит "Місце формування пакета-відповіді" дорівнює "S", то вважати, що достовірної інформації про даний пакет-запит немає, і якщо це був пакет 1.08 (початковий платіж) - вживати заходів для з'ясування результатів його проходження (див. п. 4.3.2.3 Опису інтерфейсу).

2) звернути увагу на окреме оброблення коду помилки "8001" - "Повторне надходження он-лайнового переказу, вже проведеного". Цей код свідчить про те, що он-лайновий переказ із зазначеними реквізитами вже наявний у ЦОСЕП. Отже, якщо учасник пробує з'ясувати долю он-лайнового платежу шляхом його повторного відправлення і отримує цей код помилки, то це означає, що даний он-лайновий платіж вже успішно здійснено.

4. Відбраковка початкових платежів у СЕП у більшості випадків є нештатною ситуацією. Практично, "штатною" можна вважати тільки відбраковку з причини нестачі коштів при роботі за моделлю з безпосередньою участю філій у СЕП. У решті випадків відбраковка свідчить про нештатну ситуацію, у якій немає сенсу продовжувати обмін платежами без виправлення причини цієї ситуації. Наприклад, розбіжність ключової системи захисту інформації; розбіжність в довіднику учасників СЕП; помилки або збої в програмному забезпеченні банку; робота банку зі старою версією АРМ-СЕП тощо.

Рекомендуємо:

реалізувати в банку такий алгоритм дій у разі надходження щонайменше:

• квитанції про відбраковку файла $A;

• пакета-відповіді про відбраковку пакета 1.08;

• пакета-відповіді, в якому зазначено про неможливість отримати достовірну відповідь про пакет-запит 1.08:

1) САБ має автоматично зупинити обмін з СЕП, щонайменше обов'язково припинити відправку початкових платежів, і повідомити про це персонал;

2) персонал має з'ясувати причину відбраковки та усунути її;

3) якщо отримано пакет-відповідь про неможливість отримати достовірну відповідь про пакет-запит 1.08, то з'ясувати, чи його прийнято в ЦОСЕП (див. попередній пункт даного листа);

4) у випадках, коли є підозра на некоректне функціонування програмного забезпечення САБ / АРМ-СЕП / ЦОСЕП, персонал має проаналізувати ситуацію та вжити заходів для повного її розуміння та визначення результатів проходження ініційованих початкових платежів, зокрема, переконатися, що подальші дії не призведуть до подвоєння платежів;

5) тільки після цього вживати дій, рекомендованих відповідно до технології роботи даного САБ, для того, щоб повторно відправити платежі з забракованих файлів до СЕП.

Аналогічно, сигналом про загальну непрацездатність ланцюгу обміну між СЕП, АРМ-СЕП та САБ учасника, який потребує негайного реагування та виправлення ситуації, є надходження квитанції $O про відбраковку на АРМ-СЕП будь-якого файлу (як від САБ, так і отриманого від СЕП).

5. Інформація, яку отримує САБ про один і той самий файл початкових платежів $A (або платіж он-лайнового режиму) від АРМ-СЕП і ЦОСЕП, повинна бути несуперечливою і відповідати тій інформації, яку наразі має про них САБ.

Наприклад:

Якщо АРМ-СЕП відбракував файл $A (квитанція $O), а потім надійшла квитанція $T від ЦОСЕП про цей самий файл та/або інформація про нього в файлі $K, то це означає, що без відома САБ банку даний файл $A було відправлено до ЦОСЕП (причиною можуть бути ручні дії персоналу, недотримання вимог щодо розміщення каталогів АРМ-СЕП на локальному диску тощо).

Якщо учасник отримує квитанцію $T та/або інформацію в файлі $K, у який кількість платежів, суми за файлом або ЕЦП відрізняються від реквізитів файлу $A в САБ (за винятком ситуації "файл не розшифрувався", коли ці реквізити нульові), це свідчить про несанкціонований доступ від імені цього учасника або про невправне повторне відправлення банком раніше забракованого файлу.

Рекомендуємо:

реалізувати в САБ звіряння усієї технологічної інформації, яка надходить від СЕП до САБ банку щодо результатів оброблення файлів / он-лайнових платежів, з поточною інформацією про їх статус у САБ. У разі виявлення суперечностей негайно зупиняти обмін платежами з СЕП та інформувати персонал про сутність розбіжностей.

6. Необхідним етапом завершення банківського дня в СЕП є формування учасником файлу $Z та його перевірка в ЦОСЕП.

Відсутність файлу $Z від учасника до часу, визначеного регламентом, розглядається як сигнал про негаразди в банку. Від учасників вимагалися пояснення щодо причин кожного ненадання файлу $Z.

Аналіз зазначених пояснень за 2011 і перший квартал 2012 р. виявив такі основні причини ненадання файлу $Z.

Причина

% від загальної кількості

Організаційні недоліки в учасника і "людський фактор"

30 %

Виявлення помилок та збої в програмному забезпеченні системи автоматизації банку

30 %

- у тому числі після встановлення нового програмного забезпечення

10 %

Збої та технічні проблеми на вузлі електронної пошти банку

10 %

Вихід з ладу техніки і проблеми щодо відновлення роботи

15 %

Об'єктивні причини, що лежать поза межами впливу учасника

1 %

Відсутність телекомунікаційного зв'язку між учасником та НБУ

2 %

Відсутність електроживлення

2 %

За змістом пояснень причина незрозуміла ("відписка")

10 %

Вищенаведене свідчить про досить низький рівень відповідальності значної кількості учасників СЕП за належну організацію роботи і забезпечення безперебійного виконання такої важливої ланки діяльності банку як міжбанківські платежі.

Слід зазначити такі загальні недоліки:

1. Відсутність повноцінної системи резервування та відновлення роботи. У разі виходу з ладу технічного забезпечення проблеми щодо відновлення роботи спричинюються або відсутністю відповідної резервної техніки взагалі, або тим, що резервна техніка існує, але процедури переходу на її роботу не відпрацьовані і займають багато часу. Наприклад, може бути виділений резервний комп'ютер для АРМ-СЕП, але сам АРМ-СЕП на ньому не розгорнуто та/або не підтримується в актуальному стані резервна копія ключової системи.

2. Досить великою є кількість проблем, викликаних помилками та збоями в програмному забезпеченні САБ учасників. Зокрема, значна кількість помилок і збоїв викликана такою штатною ситуацію як закінчення звітного місяця.

Особливе занепокоєння викликають випадки, коли учасник СЕП повторює одні й ті самі пояснення щодо непрацездатності свого програмного забезпечення. Наприклад, Головне управління Державного казначейства України у Київській області посилалося на "вихід з ладу програмного забезпечення, яке формує $Z", 5 разів за зазначений період.

3. Серед причин, які викликають нештатну роботу учасника, досить часто зазначається "перехід на нове програмне забезпечення", що свідчить про неналежний рівень його тестування перед впровадженням.

Рекомендуємо:

1. Дотримуватися вимог нормативних актів Національного банку України з питань забезпечення безперервного функціонування інформаційних систем, зокрема, мати резервну техніку та добре опрацьовані процедури відновлення роботи для всіх ключових ланок, які задіяні у виконанні платежів, а саме: САБ, вузол системи електронної пошти, АРМ-СЕП, відповідні сервери.

2. Докладно опрацьовувати з розробниками САБ кожний випадок некоректної роботи її програмного забезпечення та вживати заходів для ліквідації помилок.

3. Звернути увагу розробників САБ на те, що будь-які збої, вихід з ладу технічного обладнання тощо не повинні приводити до руйнування бази даних або появи в ній нецілісної інформації. Має бути передбачено механізм транзакцій, засоби діагностики, відновлення тощо, які повинні надавати змогу після збоїв відновлювати цілісний стан бази даних, включаючи фактично здійснені операції.

4. При розробленні і впровадженні нових версій САБ користуватися можливістю відпрацювати взаємодію з СЕП на стенді СЕП у Центральній розрахунковій палаті.

5. У разі надання Національному банку пояснень та клопотань, у яких згадуються "технічні проблеми / збої", більш конкретно деталізувати зміст проблем. Якщо йдеться про помилки та збої в системі автоматизації банку та/або внутрішньобанківській платіжній системі, то слід вказати фірму-розробника зазначеного програмного забезпечення та більш детально вказати сутність збою/помилки.

6. Також нагадуємо про вимогу Положення про забезпечення безперервного функціонування інформаційних систем Національного банку України та банків України, затвердженого постановою Правління Національного банку України від 17.06.2004 N 265 (зі змінами), щодо формування і зберігання архівів особливо важливих даних.

Окремо наголошуємо на необхідності персоналу, до повноважень якого входить обслуговування АРМ-СЕП та АРМ-НБУ-інформаційного, вивчити експлуатаційну документацію та дотримуватися викладених в ній вимог та рекомендацій.

 

Заступник директора
Генерального департаменту інформаційних
технологій та платіжних систем -
директор Департаменту
інформаційних технологій

О. О. Білаш

Начальник
Центральної розрахункової палати

Ю. Л. Бендерський

 




 
 
Copyright © 2003-2018 document.UA. All rights reserved. При використанні матеріалів сайту наявність активного посилання на document.UA обов'язково. Законодавство-mirror:epicentre.com.ua
RSS канали