Привет, Хабр! Архитектура ПО — это фундамент, на котором строится предлагаемый пользователю продукт. И если этот фундамент даёт трещину, последствия могут быть катастрофическими.
Меня зовут Евгений, я являюсь ведущим экспертом в области информационной безопасности компании ИнфоТеКС. В этой статье я разберу шесть архитектурных антипаттернов в рамках системного подхода к проектированию и покажу, как их избежать, либо оперативно исправить. Эти знания помогут улучшить качество продукта, сэкономить нервы, время и ресурсы — как свои, так и Компании.
Содержание
Антипаттерн №2: Сотрудник компании не может быть нарушителем
Антипаттерн №5: Передача чувствительной информации в открытом виде
Антипаттерн №6: Хранение чувствительной информации в открытом виде
Уязвимости архитектурного характера в цикле ПО
Разработка программного обеспечения — сложный процесс, который можно сравнить с развитием живого организма. На каждом этапе жизненного цикла продукт обрастает «скелетом», «мышцами» и другими элементами, которые формируют его конечный облик. И чем раньше задуматься о безопасности, тем меньше переделок потребуется в будущем.
Почему важно прорабатывать безопасность на этапе проектирования?
На этом этапе закладывается основной "скелет" продукта. Разработанная архитектура определяет, насколько устойчивым, масштабируемым и безопасным будет конечное решение. Если сразу не продумать обеспечение безопасности, сделать это позже может быть крайне сложно или вовсе невозможно.
Возможные ошибки распространяются на всю информационную систему. Если не заложить элементы безопасности как составную часть базовой архитектуры, далее, уязвимости могут распространяться на все уровни и механизмы.
Это дешевле. Не сразу, не в моменте, но в перспективе и существенно. Исправление проблем проектирования, как правило, требует не точечных изменений, а глобальный переработки больших объёмов кода. Это ставит под угрозу сроки реализации проекта и его бюджет.
При разработке системы архитекторы могут иметь заведомо ложные представления о вопросах безопасности и неверно формировать требования к системе, которые в итоге становятся антипаттернами разработки, дальнейшей интеграции разработанного продукта и его эксплуатации.
Антипаттерн №1: Администратор не может быть нарушителем
Это один из самых опасных мифов в разработке и эксплуатации систем. Часто считается, что сотрудник, допущенный к управлению системой, — это человек кристальной честности, неподкупный и неспособный на злой умысел или сговор. Однако, реальность показывает, что это бывает далеко не так. Плюс, социальная инженерия остаётся самым простым, распространённым и действенным методом атак на защищаемые системы.
Основные риски
Администратор обеспечивает функционирование некоторой системы. Но никто не гарантирует, что, имея максимальные полномочия доступа в систему, он не нарушит, случайно или целенаправленно, её безопасность.
Администратор может стать жертвой подкупа или шантажа, что ставит под угрозу безопасность всей системы.
Рассмотрим стандартную схему удалённого администрирования. Между сервером управления и компьютером администратора устанавливается шифрованное соединение, например, с использованием протокола TLS. Вроде бы типовая безопасная реализация удалённого подключения, но она никак не спасает: если администратор становится нарушителем, вся система оказывается под угрозой.
Чем это грозит?
Если администратор имеет неограниченный доступ к системе, он может:
Изменять настройки безопасности, открывая доступы кому угодно,
Получать доступ к конфиденциальным данным,
Скрывать следы своих действий, что затрудняет расследование инцидентов.
Как решить проблему?
Ответ кроется в правильной организации доступа и разделении полномочий.
Разделите управление системой и доступ к данным. Администратор не должен иметь доступ к защищаемой информации.
Используйте принцип минимизации полномочий: выделите разные роли администраторов с ограниченными правами. Не «кладите все яйца в одну корзину» — не давайте какому-либо администратору неограниченные права.
Если в системе всё же требуется суперпользователь, используйте схему разделения его секрета (например, схему Шамира). Это позволяет распределить доступ между несколькими сотрудниками, исключая концентрацию «власти» в одних руках.
Фиксируйте и проверяйте все действия администраторов с использованием автоматизированных средств, например, с помощью систем PAM (Privileged Access Management). Также проводите регулярный аудит доступов. Такие меры помогут своевременно выявлять подозрительные активности.
Антипаттерн №2: Сотрудник компании не может быть нарушителем
Ещё одно распространённое заблуждение — уверенность в том, что сотрудник компании не может стать нарушителем. Зачастую безопасность внутренней инфраструктуры настраивается с минимальными усилиями: работает аутентификация, и этого достаточно. Однако, такой подход игнорирует риски, связанные с действиями сотрудников, которые могут быть как злонамеренными, так и непреднамеренными.
Основные риски
Несанкционированный доступ к инфраструктуре позволяет злоумышленнику получать конфиденциальные данные — например, когда рядовой сотрудник получает возможность просматривать финансовые операции компании, а данный функционал выходит за рамки его полномочий.
Кроме того, избыточный доступ к инфраструктуре сети открывает злоумышленнику возможности её полного исследования, что упрощает проведение атак, включая внутреннее сканирование системы и внедрение вредоносного ПО.
Сотрудник может стать жертвой подкупа или шантажа, что превращает его в инструмент для атаки.
Представим предприятие с внутренней инфраструктурой, где сервисы, базы данных, маршрутизаторы и другие элементы настроены с минимальными мерами безопасности. Например, используются пароли по умолчанию, отсутствует сегментация сети, а доступ к данным не разграничен. В такой среде сотрудник, даже рядовой, может получить доступ к конфиденциальной информации, включая финансовые данные или управленческие отчёты.
Более того, сотрудник может стать нарушителем, как напрямую (например, из любопытства или злого умысла), так и опосредованно — через заражённый компьютер, который становится точкой входа для внешних атак.
Чем это грозит?
Финансовые данные, персональные данные сотрудников, документы, представляющие коммерческую тайну — всё это может оказаться в руках злоумышленников.
Злоумышленник, получивший доступ к данным о внутренней сети, может использовать их для более масштабных атак.
Сотрудник может намеренно или случайно запустить вредоносный код, что приведёт к нарушению работы одной или нескольких систем компании.
Как защититься от внутреннего нарушителя?
Разделите сеть на изолированные сегменты. Это позволит ограничить сотрудникам доступ только к ресурсам, которые необходимы для их работы.
Внедрите модель минимальных привилегий при доступе в системы — это ещё один механизм, дающий возможность предоставить доступ сотрудникам только к тем ресурсам и сервисам, с которыми они имеют право работать.
Фиксируйте и контролируйте действия сотрудников, связанные с доступами к данным и управлению инфраструктурой.
Настройте постоянный мониторинг сети и действий пользователей, чтобы своевременно выявлять подозрительную активность.
Регулярно проводите обучение сотрудников основам кибербезопасности. Это снижает риски непреднамеренных действий, которые могут привести к несанкционированным последствиям.
Антипаттерн №3: Запуск из-под суперпользователя
На первый взгляд, запуск сервисов и приложений от имени суперпользователя (root) кажется удобным: нет ограничений на доступ к ресурсам системы, что упрощает разработку и эксплуатацию. Однако такое отсутствие ограничений становится и основной «уязвимостью», которая может привести к катастрофическим последствиям.
Основные риски
Данный антипаттерн несёт в себе один большой риск, который представляет собой следующую последовательность:
Рассмотрим пример с сервисом удалённого администрирования через SSH. Организации нужен удалённый доступ к системе, и разработчики устанавливают SSH-сервер, который по умолчанию запускается на порту 22. Сервис сконфигурирован с правами суперпользователя.
Если в SSH-сервере есть актуальные незакрытые общеизвестные уязвимости (CVE), злоумышленник может проэксплуатировать их для получения доступа к системе. В худшем случае это приведёт к полному захвату системы с правами root.
Чем это грозит?
Злоумышленник может изменять настройки, устанавливать вредоносное ПО, красть данные и выводить систему из строя.
Скомпрометированная система может стать плацдармом для атак на другие элементы инфраструктуры.
Утечка данных и простои системы наносят ущерб репутации компании.
Как решить проблему?
Ограничьте доступ сервисов к другим элементам системы. Например, настройте запрет на чтение или запись в критически важные каталоги.
Настройте запуск сервисов и приложений с минимальными правами, необходимыми для их работы. Например, можно создать учётную запись отдельного пользователя с ограниченными правами для запуска и функционирования SSH-сервера.
Используйте нетиповые порты для запуска сервисов. Например, настройте перенаправление трафика с порта 22 на порт 2582.
Своевременно обновляйте сервисы и ОС для устранения общеизвестных уязвимостей.
Постоянно контролируйте активность сервисов и пользователей, внедрив системы мониторинга и аудита, чтобы своевременно выявлять подозрительную активность.
Антипаттерн №4: Отсутствие аутентификации между сервисами
Даже если были учтены предыдущие антипаттерны и сервисы работают с минимальными привилегиями, это не гарантирует полной безопасности. Следующая ключевая уязвимость, которую часто упускают из виду, — это отсутствие аутентификации между внутренними сервисами. В результате злоумышленник, имеющий доступ к инфраструктуре организации, может беспрепятственно получить доступ к данным или управлению работающих в ней систем.
Основные риски
Злоумышленник может получить контроль над критически важными сервисами, что приведёт к нарушению работы всей организации.
У злоумышленника появляется доступ к управлению данными: возможность чтения, изменения или удаления данных, включая конфиденциальную информацию.
Представим, что злоумышленник смог получить доступ к системе через общеизвестную уязвимость в SSH-сервере, который был запущен с ограниченными правами доступа. Однако внутри хоста сервисы взаимодействуют друг с другом без аутентификации. Например, база данных использует логин и пароль по умолчанию.
В такой ситуации злоумышленнику не нужно эксплуатировать дополнительные уязвимости — достаточно подключиться к серверу баз данных с учётными данными по умолчанию. Это даст ему полный доступ ко всем данным, включая возможность их изменения или удаления.
Чем это грозит?
Конфиденциальная информация, такая как финансовые данные, персональные данные или коммерческая тайна, может быть украдена.
Злоумышленник может манипулировать данными, включая потерю критически важной информации, что может привести к ошибкам в работе системы и на их основе неверным решениям, включая стратегические.
Получив доступ к внутренним сервисам, злоумышленник может изменять настройки системы, что приведёт к её нестабильности или полному выходу из строя.
Как не допустить подобного?
Настройте взаимную аутентификацию всех сервисов. Например, это можно реализовать с использованием протокола TLS с взаимной проверкой сертификатов.
Контролируйте взаимодействие сервисов, чтобы своевременно выявлять подозрительную активность.
Антипаттерн №5: Передача чувствительной информации в открытом виде
Следующая критичная проблема, когда при разработке архитектуры сервиса в неё не закладывается обеспечение защиты либо каналов связи, либо передаваемых по ним чувствительных данных (например, паролей). Подразумевается, что защита каналов обеспечивается иными средствами. Например, данные передаются по протоколу HTTP. Один из самых опасных и часто встречающихся антипаттернов — это передача чувствительной информации в открытом виде.
Основные риски
Перехват паролей, ключей шифрования, персональных данных и другой конфиденциальной информации.
Злоумышленник может перехватывать и/или изменять передаваемые данные, что приведёт к ошибкам в работе системы, её компрометации или распространению ложной информации.
Рассмотрим стандартную схему взаимодействия между клиентом и сервером. При этом, на интервале между веб-интерфейсом пользователя и сервером данные передаются по протоколу HTTP, включая логин и пароль пользователя, который их вводит в веб-интерфейсе. Это создаёт уязвимость системы, которую может использовать злоумышленник для атаки «человек посередине». Это особенно опасно, если речь идёт о паролях, закрытых ключах и т.д.
Чем это грозит?
Злоумышленник может получить доступ к паролям, ключам шифрования или иным чувствительным данным.
Перехваченные данные, которые обрабатываются в системе, могут быть изменены, что приведёт к ошибкам в её работе или распространению ложной информации.
Утечка или модификация данных наносит ущерб репутации компании и может привести к финансовым потерям.
Как решить проблему?
Используйте защиту интервалов взаимодействия в системе, на которых передаются чувствительные данные (например, путем их шифрования), а также доверенные и актуальные алгоритмы шифрования. Это исключает возможность атаки «человек посередине».
Шифруйте или маскируйте чувствительные данные даже при использовании защищённого канала.
Передавайте данные через разные логические каналы. Например, запароленный архив с данными можно передавать посредством электронной почты, а пароль к нему через отправку персонального SMS-сообщения.
Антипаттерн №6: Хранение чувствительной информации в открытом виде
После рассмотрения проблем, связанных с передачей данных, логично перейти к следующему критическому аспекту — хранению чувствительной информации. Если данные передаются по защищённым каналам, но хранятся в открытом виде, это можно свести на нет все усилия по обеспечению безопасности. Например, когда в конфигурации сервиса прописаны логин и пароль в открытом виде в текстовом документе.
Основные риски
Злоумышленник, получивший доступ к системе, может легко извлечь пароли, ключи шифрования и другую конфиденциальную информацию.
Используя украденные данные аутентификации, злоумышленник может получить несанкционированный доступ к другим частям системы или иным сервисам, к которым она подключается.
Хранение данных в открытом виде делает их уязвимыми для внутренних нарушителей, особенно для администраторов.
Рассмотрим стандартную схему взаимодействия клиента и сервера. Для аутентификации необходимы логин и пароль или пары ключей (открытый/закрытый). Если эти данные хранятся в открытом виде на машине пользователя, любой пользователь этой системы, может легко их извлечь.
Чем это грозит?
Конфиденциальная информация, такая как пароли, ключи шифрования или иные чувствительные данные могут быть украдены.
Используя украденные данные, злоумышленник может получить доступ к системе или другим системам или сервисам, с которыми она взаимодействует.
Утечка данных, их изменение или удаление наносит ущерб репутации компании и может привести к финансовым потерям.
Как не допустить подобного?
Храните в зашифрованном виде все чувствительные данные, такие как пароли и ключи шифрования.
Храните пароли в виде хэшей, полученных с использованием современных алгоритмов, таких как bcrypt или Argon2. Это предотвращает восстановление паролей даже в случае утечки данных.
Ограничьте доступ к чувствительным данным. Откройте доступ только тем сервисам и пользователям, которым он действительно необходим.
Применяйте специализированные решения для хранения секретов, такие как HashiCorp Vault или AWS Secrets Manager.
Проверяйте настройки хранения данных и своевременно устраняйте уязвимости.
Как избежать последствий антипаттернов?
Чтобы построить надёжную и безопасную систему, необходимо учитывать антипаттерны уже на этапе проектирования. Это позволит не только избежать критических архитектурных уязвимостей, но и сэкономить время и ресурсы в будущем.
Делимся с вами чек-листом, который поможет избежать последствий антипаттернов при работе с корпоративной архитектурой. Читайте, сохраняйте себе и делитесь с коллегами статьёй.
А что со сроками?
При изначальном учёте антипаттернов:
Время первоначального проектирования и разработки ядра системы увеличится. Но оно увеличится однократно и предсказуемо, а дальнейшие радикальные изменения архитектуры системы во время эксплуатации могут занять неопределённое количество времени и значительные ресурсы всей команды.
Время для устранения архитектурных уязвимостей — увеличивается кратно. Исключаются значительные трудозатраты, включая временные, на исправление критичных архитектурных уязвимостей, если их не учли при первоначальном проектировании.
Экономия времени даёт возможность потратить его на дальнейшую доработку бизнес-функционала разрабатываемого сервиса и минимальными усилиями закрывать минорные уязвимости, если они обнаруживаются.
Таким образом, правильный подход к проектированию не только повышает безопасность, но и оптимизирует временные и финансовые затраты на поддержку системы.
Заключение
Защита сервиса и обрабатываемой им информации — это не разовая задача, а непрерывный процесс. Мы рассказали о своём подходе к повышению безопасности. Поделитесь и вы своим опытом.
Если у вас есть примеры успешного внедрения механизмов безопасности или, наоборот, случаи, когда что-то пошло не так, — расскажите об этом. Поможем друг другу избежать ошибок и создать более надёжные решения!
P.S. Чтобы не пропустить наши новые материалы, подписывайтесь на блог! И заходите в TG-канал, там мы рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.