Платформа Налоговый мониторинг...СУБД 1 PostgreSQL 9.6 и выше 2...

Платформа Налоговый мониторинг

Техническое описание Версия 2.1

на 29 листах

г. Москва

2019 г.

Платформа Налоговый Мониторинг. Техническая архитектура. Версия 2.1 Стр. 2 из 29

Оглавление

1 Термины и определения ............................................................................................. 3

2 Общие сведения ............................................................................................................ 4

2.1 Назначение документа ....................................................................................... 4

2.2 Назначение Платформы Налоговый мониторинг ........................................ 4

3 Ролевая модель системы ............................................................................................. 5

3.1 Роли пользователей ............................................................................................ 5

3.2 Доступ пользователей к системе ...................................................................... 7

4 Техническая архитектура системы ............................................................................ 8

4.1 Подход к построению архитектуры ................................................................. 8

4.2 Схема технической архитектуры .................................................................... 10

4.3 Структурная схема компонентов .................................................................... 13

4.3.1 Потоки данных между компонентами и смежными системами16

4.3.2 Сервис интеграции с информационными системами ................ 18

4.3.3 Файловый сервис ................................................................................. 19

5 Схема развертывания системы ................................................................................ 20

5.1 Ландшафт системы ............................................................................................ 20

5.2 Установка/ обновление системы .................................................................... 20

5.3 Требования к оборудованию в минимальной конфигурации ................ 22

5.4 Требования к настройке сетевых взаимодействий .................................... 23

6 Нефункциональные требования ............................................................................. 26

6.1 Обеспечение требований к быстродействию ............................................. 26

6.2 Обеспечение требований к высокой готовности к балансировке ......... 26

6.3 Обеспечение требований к надёжности ...................................................... 27

6.4 Обеспечение требований к информационной безопасности ................. 27

6.5 Дополнительные меры для повышения безопасности веб-приложений .............................................................................................................................. 28


1 Термины и определения Таблица 1 - Термины и определения

№ Термин Определение 1 Налоговый

мониторинг/ НМ Вид налогового контроля, который применяется с согласия и по заявлению налогоплательщика. Особенность налогового мониторинга в том, что налоговый орган имеет доступ к финансовой информации на постоянной основе. Налоговый мониторинг регулируется Разделом V.2. Налогового кодекса Российской Федерации (НК РФ) "Налоговый контроль в форме налогового мониторинга"

2 Витрина данных/ ВД

Внешняя по отношению к ERP система, выполняющая функции отображения данных (отчетов, первичных документов) для внешних пользователей (сотрудников налоговой инспекции)

3 Платформа Налоговый мониторинг/ система

Программное обеспечение (ПО), разрабатываемое Mail.ru Group, для целей выполнения требований НМ по предоставлению налогоплательщиком доступа налоговому органу в режиме ВД

4 Пакет отчетности Набор документов по одному виду налоговой отчетности: налоговая декларация, налоговые регистры, подтверждающие документы, протоколы проведения контрольных процедур

5 Версия раскрытия Пакет отчетности, опубликованный налогоплательщиком в витрине данных

6 Раскрытие показателей

Возможность расшифровки показателей отчетов через показатели других отчетов более низкого уровня

7 Хеш-сумма Контрольная сумма – результат фиксации среза данных по опубликованной версии раскрытия

8 ПУД Первичные учетные документы 9 НСИ Нормативно-справочная информация 10 ПО Программное обеспечение


2 Общие сведения

2.1 Назначение документа

В настоящем документе приведено описание технической архитектуры Платформы Налоговый мониторинг с детальным описанием структурной схемы компонентов системы, схемы развёртывания системы и подходов к обеспечению нефункциональных требований.

2.2 Назначение Платформы Налоговый мониторинг

Платформа Налоговый мониторинг – это высокопроизводительное ПО, позволяющее автоматизировать процессы информационного взаимодействия с налоговым органом и в режиме реального времени раскрывать налоговую и бухгалтерскую информацию в удобном интерфейсе, разработанном от потребностей пользователя и для пользователя.

Платформа Налоговый мониторинг также содержит широкий перечень дополнительных преимуществ, которые позволят пользователю сфокусироваться на управленческом контроле налоговой функции, за счет автоматизации рутинных процессов.

Детальная информация о функциональных возможностях Платформы Налоговый мониторинг приведено в отдельном документе «Функциональное описание продукта_Платформа Налоговый мониторинг».


