Витік даних у Fakturownia - що робити?

29 вересня 2026 року Fakturownia повідомила, що напередодні виявила несанкціонований доступ до своїх серверів. За даними оператора, доступ міг охоплювати дані облікових записів, контрагентів, частини рахунків-фактур, хеші паролів і токени, створені на боці Fakturownia. Масштаб витоку ще встановлюють.

Змініть пароль, захистіть пов’язану електронну пошту, увімкніть двоетапну перевірку та перевірте користувачів облікового запису й банківські реквізити на рахунках-фактурах. За переданою нам інформацією, у листі до клієнтів від 29 вересня Fakturownia оголосила про анулювання всіх токенів API 1 жовтня 2026 року. Якщо ви користуєтеся інтеграціями, підготуйтеся до їхнього оновлення.

Наведені нижче поради ґрунтуються на інформації, доступній 29 вересня 2026 року. Fakturownia заявляє, що інтеграція з KSeF не постраждала, а сертифікати KSeF залишилися в безпеці. Однак за принципом обмеженої довіри ми рекомендуємо як запобіжний захід замінити також токени й сертифікати KSeF, які використовувалися у Fakturownia.

Видання Zaufana Trzecia Strona описує отримані матеріали, що вказують на доступ до систем Fakturownia. Водночас обсяг викрадених даних, названий співрозмовником редакції, слід відрізняти від перевіреного масштабу інциденту.

Що відомо про витік?

Що з’ясувала Zaufana Trzecia Strona?

Що зробити насамперед?

Що зробити до анулювання токенів API 1 жовтня?

Чи стосується інцидент KSeF?

Як перевіряти платежі й повідомлення?

Які обов’язки можуть виникнути у компанії?

Чи потрібно змінювати програму?

Поширені запитання

Оператор повідомляє про використання вразливості в системі. За його словами, несанкціонований доступ перекрито, запущено нові сервери, розпочато ротацію ключів і паролів сервісів, а інцидент аналізують разом із зовнішніми фахівцями. Оператор також заявляє, що повідомив про подію польське Центральне бюро боротьби з кіберзлочинністю (CBZC), CERT Polska та голову Управління із захисту персональних даних Польщі (UODO). 28 вересня є датою виявлення інциденту; повідомлення не визначає, коли почався несанкціонований доступ.

Можливий обсяг доступу охоплює облікові записи всіх користувачів і дані їхніх контрагентів. Це ще не підтвердження розкриття повного набору даних кожної людини. Варто розрізняти окремі категорії:

29 вересня Adam Haertle із Zaufana Trzecia Strona описав спілкування з особою під псевдонімом Fingerprint. За словами автора, співрозмовник передав редакції три знімки екрана, які вона визнала доказами доступу до систем Fakturownia. В описі йдеться про каталог застосунку, фрагмент списку клієнтів і список файлів, що вказують на експортовану базу даних.

Співрозмовник також стверджував, що отримав 6 ТБ рахунків-фактур. Zaufana Trzecia Strona прямо зазначила, що не змогла перевірити цю інформацію. Тому 6 ТБ залишаються заявою зловмисника, яку наводить редакція, а не підтвердженим розміром витоку.

Для користувача важливе охоплення описаних матеріалів: вони стосуються сервера застосунку й даних клієнтів, тому перевірка доступів має включати також інтеграції та токени. Точний обсяг даних конкретної компанії ще має встановити оператор. Публікація Z3S також не уточнює, які рахунки-фактури саме за 2023 рік могли бути розкриті.

Хеш пароля є значенням, обчисленим на основі пароля. Його отримання може дати змогу підбирати пароль, але не означає автоматичного розкриття самого пароля. У повідомленні не описано спосіб захисту цих хешів. Окремо згадані системні ключі й паролі застосунку не є паролями клієнтів для входу.

