BIS Journal №2(45)/2022

27 мая, 2022

Импортозамещение на практике — это… Уроки старого админа

Импортозамещение — это срочный переезд всей организации, её клиентов и партнёров из одного мира информационных технологий в другой без остановки, со сменой лошадей прямо на марше. Собственно, как это всегда и было в ИТ (ИБ) российских компаний, когда бизнес начинал быстро, скачкообразно развиваться.

Говорить о конкретных примерах, заменах и преодолеваемых трудностях не даёт действующее законодательство и «понятийные» договоры с организациями, точнее с их владельцами. Но предупредить, где необходимо постелить соломку, оставить запас провизии и чистой воды, стоит, поэтому усаживаемся поудобнее с карандашом в руке.

 

ПЕРВОЕ ПРАВИЛО

Первое и основное правило импортозамещения — всё придётся делать самому: проверять совместимость ПО, придумывать схемы управления и т. д. В 1990–2000-е годы так жили старые админы: к ним приходили вендоры, предлагали новые решения, которые внедрялись с применением известного приёма в виде палок, костылей и нашлёпок. Со временем решения становились лучше, временные «шалашики» убирались, и Z-поколение админов видит уже красивую работающую безотказную инфраструктуру. Практически все современные крупные решения на первых шагах своего развития были «некрасивыми», угловатыми и жутко глючными. Придётся этот путь пройти во второй раз.

 

АЙСБЕРГ ПРОБЛЕМ. РЕШАЕМО

Для понимания объёма работ и проблем для планирования импортозамещения недостаточно иметь перечень ПО, установленного на серверах и рабочих станциях, и описанные бизнес-процессы обработки. Как правило, если это всё и есть, то это только вершина айсберга. Глубина залегания айсберга проблем зависит от монолитности ИТ-ландшафта. Под этим мы понимаем унифицированность аппаратной платформы и управления: даже бюджетные организации и учебные центры не могут похвастаться типовыми рабочими местами (одинаковые материнские платы, периферия, сетевое оборудование) и единым управлением (единый домен безопасности и управления). Например, для учебных заведений характерно наличие так называемого научного оборудования, купленного на деньги от выполнения НИР и НИОКР с лицензиями для коммерческого использования, а ИТ-ландшафт рабочих мест студентов представляется всем многообразием ИТ-платформ.

Для фиксации объёма работ необходимо достаточно длительное наблюдение за эксплуатацией имеющейся ИТ-инфраструктуры во всех «временных рамках» бизнес-процесса: обычная деятельность, квартальные авралы, сессия, закрытие года, отчётности в разные периоды и сроки и т. д. с фиксацией всего запускаемого ПО, в том числе пользовательских скриптов офиса, bat-ников и т. д. Без внешнего воздействия получить полный объём с использованием такого наблюдения в учебном заведении занимает примерно 14–16 месяцев, так как основной цикл — это обучение в течение 10 месяцев и набор обучаемых в течение 3–5 месяцев. Для организаций проектного плана, работающих в режиме годовых контрактов,— по немногочисленным наблюдениям — 14–15 месяцев. Что же делать, если этого времени нет? Как и с планами ОНиВД и требованиями ГО и ЧС и пожарного надзора— надо провести учения: ставим на все АРМ-программы, логирующие используемое ПО и действия пользователей, и проводим учения. Таким образом, мы получаем следующие важные параметры:

  • используемое программное обеспечение с перечнем локальной автоматизации;
  • перечень мест реального хранения информации, которая подлежит защите и резервному копированию;
  • проект программы-методики тестирования работоспособности ИТ-ландшафта после замены компонентов.

 

ТИПИЧНЫЙ ПРИМЕР

В одной из проектных организаций в рамках замещения прикладного ПО был указан закупленный на всех АРМ MS Office. При проверке оказалось, что проектный отдел в рамках выполнения государственного контракта уже два года использует portable (переносимую) версию Libre Office, которая пересобирается одним из разработчиков сопроводительной документации для выполнения требований по представлению документации по ГОСТ 2.106, ГОСТ 7.32 в формате ODF. Скрипты, используемые для оформления документации, реализованы, соответственно, на pyton. Поддержка решения фактически минует ИТ- и ИБ-отделы.

 

ДОЛГИ НАШИ

Второе большое направление анализа — это выявление технического долга собственного ИТ, которое не выполняло заявки подразделений в силу нехватки сил, средств, времени и т. д. Как правило, пользователи такой технический долг автоматизируют локально, через Excel, VBA-скрипты, Bat-ники и т. д. Ликвидация технического долга, как правило, дешевле, чем импортозамещение локальной автоматизации.

 

ОСТОРОЖНО, ОБОРУДОВАНИЕ!

