SOA променя картината на сигурността

SOA променя играта в информационната сигурност

Нейната стратегическа цел за постигане на взаимна съвместимост, интеграция, виртуализация на услугите и повторно използване изискват радикално нов подход към архитектурата на сигурността.

Взаимната съвместимост и интеграцията означават, че бизнесът предлага услуги, базирани на стойността, която добавят към обслужването на клиентите и доставчиците (например, отпечатване на самолетна бордна карта от Web.), a не просто на ИТ областта , като собствени CRM или ERP системи. Виртуализацията в контекста на Web услугите означава, че мястото на осъществяване на услугата няма връзка с времето на действието, давайки възможност на партньори в Чикаго, Бангалор и Токио да работят съвместно по даден бизнес процес. Повторното използване на бизнес логика позволява създаването на по-надеждни и ценово ефективни платформи, премахвайки необходимостта всеки проект да започва от основите. Това извиква нуждата и от повторно използваеми услуги по сигурността.

Поговорката, че сигурността трябва да бъде проактивен двигател на бизнеса повече от всякога важи в среда на SOA. Преодоляването на приемането, че мерките за сигурност са препятствие за търговията е задължително.

Как ще се случи това? Услугите по сигурността изискват проектиране, разработване и поддръжка на действието им, които да са насочени към най-големите рискове или към най-големите стойности за бизнеса. С времето в организациите започва прилагането на модели за интеграция и мениджърите по сигурност трябва да помогнат за определянето на най-изгодните инвестиции в сигурността, балансирайки повторно използваеми споделени услуги. Това измества сигурността далеч от ролята на одитор и я прави определяща в изграждането на бизнес услугите.

Нека да разгледаме ключовите елементи, които мениджърите по сигурност, трябва да вземат под внимание при изграждането на архитектурата на 21- век.

• Партньори с дялове в сигурността

Този често игнориран урок е много съществен в света на SOA. Бъдещето на ИТ сигурността е партньорството с бизнеса, софтуерното разработване (дори да е аутсорсвано) и клиентите. Колкото по-рано сигурността бъде взета под внимание, толкова по-вероятно е да бъдат внедрени механизмите, които налагат изисквания към сигурността, отколкото да бъдат прикачени след разгръщането на системата.

• Рискът за бизнеса

Има „вроден” технически и бизнес риск при всяка интеграция – умножете това стократно при SOA, която се отнася изцяло за платформена и процесна взаимна съвместимост, пресичаща бизнес, географски и технически граници. Това е и предимство. При интегрирането на клиенти и партньори бизнесът печели, а рисковете за сигурността се оценяват по-лесно в термините на риска за бизнеса, понеже са свързани с дадена бизнес услуга, а не с ИТ като цяло. Вкарайте бюджета по сигурност там където бизнесът инвестира.

• Правете го с цифри

Рискът е цифри. Оценете количествено ситуацията и измервайте развитието с времето. Като се вземе под внимание хетерогенната, разпределена структура на SOA, присъединяването на измервателна система към сигурността помага на екипа да „вижда” състоянието обективно и дава възможност на „дяловите” участници да вземат решения.

• Омесете сигурността в разработването

Сигурността трябва да функционира като партньор, а не като одитор. Въведете сигурността рано, най-добре още в жизнения цикъл на разработването на софтуера за SOA. Наложилата се с времето ситуация е такава, че разработчиците гледат на сигурността като на препятствие, така че бъдете проактивни, представете това, което ще спести инвестиции и време, например услуги по сигурността с повторна употреба.

Например базираната на браузър еднократна регистрация, използваща стандарта SAML, предоставя по-добра, по-бърза, по-евтина услуга по автентификацията, която може да е валидна за много приложения.

Предложете експертиза чрез услугата моделиране на заплахите и помогнете да се дефинират изискванията към сигурността в проекта и предоставете тестване на сигурността и на възможните въпрос и отговори.

• Гледайте по-широко от центъра

