Новые оттенки тени
Когда заходит речь о «теневом ИТ», обычно под этим термином собеседники подразумевают ИТ-сервисы, которые не контролируются информационной службой. Не секрет, что для повышения собственной эффективности подразделения иногда обращаются к платным или бесплатным облачным сервисам, куда передаются критические данные: например, продавцы пользуются облачным CRM- или SFA-сервисом, разработчики для тестирования арендуют облачные серверы, бухгалтерия подписана на обновления сервиса разъяснения законодательства и т. п. А поскольку большинство компаний разрешает использовать как минимум корпоративную электронную почту, а то и другие внутрикорпоративные сервисы с личных смартфонов, то к таким неконтролируемым ресурсам добавляются и облачные хранилища данных, которые обычно ассоциированы с мобильными клиентами электронной почты – iCloud, Google Disk и другими. И если применение платных сервисов можно хотя бы контролировать опосредовано, через выделение бюджета на их оплату, то проверять бесплатные сервисы абсолютно проблематично. Как гласит известное изречение, «если ты не платишь за сервис, то товар – это ты сам», а значит, хранящиеся на бесплатных сервисах данные используются их владельцами по собственному усмотрению.
Конечно, такая ситуация не может не вызывать беспокойства у служб ИТ, и особенно у служб информационной безопасности. Сложно конкурировать громоздким политикам безопасности с бесплатным удобством, к тому же увеличивающим эффективность бизнес-единицы. Худо-бедно, но компании начинают систематизировать передачу корпоративных данных из внутренней сети во внешние источники, используя как прямые запреты на обращения к непроверенным сервисам, так и более мягкие политики с применением специализированного программного обеспечения, для которого не так давно был придуман термин CASB (Cloud Access Security Broker). Такое решение позволяет реализовывать политики доступа к разным внешним ресурсам в зависимости от прав пользователя во внутренний сети и категории передаваемых данных, ограничивая передачу полностью или частично до выполнения требований политик, или же, например, шифруя данные перед передачей.
Но настоящая статья не про этот оттенок теневого ИТ, с ним сегодня более или менее понятно, что делать – и технически, и методологически.
Незаметное программирование
Теперь проблемой становится не только и не столько инфраструктура и приложения, арендованные вовне без санкции ИТ-службы, а приложения, созданные внутри компании не профессиональными программистами, а сотрудниками других служб. Сегодня знание языков программирования в своем резюме указывают не только разработчики или ИТ-специалисты, но и специалисты других отраслей. Например, финансист, не владеющий макросами в «Экселе», не найдет нормальной работы. Кандидат на должность в службе информационной безопасности с умением быстро написать скрипт, находящий в потоке логов нужные ему корреляции, будет иметь преимущество перед кандидатом, не владеющим подобным навыком. Сегодня большие данные в компаниях часто накапливаются в едином источнике (есть даже специальный термин data lake – «озеро данных»), а каждая служба, которой нужны какие-то данные, – извлекает из него их своими инструментами.
Что это за инструменты? Иногда – предоставленные и обслуживаемые ИТ-службами. Иногда – написанные самостоятельно сотрудниками, которым проще прокачать свое знание Python, чем часами объяснять и документировать задачу разработчикам и потом ждать от них скрипта. Иногда – созданные на основе открытых лицензий программного обеспечения или просто опубликованных примеров программного кода.
В компаниях незаметно от ИТ-службы появляются десятки приложений, про которые службы ИТ и ИБ ничего не знают. Эксель-макросы финансистов, макросы рассылок для почтовых сервисов у маркетологов, блоки регулярных выражений у специалистов по внутренним расследованиям и специалистов по противодействию мошенничеству, скрипты для обработки инцидентов и запросов в безопасности и техподдержке. Они незаметны потому, что для систем мониторинга выглядят как запуск материнского приложения – электронных таблиц, почтового сервера, CRM-системы, монитора соцсетей, антифрода, сканера уязвимостей, систем автоматизации help-desk и т.п. – большинство таких программных расширений работают поверх «материнского» приложения, исполняя код внутри него.
Хорошо и бесплатно до поры
Такие самописные системы работают хорошо и незаметно только в присутствии их авторов – специалистов в своей области, то есть глубоко понимающих тонкости функционала и одновременно посредственных (по сравнению с профессиональными разработчиками) программистов. Они учат программирование как сопутствующий инструмент, для них это такой же навык, упрощающий профессиональную жизнь, как умение быстро вслепую набирать текст на клавиатуре или понимать текст на английском языке. Они не собираются зарабатывать на жизнь программированием, поэтому, изучая язык, игнорируют такие дисциплины, как архитектура, безопасная разработка, переносимость приложений, документирование и другие, понятные разработчикам, стороны профессии. Их программы не предназначены для использования другими людьми, поэтому в них нет «защиты от дурака», контроля вводимых параметров и других правил проектирования интерфейсов – автор сам же и является пользователем, ему не надо объяснять, что и куда нужно вводить. По той же причине в них нет сообщений об ошибках – техническая поддержка не предусмотрена. Нет и разделения на администратора и пользователя, а также на режим отладки и продуктивный режим – разработчик, он же администратор, он же пользователь, имеет одну и ту же учетную запись. Отсутствует и версионность – автор постепенно улучшает программу, просто изменяя живой код, не ведя журнал изменений. То есть внутри современной компании постоянно создаются программы, но не программные продукты в привычном нам понимании – у них есть функционал, но нет остальных атрибутов продукта – документации, поддержки, разделения ролей пользователей, версионности, обработки ошибок и т. п.
Нет ничего плохого в том, что сотрудник в свое рабочее, а то и в свободное время, оптимизирует собственную работу с помощью встроенной в продукты возможности автоматизации. Плохое начинается в тот момент, когда сотрудник покидает компанию – вместе с ним исчезает полное понимание, как эта штука работает. Скорее всего, увольняемый сотрудник даже не будет претендовать на авторство, особенно если трудовой договор составлен грамотно – все, созданное в рабочее время на предоставленных для работы ресурсах, по закону принадлежит работодателю. Коммерческого использования программы при ее создании автором не предполагалось, это просто выраженный в коде навык сотрудника, а потому продавать его он сможет только вместе со своим трудом – на новом рабочем месте в другой компании он снова начнет оптимизировать свой труд с помощью навыков программирования. Но вот заставить увольняющегося сотрудника по закону документировать продукт, изменить архитектуру для разделения ролей, переписать интерфейсы и т. п., вы не сможете – программирование не входило в его трудовые обязанности, компания не составляла ему заданий на разработку и потому требовать каких-то дополнительных действий с кодом не может.
Шаг назад в эффективности процесса
Сотрудник, пришедший на замену, ничего не знает про эту, никак не описанную «надстройку» и не может ей пользоваться. А потому эффективность новичка, профессионально ничем не уступающего предшественнику, на конкретном процессе оказывается значительно ниже – ему приходится вручную делать то, что при предыдущем исполнителе делалось нажатием одной кнопки. Попытки использования недокументированного программного обеспечения без контроля вводимых данных и разделения прав доступа может привести к непредсказуемому результату: от потери времени ввиду многочисленных ошибок и обращений в поддержку до потери данных, а в финансовых системах – и денег. Разбираться в чужом коде профессиональному программисту неэффективно – слишком много в таких программах непрограммистской логики. Профессионалу в конкретном функционале, но программисту-любителю, читать чужой код просто невыносимо. Поэтому процесс начинается с самого начала: новый сотрудник начинает обрабатывать данные вручную или с помощью стандартных процедур автоматизации, а затем, по мере обретения опыта в конкретном процессе, начинает добавлять в стандартные процедуры проприетарный код. При его увольнении все повторяется сначала.
Что с этом делать?
Для начала – отказаться от «страусиной позиции», признать наличие проблемы. Потому такие самописные приложения и относятся к «теневым ИТ», что их наличие незаметно и даже неочевидно. Можно, конечно, закрыть на это глаза и продолжать делать вид, будто проблемы нет и мириться со сбоями при попытках новых сотрудников освоить результаты программотворчества предшественников, не говоря уже про потери времени на вновь и вновь разрабатываемые программы с одним и тем же функционалом. Но если такую проблему признать, то следом надо уже действовать.
Самый простой первый шаг – проаудировать в компании работу всех видов аналитиков и других сотрудников, чья деятельность может быть автоматизирована с помощью встроенных в базовое программное обеспечение скриптов и макросов, выяснить, как и с помощью чего они автоматизируют свою деятельность. Сотрудники обычно не скрывают свои навыки программирования и даже гордятся результатами своего труда.
Дальше необходимо вместе с владельцами процессов решить, какие способы обнаруженной «стихийной» автоматизации существенны для компании. Если какие-то программы и скрипты представляют ценность, нужно находить способы для вывода такого ресурса из «тени». Это можно сделать следующим образом.
Временно придать к профессионалу в процессе профессионального разработчика и технического писателя. Сохранив функциональное ядро, ввести в программу разделение ролей администратор/пользователь, контроль вводимых данных, перерисовать интерфейсы по стандартам, разделить ветви отладки и релиза, ввести сообщения об ошибках, а также сделать подробное документирование как кода, так и пользовательской и администраторской документации – то есть сделать из программы программный продукт. Конечно, надо найти способы мотивировать сотрудника не-программиста включиться в такую непроизводительную для его должности деятельность.
И лучше бы сделать это до того, как сотрудник напишет заявление об увольнении.
Опубликовано 30.11.2018
