Корпоративная сеть на ЗЖБК "Ковальская"

Автор Nikita Olenets 20 августа 2011 03:59

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

Для начала была получена карта действующей инфраструктуры и её минусы в текущей редакции. После снятия требований к будущей сетевой инфраструктуре, мы приняли решение по построению сети на базе оборудования Juniper SRX.

Первоначально сетевая инфраструктура была определена как центральное отделение и пять филиальных структур. По требованиям заказчика, сеть должна функционировать постоянно. Для этого существовуют резервные каналы связи, хоть они и обладают гораздо меншей пропускной полосой, но этого втполне достаточно для непрерывной работы бизнес приложений внутри организации. Так как большинство каналов связи арендуются у сторонних сетевых операторов, перед нами встал ещё и вопрос о конфиденциальности передачи информации между филиалами предприятия. Так как в центральном офисе предприятия были сформированы основные ИТ активы, было принято решение об установке устройства Juniper SRX240, а данной схеме он наилучшим образом подходил для такой задачи. Устройство представляет собой маршрутизатор безопасности с 16-тью медными гигабитными интерфейсами. Так же данной устройство обладает достаточным запасом производительности на будущее, а именно два ключевых параметра - 1,5Гб/с производительность файервола и 300Мб/с производительность VPN IPsec.

К филиалам предприятия были выдвинуты более просты требования к производительности.

В таким местах мы предложили использовать младшую модель Juniper SRX100, у которого производительность файервола 700Мб/с, а максимальная заявленая пропускная полоса для VPN IPSec тунелей составляет 60Мб/с. Плюсом выбора данных моделей в качестве ключевых устройств была большая производительность, а так же возможность (дополнительно приобретя лицензии) добавить в будущем функционал IDP, Antivirus, Web Filtering.

Что же касается технической реализации сетевой подсистемы, мы организовали IPSec VPN подключения между всеми узами. Так как между филиалами уже существовал выделенный L2 канал, к тому же он считался мастер подключением. Мы использовали его как основной канал для связи с другими филиалами. Второстепенный канал был организован через Интернет подключение, которое существовало в каждом филиале, а в центральном таких подключений было целых два.

С практической стороны, такой подход позволил использовать максимальное кол-во времени только канал L2, соединяющий все узлы. Маршрутизация в сети и переключение на резервные каналы построена на функциях протоколоа маршрутизации OSPF, в отличии от некотоых других сетевых вендоров, для использования данного протокола поверх IPSec тунеля не требует каких либо не стандартных конфигураций.

В итоге мы получили достаточно отказоустойчивую распределенною сетевую инфраструктуру. Законы Мерфи гласят «Если неприятность может случится, она обязаьельно случится», и вообщем то не заставила себя долго ждать. Буквально через несколько недель у местного оператора L2 связи приключилась авария и все L2 соединения стали одновременно не доступны. Благодаря динамической маршрутизации, преприяти продолжило свою операционную деятельность, хоть и с небольшой деградацией сервиса. Но цель  была достигнута. Механизм работает, как часы.

За сим откланиваюсь. 

Теги:

Сетевые решения

Установка SRX 100 и 200 в Network Security Manager

Автор Maria Parashuta 12 августа 2011 19:30

После того, как Juniper объявил о снятии с производства такой замечательной и удобной линейки NetScreen под управлением ScreenOS, а также следом за ней и линейки младших устройств SSG, многие пользователи были слегка озадачены и озабочены, как быть дальше? Успев оценить удобство, стабильность работы и надёжность устройств этого вендора, а главное простоту настроек и администрирования, резонно возникал вопрос – а будет ли так удобен аналог предлагаемый производителем? Тем более, что и операционная система на них другая. Особенно обеспокоены те, были те пользователи, которые, уже имея парк оборудования на Screen OS, вынуждены устанавливать новые устройства SRX в уже существующую инфраструктуру. И уж совсем тревожно было тем, у кого для управления всем опорным сетевым оборудованием использовалась система управления Network Security Manager.

Но Juniper Networks не зря является одним из ведущих игроков ИТ рынка в области безопасности и активного сетевого оборудования. Juniper еще в 2006 году заявлял, что в его стратегические планы входит переход на единую операционную систему на всех сетевых устройствах. И этой операционной системой после долгих тестов была выбрана JunOS. Поэтому и Netscreen и SSG со ScreenOS ушли с ИТ рынка. Безусловно, выводя с рынка один продукт и продвигая его аналог, производители предусмотрели все скользкие моменты совместимости. И оборудование с JunOS управляется системой управления наряду с устройствами под ScreenOS. Так что не стоит переживать, а лучше активно осваивать новые устройства, которые обладают более богатым функционалом, и активно развиваются производителем. Но, как и в любом подобном случае, есть некоторые нюансы.

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

  1. Использовать рекомендованную вендором и поддерживаемую системой управления версию JunOS
  2. Устройство должно быть предварительно настроено для поддержки управления через систему управления.

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

