Разработка защищённых и надёжных облачных веб-приложений — задача непростая. Даже — очень непростая. Если вы думаете, что это не так, то либо вы — представитель неизвестной науке высшей формы жизни, либо — ждите здоровенного жареного петуха.
Если вы вдохновились идеями создания минимального жизнеспособного продукта и уверены в том, что можете разработать нечто полезное и безопасное за месяц, дважды подумайте, прежде чем выпускать в жизнь подобный «продукт», а скорее — лишь прототип.
После того, как вы просмотрите приведённый ниже контрольный список задач, которые нужно решить для обеспечения безопасности веб-проекта, вы, наверняка, сами увидите, что многое из того, что в нём есть, в вашей разработке не учтено. Что делать? Как минимум — будьте честны с потенциальными пользователями и сообщите им о том, что ваш проект пока находится в стадии разработки, что вы предлагаете им ознакомиться с прототипом, в котором пока не реализована полноценная система безопасности.
Базы данных
- Если это возможно, используйте шифрование для хранения информации, идентифицирующей пользователя, и для хранения конфиденциальных данных, вроде токенов доступа, адресов электронной почты или платёжных реквизитов (такой подход, в частности, позволит ограничить запросы к базе до уровня поиска по точному совпадению).
- Если ваша СУБД поддерживает экономичное шифрование хранимых данных, включите его для защиты информации, находящейся на дисках. Кроме того, проверьте, чтобы все резервные копии баз тоже были зашифрованы.
- Используйте для доступа к базам данных учётные записи пользователей с минимальными привилегиями. Не применяйте учётную запись суперпользователя и проверяйте систему на наличие неиспользуемых учётных записей и учётных записей со слишком слабыми паролями.
- Храните и передавайте данные учётных записей, токены доступа к системе и прочую секретную информацию, используя хранилище ключей, рассчитанное на подобные сценарии работы. Не храните такие данные, жёстко задав их в коде приложений.
- Защитите систему от атак путём SQL-инъекций, используя только подготовленные SQL-запросы. Например, если ваш проект рассчитан на Node.js, не применяйте nmp-библиотеку mysql, обратитесь к библиотеке mysql2, которая поддерживает подготовленные запросы.
Разработка
- Обеспечьте проверку компонентов системы на уязвимости перед каждым релизом. Речь идёт обо всех библиотеках, пакетах, о рабочей среде. В идеале, проверки надо автоматизировать в рамках процесса CI-CD.
- Обеспечьте безопасность компьютеров разработчиков, отнесясь к этому вопросу с тем же вниманием, с которым относитесь к безопасности продакшн-серверов. Разработка должна вестись на защищённых, изолированных от потенциально опасной внешней среды машинах.
Аутентификация
- Убедитесь в том, что все пароли хэшированы с использованием подходящего криптоалгоритма вроде bcrypt. Не пользуйтесь самописными функциями хэширования, правильно инициализируйте используемые криптосистемы с помощью качественных случайных данных.
- Используйте проверенные временем, хорошо зарекомендовавшие себя компоненты для организации входа в систему, восстановления забытого пароля и сброса пароля. Не изобретайте велосипед. Дело в том, что при самостоятельной разработке вам будет очень сложно обеспечить корректную работу подобных механизмов во всех возможных сценариях.
- Внедряйте простые, но не угрожающие безопасности системы требования к паролям, которые стимулируют пользователей к созданию длинных паролей, состоящих из случайных наборов символов.
- Применяйте, для всех сервис-провайдеров, многофакторную аутентификацию.
Защита от DOS-атак
- Убедитесь в том, что DOS-атаки на ваше API не повлияют на работоспособность сайта. Как минимум, задействуйте ограничение частоты запросов в самых медленных путях API и в тех частях проекта, которые связаны с аутентификацией. Например, речь может идти о модулях входа в систему и о подсистемах создания токенов доступа. Рассмотрите использование CAPTCHA в тех частях проекта, которые доступны из внешнего мира для защиты серверных подсистем от DOS-атак.
- Установите здравые ограничения на размеры и структуру данных, которые пользователи могут отправлять в систему, а также на выполняемые ими запросы.
- Рассмотрите возможность использования системы для смягчения последствий распределённых DOS-атак, например, с помощью глобального кэширующего прокси-сервиса вроде CloudFlare. Во время атаки это поможет вашему проекту выстоять, а в обычное время снизит нагрузку на сервера и ускорит загрузку сайта.
Веб-трафик
- Используйте TLS для всего сайта, а не только для защиты системы авторизации. Никогда не применяйте TLS только для защиты формы авторизации. В переходный период задействуйте HTTP-заголовок strict-transport-security для принудительного использования протокола HTTPS.
- Куки-файлы должны иметь атрибут httpOnly, они должны быть защищёнными, среди их атрибутов должны присутствовать параметры path и domain.
- Используйте политику защиты контента (CSP, Content Security Policy), не давая разрешений unsafe-inline и unsafe-eval. Такую политику непросто настроить, но это стоит затраченных сил и времени. Применяйте механизм Subresource Integrity для CDN-контента.
- Используйте HTTP-заголовки X-Frame-Option и X-XSS-Protection в ответах клиентов.
- Применяйте механизм HSTS для обеспечения доступа к системе только с помощью TLS. Не доверяйте клиентским системам, обеспечьте использование HTTPS на стороне сервера.
- Используйте CSRF-токены во всех формах, применяйте новый атрибут куки-файлов SameSite для защиты от CSRF-атак. Его поддерживают современные версии браузеров.
API
- Проверьте, чтобы в общедоступных API не было ресурсов, которые можно обнаружить методом перебора.
- Пользователи должны быть полностью аутентифицированы и соответствующим образом авторизованы перед тем, как они смогут пользоваться API.
Проверка и преобразование данных
- Проверяйте, на стороне клиента, данные, введённые пользователями. Это позволит им быстрее получить отклик на свои действия. Однако, никогда не доверяйте этой проверке. Всегда проверяйте и преобразуйте к необходимому вам формату то, что ввёл пользователь, перед отображением на страницах сайта.
- Проверяйте всё, что поступает от пользователя, используя белые списки на сервере. Никогда не вставляйте незакодированные данные, введённые пользователем, в HTTP-запросы и ответы. Ни при каких обстоятельствах не используйте потенциально опасные данные, введённые пользователем, в SQL-запросах или в другой серверной логике.
Настройки облачной среды
- Проверьте, чтобы у всех облачных сервисов было открыто минимальное количество портов. Хотя обеспечение безопасности через сокрытие информации — это не защита, использование нестандартных портов усложнит жизнь тем, кто попытается атаковать вашу систему.
- Держите базы данных и службы в виртуальных частных облаках (VPС, Virtual Private Cloud) к которым нет доступа извне. Будьте очень внимательны, конфигурируя группы безопасности AWS и настраивая пиринг между VPC, так как ошибки могут привести к тому, что внутренние сервисы будут видны извне.
- Изолируйте логические сервисы в разных VPC и настройте пиринг между ними для обеспечения межсервисного взаимодействия.
- Убедитесь в том, что все сервисы принимают данные только с минимально необходимого набора IP-адресов.
- Ограничьте исходящий трафик по IP-адресам и портам для минимизации возможности целевых кибератак и атак ботов.
- Всегда используйте роли AWS IAM, а не учётную запись суперпользователя.
- Используйте минимальные привилегии доступа для тех, кто занимается обслуживанием системы, и для разработчиков.
- Регулярно, по расписанию, выполняйте ротацию паролей и ключей доступа.
Инфраструктура
- Убедитесь в том, что можете выполнять обновления проекта без простоев. Внедрите полностью автоматическую систему, которая позволяет быстро обновлять ПО.
- Создавайте всю инфраструктуру, используя инструменты вроде Terraform, а не через консоль управления облачными службами. Стремитесь к реализации подхода «инфраструктура как код». Это позволит вам, при необходимости, воссоздать всё буквально одним нажатием на клавишу. Не допускайте ручного создания облачных ресурсов. Проводите аудит конфигурации.
- Используйте централизованные средства логирования для всех сервисов. Система логирования должна быть выстроена так, чтобы никогда не нужно было подключаться к системе по SSH только для того, чтобы просмотреть или загрузить журналы.
- Не подключайтесь к сервисам по SSH, за исключением единичных случаев их диагностики. Регулярное использование SSH обычно означает то, что важные задачи у вас не автоматизированы.
- Не держите постоянно открытым порт 22 в любой группе сервисов AWS. Если вам совершенно необходим доступ по SSH, используйте только аутентификацию с открытым ключом, а не логины и пароли.
- Отдавайте предпочтение иммутабельным хостам, а не долгоживущим серверам, которые вы патчите и обновляете. Вот полезный материал на эту тему.
- Используйте систему обнаружения вторжений для минимизации ущерба от целевых кибератак.
Эксплуатация инфраструктуры
- Отключайте неиспользуемые сервисы и сервера. Самый защищённый сервер — это тот, из которого выдернули шнур питания.
Тестирование системы
- Выполняйте аудит архитектуры и реализации системы.
- Проводите тестирование системы на проникновение — взломайте себя сами. Однако, полезно привлекать к подобным испытаниям и сторонних специалистов.
Обучение персонала
- Обучайте персонал (особенно новичков), рассказывая о кибер-рисках и о методах социальной инженерии, используемых для взлома систем.
План действий во внештатной ситуации
- Создайте модель угроз, которая описывает то, от чего вы защищаетесь. В ней должны быть перечислены, с назначением приоритетов, возможные угрозы и участники атак.
- Подготовьте чёткий план действий во нештатной ситуации. Однажды он вам понадобится.
Итоги
Рассмотренный в этом материале контрольный список задач не претендует на полноту. Всё дело в том, что каждый веб-проект уникален и только его создатели точно знают, что именно ему угрожает, и как именно с этими угрозами бороться. Однако, у различных проектов немало общих черт. Поэтому, полагаем, каждый сможет подстроить представленный здесь список под свой проект.
То, что вы прочли, основано на более чем четырнадцатилетнем опыте автора материала в сфере разработки защищённых веб-приложений. Этот опыт дался ему нелегко, и мы уверены, что его находки смогут облегчить жизнь тем, кого беспокоит безопасность их веб-решений.
Уважаемые читатели! А что бы вы добавили в этот список?
Автор: ru_vds
