Безпека SOA 1-2-3

У даній серії статей читачеві пропонується план реалізації системи безпеки для сервіс-орієнтованої архітектури (Service-Oriented Architecture, SOA). У цій статті, першою з трьох статей серії, описується процедура з 10 кроків, яка буде корисною на будь-якому етапі – від формування робочої групи з безпеки SOA-додатки до створення ефективної процедури збору вимог. У частині 2 ви дізнаєтеся, як створити високорівнева проект, а в частині 3 описуються контрольні приклади.


У недавньому минулому у мене була можливість попрацювати над проектом SOA – конкретніше, над реалізацією системи безпеки для масштабної системи автоматичного управління. Я читав усі книги з цієї теми, які тільки зміг знайти, вивчав матеріали, опубліковані в інтернеті і навіть вів листування по електронній пошті з колишніми колегами і друзями, з якими мені доводилося працювати раніше. На подив, я не знайшов жодного плану з покроковим описом процедури, яку можна було б використовувати для виконання мого завдання – забезпечення безпеки масштабного SOA-додатки.


У підсумку я створив свій план. Я розробив просту процедуру з 10 кроків, яка і пропонується в даній статті.


Крок 1. Сформуйте оптимальну робочу групу


Переклад масштабних програм та критично важливих інфраструктур на SOA – непросте завдання. Забезпечити їх безпеку ще складніше; при цьому часто необхідно, щоб співробітники мали абсолютно нової манерою мислення;-цілком імовірно, що вам доведеться повністю оновити штат фахівців з безпеки. Фахівці з безпеки зазвичай погано знаються на SOA або навіть в програмуванні. Звичайний для головних спеціалістів із забезпечення безпеки підхід полягає в тому, щоб переслати в організації свої рекомендації і сподіватися на те, що вони підійдуть для неї. Отже, крок 1 – і, найчастіше, найважчий – Переконатися, що підібрані фахівці відповідної вашим вимогам кваліфікації.


Керівником робочої групи з безпеки має бути людина, що розбирається як в питаннях безпеки, так і в архітектурі програмного забезпечення, переважно, в SOA. Розробник архітектури забезпечення корпоративної безпеки (security enterprise architect, SEA), як і розробник корпоративної архітектури, відповідає за створення загальної моделі безпеки SOA-додатки, призначеної для інтеграції різних вимог до забезпечення безпеки на будь-якому рівні деталізації. SEA входить до складу ради управління SOA, спільно з розробником корпоративної архітектури (enterprise architect, EA) працює над забезпеченням відповідності всіх SOA-реалізацій вимогам безпеки і очолює групу бізнес-аналітиків у сфері безпеки (security business analysts, SBAs) та інженерів систем забезпечення безпеки (security systems engineers, SSEs), що відповідають за створення артефактів, необхідних протягом всього процесу. Спеціаліст SEA, крім того, відповідає за роботу з програмістами, забезпечують написання коду сервісів безпеки і тестувальники систем, що забезпечують проведення тестування систем до їх розгортання.


Крок 2. Складіть деталізований план проекту


2 крок у разі великих SOA-систем вимагає від керівників вищої ланки розуміння того, що пристосувати нову архітектуру SOA до старої моделі безпеки неможливо: це просто не буде працювати. Якщо з самого початку сконцентруватися на традиційних механізмів забезпечення безпеки (таких як міжмережеві екрани, системи виявлення вторгнень і моніторинг безпеки), можна взагалі не домогтися успіху у забезпеченні безпеки SOA-реалізації. Ваше завдання – добитися розуміння цього положення кожним учасником процесу; для цього необхідно створити деталізовані плани проекту та кошторису, що виявляють та точно відображають, у що виллється реалізація системи безпеки SOA-додатки.