Но и в этой версии устройства поддерживаются только со старой прошивкой – 10.0. При этом не с базовой схемой 43 версии, а после проведения обновления схемы хотя бы до версии 119, которая идет в комплекте с NSM 2010.1. А лучше всего обновить всю систему управления до версии 2011.1. В этой версии со схемой по умолчанию – 166 – максимальный поддерживаемый релиз 10.4. Хотя на сайте производителя уже выложен релиз 11.1R2.3.

И только обновление до схемы 192 позволит нам использовать последний релиз JunOS. Хотя, проведя обновление на двух серверах, нам пришлось отказаться от этой заманчивой идеи. Так как обновление схемы привело к плачевному результату – перестали видеться системой все релизы операционных систем. И как результат, не возможно стало управлять ни одним устройством, ну и добавить новые, тоже стало не возможно.

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

1. Зайти через ssh на сервер где установлен GuiServer и отредактировать файл /usr/netscreen/GuiSvr/var/guiSvr.cfg

Изменить строчку с переменной

guiSvrDirectiveHandler.max.heap 1024000000

на

guiSvrDirectiveHandler.max.heap 1536000000

2. Зайти через ssh на сервер где установлен DevServer и отредактировать файл /usr/netscreen/DevSvr/var/devSvr.cfg

Изменить строчку с переменной

devSvrDirectiveHandler.max.heap 1024000000

на

devSvrDirectiveHandler.max.heap 1536000000

3. Зайти через ssh на сервер где установлен DevServer и отредактировать файл /usr/netscreen/DevSvr/var/be/cfg/SWRPCInfo.prop

Изменить строчки с переменными на значения указанные ние

get-re-info.response.retry=60

request-package-add.response.retry=10

request-reboot.response.retry=10

К сожалению нам эта процедура не помогла. Пришлось провести откат на стандартный релиз и остановиться на самом стабильном варианте NSM версии 2011.1 со стандартной семой – 166. Версия JunOS, поддерживаемая этой связкой - junos-srxsme-10.4R4.5-domestic.

После всех перепитий с обновлениями схемы и установкой соответствующей операционной системы на устройства остался последний шаг – предварительная настройка устройств для работы с системой управления.

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

root> edit

[edit]
root#

И вводим необхдимы для работы с системой управления команды

[edit]
root# set system services netconf ssh

root# set system services ssh protocol-version v2

[edit]
root# commit and-quit

commit complete

Далее добавляем устройство в систему управления, как ранее добавляли Net Screen или SSG.

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

root> show configuration | display set

Теги: , ,

Сетевые решения

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

Автор Illya Golovatsky 22 июля 2011 00:43

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

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

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

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

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

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

  1. Первая – это наличие у администраторов клиентов ко всем используемым средствам;
  2. Вторая – это поддержка базы данных – на каком компьютере какое средство стоит;
  3. Третья – никто не знает, кто именно и что именно устанавливал. Легко спутать ПО установленное хакером – за новое ПО установленное другим администратором. И таким образом оставить хакера делать свои дела в вашей сети, еще на час-день-неделю...

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

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

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

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

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

Теги:

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

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

Автор Nikita Olenets 13 июля 2011 20:16

Для начала немного сухой теории про систему управления NSM Express

Система управления Juniper NSM (в настоящее время переименована в NSM Express) является коплексом для управления и мониторинга устройств под управлением ОС JunOS или ScreenOSОна написана на языке Java и представляет собой три компонента -GuiSVR, DevSVR, HaSVRКаждому приложению (процессу) отведена отдельная задача.

GuiSVR – главный процесс, отвечает за принятие запросов от GUI клиентов, а так же DevSRV процессов и GuiSVR суб-процессов. Также отвечает за функциональность базы данных и предоставляет доступ к базе из других процессов.

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

HaSVR – процесс, который может быть запущен на одиночном устройстве или в отказоустойчивом кластере устройств с NSM, отвечает за управление функциями локального бекапирования базы данных, а также следит за процессами GuiSRV и DevSRV и в случае их креша, производит попытки перезапустить процессы.

Хранение информации об устройствах, их конфигурации выполняется в базе данных PostreSQL. Отдельная хвала разработчикам из команды Juniper за то, что выбрали именно эту СУБД, она является приложением с открытым исходным кодом и хорошо документирована. Мало того, в Интернет-комьюнити PostgreSQL имеется огромное кол-во документации по решению практически любых задач, от простых манипуляций с данными, до не тривиальных операций по восстановлению целостности базы вцелом.

