Под капотом Emercoin. Часть 3. emcSSH. Инфраструктура публичных ключей всемирного масштаба

Продолжаем цикл статей про технологии Emer (Часть 1, Часть 2). Как было рассказано в предыдущих статьях, главной утилитарной особенностью сети Emer является NVS – Name-Value Storage – распределённое доверенное хранилище записей любого вида.

Под капотом Emercoin. Часть 3. emcSSH. Инфраструктура публичных ключей всемирного масштаба

И если я помещаю в 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:

  • Локализация полномочий, и повышенная безопасность как следствие
  • Удобство администрирования
  • Автоматическое обновление ключей и групп без участия админа
  • Удобство пользования
  • Снижение цены на инфраструктуру и её администрирование
  • Возможность создавать сквозное доверие между распределенными участниками

Как начать пользоваться

Всё программное обеспечение – как узел Emer, так и emcssh являются Open Source Freeware, распространяемым под GNU/BSD лицензиями. Исходные тексты доступны на github, откуда их можно скачать, проанализировать и собрать.

Управление ключами и группами удобнее всего производить через GUI QT кошелёк, доступный для скачивания тут.

Для серверов имеются пре-компилированные сборки для основных версий Linux, которые устанавливаются менеджерами пакетов. Также имеется возможность развернуть узел Emer c предустановленным emcSSH и другими сервисами в MS Azure. Подробности здесь.

Под FreeBSD и другие ОС сборка из исходников также не является проблемой, и занимает несколько минут.

Дистрибутив, man-pages и руководство по сборке доступны на странице emcSSH.

Также имеется пошаговая русскоязычная инструкция с картинками.

Внесение записей в Emer NVS платное, и требует некоего количества EmerCoins, которые «сжигаются» при создании записи. Цена невысока, примерно $0.05 по текущему курсу за 10-летнюю запись, но монеты где-то брать всё-таки надо. Их можно приобрести на какой-либо криптобирже из списка, например Livecoin. Или же можно обратиться к разработчикам [email protected], которые рады помочь хорошим людям в разумных пределах.

Внимание!

Для безопасной эксплуатации сети emcSSH не позволяйте записи истечь. Резервируйте запись на длительный срок (хоть и 1000 лет), и продляйте по мере необходимости.

Опыт практического использования

Система emcSSH уже около двух лет используется группой разработчиков EmerCoin для управления распределённой облачной инфраструктурой и VPS-ами, и показала себя соответствующей предъявляемым требованиям и ожиданиям.

Также компания HashCoins более года успешно использует эту систему для управления массивами майнеров и распределёнными датацентрами. C интервью CTO компании об опыте эксплуатации этот системы можно ознакомиться здесь.

Расширения

Система emcSSH в качестве ssh_public_key может «доставлять до потребителя» не только публичный ключ ssh, а произвольную текстовую строку. Это открывает возможность использовать emcSSH для создания распределённых ACLs для других сервисов, с ssh не связанных.

Например, компания HashCoin предложила использование emcSSH для управления списками доступа на сайт посредством сервиса emcSSL.
Подробнее об emcSSL и этом применении будет рассказано в следующих статьях.

Категория: 
Криптовалюты
10
Средняя: 10 (1 оценка)
0
Ваша оценка: Нет
3000 / 0
Аватар пользователя admin
Публикацию добавил: admin
Дата публикации: вт, 11/29/2016 - 10:57

Что еще почитать:

Комментарии:

Аватар пользователя Neodim

Neodim

Спасибо! Теперь стало намного понятней с чем его едят!

вт, 11/29/2016 - 12:51

Аватар пользователя Узда Афанасий

Узда Афанасий

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

вс, 12/04/2016 - 12:09

Аватар пользователя admin

admin

Спасибо за предложение. Сделаю при первой возможности.

пн, 12/05/2016 - 00:46

Аватар пользователя Алекс

Алекс

Присоединяюсь к предложению. Вставьте макрос на главной )

вт, 12/06/2016 - 19:54

Аватар пользователя admin

admin

Готово

ср, 12/07/2016 - 13:32

Добавить комментарий