Kako podesiti pametne telefone i računare. Informativni portal
  • Dom
  • Programi
  • Iza dvostrukog oklopa. Dvofaktorska autentifikacija u domenskim uslugama Active Directory

Iza dvostrukog oklopa. Dvofaktorska autentifikacija u domenskim uslugama Active Directory

Dobio sam neverovatno dobre komentare i pojašnjenja od prijatelja koji je želeo da ostane anoniman:
1) Na samom početku podešavanja servera unesite naredbu:
multiotp.exe -debug -config default-request-prefix-pin=0 display-log=1 nakon njega nema potrebe za unosom pin koda prilikom postavljanja korisnika i zapisnik svake operacije se prikazuje u konzoli.

2) Koristeći ovu naredbu možete podesiti bantime za korisnike koji su pogriješili sa lozinkom (podrazumevano 30 sekundi):
multiotp.exe -debug -config fail-delayed-time=60
3) Šta će pisati u prijavi Google Authenticator iznad 6 cifara, koji se nazivaju izdavač, mogu se promijeniti iz zadanog MultiOTP-a u nešto drugo:
multiotp.exe -debug -config issuer=other
4) Nakon što su operacije završene, naredba za kreiranje korisnika postaje malo jednostavnija:
multiotp.exe -debug -kreiraj korisnika TOTP 12312312312312312321 6 (ne postavljam vrijeme ažuriranja cifara od 30 sekundi, čini se da je 30 po defaultu).

5) Svaki korisnik može promijeniti opis (tekst ispod brojeva u Google aplikacija Auth):
multiotp.exe -set korisničko ime opis=2
6) QR kodovi se mogu kreirati direktno u aplikaciji:
multiotp.exe -qrcode korisničko ime c:\multiotp\qrcode\user.png:\multiotp\qrcode\user.png
7) Možete koristiti ne samo TOTP, već i HOTP (ne trenutno vrijeme, i vrijednost inkrementalnog brojača):
multiotp.exe -debug -kreiraj korisničko ime HOTP 12312312312312312321 6

Danas ćemo vam reći kako možete brzo i jednostavno postaviti dvofaktorsku autentifikaciju i šifrirati važne podatke, čak i uz mogućnost korištenja biometrije. Rješenje će biti relevantno za male kompanije ili samo za PC ili laptop. Bitno je da nam za to nije potrebna infrastruktura javnog ključa (PKI), server sa ulogom certifikacijskog tijela (Certificate Services), a ne treba nam čak ni domen ( Aktivni direktorij). Svi sistemski zahtjevi svodit će se na operativni sistem Windows i korisnikovo prisustvo elektronskog ključa, a u slučaju biometrijske autentifikacije i čitača otiska prsta, koji je, na primjer, možda već ugrađen u vaš laptop.

Za autentifikaciju ćemo koristiti naš softver - JaCarta SecurLogon i JaCarta PKI elektronski ključ kao autentifikator. Alat za šifriranje će biti obični Windows EFS, pristup šifrovanim datotekama će takođe biti omogućen preko JaCarta PKI ključa (isti onaj koji se koristi za autentifikaciju).

Podsjetimo, JaCarta SecurLogon je certificiran FSTEC Rusije softversko i hardversko rješenje kompanije Aladdin R.D., koje omogućava jednostavno i Brzi prolaz od jednofaktorske autentifikacije zasnovane na paru prijava-lozinka do dvofaktorske autentifikacije u OS-u pomoću USB tokena ili pametnih kartica. Suština rješenja je prilično jednostavna - JSL generira složenu lozinku (~63 znaka) i upisuje je u sigurnu memoriju elektronskog ključa. U tom slučaju, lozinka može biti nepoznata samom korisniku, korisnik zna samo PIN kod. Unošenjem PIN koda tokom autentifikacije, uređaj se otključava i lozinka se prenosi sistemu na autentifikaciju. Po želji, unos PIN koda možete zamijeniti skeniranjem otiska prsta korisnika, a možete koristiti i kombinaciju PIN + otisak prsta.

EFS, kao i JSL, može raditi u samostalnom načinu rada, ne zahtijevajući ništa osim samog OS-a. U svemu operativni sistemi Microsoft NT porodica, počevši od Windows 2000 i novijih (osim kućne verzije), postoji ugrađena EFS (Encrypting File System) tehnologija šifriranja podataka. EFS enkripcija se zasniva na mogućnostima datoteke NTFS sistemi i CryptoAPI arhitekturu i dizajniran je za brzo šifriranje datoteka na tvrdom disku računara. EFS enkripcija koristi privatne i javne ključeve korisnika, koji se generiraju prvi put kada korisnik koristi funkciju šifriranja. Ovi ključevi ostaju nepromijenjeni sve dok postoji njegov račun. Prilikom šifriranja EFS fajl nasumično generiše jedinstveni broj, takozvani File Ključ za šifriranje(FEK) 128 bita, sa kojima su fajlovi šifrovani. FEK ključevi su šifrirani glavnim ključem, koji je šifriran ključem korisnika sistema koji imaju pristup datoteci. Privatni ključ korisnika je zaštićen hešom korisničke lozinke. Podaci šifrirani pomoću EFS-a mogu se dešifrirati samo pomoću istog naloga. Windows unosi sa istom lozinkom koja se koristi za enkripciju. A ako certifikat enkripcije i privatni ključ pohranite na USB token ili pametnu karticu, tada će vam za pristup šifriranim datotekama biti potreban i ovaj USB token ili pametna kartica, što rješava problem kompromitovanja lozinke, jer će biti potrebno imati i dodatni uređaj u obliku elektronskog ključa.

