Безопасность, когда закрытые ключи SSH потеряны
Общий хостинг (т.е. $8/месяцев и т.п.) почти наверняка не стоит того; минута, которую Вы сделали, чтобы разработчик провел 30 минут их времени, изучая и решая проблему, связанную с тем, что она совместно используется и на дрянной, перепроданной машине, Вы, возможно, заплатили за лучшую.
Выше опции за $8/месяцев существует три опции рассмотреть:
- VPS ("виртуальные частные серверы")
- Выделенный сервер
- Облако
Кроме того, необходимо также рассмотреть, в каком уровне поддержки Вы нуждаетесь. Ваши разработчики *, ОТКЛОНЯЮТ и гуру PostgreSQL? Даже если они, который является лучшим использованием их времени?
С точки зрения масштабирования выделенные серверы выходят на более высокий уровень лучше всего - и прежде чем я получу downvotes для того, чтобы сказать, что, позвольте мне объяснить почему. Выполнение PostgreSQL означает, что масштабирование слоя базы данных лучше всего сделано вертикально; то есть, путем добавления большего количества RAM и быстрого процессора. Это относительно трудно, по сравнению с MySQL, по крайней мере, для масштабирования горизонтально (на дополнительные серверы), требуя вещей как объединение и many-many репликация. Проблема - то, что центральные процессоры облаков не все настолько быстро. Для именования один абсолют, большая часть скорости ЦП, которую можно сжать из EC2 Amazon, идет с их предложениями высокого ЦП, которые составляют 2,5 ЭКЮ ЗА ПРОЦЕССОР. Это нигде не около производительности современного ЦП, что Вы вошли бы в новую выделенную машину - каждый процессор делает приблизительно 4,600 BogoMIPS, минус штрафы виртуализации, по сравнению с хорошо более чем 6 500 даже для типичного современного ЦП. VPS поставит Вам полные 6,500 или больше, хотя все еще со связанными с виртуализацией потерями производительности. Выделенная машина даст Вам каждый цикл, который она имеет. Этот избыток скорости также означает, что можно консолидировать сеть и DB на единственной машине, пока Вы не перерастаете его.
Если Вы будете знать с начала, то Вам будет нужно разделение на стороне заядлого веб-пользователя, облака дают Вам способность масштабироваться горизонтально очень быстро (несколько секунд), VPS меньше (несколько минут, до часа или так), и выделенные серверы, наименьшее количество (где угодно от нескольких часов до недели или дольше). С другой стороны, тем не менее, Вы "заполните" облачного заядлого веб-пользователя вполне быстро, потому что они являются настолько маленькими, тогда как специализированный заядлый веб-пользователь имеет производительность нескольких дюжин облачных и наблюдение, что это заполниться будет видимо хорошо в будущем, таким образом, можно будет запланировать соответственно.
Одна последняя вещь рассмотреть: цена. Теперь, я уверен, что Вы уже смотрите на цену, но что я думаю, основанная на использовании оценка. VPS и выделенные серверы будут обычно только обвинять Вас за пропускную способность, и это прибывает в значительные блоки. Облака обвинят Вас за каждый последний ресурс, который Вы используете. VPS и выделенные серверы поэтому имеют предсказуемые счета в конце месяца; облако, особенно динамично масштабирующееся, может стоить Вам тысяч или десятков тысяч долларов, если Вы получаете DDoSed, например.
Какую версию sshd вы используете? OpenSSH 5.4, по-видимому, имеет возможность отзыва ключа:
* Add the ability to revoke keys in sshd(8) and ssh(1). User keys may
be revoked using a new sshd_config(5) option "RevokedKeys". Host keys
are revoked through known_hosts (details in the sshd(8) man page).
Revoked keys cannot be used for user or host authentication and will
trigger a warning if used.
Если вы используете более раннюю версию, вам, вероятно, придется просмотреть все возможные файлы authorized_keys на всех ваших серверах, чтобы найти и удалить подозрительный открытый ключ. Это будет включать любую учетную запись, в которую пользователь-A может использовать ssh, включая root. Это предполагает, что вы не используете централизованное управление authoried_key.
И в OpenSSH, и в Putty вы можете регенерировать открытый ключ из закрытого ключа, но не наоборот.
Используйте ssh-keygen -y -f filename
В PuttyGen импортируйте ключ, и он покажет вам открытый ключ.
Если это ключ пользователя (как кажется), то он будет расположен в файле authorized_keys для идентификаторов пользователей, к которым у пользователя был доступ. Вам нужно будет выполнить поиск в подкаталоге .ssh домашних каталогов. (Если у вас есть автоматически смонтированные домашние каталоги, вам нужно выполнить поиск только в каталоге на одном сервере; в противном случае вам нужно будет выполнить поиск на всех серверах, к которым они могли иметь доступ.)
Проблема будет в поиске первой копии старого ключа. Домашний каталог пользователя в часто используемых системах будет хорошим местом для начала. Получив ключ, вы можете найти его в других системах и с идентификаторами пользователей. Поиск по значению ключа, а не по комментарию, с большей вероятностью найдет все ключи.
Одним из возможных краткосрочных исправлений этой ситуации является использование некоторого инструмента управления конфигурацией (asible может быть хорошей ставкой здесь).
В частности, вы можете использовать authorized_key модуль (https://docs.ansible.com/ansible/authorized_key_module.html) для удаления одного (или нескольких) специфических отпечатков пальцев с открытым ключом из файла авторизованных_ключей данного пользователя.
Пример для ваших нужд отсутствует, но что-то подобное может сработать:
- name: Set authorized key took from url
authorized_key:
user: charlie
state: absent
key: https://github.com/charlie.keys
Вы также можете (по крайней мере, в допустимом варианте) выполнить команду для создания списка всех пользователей в системе, запросив /etc/passwd.
Вы также можете просто создать свежий белый список ключей и удалить все остальное, но это может быть непрактично в вашей ситуации.
Доступные документы дают пример того, как это может работать:
- name: Set authorized key, removing all the authorized key already set
authorized_key:
user: root
key: '{{ item }}'
state: present
exclusive: True
with_file:
- public_keys/doe-jane
В долгосрочной перспективе, вы можете подумать о том, чтобы иметь jumphosts - я нашел телепорт довольно неплохим.
.как мне вспомнить открытый ключ, связанный с этим закрытым ключом.
Хотя отзыв SSH ключей, конечно, неплохая идея, лучшим (или более масштабируемым) решением является реализация MFA (многофакторный аутентификатор, он же "двухфакторная аутентификация"). Это приводит к девальвации ключа, поскольку пользователь не может войти в систему, если он не удовлетворяет (1) дополнительному фактору.
Существует пара решений с открытым исходным кодом, таких как Google Authenticator и Oath. Затем гибридное решение с открытым исходным кодом / коммерческое решение типа Duo. С Duo, вы даже можете войти в систему через геозон и получать уведомления.
Для реализации 100% работоспособного примера, обратите внимание на этот бастион, реализованный в виде контейнера Docker: https://github.com/cloudposse/bastion