5.2.9.Фаза 2: робочі групи замовників

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

Рис. Фаза 2 – політики для робочих груп замовників.

Політики захисту робочих груп можуть управляти доступом як індивідуальних користувачів, так і цілих робочих груп. Розглянемо приклад на рис. . Після розгортання одної загальної політики для керівного персоналу і цілого фінансового управління, організація вирішила підвищити захист LAN, утворивши дві робочі групи. Керівна група включно з головним адміністратором і головним фінансовим адміністратором прийняла політику захисту для замовника – “Робоча група керівників”, всі учасники фінансових підрозділів включно з головним фінансовим адміністратором – політику захисту для замовника – “Фінансова робоча група”. Ці дві політики замовників віжрізняються від простої загальної політики, впровадженої у Фазі 1: кожна політика замовника має групову ідентичність, яка вживається для запобігання зовнішньому доступу, наприклад, за допомогою використання різних секретних ключів для кожної із груп. Використовуючи політики замовників, головний адміністратор може вирізняти головного фінансового адміністратора від інших учасників фінансового відділу. Крім того, політики замовників можуть використовувати різних ініціаторів сполучень, відповідачів та різні правила відходу. Наприклад, при загальній політиці фінансовий сервер завжди здійснює повернення до сполучення з відкритим текстом. З політикою замовників, доступ до сервера може бути обмежений тільки до учасників фінансової робочої групи, виключаючи таким чином правило повернення до відкритого тексту. При загальній політиці система завжди пропонує сполучення, зашифроване IPSec. Із політикою замовників, учасники фінансового відділу можуть пропонувати сполучення з відкритим текстом до сторонніх включно з публічним поштовим сервером. Політики замовників дозволяють організації точно настроювати режими робочих груп. Робочі групи з найвищим ризиком можуть бути “закриті”, тоді як інші можуть вживати як захищені, так і незахищені сполучення, залежно від ідентичності віддаленої кінцевої системи.

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