Описание примера сценария

13.1 Описание сценария

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

Они работают в двух офисах: восточном и западном.

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

13.2 Этап 1. Базовое внутреннее сотрудничество

В первую очередь, компания RedbooksCo определяет, что ей необходима система сообщений и совместной работы, которая бы позволила повысить эффективность обмена данными между сотрудниками. Требуется, чтобы сотрудники могли просматривать электронную почту, участвовать в сеансах совместной работы и осуществлять обмен данными через защищенную систему мгновенного обмена сообщениями; все это осуществляется через Web-браузер. Таким образом, было решено использовать Lotus Domino совместно с Domino Web Access (iNotes) для электронной почты, Lotus Team Workplaces (QuickPlace) для сеансов совместной работы и Lotus Instant Messaging (Sametime) для мгновенного обмена сообщениями.

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

Для этого персонал отдела информационных технологий компании Redbooks создает идентификаторы пользователей для каждого пользователя на основе его расположения в восточном либо западном офисе компании. После этого реализуется система единой регистрации (single sign-on, SSO) по всем серверам совместной работы.

На данном этапе для каждого пользователя настраивается доступ к почте через личный URL следующего вида (пример для почтового файла пользователя Matt Milza):

http://itsosec-dom.cam.itso.ibm.com/mail/mmilza.nsf

После ввода URL в Web-браузер пользователю выводится запрос входа. Пример представлен на рис. 13.1.

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

Почта iNotes пользователей, выводимая на данном этапе, изображена на рис. 13.2.

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

Пользователь также может применять возможности интерактивных встреч, реализованные в Lotus Sametime. Пользователь может участвовать в интерактивных встречах и планировать встречи без повторной регистрации. Пользователь может даже запустить клиент Sametime Java Connect для участия в чате с другими пользователями в компании Redbooks без дополнительного запроса аутентификации.

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

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

13.3 Этап 2. Удаленный доступ к электронной почте

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

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

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

Сотрудники компании Redbook могут подключиться к почтовому серверу через Интернет, используя тот же URL, который они применяют в офисе:

https://itsosec-dom.cam.itso.ibm.com/mail/mmilza.nsf

Обратите внимание на то, что после настройки SSL адрес URL изменился на HTTPS. Обратный прокси-сервер и сервер Domino настроены на использование только SSL-подключений.

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

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

https://itsosec-dom.cam.itso.ibm.com

ему будет выдано сообщение you are not authorized (вы не авторизованы), как показано на рис. 13.5. Настраивая правила обратного прокси-сервера должным образом, менеджер по информационным технологиям может избирательно блокировать доступ пользователей Интернета.

13.4 Этап 3. Создание корпоративного каталога

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

К счастью, этот первоначальный каталог поддерживает LDAP, что позволяет другим средам использовать каталог для аутентификации и просмотров. Благодаря этому сравнительно легко реализовать переход на применение первоначального каталога в качестве единого корпоративного каталога в компании RedbooksCo. Возможности Directory Assistance продуктов совместной работы Lotus используются для привязки Lotus-серверов на основе Domino к этому LDAP-каталогу для выполнения аутентификации. После некоторых изменений в конфигурации и перезагрузки сервера выполняется перенаправление аутентификации для новой среды совместной работы на первоначальный каталог. Затем осуществляется синхронизация двух LDAP-каталогов так, чтобы имена пользователей Domino были включены в первоначальный LDAP-каталог, что позволяет свести к минимуму изменения в таблицах управления доступом технологии Lotus.

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

13.5 Этап 4. Удаленный доступ ко всем инструментам совместной работы

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

Менеджер по информационным технологиям также понимает, что пользователям сложно запомнить URL для каждой функции совместной работы. Даже если пользователи создадут закладки для каждой из служб (QuickPlace, Sametime, iNotes и т. д.), это не является оптимальным решением. В связи с этим он также решил создать базовый портал совместной работы на основе WebSphere Portal. Такой единый корпоративный портал может предоставлять доступ ко всем корпоративным технологиям и приложениям совместной работы. Один и тот же портал может применяться для подключения пользователей к корпоративным ИТ-функциям как из офиса через корпоративную сеть, так и из дома через Интернет.

Сервер WebSphere Portal помещается за брандмауэром, так что RedbooksCo сохраняет свою трехзонную архитектуру. После этого выполняется переконфигурирование обратного прокси-сервера таким образом, чтобы разрешать подключения к серверу портала, и на сервере портала включается SSL-шифрование для обеспечения защищенной сетевой передачи всех данных.

Пользователю нужно будет лишь ввести URL, подобный следующему:

https://itsosec-wps.cam.itso.ibm.com/wps/myportal

Портал выдаст запрос на аутентификацию, как показано на рис. 13.6.

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

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

13.6 Этап 5. Дополнительные инструменты совместной работы

После этого компания RedbooksCo начинает рассматривать вариант внедрения обучающей программной системы и почтовой системы на основе Web-технологий для сотрудников производства, не имеющих регулярного доступа к компьютерам. Для предоставления этих служб сотрудникам производства были выбраны функции Lotus Workplace Messaging и Lotus Learning Management System. Эти функции напрямую включаются в существующую среду и подключаются к корпоративному каталогу, составляя интегрированное безопасное решение. В новых системах у пользователей останутся те же имена и пароли. Это хорошо, так как пользователям не придется запоминать новое имя и пароль.

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

13.7 Этап 6. Дополнительная защита удаленного доступа

На данном этапе RedbooksCo применяет зашифрованные подключения между пользователями и серверами при доступе через Интернет и частную корпоративную локальную сеть с применением SSL и обратного прокси-сервера. Кроме того, используется единый корпоративный LDAP-каталог, осуществляющий управление именами и паролями, употребляемыми при аутентификации, и выполняющий функции управления паролями путем применения правил длины пароля и срока действия пароля. Хотя такая система является довольно защищенной, пользователи проходят через обратный прокси-сервер на серверы заднего плана WebSphere Portal и/или Lotus до выполнения аутентификации. Обязанности выполнения аутентификации и проверки прав доступа к службам возложены на системы заднего плана.

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

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

13.8 Этап 7. Удаленный доступ к интерактивным встречам и чату

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

Примечание. Этот сценарий основан на использовании Lotus Sametime 3.0. Применение Lotus Sametime 3.1 позволило бы разместить сервер Sametime за обратным прокси-сервером, подобно другим Lotus-серверам совместной работы, так как Sametime 3.1 обеспечивает поддержку прокси-серверов.

Дополнительные сведения о поддержке прокси-серверов в Sametime 3.1 см. в разделе 5.5, "Поддержка прокси-серверов в Lotus Sametime 3.1".

13.9 Заключение

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