🥇Двухфактарная аўтэнтыфікацыя на сайце з выкарыстаннем USB-токена. Цяпер і для Linux

В адной з нашых папярэдніх артыкулаў мы расказвалі пра важнасць двухфактарнай аўтэнтыфікацыі на карпаратыўных парталах кампаній. У мінулы раз мы прадэманстравалі, як наладзіць бяспечную аўтэнтыфікацыю ў web-серверы IIS.

У каментарах нас прасілі напісаць інструкцыю для самых распаўсюджаных web-сервераў пад Linux – nginx і Apache.

Вы прасілі - мы напісалі.

Што трэба, каб пачаць?

Любы сучасны дыстрыбутыў Linux. Я выконваў тэставую наладу ў MX Linux 18.2_x64. Гэта вядома не серверны дыстрыбутыў, але для Debian ці наўрад будуць нейкія адрозненні. Для іншых дыстрыбутываў могуць злёгку адрознівацца шляхі да бібліятэкканфігаў.
Токен. Мы працягваем выкарыстоўваць мадэль Рутокен ЭЛП PKI, якая ідэальна падыходзіць па хуткасных характарыстыках для карпаратыўнага прымянення.
Для працы з токенам у Linux неабходна ўсталяваць наступныя пакеты:
libccid libpcsclite1 pcscd pcsc-tools opensc

Выпісванне сертыфікатаў

