Rambler's Top100
 
Статьи ИКС № 1 2008
Павел БОЛОТИН  28 января 2008

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

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



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

Постановка задачи

Больше десятка информационных систем TTK требовали изменения процедуры доступа. Основные требования: максимально упростить аутентификацию пользователей, не ослабив при этом систему безопасности, построить и автоматизировать единый процесс предоставления информации, изменения и отзыва прав доступа в системы, минимизировав при этом участие администраторов. Дополнительные: представить в виде отчетов собранную информацию о полномочиях пользователей во всех целевых системах.

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

Существует много вариантов минимизации количества паролей – от подстановки имен и паролей из индивидуальной коллекции идентификационных данных до изменения механизмов аутентификации в приложении и построения «доверительных отношений» между приложениями. Можно использовать и однократную регистрацию в ОС Windows. Но на практике применение только одного способа не позволяет обеспечить регистрацию сразу во все системы. Комбинация же нескольких способов для различных систем требует учета организационных мер и правил безопасности каждой из них.

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

Оптимальным стало решение IBM Tivoli Identity Manager (класса Identity & Access Management), имеющее единый интерфейс для пользователей всех целевых систем, учитывающее особенности каждой из них и общающееся на языке, понятном каждой целевой системе. Еще один плюс Tivoli Identity Manager – возможность построения процессов утверждения и аудита полномочий, т.е. автоматизацию предоставления, изменения и отзыва полномочий, а также получения отчетности.

Организация процесса доступа

Приложения. В текущих версиях Lotus Notes аутентификация основана на парольной проверке сертификационной информации, хранящейся в специальном файле. Решение, предложенное для однократной регистрации в Lotus Notes, использует опцию Single Logon, которая подставляет пароль Windows при аутентификации в данном приложении. Поскольку пароль в процессе работы в Windows используется в открытом виде только при вводе, его нужно «отловить» именно в этот момент. Для этого на рабочее место сотрудника устанавливается ПО Single Logon Network Provider, а после перехвата пароль шифруется средствами Single Logon и хранится в зашифрованном виде. Понятно, что данная схема будет работать лишь при совпадении паролей для первичной Windows-аутентификации и в id-файле Lotus Notes.

В Microsoft Axapta реализуется способ однократной регистрации – пароль нужен только для доступа пользователя в Windows и механизм аутентификации приложения лишь настраивается на использование регистрационных данных Windows. При запуске MS Axapta из контекста пользователя берется имя пользователя Windows и база пользователей приложения проверяется на наличие такой учетной записи.

Для однократной регистрации в технологическом приложении на базе Oracle Application Server выбран один из наиболее защищенных способов аутентификации – Kerberos. Для доступа к приложению задействуется обозреватель Internet Explorer, и упрощенно аутентификация происходит следующим образом:

1| при начальной регистрации в домене Active Directory пользователь предоставляет свои идентификационные данные;

2| затем он получает специальный билет Kerberos для использования в приложениях;

3| Internet Explorer направляет запрос приложению для начала работы —— приложение запрашивает аутентификационную информацию —— Internet Explorer предоставляет полученный билет Kerberos;

4| приложение на сервере проверяет билет на контроллере домена Active Directory и открывает требуемую информацию обозревателю пользователя.

Преимуществом метода является высокая стойкость к взлому и подмене информации. Кроме того, идентификационные данные пользователя (имя + пароль) используются только один раз – в момент начальной аутентификации в домене Active Directory.

Удаленный доступ сотрудников компании к ресурсам корпоративной сети был организован с помощью модемного пула с аутентификацией на сервере Steel-Belted по протоколу RADIUS. Такое решение требовало отдельного администрирования базы пользователей RADIUS-сервера. Замена его на MS Internet Authentication Service позволила сэкономить время и средства.

Однако специфика работы сотрудников TTK, пользующихся удаленным доступом, – это частые командировки и редкое присутствие в центральном офисе, тогда как установка нового сервера влечет за собой смену паролей на рабочих станциях. Поэтому решение внедрялось путем постепенной миграции учетных записей с одного сервера на другой с помощью механизма proxy для RADIUS-сервера. Сотрудники, еще не перешедшие на новую схему распознавания, аутентифицировались старым сервером, а сменившие «прописку» – новым.

Слагаемые системы

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

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

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

На следующем этапе целевые системы были подключены к Tivoli Identity Manager в режиме сбора информации. Это приложение позволяет собрать информацию об учетных записях в целевых системах и сопоставить ее с данными кадровой системы. К сожалению, все системы управления учетными записями, автоматизируя процесс сопоставления, оставляют неотсортированными около 20% учетных записей, которые приходится обрабатывать вручную. Кроме того, обычно выявляются «мертвые души», т.е. записи, принадлежавшие уволенным работникам. Процесс изменения ролей пользователя был построен по модели, представленной на рис. 2.
. . .

Техническое воплощение любого проекта не обходится без трудностей. В данном случае ситуация осложнялась отсутствием примеров внедрения подобной системы на отечественном рынке (это был первый опыт). Да и сам продукт IBM Tivoli Identity Manager появился на рынке не так давно. Реальную работу технических решений приходилось подтверждать с помощью тестовых зон. Кроме того, наличие в информационной системе ТТК таких приложений, как MS Axapta и Steel-Belted Radius, потребовало дополнительной разработки коннекторов к ним.

Тем не менее проект был завершен и система управления правами доступа на базе IBM Tivoli Identity Manager успешно работает. Первые полгода прошли без рекламаций, и, что самое приятное, система признана лучшим проектом 2006 года по информационной безопасности в «Компании ТрансТелеКом».
Поделиться:
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!