Dufaktora aŭtentigo en la retejo uzante USB-ĵetonon. Nun ankaŭ por Linukso

В unu el niaj antaŭaj artikoloj ni parolis pri la graveco de dufaktora aŭtentigo en kompaniaj portaloj de kompanioj. Lastan fojon ni montris kiel agordi sekuran aŭtentikigon en la retservilo de IIS.

En la komentoj, ni estis petitaj skribi instrukciojn por la plej oftaj retserviloj por Linukso - nginx kaj Apache.

Vi demandis - ni skribis.

Kion vi bezonas por komenci?

• Ajna moderna Linukso-distribuo. Mi faris testan aranĝon sur MX Linukso 18.2_x64. Ĉi tio kompreneble ne estas servila distribuo, sed verŝajne ne estos diferencoj por Debiano. Por aliaj distribuoj, la vojoj al la agordaj bibliotekoj povas malsami iomete.
• Token. Ni daŭre uzas la modelon Rutoken EDS PKI, kiu estas ideala laŭ rapidecaj trajtoj por kompania uzo.
• Por labori kun ĵetono en Linukso, vi devas instali la jenajn pakaĵojn:
  libccid libpcsclite1 pcscd pcsc-iloj opensc

Eldonado de atestiloj

En antaŭaj artikoloj, ni fidis je la fakto, ke atestiloj pri servilo kaj kliento estos eldonitaj per Microsoft CA. Sed ĉar ni agordas ĉion en Linukso, ni ankaŭ rakontos al vi pri alternativa maniero eldoni ĉi tiujn atestojn - sen forlasi Linukso.
Ni uzos XCA kiel CA (https://hohnstaedt.de/xca/), kiu estas havebla sur iu moderna Linukso-distribuo. Ĉiuj agoj, kiujn ni faros en XCA, povas esti faritaj en komandlinia reĝimo uzante la ilojn OpenSSL kaj pkcs11-ilo, sed por pli granda simpleco kaj klareco, ni ne prezentos ilin en ĉi tiu artikolo.

Kiel ekuzi

1. Instali:

   $ apt-get install xca

2. Kaj ni kuras:

   $ xca

3. Ni kreas nian datumbazon por CA - /root/CA.xdb
   Ni rekomendas konservi la datumbazon de la Atestila Aŭtoritato en dosierujo, kie nur la administranto havas aliron. Ĉi tio gravas por protekti la privatajn ŝlosilojn de la radikaj atestiloj, kiuj estas uzataj por subskribi ĉiujn aliajn atestojn.

Kreu ŝlosilojn kaj radikan CA-atestilon

Publika ŝlosila infrastrukturo (PKI) baziĝas sur hierarkia sistemo. La ĉefa afero en ĉi tiu sistemo estas la radika atestadaŭtoritato aŭ radika CA. Ĝia atestilo devas esti kreita unue.

1. Ni kreas privatan ŝlosilon RSA-2048 por la CA. Por fari tion, sur la langeto Privataj Ŝlosiloj puŝi Nova ŝlosilo kaj elektu la taŭgan tipon.
2. Agordu nomon por la nova ŝlosilparo. Mi nomis ĝin CA Key.
3. Ni eldonas la CA-atestilon mem, uzante la kreitan ŝlosilparon. Por fari tion, iru al la langeto atestiloj kaj alklaku Nova Atestilo.
4. Nepre elektu SHA-256, ĉar uzi SHA-1 ne plu povas esti konsiderata sekura.
5. Nepre elektu kiel ŝablonon [defaŭlte]CA. Ne forgesu klaki sur Apliki ĉion, alie la ŝablono ne estas aplikata.
6. En la langeto temo elektu nian ŝlosilparon. Tie vi povas plenigi ĉiujn ĉefajn kampojn de la atestilo.

Kreante ŝlosilojn kaj https-servilan atestilon

1. Simile, ni kreas privatan ŝlosilon RSA-2048 por la servilo, mi nomis ĝin Servila Ŝlosilo.
2. Kreante atestilon, ni elektas, ke la servila atestilo devas esti subskribita per CA-atestilo.
3. Ne forgesu elekti SHA-256.
4. Ni elektas kiel ŝablonon [defaŭlte] HTTPS_servilo. Alklaku Apliki ĉion.
5. Tiam sur la langeto temo elektu nian ŝlosilon kaj plenigu la postulatajn kampojn.

Kreu ŝlosilojn kaj atestilon por la uzanto

1. La privata ŝlosilo de la uzanto estos konservita sur nia ĵetono. Por labori kun ĝi, vi devas instali la bibliotekon PKCS#11 de nia retejo. Por popularaj distribuoj, ni distribuas pretajn pakaĵojn, kiuj troviĝas ĉi tie - https://www.rutoken.ru/support/download/pkcs/. Ni ankaŭ havas asembleojn por arm64, armv7el, armv7hf, e2k, mipso32el, kiuj povas esti elŝutitaj de nia SDK - https://www.rutoken.ru/developers/sdk/. Krom asembleoj por Linukso, ekzistas ankaŭ asembleoj por macOS, freebsd kaj android.
2. Aldono de nova PKCS#11 Provizanto al XCA. Por fari tion, iru al la menuo opcioj al la langeto PKCS#11 Provizanto.
3. Klaku Aldoni kaj elektu la vojon al la biblioteko PKCS#11. En mia kazo ĝi estas usrliblibrtpkcs11ecp.so.
4. Ni bezonos formatitan Rutoken EDS PKI-ĵetonon. Elŝutu la ilon rtAdmin - https://dev.rutoken.ru/pages/viewpage.action?pageId=7995615
5. Ni efektivigas

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

6. Ni elektas la ŝlosilon RSA-2048 por la Rutoken EDS PKI kiel la ŝlosilon. Mi nomis ĉi tiun ŝlosilon Klienta Ŝlosilo.

   

7. Enigu la PIN-kodon. Kaj ni atendas la kompletigon de aparataro-generado de la ŝlosila paro

   

8. Ni kreas atestilon por la uzanto analoge kun la servila atestilo. Ĉi-foje ni elektas ŝablonon [defaŭlte] HTTPS_kliento kaj ne forgesu klaki Apliki ĉion.
9. En la langeto temo enigi informojn pri la uzanto. Ni respondas jese al la peto konservi la atestilon por la ĵetono.

Kiel rezulto, sur la langeto Atestiloj en XCA vi devus ricevi ion tian.

Ĉi tiu minimuma aro de ŝlosiloj kaj atestiloj sufiĉas por komenci agordi la servilojn mem.

Por agordi, ni devas eksporti la CA-atestilon, servilatestilon kaj servilan privatan ŝlosilon.

Por fari tion, elektu la deziratan eniron sur la responda langeto en XCA kaj alklaku eksportado.

Nginx

Mi ne skribos kiel instali kaj ruli nginx-servilon - estas sufiĉe da artikoloj pri ĉi tiu temo en la Interreto, por ne mencii la oficialan dokumentaron. Ni iru rekte agordi HTTPS kaj dufaktoran aŭtentikigon per ĵetono.

Aldonu la sekvajn liniojn al la servila sekcio en 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;
}

