Перенос данных: основные риски.
При переходе на новое программное обеспечение, типы файловых хранилищ и СУБД предприятию необходимо организовать перенос данных из одной информационной системы в другую. Ознакомимся с алгоритмом, направленным на минимизацию рисков совершения ошибок при решении такой задачи.
Перенос данных: основные риски
Перенос (миграция) данных из одной информационной системы в другую может сопровождаться — если не будет организована должным образом:
1. Искажением передаваемой информации, которое приводит:
- к невозможности корректного ее использования в новой (целевой) ИС;
- к частичной утрате информации (и издержкам на восстановление).
2. Нарушениями установленных законом (отраслевыми, корпоративными стандартами) правил обработки информации (допущению ее утечки, несанкционированного доступа).
3. Вынужденными перерывами в обработке информации (и если они критически значимы для производства, то произойдет остановка работы предприятия).
Рассмотрим нижеследующий алгоритм, который поможет снизить указанные риски.
Как уменьшить риски?
В этих целях необходимо последовательно:
1. Идентифицировать данные, которые подлежат миграции (условимся именовать их защищаемыми данными), выделить их из массива прочих данных, не подлежащих переносу (или не относящихся к защищаемым по иным причинам).
В основе указанной идентификации будут:
- перечни данных, обрабатываемых текущей информационной системой, которую планируется заменить на целевую;
- перечни данных, которые должны дополнять защищаемые для обеспечения их корректной обработки в целевой системе.
2. Разработать график миграции защищаемых данных (отдельных их категорий).
Многие типы данных будут использоваться для обеспечения текущих производственных операций на предприятии. Их миграцию необходимо запланировать на внерабочее время (время организации перерывов в работе, имеющих достаточную длительность).
3. Определить критерии валидации (проверки на предмет целостности, совместимости с целями обработки) данных, передаваемых из старой ИС в целевую.
На основании этих критериев впоследствии будет оцениваться завершенность переноса защищаемых данных. Критерии должны учитывать функциональные возможности новой системы (либо дополняющих ее программ).
4. Убедиться в наличии программно-технических средств, обеспечивающих приведение данных в соответствие с критериями валидации.
Одним из таких критериев может быть представление файлов в новой информационной системе в определенном формате (например, XML). Если штатными средствами соответствующей системы обеспечить отмеченное соответствие нельзя, то необходимо предусмотреть дополнение системы подходящими внешними программами.
5. Произвести резервное копирование защищаемых данных (либо удостовериться в наличии механизмов, обеспечивающих надежное сохранение данных в исходной информационной системе по завершении их переноса в целевую систему).
Также необходимо проверить, может ли текущая система корректно обрабатывать данные, восстановленные из резервной копии.
6. Произвести обучение пользователей целевой ИС порядку обработки защищаемых данных, которые в нее поступят.
Акцент в соответствущем обучении можно сделать на выявлении различий между характеристиками и функционалом текущей системы и целевой, а также на целенаправленной работе над освоением нового функционала при обработке защищаемых данных.
По итогам обучения может быть оформлена организационно-распорядительная документация (например, составлены пользовательские и должностные инструкции, изданы локальные акты на получение допуска работников предприятия к новой системе).
7. Произвести тестовую миграцию — незащищенных данных, представленных в тех же форматах, что и защищенные данные (соответственно, имеющих аналогичные критерии валидации).
8. Произвести валидацию незащищенных данных (в соответствии с установленными критериями), переданных в новую систему.
9. Сформировать отчет по валидации, отразить в нем выявленные ошибки (не только при анализе критериев валидации, но и иные, осложняющие практическую работу в целевой ИС).
10. Произвести в целевой системе обработку тестовых данных способами:
- при наличии возможности (функционала) — аналогичными тем, что характерны для исходной системы;
- дополняющими те, что характерны для исходной системы (то есть, реализуемые в рамках более широких функциональных возможностей новой системы);
- принципиально новыми, что реализованы только на уровне целевой ИС.
11. Сформировать отчет по обработке тестовых данных, отразить в нем:
- выявленные ошибки (не только при обработке, но и иные сопутствующие, которые препятствуют применению возможностей новой ИС);
- рекомендации по последующей обработке данных в целевой системе.
12. Исправить выявленные ошибки и произвести повторную тестовую передачу (обработку) данных.
Как только будет установлено, что тестовый массив передан в новую систему, произведена его валидация, обработка, и при этом нет иных ошибок, то можно производить миграцию защищаемых данных — осуществляя действия, соответствующие п. 7, 8 и 10 рассмотренного алгоритма. Последующую их обработку — осуществлять с учетом рекомендаций, сформированных при тестовой передаче (обработке).
Формирование специальных отчетов по передаче и обработке защищаемых данных (издание дополнительных рекомендаций) также возможно, если это следует из принципов выстраивания политики информационной безопасности предприятия. Либо — по решению компетентных специалистов или руководства компании, продиктованному фактическими обстоятельствами.
Есть ряд нюансов, которые заслуживают внимания при следовании указанному алгоритму.
Что учесть при миграции данных?
Прежде всего, следующее:
1. В целях повышения качества идентификации данных (как и тестирования их передачи и обработки) можно распределить их по категориям.
Могут быть выделены данные (их источники):
- фиксированного характера (пример — первичная документация для бухгалтерии);
- переменного характера (регистры бухгалтерского учета);
- критически значимые для деятельности предприятия (локальные акты, распоряжения руководства);
- вспомогательные (служебные записки, обращения).
В отношении каждой категории данных определяются оптимальные критерии валидации (например, наличие действующей электронно-цифровой подписи или машиночитаемой доверенности в связке с критически значимым документом).
2. Специфика переноса данных может зависеть от целей осуществления миграции (причин смены текущей информационной системы на новую).
Так, одной из целей миграции может быть выделение защищаемых данных, наиболее значимых и актуальных для пользователя при обработке в новой системе (и, соответственно, архивирование либо удаление устаревших, которые обрабатывать нецелесообразно или нежелательно). В этом случае критерии актуальности (например, дату создания документа или завершения его в делопроизводстве) необходимо включить в перечень критериев валидации — так, чтобы случайно принятые в новую систему устаревшие данные были своевременно выявлены до начала их обработки.
Замена информационной системы (с последующей организацией миграции данных) может быть продиктована в том числе выполнением предприятием неких внешних предписаний, контрактных обязательств (например, требованием о переводе того или иного вида отчетности в электронный вид). В этом случае критерии валидации должны учитывать действующие нормативные требования (например, они могут запрещать обрабатывать в новой информационной системе файлы определенного формата).
3. При обработке многих типов данных нужно учитывать законодательные ограничения (прежде всего, в части обработки персональных данных, а также сведений, составляющих государственную, корпоративную тайну).
Соответственно, миграция этих данных должна удовлетворять не только техническим критериям, которые предусмотрены приведенным алгоритмом, но также режимам безопасной обработки без нарушений. В этих целях указанные этапы миграции могут быть дополнены необходимыми процедурами (например, проведением инструктажа сотрудников по обработке персональных данных).