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