Мы привлекаем консультанта в Индии в качестве нашего администратора Linux. Мы его не очень хорошо знаем, и для его работы ему необходим доступ Root ко всем нашим серверам (включая аудит безопасности).
Какова наилучшая практика предоставления удаленного консультанта для такой работы, чтобы мы были защищены от любых злокачественных действий?
Заранее спасибо.
Ответы:
Не . Кроме того, вы подвержены такой же опасности неумелости, как и злого укуса, от того, что я видел в типичных способах, которыми компании справляются с этим.
Я хотел бы сказать, что в Индии, вероятно, есть отличные системные администраторы, но то, как многие компании делают вещи, ужасно.
Если вы ходите в салон-магазин, вы, скорее всего, увидите, что к ним придет довольно большой разрез, и многие из них вряд ли должным образом проверят своих сотрудников. Я разговаривал с тремя, с одним из которых я работал, и никто из них не давал никаких технических интервью.
Так что, если вы хотите нанять кого-то удаленно, ради бога, опросите его сами и убедитесь, что он знает свою работу. Системное администрирование слишком важно, чтобы передавать кому-либо вслепую
Теперь, когда я справился с «неумелой» частью этого,
Администрация довольно широкая фраза. И кто-то с доступом с правами root может сделать что угодно . Теперь лично я думаю, что создание учетной записи для администратора и предоставление ему возможности подняться с помощью sudo - лучшая идея (с которой ваша система управления конфигурациями должна справиться, если у вас много серверов). Тем не менее, даже это зависит от определенного количества доверия. Есть так много историй о явном повреждении, которое может нанести недовольный системный администратор. Изменить все ваши пароли? Конечно, вы можете войти в конце концов, но это не тривиально, и это, вероятно, будет стоить больше, чем вы экономите.
Итак, рассмотрим местный. Если нет, подумайте о ком-то, кого вы сами проверили и наняли напрямую .
источник
su
полномочия подняться до уровня root. Когда кто-то говорит, что ему нужен «root-доступ», это то, о чем он должен просить. Если этот человек говорит, что ему нужен «пароль root», он все равно не компетентен выполнять эту работу.sudo
полномочия подняться до root? Если нет, не могли бы вы рассказать о своих лучших методах использованияsu
для повышения уровня своих прав, не имея и не распространяя пароль root?sudo
иsu
две совершенно разные вещи. Спасибо за разъяснение.Как уже упоминалось, не делай этого.
Единственный способ защитить себя - сделать что-то вроде этого:
Как должно быть ясно, это очень неуклюжий и неэффективный процесс, но если вы настаиваете на приеме работы от не доверенного лица, это один из способов справиться с ситуацией.
Однако, как я рекомендовал, вам гораздо лучше нанять известного, доверенного человека.
источник
С юридической точки зрения: должная осмотрительность заранее и строгие штрафы за нарушение договора.
Вы начинаете с обычной хорошей практики найма, которая также применяется при найме местного персонала (и / или поставщиков услуг), который включает в себя проверку фактов предоставленного резюме, запрашивать стенограммы и номера сертификации, проверять и называть их рекомендации, интервью, возможно, даже проверка данных или проверка безопасности и т. д. и т. д.
Затем примените кнут : платите справедливую стоимость, предлагайте привлекательную работу, замечательных коллег, хорошие условия труда, льготы и т. Д. ( Если вы платите арахис, вы получаете обезьян ).
И клюшка : нарушите условия вашего трудового договора / контракта на обслуживание, и мы заразим вас нашими адвокатами и оставим вас банкротами!
К сожалению, оба перечисленных варианта становятся все более сложными при пересечении границ и часовых поясов.
Как только вы решите нанять кого-нибудь:
Этот вопрос подробно описывает то, что я обычно прошу своих клиентов сделать для меня удаленный доступ, что также может стать отправной точкой для вас.
источник
На ум приходит один системный метод защиты, о котором я не упоминал.
Размещайте экземпляры Linux в качестве виртуальных машин на гипервизоре виртуализации (VMware, Xenserver, Hyper-V и т. Д.).
НЕ ДАЙТЕ удаленному администратору административный доступ к гипервизору. Удаленный администратор получит только root-доступ к самим виртуальным машинам.
Внедрить систему резервного копирования на основе гипервизора (Unitrends, Veeam, vSphere Data Protection и т. Д.)
Держите по крайней мере один снимок в день каждой виртуальной машины Linux, возвращаясь к тому времени, которое вы считаете необходимым.
НЕ ДАЙТЕ удаленному администратору доступ для записи в резервные хранилища.
Если вы сделаете это, у вас будут резервные снимки каждого экземпляра Linux, которые удаленный администратор не может контролировать. Если удаленный администратор делает что-то неуместное, умышленно или случайно, вы всегда можете смонтировать резервную копию до того, как возникла подозрительность, чтобы оценить произошедшее и, возможно, восстановить чистое состояние.
Это не будет доказательством против атаки по боковому каналу гипервизора, которая потенциально может быть смонтирована изнутри виртуальной машины, к которой злоумышленник имеет root-доступ.
Если ваши резервные копии не заходят достаточно далеко во времени, это не защитит вас.
Вы должны полностью доверять тому, кто контролирует ваш гипервизор и инфраструктуру резервного копирования.
Если вы делаете это в облаке (AWS, Azure и т. Д.), Детали реализации будут отличаться, но общая концепция будет такой же.
По сути, разделите обязанности между сторонами, которые не являются деловыми партнерами, в дополнение к найму людей, которым вы доверяете.
источник
Дайте ему свою учетную запись. Затем выясните, к чему ему конкретно нужен доступ, и предоставьте только этот доступ, но больше ничего. Например, если ему нужно перенастроить веб-сервер Apache, используйте ACL, чтобы предоставить ему доступ на запись к файлам конфигурации Apache, и настройте его так,
sudo
чтобы он перезапускал службу Apache, но не выполнял никаких других команд от имени root. Как всегда, сохраняйте резервные копии всего, что вы предоставляете ему (в данном случае, ваши файлы конфигурации Apache).источник