Установка и настройка kerio control 9.2 1. Kerio Control — установка и некоторые базовые настройки

Наглядное представление этапов внедрения.

Более подробная схема см. приложение №2.

Этап 1: диагностика

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

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

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

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

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

В данном этапе требуется оценить бизнес-требования, объем и рамки проекта, а также план проекта, и по этим данным определить, что лучше использовать - быстрое или полное внедрение Microsoft Dynamics.

Основные результаты стадии:

• * Предложение относительно работы над проектом:
• * описание содержания проекта;
• * предварительный план проекта.
• * Оценка инфраструктуры.

Результаты стадии:

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

Этап 2: анализ.

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

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

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

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

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

Основные результаты этапа:

• * Устав проекта.
• * Тренинги ключевых пользователей.
• * Детальный анализ бизнес-процессов:
  • o анализ разрывов требований с базовой функциональностью;
  • o оценка устранения разрывов;
  • o описание интерфейсов.
• * План миграции данных.
• * План проекта.
• * Функциональные требования:
  • o инфраструктура, функциональность и безопасность;
  • o интеграция.
• * Требования к контролю качества и тестированию.

Основные вехи этапа:

• * Проведено совещание по запуску проекта.
• * Заказчик утверждает Устав проекта.
• * Проводится обучение по проектируемой ИС для ключевых пользователей.
• * Заказчик утверждает «Функциональные требования», включая описания бизнес-процессов, интеграции и миграции данных.
• * Заказчик утверждает обновленный план-график проекта.

Этап 3: дизайн.

Начало стадии дизайна положено в аналитическом этапе и отрегулировано порожденными на ней артефактами, произведенными на нем, в частности результатом анализа бизнес-процессов и плана миграции данных. Цели стадии дизайна включают следующее (но не ограничены им):

• * Создать или обновить полный дизайн проекта и соответствующих документов, которые будут требоваться, чтобы решение соответствовало функциональным требованиям.
• * Чтобы создать верхнеуровневую спецификацию для каждой модификации системы, приспособлена обработка, определенные отчеты и интеграция определенная в документе «Функциональные Требования».
• * Создать подробное описание требований к преобразованию данных, которые были определены во время анализа и планирования миграции данных в аналитической стадии.
• * Получить одобрение от заказчика верхнеуровнего плана миграции данных и спецификации дизайна решения перед началом созданием подробной спецификации дизайна и выполнения заключительных оценок.
• * Создать подробную спецификацию дизайна решения на основе верхнеуровневой структуры дизайна, одобренного клиентом.
• * Выполнить и представить заказчику оценки созданию модификаций, контроля, интеграции и миграции данных.
• * Получить, одобренные заказчиком дизайном, технические требования модификаций системы, дизайн миграции данных и оценки всех перечисленных операций.

Основные результаты стадии:

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

Главные этапы стадии:

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

Этап 4: разработка.

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

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

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

Циклы развития и тестирования продолжаются, пока результаты тестирования не отвечают критериям тестирования определенным ранее и не удовлетворят клиента. На этой стадии проекта такие процессы как управление объемом и структурой проекта и управление изменениями крайне важны.

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

Основные результаты стадии:

• * Настройка решения проектируемой ИС.
• * Подготовка документации относительно решения проектируемой ИС
• * Развитие дополнительной функциональности (настройки).
• * Контроль и тестирование миграции данных.
• * Тестирование интеграции (включая интеграцию с внешними системами).

Главные этапы стадии:

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

Этап 5: развертывание.

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

Основные результаты стадии:

• * План начала и контрольный список.
• * План тестирования системы.
• * План обучения пользователей.
• * Обучение пользователей.
• * Рабочая система.

Главные этапы стадии:

• * План старта и контрольный список.
• * План тестирования системы.

Этап 6: эксплуатация.

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

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

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

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

По этому вопросу взаимодействие с клиентом проводится в пределах ранее скоординированной поддержки продукта (с подписанием соответствующего контракта). Команда консультанта переключается на следующий проект.

Основные результаты стадии:

• * Принятие системы клиентом.
• * Документы для закрытия проекта.
• * Соглашение по поддержке системы.

Главные этапы стадии:

• * Клиент признает, что спроектированный ЯВЛЯЕТСЯ и подписывает акт входа в коммерческой операции.
• * Клиент формально закрывает проект.
• * Клиент подписывает контракт поддержки.

Модель методологии проектируемой ИС также определяет две дополнительные стадии, которые можно реализовать после запуска решения

Проектируемая ИС в рабочей среде клиента:

Цель стадии оптимизации: создание структуры управления процессами, происходящими после процедуры Go-Live. Эта стадия также позволяет поддерживать отношения с клиентом после оригинального проекта введения или может стать первым шагом на способе предоставить услуги новому клиенту.

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

Стадия оптимизации - отражение процесса полного внедрения. Эта стадия включает перечисленные ниже действия:

