Опасность того, что кто-то сможет запускать новые приложения, заключается в том, что мало кто думает о безопасности. Вот почему каждый несет ответственность за безопасность low-code/no-code приложений.
Со всей шумихой вокруг low-code/no-code платформ многие сейчас рекламируют преимущества внедрения low-code разработки. Давайте обратимся к слону в комнате (безопасности): любой может запускать приложения с помощью этих инструментов, но кто отвечает за безопасность этих приложений?
Если, подобно облачным вычислениям, это модель совместной ответственности, то где мы проводим границы ответственности между различными вовлеченными сторонами?
Один размер подходит не всем Low-code приложения разнообразны: они бывают разных форм, различаются по способу развертывания и решают широкий спектр проблем. При обсуждении модели ответственности за безопасность для low-code приложений мы должны сначала понять различные уровни. Вот краткое резюме:
Уровень 1: Инфраструктура, на которой выполняется low-code приложение, которая включает серверы, на которых работает операционная система, сеть, в которой развернуты серверы, базовые операционные системы и используемые уровни виртуализации, контейнеры и оркестрация контейнеров.
Уровень 2: Среда выполнения, используемая для запуска low-code приложения.
Уровень 3: Само приложение, которое включает бизнес-логику приложения; любые виджеты, компоненты и соединители, предоставляемые low-code платформой; пользовательские виджеты/компоненты, созданные организацией владельца приложения; сторонние виджеты, компоненты и соединители, такие как доступные через различные общедоступные рынки; любые вспомогательные службы, используемые low-code приложением, такие как общедоступные облачные службы (например, хранилища, очереди сообщений, устройства интернета вещей) и экземпляры SaaS (например, Salesforce, ServiceNow, Slack).; и используемые инструменты управления идентификацией и доступом.
Уровень 4: Данные, используемые приложением. Данные могут храниться в разных местах — иногда в облаке, а иногда локально.
Мы также можем рассматривать среду разработки low-code платформы, используемую для разработки приложения, как уровень 0. Даже если вы сделаете все необходимое для строгой защиты своего приложения, если злоумышленник получит доступ к вашей консоли разработки — это также плохо.
Безопасность - это общая ответственность
Подход облачных вычислений к модели совместной ответственности прост: по мере того, как вы продвигаетесь в своем облачном путешествии и переходите на более высокие уровни абстракции, ответственность за безопасность переходит от вас к поставщику облачных услуг.
Должны ли мы рассматривать low-code приложения еще один шаг в этой эволюции?
Где лежит ответственность, зависит от выбора, который вы делаете при внедрении low-code разработки. Например, на уровне инфраструктуры вы планируете размещать свое приложение в частном облаке или в общедоступном центре обработки данных? Некоторые low-code платформы разработаны специально для локальных или гибридных облачных/локальных развертываний. Если вы решите разместить свои собственные приложения, у вас будет полный контроль над базовой инфраструктурой, но это также означает, что вы несете ответственность за безопасность каждого аспекта среды.
Выбор уровня приложения
Каковы некоторые варианты разработки на уровне приложений, которые влияют на ответственность за безопасность?
Если low-code приложение строго состоит из собственных возможностей или сервисов low-code платформы, вам нужно беспокоиться только об основах. Это включает в себя недостатки в дизайне приложений и бизнес-логике, защиту ваших данных при передаче и в состоянии покоя, неправильные настройки безопасности, аутентификацию, авторизацию и соблюдение принципа наименьших привилегий, обучение по вопросам безопасности для ваших гражданских разработчиков и поддержание безопасной среды развертывания. Это те же самые элементы, о которых должен подумать любой разработчик — low-code или традиционный - для обеспечения безопасности приложения. Все остальное обрабатывается самой low-code платформой.
Это настолько просто, насколько это возможно.\
Но что, если вы используете дополнительные виджеты, компоненты или интеграции, предоставляемые low-code платформой? Эти компоненты — и код, используемый для их создания, — определенно находятся вне вашей юрисдикции ответственности. Однако вам может потребоваться рассмотреть, как они настроены или используются в вашем приложении. Возможно, неправильно используемый компонент может привести к потенциальной уязвимости в вашем приложении.
Например, большинство low-code платформ предоставляют интеграцию базы данных SQL, который позволяет разработчикам low-code приложений запускать SQL-запросы для доступа к данным, хранящимся в базах данных. В некоторых распространенных интеграций SQL, которые мы рассмотрели, мы увидели несколько методов взаимодействия с базами данных: некоторые обеспечивали строгую безопасность и предоставляли разработчикам меньшую гибкость, в то время как другие были более гибкими. При неправильном использовании эти интеграции с гибкими методами могут привести к катастрофической уязвимости внедрения SQL-кода (SQLi). Например, успешная атака SQLi на low-code приложение может привести к несанкционированному доступу к данным. Злоумышленник может манипулировать данными или даже выполнять команды оболочки на сервере базы данных.
Третий вариант - расширить библиотеку компонентов пользовательскими компонентами, поскольку выбранная low-code/no-code платформа не обеспечивает всю необходимую (или желаемую) функциональность. Например, вы можете создать пользовательские виджеты Mendix для создания динамических меню в своем приложении, пользовательские подключаемые компоненты Appian для визуализации объекта Google Maps или приложения Canvas в приложениях Microsoft Power для интеграции данных из других приложений Microsoft.
В то время как пользовательские компоненты обеспечивают расширяемость и свободу создания функциональности по вашему усмотрению, они также вносят больше кода и логики в ваше приложение. Как и в случае с традиционно разработанным программным обеспечением, большее количество кода и логики означает большую вероятность появления дефектов, недостатков дизайна и уязвимостей в системе безопасности. При разработке пользовательских компонентов, даже в мире low-code/no-code, убедитесь, что у вас есть надлежащие SDLC и процессы безопасности. Разработчики должны следовать политике безопасности вашей организации и руководящим принципам разработки и развертывания приложений.
Наконец, вам, возможно, придется полагаться на компоненты сторонних производителей, поскольку функциональность, которую вы ищете, не существует в качестве собственной службы или предлагается в качестве дополнительного компонента вашей low-code платформой. В этом случае вы будете нести ответственность за проверку и выбор компонентов сторонних производителей на основе нескольких факторов:
Доступен ли исходный код для ознакомления?
Как часто обновляется компонент?
Принадлежит ли компонент авторитетному автору или организации?
• Подключен ли компонент к сторонней службе, и если да, то безопасен ли он?
Выполняет ли поставщик low-code платформы какую-либо проверку безопасности компонентов на рынке?
Аналогично проверке сторонних пакетов с открытым исходным кодом, у вас должен быть процесс, чтобы убедиться, что вы не превращаете эти компоненты в самое слабое звено цепочки безопасности вашего приложения.
Выбор между облачным и локальным
Довольно часто low-code приложения интегрируются с существующими общедоступными облачными учетными записями, чтобы использовать общедоступные облачные сервисы, такие как хранилища, очереди сообщений, базы данных и т. Д. Если это так, вам необходимо добавить облачную безопасность в качестве дополнительного фактора к общему уровню безопасности вашего приложения. Вы должны убедиться, что применяете зрелый подход к управлению облачными системами безопасности.
Многие low-code платформы обеспечивают подключение к локальным данным и приложениям. Например, организации, использующие low-code платформу Microsoft Power Apps, могут использовать локальный шлюз данных, который действует как мост для обеспечения быстрой и безопасной передачи данных между локальными данными (данные не в облаке) и несколькими облачными службами Microsoft. Другой пример — использование low-code платформы Appian с автоматизацией роботизированных процессов (RPA), которая поддерживает гибридную облачную/локальную модель развертывания.
Создавая мост между облаком и локальной инфраструктурой, данными и приложениями вашей организации, вы, по сути, открываете свои частные активы для доступа из общедоступной сети. Излишне говорить, что в таких случаях безопасность и конфиденциальность должны быть на первом месте, а доступ должен быть максимально ограничен - зашифрован и постоянно контролироваться.
Кто несет за это ответственность? Вердикт
Учитывая все различные варианты разработки low-code приложений, на самом деле простого ответа нет. Также нет прямой линии, которую мы могли бы провести на какой-нибудь диаграмме безопасности low-code стека, которая была бы четкой. Low-code/no-code — это сдвиг парадигмы в способе разработки программного обеспечения, от монолитного к микросервисам, а теперь - low-code/no-code. Это не следует рассматривать как способ абстрагироваться от аппаратных средств и моделей развертывания в рамках следующего этапа эволюции облачных вычислений.
Суть в том, что low-code/no-code приложения - это еще одна форма программного обеспечения. Они неизбежно будут содержать ошибки, недостатки дизайна, уязвимости и неправильные конфигурации, которые приведут к возникновению риска. Даже если вы передаете часть контроля и ответственности поставщику low-code/no-code платформы или другому поставщику, вы все равно являетесь владельцем своего приложения и его данных. Вы по-прежнему несете ответственность за обеспечение безопасности приложений и соблюдение ваших корпоративных политик и стандартов безопасности.
Независимо от того, сколько абстракции вы используете и от какого контроля отказываетесь, всегда имейте в виду следующие два аспекта: знайте свои приложения и защищайте свою бизнес-логику. Вам необходимо полностью понимать, как разрабатываются, развертываются и поддерживаются ваши low-code приложения. Всегда убедитесь, что у вас есть полная видимость ваших low-code приложений, и устраните любые проблемы безопасности, поднятые здесь. И независимо от того, как разработано ваше приложение, вы всегда должны быть уверены, что применили лучшие методы безопасного проектирования, разработки и безопасности приложений. Простой недостаток в бизнес-логике может сделать уязвимым самое устойчивое приложение. Майкл Барри - генеральный директор "Zenity".
Источwww.darkreading.com/edge-articles/addressing-the-low-code-security-elephant-in-the-room