Безопасность и продакшен-деплой AI-кода: Nginx, Docker и SSL

Написать работающий прототип с помощью AI — это только половина дела. Настоящая коммерческая зрелость разработчика проявляется в том, как этот продукт доставляется до конечных пользователей. Если ваш сервис падает при первой нагрузке или позволяет любому злоумышленнику выкачать базу клиентов через незащищенный эндпоинт, ни один серьезный заказчик не заплатит за такую работу.

Языковые модели часто склонны генерировать код с «детскими» уязвимостями: жестко прописанные секреты в репозитории, отсутствие валидации входящих параметров или отключенный CORS. Разберем, как построить безопасную инфраструктуру.

1. Полная контейнеризация через Docker Compose

Никаких установок Node.js и PostgreSQL прямо в хостовую систему Linux! Каждый коммерческий сервис должен быть изолирован в собственном контейнере:

  • Сервер приложения (API) запускается под непривилегированным пользователем;
  • Порт базы данных (5432) никогда не пробрасывается наружу (доступен только во внутренней docker-сети);
  • Используется restart policy always или unless-stopped для защиты от непредвиденных падений.

2. Реверс-прокси Nginx и автоматический SSL

Nginx принимает внешний трафик на портах 80 и 443, берет на себя терминацию TLS-шифрования и проксирует запросы во внутренний контейнер приложения:

/etc/nginx/conf.d/app.conf (Reverse Proxy Snippet)
server {
    listen 443 ssl http2;
    server_name myapp.domain.ru;

    ssl_certificate /etc/letsencrypt/live/myapp.domain.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.domain.ru/privkey.pem;

    # Защитные заголовки
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    server_tokens off;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

3. Безопасное хранение ключей API и токенов

Никогда не добавляйте файл .env в систему контроля версий Git. В репозитории должен лежать только .env.example с пустыми значениями. На сервере секреты передаются через защищенные переменные окружения или хранилище секретов.

Важно: Всегда настраивайте пре-коммит хуки (gitleaks или trufflehog), чтобы случайно сгенерированный коммит с боевым токеном Telegram-бота или ключом OpenAI не утек в открытый репозиторий.

4. Итоговый чек-лист деплоя

  1. Сервер защищен: SSH по паролю выключен, вход только по ed25519/rsa ключам.
  2. Фаервол UFW активен: открыты только порты 22, 80, 443.
  3. Certbot настроен на автопродление сертификатов каждые 60 дней.
  4. Служба приложения настроена на автоматический перезапуск через Docker daemon.

Рекомендуем к прочтению: