Занурення в технологію блокчейн: Інфраструктура публічних ключів всесвітнього масштабу

Продовжуємо цикл статей про технології 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. Управління ключами і групами зручніше за все робити через QT GUI гаманець.
3. Для серверів існують пре-компільовані збірки для основних версій Linux, які встановлюються менеджери пакетів. Також є можливість розгорнути вузол Emer c встановленим emcSSH та іншими сервісами Microsoft Azure.
4. Під FreeBSD і інші ОС збірка з исходников також не є проблемою, і займає кілька хвилин.
5. Дистрибутив, man-pages керівництво по збірці доступні на сторінці emcSSH.
6. Покрокова російськомовна инструкция з картинками.
7. Внесення записів до Emer NVS платне, і вимагає певної кількості EmerCoins, які «спалюються» при створенні запису. Ціна невисока, приблизно $0.05 за поточним курсом за 10-річну запис, але монети де-то брати все-таки треба. Їх можна придбати на який-небудь криптобирже з список, наприклад Livecoin.
8. Поспілкуватися з розробниками можна поштоюteam@emercoin.com.

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

Досвід практичного використання
Система emcSSH вже близько двох років використовується групою розробників EmerCoin для керування розподіленою хмарної інфраструктурою і VPS-ами, і показала себе відповідної вимогам і очікуванням.

Також компанія HashCoin більше року успішно використовують цю систему для управління масивами майнер і розподіленими датацентрами. Інтерв'ю CTO компанії про досвід експлуатації системи здесь.

Розширення
Система emcSSH як
ssh_public_key
може «доставляти до споживача» не тільки публічний ключ ssh, а довільну текстову рядок. Це відкриває можливість використовувати emcSSH для створення розподілених ACLs для інших сервісів, з ssh не пов'язаних.

Наприклад, компанія HashCoin запропонувала використання emcSSH для керування списками доступу на сайті за допомогою сервісу emcSSL.

Детальніше про emcSSL і це застосуванні буде розказано в наступних статтях.

Про автора

Олег Ховайко – провідний розробник кріптовалюти «EmerCoin», експерт в області криптографії та комп'ютерної безпеки. З 1994 року працює в IT-сфері. У даний момент також є віце-президентом американського інвестиційного банку, проводить операції з цінними паперами – Jefferies & Company. Який вважається одним з найбільших незалежних банків США.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.