Щодо документів Fakturownia вказує на рахунки-фактури, виставлені «до 2023 року». Водночас повідомляє, що, за наявною в неї інформацією, витоку рахунків-фактур, виставлених «після 2023 року», не було. Сам 2023 рік у цьому описі залишається неоднозначним. Які саме ваші документи зачепив інцидент, варто уточнювати за подальшими повідомленнями оператора.

Fakturownia заявляє, що дані з її систем не видаляли, а порушення не торкнулося даних платіжних карток. Однак те, що документи не видалені, не виключає доступу до їхнього вмісту чи використання інформації для шахрайства.

Відкрийте обліковий запис за відомою адресою або через власну закладку. Тривожний лист із кнопкою «захистити обліковий запис» сам може бути спробою виманити дані. Далі виконайте такі кроки:

1. Установіть новий унікальний пароль до Fakturownia. Якщо старий пароль використовувався також деінде, змініть його в кожному з цих сервісів. Менеджер паролів допоможе використовувати окремий пароль для кожної послуги.

2. Захистіть електронну пошту, пов’язану з обліковим записом. Fakturownia рекомендує змінити і її пароль. Перевірте налаштування відновлення доступу та двоетапної перевірки, адже пошта часто використовується для скидання паролів в інших програмах.

3. Увімкніть двоетапну перевірку у Fakturownia. Перегляньте список користувачів і з’ясуйте походження кожного невідомого доступу. Також узгодьте з адміністратором, як завершити підозрілі сесії; сама зміна пароля не підтверджує їхнього закриття.

4. Порівняйте банківський рахунок у налаштуваннях із правильним рахунком компанії та перевірте його на поточних рахунках-фактурах. Якщо знайдете розбіжність, установіть, які документи вже надійшли одержувачам, і зв’яжіться з ними відомим каналом.

У компанії з кількома користувачами кожен має захистити власний доступ. Одноразова зміна пароля власником не замінює перевірки решти облікових записів.

За переданою нам інформацією про електронний лист Fakturownia до клієнтів від 29 вересня 2026 року, оператор оголосив про анулювання всіх токенів API 1 жовтня 2026 року. Це запланована дія щодо доступу через API, окрема від зміни пароля облікового запису й ротації системних ключів.

Токен API дає підключеній програмі змогу користуватися обліковим записом без ручного введення пароля щоразу. Після його анулювання програма не зможе виконувати операції, що потребують цього токена, доки не отримає чинних даних доступу. Це може зупинити отримання чи передавання рахунків-фактур та автоматизації, які використовують це з’єднання.

До 1 жовтня разом з адміністратором або інтегратором складіть список програм, що користуються Fakturownia, і призначте відповідального за оновлення кожного з’єднання. Час створення нового токена визначте за вказівками Fakturownia. Це важливо й тоді, коли токен уже замінили після інциденту: потрібно підтвердити, чи залишиться він чинним після оголошеної операції.

Якщо ви вже користуєтеся інтеграцією Fakturownia у KSeFGPT, після заміни токена виберіть потрібну компанію, відкрийте Інтеграції та натисніть Редагувати на відповідній картці. Вставте новий токен, натисніть у формі Перевірити з'єднання та збережіть зміни. Подробиці наведено в інструкції з підключення Fakturownia.

Після відновлення з’єднання перевірте, які операції завершилися успішно, а які очікують повторного виконання. Перш ніж знову надсилати рахунок-фактуру до KSeF, перевірте його поточний статус і номер KSeF, щоб не виставити вдруге документ, який система вже прийняла.

Не надсилайте токени у зверненнях до підтримки, повідомленнях або на знімках екрана. Успішний тест підтверджує працездатність указаних даних доступу; він не є аудитом безпеки облікового запису.

Fakturownia заявляє, що інцидент не торкнувся даних, збережених у її розділі інтеграцій і додатків, зокрема сертифікатів KSeF, польської Національної системи електронних рахунків-фактур. Водночас оператор згадує можливий доступ до токенів, створених на боці самої Fakturownia. Ці два повідомлення стосуються різних даних доступу, тому їх не слід ототожнювати.

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