3 Ролевая модель системы

3.1 Роли пользователей

Система имеет гибкую ролевую модель, позволяющую настраивать различные роли в зависимости от потребностей компании. В Платформе предусмотрены следующие базовые роли пользователей:

• Сотрудник налогового органа (НО);

• Сотрудник налогоплательщика (НП);

• Аналитик ИТ;

• Администратор.

В таблице ниже приведено описание ролей с указанием доступных функций и требуемой квалификации эксплуатационного персонала.

Таблица 2 - Эксплуатационный персонал системы

Роль Доступные функции Требуемая

квалификации Администратор • Настройка, диагностирование,

оперативный контроль и оптимизация загрузки аппаратных средств системы.

• Резервное копирование компонентов системы.

• Восстановление компонентов системы. • Оперативный контроль и

администрирование программно- аппаратного комплекса (далее – ПАК) системы, восстановление функционирования ПАК при возникновении внештатных ситуаций.

• Идентификация проблем, возникших у пользователей системы, связанных как с функционированием аппаратных и базовых программных средств, так и с сетевой инфраструктурой.

• Управление настройками безопасности системы.

• Оптимизация и конфигурация настроек серверов.

• Обеспечение загрузки данных с помощью процессов (при необходимости).

• Обновление системы.

Опытный пользователь ПК.

Квалификация администратора: необходимы навыки работы с оборудованием и программным обеспечением, используемым в системе.


Роль Доступные функции Требуемая квалификации

Сотрудник, НО

• Просмотр/ проверка данных пакета отчетности до уровня детализации в соответствии с правами доступа.

• Построение отчетов/ диаграмм по опубликованной версии раскрытия.

• Сравнение версий раскрытия в рамках одного пакета отчетности.

• Запрос данных по ПУД. • Запрос информации в техническую

поддержку. • Запрос информации/ документов в адрес

НП.

Рядовой пользователь ПК

Сотрудник НП

• Загрузка данных в систему. • Просмотр/проверка данных пакета

отчетности до уровня детализации в соответствии с правами доступа.

• Анализ КС, загруженных данных, предоставление комментариев.

• Публикация версии раскрытия в адрес, НО. • Построение отчетов/ диаграмм по

загруженной/ опубликованной версии раскрытия.

• Запрос информации в техническую поддержку.

• Ответы на запросы НО, запросы на разъяснения в адрес НО.

Рядовой пользователь ПК

Аналитик ИТ

• Контроль целостности загруженных данных.

• Решение технических вопросов. Подключение новых пользователей.

• Настройка и разработка новых отчетов по требованиям компании.

Опытный пользователь ПК


3.2 Доступ пользователей к системе

Доступ пользователей к системе осуществляется через современный браузер с использованием следующих инструментов:

• Сотрудники НП, Аналитик ИТ, Администратор получают доступ к системе по протоколу HTTPS внутри корпоративной сети;

• Сотрудники, НО подключаются через VPN к защищенному контуру компании, после чего подключаются к системе по протоколу HTTPS.

Базовый вариант системы рассчитан на одновременную работу не более 100 пользователей. При этом система способна обеспечить одновременную работу неограниченного количества пользователей, при условии достаточного количества вычислительных мощностей.


4 Техническая архитектура системы

4.1 Подход к построению архитектуры

Архитектура Платформы представляет собой классическую трехзвенную модель, состоящую из трех слоев: веб-клиента, приложений и хранения данных.

Рисунок 1. Трехзвенная архитектура

В таблице ниже представлено описание/назначение каждого слоя и требования к программному обеспечению для корректного функционирования.

Таблица 3 - Назначение слоев трехзвенной модели

№ Слой Назначение ПО 1 Веб-клиент Слой представления. Используется для

графического отображения интерфейса конечным пользователям системы. Веб-приложение является тонким клиентом и не требует обновления страницы для перехода между экранами.

- ОС: Linux, Windows 7-10, MacOS; - Браузеры: Microsoft Interne;t Explorer v11, Google Chrome; - Основные технологии: Javascript (React.js).

2 Приложения Слой приложений. Используется для обработки данных, вычислений и расчетов. Приложения включают сервисы для выполнения основной бизнес-логики системы и хранилища оперативных данных в памяти (кэш).

- ОС: Linux; - Основные. технологии: Tarantool, Go.

3 Хранение данных