Есть рабочие места, на которых импортозамещение необходимо выполнять с особой осторожностью: это системы управления технологическим оборудованием (рентген-оборудование, различные насосы, клапаны, станки и т. д.). Как правило, всё это оборудование имеет требования по безопасности помимо информационной. Например, замена ПО сервера СКУД (системы контроля и управления доступом) может привести к большому числу пострадавших при нештатной ситуации на объекте, что грозит команде импортозамещения уголовной ответственностью даже после увольнения с работы.

 

ПРОСТОЙ ВОПРОС

Перейдём к самому, пожалуй, простому вопросу — выбору замещающих систем управления баз данных (СУБД). Вопрос этот прост по причине малого числа пар, которые позволяют провести замену.

Правда, отдельно стоит сказать про замену СУБД Oracle с хранимыми процедурами (фактически размещённым сервером приложений). Замены такому решению один в один нет. Но есть два направления движения. Первое— Tibero от южнокорейской корпорации Tmax Soft. На её базе работает АО НСПК. Совместимость — переносимая. Необходимо специальным программным обеспечением от разработчика пройти по коду PL/SQL и определить порядок перехода. В среднем такой переход можно осуществить в течение 6 месяцев, но надо помнить: количество сертифицированных админов СУБД надо увеличить в ИТ-отделе в два раза, а в ИБ-отделе необходим минимум один человек, который понимает особенности работы с Tibero. Второе направление — PostgreSql. Замена возможна только в плане базы данных с фактическим переписыванием кода сервера приложений (хранимых процедур).Что касается замены MS SQL на PostgreSql, то в моей практике такая замена не приводила к большим затратам ресурсов на переход.

 

ЗАМЕНА СЕРВЕРНОГО ПО

Замена серверного программного обеспечения вызывает трудности только для двух классов ПО: удостоверяющий центр и сервер приложений, завязанный на IIS. В остальных случаях это стандартный выбор окружения прикладного серверного ПО и привычек ИТ-отдела с учётом пожеланий ИБ.

 

ОПЫТ ЗАМЕНЫ ОС

Отдельно хочется поделиться опытом замены ОС на рабочих местах. На опыте при массовом импортозамещении выявлено, что построение только на базе одной конкретной ОС невозможно в силу ограничений поддержки драйверами как конфигурации используемых АРМ, так и периферийных устройств, которые используются в работе.

Перечень ОС, которые стоит рассматривать для установки на АРМ, можно взять из документации на СКЗИ, которые используются в организации. Это позволит ограничить круг рассматриваемых ОС. Хотя коллеги из банковской сферы могут и не знать такого количества существующих на рынке ОС.

Если вопросы электронного документооборота уже вошли в область ответственности ИТ и ИБ, то для применения СКЗИ на отечественных ОС имеются серьёзные ограничения:

  • нельзя получить класс СКЗИ выше КС2 без использования HSM;
  • стоимость лицензий на программные СКЗИ под некоторые ОС в разы выше, чем используемые для Windows. Так, эксплуатация «КриптоПро CSP» под FreeBSD всегда считается как серверная (есть целый научный институт, который работает на рабочих местах FreeBSD; дизайн рабочих мест очень похож на Windows XP);
  • необходимо использовать аппаратные хранилища с неизвлекаемыми ключами («Аладдин», «Актив», «Мультисофт», «АТ Бюро», «СмартПарк»);
  • для работы с СКЗИ на порталах госорганов необходимо тестирование как носителей (аппаратных СКЗИ), так и плагинов в браузерах.

 

НЕ СТОИТ ЗАБЫВАТЬ

При импортозамещении прикладного ПО необходимо помнить, что основную ценность для расчётных программных систем составляет не алгоритмы расчёта, а база ошибок операций с плавающей точкой. Из-за этого результаты моделирования в системах MatLab, MultiSim и других при запуске в среде эмуляции Wine могут сильно отличаться от результатов как эксперимента, так и запуска на родных ОС.

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

28.03.2024
Аитов: Ограничения Samsung Pay на использование карт «Мир» можно обойти
28.03.2024
Киберпреступления — 35% всех преступлений в России
28.03.2024
Почему путешествовать «налегке» не всегда хорошо
28.03.2024
«Тинькофф»: Несколько платёжных систем лучше, чем одна
28.03.2024
В РФ готовят базу для «усиленной блокировки» незаконного контента
28.03.2024
Термин «риск ИБ» некорректен по своей сути
27.03.2024
Samsung Pay перестанет дружить с «мировыми» картами
27.03.2024
Канадский университет восстанавливает работу после ИБ-инцидента
27.03.2024
Crypto Summit 2024. Трейдинг, майнинг и перспективы развития рынка ЦФА
27.03.2024
РКН начал работу по контролю за «симками» иностранцев

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных