Разработка безопасных и надежных облачных веб-приложений — непростая задача.
Это даже очень сложно.
Если вы думаете, что это не так, то либо вы представитель неизвестной науке высшей формы жизни, либо ждите изрядного жареного петуха.
Если вы вдохновлены идеи создавая минимально жизнеспособный продукт и уверены, что за месяц можно разработать что-то полезное и безопасное, дважды подумайте, прежде чем выпускать такой «продукт», а лучше всего лишь прототип.
После того, как вы просмотрите следующий чек-лист задач, которые необходимо выполнить для обеспечения безопасности веб-проекта, вы, вероятно, сами убедитесь, что многое из того, что там есть, не учтено в вашем дизайне.
Что делать? Как минимум, будьте честны с потенциальными пользователями и скажите им, что ваш проект все еще находится в разработке, что вы предлагаете им ознакомиться с прототипом, в котором еще не реализована полноценная система безопасности.
База данных
- Если возможно, используйте шифрование для хранения информации, идентифицирующей пользователя, и для хранения конфиденциальных данных, таких как токены доступа, адреса электронной почты или платежные реквизиты (этот подход, в частности, ограничит запросы к базе данных уровнем поиска с точным совпадением).
- Если ваша СУБД поддерживает экономичное шифрование хранящихся данных, включите его для защиты информации на дисках.
Кроме того, убедитесь, что все резервные копии базы данных также зашифрованы.
- Используйте учетные записи пользователей с минимальными привилегиями для доступа к базам данных.
Избегайте использования учетной записи суперпользователя и проверьте свою систему на наличие неиспользуемых учетных записей и учетных записей со слабыми паролями.
- Храните и передавайте учетные данные учетной записи, токены доступа к системе и другую конфиденциальную информацию, используя хранилище ключей, предназначенное для сценариев такого типа.
Не храните такие данные, жестко фиксируя их в коде приложения.
- Защитите свою систему от атак с использованием SQL-инъекций, используя только подготовленные SQL-запросы.
Например, если ваш проект разработан для Node.js, не используйте библиотеку mysql nmp, обратитесь к библиотеке mysql2 , который поддерживает подготовленные запросы.
Разработка
- Убедитесь, что компоненты системы проверяются на наличие уязвимостей перед каждым выпуском.
Речь идет обо всех библиотеках, пакетах и рабочей среде.
В идеале проверки должны быть автоматизированы как часть процесса.
CI-CD .
- Обеспечьте безопасность компьютеров разработки, рассматривая эту проблему с таким же вниманием, как и безопасность рабочих серверов.
Разработка должна вестись на защищенных машинах, изолированных от потенциально опасной внешней среды.
Аутентификация
- Убедитесь, что все пароли хешированы с использованием подходящего криптографического алгоритма, например bcrypt .
Не используйте самодельные функции хеширования; правильно инициализируйте используемые вами криптосистемы, используя высококачественные случайные данные.
- Используйте проверенные временем, проверенные компоненты для управления входом в систему, восстановлением забытого пароля и сбросом пароля.
Не изобретайте велосипед. Дело в том, что если вы будете разрабатывать его самостоятельно, вам будет очень сложно обеспечить корректную работу таких механизмов во всех возможных сценариях.
- Внедрите простые, но не угрожающие безопасности требования к паролям, которые побуждают пользователей создавать длинные пароли, состоящие из случайных наборов символов.
- Используйте многофакторную аутентификацию для всех поставщиков услуг.
Защита от DOS-атак
- Убедись в том, что DOS-атаки ваш API не повлияет на производительность сайта.
Как минимум, реализуйте ограничение скорости на самых медленных путях API и в частях вашего дизайна, связанных с аутентификацией.
Например, речь может идти о модулях входа и подсистемах создания токенов доступа.
Рассмотрите возможность использования CAPTCHA в тех частях проекта, которые доступны из внешнего мира, чтобы защитить подсистемы сервера от DOS-атак.
- Установите разумные ограничения на размер и структуру данных, которые пользователи могут отправлять в систему, а также на запросы, которые они могут выполнять.
- Рассмотрите возможность использования системы для смягчения последствий распределенных атак DOS, например, с помощью прокси-службы глобального кэширования, такой как ОблакоВспышка .
Во время атаки это поможет вашему проекту выжить, а в обычное время снизит нагрузку на серверы и ускорит загрузку сайта.
Веб-трафик
- Используйте TLS для всего сайта, а не только для защиты системы авторизации.
Никогда не используйте TLS только для защиты формы входа.
В течение переходного периода используйте заголовок HTTP strict-transport-security, чтобы принудительно использовать протокол HTTPS.
- Файлы cookie должны иметь атрибут httpOnly, они должны быть безопасными, а их атрибуты должны включать параметры пути и домена.
- Используйте политику защиты контента ( CSP , Политика безопасности контента), без предоставления разрешений unsafe-inline и unsafe-eval. Эту политику непросто настроить, но она стоит затраченных усилий и времени.
Применить механизм Целостность субресурса для контента CDN.
- Используйте HTTP-заголовки X-Frame-Option и X-XSS-Protection в ответах клиентов.
- Используйте механизм HSTS, чтобы обеспечить доступ к системе только с использованием TLS. Не доверяйте клиентским системам, убедитесь, что на стороне сервера используется HTTPS.
- Используйте токены CSRF во всех формах, используйте новый атрибут cookie SameSite для защиты от атак CSRF. Поддерживается современными версиями браузеров.
API
- Убедитесь, что в общедоступных API нет ресурсов, которые можно обнаружить методом перебора.
- Пользователи должны быть полностью аутентифицированы и должным образом авторизованы, прежде чем они смогут использовать API.
Проверка и преобразование данных
- Проверка на стороне клиента данных, введенных пользователями.
Это позволит им быстро получить ответ на свои действия.
Однако никогда не доверяйте этому тесту.
Всегда проверяйте и конвертируйте то, что ввел пользователь, в нужный вам формат, прежде чем отображать это на страницах сайта.
- Проверяйте все, что приходит от пользователя, используя белые списки на сервере.
Никогда не вставляйте незакодированный пользовательский ввод в HTTP-запросы и ответы.
Ни при каких обстоятельствах не используйте потенциально опасные данные, предоставленные пользователем, в запросах SQL или другой логике на стороне сервера.
Облачные настройки
- Убедитесь, что у всех облачных сервисов открыто минимальное количество портов.
Хотя обеспечение безопасности путем сокрытия информации не является защитой, использование нестандартных портов усложнит жизнь тем, кто попытается атаковать вашу систему.
- Храните базы данных и сервисы в виртуальных частных облаках (VPC), недоступных извне.
Будьте очень осторожны при настройке групп безопасности AWS и настройке пиринга между VPC, поскольку ошибки могут привести к тому, что внутренние сервисы станут доступны внешнему миру.
- Изолируйте логические сервисы в разных VPC и настройте пиринг между ними, чтобы обеспечить межсервисное взаимодействие.
- Убедитесь, что все сервисы принимают данные только с минимально необходимого набора IP-адресов.
- Ограничьте исходящий трафик по IP-адресу и порту, чтобы свести к минимуму возможность целевые кибератаки и атаки ботов.
- Всегда используйте роли AWS IAM, а не учетную запись root.
- Используйте минимальные права доступа для специалистов по обслуживанию и разработчиков системы.
- Регулярно меняйте пароли и ключи доступа в соответствии с графиком.
Инфраструктура
- Убедитесь, что вы можете выполнять обновления проекта без простоев.
Внедрить полностью автоматическую систему, позволяющую быстро обновлять программное обеспечение.
- Создайте всю свою инфраструктуру с помощью таких инструментов, как Terraform, а не с помощью консоли управления облаком.
Стремитесь реализовать подход «инфраструктура как код».
Это позволит вам при необходимости воссоздать все буквально одним нажатием клавиши.
Избегайте создания облачных ресурсов вручную.
Проведите аудит конфигурации.
- Используйте инструменты централизованного журналирования для всех сервисов.
Система журналирования должна быть спроектирована таким образом, чтобы вам никогда не приходилось подключаться к системе через SSH только для просмотра или загрузки журналов.
- Не подключайтесь к сервисам по SSH, за исключением единичных случаев диагностики.
Регулярное использование SSH обычно означает, что важные задачи не автоматизируются.
- Не оставляйте порт 22 всегда открытым в любой сервисной группе AWS. Если вам абсолютно необходим доступ по SSH, используйте только аутентификацию с открытым ключом, а не логины и пароли.
- Отдать предпочтение неизменяемые хосты , а не долгоживущие серверы, которые вы исправляете и обновляете.
Здесь полезный материал по этой теме.
- Использовать Система обнаружения вторжений минимизировать ущерб от целенаправленных кибератак.
Эработа инфраструктуры
- Отключите неиспользуемые службы и серверы.
Самый безопасный сервер — тот, у которого отключен шнур питания.
Тестирование системы
- Проводить аудит архитектуры и реализации системы.
- Проведите тестирование системы на проникновение – взломайте сами.
Однако к таким испытаниям полезно привлекать сторонних специалистов.
Обучение
- Обучите персонал (особенно новых сотрудников) киберрискам и методам социальной инженерии, используемым для компрометации систем.
План действий в непредвиденных обстоятельствах
- Создайте модель угроз, описывающую, от чего вы защищаете.
В нем следует перечислить с указанием приоритетов возможные угрозы и участников атак.
- Подготовьте четкий план действий в чрезвычайной ситуации.
Однажды оно тебе понадобится.
Полученные результаты
Чек-лист задач, рассмотренный в этом материале, не претендует на полноту.Все дело в том, что каждый веб-проект уникален и только его создатели точно знают, что ему угрожает и как именно с этими угрозами бороться.
Однако различные проекты имеют много общих черт. Поэтому мы уверены, что каждый сможет скорректировать представленный здесь список под свой проект. То, что вы прочитали, основано на более чем четырнадцатилетнем опыте автора в разработке безопасных веб-приложений.
Этот опыт дался ему непросто, и мы уверены, что его выводы облегчат жизнь тем, кто беспокоится о безопасности своих веб-решений.
Уважаемые читатели! Что бы вы добавили в этот список? Теги: #информационная безопасность #разработка веб-сайтов #безопасность #тестирование веб-сервисов #веб-разработка
-
Краш-Тест При Запуске Версии 2.0
19 Oct, 24 -
Плохой Стиль Для Нового Комментария
19 Oct, 24 -
Интернет-Магазин Промышленного Оборудования
19 Oct, 24
