Остерегайтесь олицетворения пользователя в приложениях с низким кодом / без кода

В прошлом месяце я написал статью о том, как платформы low-code/no-code предлагают совместное использование учетных данных как услугу, почему они это делают и как это выглядит с точка зрения злоумышленника. В этой статье я сосредоточусь на последствиях этого компромисса и на том, как он влияет на предприятия сегодня.

Вот почему делиться корпоративными учетными данными с кем-то другим — плохая практика. Скажем, я хочу передать свои учетные данные коллеге, чтобы запросить производственные журналы для какого-то одноразового анализа поведения пользователя. На типичном предприятии предоставление кому-либо разрешений на запрос нового источника данных может означать длительный процесс проверки доступа, особенно когда речь идет о рабочих или конфиденциальных данных. Мой коллега легко мог расстроиться. «Все, что я хотел, это сделать этот крошечный одноразовый запрос, и я уже жду месяц!» они могли бы сказать. Я мог бы просто выполнить запрос для них, но я завален своими повседневными задачами, а одноразовые запросы, как правило, усложняются.

У меня осталось одно быстрое решение: я могу просто поделиться своим именем пользователя/паролем с моим коллегой. Если они получат вызов MFA, я с радостью одобрю. Мне не нужно тратить время на выполнение запроса, и мой коллега разблокируется. Все выигрывают! Верно?

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

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

Реальный пример

Давайте обратимся к миру low-code/no-code и рассмотрим реальный сценарий. На большом предприятии Джейн, вдохновленный сотрудник группы обслуживания клиентов, поняла, что когда сотрудники всей организации принимают участие в работе с клиентом, им обычно не хватает ключевой информации о клиенте, такой как история их обращений в службу поддержки и последние покупки. Это ухудшает качество обслуживания клиентов, поскольку им приходится снова и снова объяснять свою проблему, пока дело направляется нужному сотруднику, который может решить проблему.

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

При создании приложения Джейн пришлось решить несколько проблем, самой большой из которых были разрешения. Сотрудники организации не имеют прямого доступа к базе данных клиентов для получения необходимой им информации. Если бы они это сделали, Джейн не пришлось бы создавать это приложение. Чтобы решить эту проблему, Джейн вошла в базу данных и внедрила свой аутентифицированный сеанс непосредственно в приложение. Когда приложение получает запрос от одного пользователя, оно использует личность Джейн для выполнения этого запроса, а затем возвращает результаты пользователю. Эта функция внедрения учетных данных, как мы исследовали в прошлом месяце, является ключевой особенностью платформ с низким кодом/без кода. Джейн позаботилась о том, чтобы настроить в приложении управление доступом на основе ролей (RBAC), чтобы каждый пользователь мог получить доступ только к обращениям клиентов, на которые он назначен.

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

Тем временем в SOC было инициировано предупреждение высокой степени серьезности, указывающее на аномальную активность в производственной базе данных клиентов, которое было назначено Эми, опытному аналитику по безопасности. Первоначальное расследование Эми показало, что внутренний пользователь пытался очистить всю базу данных, запрашивая информацию о нескольких клиентах с нескольких IP-адресов в организации. Шаблон запроса был очень сложным; вместо простого шаблона перечисления, который вы ожидаете увидеть при очистке базы данных, данные одного и того же клиента запрашивались несколько раз, иногда через разные IP-адреса и в разные даты. Мог ли это быть злоумышленник, пытающийся сбить с толку системы мониторинга безопасности?

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

Эми связалась с Джейн, чтобы спросить ее, что происходит. Сначала Джейн не знала. Были ли украдены ее учетные данные? Нажала ли она не на ту ссылку или доверилась не тому входящему письму? Но когда Джейн рассказала Эми о приложении, которое она недавно создала, они оба поняли, что между ними может быть связь. Эми, аналитик SOC, не была знакома с low-code/no-code, поэтому они обратились к команде AppSec. С помощью Джейн команда выяснила, что в приложение Джейн были встроены учетные данные Джейн. С точки зрения базы данных не было никакого приложения — была просто Джейн, выполняющая множество запросов.

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

Пока Эми закрыла проблему и задокументировала свои выводы, вице-президент по работе с клиентами был недоволен падением уровня удовлетворенности клиентов, поэтому они попросили Джейн найти постоянное решение. С помощью документации платформы и команды Center of Excellence организации Джейн удалила свою встроенную идентификацию из приложения, изменила приложение, чтобы оно использовало идентификацию каждого пользователя для запросов к базе данных, и гарантировала, что пользователи получают разрешения только на обращения клиентов, с которыми они связаны. . В своей новой и улучшенной версии приложение использовало личность каждого пользователя для запроса базы данных клиентов. Джейн и пользователи приложения были счастливы, что приложение снова в сети, Эми и команда AppSec были счастливы, что личность Джейн больше не разглашается, и предприятие увидело, что уровень удовлетворенности клиентов снова начал расти. Все было хорошо.

Две недели спустя SOC получил еще одно предупреждение об аномальном доступе к производственной базе данных клиентов. Оно было подозрительно похоже на предыдущее оповещение в той же базе данных. Опять же, IP-адреса со всей организации использовали идентификатор одного пользователя для запросов к базе данных. Опять же, этим пользователем была Джейн. Но на этот раз команда безопасности и Джейн знали, что приложение использует идентификаторы пользователей. В чем дело?

Расследование показало, что исходное приложение неявно разделяемый Аутентифицированный сеанс базы данных Джейн с пользователями приложения. Поделившись приложением с пользователем, этот пользователь получил прямой доступ к связи, оболочка для аутентифицированного сеанса базы данных, предоставляемая платформой low-code/no-code. Используя это соединение, пользователи могли напрямую использовать аутентифицированный сеанс — им больше не нужно было проходить через приложение. Оказывается, несколько пользователей узнали об этом и, думая, что это было предполагаемым поведением, использовали аутентифицированный сеанс базы данных Джейн для выполнения своих запросов. Им понравилось это решение, так как прямое подключение дало им полный доступ к базе данных, а не только к обращениям клиентов, которые им назначены.

Соединение было удалено, и инцидент исчерпан. Аналитик SOC обратился к пользователям, которые использовали соединение Джейн, чтобы убедиться, что они удалили все данные о клиентах, которые они сохранили.

Решение проблемы безопасности Low-Code/No-Code

Приведенная выше история — это сценарий из реальной жизни международной компании B2C. Некоторые детали были опущены или изменены для защиты конфиденциальности. Мы видели, как действующий из лучших побуждений сотрудник мог непреднамеренно раскрыть свою личность другим пользователям, что вызвало целый ряд проблем в сфере ИТ, безопасности и бизнеса. Как мы выяснили в прошлом месяце, совместное использование учетных данных является ключевой функцией low-code/no-code. Это норма, а не исключение.

As low-code/no-code продолжает процветать на предприятиях, сознательно или нет, крайне важно, чтобы специалисты по безопасности и ИТ-специалисты присоединились к разговору о развитии бизнеса. Приложения с низким кодом / без кода поставляются с уникальный набор проблем безопасности, и их плодовитый характер означает, что эти проблемы становятся более острыми, чем когда-либо прежде.