Слой хранения данных. Используется для хранения данных и файлов. Компоненты

- ОС: Linux; - Основные. технологии:


№ Слой Назначение ПО данного слоя не зависят от компонентов вышележащих слоев.

PostgreSQL, Jatoba, PostgresPro.

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

• Слой приложений имеет сервисно-ориентированную архитектуру, что позволяет входящим в состав сервисам реализовать независимую функциональность. Такой подход позволяет обеспечить модульность, расширяемость, возможность частичного развертывания, высокую доступность, мультиплатформенность, независимую доработку компонентов (подсистем);

• Модульная структура системы позволяет сделать ее геораспределенной, гибко настроить сценарии отказоустойчивости и репликации данных. Ключевые компоненты имеют резервные экземпляры, переключение на которые осуществляется средствами балансировщика.


4.2 Схема технической архитектуры

Схема технической архитектуры Платформы Налоговый мониторинг представляет взаимосвязь функциональных и вспомогательных компонентов системы. Такая система поддерживает любые сервера общего назначения с архитектурой “x64”.

Рисунок 1. Схема технической архитектуры

В таблицах ниже представлено описание используемых функциональных и вспомогательных компонентов, а также требования к используемым версиям.

Таблица 4 - Описание функциональных и вспомогательных компонентов Платформы

№ Слой Компонент Характеристики Функциональные компоненты 1 Веб-клиент Веб-приложение Реализовано на языке javascript с помощью

библиотеки React.js.

2 Веб-клиент Шлюз доступа (http-сервер)

Обмен данными между компонентами на транспортном уровне осуществляется по протоколу TCP, на прикладном уровне - по бинарным протоколам и/или протоколам HTTP/HTTPS. Для балансировки нагрузки при размещении компонентов на разных серверах приложений используется балансировщик nginx (для распределения нагрузки между серверами при горизонтальном масштабировании системы).

DEV/TEST/UAT/PROD

Клиентское веб-приложение (React.js)Frontend

ЛК НО ЛК НП РМ Администратора

Load balancer Proxy TLS

Шлюз доступа (nginx)Data source ERP КХД

App (Go) Сервис раскрытия

налоговых показателей

Сервис НСИ

Сервис взаимодействия с НО

Сервис унифицированного

API для ИС НО

Сервис уведомлений Сервис интеграции

Сервис СВК и управления рисками

Сервис налогового прогнозирования

Сервис аналитической отчетности

Сервис бизнес правил

Сервис поиска Сервис регистрации и учета

Сервис расчета налогов

Сервис мотивированных

мнений

Сервисконфигурирования

метамоделиСервис базы знаний Файловый сервис Сервис управления

доступом

DB SecurityАрхивная СУБД

(PostgreSQL)Основная СУБД

(PostgreSQL)Файловое хранилище

(Ext4/Ceph/MCS S3)

Оперативный кэш + очереди сообщений

(Tarantool)

Внешние компоненты, сертифицированные ФСТЭК

Monitoring Ci/CDELK Prometheus Grafana Gitlab CI Ansible

Infra

or or or

OS Linux (Astra Linux Special Edition, Red Hat, CentOS. Debian, Ubuntu)

Bare metal Virtual machines Docker Kubernetes

Функциональный компонентВспомогательный компонентВнешняя информационная система


3 Приложения Сервисы Реализовано на языке программирования GO. Сервисы собираются в бинарные модули, которые не требуют внешних зависимостей (например, таких как JRE), что позволяет сократить необходимые для функционирования аппаратные ресурсы.

4 Хранения данных

СУБД В качестве основной СУБД используется свободно распространяемая версия PostgreSQL. В случае если требуется поддерживаемая версия PostgreSQL, то необходимо приобрести лицензии от следующих производителей:

1) PostgresPro 2) Jatoba

Компоненты СУБД системы могут быть размещены как на одном сервере, так и на нескольких, используя механизмы репликации и шардирования. Также при больших объемах данных хранилище может быть отмасштабировано путем разделения на оперативное и архивное.

5 Хранения данных

In-memory СУБД Используется in-memory СУБД Tarantool для оперативного кэш и очереди сообщений.

6 - Операционная система

Для работы серверных компонентов используется одна из следующих ОС Linux последних версий:

1) Astra Linux® Special Edition; 2) Red Hat; 3) CentOs; 4) Debian; 5) Ubuntu.

7 - Развертывание инфраструктуры

