Правильный подход к подготовке и внедрению IdM
Информационная безопасность Информационная безопасность

Как осуществляется подготовка к IdM-проектам и почему стандартный подход не всегда работает? Какие этапы должна включать подготовка? Что дает аудит перед стартом IdM-проекта?

Главная>Информационная безопасность>Так сложилось, что не получилось! Правильный подход к внедрению IdM
Информационная безопасность Тема номера

Так сложилось, что не получилось! Правильный подход к внедрению IdM

Дата публикации:
24.07.2020
Посетителей:
960
Просмотров:
1065
Время просмотра:
2.3

Авторы

Автор
Елизавета Тарасова Аналитик отдела IdM-решений Центра прикладных систем безопасности компании «Инфосистемы Джет»

Как обычно осуществляется подготовка к IdM-проектам и почему стандартный подход не всегда работает?

 

Какие этапы должна включать подготовка к внедрению IdM?

 

Что дает аудит перед стартом IdM-проекта?

 

 

В процессе реализации проектов нам приходится решать различ­ные проблемы. При этом мно­гие из них возникают из­-за того, что на этапе подготовки проекта остаются неучтенными важные детали, о которых становится известно уже в про­цессе внедрения. Например, в крупном бан­ке в ходе выполнения проекта по внедрению IdM выяснилось, что в автоматизированной банковской системе (АБС), которую требова­лось подключить к IdM, не было механиз­ма для взаимодействия — API. Произошло это, когда первый этап проекта уже был выполнен и стартовали работы по второ­му этапу. При этом управление учетными записями в АБС являлось основной целью внедрения IdM и ключевым требовани­ем на проекте, а без API подключение этой системы не представлялось возможным. Банку пришлось привлечь разработчика АБС и приостановить проект по внедрению IdM — до реализации механизма. В резуль­тате бюджет проекта увеличился на сум­му затрат на доработку системы, а сроки сдвинулись на 6 месяцев. Почему компании сталкиваются с подобными трудностями и как можно избежать неприятных сюрпри­зов при внедрении системы управления доступом, расскажем в статье.

В этой жизни определено только то, что нет ничего определенного. 

Плиний Старший

Почему нельзя просто взять и внедрить IdM-решение

 

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

Этап 1. Формирование общих требований

 

Сначала компании формируют перечень требований к IdM-­решению. В большинстве случаев это происходит следующим обра­зом. Компании отправляют запрос под­рядчику с просьбой оценить стоимость IdM­-решения. Подрядчик в ответ присы­лает опросный лист, состоящий из типо­вых вопросов. Как правило, они касаются четырех факторов:

  • количество пользователей (внутренних и внешних);
  • подключаемые информационные систе­мы;
  • автоматизируемые процессы;
  • разрабатываемые документы.

 

Далее компании формируют перечень требований. Такими требованиями могут быть:

  • автоматизация процессов: прием на работу, перевод, увольнение;
  • наличие штатного коннектора к системам MS AD, Exchange, 1C;
  • запрос прав доступа по заявке;
  • ведение справочника внешних пользо­вателей.

Эти требования являются верхнеуровневыми и не отражают всех особенностей того, как это должно быть сделано в проек­те. Так, в крупной металлургической ком­пании одним из требований было ведение справочника внешних пользователей — ра­ботников подрядных организаций. Данный функционал был реализован в следующем объеме: куратор в IdM­-системе регистри­рует внешнего пользователя, после чего IdM­-система предоставляет ему необходи­мый доступ в информационные системы. Однако в ходе промышленной эксплуатации системы выяснилось, что данного функци­онала недостаточно. Из компании уволился сотрудник, за которым было закреплено больше 50 внешних пользователей, и всех их потребовалось перевести на другого работ­ника. Для этого компании пришлось созда­вать 50 отдельных заявок, так как в системе не было возможности массового переноса подрядчиков в рамках одной заявки. В ре­зультате решение пришлось дорабатывать, что привело к дополнительным расходам на реализацию проекта. Однако этого мож­но было избежать, добавив на начальном этапе требование реализовать массовый перенос внешних пользователей в рамках одной заявки.

