Как создать в большой компании удобное рабочее место для распределённых команд?

    Последнее время многие крупные компании пытаются внедрить у себя практики DevOps, чтобы ускорить процесс доставки ценности до клиента. Работающие над продуктом люди собираются в одну команду, работают в едином информационном поле. Что же делать большой компании, если сотрудники её команд не могут собраться в одной комнате, а разбросаны по разным офисам, возможно, даже в разных городах и часовых поясах?

    Напрашивается ответ — зарегистрироваться в интернет-сервисах для ведения совместной разработки (GitHub, Slack, Evernote, Wunderlist...). Но что делать, если в твоя большая компания работает, например, с клиентскими данными или финансовой информацией, и не может доверить её интернет-сервисам? Единственный выход — развернуть у себя внутри сети инфраструктуру распределённой разработки.

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



    Сразу хочу оговориться, что в статье будет упор не на сетевые технологии или информационную безопасность — для этого есть много профессиональной литературы. А скорее речь пойдёт о принципах применения этих технологий для максимального удобства работы пользователей при допустимом уровне угроз безопасности.

    Типичная инфраструктура крупной компании


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

    Ещё из корпоративной сети доступ в интернет чаще всего ограничен или вообще отключён. Из соображений безопасности и «заботе» о рабочем времени сотрудников. Ограничение может работать через фильтрующий прокси-сервер, или через удалённый рабочий стол некого защищённого сервера, в котором открыт браузер с доступом в интернет.



    Итого, в типичной крупной компании, если сотрудник вышел из офиса/заболел/уехал в отпуск, обычно, у него нет возможности подключиться к корпоративной сети. А, с учётом ограничения доступа в Интернет, также у него пропадает возможность эффективно использовать интернет-сервисы. Из средств коммуникации остаётся лишь мобильный телефон.

    Что в этом случае делать?

    Трансформация сетевой инфраструктуры


    Далее приводятся несколько практических шагов, как улучить инфраструктуру, для возможности более эффективной коммуникации и распределённой работы сотрудников.

    Мобилизация сотрудников


    Сейчас смартфоны, планшеты, ноутбуки плотно вошли в нашу жизнь. Поэтому, лучший вариант для начала трансформации — организовать сотруднику дополнительное рабочее место на мобильном устройстве. Нужно определиться, к каким внутренним сервисам всё-таки можно дать доступ из Интернет, оценить риски их потенциального взлома или недоступности. Например, вот потенциальные кандидаты:

    • календарь встреч,
    • бронирование переговорных комнат,
    • список задач,
    • список контактов,
    • рабочая почта.

    Ясно, что такое мобильное место никогда не заменит стационарное в офисе. Но это уже хоть что-то в направлении распределённой работы.



    Хотя это кажется само собой разумеющимся, но в офисе для сотрудников должна быть Wi-Fi-сеть. Притом, не обязательно с доступами в корпоративную сеть, но точно с полным доступом в интернет. Наличие Wi-Fi в офисе позволит работать мобильным устройствам, а также, вполне может решить проблему неудобного доступа в Интернет со стационарных рабочих мест. И пользоваться интернет-сервисами для распределённой работы станет более реально.
    Но что делать, если сотрудник всё же хочет на своё мобильное устройство нечто большее, чем календарь встреч?

    Внешний доступ в корпоративную сеть


    Хочу ещё раз вернуться к прошлому пункту с точки зрения информационной безопасности.
    Если компания открывает в Интернет любой сервис из своей корпоративной сети, он сразу становится уязвим для следующих атак:

    • DDoS: работоспособность сервиса можно нарушить большим количеством одновременных запросов из интернет.

    • Аутентификация: если для доступа к сервису сотрудник использует свой корпоративный логин и пароль, злоумышленник может подобрать его и использовать для доступа к другим более опасным сервисам. Или, в самом простом случае, заблокировать учётную запись, исчерпав число неверных попыток ввода пароля. В случае, если имена учётных записей генерируются последовательно по некому алгоритму (login001, login002...), заблокировать можно не только жертву, но и все подобранные логины.

    • Взлом сервиса: через различные уязвимости, что влечёт за собой захват инфраструктуры атакованного сервиса, с возможностью продолжения атак на инфраструктуру других более важных внутренних сервисов.

    Для сокращения количества потенциальных атакующих, хорошее решение — выставлять сервис в Интернет через защищённый канал с дополнительной степенью защиты.

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


    Например, хорошо подойдёт подтверждение входа в систему по разовому SMS-паролю, или ключу из физического/программного токена. В этом случае, для организации атак, злоумышленнику нужно завладеть мобильным телефоном или токеном жертвы, пока она не успеет сообщить о пропаже в службу безопасности компании.



    Защищённый VPN-туннель


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



    Удалённый рабочий стол


    Ещё есть вариант организации доступа в корпоративную сеть по принципу «удалённый рабочий стол». То есть, доступ из Интернет даётся не до сервиса, а до рабочего стола защищённого сервера, имеющего доступ к этому сервису. Такой подход менее удобен в работе, т.к. по сути мы получаем два изолированных рабочих пространства: удалённый рабочий стол (файлы, закладки браузера, буфер обмена...) и локальный ноутбук. Есть вариант полностью перейти на удалённый рабочий стол, но тогда удалённый сервер должен быть достаточно мощный, стабильный, также как и канал связи в Интернет для работы с ним.



    Архитектура корпоративной сети


    Тогда возникает вопрос — почему бы не открыть всю корпоративную сеть через VPN или удалённый рабочий стол? И почему бы не дать всем сотрудникам ноутбуки для работы из любой точки мира?
    Всё-таки потенциальная утечка стратегической информации — слишком большой риск для крупной компании. Особенно, если сотрудник находится с рабочим ноутбуком где-нибудь за границей. Или всё-таки произошла компрометация средств аутентификации сотрудника.

    Кроме того, часто для разработки новых продуктов по практикам DevOps всем участникам команды совсем не обязателен полный доступ ко всей сети. Достаточно иметь доступ к тестовому полигону и примыкающей инфраструктуре.



    Сетевая сегментация


    Поэтому, важная задача — уметь разграничивать доступы к стратегически важным сетевым ресурсам, и к менее важным, используемым командами в повседневной работе.

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

    Поэтому, принцип сегментации — ресурсы, к которым есть доступ извне, должны находиться в изолированном сетевом сегменте.



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


    Тут появляется вопрос — что делать, если этим сервисам всё же нужен доступ к некоторым ресурсам корпоративной сети? Например, сервису управления задачами нужен доступ к корпоративному почтовому серверу для рассылки уведомлений о новых задачах. В этом случае, доступ открывается, но строго на определённые адреса и порты. Чтобы, в случае захвата сервиса управления задачами, максимальный ущерб — почтовые SPAM-рассылки, или недоступность сервиса почты через тот же DDoS. Конечно, это неприятные сценарии, но, по крайней мере, стратегическая информация не попадёт наружу.

    Управляющие порты


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

    Самый идеальный вариант — вообще не открывать доступы во внутреннюю сеть. А, вместо этого, открывать только обратные доступы — из внутренней сети во внешнюю. Например, для отправки письма, не отправляющая система делает запрос в почтовую систему, а наоборот, почтовая система обращается к отправляющей для разбора очереди накопившихся писем.

    Доступ пользователей к сегментам


    Следующий вопрос — сколько делать изолированных сегментов для внешнего доступа? Самый безопасный вариант — один сегмент на один сервис. В этом случае, при захвате этого сервиса, соседние сервисы не пострадают, или пострадают минимально. Но это несёт дополнительные накладные расходы на создание сетевых сегментов и открытие доступов между ними.

    Поэтому, самый взвешенный вариант — объединять в общий сегмент аналогичные сервисы. Например, систему управления задачами, исходными кодами и библиотеку знаний. Всем им нужны одинаковые доступы к другим сервисам: почтовый сервер, сервер аутентификации пользователей, сервер БД.

    Как следствие, кроме помещения их в общий сетевой сегмент, логичным выглядит открытие доступа к внешним сервисам не точечно (от каждого отдельного сервиса), а массово (от целого сетевого сегмента). Это сэкономит время на открытие сетевых доступов в случае увеличения количества сервисов в этом сегменте.



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

    Обезличивание данных


    Если команде всё же нужен доступ к инфраструктуре своих продуктов для их развития?
    Обычно, разработка продуктов ведётся на тестовых полигонах, самое опасное в которых — пользовательские данные/финансовая информация. Как ни странно, сами данные не нужны для разработки, обычно вполне подходит их обезличенная копия! Существует огромное количество методов обезличивания, самые простые из которых — заменить фамилии, номера телефонов и другую информацию по клиентам на аналогичные по структуре и ничего не значащие наборы символов.



    Что дальше?


    Предположим, что вы проделали эти непростые шаги в своей крупной организации: вынесли сервисы в изолированные сегменты, открыли сетевые доступы, обезличили данные. Что дальше?

    К сожалению, сотрудники могут быть весьма консервативны и не желать переезжать на новую инфраструктуру. Даже не из-за того, что она лучше или хуже, просто она новая, а они привыкли к старой. И переход для них — дополнительные затраты по проекту, а преимущества — потенциальная возможность работы вне офиса, которая может быть не всем интересна.

    Или, даже команда перешла на новую инфраструктуру, начала её обживать, но старая-то никуда не делась. И всегда остаётся соблазн вернуться на стационарное рабочее место с ноутбука и сделать что-нибудь по-старому.

    Искусственная изоляция команды


    Нужно вывести команду из офиса, можно даже не в другой город, а в коворкинг/антикафе/другой офис. Но с двумя обязательными условиями — в новом месте не должно быть корпоративной локальной сети. И новый офис не должен быть в шаговой доступности от старого. Оба условия напрочь исключают возможность возврата к старой инфраструктуре. И, если новая инфраструктура достаточно хорошо подготовлена, команда вернётся в старый офис полностью независимой от старого, ещё как бонус — дополнительно сплочённой.



    Итого


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

    Если вам есть что добавить из своего опыта, пожалуйста, пишите в комментариях!
    • +9
    • 12.3k
    • 8
    Share post

    Comments 8

      0
      Аутентификация: если для доступа к сервису сотрудник использует свой корпоративный логин и пароль, злоумышленник может подобрать его и использовать для доступа к другим более опасным сервисам. Или, в самом простом случае, заблокировать учётную запись, исчерпав число неверных попыток ввода пароля.В случае, если имена учётных записей генерируются последовательно по некому алгоритму (login001, login002...), заблокировать можно не только жертву, но и все подобранные логины.

      Обычно это решается RADIUS аутентификацией вместо AD аутентификации, хотя логин и пароль используются те же. Перебор логинов и паролей заблокирует на какое-то настраиваемое время вход логина через сервис, но не логин/аккаунт в-целом.
        0
        Если честно, то я больше верю в безопасность своих приватных репозиторев на github и учётке в Google нежели местной инфраструктуре поднятой админами, которые не смогли устроиться в Google. Это просто субъективное впечатление. Я не прав?
          0
          Да, я тоже больше верю в безопасность Google. Если для большой компании администрирование сервисов не является источником дохода (а это скорее всего так), то логичным выглядит передача этой функции на аутсорс. Особенно, такой удобный, как Google, GitHub или Slack.
          Но часто в дело вмешивается служба безопасности и наше законодательство, боящиеся хранить «стратегическую» информацию у «вражеских» компаний. Особенно, если их дата-центры находятся за пределами России. Поэтому, вариантов не остаётся, к сожалению.
            0

            Как тот самый местный, не способный устроиться в Google, админ, отвечу, что вы вообще не о том думаете. Проблема хранения информации в гугле состоит не в потенциальной компроментации, а в том, что последний в любой момент может вас забанить по какому-либо поводу. А у вас с ним даже бумажного договора нет. Это главная проблема. Забанить могут, например, по доносу конкурентов. И примеры такие были. Даже статья была на хабре.


            Технически же, любой адекватный админ будет за Google Apps, поскольку это существенное упрощение работы.

              0
              А могли бы поделиться ссылкой кого забанил Google по доносу конкурентов? Спасибо.
                0
                Любой информация которая находится на сторонних сервисах, это не ваша информация и с ней могут делать что хотят и как хотят, Яблочная компания считает, что все у вас в аренде и покупки это не покупки а аренда.
                В любой момент вы можете получить письмо, в лучшем случае, с заголовком I'm sorry, but… или просто недоступный сервер, с сообщением что вам была выслана абуза и вы на нее не прореагировали… Но в основном, получаете пустой сервер (переписку, отсутствующий аккаунт)
                В лицензионных соглашениях сказано, что ни кто не за что не отвечает и не обещает. Поэтому и приходиться поднимать свою инфраструктуру, что бы как то контролировать информацию.
            0
            qwertyRu Хотелось бы узнать в таком случае как вы трактуете соглашение об использовании сервисов Google
            https://gsuite.google.com/intl/ru/terms/2013/1/premier_terms.html

            7. Права на объекты интеллектуальной собственности; торговые марки

            7.1. Права на объекты интеллектуальной собственности. За исключением явно перечисленных здесь случаев, настоящее Соглашение не предоставляет ни одной из сторон никаких подразумеваемых или иных прав на контент другой стороны или на ее интеллектуальную собственность. По соглашению сторон Клиенту принадлежат все Права на объекты интеллектуальной собственности в отношении его данных, а компании Google принадлежат Права на объекты интеллектуальной собственности в отношении Служб.
              0
              PACBET
              Это про право на интеллектуальную собственность. Общая фраза, что ваше это ваше (ради интереса, вы можете доказать что данные это действительно ваши данные?), а наше это наше. Но если поступает жалоба что чьи-то авторские права, по его мнению нарушены, то сервису проще временно ограничить доступ, а клиенты пусть сами разбираются, кто и что друг-другу должен.
              + соглашение может меняться в любой момент в любую сторону.

              Only users with full accounts can post comments. Log in, please.