Токен API Fakturownia, токен KSeF і сертифікат KSeF потребують окремого керування. Сама заміна токена API Fakturownia не замінює ротації засобів автентифікації KSeF. Разом з адміністратором або інтегратором визначте всі місця їхнього використання, замініть дані доступу й перевірте з’єднання. Анулювання старих засобів автентифікації може перервати роботу залежних від них інтеграцій до їхнього оновлення.

Bankier.pl у матеріалі Польського агентства преси (PAP), оновленому 29 вересня о 21:00, також наводить повідомлення Міністерства фінансів Польщі. За цією публікацією, після перевірки міністерство не виявило порушення безпеки KSeF або витоку даних, що перебувають у його розпорядженні.

Інформація про KSeF не визначає обсягу доступу до копій документів, які зберігає приватний постачальник. Щодо конкретного облікового запису й рахунків-фактур стежте за результатами перевірки Fakturownia.

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

Наприклад, у повідомленні можуть посилатися на конкретний рахунок-фактуру й просити терміново переказати гроші на «новий банківський рахунок після інциденту». Це ілюстрація ризику, а не опис підтвердженої події. Підтвердьте зміну в контрагента телефоном за номером, який знали ще до отримання повідомлення. Не користуйтеся номером, уперше вказаним у цьому запиті.

Не передавайте паролі, коди підтвердження, коди BLIK або дані картки людині, яка звертається щодо інциденту. Якщо телефонує нібито представник банку, завершіть розмову й самі наберіть офіційний номер. Навіть правдоподібна адреса відправника сама по собі не підтверджує безпечності повідомлення.

Підозріле SMS можна переслати до CERT Polska на номер 8080 відповідно до рекомендації Fakturownia. Якщо гроші вже надіслано на підозрілий рахунок, негайно зв’яжіться з банком його офіційним каналом і збережіть повідомлення та підтвердження переказу. Можливість повернення коштів залежить від конкретної ситуації.

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

Якщо ваша компанія є контролером даних, яких торкнулося порушення, оцініть і задокументуйте ризик для прав чи свобод фізичних осіб. UODO пояснює, що про порушення потрібно повідомити компетентний орган без невиправданої затримки, за можливості протягом 72 годин із моменту, коли про нього стало відомо, крім випадків, коли малоймовірно, що воно спричинить такий ризик. Цей строк не відраховують автоматично від публікації новини у ЗМІ.

Якщо ви дієте як обробник даних, повідомте контролера без невиправданої затримки. Контролер, який ще не має всієї інформації, може подати попереднє повідомлення з доступними відомостями. Повідомлення, подане Fakturownia, не замінює власної оцінки обов’язків вашої компанії.

За високого ризику може також виникнути обов’язок повідомити людей, чиїх даних стосується порушення, з урахуванням винятків, передбачених Загальним регламентом ЄС про захист даних (GDPR, у Польщі RODO). Це окрема оцінка від рішення про повідомлення органу. Проведіть її з відповідальною за захист даних особою, враховуючи становище конкретних людей.

Зміна програми не скасовує розкриття копій даних. Спочатку захистіть доступи, з’ясуйте обсяг інциденту й перевірте платежі. Рішення про подальшу співпрацю з постачальником ухвалюйте на основі його повідомлень, потреб компанії та умов роботи з документами.

Якщо виберете інший інструмент, заплануйте збереження архіву, перевірку дозволів і вимкнення непотрібних з’єднань. Видалення конфігурації інтеграції з одного застосунку не обов’язково анулює токен у сервісі, який його видав. Тому це не замінює узгодженої з адміністратором перевірки доступів.

Для подальшої перевірки доступу та роботи з документами стануть у пригоді:

Налаштування інтеграції з Fakturownia, зокрема після заміни токена API.

Видалення інтеграції у KSeFGPT, коли з’єднання більше не потрібне.

Надання бухгалтерії доступу до перегляду рахунків-фактур, щоб упорядкувати обсяг доступу.

Дії з рахунком-фактурою за чужі покупки, якщо отриманий документ викликає сумніви.