Безопасность для одиночки — это не отдельный большой проект, а короткий список привычек, которые закрывают самые частые причины неприятностей: утёкший ключ, открытые данные, потерянная база и забытые обновления. Этот урок — минимум, который стоит сделать до того, как в продукт придут реальные люди со своими данными. Он не заменяет проверку специалистом, но убирает очевидное.
После урока вы сможете
- Проверить, что секреты не попадают в код, историю репозитория и журналы
- Настроить доступы по принципу «только необходимое» и включить двухфакторную защиту
- Сделать резервную копию и проверить восстановление из неё
- Составить для себя план действий на случай утечки ключа
Содержание
Секреты и ключи
Секрет — это пароль, ключ API, токен или строка подключения к базе. Правила короткие:
- ключи не лежат в коде и не попадают в репозиторий: приложение читает их из переменных окружения, локально — из файла
.env, закрытого в.gitignore; - в репозитории лежит только шаблон
.env.exampleбез значений; - в браузерную часть приложения не попадает ничего, кроме заведомо публичных значений;
- у каждой среды (разработка, рабочая версия) свои ключи.
Подробно, с примерами и проверкой на утечки, это разобрано в уроке Секреты и переменные окружения. OWASP в своём руководстве по управлению секретами также советует регулярно менять секреты, чтобы украденные учётные данные работали недолго.
Права доступа
Принцип наименьших привилегий: у человека, ключа и сервиса — ровно те права, которые нужны для работы. На практике:
- включите двухфакторную защиту во всех аккаунтах, где живёт продукт: почта, регистратор домена, хостинг, репозиторий, база, платёжный сервис;
- для сервисов, которым нужен доступ к вашей базе или хранилищу, создавайте отдельные ключи с ограниченными правами, а не используйте главный;
- если в продукте есть пользовательские данные, проверьте, что один пользователь не может прочитать или изменить данные другого. Для продуктов на базе как сервисе это критично, и это разобрано в уроке Доступ к данным в MVP.
Резервные копии и проверка восстановления
Резервная копия, из которой ни разу не пробовали восстановиться, — предположение, а не копия. Документация PostgreSQL называет три базовых подхода к копированию: дамп SQL, копирование файлов и непрерывное архивирование; управляемые сервисы баз обычно делают это за вас в рамках тарифа, но условия (как часто, как долго хранится, как восстановить) сверяйте на странице вашего поставщика.
Минимальный порядок действий:
- Выясните, делает ли ваш поставщик базы автоматические копии, как часто и сколько их хранит.
- Раз в неделю или перед крупным изменением делайте собственную выгрузку данных и храните её отдельно от основной среды.
- Раз в квартал проверяйте восстановление: разверните копию в отдельной тестовой среде и убедитесь, что приложение с ней работает.
- Запишите, сколько времени занимает восстановление, — это ваша реальная цифра, а не обещание.
Не забудьте про файлы пользователей: если они хранятся отдельно от базы, у них нужна своя копия.
Обновления зависимостей и журналы
Зависимости — это чужие библиотеки, на которых стоит ваш код. В них находят уязвимости, и если не обновляться, вы узнаете о них последним. Автоматизировать напоминания можно, например, через Dependabot на GitHub: он предлагает изменения в виде запросов на слияние, а обновления безопасности включаются отдельно. Применять предложения без запуска проверок не стоит — тесты нужны и для этого.
Журналы помогают разбираться с ошибками, но опасны, если в них попадают лишние данные. OWASP советует не записывать в журналы пароли, токены доступа, идентификаторы сессий, строки подключения к базе, ключи шифрования, платёжные данные и вообще чувствительные персональные данные. Пишите в журнал идентификатор записи и тип события, а не имя, телефон или текст сообщения. Что собирать и как реагировать, разобрано в уроке Мониторинг и логирование.
Если вы собираете персональные данные жителей Казахстана, сверьте с юристом требования закона о персональных данных: что такое согласие, как и где хранить данные и что говорить пользователю. В курсе мы этого не разбираем.
Что делать, если ключ утёк
Заранее продуманный порядок действий избавляет от паники.
- Отзовите ключ в кабинете поставщика сразу. OWASP прямо требует отзывать раскрытые ключи немедленно.
- Выпустите новый и обновите его в переменных окружения на хостинге.
- Проверьте журнал использования ключа у поставщика: были ли чужие обращения.
- Удалите ключ из места утечки: кода, истории, чата, журналов. Переписывание истории Git — вторичный шаг, после отзыва.
- Запишите, как это произошло, и закройте причину.
Если ключ дал доступ к персональным данным или деньгам — привлеките инженера или юриста, не откладывая.
Чек-лист
- Секреты не в коде, есть
.env.example - Двухфакторная защита везде
- Права ключей ограничены
- Проверено: пользователь A не видит данных пользователя B
- Есть копия данных и файлов, восстановление проверено
- Включены напоминания об обновлениях зависимостей
- В журналах нет паролей, токенов и персональных данных
- Записан план на случай утечки ключа
Что дальше
Следующий урок — запуск и первые пользователи. Если вы хотите, чтобы кто-то посторонний прошёл по чек-листу и проверил реальный продукт, посмотрите услугу технический аудит.