Комплексний аудит ІТ-інфраструктури перед впровадженням системи документообігу

Оцінка серверних ресурсів та операційного середовища

Серверна платформа забезпечує функціонування системи управління базами даних (СУБД) та серверів застосунків документообігу. Під час технічного аналізу фахівці досліджують апаратні ресурси: обсяг оперативної пам’яті, обчислювальну потужність процесорів і параметри дискових масивів. Для кожної організації визначаються специфічні графіки навантаження, оскільки пікові періоди реєстрації чи погодження документів залежать від внутрішніх регламентів установи.

Як методичні орієнтири для оцінки захищеності серверних систем залучаються матеріали NIST SP 800-123 (2008), які мають добровільний характер і застосовуються для адаптації конфігурацій під конкретні завдання. Неоптимальне налаштування служб баз даних або низька швидкість накопичувачів можуть викликати затримки при створенні картки документа чи формуванні звітів.

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

Аналіз локальної мережі та робочих місць користувачів

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

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

Захист даних, резервне копіювання та процедури відновлення

Поступовий перехід від виключно паперових архівів до електронного документообігу висуває підвищені вимоги до систем збереження інформації. Перевірка регламентів резервного копіювання може спиратися на добровільні методичні рекомендації NIST SP 800-34 (2002), що описують підходи до планування відновлення ІТ-систем після аварійних ситуацій. Перевіряються періодичність створення копій СУБД, швидкість пробного відновлення та наявність зовнішніх сховищ.

Методичні підходи до технічних перевірок описано у NIST SP 800-115 (2008). В організації варто перевірити правила міжмережевих екранів, облікові записи адміністраторів і права користувачів у службі каталогу, якщо вона застосовується. Активне тестування погоджують із відповідальними за експлуатацію, визначаючи допустимий вплив на робочі сервіси. Результат обстеження — перелік виявлених ризиків із рекомендаціями щодо їх усунення.

• Інвентаризація серверного обладнання та оцінка придатності наявних ПК для повторного використання.
• Аналіз пропускної здатності каналів зв'язку між підрозділами організації.
• Перевірка регламентів створення та періодичності відновлення резервних копій.
• Аналіз прав доступу користувачів і налаштувань безпеки в домені.
• Перевірка сумісності периферійного обладнання та сканерів із робочими станціями.
• Формування узгодженого переліку робіт і критеріїв оцінки успішності пілотного проєкту.

Нормативні вимоги, ЕЦП та сумісність із наявним ПЗ

Закон України № 851-IV «Про електронні документи та електронний документообіг» у редакції, чинній станом на 9 грудня 2009 року, у статті 6 визначає електронний підпис обов'язковим реквізитом для ідентифікації автора. Стаття 7 описує електронний оригінал з обов'язковими реквізитами, зокрема електронним цифровим підписом (ЕЦП). Тому аудит має охоплювати сумісність обраних засобів підпису з операційними системами та робочими місцями, а також порядок зберігання ключів і перевірки підписаних документів.

Також оцінюється сумісність із наявним бухгалтерським та кадровим ПЗ. Якщо підтримуються відповідні технології, для міжсистемного обміну розглядаються вебсервіси на основі XML та стандарту W3C SOAP 1.2 (2007). Для побудови коректної взаємодії виконується аналіз форматів даних та розробка вимог до інтеграційних рішень.

Методологія обстеження, інтерв'ю з діловодами та сценарії пілоту

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

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

Що отримує замовник за результатами аудиту

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

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

Керівник отримує обґрунтування обсягу проєкту, ІТ-служба — перелік робіт із пріоритетами, а працівники діловодства — можливість перевірити майбутній процес до загального запуску. Після усунення критичних зауважень результати пілоту допомагають вирішити, чи готова організація до наступного етапу впровадження.

Запитання та відповіді

Чи означає аудит обов’язкову заміну всієї техніки?

Ні. Він має визначити, що можна використовувати далі, що потребує налаштування чи розширення, а що справді потрібно замінити.

Навіщо перевіряти відновлення з резервної копії?

Щоб установити, чи можна повернути дані й робочі сервіси та скільки часу це потребує. Сам факт створення копії не дає відповіді на ці питання.

Який результат аудиту потрібен замовнику?

Обґрунтований перелік обмежень і робіт із пріоритетами, оцінка сумісності та погоджені сценарії пілоту перед загальним запуском.

Джерела

• NIST SP 800-115 (2008) — Технічні перевірки безпеки
• NIST SP 800-123 (2008) — Захист серверів мережевих сервісів
• NIST SP 800-34 (2002) — Планування відновлення ІТ-систем
• Закон України № 851-IV «Про електронні документи та електронний документообіг» (у ред., чинній станом на 09.12.2009)
• W3C SOAP 1.2 — Специфікація протоколу обміну повідомленнями (2007)