Уязвимости в Jira и Confluence — неизбежное зло. Мы все привыкли и научились с ними справляться: вывесили дополнительный пароль, обновились до безопасной версии и живём хорошо, пьём джус. 

А потом оказалось, что с третьего квартала 2024 года кина обновлений Atlassian не будет. И вскоре любая серьёзная уязвимость стала бы для нас фатальной. 

Что это значит?

1. Jira и Confluence могли лечь. И не для того, чтобы отдохнуть и вернуться к нам со свежими силами, а насовсем. 

Даже если бы мы их подняли, всё равно случился бы лютый простой бизнес-процессов.

2. Наши данные могли унести. Где-то за год конфиденциалка и всё остальное оказалось бы в даркнете или в других неположенных местах.

И поэтому мы решили раскатать его — крутой корпоративный VPN.

А что за кипиш?

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

Мы решили убрать дырявое великолепие за корпоративный VPN, и команда Infra очень кстати допиливала новую версию. Прога стала безопаснее, быстрее и производительнее, её легче масштабировать на всю компанию — не VPN, а сын маминой подруги.

Хоть он работает через бесячую двухфакторку, с точки зрения безопасности это суперкруто. И мы начали думать, как выдавать доступы.

Это будет гуманно, это по любви

У нас было 3000 сотрудников, куча ботов и фрилансеры… Не то чтобы команде инфобеза не хватало челленджей, но раз начал вдумчиво переводить компанию на корпоративный VPN, то надо идти до конца.

Мы могли бы разослать всем логины и пароли, сказать «Подключайтесь» и на следующий день убрать Confluence с Jira за VPN. Но решили быть гуманными и завести системы так, чтобы никто не запаниковал и бизнес не встал. 

Для этого мы развернули целое мероприятие и выдавали доступ постепенно — в течение двух месяцев. 

План-капкан

Задача: не допустить простоя бизнес-процессов и оперативно помочь тем, у кого лапки (кто не смог подключиться).

Решение: подключить такое количество сотрудников, чтобы после переноса Jira и Confluence за VPN не утопить саппорт в запросах потеряшек. 

Как определили необходимое количество саппорта

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

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

Мощная подготовка

Инструкции

Перед подключением команд мы составили максимально понятные user-friendly инструкции — такие, чтобы поняла даже креветка (спойлер: помогло, но не всем).

Формы выдачи доступов

Мы актуализировали формы заявок на доступы во внутреннем портале, чтобы коллегам не пришлось искать информацию о старом VPN.

Техподдержка до переноса систем за VPN

Sad but true: у нас в компании нет организованного внутреннего саппорта. Ребята, которые должны были поддерживать переход на VPN, были завалены другой работой, поэтому команду дважды пришлось модифицировать и изменять.

Support: v. 1.0

Два сотрудника из офисного саппорта — эти ребята могут обработать до 40 заявок в день.

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

— от серьезных проблем, связанных со спецификой конкретных регионов (в этом случае должны будут подключаться инженеры);

— до вопросов «А где инструкция?» и т. п. 

А ссылка на неё выделена, блин, капсом в сообщении с инструкцией! Извините, бомбануло...

Забежим вперёд

Несмотря на все инструкции и пуши, в сумме два саппорта обработали больше 1000 заявок.

Чтобы ребята не захлебнулись под тяжестью заявок, мы пошли к топам за помощью.

Support: v. 2.0. This is Suppooort!

Топы отдали нам ещё одну команду поддержки. Мы обучили её, и к двум героям присоединилось 300 спартанцев.

На новый саппорт мы направили команды со слабыми техническими скилами. Как и планировали, запросов было больше — обращался каждый второй. Но команда саппорта тоже стала больше и могла обработать 120–150 обращений. 

Рассчитываем по формуле и получаем: 120 (150) х 2 х 5 = 1200 (1500).

Ориентируемся на 1200 пользователей в командах с большой текучкой.

Коридор пользователей при саппорте v. 2.0

450 пользователей в коридоре первого саппорта + 1200 во втором = 1650 (это 55%).

Так мы вычислили, что 45% подключённых пользователей достаточно для перевода Jira и Confluence за VPN.

Предоставление доступов к VPN

Этап 1. Оценить базу сотрудников, которые пользуются Confluence и Jira 

На этом этапе мы смотрели, у кого в компании есть доступ к Atlassian. У тех, кто давно не заходил в Confluence и Jira, мы отозвали доступы. 

Это снизило риски для безопасности и нагрузку на команды саппорта и инфобеза.

Этап 2. Распределить доступы на уровне сети 

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

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

Поэтому доступы в таких командах мы ограничивали.

Этап 3. Выдать доступы

Мы делали это постепенно — по командам. Договорились с руководителями о поддержке: тимлиды дополнительно пушили своих ребят и контролировали задачу.

Логика была такой:

Чтобы отслеживать динамику, завели борд в Grafanа. В ней видели логины всех, кто хоть раз подключался к VPN, и высчитывали процент подключившихся.

Пуши. И ещё пуши. И снова пуши. И снова пуши

Наверное, перед переходом на VPN мы замучили всех. Потому что из каждого канала кричали: «Подключись, или твоя работа остановится!» 

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

Стажёры vs конфиденциальность

У нас в компании много стажёров, и все они работали в Confluence и Jira из-под одной учётной записи (да, это неправильно).

В чём фишка?

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

• Создавать каждому учётку в Confluence долго и сложно.

• Саппортить подключение стажёров к VPN ещё сложнее — техническая грамотность ребят обычно невысока.

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

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

Нужно было сделать зеркало максимально похожим, потому что:

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

• Многие стажёры впоследствии становятся сотрудниками. Мы хотели упростить их онбординг и обучить работе с Confluence.

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

Финальный аккорд 

За два месяца к VPN подключилось достаточно сотрудников. Мы жмякнули ту самую кнопку и настроили доступ через двухфакторку ко всем системам Atlassian. 

Всё прошло ровно, за исключением одного

Ребята собирались раскатать корпоративный VPN в 20:00, а я собиралась в это время за них выпить.

В итоге они дёрнули рубильник уже в час ночи, а мне пришлось… всё это время пить за них под «Игру престолов».

А что было после? 

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

Ею стали ребята, которые создавали наш корпоративный VPN. Конечно, не обошлось без нового цикла обучения, но мы уже были на опыте. 

Некоторые проблемы решали руками, но простоев не было.

Активная фаза выдачи доступов опоздунам прошла. Мы ответили на все запросы и язвительные комментарии, провели проверку безопасности и убедились, что никто лишний не получил доступ к нашим системам.

Динамику метрик при переходе на корпоративный VPN:

Да, было страшно, но мы это сделали:

• За квартал справились с крупным проектом, который коснулся каждого сотрудника Skyeng. 

Мы закладывали на работы больше двух кварталов, но активная фаза заняла всего два с лишним месяца.

• Приняли сложные, часто непопулярные решения. 

Был риск, что затея провалится. Но мы не забоялись и подкатили раскатили VPN на всю компанию.

• Получили возможность убирать любые системы за VPN.

Ведь теперь система и доступы уже настроены.

• Повысили безопасность информации в компании.

Боже, как мы хороши!

VPN с доступом через двухфакторную аутентификацию защищён намного лучше, чем наши заплатанные Jira и Confluence, а сегментация доступов снижает риски дополнительно.

Задавайте вопросы в комментах, пользуйтесь нашим кейсом и приготовьтесь много икать. Потому что вспоминать вас добрым (но это неточно) словом будут часто!