Чеклист готовности проекта к размещению на Фабрике Сайтов#

  • Имеется AntiDDoS1 защита, проект может работать через неё или уже работает.

  • Оценена необходимость использования CDN2, имеются нужные настройки.

  • Предоставлена схема взаимодействия компонентов (архитектура, по примеру из вложения)3.

  • Доступ к интерфейсу администрирования может изменяться через настройки конфигурации4.

  • Предоставлен конфигурационный файл nginx с правилами location и другими параметрами (заголовки — если используются, отдельно location для интерфейса администрирования)5.

  • Приложение должно корректно работать с заголовками, обеспечивающими безопасность пользователей web-приложений. Заголовки, применяемые на Фабрике Сайтов по умолчанию, приведены в Таблице 1. В случае невозможности работы приложения с данными заголовками необходимо предоставить рабочие менее строгие настройки (это особенно вероятно с Content-Security-Policy), обязательно приложив обоснование необходимости применения менее строгих политик.

  • Обработка особых location, rewrite, redirect производится внутри приложения, а не выносится в конфигурацию nginx прокси Фабрики Сайтов.

  • Приложение не конфликтует с правилом реверс прокси:

    location ~* (\.(bak|config|sql|fla|psd|ini|log|sh|inc|swp|dist|git|.docker.config)|~)$ {return 403;}

  • Заявлен список внешних сервисов, интегрированных через межсерверное взаимодействие или взаимодействие браузера клиента и внешнего сервиса, указаны протоколы передачи и состав данных6.

  • Все необходимые для проекта SSL сертификаты предоставлены.

  • Контейнеры выдают корректные логи приложения (например, nginx — access.log, error.log), в соответствии с рекомендациями docker (stdout, stderr).

  • Инструкции для docker stack deploy предоставлены (docker-compose.yml файл с описанием сервисов)7.

  • Приложение и поставляемые контейнеры рассчитаны на работу в режиме swarm, общее хранилище данных (кеш, шаблоны, сессии) спроектировано с учётом масштабируемости.

  • Код проекта и промежуточное ПО настроены на получение IP клиента из заголовка X-Forwarded-For.

  • Конфигурация проекта вынесена и достаточна (например, в переменные окружения, docker config).

  • DevOps не управляет конфигурацией, которой может (должен) управлять контент-менеджер.

  • Предоставлена страница-заглушка для ошибок сервера (500) и для обновления сайта8.

  • В исходном коде выключен режим отладки, пользователю не выводятся сообщения с stacktrace или другими debug данными.

  • В контейнерах настроен healthcheck, основанный на бизнес логике.

  • Образы (images) для развёртывания внутри области проекта загружены на release.appworks.ru с тегом release.

  • Коды ответа приложения соответствуют общепринятым практикам9.

  • В процессе опытной эксплуатации не возникают ошибки 50х10.

Таблица 1. Заголовки для обеспечения безопасности пользователей веб-приложений, применяемые на Фабрике Сайтов по умолчанию#

Заговок

Рекомендуемое значение

X-Frame-Options

deny

X-Content-Type-Options

nosniff

X-Permitted-Cross-Domain-Policies

none

Cross-Origin-Resource-Policy

same-origin

Cross-Origin-Embedder-Policy

require-corp

Cross-Origin-Opener-Policy

same-origin

Content-Security-Policy

default-src 'self' data:; object-src 'none'; child-src 'self'; frame-ancestors 'none';  upgrade-insecure-requests; block-all-mixed-content

Вложения

1

Под AntiDDoS защитой предполагается проксирующий сервис с возможностью защиты от DDoS атак.

2

Если проект имеет медиафайлы, а посещаемость ожидается более 1000 человек, следует рассмотреть внедрение CDN. Технически, это вынесение контента на кеширующие сервера. Для сайта это означает, что у него должна быть возможность указать отдельное доменное имя для всех медиафайлов, и оно должно быть вынесено в конфигурационный файл.

3

Под архитектурой подразумевается перерисованный файл из вложения, на котором область в пунктирном квадрате (Область для сервиса/сайта) изменена в соответствии с архитектурой сайта. После предоставления схемы требуется обсудить технические подробности использования частей приложения для оценки использования имеющихся общих сервисов.

4

URI административного интерфейса должен меняться, если интерфейс имеет отдельный адрес. Например, example.com/admin-34fdc1t5, здесь изменяемая URI — 34fdc1t5, задаётся в настройках

5

Для настройки реверс-прокси должны быть предоставлены правила минимум для 2-х location: / и /admin-(.*), если административный интерфейс находится по этому адресу, а также другие важные настройки для приложения, например: заголовки, размер POST данных, запрет открытия url извне и пр.

6

К архитектурной схеме должно быть добавлено текстовое описание взаимодействий с внешними сервисами. Hапример: Google Recaptcha, Dadata, и пр.

7

Файл docker-compose.yml во вложении, в нём комментариями указаны важные моменты, а также рекомендуемые решения. Допустимо предложить другой подход, однако прежде чем его использовать — нужно провести обсуждение.

8

Заглушки должны представлять собой единичные файлы html с включёнными стилями, java-скриптами и встроенными картинками. В файл не должны быть включены излишние данные, только то, что необходимо для отображения. В частности, не следует внедрять шрифты, вместо этого нужно использовать общедоступные. Размер файла должен быть минимально возможным.

9

HTTP код ответа должен совпадать с результатом обработки запроса. Например, не должно быть ответа 50х, 30х, 20х для страниц, которых не существует — должен быть код 404.

10

Приложение не возвращает ошибки >= 500 при работе в стандартном режиме.