К нам в лабораторию был доставлен «пациент» - старенький сервер - с системой управления такой старой версии, что была, скорее, даже древнее самой аппаратной части J

Была задача - в факультативных рамках определить степень «старости» системы и сделать все возможное, чтобы произвести обновление до более современной версии. Замечу, что разработчики не стояли на месте, выпуская постоянные релизы системы NSM. К нашему сожалению, задача ещё и усложнялась тем, что файл лицензии в закромах наших заказчиков все никак не находился.

Базовая лицензия, доступная партнерам Juniper, предоставляет возможность установить NSM с кол-вом поддерживаемых устройств до 25-ти. У заказчика же имелось 200. Поэтому нам терять время попросту было недопустимо. Небольшой брейншторм дал свои результаты: было решено, что для препарирования системы без нарушения оперционной деятельности сделать точную копию рабочей системы и затем сконвертировать её в среду виртуализации. Для конвертирования мы использовали пакет Acronis. Для виртуализации мы решили взять одну из доступных и удобных систем. У нас на выбор были предоставлены VMWare ESXI, Microsoft Hiper-V и VirtuaBox. Первоначально задача была воспринята как тривиальная. Но позже выяснилось, что Hiper-V  не с текущей версией Linux RHEL 4.4 никак не сдружиться по причине отсутствия даже минимально набора драйверов (а именно: сетевой карточки). Следует заметить, что в полученном «пациенте» (сервер с NSM) числилось ни много, ни мало - около 200 устройств. Полный слепок системы занимал у нас около 150 Гб. Данных достаточно много, чтобы было комфортно их переносить на серверные платформы виртуализации. Поэтому, попробовав одну из оных Microsoft Hyper-V, и не преуспев в этом эксперименте, мы решенили использовать десктопную версию системы виртуализации. Ею оказалась система VirtualBox, первоначально разрабатываемая компание SUN, но затем дружно вместе и с самой операционной системой Solaris была отдана на попечение компании ORACLE.

Итак, что мы имеем: 

  • Виртуализированную полностью рабочую систему управления NSM (хоть и довольно устаревшую) в систему VirtualBox.
  • Отсутствие какого либо намека на наличие файла лицензий.

Начало казалось слишком простым, запуск и поверхностное тестирование валидности переноса системы NSM не вызвало нареканий. За исключением того, что в полученной системе значилось “Installation-ID INVALID”. Для справки - Installation-ID генерируется при установке системы, затем отсылается в Juniper для получения лицензионного файла.

Благо, что рабочая система продолжала выполнять свои функции в операционном режиме, а так же имея сведения, что Installation-ID генерируется в большинстве случаев по двум признакам, это MAC адрес сетевого адаптера и ОБЯЗАТЕЛЬНО серийным номером BIOS.

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

VBoxManage setextradata WinXP  VBoxInternal/Devices/pcbios/0/Config/DmiSerial "LXA5505A7461508E132500"

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

/usr/sbin/dmidecode | egrep -i 'BIOS Information'

По факту же, для корректного отображения серийного номера, нужно  внести имезения в файл Virtual_Machine_Filename.vbox следующего содержания:

<ExtraDataItem name="VBoxInternal/Devices/pcbios/0/Config/DmiSystemSerial" value="string: LXA5505A7461508E132500"/>

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

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

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

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

Теги:

Сетевые решения

Угрозы пользовательских прокси в сети

Автор Illya Golovatsky 7 июля 2011 22:36

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

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

Обращаясь к сервисам за анонимностью, вы осознанно даете разрешение на модификацию передаваемых данных в Интернет. Вы ведь хотите, чтоб удаленный сервер убрал из ваших запросов информацию о вашем IP-адресе, версии браузера, имени компьютера и кто знает, какие еще заманчивые перспективы посулят вам, чтоб вы использовали этот сервис. Модифицируя ваши запросы в сеть и идущие к вам ответы от различных сайтов, нет никаких преград перехватить переданные вами данные, встроить троянскую программу или бота. Вы ведь сами за этим пришли к ним. А в большинстве случаев вам сразу предлагают скачать клиентское ПО, которое будет передавать ваш трафик в зашифрованном виде. Кто знает, что еще они будут передавать с вашего компьютера?

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

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

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

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

Теги:

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

Виртуализация с Microsoft Hyper-V Server

Автор Maria Parashuta 5 июля 2011 22:19

