Comments 26
Я последовал вашему совету и по максимуму закрыл всё на продакшен системе. Но мне начали звонить пользователи и жаловаться, что не могут получить доступ к нашему сайту, что почта не ходит, да и о том, что телефония не работает я узнал на личный сотовый телефон.
Я обсудил проблему с коллегами и они мне подсказали, что не надо делать всё, что пишут в Интернетах. После того, как я убрал "закрыть всё по максимуму" работоспособность сервисов восстановилась.
Я хотел показать, что чрезмерно обобщающие советы "делайте безопасно!" неконструктивны, потому что система должна быть не только безопасной, но и работать. Что выводит проблему безопасности из области тривиальной, в область почти недостижимого.
Вы, похоже, восприняли все буквально.
Э… IMHO к вам это тоже относится =)
1) Запретить всё, разрешить только нужное
2) Разрешить всё, запретить только потенциально опасное.
Безопаснее всего использовать первый подход. Да, этот подход сложнее в реализации, но профита от него намного больше.
amarao рекомендую всё же помучиться и открыть только нужные порты.
PS на клиентских проектах именно так и делаю.
Ваш сарказм неуместен.
А как в реальном мире решается проблема доступа к лайв системе для диагностики проблем и обновления? Когда с одной стороны стоит CI/CD и прочая кроссфункиональность команды, а с другой — вполне резонная безопасность и закрытость от лишних людей.
Обычно закрывают лишние порты от внешнего доступа. Вернее, наоборот, — открывают только нужные порты, а остальные, типа ssh, доступны только из внутренней сети, к которой можно подключиться только через vpn.
У каждого сотрудника должна быть индивидуальная учетка, которая блокируется в момент увольнения. Уровень доступа зависит от роли учетки. Администратор может всё, саппорт только читать логи, а технические учётки (backup, cd) только тот минимум, который необходим для создания бэкапа и выкладки нового кода.
Доступы к учетке для деплоя хранятся в настройках ci системы. Сам доступ к таким настройкам так же ограничен ролью "деплой менеджер".
Доступы к продуктовым внешним сервисам, используемым в коде (база, api), хранятся на продуктовых же серверах (файлики, переменные окружения, vault, whatever...).
Захардкоженых дефолтных юзеров быть не должно — они должны создаваться вручную на этапе первичной инсталляции приложения.
Никаких сложностей в общем нет, главное включать мозги и почаще задавать вопросы "а что если?".
Что если админ уволится? Заблокируем учётку и доступ пропадет.
Что если нечистый на руку программист сольёт код налево? Ничего, так как пароли от прода есть только на проде.
Например на этапе создания архитектуры не учли возможность появления роли «посередине», например «вторая линия саппорта», которым прав админа много, а прав саппорта — мало. Но архитектура по каким-либо причинам не позволяет в определенных местах сделать что-то «по середине» (требуется серьезное перепиливание определенного слоя).
Сюда добавляется бюрократическо-организиацонная махина большой компании, по которой у саппорта не может быть второй учетки для повышения привилегий, или еще чего этакое.
И вот уже в отделе появляются «обходные пути».
В статье подменяют понятия "не открывать код" и "не хранить приватную информацию в репозитории".
Добавлю, что очень удобно давать доступы только после письма на отдельную почту.
После увольнения можно будет пробежаться по письмам и удалить каждый доступ. А не мучительно вспоминать все ли удалили.
Статья бы выиграла с примером как очистить репу от ключа или пароля полностью. Сорри, с телефона не смогу набросать пример.
— в git-репозитариях лежат конфиги ansible, puppet, etc, т.е. от хранения ключей, паролей совсем избавиться как-бы не получается (да, есть vault, etc, но это снижение рисков, а не устранение проблемы)
— сотрудник работающий 2 дня, и сотрудник работающий 2 года, в общем случае у сотрудника всегда есть доступ к некоторой информации. и проблема отзыва всех прав ушедшего сотрудника — это проблема процесса увольнения. Технические тулы упрощают жизнь конечно, но без процесса это не живет.
— в git-репозитариях лежат конфиги ansible, puppet, etc, т.е. от хранения ключей, паролей совсем избавиться как-бы не получается (да, есть vault, etc, но это снижение рисков, а не устранение проблемы)
А кто мешает разделить код приложений от кода системы управления конфигурациями?
У меня (админа) нет доступа к коду приложений, а у разрабов нет доступа к коду salt.
ну и в открытый доступ можно выкладывать только то в чём на 100% уверен, если же раньше были дыры, то наверно не надо эту историю выкладывать, а только текущее состояние, полагаю если поискать то можно ещё дырок найти которые недофикшеные или не правильно дофикшеные
Как потерять доступ в лайв систему, просто пошарив исходный код