Як створити у великій компанії зручне робоче місце для розподілених команд?

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

Напрошується відповідь — зареєструватися в інтернет-сервісах для ведення спільної розробки (GitHub, Slack, Evernote, Wunderlist...). Але що робити, якщо твоя велика компанія працює, наприклад, з клієнтськими даними або фінансовою інформацією, і не може довірити її інтернет-сервісів? Єдиний вихід — розгорнути у себе всередині мережі інфраструктуру розподіленої розробки.

Але як це зробити, щоб забезпечити безпеку даних і процесів, при цьому не втратити в швидкості і зручності роботи? На це питання я і спробую відповісти в цій статті.



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

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

Ще з корпоративної мережі доступ в інтернет найчастіше обмежений або взагалі відключений. З міркувань безпеки і «турботу» про робочому часу співробітників. Обмеження може працювати через фільтрувальний проксі-сервер, або через віддалений робочий стіл якогось захищеного сервера, в якому відкрито браузер з доступом в інтернет.



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

Що в цьому випадку робити?

Трансформація мережевої інфраструктури
Далі наводяться декілька практичних кроків, як покращити інфраструктуру, для можливості більш ефективної комунікації та розподіленої роботи співробітників.

Мобілізація співробітників
Зараз смартфони, планшети, ноутбуки щільно увійшли в наше життя. Тому, найкращий варіант для початку трансформації — організувати співробітникові додаткове робоче місце на мобільному пристрої. Потрібно визначитися, яким внутрішнім сервісів все-таки можна дати доступ з Інтернет, оцінити ризики їх потенційного злому або недоступність. Наприклад, ось потенційні кандидати:
  • календар зустрічей,
  • бронювання переговорних кімнат,
  • список завдань,
  • список контактів,
  • робоча пошта.
Ясно, що таке мобільний місце ніколи не замінить стаціонарне в офісі. Але це вже хоч щось в напрямку розподіленої роботи.



Хоча це здається само собою зрозумілим, але в офісі для співробітників повинна бути Wi-Fi-мережу. Притому, не обов'язково з доступами в корпоративну мережу, але точно з повним доступом в інтернет. Наявність Wi-Fi в офісі дозволить працювати мобільних пристроїв, а також, цілком може вирішити проблему незручного доступу в Інтернет зі стаціонарних робочих місць. І користуватися інтернет-сервісами для розподіленої роботи стане більш реально.
Але що робити, якщо співробітник все ж хоче на свій мобільний пристрій щось більше, ніж календар зустрічей?

Зовнішній доступ в корпоративну мережу
Хочу ще раз повернутися до минулого пункту з точки зору інформаційної безпеки.
Якщо компанія відкриває в Інтернет будь-сервіс зі своєї корпоративної мережі, він відразу стає вразливим для наступних атак:
  • DDoS: працездатність сервісу можна порушити великою кількістю одночасних запитів з інтернет,
  • Автентифікація: якщо для доступу до сервісу співробітник використовує свій корпоративний логін і пароль, зловмисник може підібрати його і використовувати для доступу до інших більш небезпечним сервісів. Або, в найпростішому випадку, заблокувати обліковий запис, вичерпавши число невірних спроб вводу пароля. У разі, якщо імена облікових записів генеруються послідовно по нікому алгоритмом (login001, login002...), заблокувати можна не тільки жертву, а й всі підібрані логіни.
  • Злом сервісу: через різні уразливості, що тягне за собою захоплення інфраструктури атакованого сервісу, з можливістю продовження атак на інфраструктуру інших більш важливих внутрішніх сервісів.
Для скорочення кількості потенційних атакуючих, гарне рішення — виставляти сервіс в Інтернет через захищений канал з додатковим ступенем захисту.

Двофакторна аутентифікація

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



Захищений VPN тунель

На додаток до попереднього варіанту, для доступу до внутрішніх сервісів, зручно використовувати технологію VPN. Крім шифрування трафіку, технологія вводить додатковий фактор перевірки — під час створення VPN-з'єднання, ініціатору потрібен логін+пароль/сертифікат, без яких потенційна атака буде подавлена ще на мережевому обладнанні, не доходячи до інфраструктури сервісу.



Віддалений робочий стіл

Ще є варіант організації доступу в корпоративну мережу за принципом «віддалений робочий стіл». Тобто, доступ з Інтернет дається не до сервісу, а до робочого столу захищеного сервера, що має доступ до цього сервісу. Такий підхід менш зручний в роботі, т. к. по суті ми отримуємо два ізольованих робочих простору: віддалений робочий стіл (файли, закладки браузера, буфер обміну...) і локальний ноутбук. Є варіант повністю перейти на віддалений робочий стіл, але тоді віддалений сервер повинен бути досить потужний, стабільний, також як і канал зв'язку в Інтернет для роботи з ним.



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

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