Autentifikacija

Kao što je već napomenuto, za konfiguraciju vam nije potreban AD ili certifikacijski organ, potreban vam je bilo koji moderni Windows, JSL distribucija i licenca. Postavljanje je smiješno jednostavno.

Morate instalirati datoteku licence.

Dodajte korisnički profil.

I počnite koristiti dvofaktorsku autentifikaciju.

Biometrijska autentifikacija

Moguće je koristiti biometrijsku autentifikaciju otiskom prsta. Rješenje radi koristeći Match On Card tehnologiju. Heš otiska prsta se upisuje na karticu tokom početne inicijalizacije i naknadno se provjerava u odnosu na original. Ne ostavlja karticu nigdje, nije pohranjena ni u jednoj bazi podataka. Za otključavanje takvog ključa koristi se otisak prsta ili kombinacija PIN + otisak prsta, PIN ili otisak prsta.

Da biste je počeli koristiti, samo trebate inicijalizirati karticu s potrebnim parametrima i snimiti otisak prsta korisnika.

U budućnosti će se isti prozor pojaviti prije ulaska u OS.

U ovom primjeru, kartica se inicijalizira s mogućnošću autentifikacije pomoću otiska prsta ili PIN koda, kao što je naznačeno prozorom za autentifikaciju.

Nakon predstavljanja otiska prsta ili PIN koda, korisnik će biti prebačen u OS.

Šifrovanje podataka

Podešavanje EFS-a također nije mnogo komplicirano, svodi se na postavljanje certifikata i njegovo izdavanje elektronskom ključu i postavljanje direktorija za šifriranje. Obično ne morate šifrirati cijeli disk. Zaista važne datoteke, kojima nije poželjno da pristupe treća lica, obično se nalaze u zasebnim direktorijumima, a ni na koji način nisu razbacani po disku.

Da biste izdali certifikat za šifriranje i privatni ključ, otvorite svoj korisnički račun, odaberite - Upravljaj certifikatima za šifriranje datoteka. U čarobnjaku koji se otvori kreirajte samopotpisani certifikat na pametnoj kartici. Budući da i dalje koristimo pametnu karticu sa BIO apletom, morate dati otisak prsta ili PIN za snimanje certifikata za šifriranje.

U sljedećem koraku navedite direktorije koji će biti povezani s novim certifikatom; ako je potrebno, možete specificirati sve logičke pogone.

Sam šifrirani direktorij i datoteke u njemu bit će istaknuti drugom bojom.

Pristup datotekama se vrši samo ako posjedujete elektronski ključ, uz predočenje otiska prsta ili PIN koda, ovisno o tome šta je odabrano.

Ovim je podešavanje završeno.

Možete koristiti oba scenarija (provjeru autentičnosti i šifriranje), ili možete odabrati jedan.

Realnosti zemalja u kojima živi većina stanovnika Khabrovska su takve da čuvanje servera sa važna informacija Poslovanje van zemlje postalo je dobra praksa, koja vam omogućava da sačuvate svoje živce i podatke.

Prvo pitanje koje se nameće prilikom prelaska u oblak nakon enkripcije podataka, ili možda čak i prije nje, je osigurati da pristup podacima s korisničkim računom obavlja korisnik, a ne neko drugi. A ako se u članku mog kolege govori o dobrom načinu šifriranja podataka koji se nalaze u privatnom oblaku, onda je s autentifikacijom sve složenije.

O korisnicima i načinima zaštite

Priroda tipičnog korisnika je takva da je stav prema sigurnosti lozinki naloga prilično neozbiljan i to je nemoguće ispraviti. Naše iskustvo pokazuje da čak i ako kompanija ima stroge politike, obuku korisnika itd., i dalje će postojati nešifrovani uređaj koji napušta zidove kancelarije, a kada pogledate listu proizvoda jedne poznate kompanije, shvatićete da je samo je pitanje vremena kada će se preuzeti lozinke sa nešifrovanog uređaja.

Neke kompanije, za kontrolu pristupa podacima u oblaku, instaliraju tunele između oblaka i ureda i zabranjuju daljinski pristup https://habrahabr.ru/company/pc-administrator/blog/320016/. Po našem mišljenju, to nije u potpunosti optimalno rešenje, prvo, neke od prednosti rješenja u oblaku su izgubljene, a drugo, postoje problemi s performansama koji su navedeni u članku.

Rješenje korištenjem terminalskog servera i Remote Desktop Gateway (RDG) fleksibilniji, može se prilagoditi visoki nivo sigurnost, kako je opisao moj kolega https://habrahabr.ru/post/134860/ (članak iz 2011, ali sam princip je i dalje relevantan). Ova metoda omogućava vam da spriječite prijenos podataka iz oblaka, ali nameće ograničenja u radu korisnika i ne rješava u potpunosti problem autentifikacije, već je to DLP rješenje.