Этап 2. Выбор платформы

 

На данном этапе компании ищут реше­ние, которое бы соответствовало общим требованиям. При выборе они используют сведения из открытых источников, а так­ же запрашивают данные у вендоров и интеграторов. На основе этой информации компании формируют сравнительную та­блицу, в которой отмечают наличие того или иного функционала, стоимость реше­ния, количество внедрений, наличие реше­ния в рейтингах аналитических агентств Gartner и Forrester. В большинстве случаев ключевыми критериями для выбора явля­ются функционал и стоимость. Если про­вести сравнение представленных на рос­сийском рынке решений на основе общих требований, то можно прийти к выводу, что все они одинаковые. Соответственно, это приводит к тому, что зачастую выбор осуществляется на основе одного крите­рия — стоимости решения. На самом деле отличия в системах есть, только для их выявления требуется проводить более де­тальное сравнение.

Этап 3. Пилотный проект

 

Еще одним фактором, влияющим на окончательный выбор решения, явля­ется демонстрация его работы. Для этого вендор или интегратор выполняет пилот­ный проект. Как правило, для пилота соз­даются «лабораторные условия»: выделя­ются тестовая среда и тестовые данные в кадровой и информационных системах, а также выбирается наиболее простой для реализации и последующей демон­страции функционал (например, интеграция с системами AD и Exchange, управление учетными записями при приеме на работу и увольнении сотрудников). Однако зачастую «лабораторные условия» в корне отличают­ся от реальных данных и процессов. В ходе пилотного тестирования крайне сложно обнаружить ситуации, которые могут воз­никнуть при промышленной эксплуата­ции системы. Как это произошло в случае с внешними пользователями. В ходе пи­лотного проекта был продемонстрирован функционал по регистрации внешних поль­зователей, что соответствовало требованию к решению. А потребность в массовой заявке по переназначению внешних пользователей не была выявлена, так как в лабораторных условиях подобная ситуация едва ли может возникнуть.

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

После проведения всех процедур компа­ния уже может начать проект по внедрению IdM: сформированы общие требования, выб­рано подходящее решение, подтвержден­ное пилотным тестированием. Осталось только найти подрядчика для выполнения проекта. С этой целью компании запускают процедуру сбора предложений RFP. В от­вет на запрос они получают предложения от подрядчиков, стоимость работ в которых может варьироваться от миллиона до сотни миллионов рублей, а длительность — от нескольких месяцев до нескольких лет. Такую существенную разницу мы объясняем тем, что одни подрядчики учитывают в предло­жении выполнение дополнительных работ, которые могут возникнуть в ходе выполне­ния проекта, а другие этого не делают (см. рис. 1 и рис. 2). Рассмотрим пример одного из тре­бований — автоматизации процесса при­ема сотрудника на работу. Если смотреть на него «в лоб», его реализация будет пред­ставлять процесс, состоящий из нескольких простых шагов. Несмотря на то что процесс будет автоматизирован, а требование фор­мально выполнено, на практике может ока­заться, что данный функционал окажется неудобным для использования. Произойдет это потому, что в таком варианте учитыва­ются не все кейсы, возникающие при приеме на работу: совместительство, повторный прием на работу, отправка SMS-­сообще­ния сотруднику с первоначальным паро­лем от учетных записей и т.д. Для реше­ния проблемы в процесс нужно добавить дополнительные условия и действия. Это, в свою очередь, приводит к увеличению стоимости и сроков IdM­-проекта.

 

Тем не менее компании считают разни­цу в стоимости и сроках парадоксальной: им кажется, что в предложения включе­ны одинаковые работы. Поэтому в боль­шинстве случаев делается выбор в пользу предложений с минимальной стоимостью услуг. Как результат — множество проблем на проекте. И дело не только в последую­щем увеличении бюджета и сроков проекта. Бывают случаи, когда подрядчик выполня­ет проект формально: «реализует систему строго по ТЗ», а не в соответствии с реаль­ными требованиями компании. В итоге ре­ализованной системой просто невозможно пользоваться.