ИТ сигурността трябва да обхване децентрализирана архитектура, понеже SOA изтиква вземането на решения извън границите на организацията.

Архитектурният проблем е как да се наложи еднородна политика по сигурност в разпределени крайни точки и междинни локации, които е твърде вероятно да не контролирате или да не можете непрекъснато да проверявате.

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

• Приемете съобщението

SOA e XML ориентиран към документи-съобщения начин за организиране на системи. При традиционната ИТ сигурност сървърът идентифицира и упълномощава клиента при заявка от негова страна. При SOA интеграцията обаче съобщението-документ съдържа информацията (не централен сървър), която доставчикът на услуги изисква, за да извърши автентификация и оторизация.

Архитектурата на сигурността трябва да отразява това. За много организации по ИТ сигурност това е единствената промяна в начина на мислена, която е необходима.

Този модел изисква ИТ сигурността бързо да се нагажда към бизнес целите, защото все по-малко се разчита на физическите граници и трябва да се проверяват (да се извършва одит) на всички междинни и крайни точки.

Съобщенията са защитени чрез кодиране, цифров подпис и потвърждаване на съдържанието, независимо дали се използват в Амстердам, Сидни или Рим.

Фокусирайте корпоративната сигурност върху проектирането и внедряване на механизъм за съобщения с повторна употреба като подпис и криптиране, които позволяват широка съвместимост чрез отворени стандарти като WS Security и SAML. Тъй като това не е обикновено разработване с обичайните средства, се появиха специализирани инструменти като XML Gateway Security.

• Внедрете обединена идентичност

Тъй като цифровата идентичност е изключително контекстно-специфична, подходът на SOA с висока разпределеност създава сериозни предизвикателства в осигуряването и управлението на достъпа. Нито една система не ви казва всичко по отношение на идентичността, а по-скоро една услуга прави твърдение за определена идентичност и подкрепящите я услуги го преценяват.

В тази светлина е критично важно да се разберат както възможностите, така и ограниченията на вашите корпоративни системи за осигуряване, управление и обединяване на достъпа.

За щастие обединената идентичност използва основните принципи на SOA, за да осигури идентичността като услуга, разширявайки обхвата на управление на корпоративната система за идентичност.

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

• „Бронирани” обслужващи регистри

Регистрите на услугата, които съхраняват и управляват интерфейса й и асоциираните с нея политики, съдържат две важни неща, които трябва да се имат предвид. Те съдържат ценна информация като схеми на данните, информация за интерфейса на услугата и за политиката, които трябва да бъдат защитени чрез контрол на достъпа.

В идеалния случай те трябва да имат най-високо ниво на защита, каквото има ядрото на ОС. Освен това, понеже регистрите на услугата са мястото, където се описват метаданните на политиката и механизма на сигурността по време на разработването и се изпълняват по време на работа, екипът по ИТ сигурност трябва да гледа на тях като на ключов елемент за публикуване и налагане на политика по сигурността.

• Подсигурете мидълуера

Досега се смяташе, че мидълуерът се намира зад защитната стена, изолиран от външния свят. Изискванията за интегриране при SOA разчитат много повече на мидълуера, например на корпоративните магистрали за услуги, които позволяват надеждно, асинхронно предаване на съобщения и на аранжиращите машини, които управляват взаимодействието между различните услуги. Те функционират като децентрализирани хъбове, събиращи корпоративните услуги и данни и свързващи ключовите системи. Тази нова роля променя основно ролята им по отношение на защитата и изисква обстоен преглед на архитектурата ви на сигурност.

Важният момент е да осигурите, че съобщенията имат достатъчно права по отношение на сигурността, за да бъдат маршрутизирани по мрежата, като в същото време ограничите достъпа до самата информация. Мислете за плик, съдържащ писмо (ХML съобщение), който изисква точен адрес и пускане в пощата, но не позволява на пощенския чиновник (мидълуера) да чете неговото съдържание.