Možda najbolji način kako bi se osiguralo da nijedan napadač ne radi pod korisničkim računom dvofaktorska autentifikacija. Članci mog kolege https://habrahabr.ru/post/271259/ https://habrahabr.ru/post/271113/ opisuju postavljanje MFA od Microsofta i Googlea za klijent VPN. Metoda je dobra, ali, prvo, zahtijeva CISCO ASA, što nije uvijek lako implementirati, posebno u proračunskim oblacima, a drugo, rad preko VPN-a je nezgodan. Rad sa terminalskom sesijom preko RDG-a je mnogo udobniji, a protokol SSL enkripcije izgleda univerzalnije i pouzdanije od VPN-a iz CISCO-a.

Postoji mnogo rješenja sa dvofaktorskom autentifikacijom na samom terminal serveru, evo primjera konfiguracije besplatno rješenje- http://servilon.ru/dvuhfaktornaya-autentifikaciya-otp/. Ovo rješenje nažalost ne radi kroz RDG.

RDG server traži potvrdu autorizacije od MFA servera. MFA, ovisno o odabranom načinu autentifikacije, zove, šalje SMS ili šalje zahtjev mobilnoj aplikaciji. Korisnik potvrđuje ili odbija zahtjev za pristup. MFA vraća rezultat drugog faktora autentifikacije na RDG server.

Instalirajte i konfigurišite Azure server višefaktorske autentikacije

Kreirajte dobavljača provjere autentičnosti na Microsoft Azure portalu

Idemo na Microsoft Azure (nalog mora imati instaliranu pretplatu ili probnu verziju) i nalazimo višefaktorsku provjeru autentičnosti (MFA).

On ovog trenutka Upravljanje MIP-om nije dodano nova verzija Azure portal, tako da će se otvoriti stara verzija portala.

Da biste kreirali novog provajdera višefaktorske autentikacije, potrebno je da kliknete na donji levi „KREIRAJ → Aplikacione usluge → Aktivni direktorijum → Provajder višefaktorske autentifikacije → Brzo kreiranje" Navedite naziv i model upotrebe.

Način na koji će se obračunati plaćanje ovisi o modelu korištenja, bilo po broju korisnika ili po broju autentifikacija.


Nakon kreiranja, MFA će se pojaviti na listi. Zatim nastavite sa kontrolom pritiskom na odgovarajuće dugme.


Idite na preuzimanja i preuzmite MFA server

Postavljanje MFA servera

MFA server mora biti instaliran virtuelna mašina različit od RDG servera. Podržani su operativni sistemi stariji od Windows Server 2008 ili Windows 7. Za rad je potreban Microsoft. NET Framework 4.0.

Adrese na portu 443 trebaju biti dostupne:

Instaliramo MFA server, tokom instalacije odbijamo čarobnjaka za podešavanja.

Prilikom prvog pokretanja morate unijeti podatke o računu, koji se moraju generirati na stranici za učitavanje servera.


Zatim dodajemo korisnike. Da biste to učinili, idite na odjeljak Korisnici i kliknite na Uvezi iz Active Directory, odaberite korisnike za uvoz.



Ako je potrebno, možete konfigurirati automatsko dodavanje novi korisnici iz AD:

“Integracija direktorija → Sinhronizacija → Dodaj” itd. dodajte direktorij koji će se automatski sinkronizirati u određenom vremenskom intervalu.


Hajde da testiramo funkcionalnost MFA servera. Idite na odjeljak Korisnici. Za svoj nalog navedite broj telefona (ako već nije naveden) i odaberite metodu autentifikacije „Telefonski poziv“. Kliknite na dugme Test i unesite svoje korisničko ime i lozinku. Telefon bi trebao primiti poziv. Odgovaramo i pritisnemo #.

Konfiguriranje MFA servera za rad s Radius zahtjevima

Idite na odjeljak Radius Authentication i potvrdite izbor u polju za potvrdu “Omogući RADIUS Authentication”.

Dodajte novog klijenta tako što ćete navesti IP adresu NPS servera i zajednički tajni ključ. Ako se autentifikacija mora izvršiti za sve korisnike, označite odgovarajući okvir (u u ovom slučaju svi korisnici moraju biti dodati na MFA server).

Također morate osigurati da portovi navedeni za vezu odgovaraju portovima navedenim na NPS serveru i da ih firewall ne blokira.


Idite na karticu Cilj i dodajte Radius server.


Napomena: Ako nema centralnog NPS servera na mreži, IP adrese Radius klijenta i servera će biti iste.

Konfigurisanje RDG i NPS servera za rad zajedno sa MFA

Remote Desktop Gateway mora biti konfiguriran da šalje Radius zahtjeve MFA serveru. Da biste to učinili, otvorite svojstva gateway-a i idite na karticu “RDG CAP Store”, odaberite “NPS radi na centralnom serveru” i navedite adresu MFA servera i zajednički tajni ključ.


Zatim konfigurišemo NPS server. Proširite odjeljak „Radius klijenti i serveri → Grupe udaljenih radius servera“. Otvorite svojstva grupe “TS gateway server group” (grupa se kreira prilikom postavljanja RDG-a) i dodajte naš MFA server.