Рисунок 1. Разные представления подрядчиков о реализации процесса приема на работу
Рисунок 2. Разные представления подрядчиков о реализации процесса приема на работу

Бывают случаи, когда подрядчик выполняет IdM-проект формально: «реализует систему строго по ТЗ», а не в соответствии с реальными требованиями компании. В итоге реализованной системой просто невозможно пользоваться.

Как мы пытались решить эти проблемы «по-простому»

 

Казалось бы, чтобы избежать перечис­ленных проблем, необходимо составлять более детальные требования и проводить пилотное тестирование наиболее слож­ного функционала с использованием ре­альных данных. Но, по нашему опыту, на практике такой сценарий не работает. Для составления детальных требований мы отправляли компаниям расширенные опросные листы, сгруппированные по те­матикам: бизнес-­процессы, интеграция с информационной системой, нефункцио­нальные требования и т.д. Каждый из них содержал в среднем 70–80 вопросов. Од­нако мы ни разу не получили полностью и корректно заполненные опросные листы. Это связано с тем, что, во­-первых, ответы на такое большое количество вопросов (для компании с 5 системами — около 800 вопросов) требуют много времени, а во-­вторых, делать это должен опытный специалист, по­нимающий специфику работы IdM-системы и особенности ее внедрения.

Что касается пилотного проекта, то для его проведения в условиях, наиболее приближенных к реальным, необходимо выполнить большой объем подготовитель­ных работ. В основном это обследование автоматизируемых процессов и подключае­мых систем, доработка IdM-­системы, созда­ние копий продуктивных данных. В этом случае пилотный проект перерастает в пол­ноценный проект по внедрению, что при­ водит к увеличению стоимости и срока его проведения. Поэтому в большинстве слу­чаев ни компания, ни подрядчик не готовы брать на себя такие расходы.

Мы работаем на рынке IdM-решений с 2005 г. За это время наша команда реализовала более 30 проектов на базе 7 различных IdM-платформ в крупных организациях из различ- ных секторов экономики. Помимо реализации проектов, мы занимаемся исследованием рос- сийского рынка IdM-решений и в конце 2019 г. выпустили наш второй отчет. Он показывает, что за последние 5 лет интерес к теме IdM вырос: количество IdM-проектов в России увеличилось почти вдвое.

Правильный подход к подготовке IdM-проекта

 

Чтобы не столкнуться с вышеописанны­ми проблемами, мы предлагаем исполь­зовать следующий подход при подготовке к проекту по внедрению IdM (см. рис. 3).

Рисунок 3. Правильный подход к подготовке IdM-проекта

Шаг первый. Определение проблем

 

Сначала необходимо выяснить, какие проблемы должно решить внедрение IdM, и определить, подходит ли для этого по­добный класс систем. Мы сталкивались с ситуациями, когда средствами IdM ком­пании пытались решить задачи, для ко­торых она не предназначена. Так, напри­мер, в одной компании ключевой задачей перед проектом по внедрению IdM было мгновенное оповещение специалистов ИБ о несанкционированном изменении прав доступа в информационных систе­мах. Действительно, эту задачу можно решить и с помощью IdM, разработав мо­дуль, реализующий такой функционал. Однако IdM не предназначена для выпол­нения подобного рода задач. Для этого целесообразно применять другой класс решений — SIEM. Поэтому на данном этапе важно определить, правильный ли инструмент компания планирует ис­пользовать для решения существующих проблем.

Мы сталкивались с ситуациями, когда средствами IdM компании пытались решить задачи, для которых она не предназначена.

Шаг второй. Аудит процессов и ИС

 

Как правило, IdM-­проекты являются сложными и масштабными и затрагивают множество областей в компании. Поэто­му на следующем этапе после определе­ния проблем необходимо провести аудит, то есть обследовать те области, на которые влияет и от которых зависит внедрение IdM. Мы предлагаем аудит следующих об­ластей (см. рис. 4).

