Консультант по удаленному администрированию Linux - лучшая практика [закрыто]

Мы привлекаем консультанта в Индии в качестве нашего администратора Linux. Мы его не очень хорошо знаем, и для его работы ему необходим доступ Root ко всем нашим серверам (включая аудит безопасности).

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

Заранее спасибо.

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

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

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

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

Теперь, когда я справился с «неумелой» частью этого,

Администрация довольно широкая фраза. И кто-то с доступом с правами root может сделать что угодно . Теперь лично я думаю, что создание учетной записи для администратора и предоставление ему возможности подняться с помощью sudo - лучшая идея (с которой ваша система управления конфигурациями должна справиться, если у вас много серверов). Тем не менее, даже это зависит от определенного количества доверия. Есть так много историй о явном повреждении, которое может нанести недовольный системный администратор. Изменить все ваши пароли? Конечно, вы можете войти в конце концов, но это не тривиально, и это, вероятно, будет стоить больше, чем вы экономите.

Итак, рассмотрим местный. Если нет, подумайте о ком-то, кого вы сами проверили и наняли напрямую .

Как уже упоминалось, не делай этого.

Единственный способ защитить себя - сделать что-то вроде этого:

1. Настаивайте на том, чтобы консультант использовал выбранную вами систему управления конфигурацией.
2. Консультант напишет манифесты управления конфигурацией для необходимых вам действий.
3. Консультант проверит манифесты на тестовой системе.
4. Когда все будет готово, консультант передаст конфигурацию в хранилище кода.
5. Все изменения рассматриваются одним из ваших сотрудников или другим консультантом, который не имеет абсолютно никакого отношения к первому и не имеет возможности связаться с ними.
6. Как только изменения будут подписаны, они будут применены к серверу вами или сотрудником. Первоначальный консультант не должен иметь доступа ни к одной из ваших систем.

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

Однако, как я рекомендовал, вам гораздо лучше нанять известного, доверенного человека.

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

С юридической точки зрения: должная осмотрительность заранее и строгие штрафы за нарушение договора.

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

Затем примените кнут : платите справедливую стоимость, предлагайте привлекательную работу, замечательных коллег, хорошие условия труда, льготы и т. Д. ( Если вы платите арахис, вы получаете обезьян ).

И клюшка : нарушите условия вашего трудового договора / контракта на обслуживание, и мы заразим вас нашими адвокатами и оставим вас банкротами!

К сожалению, оба перечисленных варианта становятся все более сложными при пересечении границ и часовых поясов.

Как только вы решите нанять кого-нибудь:

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

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

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

Размещайте экземпляры Linux в качестве виртуальных машин на гипервизоре виртуализации (VMware, Xenserver, Hyper-V и т. Д.).

НЕ ДАЙТЕ удаленному администратору административный доступ к гипервизору. Удаленный администратор получит только root-доступ к самим виртуальным машинам.

Внедрить систему резервного копирования на основе гипервизора (Unitrends, Veeam, vSphere Data Protection и т. Д.)

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

НЕ ДАЙТЕ удаленному администратору доступ для записи в резервные хранилища.

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

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

Если ваши резервные копии не заходят достаточно далеко во времени, это не защитит вас.

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

Если вы делаете это в облаке (AWS, Azure и т. Д.), Детали реализации будут отличаться, но общая концепция будет такой же.

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

Дайте ему свою учетную запись. Затем выясните, к чему ему конкретно нужен доступ, и предоставьте только этот доступ, но больше ничего. Например, если ему нужно перенастроить веб-сервер Apache, используйте ACL, чтобы предоставить ему доступ на запись к файлам конфигурации Apache, и настройте его так, sudoчтобы он перезапускал службу Apache, но не выполнял никаких других команд от имени root. Как всегда, сохраняйте резервные копии всего, что вы предоставляете ему (в данном случае, ваши файлы конфигурации Apache).