Мережева сегментація

Тому, важливе завдання — вміти розмежовувати доступи до стратегічно важливих мережевих ресурсів, і до менш важливим, використовуваним командами в повсякденній роботі.

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

Тому, принцип сегментації — ресурси, до яких є доступ ззовні, повинні знаходитися в ізольованому мережевому сегменті.



Доступ між сегментами

Тут постає питання — що робити, якщо цих сервісів все ж потрібен доступ до деяких ресурсів корпоративної мережі? Наприклад, сервісу управління завданнями потрібен доступ до корпоративного поштового сервера для розсилки повідомлень про нові завдання. У цьому випадку, доступ відкривається, але строго на певні адреси і порти. Щоб, в разі захоплення сервісу керування завданнями, максимальний збиток — поштові SPAM-розсилки, або недоступність сервісу пошти через той же DDoS. Звичайно, це неприємні сценарії, але, принаймні, стратегічна інформація не потрапить назовні.

Керуючі порти

Щоб додатково захистити внутрішні сервіси від атак з потенційно захоплених зовнішніх сервісів, рекомендується не відкривати «керуючі» порти внутрішньої мережі. Тобто ті, через які можливо отримати повний доступ над сервером (SSH, Telnet, RDP, FTP...).

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

Доступ користувачів до сегментів

Наступне питання — скільки робити ізольованих сегментів для зовнішнього доступу? Найбезпечніший варіант — один сегмент на один сервіс. У цьому випадку, при захопленні цього сервісу, сусідні сервіси не постраждають, або постраждають мінімально. Але це несе додаткові накладні витрати на створення мережевих сегментів і відкриття доступів між ними.

Тому, найбільш зважений варіант — об'єднувати в загальний сегмент аналогічні сервіси. Наприклад, систему управління завданнями, вихідними кодами і бібліотеку знань. Всім їм потрібні однакові доступи до інших сервісів: поштовий сервер, сервер аутентифікації користувачів, сервер БД.

Як наслідок, крім поміщення їх у загальний мережевий сегмент, логічним виглядає відкриття доступу до зовнішніх сервісів не точково (від кожного окремого сервісу), а масово (від цілого мережевого сегменту). Це заощадить час на відкриття мережевих доступів у разі збільшення кількості сервісів в цьому сегменті.



Після готовності потрібної кількості мережевих сегментів і сервісів в них, доцільно розмежувати доступ ззовні до різних мережних сегментів. Іншими словами, пускати користувача тільки до тих сегментів, сервіси яких йому дійсно потрібні для роботи.

Знеособлення даних

Якщо команді все ж потрібен доступ до інфраструктури своїх продуктів для їх розвитку?
Звичайно, розробка продуктів ведеться на тестових полігонах, найнебезпечніше в яких — користувацькі дані/фінансова інформація. Як не дивно, самі дані не потрібні для розробки, зазвичай цілком підходить їх знеособлена копія! Існує величезна кількість методів знеособлення, найпростіші з яких — замінити прізвища, номери телефонів та іншу інформацію щодо клієнтів на аналогічні за структурою і нічого не значущі набори символів.



Що далі?
Припустимо, що ви виконали ці непрості кроки у своїй великій організації: винесли сервіси в ізольовані сегменти, відкрили мережеві доступи, обезличили дані. Що далі?
На жаль, працівники можуть бути дуже консервативні і не бажати переїжджати на нову інфраструктуру. Навіть не з-за того, що вона краще або гірше, просто вона нова, а вони звикли до старої. І перехід для них — додаткові витрати по проекту, а переваги — потенційна можливість роботи поза офісом, яка може бути не всім цікава.

Або, навіть команда перейшла на нову інфраструктуру, почала її обживати, але стара нікуди не ділася. І завжди залишається спокуса повернутися на стаціонарне робоче місце з ноутбука і зробити що-небудь по-старому.

Штучна ізоляція команди

Потрібно вивести команду з офісу, можна навіть не в інше місто, а в коворкінг/антикафе/інший офіс. Але з двома обов'язковими умовами — в новому місці не повинно бути корпоративної локальної мережі. І новий офіс не повинен бути в крокової доступності від старого. Обидва умови зовсім виключають можливість повернення до старої інфраструктури. І, якщо нова інфраструктура досить добре підготовлена команда повернеться у старе офіс повністю незалежною від старого, ще як бонус — додатково згуртованою.



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

Якщо вам є що додати з свого досвіду, будь-ласка, пишіть в коментарях!
Джерело: Хабрахабр

0 коментарів

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