Linux: продуктивные системные администраторы без рута (защита интеллектуальной собственности)?

Есть ли способ сделать продуктивного Linux syadmin продуктивным, не предоставляя ему полный root-доступ?

Этот вопрос возникает с точки зрения защиты интеллектуальной собственности (IP), которая в моем случае полностью состоит из кода и / или файлов конфигурации (то есть небольших цифровых файлов, которые легко копируются). Наш секретный соус сделал нас более успешными, чем предполагал наш маленький размер. Точно так же мы однажды укушены, дважды застенчивы от нескольких бывших недобросовестных сотрудников (не сисадминов), которые пытались украсть IP. Позиция топ-менеджмента в основном такова: «Мы доверяем людям, но из собственных интересов не можем допустить, чтобы кто-то из них имел больше доступа, чем ему абсолютно необходимо для выполнения своей работы».

Со стороны разработчика относительно легко разделить рабочие процессы и уровни доступа таким образом, чтобы люди могли работать продуктивно, а видеть только то, что им нужно. Только лучшие люди (настоящие владельцы компании) имеют возможность объединить все ингредиенты и создать специальный соус.

Но я не смог придумать хороший способ сохранить эту секретность IP на стороне администратора Linux. Мы широко используем GPG для кода и чувствительных текстовых файлов ... но что мешает администратору (например) подать в суд на пользователя и переключиться на сеанс tmux или GNU Screen и посмотреть, что они делают?

(У нас также отключен доступ к Интернету везде, где возможно возможное соприкосновение с конфиденциальной информацией. Но нет ничего идеального, и могут быть дыры для умных сисадминов или ошибок на стороне сетевого администратора. Или даже старого доброго USB. Конечно, существует множество других мер, но они выходят за рамки этого вопроса.)

Лучшее, что я могу придумать, - это в основном использование персонализированных учетных записей с помощью sudo , аналогично тому, что описано в книге «Несколько системных администраторов Linux, работающих от имени пользователя root» . В частности: никто, кроме владельцев компании, не имеет прямого корневого доступа. Другие администраторы будут иметь персональную учетную запись и возможность sudo в корень. Кроме того, будет запущено удаленное ведение журнала, и журналы будут отправляться на сервер, к которому имеют доступ только владельцы компании. Если вы отключите ведение журнала, это вызовет некоторые предупреждения.

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

Так что еще лучше будет механизм, который ограничивает возможности администратора. Но я признаю, что это тонкий баланс (особенно в свете устранения неполадок и исправления производственных проблем, которые необходимо решить прямо сейчас ).

Я не могу не задаться вопросом, как другие организации с очень чувствительными данными справляются с этой проблемой? Например, военные сисадмины: как они управляют серверами и данными, не видя конфиденциальной информации?

Редактировать: в первоначальной публикации я имел в виду упреждающее рассмотрение комментариев «практики найма», которые начинают появляться. Во-первых, это должен быть технический вопрос, и практика найма ИМО больше ориентирована на социальные вопросы. Но, два, я скажу так: я считаю, что мы делаем все, что разумно для найма людей: интервью с несколькимилюди в фирме; справочные и справочные проверки; все сотрудники подписывают многочисленные юридические документы, в том числе тот, который говорит, что они прочитали и поняли наше руководство, в котором подробно описываются проблемы, связанные с ИС. Теперь это выходит за рамки этого вопроса / сайта, но если кто-то может предложить «идеальные» методы найма, которые отфильтровывают 100% плохих актеров, я весь в ушах. Факты таковы: (1) я не верю, что существует такой идеальный процесс найма; (2) люди меняются - сегодняшний ангел может быть завтрашним дьяволом; (3) попытка кражи кода в этой отрасли выглядит несколько обыденно.

То, о чем вы говорите, известно как риск «злой сисадмин». Короче говоря, это:

• Системный администратор - это тот, кто имеет повышенные привилегии.
• Технически адепт, до уровня, который сделает их хорошим «хакером».
• Взаимодействие с системами в аномальных сценариях.

Сочетание этих вещей делает практически невозможным прекращение злонамеренных действий. Даже одитинг становится трудным, потому что у вас нет «нормального» сравнения с ним. (И, откровенно говоря, сломанная система вполне могла также нарушить одитинг).

Есть несколько смягчающих шагов:

