Як реалізується контроль мережевого доступу всередині компанії Cisco?

чи Знаєте ви що з себе представляє мережа компанії Cisco? Ось кілька цифр, які показують масштаб стоять перед нашими ІТ та ІБ-службами завдань:

  • 3 мільйона IP-адрес
  • 40 тисяч маршрутизаторів
  • 215 тисяч инфраструктурых пристроїв
  • 120 тисяч користувачів
  • 275 тисяч вузлів, з яких 135 тисяч ноутбуки та десктопи і 68 тисяч — мобільні пристрої на платформах iOS, Android, BlackBerry, Windows та інших
  • Офіси в 170 країнах світу
  • 26 тисяч домашніх офісів
  • 1350 лабораторій
  • 300 бізнес-партнерів, які мають доступ до нашої інфраструктури (логістика, виробництво, розробка, тестування тощо)
  • понад 700 провайдерів хмарних послуг, якими ми користуємося у своїй повсякденній діяльності.

Очевидно, що така масштабна і розподілена мережа, та ще й з нечітким периметром, потребує адекватної захисту і контролю доступу. Якби у нас одна точка виходу в Інтернет, відсутність зовнішніх зв'язків, заборона корпоративних і власних мобільних пристроїв (BYOD), а також гарантія відсутності випадкових або умисних підключень до стороннім Wi-Fi-точок або використання 3G/4G-модемів, ми б могли концентруватися на захист периметра і жити розкошуючи. Але на жаль… Cisco давно пішла від периметрового підходу і не тільки розмила свої кордони, давши співробітникам мобільні пристрої, перевівши їх на роботу з лептопами і забезпечивши «домашніми офісами», а й надала доступ до своєї інфраструктури своїм бізнес-партнерам, які наповнюють наші склади, забирають готову продукцію, займаються розробкою окремих компонент наших рішень, забезпечують виробництво і т. п. Але і це не все. З метою оптимізації ресурсів компанії та ІТ-служби ми пішли в хмари, уклавши договори з більш ніж 700 різними хмарними провайдерами, які надають нам широкий спектр послуг — телеконференції, CRM, зберігання файлів, корпоративні соціальні мережі, кадровий та бухгалтерський облік, BI і т. п. Нарешті, не варто забувати про периферійне обладнання типу принтерів, IP-телефонів і персональних систем TelePresence, а також різні Інтернет-«речі» — термостати, освітлення, пожежна сигналізація, системи контролю фізичного доступу і т. п. Все це МЕРЕЖА компанії Cisco, доступ до якої потрібно контролювати.

Намагатися вирішити завдання контролю такої різноманітної інфраструктури в лоб, прописуючи правила на кожному інфраструктурному пристрої (точці доступу, комутаторі або маршрутизатор) за принципом «вузла А дозволити доступ до вузла Б», але вже на 10-му пристрої ми зрозуміємо, що погарячкували (при описаному вище кількості пристроїв у мережі Cisco). Це не тільки займе час на прописування і перевірку списків контролю доступу, але і знизить продуктивність мережевих пристроїв, які будуть змушені перевіряти кожен прийшов кадр або пакет на відповідність ACL. А якщо згадати ще про мобільність наших співробітників, які можуть знаходитися в різних місцях корпоративної мережі або за її межами (і все це протягом одного дня), то завдання статичних правил не тільки неефективно, але й неможливо. В кінцевому підсумку всі правила перетворяться в класичне «всім дозволено все і всюди», яке явно не є прикладом того, до чого варто прагнути.

Тому ми стали вирішувати проблему по частинах і зверху вниз. Спочатку була визначена політика «по крупному», використовуючи всього два атрибута, — рівень довіри та можливості доступу. Вийшла високорівнева матриця, яка дозволила згрупувати всі вищезгадані типи пристроїв і користувачів всього у 4 великих блоку. Дана матриця дозволила нам визначитися з відповіддю на питання "кого/що пускати в нашу мережу".

Високорівнева матриця доступу

Однак обмежуватися банальним аутентифікацією користувачів або пристроїв ми не стали (хоча це вже немало). Все-таки при тому рівні мобільності співробітників Cisco, можлива ситуація, коли перебуваючи тиждень-іншу (а бувають і місячні відрядження) у відлученні від корпоративної мережі, співробітник може підхопити яку-небудь заразу на свій ноутбук або планшет. Тому крім аутентифікації треба було перевіряти ще й стан пристрою — наявність необхідних засобів захисту, антивірусу, актуальних антивірусних баз, патчів, а для смартфонів або планшетників ще і наявність джейлбрейка, включеного шифрування, встановленого PIN-коду певної довжини і т. д.

Частина політики доступу

Вибравши на першому етапі в якості атрибуту політики довіру, ми визначилися для себе, що, наприклад:

  • з'єднання з внутрішньої мережі є більш надійним, ніж з зовнішньої,
  • підключення через VPN більш надійно, ніж з Інтернет,
  • — доступ Wi-Fi повинен перевірятися не так, як дротове підключення,
  • гостьове мобільний пристрій менше доверенно мобільного пристрою співробітника,
  • і т. п.
Іншими словами, відповівши на питання «хто підключається і що», ми також включили в нашу політику мережевого доступу відповідь на питання "як здійснюється підключення до мережі Cisco?".

Частина політики доступу

