Риски программной роботизации

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

В каких областях RPA уже доказали свою эффективность?

Наиболее успешно роботизируются процессы, которые соответствуют определенным критериям: ручные, повторяющиеся, связанные со стандартным считыванием или вводом данных, выполняющиеся в разных информационных системах, зрелые и стабильные. Такие операции есть во многих функциональных областях. В финансовой сфере это формирование актов сверок, обработка банковских выписок, составление стандартных писем, сопровождающих отправку счетов‑фактур экспресс­почтой, формирование статистических отчетов. В кадровой службе — подготовка справок 2­НДФЛ и подобных документов. В области документооборота тоже довольно много задач, подлежащих роботизации: отчеты на основе выгрузок из «1С», СЭД, почтовая рассылка этих отчетов по расписанию, обработка вложений электронной почты, протоколов, распоряжений, внесение всех этих сведений в информационные системы.

Есть задачи для роботов и в цепочках поставок: согласование спецификаций, контроль сроков поставки, создание заявок на платежи, акты инвентаризации, сверки этих актов с балансовой отчетностью. Можно применять RPA в продажах: обрабатывать клиентские запросы, работать с рекламациями, вводить данные в CRM, проверять их и актуализировать по внешним источникам.

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

У многих холдингов появились центры компетенции, занимающиеся исследованием применимости новых технологий. Часть наших клиентов создает центры компетенции именно по RPA, потому что они дают быстрый и ощутимый эффект. Обычно крупная организация делает несколько пилотов по программной роботизации. Если они оказываются успешными, принимается решение о широком применении технологии. Однако довольно часто даже успешные RPA­проекты сталкиваются со стоп­факторами, которые мешают масштабированию. Многие из них относятся к информационной и экономической
безопасности.

Каковы эти стоп­факторы?

Во‑первых, вопрос распределения ответственности. Скажем, если по результатам работы робота выполняется платеж, а затем выясняется, что это было ошибкой и не следовало переводить деньги, возникает вопрос: кто виноват?

Есть несколько вариантов решения. Можно возложить ответственность на сотрудника, чья деятельность была роботизирована. Без RPA так бы и сделали, человек бы получил взыскание. Но сотрудник за роботизированную систему не может отвечать. Можно возложить ответственность на тех, кто занимался автоматизацией, но тогда на них со временем ляжет ответственность за все процессы в компании, что тоже некорректно.

Ответом может быть изменение бизнес­процессов и документирование этих изменений. Можно провести GAP­анализ, задокументировать найденные проблемные места и ввести точки контроля работы RPA. Специально назначенные люди должны периодически проверять результаты, в том числе и проводить выборочные проверки.

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

Зачастую появляется проблема доступности системы роботизации. Если имеется автоматизированная система, всегда есть риск, что кто­то ее выведет из строя намеренно или случайно. А потому очень важно принять меры, связанные с кластеризацией, с резервным копированием, — это критично для обеспечения доступности. Большинство систем роботизации сделано так, что на выходе робот представляет собой текстовый файл. Его можно вручную отредактировать, подменить. Здесь важна целостность — второй ключевой аспект ИБ. Нужно в любой момент быть уверенным, что действуют именно те роботы, которых мы написали, что их никто не подменил.

Кто может их подменить?

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

Все то же самое могут делать те, кто непосредственно занят созданием роботов, — подрядчики или собственные разработчики. Нужно в любой момент быть уверенными в том, что сделанное ими идет на пользу, а не во вред организации. Рядовые сотрудники, чья работа автоматизируется, тоже могут использовать роботов в своих целях, наняв, например, консультантов через Даркнет.

Надо систематически проводить аудит системы роботизации бизнес­процессов, разработать модель угроз, модель нарушителя, предусмотреть систему защиты информации, подготовить для нее комплект эксплуатационной и организационно­распорядительной документации. Использовать эти средства защиты будет служба безопасности, и она же станет контролировать эксплуатацию RPA. В целом необходимо отдавать себе отчет в том, что программная роботизация довольно рискованная вещь. Требуется и контроль кода. Служба безопасности должна с самого начала контролировать код, который получится на выходе, но тут возникает дилемма. Одно из преимуществ систем роботизации — их создание по методологии аджайл. Полноценное решение, копирующее работу сотрудника, может появиться в течение нескольких дней. С точки зрения безопасности каждый раз перед тем, как начинать эксплуатацию, робота необходимо проверить. Проверка может тормозить подключение роботов к работе и отчасти нивелировать ценность, которую автоматизация по такой технологии дает.

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

Как отражается появление программных роботов на регламентах работы службы ИБ?

Это также серьезный вопрос. Чаще всего система документов по ИБ на предприятии программных роботов не рассматривает вовсе, а они ведь могут обрабатывать и персональные данные, и конфиденциальную информацию. В компаниях обычно есть документы, которые описывают процессы обработки информации ограниченного доступа. Следует пересматривать такие документы, политики и концепции безопасности вплоть до рабочих инструкций и прописывать, как нужно обращаться с программными роботами.

