Zero trust для компании из 30 человек: VPN, обратные прокси и патч, дошедший до прода

Zero trust звучит как тема для банка с отделом безопасности. На этой неделе о нём писали Forrester, Red Hat и Docker, и у каждого между строк один и тот же вопрос: что из этого делать компании, где отдела безопасности нет, а есть один человек, который отвечает за сервер. Я такой человек в нескольких компаниях, и ниже то, что у меня из этого сложилось.

Что вышло

Forrester 23 октября вернулся к теме «Zero Trust на пивной бюджет» и назвал текст «минимально жизнеспособный zero trust». Адресат из вводной части понятен: тот, кто прочитал эталонные архитектуры и BeyondCorp, попробовал найти себя в одной из моделей зрелости и не понял, с чего начать. Рецепт Forrester пересказывать не буду, скажу свой.

Red Hat 22 октября выпустила четвёртую часть серии о zero trust в OpenShift. Формулировка оттуда точная: zero trust легко описать одной фразой «никогда не доверяй, всегда проверяй», трудно сделать повторяемым. Фраза не говорит, что разворачивать в понедельник утром и как показать проверяющему, что контроль работает. OpenShift для компании из 30 человек не тот масштаб, но вопрос про понедельник правильный.

Тремя днями раньше, 19 октября, Red Hat написала о патчах, и это, по-моему, главный текст недели. Патч был готов за дни, а до прода шёл месяцы. В разговорах с клиентами ответ почти никогда «мы не знали», почти всегда «знали, но довезти до прода заняло дольше, чем окно эксплуатации». Эту задержку они называют одной из самых недооценённых метрик риска: AI сжимает время до эксплойта до часов, а многие организации всё ещё тратят от 40 до 90 дней на пересборку и проверку.

Docker 21 октября рассказал про Secure Software Factory, эталонную архитектуру для команд, где AI-агенты меняют код, гоняют тесты и отдают результат человеку. Она выросла из Agent Baseline, который Docker, Snyk и Keycard опубликовали в июле. Команды, по их словам, получают скорость и заодно агентов, которые удаляют базы и пушат в прод без согласования. Центральная мысль: чем больше автономии у агента, тем меньше на него можно полагаться, и контроль должен жить в среде, где он запущен. Это та же мысль, что у zero trust, только про программу вместо сотрудника.

Manufacturing Today 22 октября перечислил восемь практик кибербезопасности для производств: подключённые станки и промышленный интернет вещей дают производительность и одновременно новые уязвимости. Самого списка в анонсе нет, ниже мой.

Производство, где подрядчик видит всё

Возьмём производственную компанию. В цехе сеть, в ней станки, сервер 1С, сетевые папки с чертежами и ноутбук подрядчика, который приехал настроить лазер. Он подключился к Wi-Fi, и теперь ему доступно всё, что внутри: папки по SMB, база, принтеры. Сеть устроена по принципу «внутри свои».

Вывод: «внутри сети» перестаёт быть правом доступа. Право даёт конкретному человеку или программе конкретный сервис, и даёт его тот, кто за сервис отвечает.

Как это устроено у меня

На гидропонной ферме в США, с которой я работаю с 2023 года, 25 контроллеров на 2 площадках, и у сетей площадок серые IP, без публичного адреса. Чтобы сервер на Debian в Google Cloud видел контроллеры, я настроил обратные прокси, NAT, firewall и VPN. Вместе это одна сеть, где у сервера есть доступ ко всем контроллерам, а снаружи до них не добраться. Адреса и сетевые продукты не раскрываю, это частная инфраструктура клиента.

В PDR-компании в США, где сейчас больше 30 человек, вопросы безопасности идут ко мне. У системы несколько контуров защиты и резервных копий. Сервер, VPN, сетевое оборудование и телефонию обслуживаю сам, а при крупных взломах в мире проверяю, касается ли это нас. С 2022 года, когда появился свой сервер, серьёзных сбоев с восстановлением не было.

У производственной компании, для которой я делал расчёт деталей по Excel-спецификациям, веб-версия программы открыта только внутри сети компании и ограничена ACL, а к сетевым папкам по SMB программа ходит через VPN. Сама логика расчёта живёт на сервере, и без доступа к нему клиентская часть ничего не считает: заказчик хотел, чтобы программу нельзя было унести.

Это и есть zero trust на мой размер: без платформы и без отдела, на VPN, обратных прокси и правах, которые выдаются под конкретный сервис.

Что я бы сделал в компании из 30 человек

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

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

Измерять одно число, как предлагает Red Hat: сколько дней проходит от выхода патча до его работы в проде. Если это недели, разбирать, где застревает: на согласовании, на сборке или на том, что некому.

Отрепетировать восстановление из резервной копии.

AI-помощникам, если они у вас есть в разработке, давать те же права, что подрядчику: ограниченную среду и ничего боевого.

О сервере как общем центре, который хранит состояние и проверяет права: статья Сервер: данные, доступ и выполнение процесса. Инфраструктура, которую можно выпускать и восстанавливать: DevOps и инфраструктура. Сети из этого текста описаны в кейсах гидропонной фермы и технического партнёрства с PDR-компанией. Из близких обзоров: PHP2Shell и проверка своих серверов, уязвимость в бизнес-логике и почему малому бизнесу хватает Docker Compose; раньше я писал про закрытый контур и работу без интернета. Если список доступов у вас не записан, расскажите, как всё устроено сейчас, и я предложу, с чего начать. Обсудить задачу.