Условия информационной безопасности
Версия: 1.0
Дата вступления в силу: {{ДАТА}}
Дата последнего изменения: {{ДАТА}}
Постоянный адрес: /legal/security
1. Назначение и статус документа
1.1. Настоящие Условия описывают организационные и технические меры защиты информации, применяемые в сервисе DefAct.
1.2. Документ является приложением к Условиям обработки данных клиента (DPA) и к договору с Клиентом и раскрывает меры, предусмотренные разделом 10 DPA.
1.3. Документ описывает меры, применяемые фактически на дату указанной редакции. Меры, которые запланированы, но ещё не введены, перечислены отдельно в разделе 12 и не должны считаться действующими.
1.4. Оператор: Индивидуальный предприниматель Беляев Иван Васильевич, ОГРНИП {{ОГРНИП}}, ИНН {{ИНН}}, адрес: {{АДРЕС}}, e-mail: info@defact.pro.
2. Размещение и инфраструктура
2.1. Данные размещаются на собственном сервере Оператора на территории Российской Федерации. Арендованные облачные платформы для хранения данных Клиентов не используются.
2.2. Сервис состоит из приложения, базы данных PostgreSQL и обратного прокси-сервера, работающих в изолированных контейнерах на одном сервере.
2.3. Порт приложения привязан к локальному интерфейсу сервера и недоступен из сети. Обращения извне возможны только через обратный прокси-сервер.
2.4. Снаружи доступны только порты, необходимые для работы: 80 и 443 для веб-трафика и 22 для административного доступа. Межсетевой экран сервера включён.
2.5. Административный доступ к серверу осуществляется по протоколу SSH с аутентификацией по ключу.
3. Защита канала связи
3.1. Весь обмен данными между приложениями, веб-порталом и сервером выполняется по протоколу HTTPS.
3.2. Сертификаты выпускаются удостоверяющим центром Let's Encrypt и обновляются автоматически.
3.3. Обращения к сервису идут напрямую на инфраструктуру Оператора. Сторонние прокси-сервисы, подменяющие сертификат или расшифровывающие трафик, в схеме не участвуют.
3.4. Обратный прокси-сервер добавляет к запросу сведения об исходном адресе клиента. Приложение принимает такие сведения только от локального интерфейса и внутренних адресов, чтобы отправитель запроса не мог назвать произвольный адрес.
4. Аутентификация и учётные записи
4.1. Пароли не хранятся в открытом виде. Хранится результат вычисления криптографической функции bcrypt с индивидуальной солью для каждого пароля.
4.2. При регистрации выдаётся временный пароль. До его смены вход в личный кабинет ведёт на экран смены пароля, а синхронизация недоступна.
4.3. Доступ приложений к серверу выполняется по токену. Срок действия токена — 30 суток, после чего требуется повторный вход.
4.4. Формы личного кабинета и административной панели защищены от подделки межсайтовых запросов (CSRF-токен, связанный с сессией).
4.5. Публичная форма регистрации ограничена по частоте обращений.
4.6. Двухфакторная аутентификация в редакции 1.0 не применяется. См. раздел 12.
5. Разграничение доступа
5.1. Данные разных организаций изолированы. Принадлежность организации проверяется в каждом запросе к документам, справочникам, сотрудникам, файлам и подписям, а не только в интерфейсе.
5.2. Внутри организации действуют роли: администратор, контролёр, исполнитель. Членство в организации требует подтверждения администратором.
5.3. Документы разграничены по их автору. Исполнитель работает со своими документами; расширенный доступ определяется ролью.
5.4. Удаление записей справочника клиентов и сотрудников доступно только администратору. Контролёр и исполнитель вносят собственные данные.
5.5. Кабинет заказчика доступен только на просмотр и согласование. Редактирование документов заказчику недоступно.
5.6. Проверки прав выполняются на сервере. Отсутствие кнопки в приложении не рассматривается как мера защиты: приложение передаётся Клиенту в виде устанавливаемого файла.
6. Защита файлов
6.1. Фотографии, подписи и готовые документы хранятся в файловом хранилище, разделённом по организациям.
6.2. Файлы адресуются по криптографической контрольной сумме содержимого (SHA-256).
6.3. Выдача файла требует, чтобы у обратившегося была собственная запись, ссылающаяся на этот файл. Знания контрольной суммы недостаточно.
6.4. Отказ в выдаче не различает «файла нет» и «файл не ваш».
7. Резервное копирование
7.1. Ежесуточно создаётся локальная резервная копия базы данных и файлового хранилища. Хранятся пять последних копий.
7.2. Ежесуточно создаётся внешняя резервная копия, размещаемая вне сервера.
7.3. Внешние копии шифруются на стороне сервера средствами restic до отправки. Внешнее хранилище получает нечитаемые зашифрованные блоки и не располагает ключом.
7.4. Глубина хранения внешних копий: 7 суточных, 5 недельных и 12 месячных.
7.5. Еженедельно выполняется автоматическая проверка восстановления: последняя внешняя копия разворачивается в отдельную временную базу данных, и результат проверяется по составу восстановленных данных. Проверка не затрагивает рабочие данные.
7.6. Ежесуточно проверяется свежесть резервных копий; устаревание фиксируется в журнале операций.
8. Журналирование
8.1. Ведётся журнал обращений к веб-серверу: время, адрес обратившегося, запрошенный ресурс, код ответа и длительность обработки.
8.2. Журнал обращений хранится не более 30 суток и не более установленного объёма — в зависимости от того, что наступит раньше.
8.3. Ведётся журнал событий по документам: направление на согласование, согласование, отклонение, с указанием участника и времени.
8.4. Факты принятия правовых документов фиксируются отдельными неизменяемыми записями. Подробнее — в Правилах хранения и удаления данных.
9. Устройства и офлайн-данные
9.1. DefAct работает офлайн: документы создаются на устройстве и хранятся в локальной базе устройства до синхронизации.
9.2. Защита самого устройства (блокировка экрана, шифрование накопителя, ограничение доступа посторонних) находится в зоне ответственности Клиента и пользователя.
9.3. Прямой обмен между устройствами по локальной сети или кабелю требует ввода одноразового кода, показываемого на принимающем устройстве, и допускается только между устройствами, работающими с одной и той же компанией.
9.4. При смене пользователя на устройстве синхронизированные рабочие данные предыдущего пользователя с устройства удаляются.
10. Управление изменениями
10.1. Изменения серверной части и приложений покрываются автоматическими тестами, выполняемыми до развёртывания.
10.2. Миграции базы данных применяются до начала обслуживания запросов. При ошибке миграции сервис не запускается, вместо того чтобы работать на несогласованной схеме.
10.3. Доступность сервиса проверяется автоматически каждые 5 минут.
11. Инциденты
11.1. При выявлении инцидента информационной безопасности, затрагивающего данные Клиента, Оператор уведомляет Клиента по адресу электронной почты, указанному в договоре или в кабинете компании.
11.2. Срок и порядок уведомления определяются разделом 14 DPA.
11.3. Сообщения о предполагаемых уязвимостях и инцидентах принимаются по адресу info@defact.pro.
12. Меры, не введённые в редакции 1.0
Перечислено прямо, чтобы Клиент не рассчитывал на отсутствующее:
12.1. Двухфакторная аутентификация не применяется.
12.2. Установочные файлы для Windows не подписаны сертификатом издателя, сборка для macOS не нотаризована. Операционные системы предупреждают об этом при установке. Приобретение сертификатов запланировано.
12.3. Сервис работает на одном сервере. Горячего резерва, обеспечивающего продолжение работы при отказе оборудования, нет. Восстановление после отказа выполняется из резервных копий.
12.4. Круглосуточное дежурство персонала не организовано. Реакция на инциденты выполняется в рабочее время.
12.5. Сертификация по требованиям ФСТЭК России и аттестация информационной системы не проводились.
13. Изменение Условий
13.1. Оператор вправе изменять настоящие Условия при изменении архитектуры сервиса, состава мер защиты или требований законодательства.
13.2. Изменения, снижающие уровень защиты, доводятся до Клиента заблаговременно.
13.3. Актуальная редакция публикуется по адресу /legal/security.
14. История изменений
| Версия | Дата | Изменения |
|---|---|---|
| 1.0 | {{ДАТА}} | Первичная редакция |