• * Аналитические действия, направленные на сбор информации о процессе, контроле и производительности.
• * Предложения относительно объема работ.
• * Работа над выполнением и расширением оптимизации.

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

• * анализ;
• * планирование;
• * определение оптимизации;
• * расширение оптимизации;
• * эксплуатационные операции.

Обновление.

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

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

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

• * анализ;
• * планирование;
• * обновление работы;
• * тестирование;

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

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

Подробности Опубликовано: 14.07.2018 21:24 : рассматриваются базовые этапы внедрения корпоративных информационных систем. Кроме того выполняется обзор проектных документов каждого из этапов, а также демонстрируется зависимость данных заданной фазы на документы последующих этапов.
Скачать: PDF .
Ключевые слова: документы ERP систем, документирование внедрения корпоративных информационных систем, документирование информационных систем, документы в информационной системе, проектная документация ERP систем, рабочая документация ИС, техническая документация КИС, нормативные документы информационной системы, нормативные документы по проектированию информационных систем, документы внедрения ПО, документы внедрения информационных систем, этапы и документы внедрения программного продукта, опытная эксплуатация информационных систем, ГОСТ Р 54869-2011, ANSI PMBoK.

Определенно, самая удручающая из возможных ситуаций – это неопределенность. Незнание того, что же будет дальше по волнующему вас вопросу, сказывается крайне негативно. Процесс внедрения корпоративной информационной системы (далее - КИС) не исключение. Допустим, вы только что присоединились к проектной команде, не обладая ни опытом работы, ни теоретическими знаниями. Выполняя конкретно поставленные задачи, мы напоминаем «слепых котят», ожидающих завтрашних острых ощущений. Другой не менее показательный пример, консультант в течение нескольких лет решает строго ограниченный круг задач, не желая понять, для каких вышестоящих процессов они релевантны. В подобных случаях не стоит удивляться, когда задание вдруг оказывается должно быть выполнено «вчера». Для исключения вышеописанного необходимо четко представлять последовательность этапов имплементации КИС и документов, подготавливаемых на каждом из этапов.

Цель и задачи

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

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

1. Обзор подходов внедрения корпоративных информационных систем

Корпоративная информационная система представляется совокупностью информационных систем (далее - ИС), определяющих заданную предметную область. Существует несколько подходов внедрения ИС, применимых так же для имплементации КИС (рис.1). Начнем обзор с подхода, декларированного государством. Речь идет об отраслевых стандартах, в частности, ГОСТ Р 54869-2011 , а так же международном стандарте ISO 21500 . Документы содержат описание этапов управления проектами от процесса инициализации до завершения вне зависимости от вида реализуемой системы. Поэтому возможно использование указанных стандартов для реализации технических, информационных и корпоративных систем. Свод профессиональных знаний по управлению проектами, представленный ANSI PMI PMBoK , регламентирует процессы планирования, исполнения, проверки и воздействия от этапа инициирования до завершения проекта. Аналогично ГОСТ Р 54869-2011 и ISO 21500 допускается его применение для управления внедрением различных видов систем.

Рис. 1.

Методологии Accelerated SAP (далее - ASAP) , Accenture Delivery Methods (далее - ADM) , а также Microsoft Dynamics Sure Step (далее - MDSS) используются компаниями SAP, Accenture и Microsoft соответственно при внедрении пакетированных КИС решений. Подходы ориентированы исключительно на реализацию проектов имплементации КИС. В рассмотренных выше подходах используется преимущественно каскадная схема внедрения КИС . Данная схема характеризуется строгой временной зависимостью выполнения этапов проекта. Работы на заданном этапе могут выполняться только в том случае, если реализованы все активности предыдущей фазы проекта. Наименование этапов разнится от подхода к подходу, однако, содержание работ неизменно. Поэтому вполне реально сформировать единый перечень как операций, так и подготавливаемых документов. Подытожим результат анализа подходов внедрения КИС списком типовых этапов реализации проекта (рис.2).

Рис. 2.

2. Проектные документы типовых этапов реализации проекта

В предыдущем разделе были выделены типовые этапы реализации проектов по внедрению КИС, включающие

• подготовку проекта;
• проектирование;
• реализацию;
• подготовку к опытно-промышленной эксплуатации (далее - ОПЭ);
• ОПЭ;
• переход к продуктивной эксплуатации (далее - ПЭ)

и являющиеся общими для методологий ASAP, ADM, MDSS и стандартов . Допускается отсутствие этапа ОПЭ, тогда 4-я и 5-я фазы проекта будут обеспечивать подготовку к ПЭ и ПЭ соответственно. Рассмотрим документы каждого из этапов подробнее (рис.3).

Рис. 3.

2.1. Этап подготовки проекта

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

2.2. Этап проектирования