• Разделение привилегий - вы не можете помешать парню с root-правами что- либо делать в системе. Но вы можете назначить одну команду ответственной за работу в сети, а другую команду - за «операционные системы» (или отдельно Unix / Windows).
• Ограничьте физический доступ к набору другой команде, которая не получает учетные записи администратора ..., но берет на себя всю работу «на руках».
• Разделите ответственность за «рабочий стол» и «сервер». Настройте рабочий стол, чтобы запретить удаление данных. Администраторы рабочего стола не имеют доступа к секретным, администраторы сервера могут украсть его, но им приходится прыгать через обручи, чтобы вывести его из здания.
• Аудит в системе с ограниченным доступом - syslogи аудит на уровне событий, в относительно устойчивой к взлому системе, к которой у них нет привилегированного доступа. Но собирать его недостаточно, вам нужно следить за ним - и, честно говоря, есть множество способов «украсть» информацию, которая может не отображаться на контрольном радаре. (Браконьер против егерей)
• применять шифрование «в состоянии покоя», чтобы данные не хранились «в открытом виде» и для доступа к ним требуется работающая система. Это означает, что люди с физическим доступом не могут получить доступ к системе, за которой не ведется активный мониторинг, и что в «аномальном» сценарии, когда над ним работает системный администратор, данные менее уязвимы. (например, если база данных не работает, данные, вероятно, не читаются)
• Правило двух человек - если ты в порядке с твоей производительностью, которой наносят вред, и твоим моральным духом также. (Серьезно - я видел, как это было сделано, и постоянное состояние работы и наблюдения делает его чрезвычайно трудным для работы).
• Проверьте ваши системные администраторы - различные проверки записей могут существовать в зависимости от страны. (Проверка судимости, вы можете даже обнаружить, что в некоторых случаях вы можете подать заявление на проверку безопасности, что приведет к проверке)
• Позаботьтесь о своих системных администраторах - последнее, что вы хотите сделать, это сказать «доверенному» человеку, что вы ему не доверяете. И вы, конечно же, не хотите вредить моральному духу, потому что это увеличивает вероятность злонамеренного поведения (или «не совсем небрежности, но ослабления бдительности»). Но платить в соответствии с ответственностью, а также набор навыков. И рассмотрим «льготы» - это дешевле, чем зарплата, но, вероятно, ценится больше. Нравится бесплатный кофе или пицца раз в неделю.
• и вы также можете попытаться применить условия договора, чтобы помешать этому, но будьте осторожны с вышесказанным.

Но в принципе - вы должны признать, что это вещь доверия, а не техническая вещь. Ваши системные администраторы всегда будут потенциально очень опасны для вас в результате этого идеального шторма.

Все сказанное до сих пор здесь - хорошая вещь, но есть один «легкий» нетехнический способ, который помогает свести на нет мошеннического администратора системы - принцип четырех глаз, который в основном требует присутствия двух системных администраторов для любого повышенного доступа.

РЕДАКТИРОВАТЬ: две самые большие вещи, которые я видел в комментариях, обсуждают стоимость и возможность сговора. Один из самых больших способов избежать обеих этих проблем, который я рассмотрел, заключается в использовании управляемой сервисной компании, используемой только для проверки предпринятых действий. Если все сделано правильно, техники не узнают друг друга. Если исходить из технического мастерства, которым должен обладать ССП, было бы достаточно просто подписать выполненные действия ... может быть, даже так просто, как «да» или «нет» на что-нибудь гнусное.

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

Большинство организаций делают, что доверяют, но проверяют - вы можете дать людям доступ к частям системы, но вы используете именованные учетные записи администратора (например, вы не предоставляете им прямой доступ к root ), а затем проверяете их действия в журнале, который они не может мешать.

Здесь есть балансирование; вам может потребоваться защитить ваши системы, но вам также нужно доверять людям выполнять свою работу. Если компания была ранее «укушена» недобросовестным сотрудником, то это может указывать на то, что практика найма компаний в некотором роде плохая, и эти практики предположительно были созданы «топ-менеджерами». Доверие начинается дома; что они делают, чтобы исправить свой выбор при найме?

Без погружения себя в безумное техническое извращение ума, чтобы попытаться придумать способ дать сисадмину силу, не давая им силы (это, вероятно, выполнимо, но в конечном итоге будет иметь недостатки).

