Продолжаем цикл статей про технологии Emer. Данная статья расскажет об инфраструктуре для управления терминальным доступом к узлам сети по протоколу ssh, emcSSH.
Цикл статей «Погружение в технологию блокчейн»
1. Серия материалов, посвященных технологии Emer:
1.1. Секреты EmerCoin.
1.2. Децентрализованная нецензурированная система доменных имён.
1.3. Инфраструктура публичных ключей всемирного масштаба.
1.4. Loading…
2. Быстрые и безопасные транзакции.
3. Экосистема цифровой стоматологии.
4. Loading…
Введение
Как было рассказано в предыдущих статьях, главной утилитарной особенностью сети Emer является Name-Value Storage (NVS) – распределённое доверенное хранилище записей любого вида.
И если вы помещаете в NVS некую запись, то можно быть уверенным в том, что:
- Данная запись будет распространена на все узлы сети, то есть каждый узел будет иметь в своём локальном блокчейне её копию.
- Доверие к конкретной записи, как и всему блокчейну создаётся посредством консолидированных усилий майнеров POW и POS.
Иными словами, можно быть уверенным, что запись, помещённая в блокчейн, будет доступна всем участникам сети, и у всех она будет одинакова и именно такая, какой вы её внесли, и никто «по дороге» не подменил эту запись, как в сказке Пушкина: «и в суму его пустую, кладут грамоту другую».
Учитывая также, что Emer неограниченно масштабируется, возникает возможность сделать на базе сервиса Emer NVS эффективную инфраструктуру публичных ключей PKI (Public Key Infrastructure) всемирного масштаба.
Ниже вы узнаете как раз о такой инфраструктуре для управления терминальным доступом к узлам сети по протоколу ssh, emcSSH.
Как всё работает без emcSSH
В большинстве случаев, для логина на серверы сети по ssh используется классическое решение аутентификации – пароль, который пользователь предъявляет серверу при логине. Парольная аутентификация обладает рядом недостатков, таких как возможность подобрать или выманить пароль, и продвинутые пользователи используют аутентификацию по публичному ключу, по которому сервер идентифицирует клиентов.
В небольших сетях применяют простейшее решение, когда публичные ключи размещаются в статическом файле (обычно $HOME/.ssh/authorized_keys) на том или ином сервере. Однако, по мере роста размера сети, поддержка актуальности списка ключей на самых разных машинах превращается в головную боль администратора. Например, при увольнении некоего человека, администратор должен обойти все компьютеры, в которые тот имел доступ, и безошибочно удалить соответствующую запись из каждого файла. Такой подход оправдывает себя в сети из пяти компьютеров, но уже практически не применим в сети из пятидесяти.
В более-менее крупных сетях (масштаба предприятия, enterprise-level) применяется централизованное управление как ключами доступа пользователей, так и группами пользователей, которые имеют те или иные привилегии. Обычно такие системы делаются на базе программных продуктов Puppet, LDAP/Kerberos, и им подобных. Такая централизованная система уже более управляема, чем набор файлов, разбросанных по различным серверам. Но тем не менее, она имеет ряд недостатков:
- Необходимость разворачивания, настройки и администрирования инфраструктуры PKI – центрального сервера ключей, серверов домен-контролеров, создания баз данных и правил репликации на контроллерах, системы безопасности каналов обновления, системы безопасности запросов авторизации, и много подобной работы.
- Централизация такой системы даёт администратору практически неограниченные полномочия, то есть наделяет администратора «режимом бога», где он имеет возможность скомпрометировать любые учётные записи любых пользователей (да хоть и всех сразу), или ввести в систему фиктивных псевдо-пользователей, делая от их имени всякое. И возникает архиважный вопрос – как сторожить сторожа?
- Захват контроля над центром управления ключами приведёт к компрометации либо параличу всей сети. Иными словами, цена потерь при компрометации огромна.
- Обновление ключей пользователей происходит посредством администратора. То есть пользователю для смены ключа требуется связаться с администратором, идентифицировать себя, передать ему ключ, а тот уже внесёт ключ в централизованную систему. Этот процесс напоминает телефонные коммутации столетней давности вроде «алё, барышня, дайте Смольный».
- Ограничения роста такой системы уровнем масштаба предприятия (enterprise level). Кроме технических, когда сложно представить поддержку базы LDAP на сотни тысяч домен-контроллеров сети уровня страны или общемирового масштаба, есть ещё и проблема ограничения доверия – так, админ базы безопасности предприятия вряд ли допустит админа другого произвольного предприятия к модификации этой базы. Это уже привело к тому, что люди просто не представляют себе системы PKI уровня выше чем enterprise. Хотя, казалось бы, перед глазами каждый день – пример работающей всемирной сети, Интернет!
Как работает emcSSH
Технически, система PKI всемирного масштаба emcSSH устроена очень просто. Простота же обусловлена тем фактом, что почти всю работу выполняет Emer NVS. Программа emcssh является всего лишь «мостом» между блокчейном Emer и сервером sshd, которая интерпретирует соответствующие NVS-записи из блокчейна и формирует для sshd список публичных ключей той или иной учётной записи. Согласно спецификации, NVS-запись состоит из Name (поискового ключа) и Value (данных, связанных с ключом).
Записи NVS (Name, Value) для сервиса emcssh имеют префикс Name “ssh:” и подчиняются следующим формальным правилам:
username, groupname, ssh_public_key ::= VisibleString name_key ::= <username> | <groupname> token ::= <ssh_public_key> | ”@”<name_key> Name ::= ”ssh:”<name_key> Value ::= <token> | <token>“|”<Value>Записи вносятся в NVS либо вручную, через GUI кошелька, либо посредством команд JSON RPC API.
Рассмотрим создание записей для emcssh на примерах, пошагово:
1. Конечные пользователи размещают в Emer NVS свои публичные ключи в записях вида:
Name=ssh:username Value=ssh_public_keyНапример:
"name" : "ssh:emergator", "value" : "ssh-rsa AAAAB3…”.Так как имя уникально в пределах сети Emer, то оно однозначно идентифицирует владельца публичного ключа.
2. Администратор группы доступа к ресурсу может создать ACL (access control list, список контроля доступа) для некоей группы пользователей, создав список из ссылок на username пользователей, то есть запись вида:
Name=ssh:groupname Value=@usename1|@username2|...|@usernameNНапример:
"name" : "ssh:EmercoinTeam", "value" : "@EvgenijM86|@Garrett|@emergator|@denis|@sv",3. Администратор группы может включить в ACL не только ссылки на пользователей, но и ссылки на другие группы, например:
Name=ssh:super_group Value=@usename1|@username2|@EmercoinGroupГруппы по ссылке также могут содержать ссылки на другие группы, создавая таким образом иерархию групп и пользователей. Причём следует заметить, что владельцы записей о группах и пользователях могут быть самыми разными людьми, работающими в разных организациях. То есть каждый управляет своими записями, в своей зоне ответственности, а блокчейн создаёт иерархию посредством ссылок между записями.
Теперь, когда записи созданы, в дело вступает программа emcssh. При попытке логина очередного пришедшего, сервер sshd запускает программу emcssh, передавая ей в качестве параметра username. Программа для данного username извлекает из конфигурации соответствующего пользователя ссылки на name_key(s) в блокчейне, и рекурсивно, посредством цепочки запросов в блокчейн, «распаковывая» эти ключи, формирует список ssh-ключей для данной учётной записи, который и передаёт программе sshd. А та уже в свою очередь авторизует приходимца или отвергает его.
При формировании списка ssh-ключей программа кеширует список уже обработанных name_key, и при повторной встрече не обрабатывает ранее обработанные ключи. Это защищает систему от бесконечной рекурсии (в том числе и непрямой), а также позволяет корректно разрешать «ромбовидное наследование», когда некая группа ссылается на другие группы, а те в свою очередь ссылаются на третью. В этом случае третья группа будет обработана единожды, и проигнорирована при обработке второй ветви ромба.
Например, если в конфигурации сервера для некой учётной записи будет стоять ссылка «@EmercoinTeam», то программа emcssh по этой ссылке извлечёт из блокчейна соответствующую группу «@EvgenijM86|@Garrett|@emergator|@denis|@sv», а потом тут же разрешит каждую ссылку из группы в индивидуальный публичный ключ, и таким образом, сформирует список из пяти публичных ключей.
Преимущества emcSSH
Казалось бы – велика ли разница, когда вместо собственно публичного ключа на сервере мы храним только ссылку на него, а сам ключ извлекаем из какого-то блочейна? Но на самом деле, разница есть, и она огромна. И проистекает она из того факта, что связью между username и ключом управляет хозяин имени username, а использованием username и соответствующего ключа управляет ответственный за сервер, на который происходит логин. И, например, в случае необходимости замены ключа, хозяин username на своей стороне генерирует новый ключ (ssh_public_key) и публикует его в NVS. После этого обновлённая запись реплицируется по всем узлам сети, и её достоверность подтверждается публичным консенсусом криптовалюты. Администратору сервера уже нет дела до того, что ключ был обновлён хозяином. Причём это обновление ключа автоматически произойдёт во всех серверах, куда имеет доступ наш username, без участия каких-либо администраторов или операторов-людей. Возвращаясь к аналогии с телефонной сетью, можно сказать, что вместо человека-оператора «алё, дайте Смольный», стала применяться система автоматического набора номера.
Аналогичные рассуждения можно привести для ACL, управляемым groupname. Например, если ваша компания решила дать доступ в какой-то аккаунт для EmercoinTeam, то админ компании просто прописывает ссылку на группу у себя. А уже содержимым группы управляет не админ вашей компании, а админ Emercoin. И если в Emercoin произошли какие-то кадровые перестановки – то это не дело админа вашей компании, а дело админа Emercoin, который и поддерживает актуальность данной группы.
Учитывая, что в современном бизнесе расширяется тенденция отдавать на аутсорс IT, бухгалтерию, телефонию, аудит и тому подобное – emcSH становится эффективным средством обеспечения межкорпоративного взаимодействия. Компания-аутсорсер управляет своими группами, в том числе и иерархическими. Пользователи управляют своими ключами. А компания-заказчик разрешает доступ соответствующим группам, и у её админа не болит голова о том, что и как происходит у аутсорсера.
Рассмотренное выше разделение полномочий (локализация ответственности) позволяет организовать масштабную групповую работу без централизации привилегий и ввода роли супер-админа, ответственного за всё.
Перечислим кратко основные преимущества emcSSH:
- локализация полномочий, и повышенная безопасность как следствие;
- удобство администрирования;
- автоматическое обновление ключей и групп без участия админа;
- удобство пользования;
- снижение цены на инфраструктуру и её администрирование;
- возможность создавать сквозное доверие между распределенными участниками.
Полезные ссылки
1. Всё программное обеспечение – как узел Emer, так и emcssh являются Open Source Freeware, распространяемым под GNU/BSD лицензиями. Исходные тексты доступны на GitHub, откуда их можно скачать, проанализировать и собрать.
2. Управление ключами и группами удобнее всего производить через GUI QT кошелёк.
3. Для серверов существуют пре-компилированные сборки для основных версий Linux, которые устанавливаются менеджерами пакетов. Также есть возможность развернуть узел Emer c предустановленным emcSSH и другими сервисами в Microsoft Azure.
4. Под FreeBSD и другие ОС сборка из исходников также не является проблемой, и занимает несколько минут.
5. Дистрибутив, man-pages и руководство по сборке доступны на странице emcSSH.
6. Пошаговая русскоязычная инструкция с картинками.
7. Внесение записей в Emer NVS платное, и требует некоего количества EmerCoins, которые «сжигаются» при создании записи. Цена невысока, примерно $0.05 по текущему курсу за 10-летнюю запись, но монеты где-то брать всё-таки надо. Их можно приобрести на какой-либо криптобирже из списка, например Livecoin.
8. Пообщаться с разработчиками можно по
.
Для безопасной эксплуатации сети emcSSH не позволяйте записи истечь. Резервируйте запись на длительный срок (хоть и 1000 лет), и продлевайте по мере необходимости.
Опыт практического использования
Система emcSSH уже около двух лет используется группой разработчиков EmerCoin для управления распределённой облачной инфраструктурой и VPS-ами, и показала себя соответствующей предъявляемым требованиям и ожиданиям.
Также компания HashCoin более года успешно использует эту систему для управления массивами майнеров и распределёнными датацентрами. Интервью CTO компании об опыте эксплуатации системы здесь.
Расширения
Система emcSSH в качестве ssh_public_key может «доставлять до потребителя» не только публичный ключ ssh, а произвольную текстовую строку. Это открывает возможность использовать emcSSH для создания распределённых ACLs для других сервисов, с ssh не связанных.
Например, компания HashCoin предложила использование emcSSH для управления списками доступа на сайт посредством сервиса emcSSL.
Подробнее об emcSSL и этом применении будет рассказано в следующих статьях.
Об авторе
Олег Ховайко – ведущий разработчик криптовалюты «EmerCoin», эксперт в области криптографии и компьютерной безопасности. С 1994 года работает в IT-сфере. В настоящий момент также является вице-президентом американского инвестиционного банка, производящего операции с ценными бумагами – Jefferies & Company. Который считается одним из крупнейших независимых банков США.
ссылка на оригинал статьи https://habrahabr.ru/post/316326/
Добавить комментарий