Аутентификация пользователей при удаленном доступе

Размещено на http://www.allbest.ru

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«САНКТ-ПЕТЕРБУРГСКИЙ ТОРГОВО-ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра Информационных систем и информационных технологий

КОНТРОЛЬНЯ РАБОТА

Аутентификация пользователей при удаленном доступе

Выполнила: Гатман Анна Сергеевна

Содержание

Введение

1. Понятие удаленного доступа

2. Типы аутентификации

3. Локальные и удаленные пользователи

4. Независимое сопровождение удаленного доступа

Заключение

Литература

Введение

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

Доступ по паролю

Простейший протокол аутентификации - доступ по паролю (Password Access Protocol, PAP): вся информация о пользователе (логин и пароль) передается по сети в открытом виде (рис. 1). Полученный сервером пароль сравнивается с эталонным паролем данного пользователя, который хранится на сервере. В целях безопасности на сервере чаще хранятся не пароли в открытом виде, а их хэш-значения.

Рисунок 1 - Схема протокола PAP

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

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

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

Запрос-ответ

В семейство протоколов, называемых обычно по процедуре проверки "запрос-ответ", входит несколько протоколов, которые позволяют выполнить аутентификацию пользователя без передачи информации по сети. К протоколам семейства "запрос-ответ" относится, например, один из наиболее распространенных - протокол CHAP (Challenge-Handshake Authentication Protocol).

Процедура проверки включает как минимум четыре шага (рис. 2):

· пользователь посылает серверу запрос на доступ, включающий его логин;

· сервер генерирует случайное число и отправляет его пользователю;

· пользователь шифрует полученное случайное число симметричным алгоритмом шифрования на своем уникальном ключе, результат зашифрования отправляется серверу;

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

Рисунок 2 - Схема протокола аутентификации типа "запрос-ответ".

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

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

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

Протоколы типа "запрос-ответ" легко "расширяются" до схемы взаимной аутентификации (рис. 3). В этом случае в запросе на аутентификацию пользователь (шаг 1) посылает свое случайное число (N1). Сервер на шаге 2, помимо своего случайного числа (N2), должен отправить еще и число N1, зашифрованное соответствующим ключом. Тогда перед выполнением шага 3 пользователь расшифровывает его и проверяет: совпадение расшифрованного числа с N1 указывает, что сервер обладает требуемым секретным ключом, т. е. это именно тот сервер, который нужен пользователю. Такая процедура аутентификации часто называется рукопожатием.

Рисунок 3 - Схема протокола взаимной аутентификации

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

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

Протокол Kerberos

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

Рисунок 4 - Схема протокола Kerberos

Прежде всего, стоит сказать, что при использовании Kerberos нельзя напрямую получить доступ к какому-либо целевому серверу. Чтобы запустить собственно процедуру аутентификации, необходимо обратиться к специальному серверу аутентификации с запросом, содержащим логин пользователя. Если сервер не находит автора запроса в своей базе данных, запрос отклоняется. В противном случае сервер аутентификации формирует случайный ключ, который будет использоваться для шифрования сеансов связи пользователя с еще одним специальным сервером системы: сервером предоставления билетов (Ticket-Granting Server, TGS). Данный случайный ключ (обозначим его Ku-tgs) сервер аутентификации зашифровывает на ключе пользователя (Kuser) и отправляет последнему. Дополнительная копия ключа Ku-tgs с рядом дополнительных параметров (называемая билетом) также отправляется пользователю зашифрованной на специальном ключе для связи серверов аутентификации и TGS (Ktgs). Пользователь не может расшифровать билет, который необходим для передачи серверу TGS на следующем шаге аутентификации.

Следующее действие пользователя - запрос к TGS, содержащий логин пользователя, имя сервера, к которому требуется получить доступ, и тот самый билет для TGS. Кроме того, в запросе всегда присутствует метка текущего времени, зашифрованная на ключе Ku-tgs. Метка времени нужна для предотвращения атак, выполняемых повтором перехваченных предыдущих запросов к серверу. Подчеркнем, что системное время всех компьютеров, участвующих в аутентификации по протоколу Kerberos, должно быть строго синхронизировано.

В случае успешной проверки билета сервер TGS генерирует еще один случайный ключ для шифрования сеансов связи между пользователем, желающим получить доступ, и целевым сервером (Ku-serv). Этот ключ шифруется на ключе Kuser и отправляется пользователю. Кроме того, аналогично шагу 2, копия ключа Ku-serv и необходимые целевому серверу параметры аутентификации (билет для доступа к целевому серверу) посылаются пользователю еще и в зашифрованном виде (на ключе для связи TGS и целевого сервера - Kserv).

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

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

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

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

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

3. Локальные и удаленные пользователи

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

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

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

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

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

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