Майкрософт как всегда, свято соблюдает свои традиции. Несмотря на то, что их операционные системы слывут «системами для домохозяек», но установка и настройка некоторых из них настолько нетривиальна, что далеко не каждая домохозяйка справится с этим непосильным трудом. Возьмем, например, замечательный продукт, так продвигаемый Microsoft в последнее время – Hyper-V Server 2008 R2. Казалось бы, что о виртуализации не писал и не говорил только самый ленивый. В том числе и о виртуализации от Microsoft. Но в очередной раз услышав от своих партнеров вопрос о том, а что же делать с этим голубым экраном с пятнадцатью менюшками и командной строкой, и где же тут создавать виртуальные машины, я поняла, что разговоров было все-таки не достаточно. И разговоров именно о практическом применении. Конечно, поискав в интернете можно найти разнообразные советы то от одного гуру, то от другого. Похоже, что лично мне удалось наступить на все возможные «грабли» при установке и первичной настройке этого чуда от Microsoft. Поэтому мне бы хотелось собрать все полезные советы в одну небольшую статью и описать возможные подводные камни в установке и администрировании виртуальной платформы Hyper-V Server 2008 R2.

Начнем с того, что, не смотря на утверждение, что это самостоятельный продукт, базируется он все же на ядре Windows 2008. Причем, хочу сразу обратить внимание, что это не привычный для нас Windows с «дружественным интерфейсом» а так называемая Core версия, где для истинных любителей непростых путей решения простых задач есть только командная строка. Если ранее не доводилось управлять операционной системой из «повер шелла», придётся немного поломать голову. И учтите, это не линуксовая командная строка. Маны тут не помогут. Так что, не обольщайтесь, и не надейтесь, что поставив Hyper-V Server 2008 R2 вам удастся сходу с ним подружиться.

Ну вот, прокликав все необходимые «Next» мы установили очень даже быстро систему на наше железо. Заходим и видим два окна:

1.       Черное с Windows PowerShell — расширяемое средство автоматизации от Microsoft, состоящее из оболочки с интерфейсом командной строки и сопутствующего языка сценариев согласно Википедии;

2.       Синее – с текстовым меню из 15-ти пунктов.

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

Дело в том, что тут их создавать никак нельзя! Для управления сервером вам потребуется скачать и установить Remote Server Administration Tools (RSAT) для клиентской операционной системы и установить компонент Диспетчер Hyper-V - необходимо выбрать компоненты через установку программ, для управления сервером, т.к. по умолчанию они просто внесутся в список компонентов windows, но не поставятся.

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

John Howard, который занимает пост Senior Program Manager in the Hyper-V team at Microsoft, написал цикл статей, посвященный раздаче необходимых прав, а в последствии создал замечательную утилиту HVRemote, которая произведет хитроумную настройку сервера и клиента.

Ей мы и воспользуемся. Итак, скачиваем, заходим на сервер по \\server\C$, кладем HVremote.wsf в папку Windows (или в любое другое место, но тогда не забываем указывать полный путь к ней). Запускаем на сервере:

cscript hvremote.wsf /add:domain\account ***,

где domain\account – ваше имя пользователя в домене (или на машине с сервером виртуализации). Скрипт пропишет все необходимые привилегии, в том числе откроет нужные порты на фаерволе. Только одно маленькое но – скрипт замечательно работает на английской версии ОС. На русской будут проблемы с названием групп. Рекомендую в таком случае все политики фаервола менять вручную заменив английские названия групп на соответствующие русские.

Теперь можно запускать Диспетчер Hyper-V и подключаться к нашему серверу, создавать виртуалки и радоваться жизни.

Но тут появляется вторая проблема. Microsoft рекомендует ввести машину с Hyper-V Server 2008 R2 в домен и тогда все вопросы с администрированием будут просты и прозрачны. Но что делать если у нас нет домена???

Нужно будет выполнить следующие шаги:

 • Создать на сервере и на клиенте аккаунт с помощью net user

 • Дать этому пользователю доступ cscript hvremote.wsf /add:accountname ***

 • На клиенте разрешить анонимный доступ к DCOM cscript hvremote.wsf /anondcom:grant, залогиниться под тем же аккаунтом, которому разрешили доступ на сервере, или запустить Диспетчер Hyper-V из под нужного аккаунта, прописать учетные данные для подключения к серверу командой cmdkey /add:servername /user:servername\account /pass, а также создать исключения брандмауэра командой cscript hvremote.wsf /mmc:enable

Кроме того, если клиент или сервер находятся в рабочей группе или они находятся в разных доменах, между которыми нет доверительных отношений, то соединение от сервера до клиента, устанавливаемое для доставки результирующей информации, происходит анонимно. Анонимное соединение завершается неудачно с кодом ошибки 0x80070005 или 0x8007000e до тех пор, пока анонимному соединнеию не будет дано право Remote Access на DCOM клиента. Дать это право можно, выполнив следующие шаги:

1.  Нажмите Start, выберите Run, запустите dcomcnfg.exe.

2.  В Component Services раскройте Computers, правой кнопкой выберите My Computer и укажите Properties.

3.  В My Computer Properties раскройте COM Security.

4.  В Launch and Activation Permissions выберите Edit Limits.

5.  В окне Access Permissions выберите ANONYMOUS LOGON в списке Group or user names. В колонке Allow в Permissions for User укажите Remote Access и нажмите OK.

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

Рекомендую посмотреть этот материал, даже если скрипт отработал без проблем - cпособствует пониманию концепции.

И напоследок хочу порекомендовать замечательную утилиту, которая очень облегчает жизнь администратору серверов в Core редакции - http://coreconfig.codeplex.com/ 

Теги:

CODEC – краткое справочное руководство

Автор Maksim Kovalenko 2 июля 2011 19:41

Достаточно много внимания уделено в специализированных изданиях описанию протоколов управления VoIP таких как: SIP, MGCP, H.248 и т.д. Однако, крайне мало внимания уделяется описанию самой главной части IP-телефонии – голосовым сессиям. А ведь именно это и есть основной трафик VoIP сетей.

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

РСМ

Как известно, для улучшения качества голосового сигнала в сетях традиционной телефонии уже давно используется метод преобразования аналогового сигнала в цифровые выборки, которые состоят из бинарной последовательности нулей и единиц. Такое преобразование называется импульсно-кодовая модуляция (Pulse Code Modulation – PCM).  РСМ преобразовывает аналоговый звук в цифровую форму, проводя выборку аналогового звукового сигнала 8000 раз в секунду и преобразуя каждую выборку в цифровой код. Как следует из теоремы Найквеста, если частота выборки аналогового сигнала вдвое выше выше максимальной требуемой частоты, впоследствии этот сигнал можно будет точно восстановить в аналоговом виде. Поскольку частота голоса редко превышает 4 КГц, достаточной частотой выборки для голосовых данных окажется 8000 выборок в секунду (125мс между выборками).

Методы компрессии голосовых данных

Общепринятыми сейчас являются два основных варианта РСМ:

·         µ - стандарт (используемый в Северной Америке)

·         α – стандарт (принятый в Европе)

Оба они используют логарифмический метод сжатия, чтобы достичь 12-13 битного качества канала РСМ при всего лишь восьмибитовых словах, а отличаются незначительными деталями. Таким образом, полоса пропускания, необходимая РСМ каналу, равна: 8000 выборок/с * 8 бит = 64 000 бит/с, или 64Кбит/с. Важным является момент, что во время звонка ответственность за необходимое преобразование функции µ-вида к функции α-вида берет на себя сторона, использующая функцию µ-вида.

Другой популярный метод компрессии – адаптивная дифференциальная импульсно-кодовая модуляция (Adaptive Differential Pulse Code Modulation – ADPCM). Общепринятым стандартом ADPCM является ITU-T G.726, по которому кодирование происходит с помощью 4-битовых выборок, обеспечивающих частоту передачи 32Кбит/с., соответственно. В отличие от РСМ, четырмя битами непосредственно кодируется не амплитуда голоса, а разница амплитуды (как частота изменения амплитуды).

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

Эти методы, как правило, объединены в исходные кодеки, включающие такие варианты, как: 

  • кодирование методом линейного предсказания (Linear Predictive Coding – LPC)
  • алгоритм сжатия при кодировании методом линейного предсказания (Code Excited Linear Predictive Coding – CELP)
  • мульти-импульсное многоуровневое квантование (Multipulse, Multilevel Quantization – MP-MLQ).

Схемы кодирования CELP, MP-MLQ, PCM и ADPCM стандартизированы ITU-T в рекомендациях G. Наиболее применяемые в VoIP сетях кодеки приведены в Таблице 1.

Стандарт (компрессия)

Занимаемая полоса пропускания (Bitrate)

Описание

G.711

(РСМ)

64 Кбит/с

Стандарт кодирования предполагает немедленное преобразование голосовых данных в формат, необходимый для цифровой голосовой передачи по ТфСОП

G.726

(ADPCM)

40 Кбит/с

32 Кбит/с

24 Кбит/с

16 Кбит/с

Голосовой сигнал, закодированный этим стандартом кодирования, может передаваться в виде голосовых пакетов по обычной телефонной сети или РВХ, если последние поддерживают ADPCM

G.728

(CELP)

16 Кбит/с

Вариант компрессии с низкой задержкой и скоростью передачи

G.729

(CELP)

8 Кбит/с

