Есть ли способ сделать опытного системного администратора Linux продуктивным, не предоставляя ему полный root-доступ?
Этот вопрос возникает с точки зрения защиты интеллектуальной собственности (IP), которая в моем случае представляет собой полностью файлы кода и / или конфигурации (то есть небольшие цифровые файлы, которые легко копируются). Наш секретный соус сделал нас более успешными, чем можно предположить из-за нашего небольшого размера. Точно так же мы идиома: обжегся на молоке - дует на воду от нескольких бывших недобросовестных сотрудников (не сисадминов), которые пытались украсть IP. Позиция высшего руководства в основном такова: «Мы доверяем людям, но из корыстных соображений не можем позволить себе рисковать тем, что предоставим любому человеку больше доступа, чем ему абсолютно необходимо для выполнения своей работы».
На разработчик Кроме того, относительно легко разделить рабочие процессы и уровни доступа, чтобы люди могли работать продуктивно, но видели только то, что им нужно видеть. Только лучшие люди (фактические владельцы компании) имеют возможность комбинировать все ингредиенты и создавать особый соус.
Но мне не удалось придумать хороший способ сохранить эту секретность IP на стороне администратора Linux. Мы широко используем GPG для кода и конфиденциальных текстовых файлов ... но что может помешать администратору (например) подать запрос пользователю и перейти на его сеанс tmux или GNU Screen и посмотреть, что они делают?
(У нас также отключен доступ в Интернет повсюду, где возможно соприкосновение с конфиденциальной информацией. Но нет ничего идеального, и могут быть дыры, открытые для умных системных администраторов или ошибок на стороне администратора сети. Или даже старый добрый USB. конечно, существует множество других мер, но они выходят за рамки этого вопроса.)
Лучшее, что я могу придумать, это в основном использовать персонализированные учетные записи с судо, аналогично тому, что описано в Несколько системных администраторов Linux, работающих от имени пользователя root. В частности: никто, кроме владельцев компании, фактически не имел бы прямого корневого доступа. У других администраторов будет личная учетная запись и возможность судо в корень. Кроме того, будет установлено удаленное ведение журнала, и журналы будут отправляться на сервер, доступный только владельцам компании. Если вы увидите отключенное ведение журнала, появятся какие-то предупреждения.
Умный системный администратор, вероятно, еще найдет в этой схеме какие-то дыры. И это в стороне, это все еще реактивный скорее, чем активный. Проблема с нашим IP такова, что конкуренты могут использовать его очень быстро и в очень короткие сроки причинить большой ущерб.
Так что еще лучше был бы механизм, ограничивающий возможности администратора. Но я понимаю, что это тонкий баланс (особенно в свете устранения неполадок и исправления производственных проблем, которые необходимо решить. сейчас).
Я не могу не задаться вопросом, как другие организации с очень конфиденциальными данными решают эту проблему? Например, военные системные администраторы: как они управляют серверами и данными, не имея возможности видеть конфиденциальную информацию?
Редактировать: В первоначальной публикации я имел в виду упреждающе рассмотреть комментарии о «практике найма», которые начинают появляться. Во-первых, это должно быть технический вопрос, и практика найма ИМО больше склоняется к Социальное вопросы. Но, во-вторых, я скажу следующее: я считаю, что мы делаем все, что разумно для найма людей: собеседование с множественный люди в фирме; проверка биографических данных и рекомендаций; все сотрудники подписывают многочисленные юридические документы, в том числе один, в котором говорится, что они прочитали и поняли наше руководство, в котором подробно описаны проблемы интеллектуальной собственности. Теперь это выходит за рамки этого вопроса / сайта, но если кто-то может предложить «идеальные» методы найма, которые отфильтровывают 100% плохих актеров, я все слышу. Факты таковы: (1) я не верю, что существует такой идеальный процесс приема на работу; (2) люди меняются - сегодняшний ангел может быть завтрашним дьяволом; (3) попытки кражи кода кажутся обычным делом в этой отрасли.
Все, что было сказано до сих пор, является хорошим материалом, но есть один «простой» нетехнический способ, который помогает свести на нет мошеннического системного администратора - принцип четырех глаз что в основном требует присутствия двух системных администраторов для любого повышенного доступа.
РЕДАКТИРОВАТЬ: два самых важных вопроса, которые я видел в комментариях, - это обсуждение стоимости и возможность сговора. Один из самых важных способов, которые я рассмотрел для избежания обеих этих проблем, - это использование управляемой сервисной компании, используемой только для проверки предпринятых действий. Если все сделано правильно, техники не узнают друг друга. Если исходить из технического мастерства, которым должен обладать MSP, будет достаточно просто подписать предпринятые действия ... может быть, даже так просто, как да / нет в отношении чего-либо гнусного.
Если людям действительно нужен административный доступ к системе, вы мало что можете сделать, чтобы ограничить их действия в этом окне.
Большинство организаций делают доверяй, но проверяй - вы можете предоставить людям доступ к частям системы, но вы используете именованные учетные записи администратора (например, вы не предоставляете им прямой доступ к корень), а затем проверять их действия в журнале, в который они не могут вмешиваться.
Здесь есть балансирующий акт; вам может понадобиться защитить свои системы, но вам нужно также доверять людям делать свою работу. Если раньше компанию «укусил» недобросовестный сотрудник, то это может означать, что практика найма в компании в некотором роде плохая, и эта практика предположительно была создана «топ-менеджерами». Доверие начинается дома; что они делают, чтобы исправить свой выбор найма?
То, о чем вы говорите, известно как риск «злого системного администратора». Вкратце и короче:
Сочетание этих вещей делает практически невозможным пресечение злонамеренных действий. Даже одитинг становится трудным, потому что у вас нет «нормального» для сравнения. (И, честно говоря, сломанная система тоже могла сломать одитинг).
Есть несколько смягчающих шагов:
syslog и аудит на уровне событий для относительно устойчивой к взлому системы, к которой у них нет привилегированного доступа. Но собрать ее недостаточно, вам нужно отслеживать ее - и, честно говоря, существует множество способов «украсть» информацию, которая может не отображаться на радаре аудита. (Браконьер против егерей)Но довольно фундаментально - вы должны признать, что это вопрос доверия, а не технический аспект. Ваши системные администраторы всегда будут потенциально очень опасны для вас в результате этого идеального шторма.
Не вдаваясь в безумный технический поворот ума, чтобы попытаться придумать способ наделить системных администраторов полномочиями, не давая им полномочий (это, вероятно, выполнимо, но в конечном итоге будет в некотором роде ошибочным).
С точки зрения деловой практики существует набор простых решений. Не дешевое решение, но простое.
Вы упомянули, что части ИС, которые вас беспокоят, разделены, и только люди наверху имеют право их видеть. По сути, это ваш ответ. У вас должно быть несколько администраторов, и НИ ОДИН из них не должен быть администратором в достаточном количестве систем, чтобы составить полную картину. Вам, конечно, понадобится как минимум 2 или 3 администратора для каждой части, на случай, если админ заболел, попал в автомобильную аварию или что-то в этом роде. Может, даже ошеломить их. скажем, у вас 4 админа и 8 единиц информации. Администратор 1 может получить доступ к системам, в которых есть части 1 и 2, администратор 2 может перейти к частям 2 и 3, администратор 3 может получить доступ к 3 и 4, а администратор 4 может получить доступ к 4 и 1. У каждой системы есть резервный администратор, но нет админ может поставить под угрозу полную картину.
Одной из техник, которые используют военные, является ограничение перемещения данных. В чувствительной области может быть только одна система, способная записывать диск или использовать USB-накопитель, все остальные системы ограничены. И возможность использовать эту систему крайне ограничена и требует специального документально подтвержденного одобрения вышестоящего руководства, прежде чем кому-либо будет разрешено размещать какие-либо данные о чем-либо, что может привести к утечке информации. Используя тот же токен, вы гарантируете, что сетевой трафик между различными системами ограничен аппаратными брандмауэрами. Администраторы вашей сети, которые контролируют межсетевые экраны, не имеют доступа к системам, которые они маршрутизируют, поэтому они не могут специально получить доступ к информации, а администраторы вашего сервера / рабочей станции гарантируют, что все данные в систему и из системы настроены для шифрования, поэтому что администраторы вашей сети не могут подключиться к сети и получить доступ к данным.
Все ноутбуки / рабочие станции должны иметь зашифрованные жесткие диски, и у каждого сотрудника должен быть личный шкафчик, в котором он должен запирать диски / ноутбуки в конце ночи, чтобы никто не пришел рано / не ушел поздно и не получил доступ к чему-либо. они не должны.
Каждый сервер должен, по крайней мере, находиться в собственной запертой стойке, если не в собственной запертой комнате, чтобы только администраторы, ответственные за каждый сервер, имели к нему доступ, поскольку в конце дня физический доступ важнее всего.
Далее идет практика, которая может навредить или помочь. Ограниченные контракты. Если вы думаете, что можете платить достаточно, чтобы продолжать привлекать новые таланты, возможность держать каждого администратора только в течение заранее определенного периода времени (IE 6 месяцев, 1 год, 2 года) позволит вам ограничить продолжительность чтобы попытаться собрать все части вашего IP.
Мой личный дизайн был бы чем-то вроде ... Разделите ваши данные на любое количество частей, скажем, ради числа 8 у вас есть 8 серверов git, каждый со своим собственным набором избыточного оборудования, каждый из которых управляется другой набор админов.
Зашифрованные жесткие диски для всех рабочих станций, которые будут касаться IP. с определенным каталогом «проекта» на диске, который является единственным каталогом, в который пользователи могут помещать свои проекты. В конце каждой ночи им необходимо очищать свои каталоги проектов с помощью инструмента безопасного удаления, затем жесткие диски удаляются и взаперти (на всякий случай).
Каждому биту проекта назначен другой администратор, поэтому пользователь будет взаимодействовать только с администратором рабочей станции, которому он назначен, если их назначение проекта изменится, их данные будут стерты, им будет назначен новый администратор. Их системы не должны иметь возможности записи и должны использовать программу безопасности, чтобы предотвратить использование USB-накопителей для передачи данных без авторизации.
бери из этого, что хочешь.
Это было бы похоже на задачу найма дворника для здания. У дворника есть все ключи, он может открыть любую дверь, но причина в том, что они нужны дворнику для работы. То же самое и с системными администраторами. Симметрично можно подумать об этой извечной проблеме и посмотреть на исторические способы предоставления доверия.
Хотя нет четкого технического решения, тот факт, что его нет, не должен быть причиной того, что мы его не пробуем, совокупность несовершенных решений может дать несколько отличные результаты.
Модель, в которой заслуживают доверия:
Реализовать несколько уровней административных полномочий:
Всегда создавайте среду, в которой полный доступ для одного человека невозможен:
Используйте правило двух человек при внесении высокоуровневых изменений ядра:
Доверяйте и проверяйте:
Оформление документации:
Очень и очень сложно защитить хосты от тех, у кого есть административный доступ. Хотя такие инструменты, как PowerBroker Попытка сделать это, стоит добавить что-то еще, что может сломать И добавление барьеров для попыток исправить это. Доступность вашей системы ВОЛЯ падение, когда вы реализуете что-то вроде этого, поэтому установите это ожидание как стоимость защиты вещей.
Другая возможность - проверить, может ли ваше приложение работать на одноразовых хостах через облачного провайдера или в локальном частном облаке. Когда кто-то ломается, вместо того, чтобы посылать администратора, чтобы исправить это, вы выбрасываете его и автоматически создаете замену. Это потребует довольно много работы со стороны приложения, чтобы заставить их работать в этой модели, но это может решить множество операционных проблем и проблем безопасности. Если все сделано неправильно, это может создать серьезные проблемы с безопасностью, поэтому обратитесь за помощью к опытным специалистам, если вы пойдете по этому пути.
Это ваше базовое обсуждение: https://security.stackexchange.com/questions/7801/keeping-secrets-from-root-on-linux
Вы разделяете свою ответственность, имея инженеров по безопасности, чья работа заключается в настройке и установке системы, но они не получают учетных данных или доступа к машинам в производственной среде. Они также управляют вашей инфраструктурой аудита.
У вас есть производственные администраторы, которые получают системы, но не имеют ключей для загрузки машины без активных политик SELinux. Служба безопасности не получает ключей для расшифровки конфиденциальных данных, хранящихся на диске в состоянии покоя, когда они выводят из строя сломанную машину.
Используйте централизованную систему аутентификации с сильным аудитом, например Свод и использовать его криптографические операции. Раздайте устройства Yubikey, чтобы сделать ключи абсолютно конфиденциальными и нечитаемыми.
Машины либо протирают при поломке, либо обрабатывают операторы и служба безопасности вместе, и, если вы чувствуете необходимость, контроль со стороны руководства.
Админы по роду работы имеют доступ ко всему. Они могут видеть каждый файл в файловой системе со своими учетными данными администратора. Итак, вам понадобится способ зашифровать файлы, чтобы администраторы не могли их видеть, но файлы по-прежнему могут использоваться командами, которые должны их увидеть. Посмотрите на Vormetric Transparent Encryption (http://www.vormetric.com/products/transparent-encryption)
Это будет работать между файловой системой и приложениями, которые к ней обращаются. Руководство может создать политику, которая гласит: «Только пользователь httpd, запускающий демон веб-сервера, может видеть файлы в незашифрованном виде». Затем администратор со своими учетными данными root может попытаться прочитать файлы и получить только зашифрованную версию. Но веб-сервер и все необходимые инструменты видят их незашифрованными. Он может даже подсчитать контрольную сумму двоичного файла, чтобы администратору было сложнее обойти его.
Конечно, вы должны включить аудит, чтобы в случае, если администратор попытается получить доступ к файлам, сообщение будет помечено, и люди узнают об этом.
Единственный практический способ - ограничить, кто что может делать с помощью 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, поэтому только часть работы может потребовать перехода в эту комнату для «парного программирования».
Вы также можете записывать на видео действия в этой комнате, в основном, чтобы убедиться, что никто не работает в одиночку (это хорошо видно). Также убедитесь, что рабочее место таково, что экран хорошо виден обоим людям (возможно, большой экран телевизора с крупными шрифтами).