Развенчиваем актуальные заблуждения про хранилища данных

Вокруг хранилищ данных всегда роится множество ложных мнений. Плохо, когда они мешают работать.

В последнее время столкнулась с парой «свеженьких» заблуждений относительно хранилищ данных:

• ХД – экономически значимый объект КИИ.
• ХД – бизнес-критичный софт.

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

1. ХД – экономически значимый объект КИИ

Почему это не так?

Согласно «Правилам категорирования объектов КИИ», утвержденных ПП РФ №127, к экономически значимым относятся системы, на которые распространяется угроза прекращения и нарушения проведения платежных операций. И это точно не ХД.
И все же, отдельные банки ошибочно присвоили хранилищам данных категории экономической значимости.

К чему это привело:

• согласно «Методическим рекомендациям по цифровой трансформации для государственных корпораций и компаний с государственным участием» от 12 января 2024 года банкам с госучастием с 01 января 2025 года приобретать и эксплуатировать такой софт, не отвечающий критериям отечественного ПО, запрещено;
• остальные кредитные организации в соответствии с «Методическими рекомендациями по переходу на использование российского программного обеспечения» от 31 января 2023 года обязаны разработать и исполнять планы по импортозамещению такого ПО, если сам софт или компоненты в его составе запрещены к распространению на территории РФ.

Как исправить ситуацию?

Изменить категорию объекта КИИ. Формальные поводы для пересмотра перечислены в ПП РФ №127. Но наиболее вероятно, для перекатегорирования придется подождать 5 лет с момента установки ошибочной категории.

2. ХД – бизнес-критичный софт

Почему это не так?

К бизнес-критичному относят ПО, жизненно необходимое для обеспечения непрерывности бизнеса. В банках это софт, без которого невозможно обслуживать клиентов и выполнять платежи. Основной критерий идентификации бизнес-критичности – убытки, которые несет бизнес от простоя ПО. Этому критерию ХД не соответствуют.

Но не все банки готовы с согласиться с такой оценкой.

К чему это приводит?

К необоснованному завышению требований к уровню сервисного обслуживания ХД и стоимости технической поддержки.

Как исправить ситуацию?

Проанализировать влияние простоя ХД на убытки и объективно/количественно оценить его критичность для бизнеса. По итогам переоценки критичности пересмотреть внутренние требования к уровню доступности технической поддержки, ко времени реагирования на инциденты, к срокам устранения их последствий и проч. метрикам SLA, и получить оптимизированное предложение на услуги технической поддержки от вендора.

Внимание! Если вы только что поняли, что поддались на одно из рассмотренных заблуждений, еще не поздно все исправить.