Рисунок 4. Аудит процессов, информационных систем и источника кадровых данных

В ходе обследования процессов управления доступом важно определить два основных момента. Во­-первых, необходимо выяснить, как в действительности в ком­пании осуществляются процессы управ­ления доступом. Ведь зачастую процессы, описанные в регламентах или других до­кументах компании, в жизни исполняются лишь частично либо по совершенно другому сценарию. Во­-вторых, нужно оценить воз­можность автоматизации этих процессов. В случае, если текущие процессы автома­тизировать невозможно, нужно определить необходимость и возможность их измене­ния. Бывают ситуации, когда текущие про­цессы изменить нельзя и это становится стоп-­фактором для внедрения IdM. Напри­мер, в одной компании в начале каждого месяца существует 10­-дневный тайм­аут по внесению информации о кадровых ме­роприятиях в кадровую систему, то есть в этот период IdM не сможет получать дан­ные о кадровых мероприятиях и выпол­нять операции по управлению правами доступа. Изменение текущего процесса не представлялось возможным, поскольку это требовало изменений процедуры рас­чета заработной платы и работы кадровой системы. В результате кадровые процессы были автоматизированы частично.

На следующем шаге нужно провести аудит систем компании. Требуется сфор­мировать их перечень, определить кри­тичность, а также необходимость и целе­сообразность подключения к IdM. Кроме того, необходимо выявить внутреннюю логику управления доступом и выбрать способы подключения информационных систем к IdM. В случае, если у системы нет механизма для взаимодействия, рассмат­риваются варианты его разработки либо подключения системы как неуправляемой. После этого следует выяснить внутреннюю логику управления доступом в системах, то есть установить, какие объекты внутри них отвечают за предоставление доступа. Это делается, для того чтобы определить варианты переноса такой логики в IdM. Идеология работы IdM­-решений основана на модели RBAC (Role Based Access Control). Это означает, что IdM управляет доступом только на основе ролей без управления ато­марными полномочиями. Однако сущес­твуют системы, в которых, помимо ролей для управления доступом, используются дополнительные параметры. Это могут быть профили, группы, справочники и т.д. Для распространенных систем, например SAP, производители IdM­решений разрабо­тали коннектор, который позволяет управ­лять доступом, используя не только роли, но и дополнительные параметры. Однако это единичные примеры, и для нераспро­страненных или самописных систем есть два варианта подключения к IdM. Первый подразумевает, что IdM будет управлять доступом в этих системах только на уров­не ролей, а второй — что вся внутренняя логика управления доступом будет пере­несена в IdM. В последнем случае компа­нии должны быть готовы к существенно­му увеличению стоимости подключения данной системы, а также к тому, что любое изменение логики управления доступом внутри системы потребует переработки функционала подключения этой системы.

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

Еще одна область, которую необходимо обследовать в рамках аудита, — кадровая система. Следует проанализировать те­кущие кадровые данные, чтобы выявить их специфику и определить полноту. Это нужно, для того чтобы оценить, достаточ­но ли текущих данных в кадровой системе для автоматизации процессов в IdM. Пред­положим, в компании 5000 сотрудников и десятой части из них не требуются ра­бочее место и доступ в системы. Создание учетных записей в IdM и информацион­ных системах для них влечет за собой из­быточный расход лицензий. Чтобы этого не произошло, IdM­-решение должно по­лучать информацию о том, что для этих сотрудников не требуется создавать учет­ные записи. Соответственно, нужно, чтобы в кадровой системе существовал признак необходимости рабочего места и его кор­ректно заполняли специалисты кадрового учета.

Шаги третий и четвертый. Оценка возможности внедрения IdM и выполнение рекомендаций

 

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

  • старт проекта по внедрению IdM­-решения в полном объеме;
  • выполнение рекомендаций, доработка систем и изменение процессов, старт про­екта после выполнения этих действий;
  • разделение проекта по этапам, старт пер­вого этапа, доработка систем и изменение процессов, подключаемых на дальнейших этапах;
  • и др.

 