Prilikom dodavanja, na kartici “Load Balancing” povećavamo ograničenja vremena čekanja servera. Postavljamo "Broj sekundi bez odgovora, nakon čega se zahtjev smatra odbačenim" i "Broj sekundi između zahtjeva, nakon kojih se server smatra nedostupnim" u rasponu od 30-60 sekundi.

Na kartici “Authentication/Accounting” provjeravamo ispravnost navedenih portova i postavljamo zajednički tajni ključ.



Sada idemo na odjeljak „Radius klijenti i serveri → Radius klijenti“ i dodajmo MFA server, navodeći „Prijateljsko ime“, adresu i zajedničku tajnu.


Idite na odjeljak “Smjernice → Politike zahtjeva za povezivanje”. Ovaj odjeljak bi trebao sadržavati politiku kreiranu prilikom konfiguriranja RDG-a. Ova politika usmjerava Radius zahtjeve na MFA server.

Duplirajte politiku i idite na njena svojstva. Dodajte uslov koji odgovara “Nazivu prilagođenom klijentu” sa “Prijateljskim imenom” navedenim u prethodnom koraku.


Na kartici “Postavke” promijenite provajdera usluge provjere autentičnosti na lokalni server.


Ova politika će osigurati da kada se primi Radius zahtjev od MFA servera, zahtjev će biti obrađen lokalno, što će eliminirati petlju zahtjeva.

Hajde da to proverimo ovu politiku postavljen iznad originalnog.


U ovoj fazi, kombinacija RDG i MFA je u radnom stanju. Sljedeći koraci su neophodni za one koji žele moći koristiti autentifikaciju mobilne aplikacije ili žele korisnicima dati pristup nekim MFA postavkama putem korisničkog portala.

Instaliranje SDK-a, web usluge za mobilne aplikacije i korisničkog portala

Povezivanje sa ovim komponentama se vrši preko HTTPS protokola. Stoga morate instalirati SSL certifikat na server na kojem će biti raspoređeni.

Korisnički portal i web servis mobilnih aplikacija koriste SDK za komunikaciju sa MFA serverom.

Instaliranje SDK-a

SDK je instaliran na MFA serveru i zahtijeva IIS, ASP.NET, Basic Authentication, koji mora biti unaprijed instaliran pomoću Server Managera.

Za SDK instalacija idite na odeljak Web Service SDK na serveru za višefaktorsku autentifikaciju i kliknite na dugme za instaliranje, pratite čarobnjaka za instalaciju.

Instaliranje web usluge za mobilne aplikacije

Ova usluga je potrebna za interakciju mobilne aplikacije sa MFA serverom. Za ispravan rad usluge, računar na koji će biti instaliran mora imati pristup Internetu i port 443 mora biti otvoren za povezivanje sa Interneta.

Datoteka za instalaciju usluge nalazi se u folderu C:\Program Files\Azure višefaktorska autentifikacija na računaru sa instaliranim MFA. Pokrenite instalater i pratite čarobnjaka za instalaciju. Za praktičnost korisnika, naziv virtuelnog direktorija “MultiFactorAuthMobileAppWebService” možete zamijeniti kraćim.

Nakon instalacije idite u folder C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService i promijenite web.config fajl. IN ovaj fajl morate postaviti ključeve odgovorne za račun koji je dio sigurnosne grupe PhoneFactor Admins. Ovaj račun će se koristiti za povezivanje na SDK.


U istoj datoteci morate navesti URL na kojem je dostupan SDK.

Napomena: Povezivanje sa SDK-om se vrši pomoću SSL protokol, tako da se morate pozivati ​​na SDK po imenu servera (navedenom u SSL certifikatu), a ne po IP adresi. Ako je žalbu uložio lokalni naziv, morate dodati odgovarajući unos u hosts datoteku da biste koristili SSL certifikat.


Dodamo URL na kojem je web usluga mobilne aplikacije dostupna u aplikaciji Server za višefaktorsku autentifikaciju u odjeljak Mobilna aplikacija. Ovo je neophodno za pravilno generisanje QR koda na korisničkom portalu za povezivanje mobilnih aplikacija.

Takođe u ovom odeljku možete označiti polje za potvrdu „Omogući OATH tokene“, što vam omogućava da koristite mobilnu aplikaciju kao softverski token za generisanje jednokratnih lozinki na osnovu vremena.

Instaliranje korisničkog portala

Instalacija zahtijeva IIS, ASP.NET i ulogu kompatibilnosti metabaze IIS 6 (za IIS 7 ili noviji).

Ako je portal instaliran na MFA serveru, samo idite na odjeljak Korisnički portal u Serveru za višefaktorsku autentifikaciju, kliknite na dugme za instaliranje i pratite čarobnjaka za instalaciju. Ako je računar spojen na domen, tada će tokom instalacije biti kreiran korisnik koji je član PhoneFactor Admins sigurnosne grupe. Ovaj korisnik je potreban za sigurnu vezu sa SDK-om.