С точки зрения деловой практики существует множество простых решений. Не дешевое решение, но простое.

Вы упомянули, что фрагменты ИС, которые вас беспокоят, разделены, и только люди наверху имеют право видеть их. Это по сути ваш ответ. У вас должно быть несколько администраторов, и ни один из них не должен быть администратором на достаточном количестве систем, чтобы составить полную картину. Вам, конечно, понадобится как минимум 2 или 3 администратора для каждой части, в случае, если администратор заболел или попал в автомобильную аварию или что-то еще. Может быть, даже ошеломить их. скажем, у вас есть 4 администратора и 8 единиц информации. Администратор 1 может получить доступ к системам, в которых есть части 1 и 2, администратор 2 - к частям 2 и 3, администратор 3 - к 3 и 4, а администратор 4 - к 4 и 1. В каждой системе есть резервный администратор, но нет Администратор может поставить под угрозу полную картину.

Одной из техник, которую используют и военные, является ограничение перемещения данных. В чувствительной области может быть только одна система, которая может записывать диск или использовать флэш-накопитель USB, все остальные системы ограничены. А возможность использования этой системы крайне ограничена и требует специального документированного одобрения высшими должностными лицами, прежде чем кому-либо будет разрешено помещать какие-либо данные во что-либо, что может привести к утечке информации. Вместе с тем, вы гарантируете, что сетевой трафик между различными системами ограничен аппаратными брандмауэрами. Администраторы вашей сети, управляющие межсетевыми экранами, не имеют доступа к системам, которые они маршрутизируют, поэтому они не могут конкретно получить доступ к информации, а администраторы вашего сервера / рабочей станции гарантируют, что все данные в и из системы настроены для шифрования,

Все ноутбуки / рабочие станции должны иметь зашифрованные жесткие диски, и у каждого сотрудника должен быть личный шкафчик, в котором они обязаны запирать диски / ноутбуки в конце ночи, чтобы никто не приходил рано / не уезжал поздно и не получал доступ к чему-либо. они не должны.

Каждый сервер должен, по крайней мере, находиться в своей собственной запертой стойке, если не в своей собственной запертой комнате, чтобы к нему имели доступ только администраторы, ответственные за каждый сервер, поскольку в конце дня физический доступ превосходит все.

Далее идет практика, которая может либо навредить / помочь. Ограниченные контракты. Если вы думаете, что можете заплатить достаточно, чтобы продолжать привлекать новых талантов, то возможность удерживать каждого администратора только в течение заранее определенного периода времени (например, 6 месяцев, 1 год, 2 года) позволит вам ограничить продолжительность работы кого-то другого. попытаться собрать все кусочки вашего IP.

Мой личный дизайн был бы чем-то вроде ... Разделить ваши данные на сколько угодно частей, скажем, ради числа 8, у вас есть 8 git-серверов, каждый со своим набором избыточного оборудования, каждый из которых администрируется другой набор администраторов.

Зашифрованные жесткие диски для всех рабочих станций, которые будут касаться IP. с конкретным каталогом «project» на диске, который является единственным каталогом, в который пользователям разрешено помещать свои проекты. В конце каждого вечера они должны проводить санитарную обработку своих каталогов проектов с помощью инструмента безопасного удаления, затем жесткие диски удаляются и заперт (просто чтобы быть в безопасности).

Каждому биту проекта назначается отдельный администратор, поэтому пользователь будет взаимодействовать только с администратором рабочей станции, которому он назначен, если его назначение проекта изменяется, его данные стираются, ему назначается новый администратор. Их системы не должны иметь возможности записи и должны использовать программу безопасности, чтобы предотвратить использование флэш-накопителей USB для передачи данных без авторизации.

возьми из этого что хочешь.

Это было бы похоже на вызов найма дворника для здания. У уборщика есть все ключи, он может открыть любую дверь, но причина в том, что он нужен для выполнения этой работы. То же самое с системными администраторами. Симметрично можно подумать об этой извечной проблеме и взглянуть на то, как доверие предоставляется исторически.

Хотя нет точного технического решения, тот факт, что его нет, не должен быть причиной того, что мы его не пробуем, совокупность несовершенных решений может дать несколько отличные результаты.

Модель, где заслужено доверие :

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

Реализовать несколько уровней административных полномочий :