Detala priskribo de ĉiuj parametroj rilataj al agordo de ssl en nginx troveblas ĉi tie - https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

Mi nur mallonge priskribos tiujn, kiujn mi demandis al mi:

• ssl_verify_client - specifas ke la ĉeno de fido por la atestilo devas esti kontrolita.
• ssl_verify_depth - Difinas la serĉprofundon por la fidinda radika atestilo en la ĉeno. Ĉar nia klienta atestilo estas tuj subskribita sur la radika atestilo, la profundo estas agordita al 1. Se la uzantatestilo estas subskribita sur meza CA, tiam 2 devas esti specifita en ĉi tiu parametro, ktp.
• ssl_client_certificate - specifas la vojon al la fidinda radika atestilo, kiu estas uzata kiam kontrolas fidon en la atestilo de la uzanto.
• ssl_certificate/ssl_certificate_key - indiku la vojon al la servila atestilo/privata ŝlosilo.

Ne forgesu ruli nginx -t por kontroli, ke ne estas tajperaroj en la agordo, kaj ke ĉiuj dosieroj estas en la ĝusta loko, ktp.

Kaj jen ĉio! Kiel vi povas vidi, la agordo estas tre simpla.

Kontroli ke ĝi funkcias en Firefox

Ĉar ni faras ĉion tute en Linukso, ni supozos, ke niaj uzantoj ankaŭ laboras en Linukso (se ili havas Vindozon, do vidu instrukciojn por agordi retumiloj en la antaŭa artikolo.

1. Ni lanĉu Firefox.
2. Ni provu unue ensaluti sen signo. Ni ricevas ĉi tiun bildon:

   

3. Iru al pri: preferoj # privateco, kaj ni iras al Sekurecaj aparatoj...
4. Klaku ŝarĝoaldoni novan PKCS#11-Aparato-pelilon kaj specifi la vojon al nia librtpkcs11ecp.so.
5. Por kontroli, ke la atestilo estas videbla, vi povas iri al Atestilo. Oni petos vin enigi vian PIN. Post ĝusta enigo, vi povas kontroli kio estas sur la langeto Viaj Atestiloj aperis nia atestilo el la ĵetono.
6. Nun ni iru kun la ĵetono. Firefox petas vin elekti atestilon, kiu estos elektita por la servilo. Elektu nian atestilon.

   

7. PROFITO!

   

La agordo estas farita unufoje, kaj kiel vi povas vidi en la fenestro de peto de atestilo, ni povas konservi nian elekton. Post ĉi tio, ĉiufoje kiam ni ensalutas en la portalon, ni nur bezonos enmeti ĵetonon kaj enigi la uzantan PIN-kodon, kiu estis specifita dum formatado. Post tia aŭtentigo, la servilo jam scias, kiu uzanto ensalutis kaj vi ne plu povas krei pliajn fenestrojn por kontroli, sed tuj enlasas la uzanton en sian personan konton.

Apache

Same kiel kun nginx, neniu devus havi problemojn instali apache. Se vi ne scias kiel instali ĉi tiun retservilon, simple uzu la oficialan dokumentaron.

Kaj ni komencas agordi nian HTTPS kaj dufaktoran aŭtentikigon:

1. Unue vi devas aktivigi mod_ssl:

   $ a2enmod ssl

2. Kaj tiam ebligu la defaŭltajn HTTPS-agordojn de la retejo:

   $ a2ensite default-ssl

3. Nun ni redaktas la agordan dosieron: /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

   Kiel vi povas vidi, la nomoj de la parametroj praktike koincidas kun la nomoj de la parametroj en nginx, do mi ne klarigos ilin. Denove, iu ajn interesita pri la detaloj estas bonvena al la dokumentado.
   Nun ni rekomencas nian servilon:

   $ service apache2 reload
   $ service apache2 restart

Kiel vi povas vidi, instali dufaktoran aŭtentikigon ĉe iu ajn retservilo, ĉu en Vindozo aŭ Linukso, daŭras unu horon maksimume. Kaj agordo de retumiloj daŭras ĉirkaŭ 5 minutojn. Multaj homoj opinias, ke starigi kaj labori kun dufaktora aŭtentikigo estas malfacila kaj neklara. Mi esperas, ke nia artikolo malkonfirmos ĉi tiun miton, almenaŭ iomete.

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Ĉu vi bezonas instrukciojn por agordi TLS kun atestiloj laŭ GOST 34.10-2012:

• Jes, TLS-GOST estas tre necesa

• Ne, agordi kun GOST-algoritmoj ne estas interesa

44 uzantoj voĉdonis. 9 uzantoj sindetenis.

fonto: www.habr.com