Достатньо відповідей на ці три питання для захисту мережевого доступу? Для захисту можливо і так, але не для вирішення всіх питань, що стоять перед різними підрозділами Cisco. Адже крім служби ІБ контролю мережевого доступу зацікавлені і інші структури нашої компанії. Наприклад, ІТ, яке хотіло б знати про те, які типи пристроїв використовують співробітники найчастіше? Це дозволило б оптимізувати внутрішні програми для роботи з найбільш активно використовуваних. Служба безпеки хотіла б знати, ким і в який час здійснювалася та чи інша спроба доступу і, при необхідності, обмежувати її. Наприклад, гості не можуть перебувати у наших офісах поза робочого часу (тобто з 9.30 до 18.30 в Москві або з 8.00 до 17.00 в США). А значить і доступ до нашої гостьової бездротової мережі ним в «нічний» час не потрібен (на відміну від співробітників, які можуть працювати і вночі).

Частина політики доступу

Департамент розробки виставив вимоги по використанню географічних атрибутів як елемента політики доступу. Не секрет, що в Cisco розробка ЗА ведеться не в кожному офісі, а зосереджена всього в декількох точках земної кулі. Тому співробітникам офісу в австралійському Брісбені навряд чи потрібен доступ до серверів, розташованих в індійському Бангалорі, і зберігає вихідні коди нашого. Compliance-служба, яка стежить за дотриманням нормативних вимог, має свої вимоги до мережевого доступу. Наприклад, для виконання певних договорів потрібне залучення обмеженої кількості співробітників і тільки мають певне громадянство (так, і таке буває). Або, наприклад, для виконання вимог вітчизняного 242-го закону про локалізації баз даних персональних даних російських громадян.

Нарешті, кожний підрозділ має свій набір використовуваних у роботі даних, до яких повинні мати доступ тільки співробітники цього підрозділу і ніхто інший. Наприклад, відділ кадрів працює з персональними даними співробітників, бухгалтерія — з зарплатними відомостями, ІТ — з Active Directory, безпека — з відеоспостереженням, розробники — з системами контролю версій вихідних кодів і з системами їх динамічного або статичного аналізу. Тобто в політиці має бути враховано і роль суб'єкта доступу в оргштатної структури компанії.

Іншими словами політика мережевого доступу Cisco спирається не на один атрибут (хто/що), а враховує безліч факторів, які відповідають на наступні питання:

  • ХТО підключається?
  • підключається?
  • здійснюється зв'язок?
  • знаходиться підключаються пристрій або користувач?
  • ЗВІДКИ здійснюється доступ?
  • КОЛИ здійснюється доступу?
  • ЯКІ УМОВИ повинні бути дотримані для надання доступу?
Атрибути політики мережевого доступу

Відразу скажу, що ми не відразу реалізували таку політику. Було б лукавством стверджувати таке. Ми довго йшли до неї. Ключовим фактором успіху стало не стільки розуміння необхідності реалізувати гнучкі сценарії доступу, що залежать від комбінації різних атрибутів (а не тільки ХТО + КУДИ + КОЛИ), скільки можливість відповісти на кожне з перерахованих вище питань. Без цього політику мережевого доступу Cisco було б реалізувати неможливо. Тут довелося посидіти, щоб скласти списки ролей і мають ресурсів, зіставити їх з конкретними співробітниками, пов'язати ІТ-сервіси з HR-службою, та виконати ряд інших, так нелюбимих і часто званих «паперової безпекою» дій. Ну і, звичайно, гарною підмогою став вихід системи Cisco ISE (Identity Service Engine), яка і допомогла автоматизувати процес створення, впровадження і контролю політики мережевого доступу до мережевої інфраструктури Cisco. Без нього (ми пару років тому про нього на Хабре вже писали) всі наші благі наміри щодо динамічного та гнучкого доступу людей і пристроїв до наших ресурсів так і залишилися б гарною ідеєю, не вийшла за межі дошки, на якій це все було намальовано. ISE допоміг нам це все втілити в життя.

Приклад розширеної політики доступу

Зараз стало модно використовувати термін «agile». Так от можу сказати, що нам вдалося реалізувати мережевий доступ саме в стилі agile. Динамічне середовище з постійно мінливими умовами доступу — це і є мережа Cisco, в якій доступ повинен надаватися оперативно (і без купи папірців і заявок) і автоматично, без постійно залучення співробітників різних служб, що дають «добро» на доступ. Таке працює в мережі з одного комутатора, одного адміністратора і десяти співробітників. Коли число контрольованих суб'єктів і об'єктів доступу вимірюється сотнями тисяч, то тільки agile або іншими словами динамічний контроль мережевого доступу здатний допомогти вирішити поставлену задачу. І в Cisco нам це вдалося зробити.

ЗИ. Так, передбачаючи можливий питання про те, на якому обладнанні побудована мережа Cisco, відповідаю — на обладнанні Cisco (як це ні дивно :-) Проте зазначені принципи не залежать від того, що лежить в основі мережі, — вони універсальні. А ось рішення, що реалізує політику, засновані на цих принципах, вже є вендор-залежним. У випадку з Cisco ISE він працює з мережевим обладнанням Cisco, HP, Ruckus, Aruba, Motorola, Brocade. Не впевнений, але схема повинна працювати і на інших вендорах, наприклад, китайських, якщо вони підтримують той же 802.1 x і стандартні механізми управління (SSH, Telnet, SNMP).
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.