Последнее время многие крупные компании пытаются внедрить у себя практики DevOps, чтобы ускорить процесс доставки ценности до клиента. Работающие над продуктом люди собираются в одну команду, работают в едином информационном поле. Что же делать большой компании, если сотрудники её команд не могут собраться в одной комнате, а разбросаны по разным офисам, возможно, даже в разных городах и часовых поясах?
Напрашивается ответ — зарегистрироваться в интернет-сервисах для ведения совместной разработки (GitHub, Slack, Evernote, Wunderlist...). Но что делать, если в твоя большая компания работает, например, с клиентскими данными или финансовой информацией, и не может доверить её интернет-сервисам? Единственный выход — развернуть у себя внутри сети инфраструктуру распределённой разработки.
Но как это сделать, чтобы обеспечить безопасность данных и процессов, при этом не потерять в скорости и удобстве работы? На этот вопрос я и постараюсь ответить в данной статье.
Сразу хочу оговориться, что в статье будет упор не на сетевые технологии или информационную безопасность — для этого есть много профессиональной литературы. А скорее речь пойдёт о принципах применения этих технологий для максимального удобства работы пользователей при допустимом уровне угроз безопасности.
Типичная инфраструктура крупной компании
В начале я опишу, как обычно выглядит сетевая инфраструктура у типовых крупных компаний.
У них есть головной офис, в котором находится руководство, ключевые сотрудники и дата-центр с ценной информацией. Все рабочие места подключены к корпоративной сети головного офиса, к ней же подключён и сервера дата-центра. Подсети филиалов в других городах подключаются с сети головного офиса по физическому/чаще виртуальному каналу.
Ещё из корпоративной сети доступ в интернет чаще всего ограничен или вообще отключён. Из соображений безопасности и «заботе» о рабочем времени сотрудников. Ограничение может работать через фильтрующий прокси-сервер, или через удалённый рабочий стол некого защищённого сервера, в котором открыт браузер с доступом в интернет.
Итого, в типичной крупной компании, если сотрудник вышел из офиса/заболел/уехал в отпуск, обычно, у него нет возможности подключиться к корпоративной сети. А, с учётом ограничения доступа в Интернет, также у него пропадает возможность эффективно использовать интернет-сервисы. Из средств коммуникации остаётся лишь мобильный телефон.
Что в этом случае делать?
Трансформация сетевой инфраструктуры
Далее приводятся несколько практических шагов, как улучить инфраструктуру, для возможности более эффективной коммуникации и распределённой работы сотрудников.
Мобилизация сотрудников
Сейчас смартфоны, планшеты, ноутбуки плотно вошли в нашу жизнь. Поэтому, лучший вариант для начала трансформации — организовать сотруднику дополнительное рабочее место на мобильном устройстве. Нужно определиться, к каким внутренним сервисам всё-таки можно дать доступ из Интернет, оценить риски их потенциального взлома или недоступности. Например, вот потенциальные кандидаты:
- календарь встреч,
- бронирование переговорных комнат,
- список задач,
- список контактов,
- рабочая почта.
Ясно, что такое мобильное место никогда не заменит стационарное в офисе. Но это уже хоть что-то в направлении распределённой работы.
Хотя это кажется само собой разумеющимся, но в офисе для сотрудников должна быть Wi-Fi-сеть. Притом, не обязательно с доступами в корпоративную сеть, но точно с полным доступом в интернет. Наличие Wi-Fi в офисе позволит работать мобильным устройствам, а также, вполне может решить проблему неудобного доступа в Интернет со стационарных рабочих мест. И пользоваться интернет-сервисами для распределённой работы станет более реально.
Но что делать, если сотрудник всё же хочет на своё мобильное устройство нечто большее, чем календарь встреч?
Внешний доступ в корпоративную сеть
Хочу ещё раз вернуться к прошлому пункту с точки зрения информационной безопасности.
Если компания открывает в Интернет любой сервис из своей корпоративной сети, он сразу становится уязвим для следующих атак:
- DDoS: работоспособность сервиса можно нарушить большим количеством одновременных запросов из интернет,
- Аутентификация: если для доступа к сервису сотрудник использует свой корпоративный логин и пароль, злоумышленник может подобрать его и использовать для доступа к другим более опасным сервисам. Или, в самом простом случае, заблокировать учётную запись, исчерпав число неверных попыток ввода пароля. В случае, если имена учётных записей генерируются последовательно по некому алгоритму (login001, login002...), заблокировать можно не только жертву, но и все подобранные логины.
- Взлом сервиса: через различные уязвимости, что влечёт за собой захват инфраструктуры атакованного сервиса, с возможностью продолжения атак на инфраструктуру других более важных внутренних сервисов.
Для сокращения количества потенциальных атакующих, хорошее решение — выставлять сервис в Интернет через защищённый канал с дополнительной степенью защиты.
Двухфакторная аутентификация
Например, хорошо подойдёт подтверждение входа в систему по разовому SMS-паролю, или ключу из физического/программного токена. В этом случае, для организации атак, злоумышленнику нужно завладеть мобильным телефоном или токеном жертвы, пока она не успеет сообщить о пропаже в службу безопасности компании.
Защищённый VPN-туннель
В дополнение к предыдущему варианту, для доступа ко внутренним сервисам, удобно использовать технологию VPN. Кроме шифрования трафика, технология вводит дополнительный фактор проверки — при создании VPN-соединения, инициатору нужен логин+пароль/сертификат, без которых потенциальная атака будет подавлена ещё на сетевом оборудовании, не доходя до инфраструктуры сервиса.
Удалённый рабочий стол
Ещё есть вариант организации доступа в корпоративную сеть по принципу «удалённый рабочий стол». То есть, доступ из Интернет даётся не до сервиса, а до рабочего стола защищённого сервера, имеющего доступ к этому сервису. Такой подход менее удобен в работе, т.к. по сути мы получаем два изолированных рабочих пространства: удалённый рабочий стол (файлы, закладки браузера, буфер обмена...) и локальный ноутбук. Есть вариант полностью перейти на удалённый рабочий стол, но тогда удалённый сервер должен быть достаточно мощный, стабильный, также как и канал связи в Интернет для работы с ним.
Архитектура корпоративной сети
Тогда возникает вопрос — почему бы не открыть всю корпоративную сеть через VPN или удалённый рабочий стол? И почему бы не дать всем сотрудникам ноутбуки для работы из любой точки мира?
Всё-таки потенциальная утечка стратегической информации — слишком большой риск для крупной компании. Особенно, если сотрудник находится с рабочим ноутбуком где-нибудь за границей. Или всё-таки произошла компрометация средств аутентификации сотрудника.
Кроме того, часто для разработки новых продуктов по практикам DevOps всем участникам команды совсем не обязателен полный доступ ко всей сети. Достаточно иметь доступ к тестовому полигону и примыкающей инфраструктуре.
Сетевая сегментация
Поэтому, важная задача — уметь разграничивать доступы к стратегически важным сетевым ресурсам, и к менее важным, используемым командами в повседневной работе.
Основной принцип разграничения — сетевая сегментация, то есть, ограничивать на сетевом уровне доступы к определённым сервисам. В крупных компаниях часто пренебрегают этим принципом, так как проще растить всю сетевую инфраструктуру в едином сетевом пространстве, не тратить время на открытие сетевых доступов между различным частями инфраструктуры. В этом случае, захват одного сервера извне ставит под риск все оставшиеся ресурсы.
Поэтому, принцип сегментации — ресурсы, к которым есть доступ извне, должны находиться в изолированном сетевом сегменте.
Доступ между сегментами
Тут появляется вопрос — что делать, если этим сервисам всё же нужен доступ к некоторым ресурсам корпоративной сети? Например, сервису управления задачами нужен доступ к корпоративному почтовому серверу для рассылки уведомлений о новых задачах. В этом случае, доступ открывается, но строго на определённые адреса и порты. Чтобы, в случае захвата сервиса управления задачами, максимальный ущерб — почтовые SPAM-рассылки, или недоступность сервиса почты через тот же DDoS. Конечно, это неприятные сценарии, но, по крайней мере, стратегическая информация не попадёт наружу.
Управляющие порты
Чтобы дополнительно защитить внутренние сервисы от атак с потенциально захваченных внешних сервисов, рекомендуется не открывать «управляющие» порты внутренней сети. То есть те, через которые возможно получить полный доступ над сервером (SSH, Telnet, RDP, FTP...).
Самый идеальный вариант — вообще не открывать доступы во внутреннюю сеть. А, вместо этого, открывать только обратные доступы — из внутренней сети во внешнюю. Например, для отправки письма, не отправляющая система делает запрос в почтовую систему, а наоборот, почтовая система обращается к отправляющей для разбора очереди накопившихся писем.
Доступ пользователей к сегментам
Следующий вопрос — сколько делать изолированных сегментов для внешнего доступа? Самый безопасный вариант — один сегмент на один сервис. В этом случае, при захвате этого сервиса, соседние сервисы не пострадают, или пострадают минимально. Но это несёт дополнительные накладные расходы на создание сетевых сегментов и открытие доступов между ними.
Поэтому, самый взвешенный вариант — объединять в общий сегмент аналогичные сервисы. Например, систему управления задачами, исходными кодами и библиотеку знаний. Всем им нужны одинаковые доступы к другим сервисам: почтовый сервер, сервер аутентификации пользователей, сервер БД.
Как следствие, кроме помещения их в общий сетевой сегмент, логичным выглядит открытие доступа к внешним сервисам не точечно (от каждого отдельного сервиса), а массово (от целого сетевого сегмента). Это сэкономит время на открытие сетевых доступов в случае увеличения количества сервисов в этом сегменте.
После готовности нужного количества сетевых сегментов и сервисов в них, целесообразно разграничить доступ извне к разным сетевым сегментам. Другими словами, пускать пользователя только к тем сегментам, сервисы которых ему действительно нужны для работы.
Обезличивание данных
Если команде всё же нужен доступ к инфраструктуре своих продуктов для их развития?
Обычно, разработка продуктов ведётся на тестовых полигонах, самое опасное в которых — пользовательские данные/финансовая информация. Как ни странно, сами данные не нужны для разработки, обычно вполне подходит их обезличенная копия! Существует огромное количество методов обезличивания, самые простые из которых — заменить фамилии, номера телефонов и другую информацию по клиентам на аналогичные по структуре и ничего не значащие наборы символов.
Что дальше?
Предположим, что вы проделали эти непростые шаги в своей крупной организации: вынесли сервисы в изолированные сегменты, открыли сетевые доступы, обезличили данные. Что дальше?
К сожалению, сотрудники могут быть весьма консервативны и не желать переезжать на новую инфраструктуру. Даже не из-за того, что она лучше или хуже, просто она новая, а они привыкли к старой. И переход для них — дополнительные затраты по проекту, а преимущества — потенциальная возможность работы вне офиса, которая может быть не всем интересна :)
Или, даже команда перешла на новую инфраструктуру, начала её обживать, но старая-то никуда не делась. И всегда остаётся соблазн вернуться на стационарное рабочее место с ноутбука и сделать что-нибудь по-старому.
Искусственная изоляция команды
Нужно вывести команду из офиса, можно даже не в другой город, а в коворкинг/антикафе/другой офис. Но с двумя обязательными условиями — в новом месте не должно быть корпоративной локальной сети. И новый офис не должен быть в шаговой доступности от старого. Оба условия напрочь исключают возможность возврата к старой инфраструктуре. И, если новая инфраструктура достаточно хорошо подготовлена, команда вернётся в старый офис полностью независимой от старого, ещё как бонус — дополнительно сплочённой.
Итого
Подводя итог статьи, могу точно сказать из своего опыта — даже самые большие и хранящие свои секреты компании вполне могут создать своим сотрудникам условия для распределённой разработки. Нужно лишь реализовать несложные, разумные технические и организационные принципы, про некоторые из которых я рассказал выше.
Если вам есть что добавить из своего опыта, пожалуйста, пишите в комментариях!
Автор: glar
