Я собираюсь внедрить Ansible в свой центр обработки данных, и я ищу некоторые рекомендации по обеспечению безопасности о том, где разместить управляющую машину и как управлять ключами SSH.
Вопрос 1: управляющая машина
Конечно, нам нужна управляющая машина. На управляющей машине сохранены общедоступные SSH-ключи. Если злоумышленник имеет доступ к управляющей машине, он потенциально имеет доступ ко всему центру обработки данных (или к серверам, управляемым Ansible). Итак, что лучше: иметь специальную машину управления в центре обработки данных или машину с дистанционным управлением (например, мой ноутбук, удаленно подключенный к центру обработки данных)?
Если лучше всего использовать мой ноутбук (который, конечно, может быть украден, но я мог бы надежно сохранить свои открытые ключи в Интернете в облаке или в автономном режиме на портативном зашифрованном устройстве), что, если мне нужно использовать некоторые веб-интерфейсы с Ansible, например Ansible Tower, Semaphore, Rundeck или Foreman, который необходимо установить на централизованной машине в центре обработки данных? Как его обезопасить и не допустить, чтобы он превратился в «единую точку атаки»?
Вопрос 2: ключи SSH
Предположим, мне нужно использовать Ansible для выполнения некоторых задач, которые необходимо выполнять от root (например, установка пакетов программного обеспечения или что-то в этом роде). Я думаю, что лучше всего не использовать пользователя root на контролируемых серверах, а добавить обычного пользователя для Ansible с разрешениями sudo. Но, если Ansible должен выполнять почти все задачи, он должен иметь доступ ко всем командам через sudo. Итак, какой выбор лучше:
~/.ssh/authorized_keys> Вопрос 1: управляющая машина
В Userify (полное раскрытие информации: мы фактически предлагаем программное обеспечение для управления ключами ssh) мы постоянно занимаемся этим, поскольку у нас также есть самое большое хранилище ключей SSH. Как правило, мы рекомендуем локальную установку, а не использование облака, поскольку вы увеличиваете контроль, уменьшаете площадь вашей поверхности, вы действительно можете ограничить ее только известными надежными сетями.
Важно помнить, что в правильно построенной системе, подобной этой, на самом деле не должно быть никаких существенных секретов, которые могут быть раскрыты злоумышленнику. Если кто-то въезжает в ваш центр обработки данных на вилочном погрузчике и уходит с вашим сервером, он не получит многого, за исключением некоторых сильно зашифрованных паролей, возможно, некоторых сильно зашифрованных файлов и некоторых открытых ключей без соответствующих закрытых ключей. Другими словами, не так уж и много.
Как вы указываете, настоящие векторы угроз здесь следующие: что произойдет, если злоумышленник получит контроль над этой машиной и использует его для развертывания собственных учетных записей пользователей и (открытых) ключей. Это риск практически для каждой облачной платформы (например, Linode). Вы должны быть максимально сосредоточены на предотвращении доступа к плоскости управления, что означает минимизацию поверхности атаки (раскрытие только нескольких портов и максимально возможная блокировка этих портов) и, предпочтительно, использование программного обеспечения, защищенного от повышения привилегий и различных атак ( Внедрение SQL, XSS, CSRF и т. Д.) Включите доступ 2FA / MFA к плоскости управления и сосредоточьтесь на максимальной блокировке этой плоскости управления.
Итак, что лучше: иметь специальную машину управления в центре обработки данных или машину с дистанционным управлением (например, мой ноутбук, удаленно подключенный к центру обработки данных)?
Это определенно лучше иметь выделенную машину управления в защищенном центре обработки данных, потому что вы можете изолировать ее и заблокировать, чтобы предотвратить / минимизировать риск кражи или несанкционированного доступа.
Если лучше всего использовать мой ноутбук (который, конечно, может быть украден, но я мог бы надежно сохранить свои открытые ключи онлайн в облаке или офлайн на портативном зашифрованном устройстве), что, если мне нужно использовать некоторые веб-интерфейсы с Ansible, например Ansible Tower, Semaphore, Rundeck или Foreman, который необходимо установить на централизованном компьютере в центре обработки данных?
Вам не нужно запускать ЛЮБОЙ веб-интерфейс или вторичный уровень управления для управления вашими ключами (даже Userify) до тех пор, пока вы не станете достаточно большим, чтобы начать заниматься проблемами управления из-за большего количества пользователей и разных уровней авторизации на серверах или необходимости дополнительной поддержки ваших пользователей, которые могут не иметь знания или доступ к Ansible для обновления ключей. Сначала Userify представлял собой не более чем кучу сценариев оболочки (сегодня они, вероятно, были бы Ansible!), И в этом нет ничего плохого, пока вам не понадобится дополнительный контроль управления и простые способы для людей управлять / менять свои собственные ключи. (Конечно, пожалуйста, взгляните на Userify, если вы дойдете до этого!)
Как его обезопасить и не допустить, чтобы он превратился в «единую точку атаки»?
Ну, конечно, проверьте все ресурсы в сети, чтобы заблокировать вещи, но самое главное начните с надежного фундамента:
1. С самого начала создавайте свое решение с учетом требований безопасности. Выберите технологию (например, базу данных или языки), с которой традиционно было меньше проблем, а затем кодируйте с учетом безопасности. Дезинфицируйте все входящие данные, даже от доверенных пользователей. Паранойя - это добродетель.
2. В конце концов, все ломается. Сведите к минимуму ущерб, когда это произойдет: как вы уже указали, постарайтесь свести к минимуму обращение с секретным материалом.
3. Будьте проще. Не делайте новейших экзотических вещей, если вы не уверены, что это заметно и доказуемо повысит вашу безопасность. Например, мы выбрали X25519 / NaCl (libsodium) вместо AES для нашего уровня шифрования (мы шифруем все, в состоянии покоя и в движении), потому что он был первоначально разработан и написан кем-то, кому мы доверяли (DJB и др.), И был рассмотрен во всем мире. -известные исследователи, такие как Шнайер и команда безопасности Google. Используйте вещи, которые стремятся к простоте, если они более новые, поскольку простота затрудняет скрытие глубоких ошибок.
4. Соответствовать стандартам безопасности. Даже если вы не попадаете в режим безопасности, такой как PCI или HIPAA Security Rule, прочтите эти стандарты и выясните, как им соответствовать или, по крайней мере, очень жесткие компенсационные меры. Это поможет гарантировать, что вы действительно соблюдаете «лучшие практики».
5. Проведите внешнее / независимое тестирование на проникновение и запустите вознаграждение за обнаружение ошибок. чтобы убедиться, что вы постоянно следуете этим передовым методам. Все выглядит великолепно, пока к вам не присоединятся несколько умных и высокомотивированных людей ... как только это будет завершено, вы будете полностью уверены в своем решении.
Вопрос 2: ключи SSH. Какой лучший выбор: разрешить Ansible использовать пользователя root (с его открытым ключом, сохраненным в
~/.ssh/authorized_keys/ позволить пользователю Ansible запускать все команды через sudo с указанием пароля (уникальный пароль должен быть известен каждому системному администратору, использующему Ansible для управления этими серверами)
Старайтесь никогда не использовать пароли на серверах, даже для sudo. Это связано с секретами и в конечном итоге подорвет вашу безопасность (вы не можете очень легко менять этот пароль sudo между машинами, вы должны где-то его хранить, пароль означает, что вы действительно не можете выполнять автоматизацию между серверами, что является Кроме того, если вы оставите SSH по умолчанию, эти пароли могут быть перебором, что делает ключи несколько бессмысленными.Кроме того, избегайте использования пользователя root для любых целей, и особенно удаленного входа в систему.
Создайте непривилегированного пользователя, предназначенного для Ansible, с доступом sudo / позвольте пользователю Ansible запускать все команды через sudo без указания пароля
Именно. Непривилегированный пользователь, которого вы можете проверять обратно в анзибле с ролями sudo. В идеале создайте стандартного пользователя, выделенного для межсерверных / доступных коммуникаций с доступом sudo (без пароля).
... NB, если бы вы использовали Userify, я бы предложил создать пользователя Userify для ansible (вы также можете разбить это на проект или даже группу серверов, если у вас есть несколько машин управления ansible), сгенерировать ключ SSH на управляющем сервере и укажите его открытый ключ на странице профиля Userify. (Это текстовое поле по существу становится /home/ansible/.ssh/authorized_keys). Вы должны хранить системную учетную запись ansible отдельно от других межсерверных системных учетных записей, таких как учетная запись удаленного резервного копирования, управление секретами и т. Д. Затем пригласите своих людей, и они также смогут создавать и управлять своими собственными ключами, и все остается разделенным. Но, как и в случае блокировки сервера управления Ansible, попробуйте таким же образом заблокировать свой сервер Userify (или любое другое решение, которое вы развертываете).
какие-нибудь другие подсказки?
Я думаю, что вы определенно делаете это правильно и задаете правильные вопросы. Если вы хотите обсудить такие вещи, напишите мне (первая точка фамилия на userify), и я буду рад поболтать, независимо от того, в каком направлении вы в конечном итоге будете следовать. Удачи!
Хост-бастион (центр управления доступом) принадлежит отдельной подсети. Он не должен быть доступен напрямую извне, он не должен быть доступен напрямую из управляемые серверы!
Ваш ноутбук - наименее безопасное устройство из всех. Одно глупое письмо, одна глупая уязвимость во флеш-памяти, один глупый гостевой Wi-Fi, и он взломан.
Для серверов вообще не разрешайте root-доступ через ssh. Многие аудиторы над этим смеются.
Для возможности разрешите каждому администратору использовать свою личную учетную запись на каждом целевом сервере и разрешите им использовать sudo с паролями. Таким образом, два человека не используют общий пароль. Вы можете проверить, кто что делал на каждом сервере. Вам решать, разрешают ли личные учетные записи вход по паролю, только ключ ssh или требуется и то, и другое.
Чтобы уточнить ansible не требует использования единственного целевого логина. Каждый администратор может и должен иметь персональное целевое имя для входа.
Примечание: Старайтесь никогда не создавать учетную запись, называемую каким-либо словом (например, «ansible», «admin», «cluster», «management» или «operator»), если у нее есть пароль. Единственное хорошее имя для учетной записи с паролем - это имя человека, например, jkowalski. Только человек может нести ответственность за действия, совершенные через учетную запись, и ответственность за ненадлежащую защиту своего пароля, «анзибль» не может.
Ответ 1: управляющая машина
Немного и того и другого, вы можете использовать свой ноутбук для подключения к серверам через хост-бастион. что-то вроде:
Host private1
IdentityFile ~/.ssh/rsa_private_key
ProxyCommand ssh user@bastion -W %h:%p
Host bastion
IdentityFile ~/.ssh/bastion_rsa_key
Где у вас есть ключ для сервера-бастиона, а затем отдельный ключ для хоста, стоящего за ним. (лично я бы использовал gpg-agent / ssh-agent)
Ответ 2: аутентификация
Я не уверен, насколько "ansible" конкретные передовые практики отличаются от любых других передовых практик ssh-соединений. Но нет, вы хотите запускать ansible от имени себя, а не учетной записи службы и не учетной записи root.
Комбинация следующих аутентификаций:
Другие мысли:
Наконец, вы ничего не упомянули об окнах. Поэтому я могу только предположить, что вы этим не пользуетесь. Однако в этом случае я бы использовал опцию делегата, чтобы ваш ноутбук использовал хост-бастион (delegate_to: bastion.hostname.fqdn) и kerberos / winrm https с билетами kerberos.
Если вы его пропустили, лучшие методы вычислений, никогда ничего не делайте как root, всегда используйте именованные учетные записи