Варианты этого кодека: G.729 и G.729 Annex A различаются, главным образом, сложностью вычислений и обеспечивают качество речи, аналогичное методу ADPCM со скоростью передачи 32 Кбит/с

G.723.1

(MP-MLQ, CELP)

6,3 Кбит/с (MP-MLQ)

5,3 Кбит/с (CELP)

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

iLBC

(Internet Low Bitrate Codec)

13,33 Кбит/с  (при длине фрейма 30мс)

15,20 Кбит/с (при длине фрейма 20мс)

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

Таблица 1. Стандарты компрессии голосовых данных

Необходимо также отметить, что кодек G.729 патентованный и его использование в решениях VoIP всегда платное. В то же время кодек iLBC – абсолютно бесплатный. Консорциум PacketCable и множество других производителей отдали свое предпочтение именно этому кодеку. Он также используется многими приложениями CTI, такими как: Skype, Google Talk, Yahoo! Messenger with Voice и MSN Messenger.

Расчет требуемой полосы пропускания для трафика VoIP.

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

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

Размер полезной нагрузки зависит от размера голосового сэмпла (звукового файла), который является величиной конфигурируемой и непосредственно влияет на требуемую полосу пропускания. Голосовой сэмпл — это выход с процессора DSP, инкапсулирующийся в PDU. AudioCodes, по умолчанию, инкапсулирует в PDU по 20мс голоса для всех кодеков, за исключением G.723, где инкапсулируется по 30мс голоса.

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

Размер сэмпла в байтах рассчитывается по формуле:

Bytes_per_sample= (Samlpe_size * Codec_bitrate) : 8

где:

  •         Bytes_per_sample – размер сэмпла (в Байтах)
  •         Sample_size – размер сэмпла (в секундах)
  •         Codec_bitrate – битрейт используемого кодека

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

  1. Total_packet_size = Layer2_overhead + IP_UDP_RTP_overhead + Bytes_per_sample
  2. PPS = Codec_bitrate: Bytes_per sample
  3. BW = Total_packet_size * PPS

где: 

  •         Total_packet_size – размер пакета данных, включая payload и все заголовки вплоть до канального уровня, включительно
  •         Layer2_ovrhead – размер заголовка канального уровня (в Байтах)
  •         IP_UDP_RTP_overhead – суммарный заголовок протоколов верхних уровней, равный 40 Байт
  •         Bytes_per_sample – размер сэмпла (в Байтах), который берем из первой формулы
  •         Codec_bitrate – битрейт используемого кодека
  •         PPS – количество пакетов, которые надо передавать в секунду для того, чтобы успевать доставлять данные, генерируемые данным кодеком
  •         BW – номинальная требуемая полоса пропускания (!)

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

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

Для тех, кого начинает подташнивать при виде формул, а осознание того, что необходимо еще вооружиться входными данными, вызывает все нарастающее чувство тревоги и мигрень – существуют специальные VoIP BW калькуляторы. В большинстве своем – они платные. Однако, есть также и бесплатные on-line версии, как например: http://www.bandcalc.com/ 

Теги: , ,

Инструкция | Телефония

Комплексная система антивирусной защиты

Автор Illya Golovatsky 30 июня 2011 23:03

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

Давайте рассмотрим небольшую фирму.  10-20 компьютеров. У них наверняка установлен антивирус на каждом компьютере. Не будем подсчитывать чьи-то деньги, но если взять даже самую розничную цену на антивирусные средства для 20-ти компьютеров, будет всего 40 грн/мес. Вы все еще верите в миф, что это дорого?

Теперь учтем, что чем больше человек в компании, тем больше растет скидка. Соответственно, для компании в 100 рабочих мест – цена в месяц обойдется уже около 22 грн.

И это называется дорого? Какой процент от затрат на каждое рабочее место это будет, 0,5% или дотянет до 1%?

Теперь поговорим о комплексности защиты. Что такое комплекс?  И здесь и там мы постоянно слышим заученные фразы «комплекс», «ксаз», «администратор антивирусной безопасности» – это даже выговорить сложно – не то, что внедрить. Вам нужна антивирусная защита? – Нате вам комплекс. Теперь еще наймите двух сотрудников, которые будут его обслуживать. А лучше 5, так как четверо из них будут ходить на работу круглосуточно. Это надо вашему бизнесу? Тот, кто разрабатывал нормативную документацию вообще задавался вопросом о том, что надо бизнесу?!

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

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

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

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

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

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

Что имеется на входе:

1) Администратору не всегда выгодно показывать весь состав трафика на предприятии – это реальность и довольно распространенная.

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

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

Что необходимо:

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

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

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

Методика постановки и отработки задач

Автор Владимир Шишкин 21 июня 2011 00:41

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

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

Методика постановки, контроля и выполнения задач  

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