При этом возникает сложность в распределении прав и полномочий. В большинстве компаний права и полномочия назначаются только конкретным физлицам. Есть определенные регламентированные процессы предоставления доступа. Внедряются IDM­системы для автоматизации процессов выдачи. Чтобы такие права у человека появились, он должен быть оформлен в кадровую базу, тогда на него начинают запрашиваться роли, учетные записи и права доступа. Если речь идет о роботах, возникает вопрос, как сделать все это, используя ту же систему IDM. Оформить их как сотрудников? Либо изменять IDM­систему так, чтобы в ней появилась новая сущность — роботы? Пересмотреть документы по назначению прав и полномочий?

Подобных вопросов возникает много, и, оставаясь нерешенными, они мешают получению выгод от программной роботизации. Типовая ситуация: к нам приходят представители крупного холдинга, где консультанты сделали проект по RPA. Проект вполне успешный, и хотелось бы его развивать, но вопросы безопасности не решены: есть лишь одна строка в документации о том, что все должно быть безопасно, но больше ничего конкретного не сказано и не сделано. «У нашей службы безопасности возникло очень много вопросов к этим решениям. Найдите на них ответы», — просят нас.

Есть ли у вас ответы? Ведь RPA — относительно новое направление, практики только складываются.

На большинство вопросов ответы у нас уже есть: часть приходит из нашей многолетней практики консалтинга по информационной безопасности, часть уже накоплена в рамках пилотных проектов по защите решений класса RPA. В них мы работаем совместно с системными интеграторами и производителями решений.

Нередко требуется проанализировать бизнес­процессы, подготовить документы, описывающие процесс уже в роботизированном виде с учетом требований безопасности. Готовим методические рекомендации по роботизации бизнес­процессов с учетом регламентов ИБ, помогаем выявить потенциально опасные фрагменты процессов. Как роботизировать процесс так, чтобы не внести потенциал для мошенничества? Для этого необходимо обобщение подходов, практик и принципов безопасной роботизации.

Например, контроль кода. Существует немало отличных продуктов, которые решают именно эту задачу, но они действуют обычно в среде разработки. Для RPA­сред таких продуктов еще нет. Однако существует опыт и кейсы, связанные именно с уязвимостями в коде. Более десяти лет мы развиваем собственный продукт — SafeERP Code Security. Этот программный комплекс автоматизирует процесс управления безопасностью в приложениях SAP­систем, создавая полную картину защищенности систем по всему ландшафту. Он позволяет быстро проверить безопасность разработок и поставить на контроль критичные объекты.

Поэтому нам известны сотни кейсов и множество ошибок, которые в принципе могут влиять на безопасность бизнес­приложений. Например, перед выполнением операции не проверяются права доступа: казалось бы, элементарная вещь, но как редко мы ее обнаруживаем там, где она должна быть… Мы можем проверить код, подсказать, как исправить в нем недочеты, влияющие на безопасность, поставить на контроль целостности, и заказчик будет уверен, что у него в системе действует именно тот программный робот, который был написан разработчиками.

Наша классическая услуга — доработка пакета документов по ИБ на предприятии, чтобы внести в него сущность «робот», описать все нюансы их появления в корпоративных системах. Мы проектируем системы защиты информации для систем роботизации с учетом их специфики, с их требованиями к повышенной доступности и целостности. Есть и собственные продукты, позволяющие закрывать уязвимости RPA­решений. У нас более ста пятидесяти человек заняты в R&D и семь линеек собственных продуктов.

Каким образом вы обосновываете экономическую эффективность проектов по информационной безопасности вообще и c применением программной роботизации в частности?

Для проектов по ИБ мы готовим технико­экономическое обоснование, обычно включающее два аспекта. Первый — обоснование необходимости автоматизации выполнения определенных операций, которые повышают защищенность предприятия: аудиты, обновления, поиск вирусов. Можно посчитать затраты времени персонала на эти операции и экономию времени при использовании средств защиты информации. Причем можно опираться на внутренние регламенты компании, но если их нет — то на требования регуляторов, у которых есть весьма подробно описанные про­цедуры, которые должны выполняться в рамках мероприятий по защите информации. Существуют международные стандарты, в том числе ISO 27000. Там тоже достаточно детально описано, какие процессы должны периодически
выполняться.

Второй аспект — снижение рисков. Мы проводим инвентаризацию, показываем, какие ИТ­системы поддерживают конкретные бизнес­процессы. Приходится выяснять степень критичности этих бизнес­процессов и поддерживающих их ИТ­активов, оценивать риски в случае нарушения конфиденциальности данных, целостности, доступности. Исходя из этой модели рисков, можно продемонстрировать объем сэкономленных средств за счет того, что мы эти риски снижаем.

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

RPA­системы здесь не исключение, поэтому обязательно необходимо на самых ранних стадиях их создания озадачиться вопросами обеспечения информационной безопасности.

Смотреть все статьи по теме "Информационная безопасность"