• Уровень 1. Может изменять нижний уровень файлов конфигурации.
• Уровень 2: Может изменить немного более высокий уровень файлов конфигурации
• Уровень 3: Может изменить немного более высокий уровень файлов конфигурации и настроек ОС

Всегда создавайте среду, в которой полный доступ одного человека невозможен :

• Сплит системы в кластерах
• Предоставьте полномочия администратора кластера различным группам
• Минимум 2 группы

Используйте правило двух человек при выполнении основных изменений на высоком уровне :

• https://en.wikipedia.org/wiki/Two-man_rule
• Требовать администратора от cluster1 и cluster2 для основных изменений

Доверяй и проверяй :

• Войти все
• Журнал мониторинга и оповещения
• Убедитесь, что все действия различимы

Оформление документов :

• Попросите их подписать документы, чтобы правовая система могла помочь вам, предъявив им иск, если они причинят вам боль, дает больше стимулов не делать этого

Очень очень сложно защитить узлы от тех, кто имеет административный доступ. Несмотря на то, что такие инструменты, как PowerBroker, пытаются это сделать, стоимость заключается в добавлении чего-то другого, что может сломать, и в добавлении барьеров для попыток исправить это. Ваша готовность системы БУДЕТ падение , когда вы реализуете что - то вроде этого так установить , что ожидание рано , так как стоимость защиты вещей.

Другая возможность - проверить, может ли ваше приложение работать на одноразовых хостах через облачного провайдера или в локальном частном облаке. Когда кто-то ломается, вместо того, чтобы отправить администратора, чтобы исправить это, вы выбрасываете его и автоматически строите замену. Это потребует довольно большой работы на стороне приложения, чтобы заставить их работать в этой модели, но это может решить много проблем эксплуатации и безопасности. Если все сделано плохо, это может создать некоторые серьезные проблемы с безопасностью, поэтому получите опытную помощь, если вы идете по этому пути.

Это ваше базовое обсуждение: https://security.stackexchange.com/questions/7801/keeping-secrets-from-root-on-linux

Вы разделяете свою ответственность, имея инженеров по безопасности, которые занимаются настройкой и установкой системы, но у них нет учетных данных или доступа к рабочим машинам. Они также управляют вашей инфраструктурой аудита.

У вас есть рабочие администраторы, которые получают системы, но не имеют ключей для загрузки машины без активных политик SELinux. Служба безопасности не получает ключи для расшифровки конфиденциальных данных, хранящихся в покое на диске, когда сломанная машина отключается от обслуживания.

Используйте централизованную систему аутентификации с таким строгим аудитом, как Vault, и используйте ее криптографические операции. Раздайте устройства Yubikey, чтобы сделать ключи абсолютно приватными и нечитаемыми.

Машины либо вытираются при поломке, либо обрабатываются совместно оперативной службой и службой безопасности, и, если вы чувствуете необходимость в надзоре со стороны руководства

