> Вопрос 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 без указания пароля
В точку. Непривилегированный пользователь, которого вы можете проверить обратно в ansible с помощью ролей sudo. В идеале, создать стандартного пользователя, предназначенного для межсерверной / ансильной связи с доступом sudo (без пароля).
... NB. Если бы вы использовали Userify, я бы предложил создать пользователя Userify для ansible (вы также можете разбить его по проектам или даже по группе серверов, если у вас есть несколько компьютеров управления ansible), сгенерировать SSH-ключ на управляющем сервере и предоставьте его открытый ключ на странице профиля Userify. (Это текстовое поле по сути становится /home/ansible/.ssh/authorized_keys). Вы должны держать ответную системную учетную запись отдельно от других системных серверных учетных записей, таких как удаленная резервная учетная запись, секретное управление и т. Д. Затем пригласите своих людей, и они также смогут создавать свои собственные ключи и управлять ими, и все останется разделенным. Но, как и при блокировке сервера управления Ansible, попробуйте заблокировать сервер Userify (или любое другое решение, которое вы развернете) таким же образом.
какие-нибудь другие намеки?
Я думаю, вы определенно поступите правильно и зададите правильные вопросы. Если вы хотите обсудить подобные вещи, напишите мне (первая точка фамилия на userify), и я был бы рад поболтать, независимо от того, в каком направлении вы в конечном итоге будете следовать. Удачи!