Для размещения компонентов используются один из следующих способов: • Железные сервера (Bare metal); • Системы виртуализации (Virtual machines):

Vmware, Openstack или Mail.ru cloud solutions;

• Контейнеры: lxc или Docker; • Оркестратор: Kubernetes.


Вспомогательные компоненты 8 - Централизованное

хранилище логов Используется ELK (Elasticsearch, Logstash, and Kibana).

9 - Система мониторинга

В качестве системы мониторинга используется Prometheus. В качестве дэшбордов состояния системы используется Grafana.

10 - CI/CD В качестве системы развертывания (CI) используются GitLab CI. В качестве систему вправления конфигурациями (CD) используется Ansible.

11 - Информационная безопасность

Используются внешние сертифицированные компоненты, которые позволяют использовать систему до класса 1Г включительно. Список дополнительных компонентов ИБ может быть изменен, в зависимости от требуемого класса защищенности.

Таблица 5 - Требования к используемым версиям функциональных компонентов

№ Компонент Версия Комментарий Шлюз доступа (http-сервер) 1 Nginx 1.10.3-1 и выше СУБД 1 PostgreSQL 9.6 и выше 2 Postgres Pro Enterprise 10.3.3 и выше Сертификат ФСТЭК 3 Jatoba 1.0 и выше

In-memory СУБД 1 Tarantool 2.2 и выше Операционная система 1 Astra Linux® Special Edition 1.6 и выше Сертификат ФСТЭК, МО, ФСБ 2 Debian 9.10 и выше 3 Red Hat Enterprise Linux 7.4 и выше 4 CentOS 7.4 и выше 5 Ubuntu 16.04 LTS и выше

Таблица 6 - Требования к используемым версиям вспомогательных компонентов

№ Компонент Версия Централизованное хранилище логов 1 ELK (Elasticsearch, Logstash, Kibana) 7.5.0 и выше Система мониторинга 1 Prometheus 2.14.0 и выше


№ Компонент Версия 2 Grafana 6.5.2 и выше

CI/CD 1 GitLab CI 12.5 и выше 2 Ansible 2.5.5 и выше

4.3 Структурная схема компонентов

Структурная схема Платформы Налоговый мониторинг декомпозирует компоненты системы по функциональному признаку.

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

Каждый компонент сохраняет свои данные в отдельной схеме СУБД. Такой подход позволяет разнести базы компонентов по разным экземплярам СУБД.

Рисунок 2. Структурная схема компонентов


В таблицах ниже представлено назначение/ описание компонентов структурной схемы, а также требования к программному обеспечению для корректного функционирования.

Табл. 1 Описание компонентов структурной схемы

№ Компонент Назначение ПО 1 Web app Веб-приложение, является тонким клиентом

и не требует обновления страницы для перехода между экранами.

Браузеры: Microsoft Internet Explorer v11, Google Chrome, Технологии: Javascript (React.js).

2 Gateway Шлюз, предоставляющий доступ к API для клиентского приложения. Доступ к методам API защищен авторизацией. Также данный шлюз выступает в роли балансировщика нагрузки и прокси сервера. Выполняет следующие виды шифрования трафика:

• http -> https; • ws (Web Socket) -> wss.

Nginx

3 Integration service

Сервис управления интеграциями, в том числе для ведения журнала обмена данных. Доступны следующие сервисы:

• Adapter ERP - интеграционный адаптер к учетной системе Заказчика;

• Adapter FS - интеграционный адаптер к файловому хранилищу Заказчика;

• Normalizer - сервис проверки и обогащения данных, получаемых из внешних систем.

Go

4 App Core Сервис для реализации основной бизнес-логики: • Обработка данных по налоговой

отчетности из СУБД; • Сохранение рассчитанных агрегатов в

оперативной памяти для ускорения доступа;

• Предоставление доступа к данным из пользовательского интерфейса.

Доступные следующие сервисы:

• Log service – сервис сбора событий о действиях пользователей, позволяет администратору просматривать события;

Tarantool, Go


№ Компонент Назначение ПО • Message service – сервис информационного

обмена между пользователями системы; • Search service - сервис полнотекстового

поиска. • Auth service - сервис авторизации, в том

числе с AD компании. Предназначен для ведения списка пользователей системы, ролевой модели и хранения сессии пользователей;

