Описание примера сценария
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. Настраивая правила обратного прокси-сервера должным образом, менеджер по информационным технологиям может избирательно блокировать доступ пользователей Интернета.