Завершив подготовку проекта, переходим к этапу проектирования системы. Качество, взаимосвязь и детализация проектируемых решений являются определяющим фактором успеха внедрения КИС. Допущенные на этапе проектирования ошибки устранить достаточно трудоемко. Начало этапа проектирования сопровождается подготовкой обучающих материалов и плана проведения обучения команды заказчика. Сформированная ранее концепция обучения проектной группы содержит лишь поверхностное содержание указанных документов. Далее проектная команда заказчика совместно со специалистами подрядчика участвует в обследовании бизнес-процессов клиента. Результатом анализа процессов являются функционально-технические требования, предъявляемые к проектируемой системе.

Требования заказчика сопоставляются со стандартным решением КИС (Fit-анализ) для выявления функционального дефицита (GAP-анализ). Функциональный дефицит требует доработки системы, для чего готовятся спецификации на разработку, содержащие постановку задачи и предлагаемый вектор решения. Разрабатывается концепция ролей и полномочий, определяющая перечень ролей пользователей и правила их создания и присвоения сотрудникам. Стандартный функционал КИС, спецификации на разработку и концепция ролей и полномочий необходимы для формирования проектных решений. Проектные решения содержат бизнес-процессы заказчика в моделях «как есть» и «как будет» с указанием доработок системы и ролей пользователей.

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

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

2.3. Этап реализации

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

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

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

2.4. Этап подготовки к опытно-промышленной эксплуатации

Реализация системы выполнена, и журнал проблем содержит незначительное число замечаний. Начинается подготовка к ОПЭ. Первоочередной задачей данного этапа является обучение конечных пользователей. Готовятся инструкции конечных пользователей (в разрезе бизнес-процессов или операций). Далее на их основе формируются сценарии обучения пользователей, включаемые в окончательный план обучения. Предполагаемый план обучения был создан ранее в контексте концепции обучения. Обучение пользователей проводится в условиях близких к реальным. Поэтому необходимо подготовить список участников и присвоить им реальные роли для выполнения тестовых упражнений. Тренинги являются своего рода тестированием системы, тем самым обновляется журнал проблем.

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

2.5. Этап опытно-промышленной эксплуатации

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

2.6. Этап перехода к продуктивной эксплуатации

Успешное завершение этапа ОПЭ позволяет говорить о переходе к ПЭ. Основное условие перехода – отсутствие замечаний в журнале проблем и обновление всей проектной документации по результатам исправления замечаний. Аналогично этапу подготовки к ОПЭ готовятся списки пользователей системы, планы перехода к ПЭ и миграции данных. Заполняются шаблоны загрузок данных. Создав пользователей в КИС, выполнив все операции из плана перехода и миграцию данных, начинается работа в режиме ПЭ. Начиная с этого момента, возникающие замечания и проблемы разрешаются силами группы поддержки клиента. На этапах же реализации, подготовки к ОПЭ и ОПЭ ошибки системы регистрировались в журнале проблем и исправлялись специалистами подрядчика.

3. Зависимость подготавливаемых документов от этапов проекта

Проектные документы утверждаются клиентом на этапе проектирования. В дальнейшем на фазах реализации, подготовки к ОПЭ и ОПЭ в журнале проблем отражаются замечания клиента к реализованному прототипу системы. Исправление замечаний журнала проблем состоит в обновлении и повторном согласовании документов, а также донастройки и демонстрации системы заказчику. Приведенный ниже рисунок показывает поток документов для процессов проектирования, обучения, перехода к использованию системы и миграции данных (рис.4). Допустим, по результатам тренинга было выявлено, что один из сценариев обучения противоречит требованиям. Каковы последствия?

Рис. 4.

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

Результаты и выводы

Рассмотрение методологий внедрения КИС, выявление типовых этапов имплементации систем, а также обзор проектной документации и зависимости документов от фаз проекта составляют основные результаты работы. Анализ методологий внедрения ИС позволил выделить фазы подготовки проекта, проектирования, реализации, подготовки к ОПЭ, ОПЭ и переход к ПЭ, являющиеся типовыми независимо от выбранного стандарта или методологии управления проектом. Описание проектной документации выполнено для каждого типового этапа имплементации КИС и наглядно представлено в виде каскадной схемы (рис.3). Дано краткое описание документов и порядок их подготовки. Основной акцент сделан на назначение документов, а не их содержание.

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

Литература

1. ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом. – М.: Стандартинформ, 2011. – 10 с.
2. Zandhuis A., Stellingwerf R. ISO 21500. Guidance on Project Management. A pocket guide. – NL.: Van Haren Publishing, 2013. – 148 p.
3. ANSI/PMI 99-001-2014. A Guide to the Project Management Body of Knowledge (PMBOK Guide). – Pennsylvan.: Project Management Institute, 2013 – 589 p.
4. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. – NJ.: Sybex Inc, 1999. – 591 p.
5. Kress R. Running IT Like a Business: A Step-By-Step Guide to Accenture"s Internal IT. – Ely: IT Governance Publishing, 2012. – 140 p.
6. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 p.
7. Проектирование информационных систем: учебное пособие / Гвоздева Т.В., Баллод Б.А. – Ростов н/Д.: Феникс, 2009. – 508 с.
8. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура. – М.: БИТЕК, 2012. – 498 с.
9. Степанов Д.Ю. Обзор логистических бизнес-процессов на примере закупочной деятельности предприятия // Логистика сегодня. – 2014. – т.65, №5. – c.208-228.
10. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268.