Общая часть
Классификация задач:

По сроку выполнения

  • Короткая. Требует на выполнение 1 - 2 часа. -делать сразу в течение дня-
  • Средняя. Требует на выполнение 3 - 6 часов. -по возможности делать сразу-
  • Длительная. Требует на выполнение 2-4 дня.
  • Долгосрочная. Требует на выполнение 1-2 недели.
  • Комплексная. Требует составления плана и его согласования с руководителем для разбития его в дальнейшем на более простые задачи.

По типу

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

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

Роли, права и обязанности

-В классике две роли - Инициатор и Исполнитель. Перечень Инициаторов и Исполнителей приводится тут же в привязке к штатному расписанию.-

Инициатор ставит задачу, делегируя исполнителю ответственность за результат и качество её выполнения.

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

Исполнитель выполняет задачу сам или с привлечением ресурса, несет полную ответственность за результат выполнения задачи. На стадии принятия задачи:

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

Линейный руководитель Исполнителя

- Как пример роли, вне классики, тут могут быть руководители проектов, топ-менеджеры и т.п.

  • Распределяет ресурсы и решает ресурсные конфликты.
  • Отслеживает ход выполнения задачи.
  • Имеет право фиксировать невыполнение задачи и применять санкции к Исполнителю.
  • Имеет право оговаривать сроки и результаты задачи.
  • Имеет право мотивированно отклонить задачу.

Приоритетность задач

Приоритетность задач определяет Инициатор задачи в момент постановки задачи.

- Тут возможны варианты с перечислением  приоритетов и т.п.-

Источники постановки и принятия задачи.

Задачи назначаются только в электронном виде, а именно: по электронной почте. Сроки, контрольные точки, изменения состояния задачи, результаты выполнения должны фиксироваться по источнику получения.

- Тут - по электронной почте (или инструментами коллективной работы в виде задач). Важно, чтобы источник был один! -

Методика постановки задачи

Для постановки задачи Инициатору необходимо

  • четко установить сроки, объем и ресурсоемкость.
  • определить критерии контроля.
  • и ГЛАВНОЕ - четко понимать признаки окончательного завершения задачи.

Задачи назначаются только в электронном виде. Устные просьбы, звонки и т.п. не считаются задачами до момента их фиксации в электронном письме. (Исключения можно оговаривать, например срочные или короткие поручения и т.п.).

Принципы:

  1. Четко формулировать задачу сотруднику.
  2. Четко определять временные границы.
  3. Конкретизировать и описать признаки завершения задачи.
  4. Способствовать успешному выполнению задачи.

Методика обработки задачи Исполнителем

Этап принятия

Исполнитель должен в течение короткого промежутка времени, который устанавливает Инициатор (обычно 1 час), после прочтения запроса отреагировать на поставленную задачу:

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

После прояснения ситуации по задаче Исполнитель фиксирует данные и факт принятия задачи. Задача считается принятой в случае фиксации этого факта по электронной почте Исполнителем.

- В кавычках приведены статусы задач для Исполнителя, тут они отличны от классики 0-100%. Лично для меня интересны такие статусы:

  • «Назначена» - я поставил задачу.
  • «Принял в работу» - задача принята и вопросов по срокам и результатам нет.
  • «50%» - в процессе.
  • «Выполнена» - сотрудник считает, что задача выполнена, ждет ответа.
  • «Закрыта» - результат устроил Инициатора.
  • Дальше можно развивать, например: «Заморожена», «Отменена» «Выполнена до проверки» и т.п.-

Этап выполнения

Исполнитель в процессе выполнения должен:

  • Фиксировать основные достижения, вехи изменения.
  • Эскалировать решения проблемных вопросов.
  • Нести ответственность за решения, принятые в рамках выполнения задачи.
  • Заранее сообщать инициатора об изменении сроков выполнения.

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

Контроль и отчетность по задаче

Для понимания просто привожу общие примеры:

  • Отчет по задаче должен содержать общее описание проделанной работы. -Для меня, например, важной  является та часть, в которой указано текущее состояние работы, а также что запланировано на ближайшее время, - для определения сроков закрытия задачи или этапа задачи и координации действий.-
  • В отчете должна быть указана контактная информация лиц, с которыми ведутся смежные работы.
  • Отчет по задаче необходимо предоставлять в ходе продвижения соответствующих работ, при появлении дополнительной информации или незапланированных событий, но НЕ РЕЖЕ, чем в установленный для этой задачи период.
  • К каждой задаче при отчете должна быть приложена ссылка на дополнительные материалы.

Политики