Kada instalirate na poseban server, morate kopirati instalacionu datoteku sa MFA servera (instalacioni fajl se nalazi u fascikli C:\Program Files\Multi-Factor Authentication Server). Instalirajte i uredite datoteku web.config na lokaciju C:\inetpub\wwwroot\MultiFactorAuth. Morate promijeniti ključ u ovoj datoteci USE_WEB_SERVICE_SDK od lažnog do istinitog. Navedite detalje naloga koji pripada grupi PhoneFactor Admins u ključevima WEB_SERVICE_SDK_AUTHENTICATION_USERNAME i WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD. I navedite URL adresu servisnog SDK-a, ne zaboravljajući da uredite hosts datoteku ako je potrebno kako bi SSL protokol funkcionirao.

U odeljku Korisnički portal dodajemo URL na kojem je korisnički portal dostupan u aplikaciji Server za višefaktorsku autentifikaciju.

Demonstracija kako Azure MFA radi za provjeru autentičnosti RDG veza

Mi ćemo razmotriti rad MVP-a sa strane korisnika. U našem slučaju, drugi faktor autentifikacije će biti mobilna aplikacija, jer celularnu mrežu ima niz ranjivosti koje omogućavaju, uz odgovarajuću pripremu, presretanje poziva i SMS-a.

Prije svega, korisnik će morati otići na korisnički portal i naznačiti svoj broj telefona (ako nije naveden u AD) i povezati mobilnu aplikaciju sa svojim nalogom. Idemo na portal pod našim računom i unosimo odgovore na tajna pitanja (trebat će nam ako se pristup nalogu vrati).


Zatim odaberite metodu provjere autentičnosti, u našem slučaju mobilnu aplikaciju i kliknite na dugme "Kreiraj aktivacijski kod". Generirat će se QR kod u koji se mora skenirati mobilna aplikacija.


Pošto je prilikom uvoza korisnika na MFA server postavljena autentifikacija pomoću PIN koda, od nas će biti zatraženo da ga kreiramo. Unesite željeni PIN kod i kliknite na "Potvrdi moju autentičnost". U mobilnoj aplikaciji morate potvrditi zahtjev koji se pojavi. Nakon ovih koraka, imamo aplikaciju povezanu sa nalogom i puni pristup portalu za promjenu ličnih postavki.

Lozinke mogu stvoriti veliku glavobolja u smislu sigurnosti i upravljivost za IT administratore preduzeća i organizacija. Korisnici često kreiraju jednostavne lozinke ili zapisuju lozinke kako ih ne bi zaboravili. Pored toga, nekoliko postupaka resetovanja lozinke je delotvorno ili bezbedno. S obzirom na ova ograničenja, kako se ove vrste sigurnosnih problema mogu ublažiti kada se pristupi mreži udaljeni korisnici? Kako možete učiniti lozinke vaše kompanije sigurnijim, znajući da mnogi korisnici zapisuju svoje lozinke?

Postoji rješenje - ovo je implementacija u organizaciji dodatni sistem zaštita pristupa zasnovana na unošenju jednokratnih lozinki (OTP - One Time Password), koje se generišu na mobilni uređaj vaš zaposlenik. Prijelaz na autentifikaciju zasnovanu na jednokratnim lozinkama obično se događa u situaciji kada se podrazumijeva da su standardne dugoročne lozinke nedovoljne sa sigurnosnog gledišta, a da su istovremeno mogućnosti korištenja pametnih kartica ograničene, tj. na primjer, u situaciji kada se mobilni klijenti široko koriste.

Naša kompanija se razvila tehnološko rešenje , što će vam omogućiti da dobijete dodatna linija odbrane za terminalski server ili 1C server na osnovu jednokratnih lozinki , na koji se zaposleni povezuju na daljinu.

Obim posla za implementaciju i konfiguraciju OTP sistema

Specijalizovani softver je instaliran i konfigurisan na vašem serveru za rad sa sistemom autentifikacije pristupa zasnovanom na jednokratnim lozinkama (OTP) Svi zaposleni u organizaciji kojima je potreban pristup serveru su prijavljeni u OTP sistem Za svakog zaposlenog vrši se početno podešavanje mobilni telefon uz instalaciju programa za generiranje jednokratne lozinke

Počinje trošak uvođenja u organizaciju sistema za autentifikaciju pristupa za terminalski server ili 1C server zasnovan na jednokratnim lozinkama (OTP). od 6.400 rub..

U slučajevima kada će OTP sistem biti raspoređen u sprezi sa iznajmljivanjem infrastrukture u našem sigurnom „oblaku“, popust na implementaciju sistema zaštite pomoću jednokratnih lozinki (OTP) može dostići 50%.

Jednokratne lozinke - dodatni nivo sigurnosti podataka

Tradicionalna, statična lozinka se obično mijenja samo kada je potrebno: ili kada istekne, ili kada je korisnik zaboravi i želi da je resetuje. Zato što su lozinke keširane tvrdi diskovi računar i pohranjeni na serveru, ranjivi su na hakovanje. Ovaj problem je posebno akutan za laptop računare jer ih je lako ukrasti. Mnoge kompanije obezbeđuju zaposlenima laptop računare i otvaraju svoje mreže za daljinski pristup. Oni također zapošljavaju zaposlene na određeno vrijeme i dobavljače. U takvom okruženju, jednostavno rješenje statičke lozinke postaje nedostatak.
Za razliku od statične lozinke, jednokratna lozinka mijenja se svaki put kada se korisnik prijavi na sistem i vrijedi samo kratko vrijeme (30 sekundi). Same lozinke se kreiraju i šifriraju pomoću složenog algoritma koji ovisi o mnogim varijablama: vremenu, broju uspješnih/neuspješnih prijava, nasumično generiranim brojevima, itd. Ovaj naizgled složen pristup zahtijeva jednostavne radnje od korisnika - Instalirajte na svoj telefon posebna aplikacija, koji se sinkronizira jednom sa serverom i potom generiše jednokratnu lozinku. Sa svakom novom uspješnom prijavom, klijent i server se automatski ponovo sinkroniziraju nezavisno jedan od drugog pomoću posebnog algoritma. Vrijednost brojača se povećava svaki put kada se od uređaja traži OTP vrijednost i kada se korisnik želi prijaviti, on unosi OTP-ove koji su trenutno prikazani na njegovom mobilnom uređaju.

Metode zaštite pri korištenju provjere autentičnosti lozinkom. Da biste zaštitili svoje lozinke od hakovanja, trebali biste postaviti odgovarajuću politiku. Da biste to učinili, koristite izbornik Start->Administrative Tools->Group Policy Management da pokrenete GPMC Group Policy Management Console i odaberite željeni objekt grupna politika odjeljak Konfiguracija računala->Smjernice->Sigurnosne postavke->Smjernice računa->Politika lozinke Pogledajte sl. 1 (Upravljanje postavkama lozinke).


Rice. 1 Upravljajte postavkama lozinke.

Možemo postaviti minimalnu dužinu lozinke, što će nam omogućiti da izbjegnemo kratke lozinke (Minimum lozinka dužina). Da bi korisnik mogao specificirati složene lozinke zahtjev za složenost treba uključiti (Lozinka mora upoznaj složenost zahtjevi).

Kako biste osigurali da se vaša lozinka redovno mijenja, morate je postaviti maksimalni rokživot (Maksimum lozinka Dob).

Da biste spriječili korisnike da ponavljaju stare lozinke, morate konfigurirati pohranu historije lozinki (Izvršiti lozinka istorija) .

I na kraju, kako korisnik ne bi promijenio svoju lozinku u staru višestrukom promjenom lozinke, postavite minimalni period tokom kojeg se lozinka ne može mijenjati (Minimum lozinka Dob).

Kako bismo se zaštitili od napada na rječnik, postavit ćemo zaključavanje računa ako se lozinka više puta unese pogrešno. Da biste to učinili, trebate odabrati potreban odjeljak GPO u GPMC konzoli za upravljanje pravilima grupe Kompjuter Konfiguracija-> Politike-> Sigurnost Postavke-> Račun Politike-> Račun Lockout Policy . Vidi sl. 2 (Upravljanje zaključavanjem korisničkog naloga).

Rice. 2 Upravljajte zaključavanjem korisničkog računa.

Da biste konfigurirali račun da bude trajno zaključan (prije nego ga administrator otključa), trebate postaviti parametar trajanja zaključavanja na nulu (Račun lockout trajanje).

U brojaču broja neuspješnih pokušaja prijave (Račun lockout prag) potrebno je navesti potrebnu vrijednost. U većini slučajeva prihvatljivo je 3-5 pokušaja prijave.

Na kraju, trebali biste postaviti interval za resetiranje brojača neuspjelih pokušaja (Resetovati račun lockout counter poslije).

Za zaštitu od " Trojanski konji» treba koristiti antivirusni agenti i neovlašteno blokiranje softver.

Da bi se ograničila mogućnost korisnika da unesu viruse u informacioni sistem, opravdano je: postavljanje zabrane rada sa eksternih uređaja(CD, DVD, Flash), strogi UAC mod, koristiti odvojeno stojeći internet kiosci zasnovani na računarima koji nisu uključeni radna mreža. I na kraju, uvođenje strogih propisa o radu koji definišu pravila kako korisnici rade na korporativnoj mreži (zabrana dijeljenja akreditiva sa bilo kim, zabrana ostavljanja akreditiva na pristupačnim mjestima, zahtjevi za obavezno blokiranje radne stanice pri napuštanju radnog mjesta , itd.. P.).

Kao rezultat toga, moći ćemo smanjiti rizike povezane s narušavanjem sigurnosti kompanije.

Pretpostavimo da je sve ovo urađeno. Međutim, prerano je reći da smo uspjeli osigurati sigurnu autentifikaciju u našem sistemu.

Ljudski faktor je najveća prijetnja.

Još uvijek postoje prijetnje s kojima se nismo uspjeli nositi. Jedan od najznačajnijih - ljudski faktor. Korisnici naših informacionih sistema nisu uvek dovoljno savesni i, uprkos objašnjenjima administratora bezbednosti, zapisuju svoje akreditive (korisničko ime i lozinku) i ne mare za tajnost ovog povjerljiva informacija. Više puta sam pronašao naljepnice na monitoru, vidi sl. 3, ili ispod tastature vidi sl. 4 sa korisničkim imenom i lozinkom.

Rice. 3. Divan poklon za napadača, zar ne?

Rice. 4. Još jedan poklon za provalnika.

Kao što vidimo, duge i složene lozinke se uvode u sistem i asocijativni niz se jasno ne vidi. Međutim, korisnici su pronašli "efikasan" način da pamte i pohranjuju vjerodajnice...

Dakle, vidite da je u ovom slučaju došla do izražaja funkcija koju sam pomenuo gore: dugačke i složene lozinke se snimaju i možda neće biti pravilno pohranjene.

Insider

Još jedna značajna sigurnosna prijetnja je mogućnost da napadač fizički dobije pristup radnoj stanici legitimnog korisnika i prenese povjerljive informacije trećim stranama. To je mi pričamo o tome o situaciji u kojoj se u kompaniji nalazi zaposlenik koji krade informacije od svojih kolega.

Sasvim je očigledno da je vrlo teško osigurati “fizičku” sigurnost radne stanice korisnika. Možete jednostavno povezati hardverski keylogger na razmak tastature, presrećući signal iz bežične tastature također je moguće. Takvi uređaji postoje. Naravno, niko neće ući u kancelariju kompanije, ali svi znaju da je najopasniji interni špijun. On već ima fizički pristup vašem sistemu, a postavljanje keyloggera neće biti teško, pogotovo jer su ovi uređaji dostupni širokom spektru ljudi. Osim toga, programi keyloggera se ne mogu sniziti. Zaista, uprkos svim naporima administratora, mogućnost instaliranja ovakvog „špijunskog“ softvera nije isključena. Da li korisnik uvijek blokira svoje radna stanica napustiti svoje radno mjesto? Da li je administrator u mogućnosti informacioni sistem osigurati da korisniku ne budu dodijeljene pretjerane dozvole, posebno ako je potrebno koristiti stare softverskih proizvoda? Da li administrator, posebno u maloj kompaniji, uvijek ima dovoljno kvalifikacija da implementira preporuke softvera i hardver o izgradnji sigurnih informacionih sistema?

Dakle, možemo zaključiti da je autentifikacija lozinkom u principu nepouzdana. Stoga je potrebna višefaktorska autentifikacija, i to takve vrste da se korisnička lozinka ne upisuje na tastaturi.

Šta nam može pomoći?

Ima smisla razmotriti dvofaktorsku autentifikaciju: 1. faktor je posjedovanje lozinke, drugi je poznavanje PIN koda. Lozinka domene se više ne kuca na tastaturi, što znači da je ne presreće keylogger. Presretanje lozinke domene prepuno je mogućnosti prijave, presretanje PIN koda nije toliko opasno, jer je dodatno potrebna pametna kartica.

Na ovo se može tvrditi da korisnik može ostaviti svoju karticu u čitaču i ispisati PIN na naljepnici, kao i do sada. Međutim, postoje kontrolni sistemi koji mogu blokirati napuštenu karticu, kao što je to implementirano u bankomatima. Dodatno, moguće je staviti propusnicu na karticu za ulazak/izlazak iz kancelarije, odnosno možemo koristiti karticu sa RFID oznakom, kombinujući na taj način sistem autentifikacije u servisu imenika sa fizičkim sistemom kontrole pristupa. U tom slučaju, da bi otvorio vrata, korisniku će biti potrebna njegova pametna kartica ili USB token, pa će biti primoran da je uvijek nosi sa sobom.

osim toga, savremena rešenja za dvofaktorsku autentifikaciju, ne zahtijevaju samo sposobnost provjere autentičnosti u AD ili AD DS-u. Upotreba pametnih kartica i USB ključeva također pomaže u mnogim drugim slučajevima, na primjer pri pristupu javnosti e-mail, na internet trgovine gdje je potrebna registracija, na aplikacije koje imaju svoj kataloški servis itd. itd.

Tako možete dobiti praktično univerzalni lijek autentifikaciju.

Implementacija dvofaktorske autentifikacije zasnovane na asimetrična kriptografija u ADDS.

Active Directory podržava autentifikaciju pametnom karticom od Windowsa 2000.

U svojoj srži, mogućnost provjere autentičnosti pomoću pametnih kartica sadržana je u ekstenziji PKINIT (inicijalizacija javnog ključa) za protokol Kerberos RFC 4556. Vidi. Ekstenzija PKINIT dozvoljava korištenje certifikata javnog ključa tokom faze Kerberos pre-autentifikacije.

Ovo omogućava korištenje pametnih kartica. Odnosno, možemo govoriti o mogućnosti dvofaktorske autentifikacije u Microsoft sistemi baziran na standardnim alatima, počevši od Windows 2000, pošto je Kerberos + PKINIT šema već implementirana.

Bilješka. Pre-autentifikacijaKerberos– proces koji osigurava dodatni nivo sigurnost. Izvršeno prije izdavanjaTGT (Ulaznica Odobrenje Ulaznica) sa servera za distribuciju ključeva (K.D.C.). Koristi se u protokoluKerberos v. 5 za suzbijanje oflajn napada pogađanja lozinke. Saznajte više o tome kako protokol funkcioniraKerberosmože se naći u RFC 4120.Cm

Naravno, govorimo o računarima koji su deo domena. Ako postoji potreba da se pribjegne dvofaktorskoj autentifikaciji prilikom rada u radna grupa, ili kada koristite više ranije verzije operativnim sistemima, onda ćemo se morati obratiti softveru treće strane, na primjer SafeNet (Aladdin) eToken Network Logon 5.1. Cm.

Prijava se može osigurati pomoću usluge imenika domene ili lokalne usluge imenika. U ovom slučaju, korisnička lozinka se ne upisuje na tastaturi, već se prenosi iz sigurnog skladišta na pametnu karticu.

Autentifikacija pomoću pametnih kartica implementirana je kroz Kerberos PKINIT ekstenziju, ova ekstenzija pruža mogućnost korištenja asimetričnih kriptografskih algoritama.

Što se tiče uslova za uvođenje upotrebe pametnih kartica u sprezi sa PKINIT-om, za rad Windows sistemi 2000, Windows 2003 Server, oni su sljedeći:

· Svi kontroleri domena i sve klijentski računari unutar šume u kojoj se implementira naše rješenje, mora se vjerovati korijenskom certifikacijskom tijelu (Certification Authority).

· CA koji izdaje sertifikate za korišćenje pametnih kartica mora biti smešten u NT Authority repozitorijum

· Certifikat mora sadržavati identifikatore za prijavu na pametnu karticu i autentifikaciju klijenta

· Certifikat za pametne kartice mora sadržavati UPN korisnika.

· Sertifikat i privatni ključ moraju biti smješteni u odgovarajuće dijelove pametne kartice, a privatni ključ mora biti smješten u sigurnom području memorije pametne kartice.

· Certifikat mora naznačiti putanju do CRL distribucijske točke liste opoziva certifikata

· Svi kontroleri domena moraju imati instaliran sertifikat Autentikacija kontrolera domene, ili Kerberos autentifikacija, budući da je implementiran proces međusobne autentifikacije klijenta i servera.

Brojne promjene u zahtjevima dogodile su se u operativnim sistemima počevši od Windows Server 2008:

· CRL ekstenzija više nije potrebna u certifikatima za prijavu na pametne kartice

· Sada podržava mogućnost uspostavljanja odnosa između korisničkog naloga i sertifikata

· Sertifikat se može upisati u bilo koji pristupni dio pametne kartice

· EKU ekstenzija ne mora uključiti Smart Card Logon OID, ali da budemo pošteni, ako planirate da koristite jedan šablon certifikata za klijente na svim operativnim sistemima, onda, naravno, Smart Card Logon OID mora biti omogućen.

Nekoliko riječi o samoj proceduri prijave klijenta. Ako govorimo o operativnim sistemima iz Windows Vista i gore, treba napomenuti da su se ovdje dogodile brojne promjene:

· Prvo, postupak prijave pametne kartice se više ne pokreće automatski kada umetnete pametnu karticu u čitač kartica ili povežete svoj USB ključ na USB port, tj. morat ćete pritisnuti Ctrl+Alt+Delete.

· Drugo, nova mogućnost korištenja bilo kojeg slota za pametnu karticu za pohranjivanje certifikata daje korisniku izbor između raznih identifikacijskih objekata pohranjenih na kartici, dok je trenutno potreban certifikat prikazan kao dostupan za korištenje.

zaključci

Dakle, ispitali smo nekoliko glavnih aspekata u vezi s teorijskim dijelom dvofaktorske autentifikacije u domenskim uslugama Active Directory i možemo sumirati.

Osiguranje sigurnosti procesa autentifikacije sistema je od ključnog značaja. Vrste razbijanja lozinki koje danas postoje stvaraju potrebu za višefaktorskom autentifikacijom.

Za malu kompaniju možete ograničiti se na strogu politiku zaštite vjerodajnica, implementirati antivirusni softver i uskratiti korisnicima mogućnost rada sa vanjski mediji informacije za blokiranje pokretanja neovlaštenog softvera, implementaciju korisničkih propisa itd. itd.

Kad dođe velika kompanija, ili o firmi za koju postoji jasan interes napadača - ta sredstva nisu dovoljna. Greške i insajderske informacije mogu upropastiti vaše napore da izgradite sigurnosni sistem, tako da morate odabrati drugi put. Ovdje već ima smisla govoriti o uvođenju sigurne autentifikacije.

Korištenje dvofaktorske autentifikacije je dobro rješenje sa sigurnosne tačke gledišta.

Sada imamo drugi faktor autentifikacije; osim PIN koda, korisnik mora imati i pametnu karticu ili USB ključ.

Korištenje pametnih kartica ili USB ključevi daje nam mogućnost da obezbijedimo dvofaktornu autentifikaciju u AD i AD DS okruženjima.

U jednom od sljedećih članaka reći ću vam kako se dvofaktorska autentifikacija implementira u praksi. Pogledat ćemo implementaciju i konfiguraciju infrastrukture ovlaštenja za certifikate (PKI). Windows baziran Server 2008 Enterprise R2.

Bibliografija.

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 - "Vodič za razumijevanje identifikacije i autentifikacije u pouzdanim sistemima", objavljen od strane U.S. Nacionalni centar za kompjutersku sigurnost.

RFC4120 – Kerberos mrežna usluga provjere autentičnosti (V5)

RFC4556 – Kriptografija javnog ključa za početnu autentifikaciju u Kerberos (PKINIT)

Brian Komar Windows Server 2008 PKI i sigurnost certifikata

Leonid Šapiro,
MCT, MCSE:S, MCSE:M, MCITP EA, TMS certificirani trener

Najbolji članci na ovu temu