Необхідно повідомити колегам, що перехід на SOA-модель пов'язаний з невід'ємним для цієї архітектури парадоксом щодо безпеки: чим більше ознак SOA мають системи, тим слабше їх безпеку. У процесі перетворення наявних систем в архітектуру SOA через сервіс-орієнтоване моделювання та аналітичні методики необхідна документація по бізнес-проектом. При використанні формального мови для співвіднесення бізнес-проекту з інформаційними системами часто стає очевидним, наскільки суперечливими, неефективними і складними можуть бути традиційні, не-SOA, системи. Однак ця складність часто ховає від сторонніх очей безліч похибок реалізації та ускладнює особам, які намагаються завдати шкоди корпоративній системі, їх виявлення. Після того як системи будуть приведені в порядок, і ви почнете використовувати SOA, зловмисні користувачі отримають більш просту архітектуру, яку легше скомпрометувати.


Прихильники SOA можуть не погодитися з цим твердженням, але фахівці, що відповідають за забезпечення безпеки систем знають, що відкриті, що використовують Web-ресурси системи з централізованим управлінням менш безпечні за своєю суттю і вимагають більш гнучкого підходу і реагування. Цим не можна нехтувати, тому планувальники проекту (які часто обмежуються досить скромним набором завдань щодо забезпечення безпеки SOA-додатки) повинні пам'ятати, що забезпечення безпеки SOA-додатки вимагає розробки деталізованих планів проекту та кошторисів, які дозволять робочим групам з безпеки відвести достатньо часу на аналіз і ідентифікацію нових проблем, пов'язаних з SOA-реалізаціями.


Крок 3. Ведіть таблицю рішень з безпеки для процесу впровадження SOA


Ведіть офіційну документацію високорівневої динаміки системи безпеки SOA-додатки за допомогою таблиці рішень з безпеки для процесу впровадження SOA. У цій таблиці за допомогою зацікавлених бізнес-учасників всі програми діляться на три категорії, а саме:



Кожній окремій категорії для наочності добре привласнити певний колір. Наприклад, я позначив об'єкти в першій категорії червоним, у другій – помаранчевим, а в третій категорії – жовтим кольором.


Потім робоча група з безпеки ділить програми за рівнем вимог до безпеки на три категорії – висока, середня і низька безпека. Наприклад, додатки або сервіси, які мають справу з інформацією по ринку та відомостями, що не підлягають оголошенню, потрапили б у вищу категорію безпеки, тоді як програму або сервіси, які звертаються тільки до даних, що знаходяться у відкритому доступі, можуть бути поміщені в саму нижчу категорію.


У таблиці 1 показаний приклад таблиці рішень з безпеки для процесу впровадження SOA.


Таблиця 1. Таблиця рішень з безпеки для процесу впровадження SOA


Як тільки моделі стануть деталізованими, необхідно вивчити детальні стандарти безпеки SOA-програми, що входять в WS-Security, і зрозуміти, як вони співвідносяться один з одним і з вимогами до моделі безпеки SOA-додатки. Ці стандарти безпеки будуть використовуватися для формування безпечних повідомлень у всій SOA-реалізації.


Крок 10. Розробіть стандарти для сторонніх розробників.


На закінчення, при виконанні кроку 10 робоча група з безпеки SOA-додатки створює набір стандартів і інтерфейсів прикладного програмування (application program interface, API) для сторонніх розробників. Один з головних комерційних аргументів SOA полягає в тому, що системи, побудовані на цій архітектурі, можуть використовувати свою відкритість шляхом доступу до сервісів, що надаються сторонніми розробниками. Кожен розробник повинен добре знати стандарти безпеки для SOA-реалізацій і мати чітке уявлення про те, як його сервіси будуть взаємодіяти з сервісами безпеки SOA-реалізацій.


Протягом всього процесу розробки необхідно вести найдетальніший глосарій по термінах безпеки; це дозволить забезпечити використання одних і тих самих термінів і визначень у всіх створюваних документах. Я раджу на початку роботи використовувати глосарій Oasis Security Services TC Glossary. Цей глосарій слід використовувати спільно з усіма іншими розробниками, щоб гарантувати єдність термінології.


Висновок


З даної статті ви дізналися, як за 10 кроків створити план реалізації безпеки SOA-програми:



Виконавши всі ці дії, ви забезпечите собі хорошу стартову точку у реалізації безпеки SOA-додатки.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*