Могу ли я ограничить пользователя root от установки или удаления пакетов
Я хочу ограничить пользователя root от установки пакетов
4 ответа
Да, если вы выполняете управление доступом на основе ролей (RBAC):
Управление доступом на основе ролей (RBAC) - это механизм нейтрального контроля политики, определенный вокруг ролей и привилегий. Компоненты RBAC, такие как ролевые разрешения, отношения роли пользователя и роли, упрощают выполнение пользовательских заданий. Исследование NIST показало, что RBAC удовлетворяет многие потребности коммерческих и правительственных организаций. RBAC может использоваться для упрощения администрирования безопасности в крупных организациях с сотнями пользователей и тысячами разрешений. Хотя RBAC отличается от MAC и DAC-систем управления доступом, он может применять эти политики без каких-либо осложнений. Его популярность очевидна из-за того, что многие продукты и предприятия используют это прямо или косвенно.См. управление доступом на основе ролей (RBAC)
В RBAC нет реального «корневого» пользователя, как обычно думают. То, что обычно считается «root», становится ролью, и вам не нужно предоставлять разрешения этой роли для установки программного обеспечения.
Однако внедрение RBAC не является тривиальным, и, в конце концов, вы все еще имеете иметь как минимум несколько системных администраторов, которые имеют полный доступ ко всему. Кто-то должен иметь доступ ко всему, чтобы настроить роли RBAC.
По моему опыту, RBAC действительно полезен для крупных организаций с большим количеством системных администраторов, которые должны делать разные вещи.
В США RBAC также может потребоваться для удовлетворения юридических требований, предъявляемых такими вещами, как HIPAA и Sarbanes-Oxley.
В вашем случае RBAC почти наверняка не стоит административных накладных расходов .
Но, безусловно, можно предотвратить «root» от установки программного обеспечения.
Нет.
root является суперпользователем. Он может делать все по определению. Невозможно установить какие-либо ограничения на систему, которые не могут быть возвращены с правами root.
Да, если вы выполняете управление доступом на основе ролей (RBAC):
Управление доступом на основе ролей (RBAC) - это механизм нейтрального контроля политики, определенный вокруг ролей и привилегий. Компоненты RBAC, такие как ролевые разрешения, отношения роли пользователя и роли, упрощают выполнение пользовательских заданий. Исследование NIST показало, что RBAC удовлетворяет многие потребности коммерческих и правительственных организаций. RBAC может использоваться для упрощения администрирования безопасности в крупных организациях с сотнями пользователей и тысячами разрешений. Хотя RBAC отличается от MAC и DAC-систем управления доступом, он может применять эти политики без каких-либо осложнений. Его популярность очевидна из-за того, что многие продукты и предприятия используют это прямо или косвенно.См. управление доступом на основе ролей (RBAC)
В RBAC нет реального «корневого» пользователя, как обычно думают. То, что обычно считается «root», становится ролью, и вам не нужно предоставлять разрешения этой роли для установки программного обеспечения.
Однако внедрение RBAC не является тривиальным, и, в конце концов, вы все еще имеете иметь как минимум несколько системных администраторов, которые имеют полный доступ ко всему. Кто-то должен иметь доступ ко всему, чтобы настроить роли RBAC.
По моему опыту, RBAC действительно полезен для крупных организаций с большим количеством системных администраторов, которые должны делать разные вещи.
В США RBAC также может потребоваться для удовлетворения юридических требований, предъявляемых такими вещами, как HIPAA и Sarbanes-Oxley.
В вашем случае RBAC почти наверняка не стоит административных накладных расходов .
Но, безусловно, можно предотвратить «root» от установки программного обеспечения.
-
1Если я правильно вас понимаю, это способ избежать доступа к корням пользователей, а вместо этого предоставить им роли, которые позволят им выполнять конкретные задачи, которые им нужны, не так ли? Речь идет не о том, чтобы заставить корень ничего не делать. И с физическим доступом любой может получить привилегии root в любом случае, как напоминание. – Byte Commander 31 July 2017 в 21:50
-
2@ByteCommander В RBAC нет пользователя root, чтобы он ничего не делал - пользователь root не может ничего сделать, потому что его нет. Там может быть роль, называемая root, которая может быть настроена так, как это обычно делает пользователь root, но этого не должно быть. RBAC специально разработан таким образом, что никто не может получить доступ или контролировать все. Реальная проблема OP заключается в том, что они раздавали корень всем. RBAC может вернуть некоторую власть, но управление RBAC - это кошмар. IMO OP должен либо укорениться, либо рассказать пользователям «Вы получите root, мы его не исправим». RBAC действительно предназначен для HIPAA / SOX. – Andrew Henle 31 July 2017 в 23:07
-
3(cont) Каждый раз, когда я занимался RBAC, это было болезненно. Если вы не обязаны использовать его, я бы сказал DO NOT . Но он будет делать то, что хотел OP - предотвратить «root». пользователей от установки программного обеспечения при одновременном предоставлении привилегированного доступа других типов. Но ценой большого количества человеко-часов sysadmin и множества разочарованных пользователей. – Andrew Henle 31 July 2017 в 23:10
-
4Rkb будет лучше отменять разрешения и использовать файл sudoers для добавления разрешений на команды, которые нужны пользователям. – Rinzwind 31 July 2017 в 23:31
Нет.
root является суперпользователем. Он может делать все по определению. Невозможно установить какие-либо ограничения на систему, которые не могут быть возвращены с правами root.
-
1
-
2@Rkb хорошо, что вы ошибаетесь. Попросите владельца компании аннулировать эти разрешения администратора. Для администратора должно быть 1 администратор и 1 резервная копия. – Rinzwind 31 July 2017 в 17:39
-
3Если люди хотят обойти марионетку, они ... не должно быть так много пользователей root. – Rui F Ribeiro 31 July 2017 в 20:08
-
4@RuiFRibeiro Да, конечно. Но в среде компании вы должны заставить сотрудников оставить Puppet целыми, если они подпишут документ или что-то еще. Вы можете удаленно проверить, все ли Puppet работает на всех клиентах, и для этого должно быть достаточно доверия к сотрудникам. Если нет, единственное решение - это не дать им локальные учетные записи администратора. Однако, поскольку они имеют физический доступ к машинам, они также могут теоретически получить права root без предоставления учетной записи администратора. – Byte Commander 31 July 2017 в 20:20
-
5@RKB Я читал до тех пор, пока «все пользователи имеют корневой доступ»; и тогда мне пришлось зайти в тихую комнату, чтобы закричать какое-то время. – Shadur 1 August 2017 в 08:42