Ubuntu для сотрудников банковских разработчиков [закрыто]
Есть ли процессы и методы, задокументированные о том, как запускать пользовательские компьютеры Ubuntu (от установки до повседневного использования) для банков и других предприятий, которые не хотят, чтобы пользователи загружали двоичные файлы из возможно небезопасные места?
Так что apt-get, update и т. д. происходят только из нескольких надежных мест в Интернете или интрасети?
Обновление: это добавлено после первого ответа. Это пользователи службы поддержки, начинающие пользователи систем и разработчики банковского программного обеспечения ... поэтому некоторым из них требуются привилегии sudo. Есть ли готовый способ отслеживать их, чтобы любые исключения быстро вылавливались (например, добавление списка источников), но другие действия, такие как установка вещей из известных репозиториев, не регистрируются.
Цель - обеспечить безопасность, использовать Ubuntu или его разновидность, позволить разработчикам и другим пользователям sudo быть максимально продуктивными. (И уменьшить зависимость от компьютеров Windows и Mac)
.2. А ИТ-специалисты могут диктовать политику пользователям, чтобы они не могли выполнять некоторые действия, например предоставлять общий доступ к папке, даже если пользователь sudo? Полное решение?
3 ответа
Это - очень хороший вопрос, но это - ответ, является очень трудным.
Первый, для начинаний, у @Timothy Truckle есть хорошая начальная точка. Вы выполнили бы свой собственный способный repo, где Ваша служба безопасности могла проверить каждый пакет. Но это только началом.
Следующий Вы хотели бы реализовать группы. Вы стремились бы сделать, чтобы пользователи смогли сделать вещи, они должны без большого количества справки от поддержки. Но в банковском деле Вы действительно хотите вещи, заблокированные вниз. На самом деле во многих корпоративных структурах Вы хотите заблокировать вещи вниз. Так предоставление обычных пользователей sudo полномочия на любом уровне, вероятно, отсутствует.
то, Что Вы, вероятно, сделали бы, является вещами набора так, чтобы определенным группам не были нужны поднятые полномочия делать их работы.
Снова, в большей части программного обеспечения установки корпоративных сред что-то, что могло уволить Вас, таким образом, это нет нет. При необходимости в программном обеспечении, Вы называете IT, и они делают это для Вас, или существует цепочка реквизиции или некоторые такой.
Идеально Вам никогда не был бы нужен нормальный сотрудник, чтобы установить что-либо или когда-либо нуждаться в поднятых полномочиях.
Теперь для Разработчиков вопрос несколько отличается. Возможно, они должны установить, и возможно им нужен sudo. Но их поля находятся в "опасной сети" и никогда не могут соединяться непосредственно с критическими системами.
IT/Персоналу поддержки будет нужен sudo. Но можно ограничить sudo доступ командой или процессом (документы) или другие средства. Могут быть целые объемы о вещах как "2 глазных принципала" и как реализовать их. Но контрольные журналы существуют и могут быть настроены для удовлетворения большинства потребностей.
Так, назад к Вашему вопросу. Ответ Timothy Truckle на 100% корректен, но предпосылка для Вашего вопроса выключена. Обеспечение ОС Linux намного больше о выборе настроек, который необходим для Вашего определенного варианта использования, и меньше об общем представлении, как защитить вещи.
Установите свое собственное debian прокси репозитория в Вашей интранет.
Настраивают установку человечности так, чтобы Ваш debian прокси репозитория был единственной записью в /etc/apt/sources.list.
И вуаля: Вы имеете полный контроль о программном обеспечении, установленном на Ваших клиентах (как долго, поскольку ни у какого пользователя нет полномочий суперпользователя).
<час>Обновление: Добавленный это после первого ответа. Эти пользователи являются поддержкой, неопытными пользователями систем и разработчиками программного обеспечения банка..., таким образом, некоторым из них нужны sudo полномочия. Есть ли готовый способ контролировать их так, чтобы любые исключения были пойманы быстро (как добавление исходного списка), но другие действия как установка материала от известного repos идут несообщаемые.
В Вашей пользовательской установке можно изменить /etc/sudoers файл так, чтобы пользователям разрешили работать sudo apt update и sudo apt install, но никакая другая команда, запускающаяся с apt. Конечно, также необходимо ограничить sudo bash (или любая другая оболочка).
Почти в каждом магазине я видел до сих пор, у разработчиков был полный доступ к машинам разработки, но эти машины только имели доступ к Интернету и к репозиторию исходного кода.
в Исходном коде регистрируются и компилируют на доверяемых машинах (который разработчики обычно не имеют или нуждаются в административных полномочиях на), и затем оттуда развернутый на системах тестирования, которые имеют доступ к внутренней сети.
, Используются ли эти машины разработчиками или отдельной тестовой командой, до Вашей организации - но обычно граница между доверяемыми и недоверяемыми машинами между отдельными машинами с интерфейсом между ними поддающаяся проверке (такими как фиксации исходного кода).
сотрудники Стойки регистрации не получают административных прав, никогда. Когда мы развернули Пасьянс на всех этих машинах, жалобах на эту политику, которую в значительной степени прекращают.