Помните основателя стартапа, который рассказывал вам, что построил всю систему управления клиентскими данными с помощью платформы low-code за выходные? Да. Давайте поговорим о том, почему это не даёт мне покоя.
Платформы low-code фантастические — правда. Они демократизировали разработку программного обеспечения таким образом, что десять лет назад это казалось бы невозможным. Нетехнические основатели теперь могут выпускать приложения, не изучая Python, не борясь с конвейерами развёртывания и не произнося фразу «почему не работает мой Docker-контейнер?» в тысячный раз. Это прекрасно. Это расширяет возможности. Но это также потенциальная катастрофа в области безопасности, и об этом никто не говорит достаточно громко.
Проблема не в самой технологии. Проблема заключается в фундаментальном несоответствии между тем, что позволяют платформы low-code, и тем, что требуется для обеспечения безопасности. Это всё равно что дать кому-то Ferrari, но не упомянуть, что у него нет тормозов — да, он может ехать очень быстро, но крушение будет впечатляющим.
Ложное обещание безопасности через простоту
Вот где кроется противоречие: платформы low-code позиционируют себя как доступные. «Не требуется кодирование!» — обещают они. «Выпускайте быстрее своих конкурентов!» — провозглашают они. Чего они не рекламируют явно, так это того, что каждая функция, делающая их доступными для нетехнических пользователей, также создаёт слепое пятно в области безопасности.
Когда вы убираете сложность из процесса разработки, вы не убираете риск — вы просто скрываете его. Вы берёте тысячи крошечных решений по безопасности, которые принимают профессиональные разработчики (осознанно или неосознанно), и автоматизируете их. Иногда эта автоматизация работает прекрасно. Иногда она создаёт настолько серьёзные уязвимости, что всё ваше приложение становится стеклянным домом в районе, где у каждого есть камни.
Трагедия в том, что основатели, использующие эти платформы, часто умные и способные люди. Они построили успешные бизнесы. Они глубоко понимают свою сферу. Но безопасность программного обеспечения? Это специализированная дисциплина со своими минами, и платформы low-code не учат вас, где они находятся — они просто позволяют вам ходить с завязанными глазами и называют это «расширением возможностей».
Пять способов, которыми ваше приложение на базе low-code незаметно уязвимо
1. Теневое ИТ: невидимое восстание
Доступность платформ low-code создаёт то, что специалисты по безопасности называют «теневыми ИТ» — приложениями, созданными без надзора ИТ-отдела. Это звучит почти очаровательно, пока вы не поймёте, что это значит: в вашей компании теперь есть неизвестные приложения, обрабатывающие неизвестные данные с неизвестными настройками безопасности.
Вот сценарий: вы нетехнический основатель, вы находите проблему в своём рабочем процессе, и — оп — вы создаёте приложение на базе low-code для её решения. Ваши данные проходят через него. Затем через него проходят данные клиентов. Затем финансовые записи. И никто в вашей организации не знает об этом, кроме вас и человека, сидящего рядом с вами.
Это не некомпетентность. Это дизайн самой платформы. Платформы low-code делают создание приложений настолько лёгким, что трения, необходимого для создания безопасных, документированных, проверенных приложений, больше просто не существует.
2. Безопасность данных: бесконечная ответственность в облаке
Платформы low-code обычно полагаются на инфраструктуру, размещённую в облаке. Вы передаёте свои данные на внешние серверы, часто на несколько, через интеграции и сторонние сервисы. Каждая передача — это ещё одно место, где что-то может пойти не так.
Рассмотрим реалистичный пример: вы создаёте приложение для управления взаимоотношениями с клиентами, используя платформу low-code. Платформа хранит ваши данные на своих серверах. Они также могут отправлять аналитику об использовании вашего приложения на свою собственную аналитическую платформу. Теперь ваши данные о клиентах существуют в двух местах, ни одним из которых вы не управляете. И правила, такие как GDPR, становятся сложными очень быстро. Одна неправильная настройка, одна небезопасная интеграция, и внезапно вы становитесь ответственным за миллионы штрафов.
3. Проблема гражданина-разработчика: уверенность без компетентности
Нетech основатели часто блестящи в том, что они делают, но они не инженеры по безопасности. Они не думают об уязвимостях OWASP Top 10, потому что никогда о них не слышали. Они не знают, что настройки контроля доступа по умолчанию часто «недостаточно безопасны или недостаточно детализированы». Они создают приложения так, как понимают проблемы: логически, прямо и без параноидальной оборонительной позиции, которую профессиональные разработчики усвоили на собственном опыте.
Это не недостаток характера — это пробел в знаниях. Но в сфере безопасности пробелы в знаниях обходятся дорого.
Настоящая проблема в том, что платформы low-code дают вам достаточно власти, чтобы создать что-то, что выглядит работающим, но при этом фундаментально небезопасно. Это как иметь домашнюю систему безопасности, которая кажется включённой, но на самом деле ничего не защищает. Вы не узнаете об этом, пока кто-то не войдёт через вашу парадную дверь.
4. Театрализованный авторизация: поддельная безопасность как услуга
Платформы low-code часто поставляются со встроенными функциями контроля доступа, но вот неудобная правда: они часто неадекватны. Кто-то, кому нужно просмотреть отчёты о клиентах, получает разрешения, которые также позволяют им изменять данные о клиентах. Внешний подрядчик получает доступ к чувствительным системам, с которыми он не должен иметь дело. Аккаунт бывшего сотрудника остаётся активным, потому что никто не помнит, что у него есть учётные данные.
Проблема усугубляется, если учесть все компоненты, с которыми подключается ваше приложение — API, базы данных, платёжные системы. Если безопасность не обеспечивается последовательно на всех этих уровнях, злоумышленники найдут самое слабое место и прорвутся через него. Это как иметь замок с массивными стенами, но с дверью из бумаги.
5. Унаследованные уязвимости: готовые компоненты как троянские кони
Платформы low-code ускоряют разработку, предоставляя готовые компоненты и интеграции. Вы перетаскиваете платёжный компонент на своё поле — бум, обработка платежей. Вы добавляете блок аутентификации пользователя — бум, система входа в систему. А что, если этот компонент имеет уязвимость в области безопасности, которая ещё не была устранена? Что, если система аутентификации имеет уязвимость нулевого дня? Вы унаследовали проблему без экспертизы для её диагностики.
Когда архитектура становится опасной
Позвольте мне рассказать вам, как это проявляется в реальных приложениях. Вот упрощённая диаграмма того, как данные проходят через типичное приложение на базе low-code:
Каждая линия на этой диаграмме — потенциальная точка отказа. И вот где становится действительно неудобно для нетехнических основателей: большинство этих линий настроены по умолчанию платформой, что означает, что они настроены так, как инженеры платформы считали «достаточно хорошими», а не так, как требует ваш конкретный контекст безопасности.
Конкретные риски, изложенные подробно
Уязвимость неправильной настройки
Платформы low-code часто имеют небезопасные настройки по умолчанию. Обычный пример: таблица данных, доступная любому аутентифицированному пользователю, потому что никто не вспомнил ограничить её. Звучит незначительным? Это не так. Раскрытие конфиденциальных бизнес-данных, нарушения требований соответствия, потенциальные судебные иски.
Катастрофы интеграции данных
Когда вы интегрируете своё приложение на базе low-code с другими системами, вы создаёте пути передачи данных. Эти пути часто включают:
- Слабую аутентификацию: базовые учётные данные, которые могут быть перехвачены или взломаны методом подбора.
- Незащищённые передачи данных: информация, путешествующая по интернету в виде простого текста.
- Отсутствие контроля разрешений API: сервисы, имеющие доступ к большему количеству ресурсов, чем им нужно.
Каждый из этих пунктов — известный вектор атаки. Каждый из них использовался для компрометации реальных организаций.
Необновлённые сторонние компоненты
Платформы low-code часто полагаются на сторонние библиотеки и интеграции. Если эти зависимости имеют уязвимости в области безопасности — а статистически они будут — вы уязвимы, пока они не будут исправлены и вы не обновите их. Кроме того, многие основатели даже не знают, что эти зависимости существуют, не говоря уже о том, как их обновить.
Обход контроля доступа
Исследования показали, что «low-code компоненты не обеспечивают проверки контроля доступа или не обрабатывают зашифрованные данные по умолчанию» — это тревожно распространённое явление. Это означает, что ваше приложение может хранить конфиденциальную информацию таким образом, что она доступна людям, которые не должны её видеть. Или, что ещё хуже, оно может выполнять код, написанный для улучшения рабочих процессов «непреднамеренными сторонами, такими как внешние или неаутентифицированные пользователи».