Защитите исходный код и среду своего приложения, снизив известные риски безопасности.

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

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

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

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

Первый риск: инфраструктура открытого доступа

Начиная с точки зрения безопасности инфраструктуры, нам необходимо рассмотреть все инструменты и сторонние сервисы, используемые для построения инфраструктуры.

Для дальнейшего объяснения, каждый программный проект требует нескольких инфраструктурных сервисов для управления циклом разработки программного обеспечения и поддержки автоматизации с использованием инструментов непрерывной интеграции, доставки и развертывания. Примерами таких инструментов являются Jenkins, Docker Registry, менеджер и репозиторий пакетов программного обеспечения и т. Д.

Вот основные варианты использования большинства этих инструментов:

  • Управляйте, храните и обновляйте программные пакеты
  • Запуск конвейеров CI / CD
  • Доставить или развернуть программные пакеты в соответствующих средах.

Запуск описанных выше инструментов и служб инфраструктуры с открытым доступом (без аутентификации) подвергает следующие риски безопасности:

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

Чтобы снизить риск открытого доступа, выполните следующие действия:

  • Каждый инструмент или сторонняя служба должны быть защищены механизмом аутентификации. Используйте централизованный сервер аутентификации, такой как Active Directory или OpenLDAP, для управления учетными записями пользователей вместо наличия нескольких децентрализованных механизмов. И пользователи, и администраторы будут довольны такими решениями, потому что пользователям не нужно запоминать много паролей, а администраторам не нужно управлять более чем одной базой пользователей.
  • Авторизация действий должна быть реализована для защиты от несанкционированных действий.

Второй риск: жестко заданные конфигурации

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

Совмещение данных и конфигураций приложения с исходным кодом приложения имеет следующие недостатки:

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

Чтобы снизить риск открытого доступа, выполните следующие действия:

  • Жестко запрограммированные конфигурации должны быть запрещены и удалены из исходного кода.
  • Конфигурации следует загружать и управлять ими либо во время выполнения из базы данных (это идеальное решение, потому что его можно изменить на лету без повторного развертывания), либо во время развертывания из предопределенного набора переменных среды (на мой взгляд, это должно быть ограничено до конфигурации, необходимые для запуска приложения, например URL-адрес базы данных)
  • Следует по возможности избегать конфигураций во время сборки.

Третий риск: секреты обычного текста

Хранение конфиденциальных данных (таких как пароли или секреты) в исходном коде приложения гораздо более рискованно, чем хранение обычных элементов конфигурации.

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

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

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

Четвертый риск: незащищенные конечные точки приложения

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

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

  • Открывайте только необходимые конечные точки в производственной среде. Конечные точки, разработанные для целей разработки и отладки, нельзя использовать в производственных средах.
  • Защитите открытые конечные точки или интерфейсы администратора, развернутые в производственной среде, с помощью базовых учетных данных для аутентификации или, что еще лучше, с помощью надлежащих решений для аутентификации и авторизации.

Пятый риск: отсутствие связи TLS

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

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

Поэтому рекомендуется поддерживать и использовать TLS-соединение между службами для защиты от таких атак. Ниже приведены некоторые рекомендации, которые следует учитывать при внедрении этого изменения.

  • Используйте HTTPS через HTTP-соединение между службами и включите функцию verify-SSL, чтобы убедиться, что на серверах есть действующий SSL-сертификат.
  • Используйте для своих услуг поддерживаемый протокол TLS. Например, с 31 марта 2020 года TLS 1.0 и 1.1 больше не поддерживаются. После этой даты все конечные точки должны будут поддерживать TLS 1.2 для правильной работы со многими сервисами, такими как Cisco Umbrella. Более того, Google, Microsoft, Apple и Mozilla объявили, что их браузеры больше не будут поддерживать TLS 1.0 и 1.1 с марта 2020 года.

Заключение

Безопасность следует рассматривать и регулярно рассматривать в течение жизненного цикла программного приложения. Каждое изменение, внесенное в приложение, следует оценивать с точки зрения безопасности.

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