Админы по роду работы имеют доступ ко всему. Они могут видеть каждый файл в файловой системе со своими учетными данными администратора. Итак, вам понадобится способ зашифровать файлы, чтобы администраторы не могли его увидеть, но эти файлы по-прежнему могут использоваться командами, которые должны его видеть. Посмотрите на Vormetric Transparent Encryption ( http://www.vormetric.com/products/transparent-encryption )

То, как это будет работать, заключается в том, что он находится между файловой системой и приложениями, которые к ней обращаются. Руководство может создать политику, которая гласит: «Только пользователь httpd, работающий с демоном веб-сервера, может видеть файлы в незашифрованном виде». Тогда администратор с его корневыми учетными данными может попытаться прочитать файлы и получить только зашифрованную версию. Но веб-сервер и все необходимые ему инструменты видят их в незашифрованном виде. Он может даже проверять контрольную сумму бинарного файла, чтобы администратору было труднее его обойти.

Конечно, вы должны включить аудит, чтобы в случае, если администратор попытался получить доступ к файлам, сообщение было помечено, и люди знали об этом.

Единственный практический способ - ограничить, кто может что-то делать с помощью sudo. Вы также можете сделать большую часть того, что вы хотите, с selinux, но, вероятно, потребуется целая вечность, чтобы найти правильную конфигурацию, которая может сделать ее непрактичной.

Соглашения о неразглашении. Нанимайте сисадмина, они должны подписать соглашение о неразглашении, если они нарушают свое обещание, передают их в суд. Это не может помешать им украсть секреты, но любой ущерб, который они наносят, делая это, подлежит возмещению в суде.

Военные и правительственные сисадмины должны получать допуски по безопасности разных классов в зависимости от того, насколько чувствителен материал. Идея заключается в том, что тот, кто может получить разрешение, с меньшей вероятностью может украсть или обмануть.

Еще один способ снизить риск (использовать вместо упомянутых ранее, а не вместо) - это платить хорошие деньги своим системным администраторам. Платите им так хорошо, что они не хотят воровать с вашего IP и оставлять вас.

Я думаю, что на этот вопрос невозможно ответить полностью без каких-либо подробностей, таких как:

Сколько сисадминов вы ожидаете оставить «ограниченными»?

Для чего нужен доступ "сисадмина"?

Прежде всего, знайте, что вы можете сделать с помощью sudo. С помощью sudo вы можете разрешить повышенным разрешениям запускать только одну команду (или варианты, например команды, которые начинаются с «mount -r», но другие команды запрещены). С помощью ключей SSH вы можете назначить учетные данные, которые позволяют человеку выполнять только определенную команду (например, «sudo mount -r / dev / sdd0 / media / backup»). Следовательно, существует относительно простой способ позволить любому человеку (у которого есть ключ SSH) иметь возможность выполнять некоторые конкретные операции, не позволяя им делать абсолютно все остальное.

Все становится немного сложнее, если вы хотите, чтобы технические специалисты исправляли неисправности. Обычно для этого может потребоваться большее количество разрешений и, возможно, доступ для запуска широкого спектра команд и / или записи в различные файлы.

Я предлагаю рассмотреть подход веб-систем, таких как CPanel (который используется рядом интернет-провайдеров) или облачных систем. Они часто могут заставить проблемы уйти из машины, заставив уйти всю машину. Таким образом, человек может запускать команду, которая заменяет компьютер (или восстанавливает компьютер до заведомо исправного образа), не обязательно предоставляя человеку доступ для чтения большого количества данных или делая небольшие изменения (например, объединяя незначительные исправления). с введением несанкционированной задней двери). Затем вам нужно доверять людям, которые делают изображения, но вы уменьшаете количество людей, которым нужно доверять, чтобы делать мелкие вещи.

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

Одна вещь, которую делают крупные компании, - это полагаться на такие вещи, как серверы SQL, которые хранят данные, к которым может обращаться удаленно большее количество компьютеров. Тогда большее количество технических специалистов может иметь полный доступ с правами root на некоторых компьютерах, не имея доступа с правами root к серверам SQL.

Другой подход - быть слишком большим, чтобы потерпеть неудачу. Не думайте, что у крупных военных или гигантских корпораций никогда не бывает инцидентов в сфере безопасности. Тем не менее, они знают, как:

• восстановления,
• ограничить ущерб (путем отделения ценных вещей)
• иметь контрмеры, в том числе угрозы судебного разбирательства
• иметь процессы, помогающие ограничить нежелательное воздействие прессы, и иметь планы, как повлиять на ход любых негативных историй, которые действительно развиваются

Основное предположение состоит в том, что ущерб, который действительно имеет место, является просто риском и стоимостью их ведения бизнеса. Они ожидают продолжения работы, и текущие разработки и улучшения в течение многих лет будут ограничивать степень ущерба, который один инцидент может реально повлиять на их долгосрочную стоимость в течение определенного периода времени.

Проактивная проверка очень сложна.

Такие решения, как http://software.dell.com/solutions/privileged-management/ (я не работаю в Dell, доступны другие подобные решения), очень эффективны для обеспечения подотчетности системного администратора.

Поместите машину администратора root в комнату, запертую двумя ключами, и дайте только по одному для каждого из двух администраторов. Админы всегда будут работать вместе, наблюдая за действиями друг друга. Это должен быть единственный компьютер, содержащий закрытый ключ для входа в систему как root.

Некоторым действиям могут не потребоваться права root, поэтому только часть работы потребует перехода в эту комнату для «парного программирования».

Вы также можете записывать видео в этой комнате, чтобы убедиться, что никто не работает в одиночку (это легко увидеть). Кроме того, убедитесь, что рабочее место так, что экран легко виден обоим людям (возможно, большой экран телевизора с большими шрифтами).