Что мы прячем под VPN-контуром?
В этом году на российские компании обрушилась волна кибератак: эксперты говорят о минимум трехкратном росте. За последние два года в 40 раз увеличилось число утечек персональных данных. В 2021 году их было зарегистрировано всего четыре, в 2022-м — более 140, а в 2023-м — более 150. Характерно это не только для России, но и для мира в целом. Так, BlackBerry Cybersecurity отмечает, что в мире число хакерских атак на госучреждения увеличилось на 40%. На мой взгляд, в нынешней непростой ситуации защищенный контур VPN — один из удобных инструментов для повышения безопасности проектов. Конечно, при правильной настройке и эксплуатации.
Итак, VPN-контуром у нас накрыты Jira, Confluence, наш внутренний Atlassian-стек, где мы ведем документацию и ставим задачи для разных проектов. Там же находятся тестовые контуры разных систем — в том числе системы заказчиков: они хранятся исключительно в нашем внутреннем контуре.
Кроме того, мы закрываем админки ботов, дашборды со статистикой, логами, мониторингом.
Все это нужно «огораживать» VPN-контуром, чтобы ничего «не торчало наружу». Каждая система имеет свою базу данных, а зачастую еще и какой-то «приклад» — порты, соединения, например. И у всего — собственные настройки. Если админить такое множество элементов, то можно сойти с ума. Когда системы не находятся под VPN-контуром, то таких «выходов наружу», которые нужно постоянно администрировать, становится так много, что уследить за ними просто нереально.
Представьте себе, что нужно по этим сущностям пройтись — посмотреть, где открыт либо закрыт тот или иной порт и нет ли там лишних лазеек. Чтобы в этих реалиях существовать, требуется много времени девопсов и сисадминов.
Но достаточно спрятать инфраструктуру за VPN и становится легче, потому что одно правило сразу снимает много вопросов по настройке каждого «приклада». Системы под общим контуром можно администрировать по единому принципу. Очень много проблем безопасности тут же отпадает: загнанные под VPN порты оказываются автоматически защищены, а у вас становится на одну головную боль меньше.
Почему вам НЕ нужен контур VPN
Защищенный контур у нас появился только через два года после открытия компании. Я уверен, что на старте бизнеса VPN будет «оверхед». Вам надо решить другие технические вопросы, и нет смысла ставить во главу угла задачу — накрыть инфраструктуру подобным куполом.
Совет новичкам: если вы еще не доросли до того, чтобы тратить административный ресурс и деньги на обслуживание VPN-контура, то… и забудьте о нем. Понятное дело, что у вас будут мысли: а вдруг что-то случится и кто-то вас хакнет. Но на слишком раннем этапе такой уровень защиты вовсе не требуется, а, начав огораживать систему контуром, вы просто преумножите хаос.
Главное условие внедрения VPN-контура — безопасность, которая уже стала настоящей болью. Для нас такой критической точкой оказался переход на Jira. До этого мы работали в Trello и Bitrix, в которых вели рабочие задачи по проектам и создавали борды. Но скоро число проектов кардинально увеличилось, начали приходить крупные заказчики, и нам пришлось пересесть на Jira.
На тот момент в Битриксе не было канбана. Если бы мы не столкнулись с таким ограничением, возможно, мы бы так и не переехали. Хотя там до сих пор нет базы знаний, чтобы можно было обойтись без Confluence.
Мы развернули Jira не в облаке, а на собственном сервере, Кстати, в 2023 году Atlassian закрыла аккаунты российских компаний, то есть мы не прогадали, что отказались от облачного решения. Мы были вынуждены размещать сторонние продукты on-premise, что тут же увеличивало трудоемкость поддержки этой «кухни». Как организовывать уровни доступа к ресурсам? А что, если сторонний продукт взломают? Тогда злоумышленник получит доступ ко всем клиентским проектам. Это недопустимо!
Отмечу, что сейчас российским компаниям больше не нужно внедрять у себя кастомную Jira. В связи с известными событиями рекомендую для начала обратить внимание на отечественные облачные продукты. Они сейчас очень достойно выглядят. Чтобы никого не рекламировать, не буду называть конкретные бренды.
Хождение по мукам и лайфхаки, как этого избежать
Поначалу мы долго подбирали корректные настройки VPN-контура — иногда бывало так, что у всех в компании есть доступ внутрь контура, а у одного сотрудника почему-то никак не получается зайти.
Особенно трудно было с настройками выдачи сертификатов для новых сотрудников. Проблема заключалась в том, что у нас было много приходящих сотрудников и приходилось часто генерировать и отзывать сертификаты.
Сделали так, что корневой, выпускающий сертификат лежит отдельно от той машины, где находятся остальные сертификаты (в том числе и блокировочный) и происходит их генерация. Таким образом, если вдруг случится утечка, то главный выпускающий сертификат не пострадает — мы все равно сможем управлять контуром VPN. Это считается best practice.
Другой лайфхак связан с необходимостью следить за сроком годности выпускающего сертификата. Если его не обновлять, то выпущенные сертификаты могут просто перестать работать и начнутся проблемы с совместимостью более поздних версий операционных систем.
Когда вы меняете корневой сертификат, надо менять и все остальные, что только повышает уровень безопасности ваших проектов. Таким действием вы разом отзовете доступы у всех уволенных сотрудников и выдадите их новым. Подобные операции рекомендую проводить периодически, например раз в год или при выходе обновления безопасности.
Большой плюс VPN-контура
Недавно в Телеграм у нас взломали одного сотрудника. Мы так и не поняли, как это произошло, потому что он был максимально защищен, насколько это возможно для Телеграма. В какой-то момент от сотрудника пришло сообщение «займи 10 тысяч» одному из коллег, и мы забили тревогу. Под угрозой оказался большой кусок инфраструктуры. Казалось бы, надо сбрасывать инфраструктуру — пароли, ключи, ставить новые заглушки. Но если есть защищенный VPN-контур, то достаточно просто отозвать сертификат скомпрометированного сотрудника. После этого никакой, даже самый опытный злоумышленник ничего не сделает, потому что не сможет никуда зайти. Вам нужно сделать лишь одно действие!
Добавлю, что программистам лучше вообще не давать доступа к продакшену. Это часть нашей политики безопасности.
Кстати, VPN-контур позволяет забыть о хакерах, которые запускают продакшен и в окне с вводом логина и пароля начинают перебирать варианты в поисках правильных. В этом случае контур сработает лучше, чем защита с помощью капчи или ограничения количества запросов на сервер. В VPN-контуре просто нет окна, где можно перебирать пароли.
А есть ли минусы VPN-контура?
Во-первых, каждому новому сотруднику, которого вы берете на тестовый период — и даже стажеру на месяц — придется выдавать сертификат, а потом его гасить, чтобы он не получил доступа к системе после ухода. Вы не можете выдать пароль для доступа только к одной части инфраструктуры — новичку вы открываете всю систему. Конечно, в определенных стеках (например, Microsoft) можно создать карантинные зоны, но в других комбинациях инфраструктуры VPN — наиболее адекватный вариант. Особенно когда есть и клиентские приложения, и свои.
Во-вторых, если падает сервер с VPN, вся инфраструктура тоже оказывается офлайн. Правда, пока такого с нами ни разу не случалось.
В-третьих, когда у заказчика уже есть свой VPN, то переключаться между ним и вашим для него — дополнительные усилия.
В-четвертых, если текущее интернет-соединение у сотрудника нестабильно — допустим, он с ноутбуком находитесь в дороге, — то подключаться еще и к VPN будет гораздо сложнее.
Как организовать защищенный контур
При создании VPN-контура мы завели отдельный VPS-сервер, где подняли софт с огромным количеством прописанных правил. Речь идет о XCA, которое представляет собой кросс-платформенное графическое (GUI) приложение, с функциональностью Удостоверяющего центра. Сам контур реализован на базе OpenVPN — технологии виртуальной частной сети с открытым исходным кодом.
Чтобы добиться стабильного соединения, нужно было найти подходящие DNS-настройки. Мы перебрали разные и в итоге остановились на российских DNS от Яндекса. Данные вносили в контур поэтапно: начали с Atlassian-стека, а потом закидывали в него и остальной приклад, пока в контуре не оказалось то, о чем я говорил выше — Jira, Confluence, тестовые контуры разных систем, системы заказчиков, админки ботов, дашборды со статистикой, логами, мониторингом.
В конечном счете мы пришли к определенной схеме, как загружать проекты в VPN-контур. У нас есть устоявшийся пайплайн. Согласно ему каждый большой клиентский проект мы сразу поднимаем внутри контура. Это важно — не в облаке.
Под проект мы специально арендуем VPS-сервер у хостера. Там сразу все запаковано в Docker, есть шаблон, который можно копипастить с конкретными настройками. Затем берем код из Git, куда его предварительно запушил разработчик. И после теста, если все в порядке, ответственный человек заливает проект на продакшен заказчика нажатием одной кнопки.
Отдельно хочу сказать об админке. Чаще всего в наших ботах есть админ-панель для управления системой — к примеру, пользователи могут добавить или поменять какой-то текст. И мы делаем так, чтобы админка тоже была закрыта VPN-контуром. Благодаря этому можем гарантировать хорошую степень безопасности для заказчиков и сами не переживать, что данные куда-то утекли. Работе самого бота это не мешает.
Здесь надо оговориться: если у вас сайт на WordPress, не надо пытаться спрятать админку под VPN. Просто потому, что это уже чрезмерные усилия по обеспечению безопасности, которые не дадут никакого эффекта.
Вывод
Конечно, VPN-контур не спасет вас от DDoS-атак и ряда других проблем с безопасностью, но как минимум защитит от большинства злоумышленников.
VPN-контур также сокращает количество сотрудников, которые администрируют вашу инфраструктуру, в 2–3 раза.
Ну и главное, помните, что VPN-контур защитит вашу инфраструктуру, если вы подойдете к его настройке с умом.
