Вы меня извините, но порядочному толковому сотруднику точно нужен рут, все данные, расклад, архитектура, без этого админ не сможет грамотно научится управлять инфрой/процессами
Как раз наоборот. Грамотного и толковому сотруднику - нужны минимальные привилегии, а не рут.
Короче, все это чушь, лучше занимайтесь своими сотрудниками, не проверять часы в жире, а разговаривать и понимать мотивацию людей нужно, насколько толковые, какие амбиции и какой опыт, это даёт гораздо больше чем вот эта вот снимая безопасность
Я тоже считаю, что надо нанимать порядочных и толковых людей, а не идиотов. Только вот это все равно не страхует от того, что компьютер «порядочного и толкового» сотрудника не будет заражен вирусом. Знаете, угроз каждый день меняются. И, к сожалению, злоумышленники становятся все хитрее и хитрее.
А теперь про permitrootlogin yes, что если вам нужен доступ к либвирту по сокету, а у пользака таких прав нет, будете колхоз городить и палки в работу вставлять?
Надо разбираться, зачем он нужен, а не давать возможность направо и налево пользоваться. Может быть вы дверь от своей квартиры не запираете? Или ключ оставляете в доступности всем? Что-то сомневаюсь, будьте последовательны.
Можно ли защитить ci, конечно, ваулт апрол и т.д., только назовите компанию где настолько не доверяют своим сотрудникам (которым выдают доступ в проекты инфры ci), чтобы городить на каждый чих такие строгие меры?
ну, или - в контейнере /etc/hosts условный. Какой-нибудь секурити тул будет верещать - Алярм, опасность, а ничего такого нет. Хотя, по-чесноку, наверняка, и с systemd-nspawm и chroot окружениями будет такая же ботва.
Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
я никогда их аналогом виртуалок и не называл
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит
да
Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
да
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении
нет. Именно за счет того, что с точки зрения докера и CRI контейнеры "существуют", а с точки зрения ядра линукс - нет - у нас возникают проблемы, связанные с тем, чтобы правильно рапортовать, например, что процесс ХХХ случился именно в контейнере YYY. Это примерно такая же проблема совместимости, как между nftables и iptables. Повторюсь - тулинг недостаточно зрелый. Хотя и двигается в этом направлении.
контролей и обзервабилити у контейнеров меньше - это можете даже не оспаривать. Тулинг пока не созрел до конца, увы. Условный Falco берешь - а он путь к файлу пишет не так, как надо. Сидишь и гадаешь (я утрирую) - проблема на хост машине или в контейнере. Так что проблема более широкая.
например, самой сутью образа - там нет кернела. Касательно сравнения именно убунту vs убунту - с точки зрения пакетного менеджера и установленных бинарников - разницы скорее не будет. И вообще выше товарищ правильно говорит - нечего это сравнивать, потому что для контейнеров надо брать контейнерные штуки вроде wolffie, from scratch, distroless etc.
Разработчики все дружно перешли на докер потому, что их жизнь от этого стала легче. А когда жизнь у разработчиков легче - бизнесу разработка стоит дешевле, в некоторых случаях - заметно дешевле.
то-то все фронты собирают статикой и деплояет не докерами, а напрямую на cdn.
варианты есть всегда ) но это больно. Все равно базовые образы надо откуда-то брать - а они уязвимые. Вроде бы к 2025 появилось движение к базово защищенным образам. Но че-то все сильно платное - что bitnami, что cgr.dev. Да сам докерхаб в конце-концов. Посмотрим, во что это выльется.
не чуть больше. А значительно больше (больше деталей, движущихся компонентов, достаточно высокая степень незрелости экосистемы и самое главное - возможно тащить недоверенный код с помойки в виде докерхаба). Теоретически ограничить докер можешь. Но это куча работы. Кто ее делать будет?
Но ведь и в виртуализации больше рисков чем в использовании отдельных железных серверов
тоже правда
Это вопрос баланса
да
Поэтому если у ИБ нет чёткого и здравого аргумента какие конкретно риски для бизнеса они закрывают заменой докера на виртуализацию либо соответствие каким критичным для бизнеса стандартам это обеспечивает, то вероятнее всего отдел ИБ творит фигню - обычно из-за собственной низкой квалификации или синдрома вахтёра.
честно говоря, для большинства бизнесов докер вообще не нужен. И вообще им контейнеризация не решает ни одной задачи ) Запихать 10 разных сервисов на один сервер? Ну, камон. Смешно. 10 ВМ прекрасно работает. 10 железяк - да, может быть тупо избыточно по ресурсам (но во многих компаниях деньги на железо-то и не считают внезапно).
Иными словами, я не против отключения PermitRootLogin, я за то, чтобы его выключали не "по умолчанию", а при наличии понимания что конкретно это даст в текущей ситуации.
чтобы избежать проблем - достаточно мыть руки перед едой и после туалета. Не просто так цветет наследие Земмельвайса. Но если этого не делать - дальше не пройдешь. Поэтому запрет PermitRootLogin- хорошее умолчание.
я не сказал, что рут. Если есть ssh под непривилегированным пользователем - как мы выяснили - можно эскалироваться до рута. Если есть сервисы, которые доступны по сети - тоже. Хотя это и сложнее.
Может ваш ноут вирусами заражен и давно уже слил все ваши логины, пароли и ключи. Такой вариант вы не рассматриваете?
я уже сто лет в обед пользуюсь менеджерами паролей вроде 1password и Proton Pass.
аксиома - идеально настроенных систем не бывает. Тем более в любой сколько нибудь сложной системе всегда найдутся проблемы. Уязвимые пермиссии, например, могут приехать из пакетного менеджера. Или неудачной установки, скажем, https://github.com/kubernetes-sigs/kubespray/issues/4824https://github.com/kubernetes-sigs/kubespray/issues/6891 Жесть же. Именно поэтому контейнеризация не защищает - из нее гораздо легче выбраться, чем из виртуализации (там только штуки вроде Spectre и Meltdown, да дырки в гиперах позволяют выбраться).
если бекап с той же машины - MySQL, Pg прекрасно аутентифицируют под линукс учеткой. В этом случае Вы смещаете проблему.
Если же договориться, что брать пароль из волта или подобного - тоже норм, тоже по сути смещаем проблему. Пароль нигде в открытом виде не хранится, но чтобы сходить в волт тоже нужен токен или что-то подобное. Система действительно усложняется, но упрощается аудит и упрощается ротация паролей в случае факапа.
Как раз наоборот. Грамотного и толковому сотруднику - нужны минимальные привилегии, а не рут.
Я тоже считаю, что надо нанимать порядочных и толковых людей, а не идиотов. Только вот это все равно не страхует от того, что компьютер «порядочного и толкового» сотрудника не будет заражен вирусом. Знаете, угроз каждый день меняются. И, к сожалению, злоумышленники становятся все хитрее и хитрее.
Надо разбираться, зачем он нужен, а не давать возможность направо и налево пользоваться. Может быть вы дверь от своей квартиры не запираете? Или ключ оставляете в доступности всем? Что-то сомневаюсь, будьте последовательны.
Посмотрите доклады уважаемого @0xffd
ну, или - в контейнере /etc/hosts условный. Какой-нибудь секурити тул будет верещать - Алярм, опасность, а ничего такого нет. Хотя, по-чесноку, наверняка, и с systemd-nspawm и chroot окружениями будет такая же ботва.
я никогда их аналогом виртуалок и не называл
да
да
нет. Именно за счет того, что с точки зрения докера и CRI контейнеры "существуют", а с точки зрения ядра линукс - нет - у нас возникают проблемы, связанные с тем, чтобы правильно рапортовать, например, что процесс ХХХ случился именно в контейнере YYY. Это примерно такая же проблема совместимости, как между nftables и iptables. Повторюсь - тулинг недостаточно зрелый. Хотя и двигается в этом направлении.
конфиги надо не бекапить, а
либо бекапим виртуалку целиком средствами облака
а еще лучше - раскладываем конфиги любимым средством puppet/salt/ansible и вместо бекапа просто имеем единую точку правды.
контролей и обзервабилити у контейнеров меньше - это можете даже не оспаривать. Тулинг пока не созрел до конца, увы. Условный Falco берешь - а он путь к файлу пишет не так, как надо. Сидишь и гадаешь (я утрирую) - проблема на хост машине или в контейнере. Так что проблема более широкая.
например, самой сутью образа - там нет кернела. Касательно сравнения именно убунту vs убунту - с точки зрения пакетного менеджера и установленных бинарников - разницы скорее не будет. И вообще выше товарищ правильно говорит - нечего это сравнивать, потому что для контейнеров надо брать контейнерные штуки вроде wolffie, from scratch, distroless etc.
то-то все фронты собирают статикой и деплояет не докерами, а напрямую на cdn.
я это не отрицал, если что. Но это подобно сборке своего дистрибутива линукс - никто этим в здравом уме не занимается, если можно этим не заниматься.
варианты есть всегда ) но это больно. Все равно базовые образы надо откуда-то брать - а они уязвимые. Вроде бы к 2025 появилось движение к базово защищенным образам. Но че-то все сильно платное - что bitnami, что cgr.dev. Да сам докерхаб в конце-концов. Посмотрим, во что это выльется.
не чуть больше. А значительно больше (больше деталей, движущихся компонентов, достаточно высокая степень незрелости экосистемы и самое главное - возможно тащить недоверенный код с помойки в виде докерхаба). Теоретически ограничить докер можешь. Но это куча работы. Кто ее делать будет?
тоже правда
да
честно говоря, для большинства бизнесов докер вообще не нужен. И вообще им контейнеризация не решает ни одной задачи ) Запихать 10 разных сервисов на один сервер? Ну, камон. Смешно. 10 ВМ прекрасно работает. 10 железяк - да, может быть тупо избыточно по ресурсам (но во многих компаниях деньги на железо-то и не считают внезапно).
чтобы избежать проблем - достаточно мыть руки перед едой и после туалета. Не просто так цветет наследие Земмельвайса. Но если этого не делать - дальше не пройдешь. Поэтому запрет
PermitRootLogin- хорошее умолчание.ну, да, без аудита тут не обойтись, что еще раз доказывает, что ИБ это комплексная история.
я не сказал, что рут. Если есть ssh под непривилегированным пользователем - как мы выяснили - можно эскалироваться до рута. Если есть сервисы, которые доступны по сети - тоже. Хотя это и сложнее.
я уже сто лет в обед пользуюсь менеджерами паролей вроде 1password и Proton Pass.
аксиома - идеально настроенных систем не бывает. Тем более в любой сколько нибудь сложной системе всегда найдутся проблемы. Уязвимые пермиссии, например, могут приехать из пакетного менеджера. Или неудачной установки, скажем, https://github.com/kubernetes-sigs/kubespray/issues/4824 https://github.com/kubernetes-sigs/kubespray/issues/6891 Жесть же. Именно поэтому контейнеризация не защищает - из нее гораздо легче выбраться, чем из виртуализации (там только штуки вроде Spectre и Meltdown, да дырки в гиперах позволяют выбраться).
например, https://snehbavarva.medium.com/privilege-escalation-techniques-series-linux-cron-jobs-a5b797b424b4
По su / sudoers - история тоже известная. В самом sudo пачка уязвимостей https://habr.com/ru/companies/kaspersky/articles/925604/
Чуточку добавьте любознательности
при должной степени ловкости - любой.
Admin v2.0
потому что. Иди почитай матчасть, бро. Если вдруг не получится - приходи, расскажу.
ну, 3 vs 20 не так уж страшно. А вот 3 vs 300 - беда.
если бекап с той же машины - MySQL, Pg прекрасно аутентифицируют под линукс учеткой. В этом случае Вы смещаете проблему.
Если же договориться, что брать пароль из волта или подобного - тоже норм, тоже по сути смещаем проблему. Пароль нигде в открытом виде не хранится, но чтобы сходить в волт тоже нужен токен или что-то подобное. Система действительно усложняется, но упрощается аудит и упрощается ротация паролей в случае факапа.
как доказано опытом поколений - к безопасности это не добавляет.
Если файл утек (даже под паролем) - ключи надо менять