Linux: продуктивные системные администраторы без root (защита интеллектуальной собственности)?
Есть ли способ сделать опытного системного администратора Linux продуктивным без предоставления ему полного доступа root?
Этот вопрос возникает с точки зрения защиты интеллектуальной собственности (IP), которая в моем случае полностью сводится к коду и / или конфигурации файлы (т.е. небольшие цифровые файлы, которые легко копировать). Наш секретный соус сделал нас более успешными, чем можно предположить из-за нашего небольшого размера. Точно так же мы когда-то укушены, дважды стеснительны со стороны нескольких бывших недобросовестных сотрудников (не системных администраторов), которые пытались украсть IP. Позиция высшего руководства в основном такова: «Мы доверяем людям, но из личного интереса не можем позволить себе рисковать тем, что предоставим одному человеку больше доступа, чем ему абсолютно необходимо для выполнения своей работы».
О разработчике ] сторона, это ' Относительно легко разделить рабочие процессы и уровни доступа, чтобы люди могли работать продуктивно, но видеть только то, что им нужно видеть. Только лучшие люди (настоящие владельцы компании) имеют возможность комбинировать все ингредиенты и создавать особый соус.
Но я не смог придумать хороший способ сохранить эту IP-секретность на стороне администратора Linux. . Мы широко используем GPG для кода и конфиденциальных текстовых файлов ... но что может помешать администратору (например) подать запрос пользователю и перейти на его сеанс tmux или GNU Screen и посмотреть, что они делают?
(У нас также отключен доступ к Интернету везде, где возможно соприкосновение с конфиденциальной информацией. Но нет ничего идеального, и могут быть дыры, открытые для умных системных администраторов или ошибок на стороне сетевого администратора. Или даже старый добрый USB. Конечно, существует множество других мер, но они выходят за рамки этого вопроса.)
Лучшее, что я могу придумать, - это в основном использовать персонализированные учетные записи с sudo , аналогично тому, что описано в Несколько системных администраторов Linux, работающих как root . В частности: никто, кроме владельцев компании, фактически не имел бы прямого корневого доступа. У других администраторов будет личная учетная запись и возможность sudo войти в систему root. Кроме того, будет установлено удаленное ведение журнала, и журналы будут отправляться на сервер, доступный только владельцам компании. Отключение ведения журнала вызовет какие-то предупреждения.
Умный системный администратор, вероятно, все еще может найти некоторые дыры в этой схеме. Кроме того, он по-прежнему реактивный , а не проактивный . Проблема с нашим IP заключается в том, что конкуренты могут использовать его очень быстро и в очень короткие сроки нанести большой ущерб.
Так что еще лучше был бы механизм, ограничивающий возможности администратора. Но я понимаю, что это тонкий баланс (особенно в свете устранения неполадок и устранения производственных проблем, которые необходимо решить прямо сейчас ).
Я не могу не задаться вопросом, как другие организации с очень конфиденциальные данные управляют этой проблемой? Например, военные системные администраторы: как они управляют серверами и данными, не имея возможности видеть конфиденциальную информацию?
Изменить: В первоначальной публикации я имел в виду упреждающе отреагировать на комментарии «практики найма», которые начинают появляться . Во-первых, это должен быть технический вопрос, и практика приема на работу IMO больше склоняется к социальным вопросам. Но, двое, я скажу вот что: я считаю, что мы делаем все, что разумно для найма людей: интервью с несколькими людьми в фирме; проверка биографических данных и рекомендаций; все сотрудники подписывают многочисленные юридические документы, в том числе один, в котором говорится, что они прочитали и поняли наше руководство, в котором подробно описаны проблемы интеллектуальной собственности. Теперь это выходит за рамки этого вопроса / сайта, но если кто-то может предложить «идеальные» методы найма, которые отфильтровывают 100% плохих актеров, я все слышу. Факты таковы: (1) я не верю, что существует такой идеальный процесс приема на работу; (2) люди меняются - сегодняшний ангел может быть завтрашним дьяволом; (3) попытки кражи кода в этой отрасли кажутся обычным делом.
То, о чем вы говорите, известно как риск "Злого Сисадмина". Длинный и короткий из них:
- Сисадмин - это человек, который имеет повышенные привилегии
- Технически адепт, до уровня, который сделал бы его хорошим "хакером".
- Взаимодействие с системами в аномальных сценариях.
Комбинация этих вещей делает по существу невозможным остановить вредоносные действия. Даже одитинг становится трудным, потому что у вас нет "нормального" уровня, с которым можно было бы сравнить. (И, честно говоря, сломанная система вполне может иметь и сломанный одитинг).
Есть куча шагов по уменьшению:
- Разделение привилегий - вы не можете остановить парня с корнем от выполнения чего-либо в системе. Но можно сделать так, чтобы одна команда отвечала за работу в сети, а другая - за "операционные системы" (или Unix/Windows отдельно).
- Ограничить физический доступ к набору для другой команды, которая не получает учетные записи администратора... но заботится обо всей работе "рук".
- Разделите ответственность за "рабочий стол" и "сервер". Настройте рабочий стол так, чтобы запретить удаление данных. Администраторы рабочего стола не имеют доступа к конфиденциальным данным, администраторы сервера могут их украсть, но им приходится перепрыгивать через обручи, чтобы вытащить их из здания.
- Аудит системы ограниченного доступа -
syslogи аудит на уровне событий, в относительно устойчивую к взлому систему, к которой у них нет привилегированного доступа. Но собирать её недостаточно, нужно следить за ней - и, честно говоря, есть куча способов "украсть" информацию, которая может и не появиться на радаре аудита. (Браконьер против егеря) - применяют шифрование "в покое", поэтому данные не хранятся "в чистоте", и для доступа к ним требуется живая система. Это означает, что люди с физическим доступом не могут получить доступ к системе, которая не находится под активным наблюдением, и что в "аномальном" сценарии, когда над ней работает сисадмин, данные подвергаются меньшему риску. (например, если база данных не работает, данные, вероятно, не читаются)
- Правило двух человек - если вы не возражаете против того, чтобы ваша производительность была подорвана, и ваш моральный дух тоже. (Серьезно - я видел, как это делается, и постоянное состояние работы и наблюдения делает условия работы чрезвычайно трудными).
- Проверьте своих сисадминов - в зависимости от страны могут существовать различные проверки записей. (Проверка криминальных записей, вы можете даже обнаружить, что в некоторых случаях вы можете обратиться за получением допуска, что вызовет проверку)
- Присмотрите за своими сисадминами - последнее, что вы хотите сделать, это сказать "доверенному" человеку, что вы ему не доверяете. И вы, конечно же, не хотите повредить моральному духу, потому что это увеличивает шансы на злонамеренное поведение (или "не-не-выполнение-небрежность, но проскальзывание в бдительности"). Но платят в соответствии с ответственностью, а также набором навыков. И рассмотрим "бонусы" - которые дешевле, чем зарплата, но, вероятно, ценятся больше. Например, бесплатный кофе или пиццу раз в неделю.
- и вы также можете попробовать применить условия контракта, чтобы воспрепятствовать этому, но будьте осторожны с вышеизложенным.
Но довольно фундаментально - вы должны принять, что это вещь доверия, а не техническая вещь. Ваши сисадмины всегда будут потенциально очень опасны для вас, в результате этого идеального шторма.
Если людям действительно нужен доступ администратора к системе, то мало что можно сделать, чтобы ограничить их деятельность на этом ящике.
Большинство организаций доверяют , но проверьте - вы можете дать людям доступ к частям системы, но вы используете именованные учётные записи администраторов (например, вы не даёте им прямой доступ к root), а затем проверяете их деятельность в журнале, в который они не могут вмешиваться.
Здесь есть баланс; вам может понадобиться защита ваших систем, но вам нужно доверять людям, чтобы они тоже выполняли свою работу. Если раньше компанию "укусил" недобросовестный работник, то это может означать, что практика найма в компаниях в какой-то мере неудовлетворительна, и эта практика, предположительно, была создана "топ-менеджерами". Доверие начинается дома; что они делают, чтобы исправить свой выбор при найме на работу?
.Это было бы похоже на проблему найма уборщика для здания. Уборщик получает все ключи, может открыть любую дверь, но причина в том, что они нужны уборщику для выполнения работы. То же самое и с системными администраторами. Симметрично можно подумать об этой вековой проблеме и взглянуть на то, как исторически предоставлялось доверие.
Хотя нет чистого технического решения, тот факт, что нет причины, по которой мы не пытаемся, не должен быть причиной, агрегирование несовершенных решений может дать несколько отличных результатов.
Модель, в которой доверие зарабатывается:
- Дать меньшее количество разрешений для начала
- Постепенно увеличивать разрешения
- Поставить горшочек с медом и наблюдать за тем, что произойдет в ближайшие дни
- Если сисадмин сообщает об этом вместо того, чтобы попытаться злоупотребить им, то это хороший старт
Реализовать несколько уровней административных полномочий:
- Уровень 1: Можно изменять нижний уровень конфигурационных файлов
- Уровень 2: Может модифицировать чуть более высокий уровень конфигурационных файлов
- Level 3: Может модифицировать чуть более высокий уровень конфигурационных файлов и настроек операционной системы
Всегда создавайте среду, где общий доступ одного человека невозможен:
- Разделенные системы в кластерах
- Предоставьте полномочия администратора кластера различным группам
- Минимум 2 группы
Используйте правило Two-man при выполнении изменений ядра высокого уровня:
- https://en.wikipedia.org/wiki/Two-man_rule
- Требование к администратору кластера1 и кластера2 для внесения изменений в ядро
Доверяйте и проверяйте:
- Регистрируйте все
- Регистрируйте мониторинг и оповещения
- Убедитесь, что все действия различимы
Бумажная работа:
- Пусть они подпишут документы, чтобы юридическая система могла помочь вам, подав на них в суд, если они причинят вам боль, дает больше стимулов не делать этого
Пока что все сказанное здесь хорошее, но есть один "легкий" нетехнический способ, который помогает отвергнуть неавторизованного системного администратора - принцип четырех глаз , который в основном требует присутствия двух сисадминов для любого повышенного доступа.
EDIT: Два самых больших пункта, которые я видел в комментариях обсуждают стоимость и возможность сговора. Один из самых больших способов, который я рассмотрел, чтобы избежать обеих этих проблем, это использование управляемой сервисной компании, используемой только для проверки предпринятых действий. При правильной работе техники не будут знать друг друга. Предположим, что техническое мастерство, которое должно быть у MSP, было бы достаточно простым, чтобы иметь знак "нет" предпринятых действий... может быть, даже простым, как "да/нет" чему-либо гнусному.
Очень трудно обезопасить хосты от тех, кто имеет административный доступ. В то время как такие инструменты, как PowerBroker пытаются сделать это, стоимость добавления чего-то ещё, что может сломать и , добавляют барьеры для попыток исправить это. Доступность вашей системы будет снижаться, когда вы реализуете нечто подобное, поэтому установите ожидание на ранней стадии стоимости защиты.
Другая возможность - это проверить, может ли ваше приложение работать на одноразовых хостах через облачного провайдера или в локальном частном облаке. Когда приложение ломается, вместо того, чтобы послать администратора для исправления, вы выбрасываете его и автоматически создаете замену. Это потребует довольно большой работы на стороне приложения, чтобы заставить его работать в этой модели, но это может решить множество проблем, связанных с эксплуатацией и безопасностью. Если сделать это плохо, то это может создать некоторые значительные проблемы с безопасностью, поэтому получите опытную помощь, если вы пойдете по этому пути.
.Не вдаваясь в сумасшедший технический поворот мышления, попробуйте придумать способ дать сисадмину мощность, не давая его (это, скорее всего, выполнимо, но в конечном счете, было бы в какой-то степени ошибочно).
С точки зрения бизнес-практики существует набор простых решений. Не дешевые решения, а простые.
Вы упомянули, что части IP, о которых вы беспокоитесь, разделены, и только люди наверху могут их видеть. Это, по сути, ваш ответ. У вас должно быть несколько администраторов, и НИКто из них не должен быть администратором на достаточном количестве систем, чтобы составить полную картину. Конечно, вам понадобится, по крайней мере, 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 флэш-накопителей для передачи данных без авторизации.
возьмите из этого то, что вам нужно.
.Это ваша базовая дискуссия: 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, запущенный демоном веб-сервера, может видеть файлы в незашифрованном виде". Тогда администратор с правами root может попытаться прочитать файлы и получить только зашифрованную версию. Но веб-сервер и все инструменты, которые ему нужны, видят их незашифрованными. Он даже может проверить бинарную сумму, чтобы администратору было труднее обойти его.
Конечно, вы должны включить аудит, чтобы в случае, если администратор попытается получить доступ к файлам, сообщение было помечено, и люди об этом знали.
.Единственный практический способ - это ограничение того, кто может делать то, что может делать с "судо". Потенциально, вы также можете сделать большую часть того, что вы хотите с selinux, но это, вероятно, займет вечность, чтобы выяснить правильную конфигурацию, которая может сделать это непрактичным.
Соглашения о неразглашении. Нанять сисадмина, они должны подписать NDA, если они нарушат свое обещание, то обратиться в суд. Это не может помешать им украсть секреты, но любой ущерб, который они наносят, делая это, возмещается в суде.
Военные и правительственные сисадмины должны получить допуск к секретной информации различных классов в зависимости от того, насколько чувствителен материал. Идея состоит в том, что тот, кто может получить допуск, менее склонен к воровству или обману.
Другой способ снизить риск (использовать рядом с упомянутыми ранее, а не вместо) - это заплатить хорошие деньги своим сисадминам. Заплатите им так хорошо, что они не захотят красть с вашего IP и бросить вас.
Провести проактивную проверку очень сложно.
Такие решения, как http://software.dell.com/solutions/privileged-management/ (я не работаю в Dell, и другое аналогичное решение доступно) очень эффективно реализует сисадминовую отчетность.
.Я думаю, что на этот вопрос невозможно ответить полностью без некоторых подробностей, таких как:
Сколько сисадминов, как вы ожидаете, должны сохранять "ограничение"?
Для чего нужен доступ "сисадминов"?
Прежде всего, знайте, что можно сделать с sudo. С помощью sudo вы можете разрешить повышенные разрешения для выполнения только одной команды (или вариаций, таких как команды, которые начинаются с "mount -r", но другие команды не разрешены). С помощью SSH ключей, вы можете назначить мандаты, которые позволяют человеку выполнять только определенную команду (например, "sudo mount -r /dev/sdd0 /media/backup"). Следовательно, есть относительно простой способ позволить практически любому человеку (у которого есть SSH ключ) выполнять некоторые специфические операции, не позволяя ему делать абсолютно все остальное.
Все становится немного сложнее, если вы хотите, чтобы технический персонал выполнял исправления того, что сломано. Обычно это может потребовать больших прав и, возможно, доступа для выполнения большого количества команд и/или записи в различные файлы.
Я предлагаю рассмотреть подход, основанный на веб-системах, таких как CPanel (который используется рядом провайдеров) или облачные системы. Часто они могут заставить проблемы на машине исчезнуть, заставив исчезнуть всю машину. Таким образом, человек может выполнить команду, которая заменяет машину (или восстанавливает машину на известный образ), не обязательно предоставляя ему доступ к чтению большого количества данных, или внося небольшие изменения (например, комбинируя небольшое исправление с введением неавторизованного черного хода). Затем, вы должны доверять людям, которые создают образы, но вы уменьшаете количество людей, которым вы должны доверять, чтобы делать меньшие вещи.
В конечном счете, однако, определенное количество доверия должно быть предоставлено некоторому ненулевому количеству людей, которые помогают проектировать систему и которые работают на самом высоком уровне.
Одна вещь, которую делают большие компании, это полагаться на такие вещи, как SQL-серверы, которые хранят данные, доступ к которым может быть удален большим количеством машин. Тогда большее количество техников может иметь полный корневой доступ на некоторых машинах, не имея при этом корневого доступа к SQL-серверам
Другой подход - быть слишком большим, чтобы обанкротиться. Не думайте, что крупные военные или гигантские корпорации никогда не имеют инцидентов с безопасностью. Однако они знают, как:
- восстановить,
- ограничить ущерб (путем разделения ценных вещей)
- иметь контрмеры, включая угрозы судебных разбирательств
- иметь процессы, помогающие ограничить нежелательное воздействие прессы, и планируют, как повлиять на вращение любых негативных историй, которые все же развиваются
Основное предположение заключается в том, что ущерб, который все-таки случается, это просто риск и затраты на ведение их бизнеса. Они ожидают, что продолжат свою деятельность, и происходящие на протяжении многих лет изменения и улучшения ограничат то, какой ущерб, скорее всего, будет реально влиять на их долгосрочную стоимость в течение определенного периода времени
.Поместите машину с корневым администратором в комнату, закрытую двумя ключами, и дайте только по одному каждому из двух администраторов. Админы всегда будут работать вместе, наблюдая за действиями друг друга. Это должна быть единственная машина, содержащая закрытый ключ для входа в систему как root.
Некоторые действия могут не нуждаться в правах root, поэтому только часть работы может потребовать посещения этой комнаты для «парного программирования».
Вы также можете записывать действия в этой комнате на видео в основном для того, чтобы убедиться, что никто не работает в одиночку (это хорошо видно). Кроме того, убедитесь, что рабочее место таково, что экран хорошо виден обоим людям (возможно, большой экран телевизора с большими шрифтами).