Аутентификацию с помощью ключей предлагают такие компании, как Security Dynamics, чьи ключи ACE/Server и SecurID используются широким кругом корпоративных узлов и поставщиков услуг, а также канадская фирма Crypto-Card, чьи ключи и серверы поддерживают RADIUS и TACACS и работают под управлением операционных систем Windows NT и UNIX.

Защита внутренних ресурсов

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

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

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

Еще один метод защиты внутренних ресурсов предусматривает создание инфраструктуры с открытыми ключами (Public Key Infrastructure, PKI). PKI позволяет укрепить защиту внутренних ресурсов сети за счет использования пары ключей и цифровых сертификатов. При таком подходе пользователи или сотрудники отдела информационных систем генерируют пару: открытый и личный ключ, а также получают цифровые сертификаты для этих ключей от соответствующего уполномоченного. При обращении к внутренним ресурсам, до того как пользователю будет предоставлен доступ к любым данным, ему придется представить свои "верительные грамоты". Поскольку ключи и сертификаты размещаются на клиенте, эти мандаты продублировать практически невозможно.

Кроме того, PKI предусматривает поддержку списка аннулированных сертификатов (Certificate Revocation List, CRL), т. е. тех, чей срок действия истек, или тех, что были отменены. Если ноутбук украден, администратор должен аннулировать клиентские ключи и сертификат, объявив их недействительными.

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

Туннелирование - одна из технологий, привлекшая к себе внимание главным образом благодаря растущему интересу к виртуальным частным сетям (Virtual Private Networks, VPN). Эта технология предусматривает инкапсуляцию протокольных блоков PPP, содержащих пакеты практически любого типа (IP, IPX, NetBEUI или AppleTalk), с помощью протокола туннелирования, такого как Point-to-Point Tunneling Protocol (PPTP) или Layer 2 Forwarding (L2F), с последующей упаковкой результата в пакет IP для пересылки в корпоративную сеть. Хотя эти протоколы могут использоваться и при доступе по коммутируемым каналам, чаще всего они применяются при удаленном доступе через Internet, поскольку позволяют создать частный туннель в общедоступной сети.

По словам Гордона Бернса, менеджера по продуктам компании Shiva, одного из пионеров рынка систем удаленного доступа, в случае туннеля через Internet компании могут выбрать реализацию VPN как зависящую или не зависящую от поставщика услуг. "В провайдеро-зависимой модели туннель и шифрование организуются между точкой доступа провайдера Internet и локальной сетью; в провайдеро-независимой модели туннель и шифрование выполняются из конца в конец, от клиента через точку доступа в сеть", - пояснил он (рис. 5).

Рисунок 5

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

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

Еще один протокол для организации защищенных коммуникаций через Internet - IPSecurity. Этот протокол - конкурент PPTP и L2F, хотя это сравнение не вполне сопоставимых величин. Вместо туннелирования IPSecurity - пакет протоколов, расширяющих IP, - осуществляет аутентификацию и шифрование данных. Однако, поскольку он проверяет целостность данных внутри пакета во время шифрования, IPSecurity позволяет обеспечить более высокую степень защиты, чем протоколы туннелирования. Описание IPSecurity можно найти на узле Web по адресу: www.networkmagazine.com/tutors/9802tut.htm.

Иной метод поддержки шифрования и аутентификации в виртуальных частных сетях предлагает Socks, стандарт IETF на использование посредника на уровне канала. Как отметил Каплан, компания которого реализовала данную технологию в своей частной виртуальной сети, Socks направляет весь трафик на отдельный порт и определяет полномочия доступа в корпоративную сеть всех пользователей. Протокол Socks действует на пятом уровне модели OSI и может работать с туннелями и IPSecurity. Этот протокол требует, чтобы на каждом клиенте было установлено программное обеспечение для передачи данных на сервер Socks на предмет аутентификации. Кроме того, данные должны шифроваться как на клиенте, так и на сервере.

Благодаря поддержке целого ряда схем шифрования, таких как Kerberos, Secure Sockets Layer (SSL), CHAP и RADIUS, Socks отличается большей гибкостью, чем протоколы туннелирования.

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

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

4. Независимое сопровождение удаленного доступа

Услуги Internet провайдеров

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

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

Последнее время многие компании предпочитают переложить хотя бы часть этого бремени на поставщиков услуг. "Провайдеры Internet уже имеют соответствующую инфраструктуру, поэтому все, в чем заинтересовано предприятие, может предложить провайдер", - считает Джо Райан, вице-президент компании Funk Software.

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

Одним из таких провайдеров является компания Concentric Network, чья служба RemoteLink была организована в США и Канаде летом 1997 года, а услуги на международном уровне стали предоставляться с 1998 года.

