Банка ДСК въвежда интегрирана система за управление на достъпа
Юрий Генов, началник на управление "ИТ операции" в Банка ДСК
Във финасовата институция е взето принципно решение за стандартизирането на всички приложни продукти и инфраструктурни услуги по отношение на авторизацията на потребителите. Плановете са до края на 2010 г. и всички приложни системи в ЦУ на Банка ДСК да предоставят достъп на потребителите, като се допитват до дефинициите им в профилите на изградената активна директория
Както всяка друга институция с малко повече натрупана история и Банка ДСК помни времето, когато поддържането и управлението на достъпа на потребителите се осъществяваше самостоятелно за всяка система, а във всяко поделение на банката имаше служител отговорен за предоставянето и следенето на достъп до информационните системи в поделението. Проверката на правилното управление на достъпа също ставаше само локално, когато служителите на ВКО пристигаха на проверка.
Със старта на внедряването на централизираните системи (през 2001 г.) в Централно управление се създадоха първите звена, които се занимаваха с поддържането на потребителските профили на служителите на цялата
банка. Все пак доминиращият брой системи и приложения си оставаха със самостоятелни и независими модули За управление на достъпа.
Сериозна крачка напред бе направена с внедряването на централни инфраструктурни услуги на базата на Active Directory (AD). Проектът реализиран през 2004-2005 г. създава условия за централизирано управление на достъпа не само до ресурсите на самите инфраструктурни услуги, но и до други системи.
В края на 2006 г. бе взето принципно решение 3а стандартизирането на всички приложни продукти и инфраструктурни услуги по отношение на авторизацията на потребителите. Допускат се следните две технологии:
• на база на разписването на потребителя в основната банкова система, когато става дума за предоставяне на достъп до данни свързани с клиентите на банката;
• на база на разписването на потребителя в Active Directory, когато става дума 3а вътрешнобанкова информация и инфраструктурни ресурси и услуги.
През 2008 г. стартира проект 3а внедряване на система за управление на идентичността (identity management).
РЕЗУЛТАТИТЕ
Какво постигнахме през последните години в областта на управление-
то на достъпа на потребителите до информационните ресурси и услуги?
На първо място - значителни промени в организационната структура, а също така създаване и приемане на правила и политики на база положителния опит на Банка ОТП. Накратко резултатите могат да бъдат обобщени по следния начин:
» В организационната структура настъпиха следните промени:
¦ Екипът, който поддържаше потребителските профили, се отдели от управление ИТ операции и се преструктурира, като отдел ИТ сигурност в самостоятелната дирекция Сигурност. Както и управление ВКО, дирекция сигурност е с особен статут и е на пряко подчинение на главния изпълнителен директор.
¦ В управление ВКО бе създадено самостоятелно звено, което се занимава с проверката на системите, спазването на политиките и правилата за достъп. Този екип разработи редица ценни препоръки за развитието на системите и преодоляването на слабите места.
» От потребителска гледна точка. Като правило служителите имат един-единствен идентификатор за работа с приложните и инфра-структурните системи на банката. Все още поддържаме две отделни пароли - едната за разписването 6 Active Directory (AD) и друга за банковото приложение. Това до известна степен диверсифицира риска, дава възможност новопостъпилите служители в банката веднага да получат достъп до инфраструктурни ресурси и да започнат пълноценен процес на обучение. Чак след съответните курсове и полагането на изпит те получават и достъп до банковата система.
» От технологична гледна точка. Вече трета година всички нови разработки се проектират и се поръчват в съответствие с приетите правила и Вече десетки работещи приложения предоставят достъп на потребителите, като се допитват до дефинициите им в профилите на AD. Първата стъпка бе това да се направи за всички системи работещи в поделенията. А плановете са до края на 2010 г. и всички приложни системи в ЦУ на Банка ДСК да работят по този начин.
За облекчаване работата на служителите от отдел „ИТ сигурност" бе стартиран един от основните проекти на Банка ДСК за 2009 г. -въвеждане на интегрирана система За управление на достъпа на служителите до ресурси и системи. На този етап тя ще интегрира и синхронизира данните на служителите в управление „Човешки ресурси", 6 AD и в основното банково приложение.
Особено място сред средствата за управление заема системата За абтентикаиия на клиентите на банката в електронните канали. Без да усложняваме изложението, можем да кажем, че цялата идентификация и връзките към ресурсите, които са достъпни на клиентите, се управлява и осъществява в основното банково приложение.
ИНТЕГРАЦИЯТА НА ПРИЛОЖНИТЕ СИСТЕМИ
Всички служители на банката имат свои уникални потребителски идентификатори в AD, c които се разписват по работните станции 6 мрежата. Достъпът на служителите до различни ресурси се управлява чрез групова принадлежност на техните потребителски идентификатори. Ако служител трябва да достъпи
определен ресурс, неговият потребителски идентификатор се поставя в група, която е настроена да достъпва този ресурс.
Всеки потребител задължително членува 6 следните три типа групи:
• функционални групи (с префикс FG). Те отразяват длъжността (3а служителите в клоновата мрежа) или Звеното, в което работят (3а служителите в централно управление). В името на групата, след префикса FG, се изписва наименованието на длъжността/звеното, преведено на английски. Функционалните групи са изградени на йерархичен принцип, като функционална група на ръководител на звено членува (Member of) 6 подчинените функционални групи. По този начин може да се проследи подчинеността на длъжностите в банката.
• Структурна група (с префикс StG). Те отразяват принадлежността на служителите към поделенията/ЦУ на банката. В името на групата, след префикса StG, се изписва сигнатура на поделението, последвано от името на поделението. Структурните групи са изградени на йерархичен принцип, като структурна група на поделение по-високо в йерархията, членува (Member of) в подчинените поделения. По този начин може да се проследи подчинеността на поделенията 6 банката.
• Покационна група (с префикс LG). Тези групи отразяват сградата, в която работи служителят. В името на групата, след префикса LG, се изписва сигнатура на поделението, последвано от името на поделението. Локационните групи не са изградени на йерархичен принцип.
За всеки потребител в AD има параметри, които ясно го отличават и определят неговата принадлежност. В таблица 1 са посочени някои основни параметри.
AD е изградена на базата на Windows Server 2003. Поддържаните системи за абтентикация са Kerberos и NTLM (виж. „Терминологичен речник").
Информацията на банката е организирана чрез »гоРа от домейни" (Domain Forest) и един домейн с име "dsk.grp". Домейн контролерите са сървъри, които съдържат базата данни на AD и с които приложенията се свързват за нуждите на абтентикация и авторизация. В Центъра за данни има 5 домейн контролера, с които приложението трябва да може да комуникира.
ИЗИСКВАНИЯ КЪМ ВНЕДРЯВАНИТЕ ПРИЛОЖЕНИЯ
» Връзка на приложенията с базата на AD. Приложенията се свързват с базата на активната директория посредством системни потребители, създадени за конкретното приложение. Тези потребители не могат да се ползват за разписбане на конзолите на работни станции и сървъри и могат да се ползват само от програмни средства. Системните потребители могат да четат информацията в базата данни на активната директория, но не могат да я променят (изключение от този принцип прави само системата за управление на достъпа IDM).
» Достъп до приложение -функции и роли. Права за достъп до ресурси на различни приложения се дефинират чрез ролеви групи (вътре в самото приложение). Ролевите групи отразяват всяка една от ролите в конкретното приложение. Ролите обхващат множество от изпълнявани функции.
» Административен модул. Всяко приложение трябва да има административен модул, чрез който се създава съответствие между ролевата група в приложението и групите от активната директория, 6 които членуват потребителите за съответната роля.
» Непрекъсваемост на автен-тикация и авторизация. За да не се нарушава работоспособността по причина отпадане на автентикаиия и авторизация (отпадане на домейн контролер), продуктът трябва да може да се обръща автоматично към следващ домейн контролер при отпадане на един от тях. T03U механизъм трябва да може да работи до изброяване на всички 5 домейн контролера в центъра за данни.
» Документация. Всяко приложение трябва да е съпроводено от набор документи, които да описват следните по-важни действия:
• Документация 3а потребителя (User Guide) - описание на работата на потребителите с продукта
• Документация 3а администратора на приложението - описание на административния модул, инструкция за инсталация, описание на процедури 3а Backup and Restore, описание на грешки и логове, генерирани от продукта
• Изисквания към операционната среда и ограничения по отношение на Update, съвместимост/несъвместимост с други продукти
• Документация за оператора на приложението - описание на начина на наблюдение на работата на продукта и начин на реакция при инциденти.
КОНТРОЛ НА ДОСТЪПА ДО МНОГОМЕРНИ БАЗИ ДАННИ
Един от най-интересните аспекти е свързан с предоставянето на достъп до системи съдържащи многомерни бази данни, каквито са данните събирани и структурирани в т.нар. „хранилища за данни" (Data
Warehouse). Такава система е част от ИТ инфраструктурата на Банка ДСК и е в редовна експлоатация от една година (виж. СЮ 4/2009).
Сложността на управлението на достъпа go Data Warehouse идва от факта, че ако множество крайни потребители работят в така&а система, то при тях трябва да се проследява както функционалната им специфика (съответстваща на длъжностната характеристика), така и принадлежността към една или друга йерархична структура (съответстваща на клон, финансов център, регионален център, Централно управление). Подобни Зависимости има и по отношение на банковите приложения, когато служител от даден регионален център има достъп до вътрешнобанко-вата информация на всички офиси, клонове и финансови центраве 8 структурата на този регионален център.
За да решим въпроса, без да усложняваме излишно технологиите, За Data Warehouse се приеха следните правила:
¦ Data Warehouse предоставя информация на служителите от поделенията на банката само чрез система от предварително дефинирани отчети, реализирана в самостоятелно приложение, достъпа на което е интегриран с AD и се определя на базата на длъжност на потребителя - FG група (до кои отчети има достъп) и поделение на потребителя - StG група (до данните на кои поделения има достъп), като лимитирането на достъпа е задача на приложението, а не на базата данни.
¦ Data Warehouse предоставя информация на служителите от Централно управление на банката освен чрез система от предварително дефинирани отчети, реализирана в самостоятелно приложение, само чрез Oracle BI. Достъпът на служителя се определя на базата на неговата длъжност - FG група, като в Зависимост от нея той може или не може да достига до информацията предоставена в различните Data Marts. За служителите от ЦУ не се
налага да се въвеждат ограничения по отношение на структурните единици, тъй като те достъпват информацията на ниво банка. Oracle BI също е интегриран с AD.
¦ Като трета група се отделят разработчиците, при които достъпът до информацията се ограничава и контролира с организационни методи. Например - работа в самостоятелна база, в която изобщо не се осигуряват реални цифри и т.н.
В ЗАКЛЮЧЕНИЕ
Управлението на достъпа до информационните ресурси е само една от многото задачи на всяка организация, която се стреми към високо ниво на информационна сигурност. В тази статия представяме подходът, възприет при решаването и от Банка ДСК.
***
Терминологичен речник
Kerberos - автентикационен протокол Kerberos е разработен през 80-те години в САЩ в Масачузетския технологичен институт (MJT) В рамките на проекта Athena, Наречен е на името на триглавото куче от митологията, охраняващо входа на подземния свят. Kerberos е автентикационен протокол, включващ в себе си няколко подпротокола, обхващащи и трите фази на автентикацион-ния процес, поради което често се нарича автентикационна система. При използване на Kerberos достъпът на потребителите до ресурси се разрешава с помощта на трета страна - защитен сървър. Всеки път когато даден клиент поиска достъп до файловия сървър, той следва първоначално да се обърне към защитения Kerberos, за да получи "пропуск" до желания ресурс. Всеки Kerberos сървър поддържа своя област за автентикация. При първоначалната инсталация се установяват областите, съответните отговорни за тях защитени сървъри и клиентите 8 отделните области. NTLM или Windows NT LAN Manager е протокол, използван за удостоверяване на потребителите в мрежа на Microsoft Windows)
