Кибербезопасность: как защитить платформу и завоевать доверие клиентов
Сейчас при разработке у проектов есть целый блок, посвящённый кибербезопасности: компании не хотят получать штрафы за утечку персональных данных, терять деньги и доверие клиентов. Рассказываем на примерах кейсов, с какими задачами по кибербезу обращаются крупные компании.
Две основные проблемы, которые мешают бизнесу нормально работать
Существуют две основные проблемы в области информационной безопасности, которые встречаются во всех нишах и характерны для бизнеса любого размера:
- Атаки на сайт. К ним относятся DDoS-атаки и боты, которые блокируют работу сайта. С этой проблемой хорошо справляются сторонние решения — сервисы по защите от DDoS-атак. Они фильтруют вредоносный трафик, блокируя попытки перегрузки системы, но при этом не мешают работе поисковых ботов и других сервисов. Это недорогое решение подходит и крупному, и малому бизнесу. Правильно установленный сервис значительно снижает вероятность успешной атаки на платформу. Расскажем подробнее дальше в этой статье, как мы внедряли такие решения и что из этого вышло.
- Утечка персональных данных. К персональным данным относятся любые данные о пользователях, например количество и состав заказов в интернет-магазине или любая информация в личных кабинетах клиентов. Чтобы сократить риски утечки, нужно анализировать код и проводить тесты на проникновение.
Мы решаем проблему так: разработчики запускают инструменты, которые по своим базам уязвимостей прогоняют код и проверяют слабые места — например, чтобы не было незакрытых уязвимых портов для подключения к проекту. Чтобы минимизировать риски и повысить безопасность, мы используем несколько инструментов, которые помогают нам находить и устранять уязвимости ещё на этапе разработки. Рассказываем, как это работает.
Осторожно! На тексте об инструментах можно заскучать, если вы не технический специалист. Пропускайте этот блок, если хотите узнать о кейсах без сложных терминов.
Анализ используемых компонентов
Каждый раз, когда мы создаём новый элемент системы, мы проверяем, какие программные модули в нём используются:
- Инструмент cdxgen собирает список всех компонентов, которые есть в коде, и упаковывает его в специальный файл-отчёт SBOM в формате CycloneDX.
- Этот файл отправляется в Dependency-Track, который сравнивает его с базой известных уязвимостей. Если найдёт что-то небезопасное — сигнализирует нам.
Проверка исходного кода
- SemGrep сканирует программный код и ищет потенциальные уязвимости. Если найдена проблема — формируется отчёт.
- Все отчёты отправляются в DefectDojo — платформу, которая помогает нам отслеживать и исправлять ошибки.
Проверка контейнеров
В современных IT-системах используются контейнеры, например Docker, которые объединяют в себе код и необходимые зависимости. Мы проверяем, нет ли в этих контейнерах уязвимостей:
- Trivy анализирует каждый контейнер, находит потенциальные угрозы и создаёт отчёт.
- Отчёт передаётся в DefectDojo для удобного управления исправлениями.
Но нужно понимать: это решение не универсальное, потому что все проекты разные, а значит, задачи, условия и пожелания заказчиков — тоже. Например, не все компании готовы тратить большие ресурсы на безопасность, другие, наоборот, ставят безопасность в приоритет ещё на старте проекта. Мы сталкивались с разными ситуациями и рассказываем о самых частых задачах дальше на примерах кейсов в этой статье.
Почему соблюдение готовых стандартов безопасности проекта — непростая задача
Представим такую ситуацию: к нам за помощью приходит проект, у которого есть свои кибербезопасники и требования к информационной безопасности. С нас — выполнение задач в соответствии с этими стандартами.
Кажется, что в этом нет ничего сложного: мы выполняем задания по требованиям клиента — и это вся задача. Но не всё так просто. Рассказываем, в чём особенности такой работы, на примере кейса.
Как это было в MR Group
MR Group — девелопер недвижимости со своими приложением и сайтом, где можно оформить ипотеку и купить площадь. Через приложение проходит много персональных данных, например сканы паспортов и документы для оформления ипотеки. Проект с высоким уровнем безопасности, поэтому в штате компании есть свой кибербезопасник — он и задал стандарты, по которым мы работаем.
Ой! Здесь тоже много технических деталей. Пролистывайте два следующих абзаца, если хотите сразу узнать результат.
Перед каждым релизом мы проводим сканирование на уязвимости инструментами DefectDojo и Dependency-Track. Инструменты на выходе создают отчёты, где мы проверяем наличие критических уязвимостей и исправляем их, если они высокого уровня.
Для защиты от DDoS-атак используются сервисы фильтрации трафика. Чтобы минимизировать риски утечки персональных данных, среда тестирования полностью изолирована от продакшена. База данных синхронизируется с тестовыми средами специальным инструментом, который перед передачей очищает её от персональных данных.
На первый взгляд кажется, что прописанные стандарты безопасности упрощают работу: есть конкретные требования — бери и выполняй. Но на практике всё сложнее:
- Новые уязвимости появляются постоянно, а строгие стандарты не всегда покрывают актуальные угрозы. Поэтому даже при соблюдении всех требований компании мы дополнительно анализируем потенциальные риски и предлагаем клиенту доработки, которые выходят за рамки стандартного набора мер.
- Стандарты безопасности замедляют разработку. Например, если политика компании требует обязательного ручного согласования всех изменений — это может растянуть релиз на недели. В таких случаях мы помогаем оптимизировать процессы, автоматизировать проверки и интегрировать их в пайплайн разработки, чтобы безопасность не мешала скорости работы.
Со��людение стандартов — это не следование чек-листу, а постоянный баланс между безопасностью, удобством работы команды и техническими реалиями проекта.
Какое решение выбрать, чтобы не прогадать и повысить безопасность
Неважно, о каком бизнесе идёт речь: малом, среднем или крупном. Порой даже крупному бизнесу подходит одно недорогое решение, например грамотно настроенный сервис защиты от DDoS-атак.
Всё зависит от особенностей компании, и, пока мы не проверим, как работает инструмент, сложно говорить о его эффективности.
Как это было в McDonald’s
С McDonald’s мы работали долго: с нуля разработали для них сайт и приложение в 2019 году. Площадки были новыми, и на то время сеть ресторанов только начала развивать IT-инфраструктуру. Из-за этого стабильно раз в год происходили атаки и попытки взлома.
Тогда мы вместе с клиентом исследовали проблему: узнавали, как злоумышленники пытались получить доступ к конфиденциальной информации, искали уязвимости и решение, которое закроет проблему. Мы выбрали и настроили сервис защиты от DDoS-атак, он фильтровал плохой трафик.
Но для большого проекта этого решения было недостаточно, поэтому мы подключили DevOps-инженера, который проделал такую работу:
- Проанализировал текущую систему.
- Привлёк внешнюю компанию, которая специализировалась на анализе уязвимостей.
- Составил отчёт со списком всех уязвимостей — какие есть сейчас и какие могут быть в будущем.
- Составил бэклог задач на основе отчёта — задачи были направлены на устранение слабых мест.
Не всегда установка одной системы защиты решает проблемы с безопасностью. Чаще всего для крупного бизнеса простого решения недостаточно: чем больше данных проходит через платформу, тем выше риск атак и утечек. В случае с McDonald’s нам пришлось применить комплексный подход: объединить защиту от DDoS, провести аудит безопасности и доработать архитектуру.
Что делать, если проект не беспокоится о безопасности
Ответ один для всех компаний: ориентироваться на лучшие практики OWASP — открытого проекта по обеспечению безопасности веб-приложений. В последнем отчёте OWASP перечислены 10 основных уязвимостей: инъекции, нарушенная аутентификация, раскрытие критически важных данных, внешние объекты XML, нарушенный контроль доступа, неправильная конфигурация безопасности, межсайтовый скриптинг, небезопасная десериализация, использование компонентов с известными уязвимостями, недостаточно подробные журналы и слабый мониторинг.
Подходы, которые нужно использовать по стандарту, совместимы с любой нишей. В OWASP есть несколько уровней критичности, поэтому он покрывает больше, чем нужно многим проектам. Например, там описаны требования к хранению банковских данных, но не в каждой компании такие данные есть. Поэтому всем проектам, у которых нет строгих требований к безопасности, на старте мы предлагаем это решение.
Как это было у нашего клиента — интернет-магазина товаров для дома
У клиента не было требований к информационной безопасности, поэтому при написании кода мы руководствовались своим регламентом. Интернет-магазин крупный, и попытки хищения данных тоже были. Мы оперативно реагировали на них: вносили изменения в регламент работы и давали рекомендации хостинговым площадкам — формировали требования для третьих сторон, чтобы на проекте соблюдались стандарты безопасности.
Кейс показывает, что следовать одному фиксированному регламенту — провальная стратегия. Вопросы безопасности динамичны: угрозы эволюционируют, и злоумышленники находят новые лазейки. Часто приходится выходить за рамки привычных решений, как, например, в нашем случае: не просто усиливать защиту на стороне клиента, но и формировать требования к хостинговой площадке, чтобы минимизировать риски на всех уровнях.
Лучше закладывать бюджет и время на кибербезопасность на старте проекта. Многие клиенты думают, что это долго и дорого, хотя та же установка сервиса по защите от DDoS-атак занимает месяц и закрывает 80% проблем по этой части. Не откладывайте вопрос безопасности на потом: чем раньше заложены базовые механизмы защиты, тем меньше шансов столкнуться с утечками, простоями и потерей доверия клиентов.