• Notify service - сервис уведомлений для отсылки уведомлений клиентскому приложению через Web socket или рассылки почты через SMTP (необходимо наличие почтового сервера в контуре компании или размещение собственного SMTP-сервера) и sms (необходим sms gate).

5 DBMS СУБД, основное хранилище системы. Предназначено для хранения учетных данных, полученных из внешних систем, а также данных для работы функциональных сервисов. Содержит следующие базы данных:

• DB Logs – журнал действий пользователей; • DB Notify – уведомления и настройки; • DB SAF-T – налоговые данные; • DB Auth - пользователи, роли, сессии; • DB Messages - данные информационного

обмена пользователей; • DB Integration – настройки интеграции,

данные для проверки; • DB UI - настройки пользовательского

интерфейса; • DB FS - метаданные файлового хранилища.

Указанные базы данных могут располагаться как на одном экземпляре СУБД, так и на разных.

PostgreSQL, Postgres Pro, Jatoba

6 File Service Сервис хранения файлов, как собственных, так и полученных из внешних систем. Также служит для хранения временных файлов; Хранилище - объектное, таким образом, доступ предоставляется только через интерфейс системы.

Go

7 Active Directory

Внешняя система. Корпоративная система авторизации компании

8 ERP Внешняя система. Корпоративная учетная система компании


№ Компонент Назначение ПО 9 КХД Внешняя система. Корпоративное файловое

хранилище компании

10 Sms gate Внешняя система. Сервер для отправки смс 11 Smtp server Внешняя система. Почтовый сервер для рассылки

уведомлений по почте

4.3.1 Потоки данных между компонентами и смежными системами

Компоненты взаимодействуют между собой по протоколу http, в том числе при размещении на одном хосте. В таблице ниже представлено описание потоков данных между компонентами и смежными системами.

Таблица 2 - Потоки данных

№ Смежная система - источник

Компонент - приемник

Состав данных

1 Active Directory App Core Пользователи, зарегистрированные в AD, и их привилегии, токены

2 ERP Integration service

Данные пакетов налоговой отчётности

3 КХД Integration service

Первичные учетные документы компании

4 Integration service DBMS Учетные данные, расписания, правила обработки

5 Integration service File Service Первичные учетные документы 6 Integration service Gateway Расписание, статусы, файлы для

предпросмотра 7 Integration service App Core Проверка прав для запроса 8 App Core Gateway Сессия пользователя, список

пользователей и их роли, push уведомления, ответы на запросы

9 App Core DBMS Пользователи, роли, сессии, уведомления, настройки уведомлений

10 App Core File Service Файлы для сохранения 11 App Core Integration

service Разрешения на запросы

12 App Core Active Directory Запросы на получение пользователей и токенов

13 App Core Smtp server Почтовые уведомления 14 App Core Sms gate СМС уведомления 15 Gateway Web app Данные для веб-интерфейса 16 Gateway Integration

service Управляющие команды

17 Gateway App Core Запросы на получение данных, управляющие команды

18 Gateway File Service Файлы для загрузки 19 DBMS Integration

service Расписание интеграций, правила интеграций


№ Смежная система - источник

Компонент - приемник Состав данных

20 DBMS App Core Результаты запросов 21 DBMS File Service Метаданные о файлах 22 File Service App Core Файлы 23 File Service Gateway Файлы 24 File Service Gateway Файлы 25 File Service DBMS Метаданные о файлах


4.3.2 Сервис интеграции с информационными системами

Сервис интеграции принимает данные из учетных систем и КХД компании и ведет журнал обмена данных. Для интеграции с информационными системы в Платформе предусмотрены следующие компоненты:

• Коннекторы к учетным системам/КХД;

• Унифицированный API для загрузки данных в формате SAF-T;

• Компонент трансформации данных в каноническую модель данных.

Рисунок 3. Структурная схема сервиса интеграции

В таблице ниже представлен список систем, с которыми разработан/ разрабатывается сервис интеграции и актуальный статус разработки коннекторов на момент подготовки настоящего документа.

Таблица 3 - Типы систем для настройки интеграции

№ Тип системы Система Статус разработки коннектора

1 ERP-системы Oracle ERP Разработан 2 ERP-системы SAP R/3, SAP ERP В процессе разработки 3 ERP-системы 1С В процессе разработки 4 ERP-системы Галактика ERP 9.1 В процессе разработки 5 ERP-системы Epicor ERA Financials В процессе разработки 6 КХД IBM FileNet В процессе разработки 7 КХД IBM Lotus В процессе разработки


№ Тип системы Система Статус разработки коннектора

8 КХД DocsVision, В процессе разработки 9 КХД MS SQL Server FileStream В процессе разработки

10 КХД Directum В процессе разработки 11 КХД SAP Content Server В процессе разработки

4.3.3 Файловый сервис

Для возможности ручной загрузки файлов без необходимости настройки интеграционных сервисов в Платформе реализован специальный файловый сервис для хранения любых файлов. Доступны следующие варианты размещения файлового сервиса:

1) Установка поверх дисковой системы с доступом к другим сервисам через API

Такой вариант предполагается в случае, если основным хранилищем файлов является КХД, а в самой Платформе объем хранимых файлов незначителен.

2) Установка Объектного хранилища (S3) в контур компании1

Такой вариант предполагается в случае хранения всех файлов в Платформе при условии, что объем хранимых данных существенен. В таком случае возникают дополнительные требования по надежности, масштабированию и доступности.

1 Объектное хранилище S3 от производителя Mail.ru cloud solutions


5 Схема развертывания системы

5.1 Ландшафт системы

Платформа Налоговый мониторинг может быть развернута в нескольких контурах, при этом количество контуров может варьироваться в зависимости от потребностей компании:

• DEV – контур разработки, используется, если необходима кастомизация системы;

• TEST – контур тестирования, используется для тестирования системы;

• UAT – контур пользовательского тестирования;

• PROD – контур продуктивной среды.

5.2 Установка/ обновление системы

Установка/обновление системы, в том числе в контуры разработки и тестирования, осуществляется инструментами развертывания (GitLab CI, Ansible):

• Компоненты системы размещаются в инфраструктуре компании;

• Для уменьшения единиц развертывания компоненты системы на этапе сборки собираются в объединенные сервисы;

• В качестве контейнеров для инсталляции компонентов используются виртуальные машины VMWARE. Также компоненты системы могут быть развернуты в Docker контейнерах с использованием оркестратора Kubernetes.

Для обеспечения отказоустойчивости в продуктивной среде (PROD) необходимо дублировать только сервера СУБД. Сервер приложений допустимо не дублировать ни в режиме горячего резерва, ни в случае его падения.

Для сервера приложений допустим простой сервис, который позволяет выполнить запуск нового экземпляра сервера приложений на новых мощностях.

Сервера СУБД разделены по ролям, к каждой из которых обращаются компоненты системы, в зависимости от требуемых данных:

• Master (запись и чтение);

• Slave (только чтение).

Сервера СУБД используют SSD диски для более быстрой обработки запросов.

Взаимодействие машин происходит через LAN, пропускная способность должна быть не менее (1 Гб/с). Клиентские АРМ находятся в той же LAN, либо подключены через VPN (для, НО).


На рисунке ниже представлена схема развертывания в минимальной конфигурации, сами требования к оборудованию в минимальной конфигурации приведены в разделе 4.1 настоящего документа.

Рисунок 4. Схема развёртывания в минимальной конфигурации


5.3 Требования к оборудованию в минимальной конфигурации

В таблице ниже представлены минимальные требования к оборудованию для корректного функционирования системы на серверах (виртуальных машинах). Таблица 4 - Требования к аппаратным ресурсам серверов

Сервер Назначение Процессор, ядра

Память, ГБ

HDD, ГБ

SSD, ГБ

Комментарий ПО

nm.app.node1

Сервер приложений

8 64 500

Выполняет основную работу по расчету бизнес логики

Nginx, Tarantool, Go

nm.db.node1

СУБД master 8 64 6000

СУБД. Хранит информацию полученную из смежных за текущие 5 лет

PostgreSQL, PostgresPro, Jatoba

nm.db.node2

СУБД slave 8 64 6000

СУБД. Реплика.

PostgreSQL, PostgresPro, Jatoba

nm.infra.node1

Инфраструктурные сервисы

2 4 50

Используется один сервер на три зоны

Gitlab CI, Ansible

СУБД backup 3000

СХД. Бэкап СУБД , подмонтируется к db серверу

Файловое хранилище

1000

СХД. Подмонтируется к app серверу для сервиса file service

Итого 26 196 4050

12500


Используемый подход к расчету требований к объему дисков SSD:

Для сервера приложений

• Для обеспечения скорости работы сервер приложений содержит необходимые для работы данные в оперативной памяти;

• SSD диск необходимо для хранения снапшотов оперативной памяти и вспомогательной информации.

Для СУБД

• Объем хранимых данных в СУБД за 1 год ~ 700 ГБ, с учетом возможного роста до 1 ТБ;

• Для обеспечения скорости работы требуются SSD диск объемом 6 ТБ, из расчета: 1 ТБ*5 лет = 5 ТБ (плюс 1ТБ резерв).

5.4 Требования к настройке сетевых взаимодействий

В таблице ниже представлены требования к сетевым взаимодействиям (как меж-серверным, так и клиент-серверным), которые необходимо настроить для функционирования системы.


Табл. 5 Сетевые взаимодействия

№

Наименование и IP

инициатора (source)

Наименование и IP назначения

(destination)

Сетевой протокол, по которому

осуществляется обращение до destination IP

Сетевые порты, по которым


Передача персональных

данных (Да/Нет)

1 Пользователи nm.app.node1 tcp 80, 443 нет

2 Администраторы, разработчики, тестировщики

nm.app.node1 tcp 22, 5000-6000 нет


nm.db.node1 tcp 22, 5000-6000 нет


nm.db.node2 tcp 22, 5000-6000 нет


nm.infra.node1 tcp 22, 80, 443 нет

6 nm.app.node1 nm.db.node1 tcp 5000-6000 нет 7 nm.app.node1 nm.db.node2 tcp 5000-6000 нет 8 nm.db.node1 nm.db.node2 tcp 5000-6000 нет 9 nm.db.node2 nm.db.node1 tcp 5000-6000 нет

10 nm.infra.node1 nm.app.node1 tcp 22 нет 11 nm.infra.node1 nm.db.node1 tcp 22 нет 12 nm.infra.node1 nm.db.node2 tcp 22 нет 13 nm.infra.node1 nm.app.test.node1 tcp 22 нет 14 nm.infra.node1 nm.app.dev tcp 22 нет 15 nm.infra.node1 nm.db.test.node1 tcp 21 нет 16 nm.infra.node1 nm.db.test.node2 tcp 22 нет 17 nm.infra.node1 nm.db.dev tcp 22 нет

18 nm.app.node1 Active Directory tcp, udp 88, 389, 636, 3268, 3269

нет

19 nm.app.node1 ERP tcp 1521-1620 нет

20 nm.app.node1 apd-app01-prod tcp 7001, 7002, 7004, 7005, 8000

нет

21 nm.app.node1 apd-app02-prod tcp 7001, 7002, 7004, 7005, 8000

нет

22 nm.app.node1 apd-clon1 tcp 7001, 7002 нет 23 nm.app.node1 apd-clon2 tcp 7001, 7002 нет 24 nm.app.node1 apd-clon3 tcp 7001, 7002 нет 25 nm.app.node1 apd-clon4 tcp 7001, 7002 нет 26 nm.app.node1 SMTP сервер tcp 25 нет 27 nm.app.node1 Sms-gate tcp 80, 443 нет 28 nm.app.node1 DNS tcp, udp 53 нет 29 nm.db.node1 DNS tcp, udp 53 нет


№

Наименование и IP

инициатора (source)

Наименование и IP назначения

(destination)

Сетевой протокол, по которому


Сетевые порты, по которым


Передача персональных

данных (Да/Нет)

30 nm.db.node2 DNS tcp, udp 53 нет 31 nm.infra.node1 DNS tcp, udp 53 нет


6 Нефункциональные требования

6.1 Обеспечение требований к быстродействию

Требования к быстродействию:

• Формирование стандартных форм налоговой отчетности должно выполняться не более 1 минуты при количестве обрабатываемых данных до 10 млн. строк;

• Ожидаемое количество данных в год не менее 700Гб (прогнозируемое значение);

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

Указанные выше требования к быстродействию обеспечиваются за счет:

• Использования СУБД PostgreSQL (или поддерживаемых версий СУБД PostgresPro/ Jatoba) для хранения данных и построения запросов к ним. Данная СУБД имеет возможность индексирования и партиционирования, а также построения сложных запросов;

• Для хранения данных используются SSD диски, которые ускоряют дисковые операции и позволяют быстрее обрабатывать запросы к данным;

• На слое приложений используется кэш на базе Tarantool, который хранит предварительно рассчитанные агрегаты и позволяет получать их сразу из памяти, без обращения к СУБД;

• Бизнес логика реализована на высокопроизводительном языке программирования – Go;

• Компоненты системы продублированы, что позволяет использовать несколько экземпляров параллельно, а также, при необходимости, горизонтально масштабировать систему;

• На слое представления (веб-клиент) используется легковесная библиотека React.js.

6.2 Обеспечение требований к высокой готовности к балансировке

Все серверные компоненты системы могут функционировать в кластере, т.е. при одновременной работе нескольких экземпляров. Это позволяет распределить нагрузку между серверами, повысить отказоустойчивость и обеспечить горизонтальное масштабирование.

В продуктивной среде (PROD) все компоненты могут быть продублированы на разных виртуальных машинах, что позволяет обслуживать машины по очереди,


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

6.3 Обеспечение требований к надёжности

Доступность системы для пользователей составляет не менее 99,5%. Программное обеспечение системы обеспечивает функционирование в режиме 24х7 с допустимыми перерывами на профилактику и устранение сбоев.

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

6.4 Обеспечение требований к информационной безопасности

Информационная безопасность системы обеспечивается базовыми инфраструктурными сервисами окружения.

В системе предусмотрена защита информации от несанкционированного доступа к функциям администраторского и инструментального интерфейса, за счёт ограничения доступа средствами аутентификации и авторизации.

Защита от несанкционированного доступа со стороны персонала системы к функциям администраторского интерфейса обеспечивается следующим комплексом мер:

• Доступ в администраторский интерфейс происходит только по индивидуальному логину и паролю с расширенной или ограниченной ролью «Администратор»;

• Ведение журнала всех действии администратора системы происходит только в администраторском интерфейсе;

• Имеется возможность блокировки доступа администратора в интерфейс.

• Ведется журнал всех аутентификации;

• Пользователи имеют доступ к функциям системы в соответствии с ролевой моделью;

• Система находится внутри корпоративной сети Заказчика и не имеет доступа в интернет.

Система предназначена для работы с конфиденциальными данными физических и/или юридических лиц, таким образом, в система реализованы следующие средства обеспечения безопасности пользовательских данных:

• Шифрование траффика;


Система поддерживает функцию шифрования передаваемого траффика по протоколу HTTPS. При необходимости, может быть подключен сертифицированный модуль, обеспечивающих шифрование по ГОСТ.

• Использование ролевой модели доступа в систему;

Система поддерживает ролевую модель доступа. Такая функциональность программы позволяет ограничить доступ пользователей к хранимым в системе данным.

• Политика парольной безопасности;

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

• Регистрация событий;

Система осуществляет регистрацию действий пользователей и системных событий, с возможностью их просмотра администратором системы.

• Доступ ко всем серверам осуществляется с использованием протокола SSH;

• Организация защищенного периметра в инфраструктуре НП.

Для безопасного функционирования системы в контуре предлагается организация обособленной сети (локальной или VPN сети), которая не будет иметь соединения с другими сетями (в частности, не будет иметь доступа в сеть интернет) и доступ к которой будут иметь только авторизованные лица.

6.5 Дополнительные меры для повышения безопасности веб-приложений

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

Безопасность сети

• Ограничение доступа к ресурсам сети;

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

Безопасность сервера

• Регулярное выполнение резервирования данных;

• Использование антивирусного программного обеспечения;

• Регулярное обновление используемого программного обеспечения;

• Ведение журнала событий системы;


• Использование программного обеспечения от надежных поставщиков;

• Ограничение доступа к серверу и его ресурсам;

• Отключение неиспользуемого программного обеспечения на сервере;

• Использование шифрования при доступе к серверу;

• Использование средств автоматизации при обновлении ПО на сервере.

Защита рабочих мест пользователей

• Подписание соглашения о неразглашении данных с сотрудниками;

• Внедрение политик безопасности, препятствующей утечке информации с рабочих мест пользователей (блокировка рабочей станции при отсутствии сотрудника на рабочем месте, запрет на хранение паролей в доступном месте, хранение компьютеров в запираемом помещении и прочее);

• Регулярное обновление используемого программного обеспечения;

• Использование антивирусного программного обеспечения.

Платформа Налоговый мониторинг...СУБД 1 PostgreSQL 9.6 и выше 2...

Documents

Transcript of Платформа Налоговый мониторинг...СУБД 1 PostgreSQL 9.6 и выше 2...