Безпека SOA 1-2-3, Частина 1, Oracle, Бази даних, статті

У даній серії статей читачеві пропонується план реалізації системи безпеки для сервіс-орієнтованої архітектури (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






















Безпека (висока) Безпека (середня) Безпека (низька)
Червоний 36 12 11
Помаранчевий 12 5 3
Жовтий 6 0 6

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


Для системи безпеки, побудованої на SOA, почніть зі створення інфраструктури управління ризиками, як описано в кроці 4.


Крок 4. Створіть проект з використанням принципу інфраструктури управління ризиками


На цьому етапі використовується принцип “безпеки зсередини”. “Безпека зсередини” означає, що оцінка безпеки повинна бути однаковою для всіх діяльностей в реалізації SOA. Необхідно розібратися в тому, як буде працювати реалізація SOA (шляхом перегляду проектної документації), відзначити, в яких моментах необхідне рішення з безпеки, та ідентифікувати контрольні точки безпеки, в яких ці рішення будуть реалізовані.


Ми використовуємо механізми для прийняття цих політик безпеки і застосуємо їх, поклавши їх виконання на додатки, сервіси безпеки SOA-додатки і, в міру необхідності, на SOA-компоненти. Необхідно вирішити питання про інкапсуляції або декомпозиції вимог з безпеки в набір сервісів безпеки, які будуть діяти в будь-якій точці SOA-реалізації. Так, наприклад, можна покласти завдання аутентифікації користувачів на сервіс безпеки Authentication Security Service, звертатися до якого і взаємодіяти з яким доведеться всім додаткам. І навпаки, можна сконфігурувати сервісну шину підприємства (Enterprise service bus, ESB) на обмеження доступу до окремих повідомленнями на кшталт “додаток за додатком”. (Докладніше про це читайте в частині 2.)


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


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


У дуже корисною книзі Гері Мак-Гроу (Gary McGraw) (див. розділ Ресурси) докладно описується процедура з п’яти частин, яка може допомогти в створенні інфраструктури управління ризиками (risk-management framework, RMF). Якщо коротко, ви повинні:



Розуміння бізнес-контексту, наприклад, робить очевидним, що в системі відкритих торгів між виробниками при тому, що кожен з них повинен мати можливість доступу до своєї власної інформації, навряд Чи буде правильним, якщо виробники зможуть бачити інформацію один одного. Класифікація даних має сенс тільки в бізнес-контексті, вона не може бути виконана за допомогою простої ієрархічної моделі, показаної в кроці 3.


Крок 5. Визначте зацікавлених осіб усередині організації (“своїх”) і за її межами (сторонніх)


Розібравшись в цих принципах, можна перейти до кроку 5. На цьому етапі група з безпеки SOA-додатки ідентифікує і виділяє зацікавлених у безпеці SOA-додатки осіб. Ці зацікавлені особи поділяються на дві категорії: сторонні і “свої” зацікавлені особи. Сторонні керівні органи, що приймають рішення, наприклад, Північно-Американська корпорація з питань надійності енергопостачання (North American Electric Reliability Corporation, NERC) можуть мати певні стандарти безпеки електронного простору, такі як вимоги захисту критично важливих інфраструктур (Critical Infrastructure Protection, CIP), які мають явні наслідки для реалізацій систем безпеки.


CIP охоплює такі різні області, як Security Management Controls (Елементи управління безпекою) (CIP-003-1), Electronic Security Perimeter (s) (Електронний периметр безпеки) (CIP-005-1), Physical Security of Critical Cyber ​​Assets (Фізична безпека критично важливих електронних ресурсів) (CIP-006-1), Systems Security Management (Управління безпекою систем) (CIP-007-1), Incident Reporting and Response Planning (Створення звітів про інциденти та планування реагування) (CIP-008-1) і Recovery Plans for Critical Cyber ​​Assets (Плани аварійного відновлення для критично важливих електронних ресурсів) (CIP-009-1). Всі ці стандарти формують свої набори специфічних вимог, які впливають на загальну реалізацію безпеки SOA-додатки.


Крім того, внутрішні вимоги до безпеки, які часто називають стандартами безпеки послідовності операцій (Security Standard Operating Procedures, SOP), відповідають на всі питання хто, що, де, коли і як щодо безпеки. Кому і до чого дозволений доступ, коли і де, яким чином і як довго? У багатьох організаціях ця інформація по своїй суті змінюється з плином часу і стає неорганізованою та неузгодженою; SOA-реалізація часто вимагає значної роботи по створенню систематичного документа, який точно відображав би політики безпеки даної організації.


Крок 6. Правильно виберіть і використовуйте інструменти для збору вимог

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


Добре продумані вимоги до безпеки та аналітичні методи істотно знизять ризики для безпеки системи. Інструменти визначення та аналізу вимог IBM ® Rational ® добре підходять для розуміння та подання потреб зацікавлених осіб, ведення та координації колекції та верифікації потреб споживачів і бізнесу, документування та організації вимог до системи, а також для ознайомлення до вимог кожного члена робочої групи. Я використав в роботі і рекомендую вам такі інструменти, як IBM Rational RequisitePro ®, WebSphere ® Business Modeler і Rational Software Architect.


Крок 7. При реалізації безпеки SOA-додатки дотримуйтеся схеми процесу SDLC


Враховуючи величезний обсяг інформації, який необхідно зібрати, кількість архітектурних артефактів, які необхідно написати, і конкретні сервіси безпеки SOA-додатки, які необхідно спроектувати, робочій групі з безпеки SOA-додатки слід дотримуватися стандартної схеми процедури Життєвий цикл розробки програмного забезпечення (Software Development Life Cycle, SDLC):



  1. Ідентифікація вимог до безпеки і обмежень;
  2. Виявлення та збір вимог до безпеки системи;
  3. Створення безпечного архітектурного проекту;
  4. Документація деталізованого безпечного проекту SOA;
  5. Реалізація SOA (включаючи управління SOA);
  6. Тестування;
  7. Розміщення;
  8. Обслуговування.

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


Перш ніж робоча група приступить до розробки рішень, вона повинна зібрати вимоги до систем. Існують як явні, так і неявні вимоги до реалізацій забезпечення безпеки. Що стосується явних вимог, хорошою стартовою точкою буде збір вимог від кожного із зацікавлених осіб, про яких йшлося в пункті 5. Щодо неявних вимог до безпеки корисно використовувати інфраструктури забезпечення безпеки, наприклад, тріаду конфіденційність, цілісність і отслеживаемость (confidentiality, integrity, and accountability, CIA); з урахуванням якої складається список конкретних вимог до всіх систем безпеки. Тріада CIA являє собою широко використовувану модель гарантування інформації (information assurance, IA), яка визначає конфіденційність, цілісність і доступність як основоположні характеристики безпеки всіх інформаційних систем.


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


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


Крім того, однією з вимог безпеки SOA-додатки є своєчасний і надійний доступ до сервісів даних для авторизованих користувачів (доступність). SOA-реалізації повинні гарантувати, що ці ресурси або інформація будуть доступні, коли в них виникне необхідність, це означає, що доступ до ресурсів може бути здійснений на швидкості, достатньої для того, щоб віддалена система могла виконати свою задачу запропонованим чином. Безумовно, можливі випадки, коли заходи по захисту конфіденційності та цілісності прийняті, але атакуючий тим не менш може зробити ресурси менш доступними, ніж потрібно, або взагалі недоступними. Зокрема, коли в якості брокера повідомлень використовуються компоненти SOA-системи, такі як ESB, то для забезпечення її доступності та надійності необхідно вказати в документації вимог до безпеки SOA-додатки, що необхідно використовувати протоколи високої доступності, мережні архітектури з резервуванням і апаратне забезпечення системи, не має ні однієї одиночній точки відмови. Робоча група з безпеки SOA-додатки повинна забезпечити всеосяжне виявлення всіх зазначених областей і гарантувати, що відповідні контрольні приклади будуть задокументовані і зможуть проілюструвати певні вимоги.


Крок 8. Знайдіть готові моделі і вчіться на їх прикладі


Після того як робоча група з безпеки SOA-додатки приділила деякий час обговорення всіх описаних вимог, члени групи повинні з’ясувати, чи не можна виконати їх за допомогою інструментів сторонніх виробників. Вони повинні написати програми сервісів безпеки SOA, які будуть задовольняти конкретним вимогам. Щоб не винаходити колесо, краще і корисніше ознайомитися з уже наявними моделями і дізнатися, які розробки вже були зроблені до того, як дана робоча група перейшла до етапу високорівневого проектування. Тут, на 8 етапі процедури, я рекомендую звернути увагу на наступні моделі від компанії Intelligrid (див. розділ Ресурси). Нижче представлений список і опис зазвичай використовуються службових сервісів, які можуть стати в нагоді вам в SOA-реалізації. Більш докладно про ці сервіси ми поговоримо в наступній статті, тут я наводжу список:



Можливо, вам знадобляться не всі ці сервіси. Співробітники робочої групи з безпеки SOA-додатки повинні порівняти вимоги з кожним сервісом, потім створити модель безпеки SOA для всіх сервісів, необхідних для задоволення вимог, виявлених на 7 етапі.


Після того як ви виконаєте описані дії і зберете достатньо інформації, можна перейти до виконання кроку 9, в ході якого необхідно переглянути стандарти WS-Security і з’ясувати, які з них застосовні до вашої конкретної реалізації безпеки SOA-додатки. На малюнку 1 представлена ​​схема всіх стандартів WS-Security, які необхідно переглянути.


Рисунок 1. Стандарти WS-Security



Як тільки моделі стануть деталізованими, необхідно вивчити детальні стандарти безпеки 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>

*

*