Для организации контроля в локальной сети нашей организации был выбран Kerio Control Software Appliance 9.2.4. Раньше эта программа называлась Kerio WinRoute Firewall. Рассматривать плюсы и минусы мы не будем, и почему выбран Керио, тоже, переходим сразу к делу. Программа версии 7 и выше устанавливается на голое железо без какой-либо операционной системы. В связи с этим подготовлен отдельный ПК (не виртуальная машина) со следующими параметрами:

Процессор AMD 3200+;

HDD 500Гб; (необходимо гораздо меньше)

— Сетевая карта – 2 шт.

Собираем ПК, вставляем 2 сетевых карты.

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

Скачиваем Kerio Control Software Appliance. (можно купить лицензию или скачивать образ с встроенным активатором)

Объем образа Керио не превышает 300Мб, размер флэшки соответствующий.

Вставляем флэшку в USB разъем ПК или ноут-бука.

Форматируем в FAT32 средствами Windows.

Запускаем UNetbootin и выбираем следующие настройки.

Дистрибутив – не трогаем.

Образ – Стандарт ISO, указываем путь к скаченному образу Керио.

Тип – Устройство USB, выбираем нужную флэшку. ОК.

После некоторого времени создания, загрузочная флэшка готова. Жмем выход.

Вставляем загрузочную флэшку в подготовленный ПК, включаем его и в Boot menu выбираем загрузку с USB-HDD. В начавшейся загрузке выбираем linux.

Начнется установка Kerio Control Software Appliance 9.2.4. Выбираем язык.

Читаем лицензионное соглашение.

Принимаем его, нажав F8.

Вводим код 135. Программа предупреждает о том, что жесткий диск будет отформатирован.

Ждем пока идет установка.

Система перезагрузится.

Снова ждем.

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

Мы пока этого делать не будем, а переходим в Конфигурацию сети в самом Керио.

Конфигурация сетевого интерфейса Ethernet. Отмечаем пробелом – Назначить статический IP-адрес.

И назначаем его.

IP-адрес: 192.168.1.250

Маска подсети: 255.255.255.0

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

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

https://192.168.1.250:4081/admin. Браузер может сообщить что Возникла проблема с сертификатом безопасности этого сайта. Нажимаем ниже – Продолжить открытие этого веб сайта и попадаем в мастер активации.

Анонимную статистику, конечно же, не передаем, убираем галочку.

Вводим новый пароль администратора.

Вот и всё. Здравствуй Керио.

Нужно отметить, что выбранный IP-адрес 192.168.1.250 для сетевой карты внутренней сети решено было изменить на адрес 192.168.1.1 для того, чтоб не перенастраивать много оборудования. Сеть существовала долгое время без контроля и Керио пришлось в неё добавить методом встраивания. После смены IP чтоб попасть в интерфейс нужно вводить https://192.168.1.1:4081/admin. Ниже на рисунке структурная схема подключения.

Первоначально, все функции маршрутизации и DNS выполнял модем с IP –адресом 192.168.1.1. При установке Керио модему назначили адрес 192.168.0.1 и он обращается к внешней сетевой карте Керио с адресом 192.168.0.250. Адреса в одной подсети. Внутренняя сетевая карта получила адрес, который раньше был у модема. Всё оборудование в сети со статическими IP-адресами и прописанным шлюзом (а это почти вся наша сеть) увидело новый шлюз как старый и даже, не заподозрило подмены:)

При первом запуске Керио, мастер предлагает настроить интерфейсы. Можно настраивать не через мастера. Рассмотрим подробнее всё, что описано выше.

Во вкладке интерфейсы выбираем пункт Интернет-интерфейсы.

Придумываем название типа Внешняя сеть или Интернет, по умолчанию написано WAN. Вводим вручную данные IP адреса, маску, шлюз и DNS, всё в одной подсети с модемом. ОК.

Далее выбираем следующее подключение в пункте Доверенные/локальные интерфейсы – наша внутренняя сеть. Эти пункты в зависимости от версии Керио могут называться по другому. Придумываем имя и вносим данные как на картинке ниже. Внешняя и внутренняя сеть не могут находится в одной подсети. Это не нужно забывать. DNS от Керио. Шлюз не пишем. ОК.

Нажимаем кнопку Применить в нижней правой части экрана, настройки активируются. Проверим подключение к Интернету. Интернет работает.

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

Рассмотрим еще один важный момент – это открытие портов. До установки Керео в модеме были проброшены порты на сервер. Так же изначально необходимые порты были открыты в самом сервере. Без этих портов спец. софт сервера не может нормально работать. Рассмотрим открытие порта 4443.