Используя эту службу, пользователи могут набрать местный номер более чем 40 тыс. коммутаторов в Северной Америке. После введения пользователем всех необходимых для регистрации в сети данных, Concentric передает их на корпоративный сервер RADIUS данной компании. Вся аутентификация осуществляется на корпоративном узле, а не на узле провайдера. Как отметил Джим Хаитала, директор службы виртуальных частных сетей компании Concentric, "последняя ситуация неприятна тем, что, во-первых, она чревата изъянами, а во-вторых, эта работа оказывается чересчур накладной для провайдера".

Служба RemoteLink компании Concentric использует технологию туннелирования разработки Bay Networks. Этот метод позволяет упаковывать пакеты IP или IPX в новый пакет IP для доставки на узел назначения. Concentric планирует поддерживать протокол туннелирования второго уровня после его усовершенствования в 1998 году. RemoteLink обеспечивает и другие функции защиты, в том числе Data Encryption Standard (DES).

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

Компания GTE Internetworking, которая летом прошлого года приобрела собственного сервис-провайдера, фирму BBN, с января предлагает услуги удаленного доступа.

DiaLinx обеспечивает защищенный доступ через 400 точек в США и значительно большее их число в других странах мира.

Услуги удаленного доступа также предоставляют, к примеру, компании UUNET и AT&T WorldNet.

Обращение за услугами удаленного доступа к сторонней компании пока не получило широкого распространения, но, по мере совершенствования протокола туннелирования и шифрования в IP-сетях, все большее число компаний станет рассматривать Internet как серьезное средство для связи с удаленными пользователями.

Путь через туннели. PPTP и L2F

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

Появление туннелирования - метода создания защищенных частных соединений между узлами - позволяет организациям использовать Internet в качестве виртуальной частной сети (Virtual Private Network, VPN).

Туннелирование предполагает инкапсулирование таких протоколов, как IPX, IP и NetBEUI, и защищенную транспортировку их пакетов через Internet. В настоящее время данная технология может быть реализована несколькими способами. Microsoft, 3Com и несколько других производителей систем удаленного доступа поддерживают Point-to-Point Tunneling Protocol, или PPTP. Этот протокол представляет собой расширение PPP с поддержкой шифрования данных. Он является частью служб удаленного доступа, встроенных в Windows NT 4.0, и компонентом Dial-Up Networking 1.2 в операционной системе Windows 95.

Еще один протокол туннелирования - Layer 2 Forwarding (L2F), который Cisco Systems и другие производители систем удаленного доступа поддерживают в своих маршрутизаторах и серверах удаленного доступа. Cisco, к примеру, использует его в своей Internetwork Operating System (IOS), устанавливаемой на маршрутизаторах компании.

Чтобы не заставлять заказчиков и поставщиков услуг выбирать между двумя протоколами, компании, придерживающиеся различных подходов к туннелированию, оставили в стороне свои разногласия и разработали спецификации на компромиссное решение, получившее название Layer 2 Tunneling Protocol (L2TP).

L2TP, который, как предполагают отраслевые эксперты, получит широкое распространение к лету 1998 года, объединяет функции как PPTP, так и L2F. Кроме того, он предусматривает поддержку IP Security и двухэтапной аутентификации, при которой личность пользователя проверяется дважды: сначала провайдером Internet, а затем корпоративным сервером.

Сейчас L2TP имеет только статус Internet Draft, но, несмотря на это, список производителей, поддерживающих этот протокол, расширяется чуть ли не ежедневно. Ознакомиться с различными документами, входящими в состав L2TP Internet Draft, можно на неофициальном Web-узле L2TP по адресу: www.masinter.net/~l2tp.

Заключение

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

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

Одним из самых распространенных способов обеспечения защищенного удаленного взаимодействия между территориально разнесёнными филиалами является организация виртуальных частных сетей (VPN, Virtual Private Network) на базе коммутируемых сетей общего пользования (чаще всего - Интернет). VPN-технологии не требуют построения выделенного канала связи и при грамотном использовании средств защиты, могут обеспечивать приемлемый для любой организации уровень информационной безопасности.

Литература

1. Галатенко В.А., Основы Информационных технологий. Основы Информационной безопасности. Москва, Интернет-Университет Информационных технологий, Открытые системы, 2012.

2. Michael Wenstrom, Managing Cisco Network Security. Cisco Press, 2009.

3. Константин Кузовкин. Защищенная платформа для Web-приложений. Откргшнлллллытые системы, 2011. № 4.

4. Смит Э. Аутентификация: от паролей до открытых ключей. "Вильямс", 2011.

5. Фороузан Б.А. Основы Информационных технологий. Криптография и безопасность сетей. Москва, Интернет-Университет Информационных Технологий, ЭКОМ, 2010.

Размещено на Allbest.ru