Cуть этапа наглядно продемонстрирова­на в табл. 1 и 2. В результате этих действий мы по­лучаем перечень подключаемых систем, процессов и разделение работ по этапам.

Таблица 1. Оценка возможности подключения систем и автоматизации процессов
СистемаКоличество пользователейКритичностьСтатус
Кадровая система 1С-Высокая Подключение
Microsoft Аctive Directory5000ВысокаяПодключение
Microsoft Exchange5000ВысокаяПодключение
1C Управляемая система300СредняяТребуемая разработка механизма взаимодействия
Система бухгалтерского учета10СредняяПодключение нецелесообразно
ITSM-система5000СредняяТребуется доработка системы
ПроцессСтатус
Прием на работу, перевод, увольнениеВозможна частичная автоматизация
Отсутствует признак необходимости рабочего места
Прием на дополнительное трудоустройствоПолная автоматизация
Изменение учетной записи при изменении ФИОПолная автоматизация
Добавление объекта в организационно-штатную структуруЧастичная автоматизация
Неактуальная ОШС в кадровой системе
Удаление объекта из организационно-штатной структурыЧастичная автоматизация
Неактуальная ОШС в каждой системе
Смена куратора для внешних пользователейАвтоматизация возможна
Требуется доработка
Предоставление доступа к системе по заявкеАвтоматизация возможна
Требуется доработка
Таблица 2. Оценка возможности внедрения IdM

 

ПроцессыСистемы

Этап 1

  • прием на работу, перевод, увольнение
  • изменение учетной записи при изменении фио
  • добавление объекта в организационно-штатную структуру
  • удаление объекта из организационно-штатной структуры
Кадровая система 1С
Microsoft Active Directory
Microsoft Exchange
Этап 2
  • обработка признака рабочего места при приеме на работу
  • предоставление доступа к системе по заявке
  • прекращение доступа к системе по заявке
1C Управляемая система
ITSM-система

Исходя из нашего опыта, мы можем ска­зать, что проведение оценки помогает сни­зить вероятность возникновения проблем на проекте. Так, в одной энергетической компании на начальном этапе требова­лось за полгода внедрить централизо­ванную IdM-­систему в 40 юридических лицах компании и подключить к ней 16 ин­формационных систем. После проведения аудита стало понятно, что в каждом юри­дическом лице был собственный кадровый источник, большинство информационных систем не имели механизмов взаимодей­ствия и во многих из них управление про­исходило без использования ролей. Ре­зультаты оценки возможности внедрения показали, что IdM-­проект можно запустить лишь после выполнения определенных действий. При этом проект по внедрению требовалось разделить на этапы: 1) сначала подключить системы, в которых есть меха­низмы для взаимодействия и используется ролевое управление доступом; 2) параллель­но доработать другие информационные системы; 3) только после этого подключить оставшиеся системы. При таком сценарии первоначально запланированные 6 месяцев реализации превращаются в 3 года. Нетруд­но представить, к каким проблемам привел бы запуск проекта без проведения аудита.

Шаг пятый. Формирование детальных требований

 

Удостоверившись в том, что рекомендо­ванные действия выполнены и внедрение возможно, переходим к следующему эта­пу — формированию детальных требований. После проведения аудита подготовить этот документ не составит труда. По результа­там аудита формируется детальный отчет, в котором отражается текущая ситуация по всем обследуемым системам и процес­сам. Информация из данного отчета упро­щает процесс формирования требований, а сам отчет можно использовать в качестве приложения к RFP. К тому же еще один этап подготовки к проекту — выбор решения — будет происходить как бы в фоновом режи­ме, так как при наличии детальных требова­ний сделать это гораздо проще: нужно лишь направить перечень требований вендору или интегратору, который ответит, удов­летворяет ли предлагаемый им продукт указанным требованиям.

Правильный подход: за и против

 