Модем HUAWEI HG532e, заходим в него, для этого в адресной строке браузера вводим 192.168.0.1. Переходим по вкладкам Advanced—>NAT—> Port Mapping и вносим данные как на картинке ниже.

Интерфейс – наше подключение (в режиме роута кстати).

Протокол – TCP/UDP.

Remote host – ничего.

External start port/end port – 4443 (внешний порт).

Internal host – 192.168.0.250 (адрес внешней сетевой карты Керео).

Internal port – 4443 (внутренний порт).

Mapping name – любое понятное имя.

Принцип действия таков, что обращение из интернета на внешний статический IP-адрес к порту 4443 будет переадресовано к внешней сетевой карте Керио. Теперь нужно сделать так, чтоб запрос с внешней сетевой карты перенаправлялся на внутреннюю сетевую карту и далее к нашему серверу на порт 4443. Это делается с помощью создания двух правил. Первое правило разрешает доступ извне, второе правило разрешает доступ изнутри.

Создаем эти два правила на вкладке Правила трафика. Разница в пунктах источник и назначения. Служба – наш порт 4443. см. картинку выше.

В пункте Трансляция делаем настройки как на картинке ниже. Отмечаем галочкой — Адрес назначения NAT и пишем там IP-адрес сервера назначения и нужный порт. ОК.

Нажимаем применить. Проверяем, открылся ли порт в он-лайн сервисе. Порт открыт.

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

О прочих настройках Kerio Control Software Appliance возможно будет написано в других статьях.

(подключение по оптике)

Путь к архиву показан на нижеследующих изображениях:

Предположим, что вы осуществляете переход с последней версии KWF 6.7.1, ваша цель - работающая версия Kerio Control Appliance 8.3 (актуальная версия приложения на Апрель 2014 года)

Основной «сложностью» перехода в данном случае является необходимость выполнять не прямое обновление с версии KWF 6.7.1 на Kerio Control 8.3, а последовательный переход на некоторые «мажорные» (major) версии. Данная необходимость обусловлена включением в конфигурационные файлы этих «мажорных» версий некоторых возможностей, которые требуют постобработки после установки приложения.
Для осуществления перехода с версии KWF 6.7.1 на версию Kerio Control 8.3 потребуется выполнить следующие шаги обновления:

1. Обновление до версии Kerio Control 7.0.0
2. Обновление до версии Kerio Control 7.1.0
3. Обновление до версии Kerio Control 7.4.2 (финальная версия для Windows)

Загрузить необходимые дистрибутивы вы сможете из нашего архива релизов .
Сам процесс обновления от версии к версии является обычной установкой новой версии «поверх» старой. Программа установки автоматически завершит работу системной службы Kerio Control (Kerio Winroute Firewall), определит директорию установки текущей версии Kerio Control (Kerio Win-route Firewall) и произведёт замену файлов приложения, требующих обновления; файлы протоколов приложения и пользовательской конфигурации сохраняются без изменений. Файлы конфигурации будут сохранены в специальной директории «UpgradeBackups», расположенной в корне директории %programmfiles%\Kerio\.

Видео ролик штатного процесса обновления:

Переход на последнюю Windows-версию Kerio Control 7.4.2 будет финальным шагом обновления в рамках данной платформы. Следующими этапами перехода является подготовка Appliance платформы, перенос конфигурации, базы журналов и пользовательской статистики.

Переход на платформу Appliance.

В данном разделе мы рассмотрим варианты разворачивания различных Appliance-дистрибутивов Kerio Control.

Установка Software Appliance

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

• ISO образ может быть записан на физический CD или DVD носитель, который в дальнейшем необходимо использовать для установки Kerio Control на физический или виртуальный хост.
• В случае использования виртуальных ПК, ISO-образ можно подключить как виртуальный CD/DVD-ROM для совершения установки с него, без необходимости записи на физический носитель.
• ISO образ можно записать на USB-flash накопитель и произвести установку с него. Для уточнения инструкций, обратитесь к соответствующей статье (kb.kerio.com/928) в нашей базе знаний.

Установка VMware Virtual Appliance

Для установки Kerio Control VMware Virtual Appliance на различные средства виртуализации от компании VMware, используйте соответствующий вариант дистрибутива Kerio Control VMware Virtual Appliance:

Для VMware Server, Workstation, Player, Fusion используйте заархивированный(*.zip) VMX файл:

Установка виртуального модуля в VMware player

• Для VMware ESX/ESXi/vSphere Hypervisor используйте специальную OVF-ссылку для импорта виртуального модуля, имеющую вид:

http://download.kerio.com/en/dwn/control/kerio-control-appliance-1.2.3-4567-linux.ovf

VMware ESX/ESXi автоматически загрузит OVF-конфигурационный файл и соответствующий ему образ виртуального жёсткого диска (.vmdk)
При использовании OVF формата необходимо учитывать следующие аспекты:

• В виртуальном модуле Kerio Control синхронизация времени с сервером виртуализации отключена. Однако Kerio Control обладает встроенными инструментами синхронизации времени с публичными сетевыми источниками времени Интернета. Таким образом, использование синхронизации между виртуальной машиной и сервером виртуализации необязательно.
• Задачи «отключения» и «перезапуска» виртуальной машины будут выставлены в значения «по умолчанию». Возможность установления этих значений в режим «принудительного» отключения и «принудительного» перезапуска сохранена, однако данные варианты отключения и перезапуска могут стать причинами потери данных в виртуальном модуле Kerio Control. Виртуальный модуль Kerio Control поддерживает т.н. «мягкое» отключение и «мягкую» перезагрузку, позволяющие выключить или перезагрузить гостевую ОС правильным образом, поэтому рекомендуется использовать значения по умолчанию.

Установка виртуального модуля (ovf) в VMware vSphere

Установка Virtual Appliance для Hyper-V

• Загрузите заархивированный (*.zip) дистрибутив, распакуйте его в нужную папку.
• Создайте новую виртуальную машину, выберите опцию «Использовать имеющийся виртуальный жёсткий диск», указав в качестве образа диска файл, распакованный из загруженного архива

Установка виртуального модуля в MS Hyper-V

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

Настройка сетевых интерфейсов в Software Appliance

В псевдографическом интерфейсе Kerio Control Software Appliance доступны возможности настройки IP адреса/множества адресов в статическом или динамическом режиме, создание VLAN интерфейсов и возможность настройки интерфейса в режиме PPPoE.

Примечание: Первоначальная настройка сетевых интерфейсов в самом дистрибутиве Kerio Control Software Appliance идентична для всех сборок Kerio Control Appliance, отличия есть только при настройке виртуальных сетевых интерфейсов в различных средах виртуализации, где может применяться Kerio Control.

Подготовка виртуальных сетевых интерфейсов в Hyper-V

Для выполнения корректной и минимально необходимой настройки виртуального коммутатора Hyper-V вам потребуется выполнить следующие шаги:

Сопоставление физических и виртуальных сетевых интерфейсов

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

Для ознакомления с вариантом быстрой настройки сетевых интерфейсов Kerio Control Hyper-V virtual Appliance просмотрите следующий видео ролик:

Подготовка виртуальных сетевых интерфейсов в VMware vSphere

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

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

Создание виртуального коммутатора в VMware vSphere

Создание виртуального коммутатора в VMware vSphere

Добавление соответствующих физических сетевых интерфейсов к виртуальным коммутаторам, для возможности взаимодействия с ними физической ЛВС предприятия

Сопоставление созданных виртуальных коммутаторов с виртуальными сетевыми интерфейсами Kerio Control VMware Virtual Appliance

После того, как Appliance сборка была развёрнута и была произведена настройка сетевых интерфейсов, вы можете перейти к переносу основной пользовательской конфигурации с вашей Windows версии Kerio Control.
Сам процесс переноса конфигурации состоит из двух шагов:

Сохранение текущей конфигурации с использованием помощника конфигурирования

При выполнении сохранения конфигурации рекомендуется запомнить, а лучше выписать, MAC-адреса Ваших текущих сетевых интерфейсов и их соответствие используемым IP-адресам. Это понадобится при восстановлении конфигурации на новой установке Kerio Control Appliance.

Процесс сохранения конфигурации показан на приведённых ниже изображениях:

После этого шага вы сохранили архив, включающий в себя все файлы пользовательской конфигурации текущей версии Kerio Control.

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

Примечание: Это именно тот момент, когда Вам понадобится информация о MAC и IP-адресах со старого сервера, которую Вы выписали или запомнили при сохранении конфигурации на старом.

Процесс восстановления конфигурации показан на приведённых ниже изображениях:

Для сохранения конфигурации сервер Kerio Control Appliance выполнит автоматическую перезагрузку, после чего его можно будет использовать.

И вот тут начинается самое интересное! То, что вы будете читать ниже, не описано ни в одной официальной, да и в неофициальной документации, т.е. тут будет помещено несколько приемлемых «лайв хаков», использование которых поможет вам в выполнении столь важного процесса, перехода на Appliance платформу Kerio Control.

И как обычно, прежде, чем мы перейдём с вами к непосредственному описанию, привычный «дисклэймер»:

ВАЖНО: Описанная ниже процедура не является документированной возможностью, поэтому во избежание нежелательных последствий, прежде, чем Вы начнёте выполнять перенос данных, создайте их полную резервную копию путём копирования данных на защищённое хранилище.

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

%programfiles%\kerio\winroute firewall\logs\*

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

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

%programfiles%\kerio\winroute firewall\star\data\

Оттуда нам нужен лишь файл star.fdb . Для лучшей сохранности этих данных перед выполнением переноса рекомендуется выполнить резервную копию на доступное безопасное хранилище.

