1) La începutul instalării serverului, introduceți comanda:
multiotp.exe -debug -config default-request-prefix-pin=0 display-log=1 după acesta nu este nevoie să introduceți un cod PIN la configurarea unui utilizator și jurnalul fiecărei operațiuni este afișat în consolă.
2) Folosind această comandă puteți ajusta intervalul de timp pentru utilizatorii care au greșit cu parola (implicit 30 de secunde):
multiotp.exe -debug -config failure-delayed-time=60
3) Ce se va scrie în cerere Google Authenticator peste 6 cifre, numite emitent, pot fi schimbate de la MultiOTP implicit la altceva:
multiotp.exe -debug -config emiter=altul
4) După ce operațiunile au fost finalizate, comanda de creare a unui utilizator devine puțin mai simplă:
multiotp.exe -debug -create user TOTP 12312312312312312321 6 (nu setez timpul de actualizare a cifrelor de 30 de secunde, se pare că este 30 implicit).
5) Fiecare utilizator poate schimba descrierea (text sub numerele din aplicația Google Auth):
multiotp.exe -set username description=2
6) Codurile QR pot fi create direct în aplicație:
multiotp.exe -qrcode nume de utilizator c:\multiotp\qrcode\user.png:\multiotp\qrcode\user.png
7) Puteți utiliza nu numai TOTP, ci și HOTP (nu ora curentă, și valoarea contorului incremental):
multiotp.exe -debug -creați numele de utilizator HOTP 12312312312312312321 6
Astăzi vă vom spune cum puteți configura rapid și ușor autentificarea cu doi factori și cripta datele importante, chiar și cu capacitatea de a utiliza datele biometrice. Soluția va fi relevantă pentru companiile mici sau doar pentru calculator personal sau laptop. Este important ca pentru aceasta să nu avem nevoie de o infrastructură cu chei publice (PKI), de un server cu rol de autoritate de certificare (Servicii de certificare) și nici măcar de un domeniu ( Director activ). Toate cerințele de sistem se vor reduce la sistemul de operare Windows și prezența utilizatorului a unei chei electronice, iar în cazul autentificării biometrice, de asemenea, un cititor de amprente, care, de exemplu, poate fi deja încorporat în laptopul dvs.
Pentru autentificare vom folosi software-ul nostru - JaCarta SecurLogon și cheia electronică JaCarta PKI ca autentificator. Instrumentul de criptare va fi Windows obișnuit EFS, accesul la fișierele criptate va fi asigurat și prin cheia JaCarta PKI (aceeași folosită pentru autentificare).
Să vă reamintim că JaCarta SecurLogon este certificat FSTEC din Rusia soluție software și hardware a companiei Aladdin R.D., care permite simplă și Trecere rapidă de la autentificare cu un singur factor bazată pe o pereche de autentificare-parolă la autentificare cu doi factori în sistemul de operare folosind token-uri USB sau carduri inteligente. Esența soluției este destul de simplă - JSL generează o parolă complexă (~63 de caractere) și o scrie în memoria securizată a cheii electronice. În acest caz, parola poate fi necunoscută utilizatorului însuși; utilizatorul știe doar codul PIN. Prin introducerea codului PIN în timpul autentificării, dispozitivul este deblocat și parola este transmisă sistemului pentru autentificare. Opțional, puteți înlocui introducerea unui cod PIN prin scanarea amprentei utilizatorului și puteți utiliza, de asemenea, o combinație de PIN + amprentă.
EFS, ca și JSL, poate funcționa în modul de sine stătător, nefiind nevoie de nimic, cu excepția sistemului de operare în sine. In toate sisteme de operare Familia Microsoft NT, începând cu Windows 2000 și mai târziu (cu excepția versiuni acasă), există tehnologia de criptare a datelor EFS (Encrypting File System) încorporată. Criptarea EFS se bazează pe capacitățile fișierului sisteme NTFSși arhitectura CryptoAPI și este conceput pentru a cripta rapid fișierele de pe hard diskul unui computer. Criptarea EFS utilizează cheile private și publice ale utilizatorului, care sunt generate prima dată când un utilizator utilizează funcția de criptare. Aceste chei rămân neschimbate atâta timp cât există contul său. La criptare Fișierul EFS la întâmplare generează un număr unic, așa-numitul Fișier Cheie de criptare(FEK) Lungime de 128 de biți, cu care fișierele sunt criptate. Cheile FEK sunt criptate cu o cheie principală, care este criptată cu cheia utilizatorilor sistemului care au acces la fișier. Cheia privată a utilizatorului este protejată de un hash al parolei utilizatorului. Datele criptate folosind EFS pot fi decriptate numai folosind același cont. intrări Windows cu aceeași parolă folosită pentru criptare. Și dacă stocați certificatul de criptare și cheia privată pe un token USB sau un smart card, atunci pentru a accesa fișierele criptate veți avea nevoie și de acest token USB sau smart card, care rezolvă problema compromiterii parolei, deoarece va fi necesar să aveți și dispozitiv suplimentar sub forma unei chei electronice.
Autentificare
După cum sa menționat deja, nu aveți nevoie de AD sau de o autoritate de certificare pentru a configura, aveți nevoie de oricare ferestrele moderne, distribuție și licență JSL. Configurarea este ridicol de simplă.Trebuie să instalați un fișier de licență.
Adăugați un profil de utilizator.
Și începeți să utilizați autentificarea cu doi factori.
Autentificare biometrică
Este posibil să utilizați autentificarea biometrică cu amprentă digitală. Soluția funcționează folosind tehnologia Match On Card. Hash-ul de amprentă este scris pe card în timpul inițializării și ulterior este verificat față de original. Nu lasă cardul nicăieri, nu este stocat în nicio bază de date. Pentru a debloca o astfel de cheie, se folosește o amprentă sau o combinație de PIN + amprentă, PIN sau amprentă.Pentru a începe să-l utilizați, trebuie doar să inițializați cardul cu parametrii necesari și să înregistrați amprenta utilizatorului.
În viitor, aceeași fereastră va apărea înainte de a intra în sistemul de operare.
În acest exemplu, cardul este inițializat cu capacitatea de a se autentifica folosind o amprentă sau un cod PIN, așa cum este indicat de fereastra de autentificare.
După prezentarea unei amprente sau a unui cod PIN, utilizatorul va fi dus în sistemul de operare.
Criptarea datelor
Configurarea EFS nu este, de asemenea, foarte complicată; se rezumă la configurarea unui certificat și emiterea acestuia către o cheie electronică și configurarea directoarelor de criptare. De obicei, nu trebuie să criptați întregul disc. Într-adevăr fișiere importante, la care nu este de dorit ca terții să aibă acces, sunt de obicei localizate în directoare separate și nu sunt împrăștiate oricum pe disc.Pentru a emite un certificat de criptare și o cheie privată, deschideți contul de utilizator, selectați - Gestionați certificatele de criptare a fișierelor. În expertul care se deschide, creați un certificat autosemnat pe cardul inteligent. Deoarece continuăm să folosim un card inteligent cu un applet BIO, trebuie să furnizați o amprentă digitală sau PIN pentru a înregistra certificatul de criptare.
În pasul următor, specificați directoarele care vor fi asociate cu noul certificat; dacă este necesar, puteți specifica toate unitățile logice.
Directorul criptat în sine și fișierele din acesta vor fi evidențiate într-o culoare diferită.
Accesul la fișiere se efectuează numai dacă aveți o cheie electronică, la prezentarea unei amprente sau a unui cod PIN, în funcție de ceea ce este selectat.
Aceasta completează configurarea.
Puteți utiliza ambele scenarii (autentificare și criptare) sau puteți alege unul.
Realitățile țărilor în care locuiesc majoritatea locuitorilor din Khabrovsk sunt de așa natură încât păstrarea serverelor cu Informații importante A face afaceri în afara țării a devenit o practică bună, permițându-vă să vă salvați nervii și datele.
Prima întrebare care apare atunci când treceți în cloud după criptarea datelor, sau poate chiar înainte de aceasta, este să vă asigurați că accesul la date cu un cont de utilizator este efectuat de utilizator și nu de altcineva. Și dacă o modalitate bună de a cripta datele aflate într-un cloud privat este discutată în articolul colegului meu, atunci cu autentificare totul este mai complicat.
Despre utilizatori și metode de protecție
Natura unui utilizator obișnuit este de așa natură încât atitudinea față de siguranța parolelor conturilor este destul de frivolă și este imposibil să corectăm acest lucru. Experiența noastră arată că, chiar dacă o companie are politici stricte, instruire pentru utilizatori etc., va exista totuși un dispozitiv necriptat care părăsește pereții biroului, iar când te uiți la lista de produse de la o companie cunoscută, înțelegi că este doar o chestiune de timp înainte de a prelua parolele de pe un dispozitiv necriptat.
Unele companii, pentru a controla accesul la date din cloud, instalează tuneluri între cloud și birou și interzic accesul la distanță https://habrahabr.ru/company/pc-administrator/blog/320016/. În opinia noastră, acest lucru nu este în totalitate soluție optimă, în primul rând, unele dintre avantajele soluției cloud sunt pierdute, iar în al doilea rând, există probleme de performanță notate în articol.
Soluție folosind un server terminal și Desktop la distanță Gateway (RDG) mai flexibil, poate fi personalizat nivel inalt securitate, așa cum este descris de colegul meu https://habrahabr.ru/post/134860/ (articol din 2011, dar principiul în sine este încă relevant). Aceasta metoda vă permite să împiedicați transferul de date din cloud, dar impune restricții asupra muncii utilizatorului și nu rezolvă complet problema de autentificare; mai degrabă este o soluție DLP.
Pot fi cel mai bun mod pentru a vă asigura că niciun atacator nu lucrează sub contul de utilizator este autentificare cu doi factori. Articolele colegului meu https://habrahabr.ru/post/271259/ https://habrahabr.ru/post/271113/ descriu configurarea MFA de la Microsoft și Google pentru VPN client. Metoda este bună, dar, în primul rând, necesită un CISCO ASA, care nu este întotdeauna ușor de implementat, mai ales în cloud-urile bugetare, iar în al doilea rând, lucrul printr-un VPN este incomod. Lucrul cu o sesiune de terminal prin RDG este mult mai confortabil, iar protocolul de criptare SSL pare mai universal și mai fiabil decât VPN de la CISCO.
Există multe soluții cu autentificare cu doi factori pe serverul terminal în sine, iată un exemplu de configurare soluție gratuită- http://servilon.ru/dvuhfaktornaya-autentifikaciya-otp/. Această soluție, din păcate, nu funcționează prin RDG.
Serverul RDG solicită confirmarea autorizației de la serverul MFA. MFA, în funcție de metoda de autentificare selectată, sună, trimite SMS-uri sau trimite o solicitare către o aplicație mobilă. Utilizatorul confirmă sau respinge cererea de acces. MFA returnează rezultatul celui de-al doilea factor de autentificare la serverul RDG.
Instalați și configurați Azure Multi-Factor Authentication Server
Creați un furnizor de autentificare în portalul Microsoft Azure
Mergem la Microsoft Azure (contul trebuie să aibă instalată un abonament sau o versiune de probă) și găsim Multi-Factor Authentication (MFA).Pe acest moment Managementul MFA nu este adăugat la versiune noua Portal Azure, deci se va deschide versiunea veche a portalului.
Pentru a crea un nou furnizor de autentificare cu mai mulți factori, trebuie să faceți clic în partea din stânga jos „CREATE → Servicii de aplicații → Director activ → Furnizor de autentificare cu mai mulți factori → Creare rapidă" Specificați numele și modelul de utilizare.
Modul în care va fi calculată plata depinde de modelul de utilizare, fie de numărul de utilizatori, fie de numărul de autentificări.
Odată creat, MFA va apărea în listă. Apoi, treceți la control apăsând butonul corespunzător.
Accesați Descărcări și descărcați Server MFA
Implementarea unui server MFA
Serverul MFA trebuie să fie instalat mașină virtuală diferit de serverul RDG. Sunt acceptate sistemele de operare mai vechi decât Windows Server 2008 sau Windows 7. Microsoft trebuie să funcționeze. Cadru net 4.0.Adresele de pe portul 443 ar trebui să fie disponibile:
Instalăm serverul MFA, în timpul instalării refuzăm vrăjitorul de setări.
Când porniți pentru prima dată, trebuie să introduceți datele contului, care trebuie să fie generate pe pagina de încărcare a serverului.
În continuare adăugăm utilizatori. Pentru a face acest lucru, accesați secțiunea Utilizatori și faceți clic pe Import din Active Directory, selectați utilizatorii de importat.
Dacă este necesar, puteți configura adăugare automată utilizatori noi de la AD:
„Integrare director → Sincronizare → Adăugare”, etc. adăugați un director care se va sincroniza automat la intervalul de timp specificat.
Să testăm funcționalitatea serverului MFA. Accesați secțiunea Utilizatori. Pentru contul dvs., indicați numărul de telefon (dacă nu este deja specificat) și selectați metoda de autentificare „Apel telefonic”. Faceți clic pe butonul Test și introduceți numele și parola. Telefonul ar trebui să primească un apel. Răspundem și apăsăm #.
Configurarea unui server MFA pentru a funcționa cu solicitările Radius
Accesați secțiunea Radius Authentication și bifați caseta de selectare „Enable RADIUS Authentication”.Adăugați un nou client specificând adresa IP a serverului NPS și cheia secretă partajată. Dacă autentificarea trebuie efectuată pentru toți utilizatorii, bifați caseta corespunzătoare (în în acest caz, toți utilizatorii trebuie adăugați la serverul MFA).
De asemenea, trebuie să vă asigurați că porturile specificate pentru conexiune se potrivesc cu porturile specificate pe serverul NPS și nu sunt blocate de firewall.
Accesați fila Țintă și adăugați un server Radius.
Notă: Dacă nu există un server NPS central în rețea, adresele IP ale clientului Radius și ale serverului vor fi aceleași.
Configurarea serverelor RDG și NPS pentru a funcționa împreună cu MFA
Gateway-ul Remote Desktop trebuie configurat pentru a trimite cereri Radius către serverul MFA. Pentru a face acest lucru, deschideți proprietățile gateway-ului și accesați fila „RDG CAP Store”, selectați „NPS rulează pe un server central” și indicați adresa serverului MFA și cheia secretă partajată.
Apoi, configuram serverul NPS. Extindeți secțiunea „Clienți și servere Radius → Grupuri de servere Radius la distanță”. Deschideți proprietățile grupului „TS gateway server group” (grupul este creat la configurarea RDG) și adăugați serverul nostru MFA.
Când adăugați, în fila „Echilibrare încărcăturii” creștem limitele de expirare a serverului. Setăm „Numărul de secunde fără răspuns, după care cererea este considerată respinsă” și „Numărul de secunde dintre solicitări, după care serverul este considerat indisponibil” în intervalul de 30-60 de secunde.
În fila „Autentificare/Contabilitate”, verificăm corectitudinea porturilor specificate și setăm cheia secretă partajată.
Acum să mergem la secțiunea „Clienți și servere Radius → Clienți Radius” și să adăugăm un server MFA, specificând „Nume prietenos”, adresa și secretul partajat.
Accesați secțiunea „Politici → Politici de solicitare a conexiunii”. Această secțiune ar trebui să conțină politica creată la configurarea RDG. Această politică direcționează cererile Radius către serverul MFA.
Duplicați politica și accesați proprietățile acesteia. Adăugați o condiție care să corespundă „Nume prietenos pentru clienți” cu „Nume prietenos” specificat în pasul anterior.
În fila „Setări”, schimbați furnizorul de servicii de autentificare la un server local.
Această politică va asigura că atunci când o solicitare Radius este primită de la serverul MFA, cererea va fi procesată local, ceea ce va elimina bucla de solicitare.
Să verificăm asta această politică plasat deasupra celui original.
În această etapă, combinația RDG și MFA este în stare de funcționare. Următorii pași sunt necesari pentru cei care doresc să poată utiliza autentificarea aplicației mobile sau doresc să ofere utilizatorilor acces la unele setări MFA prin portalul utilizatorilor.
Instalarea SDK-ului, serviciului web pentru aplicații mobile și portalului utilizatorului
Conexiunea la aceste componente se face prin protocolul HTTPS. Prin urmare, trebuie să instalați un certificat SSL pe serverul unde vor fi implementați.Portalul utilizatorului și serviciul web al aplicației mobile utilizează SDK-ul pentru a comunica cu serverul MFA.
Instalarea SDK-ului
SDK-ul este instalat pe serverul MFA și necesită IIS, ASP.NET, autentificare de bază, care trebuie să fie preinstalat folosind Server Manager.Pentru Instalare SDK accesați secțiunea Web Service SDK din Multi-Factor Authentication Server și faceți clic pe butonul de instalare, urmați expertul de instalare.
Instalarea serviciului web pentru aplicația mobilă
Acest serviciu este necesar pentru ca aplicația mobilă să interacționeze cu serverul MFA. Pentru funcţionare corectă serviciu, computerul pe care va fi instalat trebuie să aibă acces la Internet, iar portul 443 trebuie să fie deschis pentru conectarea de la Internet.Fișierul de instalare a serviciului se află în folder C:\Program Files\Azure Multi-Factor Authentication pe un computer cu MFA instalat. Lansați programul de instalare și urmați expertul de instalare. Pentru confortul utilizatorilor, puteți înlocui numele directorului virtual „MultiFactorAuthMobileAppWebService” cu unul mai scurt.
După instalare, accesați folderul C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService și modificați fișierul web.config. ÎN acest fișier trebuie să setați cheile responsabile pentru contul care face parte din grupul de securitate PhoneFactor Admins. Acest cont va fi folosit pentru a vă conecta la SDK.
În același fișier trebuie să specificați adresa URL la care este disponibil SDK-ul.
Notă: Conexiunea la SDK se face folosind Protocolul SSL, deci trebuie să vă referiți la SDK după numele serverului (specificat în certificatul SSL) și nu după adresa IP. Dacă contestația este făcută de nume local, trebuie să adăugați intrarea corespunzătoare în fișierul hosts pentru a utiliza certificatul SSL.
Adăugăm adresa URL unde serviciul web al aplicației mobile este disponibil în aplicația Multi-Factor Authentication Server din secțiunea Mobile App. Acest lucru este necesar pentru generarea corectă a codului QR în portalul utilizatorului pentru conectarea aplicațiilor mobile.
De asemenea, în această secțiune, puteți bifa caseta de selectare „Activați jetoanele OATH”, care vă permite să utilizați aplicația mobilă ca simbol software pentru a genera parole unice în funcție de timp.
Instalarea unui portal de utilizatori
Instalarea necesită IIS, ASP.NET și rolul de compatibilitate cu metabază IIS 6 (pentru IIS 7 sau o versiune ulterioară).Dacă portalul este instalat pe un server MFA, mergeți la secțiunea User Portal din Multi-Factor Authentication Server, faceți clic pe butonul de instalare și urmați expertul de instalare. Dacă computerul este conectat la un domeniu, atunci în timpul instalării va fi creat un utilizator care este membru al grupului de securitate PhoneFactor Admins. Acest utilizator este necesar pentru o conexiune sigură la SDK.
Când instalați pe un server separat, trebuie să copiați fișierul de instalare de pe serverul MFA (fișierul de instalare se află în folderul C:\Program Files\Multi-Factor Authentication Server). Instalați și editați fișierul web.config la locație C:\inetpub\wwwroot\MultiFactorAuth. Trebuie să schimbați cheia în acest fișier USE_WEB_SERVICE_SDK de la fals la adevărat. Specificați detaliile unui cont aparținând grupului PhoneFactor Admins în taste WEB_SERVICE_SDK_AUTHENTICATION_USERNAME și WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD. Și specificați adresa URL a SDK-ului serviciului, fără a uita să editați fișierul hosts dacă este necesar, astfel încât protocolul SSL să funcționeze.
Adăugăm adresa URL unde portalul utilizatorului este disponibil în aplicația Multi-Factor Authentication Server din secțiunea User Portal.
Demonstrare a modului în care funcționează Azure MFA pentru autentificarea conexiunilor RDG
Vom lua în considerare munca MFA din partea utilizatorului. În cazul nostru, al doilea factor de autentificare va fi aplicația mobilă, deoarece retea celulara are o serie de vulnerabilități care permit, cu o pregătire corespunzătoare, interceptarea apelurilor și SMS-urilor.În primul rând, utilizatorul va trebui să meargă pe portalul utilizatorului și să-și indice numărul de telefon (dacă nu este listat în AD) și să conecteze aplicația mobilă la contul său. Mergem pe portalul de sub contul nostru și introducem răspunsurile la întrebările secrete (vom avea nevoie de ele dacă accesul la cont este restabilit).
Apoi, selectați metoda de autentificare, în cazul nostru, o aplicație mobilă și faceți clic pe butonul „Creează cod de activare”. Va fi generat un cod QR care trebuie scanat aplicatie de mobil.
Deoarece la importarea utilizatorilor pe serverul MFA, a fost setată autentificarea folosind un cod PIN, ni se va solicita să îl creăm. Introduceți codul PIN dorit și faceți clic pe „Verificați-mi autenticitatea”. În aplicația mobilă, trebuie să confirmați solicitarea care apare. După acești pași, avem o aplicație legată de cont și acces complet la portal pentru a modifica setările personale.
Parolele pot crea un mare durere de cap din punct de vedere al securitățiiși manevrabilitate pentru administratorii IT ai întreprinderilor și organizațiilor. Utilizatorii creează adesea parole simple sau notează parole pentru a nu le uita. În plus, puține proceduri de resetare a parolei sunt eficiente sau sigure. Având în vedere aceste limitări, cum pot fi atenuate aceste tipuri de probleme de securitate atunci când se realizează accesul la rețea utilizatori la distanță? Cum puteți face soluția de parole a companiei dvs. mai sigură, știind că mulți utilizatori își notează parolele?
Există o soluție - aceasta este implementarea în organizație sistem suplimentar protecția accesului bazată pe introducerea parolelor unice (OTP - One Time Password), care sunt generate pe dispozitiv mobil angajatul dvs. Trecerea la autentificarea bazată pe parole unice se produce de obicei într-o situație în care se înțelege că parolele standard pe termen lung sunt insuficiente din punct de vedere al securității și, în același timp, posibilitățile de utilizare a cardurilor inteligente sunt limitate, pt. de exemplu, într-o situație în care clienții de telefonie mobilă sunt utilizați pe scară largă.
Compania noastră s-a dezvoltat solutie tehnologica , care vă va permite să obțineți linie suplimentară de apărare pentru un server terminal sau un server 1C bazat pe parole unice , la care angajații se conectează de la distanță.
Domeniul de activitate pentru implementarea și configurarea unui sistem OTP
Software-ul specializat este instalat și configurat pe serverul dvs. pentru a opera un sistem de autentificare a accesului bazat pe parole unice (OTP) Toți angajații organizației care au nevoie de acces la server sunt autentificați în sistemul OTP Pentru fiecare angajat, se realizează configurarea inițială telefon mobil cu instalarea unui program pentru a genera o parolă unică
Începe costul introducerii într-o organizație a unui sistem de autentificare a accesului pentru un server terminal sau un server 1C bazat pe parole unice (OTP) de la 6.400 de ruble..
În cazurile în care sistemul OTP va fi implementat împreună cu închirierea infrastructurii în „clodul” nostru securizat, Reducerea la implementarea unui sistem de protecție folosind parole unice (OTP) poate ajunge la 50%.
Parole unice - un nivel suplimentar de securitate a datelor
O parolă tradițională, statică, este de obicei schimbată numai atunci când este necesar: fie când expiră, fie când utilizatorul a uitat-o și dorește să o resetați. Pentru că parolele sunt stocate în cache hard disk-uri computer și stocate pe un server, sunt vulnerabile la hacking. Această problemă este deosebit de acută pentru computerele laptop, deoarece sunt ușor de furat. Multe companii oferă angajaților computere laptop și își deschid rețelele pentru acces la distanță. De asemenea, angajează angajați temporari și furnizori. Într-un astfel de mediu, o soluție simplă de parolă statică devine un dezavantaj.
Spre deosebire de o parolă statică, parolă de unică folosință se modifică de fiecare dată când utilizatorul se autentifică în sistem și este valabil doar pentru o perioadă scurtă de timp (30 de secunde). Parolele în sine sunt create și criptate folosind un algoritm complex care depinde de multe variabile: timp, număr de autentificări reușite/nereușite, numere generate aleatoriu etc. Această abordare aparent complexă necesită acțiuni simple din partea utilizatorului - Instalați pe telefon aplicație specială, care se sincronizează o dată cu serverul și ulterior generează o parolă unică. Cu fiecare conectare reușită nouă, clientul și serverul sunt resincronizate automat, independent unul de celălalt, folosind un algoritm special. Valoarea contorului crește de fiecare dată când este necesară o valoare OTP de pe dispozitiv și când utilizatorul dorește să se autentifice, acesta introduce OTP-urile afișate în prezent pe dispozitivul său mobil.
Metode de protecție atunci când se utilizează autentificarea prin parolă. Pentru a vă proteja parolele de piratare, ar trebui să configurați o politică adecvată. Pentru a face acest lucru, utilizați meniul Start->Administrative Tools->Group Policy Management pentru a lansa GPMC Group Policy Management Console și selectați obiectul necesar. Politica de grup secțiunea Configurare computer->Politici->Setări de securitate->Politici de cont->Politică de parolă Vezi Fig. 1 (Gestionați setările parolei).
Orez. 1 Gestionați setările parolei.
Putem seta o lungime minimă a parolei, care ne va permite să evităm parolele scurte (Minim parola lungime). Pentru ca utilizatorul să specifice parole complexe trebuie inclusă cerința de complexitate (Parola trebuie sa întâlni complexitate cerințe).
Pentru a vă asigura că parola dvs. este schimbată în mod regulat, trebuie să o setați termen maxim viaţă (Maxim parola vârstă).
Pentru a împiedica utilizatorii să repete parolele vechi, trebuie să configurați stocarea istoricului parolelor (Impune parola istorie) .
Și în sfârșit, pentru a vă asigura că utilizatorul nu își schimbă parola cu cea veche schimbând parolele de mai multe ori, setați o perioadă minimă în care parola nu poate fi schimbată (Minim parola vârstă).
Pentru a ne proteja împotriva unui atac de dicționar, vom configura o blocare a contului dacă parola este introdusă greșit în mod repetat. Pentru a face acest lucru, trebuie să selectați secțiunea GPO necesară din Consola de gestionare a politicilor de grup GPMC Calculator Configurare-> Politici-> Securitate Setări-> Cont Politici-> Cont Blocare Politică . Vezi fig. 2 (Gestionarea blocării contului de utilizator).
Orez. 2 Gestionați blocarea contului de utilizator.
Pentru a configura contul să fie blocat definitiv (înainte ca administratorul să-l deblocheze), ar trebui să setați parametrul durată de blocare la zero (Cont blocare durată).
În contorul numărului de încercări de conectare nereușite (Cont blocare prag) trebuie să specificați valoarea necesară. În cele mai multe cazuri, sunt acceptabile 3-5 încercări de conectare.
În cele din urmă, ar trebui să setați intervalul pentru resetarea contorului de încercări eșuate (Resetați cont blocare tejghea după).
Pentru a proteja împotriva " cai troieni" ar trebui folosit agenți antivirusși blocare neautorizată software.
Pentru a limita capacitatea utilizatorilor de a introduce viruși într-un sistem informatic, este justificat: stabilirea unei interdicții de a lucra cu dispozitive externe(CD, DVD, Flash), mod strict UAC, utilizați separat Internet în picioare chioșcuri bazate pe computere care nu sunt incluse în retea de lucru. Și, în sfârșit, introducerea unor reglementări stricte de muncă care definesc regulile pentru modul în care utilizatorii lucrează în rețeaua corporativă (interdicția de a-și partaja acreditările cu oricine, interzicerea de a-și lăsa acreditările în locuri accesibile, cerințe pentru blocarea obligatorie a stației de lucru la părăsirea locului de muncă , etc. . P.).
Ca urmare, vom putea reduce riscurile asociate cu o încălcare a securității companiei.
Să presupunem că toate acestea sunt făcute. Cu toate acestea, este prea devreme să spunem că am reușit să oferim autentificare sigură în sistemul nostru.
Factorul uman este cea mai mare amenințare.
Există încă amenințări cărora nu le-am putut face față. Una dintre cele mai semnificative - factorul uman. Utilizatorii sistemelor noastre informatice nu sunt întotdeauna suficient de conștiincioși și, în ciuda explicațiilor de la administratorii de securitate, își notează acreditările (nume de utilizator și parola) și nu le pasă de secretul acestui lucru. informații confidențiale. De mai multe ori am găsit autocolante pe monitor, vezi Fig. 3, sau sub tastatură vezi fig. 4 cu nume de utilizator și parolă.
Orez. 3. Un cadou minunat pentru un atacator, nu-i așa?
Orez. 4. Un alt cadou pentru hoț.
După cum putem vedea, parolele lungi și complexe sunt introduse în sistem și seria asociativă nu este clar vizibilă. Cu toate acestea, utilizatorii au găsit o modalitate „eficientă” de a-și aminti și stoca acreditările...
Astfel, vedeți că în acest caz a intrat în joc caracteristica pe care am menționat-o mai sus: parolele lungi și complexe sunt înregistrate și este posibil să nu fie stocate corect.
Insider
O altă amenințare semnificativă de securitate este potențialul ca un atacator să obțină acces fizic la stația de lucru a unui utilizator legitim și să transfere informații confidențiale către terți. Acesta este despre care vorbim despre o situație în care în cadrul companiei există un angajat care fură informații de la colegii săi.
Este destul de evident că este foarte dificil să se asigure securitatea „fizică” a stației de lucru a utilizatorului. Puteți conecta cu ușurință un keylogger hardware la spațiul tastaturii, interceptând semnalul de la tastaturi fără fir este de asemenea posibil. Astfel de dispozitive există. Desigur, oricine nu va intra în biroul companiei, dar toată lumea știe că cel mai periculos este un spion intern. El are deja acces fizic la sistemul tău, iar plasarea unui keylogger nu va fi dificilă, mai ales că aceste dispozitive sunt disponibile pentru o gamă largă de oameni. În plus, programele keylogger nu pot fi reduse. Într-adevăr, în ciuda tuturor eforturilor administratorilor, posibilitatea instalării unui astfel de software „spyware” nu este exclusă. Utilizatorul îl blochează întotdeauna pe al lui stație de lucru iti parasesti locul de munca? Administratorul este capabil să Sistem informatic asigurați-vă că utilizatorului nu i se atribuie permisiuni excesive, mai ales dacă este necesar să le folosiți pe cele vechi produse software? Are administratorul, mai ales într-o companie mică, întotdeauna suficiente calificări pentru a implementa recomandările de software și hardware privind construirea de sisteme informatice sigure?
Astfel, putem concluziona că autentificarea prin parolă este nesigură în principiu. Prin urmare, este necesară autentificarea cu mai mulți factori și de un astfel de tip încât parola utilizatorului să nu fie introdusă pe tastatură.
Ce ne poate ajuta?
Este logic să luați în considerare autentificarea cu doi factori: primul factor este deținerea parolei, al doilea este cunoașterea codului PIN. Parola de domeniu nu mai este introdusă pe tastatură, ceea ce înseamnă că nu este interceptată de un keylogger. Interceptarea unei parole de domeniu este plină de posibilitatea de a vă autentifica; interceptarea unui cod PIN nu este atât de periculoasă, deoarece este necesară suplimentar un card inteligent.
În acest sens, se poate argumenta că utilizatorul poate să-și lase cardul în cititor și să scrie PIN-ul pe un autocolant, ca înainte. Cu toate acestea, există sisteme de control care pot bloca un card abandonat, așa cum este implementat în bancomate. În plus, este posibil să plasăm un permis pe card pentru a intra/ieși din birou, adică putem folosi un card cu etichetă RFID, combinând astfel sistemul de autentificare din serviciul de director cu un sistem fizic de control al accesului. În acest caz, pentru a deschide ușa, utilizatorul va avea nevoie de cardul său inteligent sau de tokenul USB, așa că va fi obligat să-l poarte mereu cu el.
In afara de asta, solutii moderne pentru autentificarea cu doi factori, acestea necesită nu numai capacitatea de a se autentifica în AD sau AD DS. Folosirea cardurilor inteligente și a cheilor USB ajută și în multe alte cazuri, de exemplu la accesarea publicului e-mail, către magazinele online unde este necesară înregistrarea, către aplicații care au propriul serviciu de catalog etc. etc.
Astfel, puteți obține practic remediu universal autentificare.
Implementarea autentificării cu doi factori bazată pe criptografia asimetricăîn ADDS.
Active Directory acceptă autentificarea cu smart card încă din Windows 2000.
În esență, capacitatea de a se autentifica folosind carduri inteligente este conținută în extensia PKINIT (inițializarea cheii publice) pentru protocolul Kerberos RFC 4556. Vezi. Extensia PKINIT permite utilizarea certificatelor de cheie publică în timpul fazei de pre-autentificare Kerberos.
Acest lucru face posibilă utilizarea cardurilor inteligente. Adică, putem vorbi despre posibilitatea de autentificare cu doi factori în sisteme Microsoft bazat pe instrumente standard, începând cu Windows 2000, deoarece schema Kerberos + PKINIT a fost deja implementată.
Notă. PreautentificareKerberos– un proces care asigură nivel suplimentar Securitate. Execut înainte de emitereTGT (Bilet Acordarea Bilet) de la serverul de distribuție a cheilor (K.D.C.). Folosit în protocolKerberos v. 5 pentru a contracara atacurile offline de ghicire a parolei. Aflați mai multe despre cum funcționează protocolulKerberospoate fi găsit în RFC 4120.Cm
Desigur, vorbim despre computere care fac parte dintr-un domeniu. Dacă este nevoie să recurgeți la autentificarea cu doi factori atunci când lucrați în grup de lucru, sau când folosiți mai multe versiuni anterioare sisteme de operare, atunci va trebui să apelăm la software terță parte, de exemplu SafeNet (Aladdin) eToken Network Logon 5.1. Cm.
Conectarea poate fi furnizată folosind fie un serviciu de director de domeniu, fie un serviciu de director local. În acest caz, parola utilizatorului nu este introdusă pe tastatură, ci este transferată dintr-un spațiu de stocare securizat pe cardul inteligent.
Autentificarea folosind carduri inteligente este implementată prin extensia Kerberos PKINIT, această extensie oferă posibilitatea de a utiliza algoritmi criptografici asimetrici.
În ceea ce privește cerințele pentru introducerea utilizării cardurilor inteligente în combinație cu PKINIT, pentru funcționare sisteme Windows 2000, Windows 2003 Server, acestea sunt după cum urmează:
· Toate controlerele de domeniu și toate calculatoare clientîn pădurea în care soluția noastră este implementată, trebuie să avem încredere în Autoritatea de Certificare rădăcină (Autoritatea de Certificare).
· CA care emite certificate pentru utilizarea cardurilor inteligente trebuie să fie plasată în depozitul Autorității NT
· Certificatul trebuie să conțină identificatorii de conectare cu cardul inteligent și de autentificare client
· Certificatul pentru carduri inteligente trebuie să conțină UPN-ul utilizatorului.
· Certificatul și cheia privată trebuie să fie plasate în secțiunile corespunzătoare ale cardului inteligent, iar cheia privată trebuie să fie amplasată într-o zonă securizată a memoriei cardului inteligent.
· Certificatul trebuie să indice calea către punctul de distribuție CRL a listei de revocare a certificatelor
· Toate controlerele de domeniu trebuie să aibă certificat instalat Autentificare controler de domeniu sau autentificare Kerberos, deoarece procesul de autentificare reciprocă a clientului și serverului este implementat.
Au avut loc o serie de modificări ale cerințelor în sistemele de operare începând cu Windows Server 2008:
· Extensia CRL nu mai este necesară în certificatele de conectare cu smart card
· Acum acceptă capacitatea de a stabili o relație între un cont de utilizator și un certificat
· Certificatul poate fi scris în orice secțiune accesibilă a cardului inteligent
· Extensia EKU nu este necesară pentru a include OID de conectare Smart Card, dar pentru a fi corect, dacă intenționați să utilizați un singur șablon de certificat pentru clienții pe toate sistemele de operare, atunci, desigur, OID de conectare Smart Card trebuie să fie activat.
Câteva cuvinte despre procedura de conectare a clientului în sine. Dacă vorbim despre sisteme de operare din Windows Vistași mai sus, trebuie remarcat faptul că aici au avut loc o serie de modificări:
· În primul rând, procedura de conectare cu cardul inteligent nu mai este inițiată automat când introduceți un card inteligent într-un cititor de carduri sau conectați cheia USB la port USB, adică va trebui să apăsați Ctrl+Alt+Delete.
· În al doilea rând, noua capacitate de a utiliza orice slot pentru carduri inteligente pentru a stoca certificate oferă utilizatorului să aleagă dintr-o varietate de obiecte de identificare stocate pe card, în timp ce certificatul necesar în prezent este afișat ca disponibil pentru utilizare.
concluzii
Așadar, am examinat câteva aspecte principale referitoare la partea teoretică a autentificării cu doi factori în Active Directory Domain Services și putem rezuma.
Asigurarea securității procesului de autentificare al sistemului este esențială. Tipurile de spargere a parolelor care există astăzi creează nevoia de autentificare cu mai mulți factori.
Pentru o companie mică poți se limitează la o politică strictă de protecție a acreditărilor, implementează software antivirus și privează utilizatorii de capacitatea de a lucra cu medii externe informații pentru a bloca lansarea de software neautorizat, implementarea reglementărilor pentru utilizatori etc. etc.
Cand vine companie mare, sau despre o companie în care există un interes clar din partea atacatorilor - aceste fonduri nu sunt suficiente. Greșelile și informațiile privilegiate vă pot distruge eforturile de a construi un sistem de securitate, așa că trebuie să alegeți o altă cale. Aici are deja sens să vorbim despre introducerea autentificării securizate.
Utilizarea autentificării cu doi factori este o soluție bună din punct de vedere al securității.
Acum avem un al doilea factor de autentificare; pe lângă codul PIN, utilizatorul trebuie să aibă și un smart card sau cheie USB.
Folosind carduri inteligente sau chei USB ne oferă capacitatea de a oferi autentificare cu doi factori atât în medii AD, cât și AD DS.
Într-unul dintre următoarele articole vă voi spune cum este implementată în practică autentificarea cu doi factori. Ne vom uita la implementarea și configurarea unei infrastructuri de autoritate de certificare (PKI). Bazat pe Windows Server 2008 Enterprise R2.
Bibliografie.
Http://www.rfc-archive.org/getrfc.php?rfc=4556
Http://www.rfc-archive.org/getrfc.php?rfc=4120
Http://www.aladdin.ru/catalog/etoken_products/logon
NCSC-TG-017 - „A Guide to Understanding Identification and Authentication in Trusted Systems”, publicat de S.U.A. Centrul Național de Securitate Informatică.
RFC4120 – Serviciul de autentificare a rețelei Kerberos (V5)
RFC4556 – Criptografia cu chei publice pentru autentificarea inițială în Kerberos (PKINIT)
Brian Komar Windows Server 2008 PKI și certificat de securitate
Leonid Shapiro,
Trainer certificat MCT, MCSE:S, MCSE:M, MCITP EA, TMS