За почти 15 лет работы на рынке IdM-решений мы приняли участие в большом количестве конкурсов. На наш взгляд, в сравнении с подходом без аудита, предлагаемый нами подход к подготовке проектов по внедрению IdM выигрышно отличается тем, что позволяет существенно минимизировать риски и повысить вероятность достижения поставленных целей. Для подтверждения этого вывода приведем результаты сравнения двух вышеописанных подходов. Мы проанализировали данные об открытых конкурсах (см. табл. 3).

 

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

 

Несмотря на все преимущества, предлагаемый нами подход имеет и минусы. Первый и самый существенный из них — финансовый. Проведение аудита требует денег, времени и ресурсов независимо от того, будет ли он проводиться подрядчиком или силами компании. В последнем случае обязательным условием является наличие специалистов, обладающих экспертными знаниями и опытом внедрения IdM-решений. Как правило, стоимость аудита примерно равна стоимости этапа проектирования. Аудит не дает гарантии готовности компании к внедрению и возможности запуска проекта. Компания может потратить денежные средства на проведение аудита, а его результаты покажут, что на текущий момент внедрение idm не представляется возможным. Для компании это будет означать, что деньги и время потрачены впустую. С другой стороны, предположим, что компания запустила проект без проведения аудита и заложила десятки миллионов рублей и десятки месяцев на его выполнение. При этом после выполнения половины работ выявились стоп-факторы или проблемы, устранение которых потребовало дополнительных средств и времени. Получается, что во втором случае компания теряет значительно больше времени и средств.

 

Второй недостаток заключается в том, что после получения результатов аудита компании прекращают активность по подготовке к проекту по внедрению IdM. Многие руководители, узнав, какой объем работ требуется выполнить перед внедрением IdM-решения, «опускают руки» и отказываются от проекта.

В завершение отметим, что вы сами должны решить, какой подход выбрать. Готовы ли вы пойти на риск и сыграть по-крупному, поставив на кон все? Или для вас лучше сделать «проверочную ставку»?

 

Таблица 3. Сравнение конкурсов с использованием традиционного и предлагаемого нами подходов к подготовке к IdM-проекту

 

 Традиционный подходПравильный подход
Количество участников в конкурсе6—83—4
Количество вендоров в конкурсе4—71—3
Разброс по стоимости работ между участникамиДо 1000%10—30%

Уведомления об обновлении тем – в вашей почте

Интервью с Игорем Ляпуновым, директором Центра информационной безопасности компании «Инфосистемы Джет»

Не так давно центр информационной безопасности компании «Инфосистемы Джет» подвел итоги своей работы за прошлый год. И сегодня нашим собеседником стал Игорь Ляпунов, директор ЦИБ, который рассказал, какими результатами завершился 2009 г. для центра информационной безопасности.

Identity Management: взгляд Sun Microsystems

Развитие сетевого сообщества подчиняется тем же законам, что и развитие общества, за одним исключением: все процессы идут во много раз быстрее

Внедрение системы IdM за 10 шагов

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

Преимущества для бизнеса, обеспечиваемые решением для управления идентификационными данными и доступом

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

Как построить эффективную систему управления доступом

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

Беседа со Степаном Масленниковым, директором департамента бизнес-информации и службы заказчика ТНК-BP

Мы обратились в компанию ТНК-BP с просьбой поделиться своим экспертным мнением по этой теме, и на вопросы нам ответил директор департамента бизнес-информации и службы заказчика ТНК-ВР Степан Масленников.

IdM в России - пора совершеннолетия

За последние годы рынок IdM в России проделал большой путь: за 5 лет - с 2009 г. - количество внедрений выросло в 6-7 раз

Система IdM: опыт эксплуатации

Система управления правами доступа эксплуатируется в Банке Москвы уже больше двух лет. Об опыте ее использования рассказывают Евгений Горбачев, начальник Управления информационной безопасности и Андрей Петрусевич, эксперт Управления информационной безопасности Банка Москвы.

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня