Метод внутренней алгоритмизации процесса передачи защищенных данных по телекоммуникационным каналам связи
Султанова А.Н.1, Петренко В.И.2, Шарыпова В.А.1
1 Ростовский государственный экономический университет (РИНХ), Россия, Ростов-на-Дону
2 Северо-Кавказский федеральный университет - Институт математики и информационных технологий имени профессора Н.И. Червякова, Россия, Ставрополь
Скачать PDF | Загрузок: 6
Статья в журнале
Информатизация в цифровой экономике (РИНЦ, ВАК)
опубликовать статью | оформить подписку
Том 1, Номер 2 (Апрель-июнь 2020)
Цитировать:
Султанова А.Н., Петренко В.И., Шарыпова В.А. Метод внутренней алгоритмизации процесса передачи защищенных данных по телекоммуникационным каналам связи // Информатизация в цифровой экономике. – 2020. – Том 1. – № 2. – С. 67-74. – doi: 10.18334/ide.1.2.113363.
Эта статья проиндексирована РИНЦ, см. https://elibrary.ru/item.asp?id=47974324
Аннотация:
В настоящий момент самым удобным и распространенным видом представления бухгалтерской и налоговой отчетности в налоговые органы является электронный способ. Отчетность в электронной форме подают по телекоммуникационным каналам связи (ТКС). В статье выявлены проблемы передачи защищенных данных по телекоммуникационным каналам связи. Кроме того, разработан алгоритм передачи отчетности по ТКС, представлен метод заключение моделирования процесса передачи по защищенным каналам связи.
Ключевые слова: алгоритм, передача отчетности, моделирование, защищенные данные, телекоммуникационные каналы связи
JEL-классификация: L96, P25
В настоящий момент самым удобным и распространенным видом представления бухгалтерской и налоговой отчетности в налоговые органы является электронный способ. Отчетность в электронной форме подают по телекоммуникационным каналам связи (ТКС). Система представления отчетности по телекоммуникационным каналам связи является не чем иным, как переходом на бесконтактную и безбумажную технологию сдачи отчетности. Иными словами, ТКС – это система представления налоговой и бухгалтерской отчетности в электронной форме. Представление отчетности в электронной форме осуществляется по ТКС с применением усиленной квалифицированной электронной подписи через операторов электронного документооборота.
защищенности данных при ее передаче деятельности отечественных, и ученых, представлено на и форумах, а также в и журналах.
относятся в информационных в HJ Kim, услуг U Bubeck, U Shafique, MR Zafar, D. Moren, T Sahayini, А. Г., Е. А., Шибанова С. В., К. Н., К. С., Г. А. и других.
проблемы безопасности, в том и при ее передаче, обсуждаются на управление «» [4] и на мероприятиях, посвященных безопасности. По [5], 29% американских на разделение и доступом, приоритетной является передача защищенных данных .
Современная система документооборота между субъектами хозяйствования и контролирующими структурами построена на двух принципах: подача документов и отчетности в бумажном виде (обычно при условии небольшой среднесписочной численности штата); обмен информацией в электронном формате (через интернет с участием официальных посредников – операторов ТКС). Процесс отправки и приема сведений регламентирован законодательно ко всем участникам процедуры документооборота.
Процедура передачи отчетности по ТКС осуществляется согласно Приказу ФНС России от 17.02.2011 № ММВ-7-2/168. Алгоритм процедуры зарегламентирован следующими этапами: получение электронного требования налогоплательщику; отправка налогоплательщиком посредством спецоператора связи квитанции о приеме, подтверждающая факт получения требования; формирование описи документов, прикрепленных в электронном виде в определенных форматах; подписание пакета квалифицированной электронной цифровой подписью; отправка подписанного пакета в контролирующий орган [1].
Процесс передачи защищенных документов представляет собой информационный физический обмен защищенных данных в электронном формате по открытым каналам связи с использованием ЭЦП. Представление документов по ТКС очень внешне напоминает представление электронной отчетности. Существуют два алгоритма передачи отчетности по ТКС, поскольку на текущий момент используются две технологии: сдача отчетности через операторов ЭДО и самостоятельная загрузка отчетов на приемные шлюзы контролирующих органов. Для сдачи отчетности в контролирующие органы, в частности в ИФНС, необходимы три составляющие: сертификат электронной подписи (оформляется организацией самостоятельно через специализированные организации); средство криптографической защиты информации; специальное программное обеспечение для подготовки и проверки отчетности.
Все эти три составляющие налогоплательщик должен иметь в наличии, т.е. государственные органы их не предоставляют.
В процессе применения данной технологии было замечено несколько возникающих в процессе проблем [2]:
1) при сетевых неполадках на приемных каналах принимающей стороны приходится существенное время тратить на его загрузку;
2) при неполадках со стороны сети практически невозможно доказать факт загрузки отчетности налогоплательщиком вовремя;
3) практически отсутствует техническая поддержка при самостоятельной отправке.
Основные процессы, которые задействованы в алгоритме передачи защищенных данных по ТКС:
1. Реализация возможности регистрации юридического лица как налогоплательщика. Регистрация должна быть максимально проста и удобна.
2. Реализация возможности заключения договора между налогоплательщиком и спецоператором связи.
3. Реализация возможности получения электронного ключа и пароля.
4. Реализация системы рекомендаций, которая будет предлагать налогоплательщику максимально просто пройти этапы составления, проверки и передачи отчетности.
5. Разработка возможности обработки всех ошибок, возникающих в процессе и возможности анализировать их.
6. Сбор и анализ статистики затраченного времени.
Доступ к администрированию системы должен предоставляться только после авторизации парой логин/пароль. После авторизации администратору необходимо реализовать следующий необходимый функционал для полноценного функционирования системы [6]:
1. Проверять корректности введенных персональных данных пользователями и при необходимости уведомить или заблокировать пользователя, если в данных есть опечатки или они некорректны.
2. Реализовать возможность отслеживания времени.
3. Реализовать возможность анализа эффективности. Анализировать статистику ошибок, возникающих в программе, и давать возможность формировать отчет в техническую службу.
4. Реализация возможности администратору удалять, блокировать или на время, или навсегда клиентов, которые вводят некорректные данные.
Необходимость проектирования базы данных невозможно недооценивать, так как грамотно спроектированная база данных позволит избежать огромного множества проблем при дальнейшей ее разработке и поддержке. Для проектирования текущей схемы данных использовалась реляционная база данных. Реляционная база данных состоит из набора схем отношений, которые соединены различными связями между собой. Чаще всего используется связь «один к одному» или «многие к многим». При реализации логической модели были учтены основные правила, существующие при разработке базы данных, то есть таблицы приведены к основным нормальным формам, каждая таблица содержит уникальный первичный ключ, также каждое ключевое поле зависит от неключевого поля в пределах одной таблицы в базе данных и каждое неключевое поле функционально не зависит от другого неключевого поля. Это приведены примеры первых трех нормальных форм.
При проектировании базы данных использовались только два типа связей между таблицами: идентифицирующая и неидентифицирующая. Идентифицирующая – это такой тип связи, когда связь идет от ключевого поля родительской таблицы к любому неключевому полю дочерней таблицы, если данное условие не выполняется, то связь называется неидентифицирующей [7] (Khubaev, Shcherbakov, 2016). На основании двух уровней модели – логическом и физическом, в дальнейшем уже можно реализовать базу данных в Microsoft SQL Server. Приложение имеет трехуровневую архитектуру, которая состоит из пользовательского интерфейса, концептуального уровня и уровня базы данных. Необходимо разбить пользовательское представление на следующие компоненты: представление ответственного лица (клиента); представление гостя. Представление клиента, в свою очередь, разбивается на представление администратора, представление налогоплательщика. Как правило, все сервисы создаются под архитектуру «клиент – сервер». Архитектура расширяется до трехуровневой в результате внедрения составляющей части, сервера приложений. Роль клиента выполняет представление, которое является интерфейсом пользователя. Его основная цель – это предоставление результатов, понятных пользователю. На рисунке 1 представлена архитектура сервиса.
Слой данных включает в себя сервер базы данных, отсюда информация сначала отправляется на концептуальный уровень для обработки, затем – пользователю [8] (Tishchenko, Sharypova, 2010).
Рисунок 1. Архитектура сервиса
На рисунке 2 представлен макет формы регистрации ответственного лица за передачу данных. Для регистрации ответственное лицо (как правило, бухгалтер) должно ввести минимальную информацию, такую как «Фамилия», «Имя», «Отчество», «Электронная почта» и »Пароль». После чего клиент становится автоматически ответственным лицом за передачу данных.
Рисунок 2. Макет формы регистрации ответственного лица за передачу данных
Далее ответственное лицо автоматически попадает в сервис встроенной программы спецоператора по передаче отчетности и выполняет все необходимые действия для внедрения отчета и его отправки.
Проанализировав предметную область, создав алгоритм и далее спроектировав макет сервиса, необходимо приступить к одному из самых важных этапов проектирования – это выбор программного обеспечения, с помощью которого будет реализован сервис, согласно созданному алгоритму. Системой управления базой данных для сервиса будет являться Microsoft SQL Server. Выбранная база данных обладает рядом преимуществ, благодаря которым можно сделать разработку максимально быстрой и легкой. Выбранная база данных является реляционной, данный фактор влияет очень сильно на простоту в использовании и легкость при конфигурировании. Даже если в ней будет храниться огромное количество структурированных данных, это не будет влиять на скорость обработки информации и очень быстро возвращать результаты запросов клиенту. Выбранная система управления базой данных имеет высокие показатели защиты для информации за счет встроенных средств безопасности и возможности легко управлять правами пользователей.
:
Источники:
2. Указ Президента Российской Федерации О национальных целях и стратегических задачах развития Российской Федерации на период до 2024 года» от 7 мая 2018 г. Консультант Плюс. [Электронный ресурс]. URL: http://www.consultant.ru/document/cons_doc_LAW_297432/.
3. Приказ ФСТЭК России «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» от 11.02.2013 № 17. Консультант Плюс. [Электронный ресурс]. URL: http://www.consultant.ru/document/cons_doc_LAW_147084/.
4. Приказ ФСТЭК России «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» от 18.02.2013 № 21. Консультант Плюс. [Электронный ресурс]. URL: http://www.consultant.ru/document/cons_doc_LAW_146520/.
5. Официальный сайт Национальный форум информационной безопасности Инфофорум. [Электронный ресурс]. URL: https://infoforum.ru.
6. Приказ ФНС РФ от 17.02.2011 N ММВ-7-2/168@ (ред. от 07.11.2011) «Об утверждении Порядка направления требования о представлении документов (информации) и порядка представления документов (информации) по требованию налогового органа в электронном виде по телекоммуникационным каналам связи». Nalog.gov. [Электронный ресурс]. URL: https://www.nalog.gov.ru/rn77/about_fts/docs/3897318/.
7. Хубаев Г.Н., Щербаков С.М. Система автоматизированного синтеза имитационных моделей на основе языка UML 2.0 (СИМ-UML 2.0). / Свидетельство о государственной регистрации программы для ЭВМ. № 2016661676. - М.: Роспатент, 2016.
8. Тищенко Е.Н., Шарыпова Т.Н. Формализация выбора различных вариантов системы защиты информации от несанкционированного доступа в среде электронного документооборота // Вестник Ростовского государственного экономического университета (РИНХ). – 2010. – № 3(32). – c. 226-233.
Страница обновлена: 12.08.2024 в 13:14:01