Безопасность no-code и low-code приложений: о чем молчат разработчики
Привет! На связи снова команда Nocodecircle. Честно говорим о разработке без кода. И сегодня разберем вопросы безопасности, о которых создатели конструкторов говорят редко. Есть, что скрывать? Посмотрим ;)
Nocode и lowcode платформы становятся все популярнее. Ожидается, что в 2024 году на них перейдет более 65% всей разработки приложений. Аналитики прогнозируют, что средний размер рынка ноукод/лоукод вырастет примерно до 84,8 млрд долл. к 2027 году.
Платформы nocode и lowcode имеют ряд преимуществ, главными из которых считают экономию ресурсов, скорость разработки и возможность обходиться без профессиональных программистов. Но есть у конструкторов и явные недостатки. Один из важных минусов инструментов nocode/lowcode - проблемы с безопасностью, которые мы разберем здесь. Также мы дадим рекомендации по минимизации рисков.
Кто и для чего применяет nocode/lowcode инструменты?
Сегодня на рынке - не одна сотня платформ no-code/low-code. Есть среди них и лидеры с десятками и сотнями тысяч пользователей. К их числу можно отнести конструкторы веб (Mendix, Tilda, Bubble) и мобильных приложений (Adalo, Appy Pie, Flutterflow), инструменты для автоматизации рабочих процессов (Automate.io, Zapier, Integromat) и управления корпоративными задачами (Appian, OutSystems, Zoho Creator), а также для создания баз данных (Airtable, Coda).
Что делают при помощи конструкторов:
- Предприниматели и стартапы: быстро создают минимально жизнеспособные продукты (MVP) и тестируют бизнес-идеи;
- Малый и средний бизнес: внутренние инструменты и автоматизацию бизнес-процессов, не нанимая профессиональных разработчиков;
- Бизнес-аналитики и маркетологи: приложения, помогающие анализировать данные и управлять маркетинговыми кампаниями;
- Образовательные учреждения: учебные платформы и приложения;
- ИТ-отделы: прототипы продуктов, ускоряют разработку, экономят ресурсы.
Основные риски безопасности no-code и low-code приложений
Использование no-code и low-code платформ позволяет пользователям без технических навыков разрабатывать функциональные приложения, что способствует ускорению инноваций и цифровой трансформации. Но вопросы безопасности остаются открытыми. И если не разобраться с ними сейчас, в будущем они могут спровоцировать волну атак на бизнес. Какие уязвимости вызывают наибольшие опасения?
Проблемы управления доступом и правами пользователей
В приложениях, которые создаются на базе no-code/low-code платформ, может не быть эффективных механизмов управления доступом. Как следствие, пользователи продукта получат права доступа администратора (разработчика) при обращении к различным системам и базам данных. Обладая такими привилегиями, они могут вносить изменения в БД, копировать их и передавать третьим лицам. Все это открывает возможности для реализации атак. Так, недобросовестный сотрудник может получить доступ к базе данных клиентов и передать ее конкурентам за вознаграждение.
Как нивелировать риски?
- создавать отдельные учетные записи для разработчиков продуктов на базе nocode/lowcode
- ограничивать в доступе пользователей таких инструментов и обязательно запрашивать авторизацию при соединении с корпоративными базами данных и системами
Утечки или модификация данных
Сотрудники, пользующиеся внутренним инструментом, созданном на конструкторе, могут получать больше данных, чем планировал разработчик. Если решение собирает специалист без навыков в программировании, такое возможно. А неверные настройки могут приводить к ошибкам в обработке информации, а также к случайным и намеренным утечкам или повреждению данных.
Как нивелировать риски?
- разграничивать доступ к данным
- минимизировать разрешения на запись и удаление
- осуществлять мониторинг передачи данных приложением
Уязвимости, связанные с работой коннекторов
В теории, некорректно написанный коннектор может спровоцировать несанкционированный доступ к данным и их утечку. Однако на практике такие случаи встречаются редко. Почему? Среды, которые соединяет коннектор, изолированы. И даже если уязвимость есть и ей воспользуются, возможно лишь передавать данные из одной внутренней системы в другую. Конечно, может идти речь о превышении прав доступа, но об этом уже говорилось выше.
Кроме того, правильное функционирование коннектора гарантирует либо поставщик платформы, либо крупная организация, которая создает цифровой продукт и прописывает API для него. В обоих случаях разработчики придерживаются лучших практик информационной безопасности.
Как нивелировать риски?
- пользоваться решениями nocode/lowcode от проверенных поставщиков
- при самостоятельном написании коннекторов следовать правилам безопасной разработки
Невозможность контроля безопасности лоукод-платформы со стороны заказчика
Если заказчик создает самостоятельный цифровой продукт на базе drug-and-drope конструктора, не дописывая ничего самостоятельно, то его безопасность обеспечивается поставщиком. Поэтому стоит выбирать проверенные инструменты, зарекомендовавшие себя на рынке.
Если речь идет о внутреннем решении для крупной организации, будут действовать правила и стандарты обеспечения ИБ, которых придерживается заказчик. Проблем быть не должно.
Как нивелировать риски?
- применять инструменты nocode/lowcode от проверенных поставщиков
- следовать правилам безопасной разработки и стандартам, принятым в организации
Рекомендации для обеспечения безопасности no-code и low-code приложений
В целом, безопасность nocode/lowcode приложений находится сегодня на зрелом уровне. Кроме того, крупные корпоративные системы заказчиков позволяют вести непрерывный мониторинг событий и состояния цифровых продуктов и реагировать в случае возникновения угрозы.
Поэтому стоит проявлять беспокойство только в тех случаях, когда заказчик самостоятельно улучшает функционал готового решения, привлекая неквалифицированных специалистов.
Как свести к минимуму риски ИБ при использовании продуктов на базе конструкторов:
- Проводить регулярные обновления ПО, используемого в компании
- Внедрить и применять многофакторную аутентификацию (MFA)
- Использовать криптографические протоколы SSL/TLS для защиты данных при передаче
- Регулярно проводить аудиты безопасности и тестирование на проникновение ключевых систем и кода
- Осуществлять управление правами доступа и ролями пользователей
Применять лучшие практики и стандарты безопасности, включая ГОСТ («Разработка безопасного программного обеспечения»), SSDLC (Secure Software Development Life Cycle), методику BSIMM 2021 (Building Security In Maturity Model) и т.д.