Безопасность — это то, о чём никто не думает, пока не стало поздно, особенно в небольших проектах.

📌 Такие проекты проходят одни и те же стадии:1️⃣ «Зачем париться, у нас маленький проект» 2️⃣ «Кому мы вообще нужны?» 3️⃣ «Ну, что-то сломалось, но не критично» 4️⃣ «Мы наняли юристов, но уже поздно…»

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

📌 Как сделать проект безопасным с самого начала? Дисклеймер: В этом посте разберём базовые принципы безопасности. Это фундамент, без которого нельзя строить надёжную систему. Углубленный разбор – темы для отдельных постов.

1. Доступы должны быть только у тех, кому они реально нужны

❌ Ошибка: у всех разработчиков есть полный доступ ко всему, включая прод. ✅ Как правильно: 🔹 Управление доступами через централизованную систему (например, Keycloak). Обязательно разграничивать уровень доступа по ролям. 🔹 Доступ к проду только у ограниченного списка сотрудников. 🔹 Вход на серверы — только через SSH-ключи, без паролей. 🔹 Для критичных операций — обязательная OTP-авторизация. 🔹 Удалённый доступ — только через VPN (например, OpenVPN), без открытых SSH-портов.

2. Критично важные данные должны быть зашифрованы

❌ Ошибка: данные передаются и хранятся без дополнительной защиты, шифрование реализовано формально или отсутствует вовсе. ✅ Как правильно: 🔹 Шифруем конфиденциальные данные (ФИО, паспортные данные, платежную информацию) с использованием ГОСТ стандартов. 🔹 Обеспечиваем защищённую передачу данных: используем TLS 1.3, проверяем настройку HTTPS и сертификатов. 🔹 Шифруем базы данных на уровне хранилища 🔹 Разграничиваем доступ к зашифрованным данным: ключи шифрования храним отдельно от основной базы, например, можно использовать HashiCorp Vault.

3. API должны быть защищены ❌ Ошибка: API принимает запросы от кого угодно, данные можно получить без авторизации. ✅ Как правильно: 🔹 Авторизация на всех уровнях: используем JWT, OAuth2. 🔹 Ограничиваем частоту запросов (Rate Limit) на уровне веб-сервера или API-шлюза (например, nginx rate limit). 🔹 Настраиваем защиту от перегрузки API: лимитируем глубину запросов в GraphQL и ограничиваем payload в REST API. 🔹 Разделяем публичные и внутренние API, внутренние скрываем за VPN или закрытой сетью. 🔹 Используем API Firewall для фильтрации запросов и защиты от атак (SQL-инъекций, XSS, SSRF).

4. Код-ревью с фокусом на безопасность ❌ Ошибка: ревью проводят только на чистоту кода, но не на потенциальные дыры. ✅ Как правильно: 🔹 Включаем автоматическое сканирование кода на уязвимости на этапе CI/CD. 🔹 Обязательное ревью с анализом возможных атак: SQL-инъекции, XSS, CSRF, утечки данных. 🔹 Внедряем политики pre-commit для предотвращения коммитов с паролями и токенами. 🔹 Регулярно проводим аудит кода и тестируем уязвимости в реальных сценариях.

5. Sandbox для запуска подозрительных файлов и команд ❌ Ошибка: Загружаемые пользователями файлы сразу попадают в систему без проверки, создавая риск заражения. ✅ Как правильно: 🔹 Изолируем выполнение подозрительных файлов в защищённой среде перед обработкой. 🔹 Анализируем содержимое загружаемых данных на предмет вредоносного кода. 🔹 Ограничиваем доступность исполняемых файлов и контролируем их поведение в песочнице. 🔹 Автоматически блокируем загрузку и выполнение файлов с потенциальными угрозами.

6. Web Application Firewall (WAF) и защита от бот-атак ❌ Ошибка: Сервер открыт для любых запросов, боты и злоумышленники могут перегружать систему или пытаться взломать аккаунты. ✅ Как правильно: 🔹 Настраиваем WAF для фильтрации вредоносного трафика и защиты от атак . 🔹 Внедряем защиту от DDoS-атак с автоматическим выявлением аномального трафика.

Вывод: ✅ Безопасность – это не «потом», а с первого дня разработки. ✅ Чем раньше заложены правильные практики, тем меньше проблем будет в будущем. ✅ Не надо быть крупной корпорацией, чтобы стать жертвой взлома – атаки происходят каждый день.