У папярэдніх артыкулах мы абапіраліся на тое, што сертыфікаты сервера і кліентаў будуць выпісвацца з дапамогай Microsoft CA. Але раз ужо мы наладжваем усё ў Linux, то заадно распавядзем пра альтэрнатыўны спосаб выпісвання гэтых сертыфікатаў - не пакідаючы Linux.
У якасці CA будзем выкарыстоўваць XCA (https://hohnstaedt.de/xca/), які даступны ў любым сучасным дыстрыбутыве Linux. Усе дзеянні, якія мы будзем здзяйсняць у XCA можна зрабіць і ў рэжыме каманднага радка з дапамогай утыліт OpenSSL і pkcs11-tool, але для большай прастаты і навочнасці ў гэтым артыкуле мы іх прыводзіць не будзем.

Пачатак працы

Усталёўваны:
```
$ apt-get install xca
```
І запускаем:
```
$ xca
```
Ствараем нашу базу дадзеных для CA - /root/CA.xdb
Мы рэкамендуем захоўваць базу дадзеных Certificate Authority у тэчцы, куды ёсць доступ толькі ў адміністратара. Гэта важна для абароны зачыненых ключоў каранёвых сертыфікатаў, якія выкарыстоўваюцца для падпісвання ўсіх астатніх сертыфікатаў.

Ствараем ключы і сертыфікат root CA

У аснове інфраструктуры адчыненых ключоў (PKI) ляжыць іерархічная сістэма. Галоўным у гэтай сістэме з'яўляецца каранёвы цэнтр сертыфікацыі ці root CA. Яго сертыфікат і трэба стварыць у першую чаргу.

Ствараем для CA зачынены ключ RSA-2048. Для гэтага на ўкладцы Прыватныя ключы націскаем Новы ключ і выбіраемы адпаведны тып.
Задаем імя для новай ключавой пары. Я яе назваў - CA Key.
Выпісваем сам сертыфікат CA, з выкарыстаннем створанай ключавой пары. Для гэтага пераходзім на ўкладку сертыфікаты і націскаем Новы сертыфікат.
Абавязкова выбіраемы SHA-256, таму што выкарыстанне SHA-1 ужо не можа лічыцца бяспечным.
У якасці шаблону абавязкова выбіраемы [default] CA. Не забудзьцеся націснуць на Apply all, інакш шаблон не прымяняецца.
на ўкладцы Прадмет выбіраемы нашу ключавую пару. Там жа вы можаце запоўніць усе асноўныя палі сертыфіката.

Ствараем ключы і сертыфікат https-сервера

Аналагічнай выявай ствараем для сервера зачынены ключ RSA-2048, я яго назваў — Server Key.
Пры стварэнні сертыфіката выбіраемы, што сертыфікат сервера неабходна падпісаць на сертыфікаце CA.
Не забываем абраць SHA-256.
У якасці шаблону выбіраемы [default] HTTPS_server. Ціснем на Apply all.
Пасля чаго на ўкладцы Прадмет выбіраем наш ключ і запаўняем патрэбныя палі.

Ствараем ключы і сертыфікат для карыстальніка

Закрыты ключ карыстальніка будзе захоўвацца на нашым токене. Для працы з ім неабходна ўсталяваць бібліятэку PKCS#11 з нашага сайта. Для папулярных дыстрыбутываў мы распаўсюджваем гатовыя пакеты, якія ляжаць тут. https://www.rutoken.ru/support/download/pkcs/. У нас таксама ёсць зборкі для arm64, armv7el, armv7hf, e2k, mipso32el, якія можна ўзяць у нашым SDK https://www.rutoken.ru/developers/sdk/. Акрамя зборак для linux таксама ёсць зборкі для macOS, freebsd і android.
Дадаем новы PKCS#11 Provider у XCA. Для гэтага ідзем у меню опцыі на ўкладку PKCS#11 Provider.
Ціснем Дадаваць і выбіраемы шлях да бібліятэкі PKCS#11. У маім выпадку гэта usrliblibrtpkcs11ecp.so.
Нам спатрэбіцца адфарматаваны токен Рутокен ЭЛП PKI. Спампоўваем утыліту rtAdmin https://dev.rutoken.ru/pages/viewpage.action?pageId=7995615

Выконваем

$ rtAdmin -f -q -z /usr/lib/librtpkcs11ecp.so -u <PIN-код пользователя>

У якасці тыпу ключа выбіраемы - ключ RSA-2048 на Рутокен ЭЛП PKI. Я назваў гэты ключ Client Key.
Уводзім PIN-код. І чакаем завяршэння апаратнай генерацыі ключавой пары
Сертыфікат для карыстальніка ствараем па аналогіі з сертыфікатам сервера. На гэты раз выбіраемы шаблон [default] HTTPS_client і не забываем націснуць Apply all.
на ўкладцы Прадмет уводзім інфармацыю аб карыстальніку. На запыт аб захаванні сертыфіката на токен адказваем сцвярджальна.

У выніку на ўкладцы Сертыфікаты у XCA павінна атрымацца прыкладна такая карцінка.

Гэтага мінімальнага набору ключоў і сертыфікатаў дастаткова для таго, каб прыступаць да налады непасрэдна сервераў.

Для настройкі нам неабходна выканаць экспарт сертыфіката УЦ, сертыфіката сервера і закрытага ключа сервера.

Для гэтага трэба абраць патрэбны запіс на якая адпавядае ўкладцы ў XCA і націснуць Экспарт.

Nginx

Як усталяваць і запусціць nginx-сервер, пісаць не буду - на гэтую тэму дастаткова артыкулаў у інтэрнэце, не кажучы ўжо аб афіцыйнай дакументацыі. Прыступім адразу да налады HTTPS і двухфактарнай аўтэнтыфікацыі па токене.

Дадаем у секцыю server у nginx.conf наступныя радкі:

server {
	listen 443 ssl;
	ssl_verify_depth 1;
	ssl_certificate /etc/nginx/Server.crt;
	ssl_certificate_key /etc/nginx/ServerKey.pem;
	ssl_client_certificate /etc/nginx/CA.crt;
	ssl_verify_client on;
}

Падрабязнае апісанне ўсіх параметраў, якія тычацца налады ssl у nginx можна знайсці тут. https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

Я толькі сцісла апішу тыя, якія сам задаў:

ssl_verify_client - паказвае, што неабходна праверыць ланцужок даверу да сертыфіката.
ssl_verify_depth - вызначае глыбіню пошуку даверанага каранёвага сертыфіката ў ланцужку. Так як у нас сертыфікат кліента адразу падпісаны на каранёвым сертыфікаце, то і глыбіня зададзена - 1. Калі сертыфікат карыстальніка падпісваецца на прамежкавым CA, то ў гэтым параметры неабходна ўказаць 2, і гэтак далей.
ssl_client_certificate - паказвае шлях да даверанага каранёвага сертыфіката, які выкарыстоўваецца пры праверцы даверу да сертыфіката карыстальніка.
ssl_certificate/ssl_certificate_key - паказваюць шлях да сертыфіката/закрытага ключа сервера.

Не забываем выканаць nginx -t, каб праверыць, што ў канфігу няма памылак друку, а ўсе файлікі ляжаць дзе трэба і гэтак далей.

І ўласна ўсё! Як бачыце настройка вельмі простая.

Правяраем працу ў Firefox

Раз ужо мы ўсё цалкам які робіцца ў Linux, то будзем лічыць, што і нашы карыстачы таксама працуюць у Linux (калі ў іх Windows, то глядзіце інструкцыю па наладзе браўзэраў у папярэднім артыкуле.

Запускаем Firefox.
Паспрабуем спачатку зайсці без токена. Атрымліваем вось такі малюнак:
заходзім на about: налады # канфідэнцыяльнасць, і ідзем у Security Devices…
Ціснем Нагрузка, каб дадаць новы PKCS#11 Device Driver і паказваем шлях да нашай librtpkcs11ecp.so.
Для праверкі таго, што сертыфікат бачыцца можна зайсці ў Менеджэр сертыфікатаў. З'явіцца запыт на ўвод PIN-кода. Пасля карэктнага ўводу можна праверыць, што на ўкладцы Your Certificates з'явіўся наш сертыфікат з токена.
Цяпер заходзім з такенам. Firefox прапануе абраць сертыфікат, які будзе абраны на сервер. Выбіраемы наш сертыфікат.
PROFIT!

Настройка выконваецца адзін раз, і як бачна ў акне запыту на сертыфікат мы можам захаваць наш выбар. Пасля гэтага пры кожным уваходзе на партал нам трэба будзе толькі ўставіць токен і ўвесці PIN-код карыстальніка, які быў зададзены пры фарматаванні. Пасля такой аўтэнтыфікацыі сервер ужо ведае які карыстач на яго зайшоў і мага больш не рабіць ніякіх дадатковых вокнаў для праверкі, а адразу пускаць карыстача ў яго асабісты кабінет.

Апач

Гэтак жа як і з nginx праблем з усталёўкай apache ні ў каго не павінна паўстаць. Калі ж вы не ведаеце, як усталяваць гэты web-сервер, проста карыстайцеся афіцыйнай дакументацыяй.

А мы прыступаем да наладкі нашага HTTPS і двухфактарнай аўтэнтыфікацыі:

Для пачатку неабходна актываваць mod_ssl:
```
$ a2enmod ssl
```
А затым уключыць наладкі HTTPS сайта па змаўчанні:
```
$ a2ensite default-ssl
```
Цяпер рэдагуем файл канфігурацыі: /etc/apache2/sites-enabled/default-ssl.conf:
```
    SSLEngine on
    SSLProtocol all -SSLv2

    SSLCertificateFile	/etc/apache2/sites-enabled/Server.crt
    SSLCertificateKeyFile /etc/apache2/sites-enabled/ServerKey.pem

    SSLCACertificateFile /etc/apache2/sites-enabled/CA.crt

    SSLVerifyClient require
    SSLVerifyDepth  10
```
Як бачыце, назовы ў параметраў практычна супадае з назовамі параметраў у nginx, таму тлумачыць я іх не буду. Зноў жа каму цікавыя падрабязнасці - сардэчна запрашаем у дакументацыю.
Цяпер перазапускаем наш сервер:
```
$ service apache2 reload
$ service apache2 restart
```

Як бачыце наладзіць двухфактарную аўтэнтыфікацыю на любым вэб-серверы, што ў Windows, што ў Linux справа адной гадзіны максімум. А настройка браўзэраў займае каля 5 хвілін. Многія лічаць, што настройка і праца з двухфактарнай аўтэнтыфікацыяй гэта складана і незразумела. Спадзяюся наш артыкул хоць крыху, але развенчвае гэты міф.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Ці патрэбна інструкцыя па наладзе працы TLS з сертыфікатамі на ДАСТ 34.10-2012:

Так, TLS-ДАСТ вельмі патрэбен
Не, настройка з ДАСТ-алгарытмамі не цікавая

Прагаласавалі 44 карыстальніка. Устрымаліся 9 карыстальнікаў.

Крыніца: habr.com

Двухфактарная аўтэнтыфікацыя на сайце з выкарыстаннем USB-токена. Цяпер і для Linux