После того, как мы обнаружили и сохранили всю необходимую информацию, нам необходимо её перенести на новый сервер, работающий под управлением Kerio Control Appliance, для этого первое, что вам потребуется сделать для загрузки сохранённых ранее данных на Kerio Control Appliance, это включить SSH сервер для выполнения SFTP доступа. Для этого в веб-интерфейсе администрирования Kerio Control перейдите в меню Состояние -> Состояние системы , нажмите и держите клавишу “Shift” и щёлкните по кнопке «Действия ». В раскрывшемся списке выберите пункт «Включить SSH », подтвердите ваши действия, согласившись с вопросом в появившемся окне.

После этого необходимо удостовериться, что в правилах трафика Kerio Control Вы разрешили доступ к хосту Kerio Control Appliance по протоколу SSH из нужного Вам местоположения.

После того, как Вы включили SSH и разрешили соответствующий доступ, Вам необходимо выполнить подключение к серверу Kerio Control Appliance для загрузки на него необходимых данных протоколов и базы данных пользовательской статистики. Для этого мы будем использовать приложение WinSCP, которое позволяет выполнять подключения по протоколу SFTP.
Для подключения к серверу Kerio Control Appliance необходимо указать имя пользователя и пароль доступа, в качестве имени пользователя укажите имя “root” (без кавычек); в качестве пароля укажите пароль встроенной в Kerio Control учётной записи “Admin”.

Параметры sFTP подключения к серверу Kerio Control

После установления подключения необходимо разместить Ваши данные в определённых папках сервера. Файлы протоколов необходимо скопировать в папку /var/winroute/logs , а файл пользовательской статистики в папку /var/ winroute/star/data , при этом старые файлы необходимо либо удалить, либо переименовать.

Примечание: Лучше переименовать старые файлы, для сохранения резервной копии текущих данных. В случае файлов протоколов приложения переименовывать надо лишь старые файлы с расширением *.log

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

Для перехода из псевдографической консоли к интерфейсу командной строки, нажмите комбинацию клавиш “Alt-F2”. В приглашении на введение имени пользователя укажите имя “root” (без кавычек), нажмите “enter”, в поле пароль введите пароль встроенной в Kerio Control учётной записи «Admin».

Примечание: необходимо учесть, что в ОС семейства Linux введение пароля не отображается даже значками астериска, и если Вы допустили ошибку, исправить её будет нельзя - придётся вводить пароль заново.

В приглашении на ввод команды введите следующее:

/etc/boxinit.d/60winroute restart

Эта команда выполнит перезапуск демона (службы) Kerio Control, после чего Kerio Control «подцепит» скопированные ранее данные протоколов приложения и пользовательской статистики.

После старта демона Kerio Control, необходимо проверить целостность перенесённых данных, для этого можно воспользоваться веб-интерфейсом пользовательской статистики и/или веб-интерфейсом администрирования приложения Kerio Control.

Если со всеми данными всё в порядке, то можно считать переход на новую платформу Kerio Control Appliance завершённым и осталось лишь выполнить штатную процедуру обновления Kerio Control до актуальной на текущий момент версии. Если же с какой-то частью данных «не всё в порядке», то есть два варианта:
1) удостовериться, что данные взятые с исходного сервера Kerio Control (KWF) были изначально в порядке;)
2) если с исходными данными всё ок, то необходимо повторить процедуру переноса той части данных с которыми были проблемы.
3) если решения из пп. 1 и 2 не помогли, то оставьте тут комментарий, попробуем разобраться вместе:)

Теперь, когда все важные данные на своих местах, можно «подтянуть» версию Kerio Control Appliance до актуальной. Штатный процесс обновления может проходить двумя способами, в автоматическом и ручном режимах.

Автоматический режим обновления версии.

Kerio Control может выполнять автоматическую проверку наличия новых версий на сайте обновления компании Kerio.

1. Дополнительные опции », во вкладку «Проверка обновлений »
2. Включите опцию «Периодически проверять наличие новых версий ». Kerio Control будет проверять наличие новых версий каждые 24 часа. Как только будет установлено наличие новой версии, на вкладке «Проверка обновлений » будет отображена ссылка для загрузки обновления. Для того чтобы проверить наличие обновления незамедлительно, щёлкните по кнопке «Проверить сейчас »
3. Если Вы хотите загружать обновлённые версии сразу же после их обнаружения, включите опцию «Загружать новые версии автоматически ». Как только новая версия будет загружена, Вы получите соответствующее уведомление в веб-интерфейсе администрирования.
4. После загрузки обновления нажмите кнопку «Обновить сейчас »
5. Подтвердите Ваше намерение произвести обновление и выполнить последующую автоматическую перезагрузку Kerio Control
6. Дождитесь завершения установки новой версии и перезагрузки Kerio Control.
7. Обновление завершено.

Ручной режим обновления версии.

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

• Откат на предыдущую версию Kerio Control
• Обновление на промежуточную или не очередную версию (например, закрытый Beta релиз).
• Обновление шлюза при наличии максимальных ограничений для МСЭ на доступ к ресурсам сети Интернет.