- В политиках указываем специфику, например:-

  1. Все задачи специалистам технического департамента ставятся по согласованию с Техническим директором, или все задачи специалистам технического департамента ставятся напрямую и т.п.
  2. После согласования задачи и принятия ее в работу Инициатор и Исполнитель коммуницируют напрямую. Линейный руководитель привлекается только в случае ресурсных конфликтов.
  3. Инициатор при постановке задачи должен назначать контрольные промежуточные даты и события.
  4. Отчеты исполнитель предоставляет Инициатору не реже одного раза в неделю.

И немного "приправ" к методике:

  1. Провести серию мероприятий и донести ее сотрудникам.
  2. Дать все необходимые ИТ сервисы и системы.
  3. Очень важно нести эти политики топ-менеджерам и превращать их в корпоративную культуру.
  4. Внести взыскание за невыполнение внутренних правил.

 

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

Организация Hot Spot на оборудовании Extreme Networks.

Автор Nikita Olenets 14 июня 2011 10:39

При организации Hot Spot  аутентифицированого доступа к WLAN для пользовалей и устройств используется стандартный веб браузер. Это позволяет предоставлять аутентификацию доступа посредством перехвата и перенаправления браузерной веб- сессии в специальный веб-портал, где пользователю предлагается ввести свои учетные данные, чтобы получить доступ к сети.

Обзор

Серия беспроводных контроллеров Extreme Networks® Summit® WM3000 поддерживает набор расширенных функций, обеспечивающихподдержку Hot Spot  аутентификации для гостевых или частных пользовалей.


HotSpot становится все более популярным средством для аутентификации пользователей и устройств, поскольку этот механизм позволяет администраторам обеспечить функционал проверки подлинности пользователя без развертывания 802.1X или PKI-инфраструктуры (инфраструктура открытых ключей). Благодаря тому, что данная технология способна обрабатывать множество приложений, включая доступ гостевых или частный пользователей, она широко распространена в частных компаниях, медицинский  учреждениях, учебных заведениях и т.п.

Области применения:

Аутентифицированный гостевой доступ

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

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

Преимущества Hot Spot   аутентификации для гостевого доступа:

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

Аутентифицированный частный доступ

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

В типичных корпоративных средах для обеспечения подлинности доступа в сеть обычно используются аутентификация  802.1X. Этот тип аутентификации достаточно легко развернуть  и поддерживать, если все устройства управляемые, имеют конечного пользователя, а также находятся в собственности ИТ-подразделения предприятия. Однако  в других условиях, таких как сфера образования, большое кол-во разновидностей ОС и устройств делают процедуры развертывания и поддержки 802.1X затруднительными.

До применения HotSpot аутентификации в сфере образования было достаточно развернуть беспроводную сеть, сгенерировать общие ключи (shared key) и настроить MAC аутентификацию. Этот подход хорош тем, что он не требует развертывания 802.1X аутентификации, но при этом увеличиает нагрузку на ИТ персонал, который каждый семестр вынужден  делать ротацию ключей и сверять списки разрешенных MAC адресов.

HotSpot  аутентификация имеет возможность привязать аутентификацию пользователей к уже существующей RADIUS или LDAP базе пользователей,которым разрешен доступ. Скажем, аутентификация студентов может быть выполнена по номеру студенческого билета пользователя.

 Преимущества HotSpot аутентификации для предоставления частного доступа:

  • Уменьшает нагрузку на администраторов для поддержкания огромного количества списков разрешенных MAC адресов.
  • Позволяет производить аутентификацию пользователей в уже существующих базах LDAP или RADIUS.
  • Позволяет провети аутентификацию без разворачивания и управления инфраструктурой 802.1X.
  • Позволяет классифицировать пользователей в зависимости от уровня доступа. Например, преподаватели и студенты.
  • Возможность назначения политик доступа и использования пропускной полосы как классу пользователей, так и конкретному пользователю.
  • Разрешение на доступ к сети может быть ограничено местонахождением пользователя. Например, на время сессии могут быть назначены политики  запрета доступа к внешней сети Интернет из специфической географической локации.
  • Позволяет администраторам предотвратить передачу учетных данных пользователей другим лицам.  

 Платный доступ к Интернет

HotSpot аутентификация  позволяет организовать платный доступ в Интернет на фиксированный период  (от одного дня и более), а также обеспечивает многоуровневые услуги для позователей, таких как: обеспечение пропускной полосы и приоритетности траффика, основанной на приобретённом сервисном пакете.

HotSpot аутентификация привлекательна для платного доступа тем, что не требует никакого специального ПО на клиентском оборудовании. Для аутентификации пользователя достаточно наличия веб-браузера. Все остальные задачи берет на себя контроллер Summit WM3000. С его помощью после успешной аутентификации будут контролироваться ограничения по времени и  пропускной полосе.