Для выполнения обновления в ручном режиме Вам необходимо загрузить специальный образ (Upgrade Image) со страницы загрузки Kerio Control (http://www.kerio.ru/support/kerio-control).

После загрузки выполните следующие шаги:

• В веб-интерфейсе администрирования перейдите в пункт меню «Дополнительные опции », во вкладку «Проверка обновлений »
• Щёлкните по кнопку «Выбор »
• Укажите местоположение файла образа обновления (kerio-control-upgrade.img)
• Щёлкните по кнопке «Загрузить файл обновления версии »
• После загрузки щёлкните по кнопке «Начать обновление версии »
• Дождитесь обновления версии и перезагрузки Kerio Control
• Обновление завершено.

Вуаля, у вас полноценный интернет шлюз на базе Kerio Control Appliance! Поздравляем вас с завершением процесса перехода на UTM Kerio Control!

Только зарегистрированные пользователи могут участвовать в опросе.

Анонсировала выпуск обновленной версии своего флагманского продукта - межсетевого экрана Kerio Control. Новая версия 9.1 получила ряд усовершенствований и новых возможностей. Наверное, главной особенностью данного релиза стала функция автоматического обновления межсетевого экрана. Это позволяет автоматизировать процесс развертывания новой версии в уже имеющейся сетевой инфраструктуре. Кроме того, инженеры компании дополнили свое комплексное решение в области сетевой безопасности для малых и средних компаний некоторыми новыми возможностями, среди которых - контроль приложений и безопасная фильтрация контента. Отметим, что основной релиз Kerio Control 9.0 состоялся в конце прошлого года. Девятая по счету версия межсетевого экрана привнесла в продукт функции Shared definitions в MyKerio, защиту от атак типа «отказ в обслуживании», двухфакторную авторизацию для сервиса MyKerio и многое другое. Но обо всем по порядку.

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

Отметим, что при первичной установке системы на компьютер или виртуальную машину пользователю по умолчанию предлагается добавить новый Kerio Control в сервис MyKerio для последующего удаленного управления им.

Впоследствии администратор может активировать работу сервиса MyKerio на межсетевом экране из отдельного меню «Удаленные службы».

Напомним, что сервис MyKerio появился у продуктов Kerio не так давно, но уже сейчас понятно, что эта возможность очень удобна для работы с несколькими межсетевыми экранами и продуктами Kerio. Стоит отметить, что кроме добавления межсетевого экрана из панели администратора существует возможность подключить Kerio Control по его серийному номеру и номеру лицензии. Этот сервис поддерживает двухфакторную авторизацию с помощью таких популярных приложений, как Google Authenticator и FreeOTP Authenticator для повышения уровня безопасности облачного централизованного web-интерфейса, что позволяет IT-администраторам настроить в качестве дополнительной формы проверки подлинности код из шести цифр с синхронизацией по времени. Владельцы предприятия могут быть уверены, что сетевая безопасность будет сохранена даже в таком маловероятном случае, когда пароли окажутся в чужих руках.

Сервис MyKerio позволяет удаленно управлять межсетевыми экранами Kerio Control и, что немаловажно, переносить часть настроек с одного на другой. Так администраторам доступна функция переноса групп URL, диапазонов IP-адресов и временных интервалов. Все эти возможности в сервисе управления имеют название «Shared definitions» и, вполне возможно, в следующих версиях Kerio Control их список будет расширен. Для оперативного устранения проблем и информирования администраторов на основном экране отображаются важные уведомления о работе подключенного межсетевого экрана.

Что же касается обновленной версии Kerio Control 9.1, то в нее была добавлена возможность автоматического создания резервных копий настроек Kerio. Если ранее резервные копии настроек можно было загружать на сервис Samepage.io или на FTP, то теперь эта функция доступна только для FTP и сервиса MyKerio. Централизованное хранилище настроек позволяет существенно упростить развертывание Kerio Control на ПК и виртуальных машинах после возможных сбоев или при установке межсетевого экрана с чистого листа.

В новой версии Kerio Control 9.1 также предлагается приложение MyKerio для iPhone и Apple Watch, обеспечивающее мониторинг и уведомления в реальном времени для всех подключенных устройств. При изменении состояния немедленно подается уведомление, что позволяет быстро устранить любые проблемы.

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

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

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

Выводы

Как и всегда, компания Kerio старается максимально упростить работу системных администраторов и в то же время обеспечить высочайшую защиту посредством своего межсетевого экрана Kerio Control. Обновленная версия, безусловно, привнесла одну из самых ожидаемых функций по автоматическому обновлению этой системы, поэтому можно не сомневаться, что она будет востребована конечными пользователями. Будем надеяться, что выпуск приложения по удаленному управлению MyKerio для устройств на базе Android не заставит себя ждать, ведь в век Интернета эта возможность всегда окажется кстати. Последнюю версию Kerio Control, как всегда, можно скачать на официальном сайте компании.