Neizmantojiet piekļuves atslēgas lietotāja datu šifrēšanai

Pasoles ir aizraujošākā autentifikācijas izstrāde pēdējo gadu laikā. Tie novērš pikšķerēšanu, noņem paroļu slogu un nodrošina netraucētu pieteikšanos, ko nodrošina publiskās atslēgas kriptogrāfija. Taču izstrādātāju kopienās izplatās bīstams nepareizs priekšstats: ja piekļuves atslēgas ir kriptogrāfiskas, tās noteikti var šifrēt arī lietotāja datus. Viņi nevar — un mēģinājumi tos izmantot šādā veidā radīs trauslas, neuzticamas sistēmas, kas var neatgriezeniski bloķēt jūsu lietotājus no viņu pašu informācijas. Lai saprastu, kāpēc, ir skaidri jāizpēta, kas patiesībā ir piekļuves atslēgas, kādas ir šifrēšanas prasības un kur tās atšķiras tādos veidos, kas ir ārkārtīgi svarīgi jebkurai platformai, kas apstrādā sensitīvus uzņēmējdarbības datus.

Autentifikācija un šifrēšana ir būtiski atšķirīgi uzdevumi

Autentifikācija atbild uz vienu jautājumu: "Vai jūs esat tas, par ko uzdodat?" Šifrēšana atbild uz pavisam citu: "Vai šie dati var palikt nelasāmi visiem, izņemot pilnvarotās puses?" Šīm divām problēmām ir kopīgas kriptogrāfijas primitīvas, taču inženiertehniskās prasības krasi atšķiras. Autentifikācijai ir jānotiek vienu reizi sesijā, tā var izturēt neregulāras kļūmes ar elegantiem atkāpšanās gadījumiem, un tai nav katru reizi jārada viena un tā pati izvade. Šifrēšanai ir nepieciešama deterministiska, reproducējama atslēgas piekļuve visā datu kalpošanas laikā — tas var būt gadi vai gadu desmiti.

Kad autentificējat ar ieejas atslēgu, ierīce ģenerē kriptogrāfisku parakstu, kas apliecina, ka jums pieder ar jūsu kontu saistītā privātā atslēga. Serveris pārbauda šo parakstu un piešķir piekļuvi. Nevienā brīdī serveris vai pat jūsu lietojumprogramma nevar piekļūt pašam privātās atslēgas materiālam. Šī ir funkcija, nevis ierobežojums. Viss piekļuves atslēgu drošības modelis ir atkarīgs no privātās atslēgas, kas nekad neiziet no jūsu ierīces drošā anklāva. Bet šifrēšanai ir nepieciešams izmantot atslēgu, lai pārveidotu datus, un vēlāk izmantot to pašu atslēgu (vai tās ekvivalentu), lai mainītu transformāciju. Ja nevarat droši piekļūt atslēgai, jūs nevarat droši atšifrēt.

Platformām, piemēram, Mewayz, kas pārvalda sensitīvu biznesa informāciju — rēķinus, algu ierakstus, CRM kontaktpersonas, HR dokumentus 207 moduļos — ir vajadzīgas šifrēšanas stratēģijas, kas balstītas uz atslēgām, kas ir izturīgas, atkopjamas un pastāvīgi pieejamas. Tā izveide uz pamata, kas īpaši izstrādāta, lai novērstu piekļuvi atslēgai, ir arhitektoniska pretruna.

Kāpēc ieejas atslēgas netiek izmantotas kā šifrēšanas atslēgas

WebAuthn specifikācija, kas ir piekļuves atslēgu pamatā, tika apzināti izstrādāta ar ierobežojumiem, kas padara šifrēšanas izmantošanu nepraktisku. Izprotot šos ierobežojumus, tiek atklāts, kāpēc šī nav plaisa, ko gudra inženierija var pārvarēt — tā ir būtiska dizaina robeža.

• Bez atslēgu eksportēšanas: piekļuves atslēgas reģistrācijas laikā ģenerētās privātās atslēgas tiek glabātas drošos anklāvos, kas nodrošināti ar aparatūru (TPM, Secure Enclave vai līdzvērtīgi). Operētājsistēmas un pārlūkprogrammas API nenodrošina mehānismu izejmateriāla izvilkšanai. Varat lūgt atslēgai kaut ko parakstīt, bet jūs nevarat nolasīt pašu atslēgu.
• Nedeterministiska atslēgu ģenerēšana: izveidojot ieejas atslēgu vienam un tam pašam lietotājam citā ierīcē, tiek izveidots pilnīgi atšķirīgs atslēgu pāris. Nav sākuma frāzes, nav atvasināšanas ceļa, nav iespējas rekonstruēt to pašu atslēgu citā ierīcē. Katra reģistrācija ir kriptogrāfiski neatkarīga.
• Pieejamība atkarībā no ierīces: pat ar ieejas atslēgu sinhronizāciju (iCloud Keychain, Google Password Manager), pieejamība ir atkarīga no ekosistēmas līdzdalības. Lietotājs, kurš reģistrējas iPhone tālrunī un vēlāk pārslēdzas uz Android, var zaudēt piekļuvi. Lietotājs, kura ierīce ir pazaudēta, nozagta vai atiestatīta uz rūpnīcas iestatījumiem, saskaras ar to pašu problēmu.
• Tikai atbilde uz izaicinājumu: WebAuthn API atklāj navigator.credentials.get(), kas atgriež parakstītu apgalvojumu, nevis neapstrādātu atslēgas materiālu. Jūs saņemat parakstu, izmantojot servera nodrošināto izaicinājumu — tas ir noderīgs identitātes apliecināšanai, nederīgs šifrēšanas atslēgas iegūšanai.
• Nav algoritma elastīguma: ieejas atslēgas parasti izmanto ECDSA ar P-256 līkni. Pat ja jūs varētu piekļūt atslēgai, ECDSA ir parakstīšanas algoritms, nevis šifrēšanas algoritms. Jums būs nepieciešamas papildu transformācijas (ECDH atslēgas līgums, KDF atvasinājums), ko API neatbalsta šajā kontekstā.

Daži izstrādātāji ir ierosinājuši risinājumus — piemēram, izmantojot WebAuthn paplašinājumu PRF (pseidogadījuma funkcija), lai autentifikācijas laikā iegūtu simetriskas atslēgas. Lai gan šis paplašinājums pastāv specifikācijā, pārlūkprogrammas atbalsts joprojām ir nekonsekvents, tas nav pieejams daudzās mobilajās platformās un joprojām pārmanto ierīces saistīšanas problēmu. Atslēgu, kas vienā ierīcē iegūta, izmantojot PRF, nevar reproducēt citā ierīcē ar atšķirīgu ieejas atslēgu, pat ar to pašu lietotāja kontu.

Datu zaudēšanas scenārijs, kuru neviens nevēlas nosūtīt

Apsveriet, kas notiek, ja šifrējat lietotāja datus ar atslēgu, kas iegūta no piekļuves atslēgas. Pirmajā dienā viss darbojas skaisti. Lietotājs piesakās, tiek iegūta atslēga, dati tiek šifrēti un atšifrēti nemanāmi. Pēc tam trīs mēnešus vēlāk viņu tālrunis iekrīt ezerā.

Izmantojot tradicionālo autentifikāciju, ierīces pazaudēšana rada neērtības. Lietotājs atkopj savu kontu pa e-pastu, iestata jaunus akreditācijas datus un turpina strādāt. Bet, ja viņu dati tika šifrēti ar atslēgu, kas saistīta ar tagad iegremdētās ierīces drošo anklāvu, šie dati ir pazuduši. Nav “grūti atkopjams” — pagājis kriptogrāfiski neatgriezenisks. Neviena klientu atbalsta biļete, bez konta atkopšanas plūsmas, neviena vadības eskalācija nevar mainīt matemātiku. Dati tikpat labi varētu būt dzēsti.

Šifrēšanas sistēmas dizaina galvenais noteikums: ja jūsu atslēgu pārvaldības stratēģijai ir kāds viens kļūmes punkts, kas neatgriezeniski iznīcina piekļuvi lietotāja datiem, jūs neesat izveidojis drošības līdzekli — esat izveidojis datu zaudēšanas mehānismu ar papildu darbībām.

Uzņēmumam, kas darbojas, izmantojot platformu — 50 klientu attiecību pārvaldīšana CRM, ikmēneša algu apstrāde 30 darbiniekiem, transportlīdzekļu parka izsekošana — pastāvīgs datu zudums no nomestā tālruņa nav mazsvarīga UX problēma. Tā ir biznesa nepārtrauktības katastrofa. Tieši tāpēc Mewayz arhitektūra atdala autentifikācijas mehānismus no datu aizsardzības slāņiem, nodrošinot, ka neviena atsevišķa ierīces kļūme nevar apdraudēt piekļuvi svarīgai biznesa informācijai visos integrētajos moduļos.

Ko vajadzētu tā vietā izmantot

Labās ziņas ir tādas, ka pastāv vispāratzītas lietotāju datu šifrēšanas metodes, neiekļūstot piekļuves atslēgu slazdā. Šīs pieejas ir pārbaudītas, plaši atbalstītas un īpaši izstrādātas šifrēšanas lietošanai.

Servera puses šifrēšana ar pārvaldītām atslēgām joprojām ir vispraktiskākā izvēle lielākajai daļai lietojumprogrammu. Jūsu platforma šifrē datus miera stāvoklī, izmantojot atslēgas, kas tiek pārvaldītas, izmantojot atbilstošu atslēgu pārvaldības pakalpojumu (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault vai līdzvērtīgu. Lietotājs autentificējas (ja vēlaties, ar piekļuves atslēgām!), un serveris šifrēšanu un atšifrēšanu apstrādā pārredzami. Tādā veidā lielākā daļa SaaS platformu aizsargā datus, un tas darbojas, jo atslēgas ir izturīgas, dublētas, grozāmas un neatkarīgas no jebkuras lietotāja ierīces.

No paroles iegūtās šifrēšanas atslēgas (atslēgu atvasināšanai izmanto Argon2id vai scrypt) ir piemērotas, ja nepieciešama patiesa nulles zināšanu šifrēšana, kad pat serveris nevar nolasīt lietotāja datus. Kompromiss ir tāds, ka paroles pazaudēšana nozīmē datu zaudēšanu, taču paroles var iegaumēt, pierakstīt un saglabāt paroļu pārvaldniekos — tās nav bloķētas aparatūras anklāvā. Tādos pakalpojumos kā 1Password un Standard Notes šī pieeja tiek izmantota efektīvi.

1. Izmantojiet piekļuves atslēgas (vai jebkuru spēcīgu metodi) autentifikācijai — lietotāja identitātes pārbaudei.
2. Pēc autentifikācijas atgūstiet vai izgūstiet šifrēšanas atslēgas, izmantojot atsevišķu, šim nolūkam izveidotu atslēgu pārvaldības sistēmu.
3. Ieviesiet atslēgu darījuma vai atkopšanas mehānismus — atkopšanas atslēgas, vairāku ierīču atslēgu sinhronizāciju vai organizācijas atslēgu glabāšanu uzņēmumu kontiem.
4. Šifrējiet datus miera stāvoklī un sūtīšanas laikā, izmantojot AES-256-GCM vai XChaCha20-Poly1305 ar atslēgām no jūsu KMS.
5. Periodiski pagrieziet atslēgas un uzturiet šifrētu atslēgu dublējumkopijas, kas pārdzīvo jebkuru atteices punktu.

Šī problēmu nošķiršana nav tikai paraugprakse — tā ir vienīgā arhitektūra, kas ļauj jaunināt autentifikācijas metodes neatkarīgi no šifrēšanas stratēģijas. Kad piekļuves atslēgas galu galā attīstās vai tiek aizstātas ar kaut ko labāku, jūsu šifrētie dati joprojām ir lieliski pieejami.

PRF paplašinājums: solījums un nepilnības

Izstrādātāji, kas stingri ievēro WebAuthn specifikāciju, var norādīt uz paplašinājumu prf kā potenciālu tiltu starp piekļuves atslēgām un šifrēšanu. Šis paplašinājums ļauj paļautajai pusei autentifikācijas ceremonijas laikā pieprasīt pseidogadījuma vērtību, kas iegūta no piekļuves atslēgas slepenā materiāla. Teorētiski šī vērtība varētu kalpot kā šifrēšanas atslēga vai sākums.

Praksē PRF paplašinājums saskaras ar ievērojamiem pārņemšanas šķēršļiem. Sākot ar 2026. gada sākumu, atbalsts dažādās pārlūkprogrammās un platformās ievērojami atšķiras. Safari ieviešana atšķiras no Chrome. Daudzas Android ierīces to vispār neatbalsta. Aparatūras drošības atslēgām ir nekonsekvents atbalsts. Jebkurai platformai, kas apkalpo daudzveidīgu lietotāju bāzi — un Mewayz apkalpo vairāk nekā 138 000 lietotāju visās lielākajās operētājsistēmās un ierīču veidos, šifrēšanas izveide, izmantojot funkciju ar nevienmērīgu pieejamību, ir praktiski neiespējama.

Vēl būtībā PRF neatrisina vairāku ierīču problēmu. Pseidogadījuma izvade tiek iegūta no konkrētas piekļuves atslēgas konkrētajā ierīcē. Lietotājs, kurš reģistrē piekļuves atslēgas gan savā klēpjdatorā, gan tālrunī, saņem divas dažādas PRF izvades vienam kontam. Jums ir jāšifrē dati ar vienas ierīces atvasinātu atslēgu un pēc tam kaut kādā veidā atkārtoti jāšifrē vai jākopīgo šī atslēga ar otru ierīci, kas jebkurā gadījumā ļaus jums atgriezties pie pareizas atslēgu pārvaldības sistēmas izveides. Tajā brīdī no ieejas atslēgas iegūtā atslēga padara sarežģītību, nepalielinot drošību.

Nodarbības celtniekiem: izmantojiet pareizo rīku pareizajam slānim

Kārdinājumu izmantot piekļuves atslēgas šifrēšanai rada labs instinkts — izstrādātāji vēlas izmantot spēcīgu kriptogrāfiju un samazināt to noslēpumu skaitu, kas lietotājiem jāpārvalda. Taču drošības inženierija pamatā ir pareiza primitīva izmantošana pareizajā slānī. Gan slēdzene, gan seifs aizsargā vērtslietas, taču jūs nedrīkstat uzstādīt aizbīdni velvē vai mēģināt nēsāt seifu kabatā.

Piekļuves atslēgas ir izcilas to paredzētajā nolūkā. Viņi ir samazinājuši ar pikšķerēšanu saistīto kontu pārņemšanu par līdz pat 99,9%, izmantojot Google iekšējo izvietošanu. Tie pilnībā novērš akreditācijas datu pildīšanas uzbrukumus. Tie nodrošina pieteikšanās pieredzi, kas vienlaikus ir drošāka un ērtāka nekā paroles. Tas ir ievērojams sasniegums, un ar to pietiek. Prasīt piekļuves atslēgām, lai atrisinātu arī šifrēšanu, ir tas pats, kas lūgt ugunsmūri darboties arī kā rezerves sistēma — tas pārprot arhitektūru.

Veidojot platformas, kas apstrādā sensitīvas uzņēmējdarbības operācijas, arhitektūrai ir jāatspoguļo skaidras robežas. Autentifikācija pārbauda identitāti. Autorizācija nosaka piekļuvi. Šifrēšana aizsargā datus miera stāvoklī un sūtīšanas laikā. Atslēgu pārvaldība nodrošina, ka šifrēšanas atslēgas iztur ierīces zudumu, darbinieku mainību un infrastruktūras izmaiņas. Katram slānim ir īpaši izstrādāti rīki, un to sajaukšana rada trauslumu, kas parādās vissliktākajos brīžos — kad lietotājam visvairāk ir nepieciešams piekļūt saviem datiem, bet tas nevar.

Pareizas drošības nodrošināšana, to nepārliekot sarežģījot

Lielākajai daļai SaaS lietojumprogrammu un biznesa platformu praktiskais ieteikums ir vienkāršs: autentifikācijai ar entuziasmu izmantojiet piekļuves atslēgas un veiciet šifrēšanu pilnībā servera pusē, izmantojot pārvaldītu KMS. Tas nodrošina jūsu lietotājiem vislabāko pieteikšanās pieredzi, kas šobrīd ir pieejama, vienlaikus aizsargājot viņu datus ar infrastruktūru, kas īpaši izstrādāta izturībai un atkopšanai.

Ja jūsu draudu modelim patiešām ir nepieciešama pilnīga šifrēšana, kad serveris nevar piekļūt vienkārša teksta datiem, ieguldiet pienācīgā klienta puses šifrēšanas arhitektūrā ar paroles atvasinātām atslēgām, atkopšanas kodiem un organizācijas atslēgu darījuma kontu, nevis no ieejas atslēgas atvasinātiem īsinājumtaustiņiem. Inženiertehniskie ieguldījumi ir lielāki, taču alternatīva ir tādas sistēmas piegāde, kas galu galā neatgriezeniski iznīcinās kāda lietotāja datus.

Drošības lēmumi laika gaitā sarežģī. Šodien izmantotais īsceļš kļūst par migrācijas murgu trīs gadu laikā, kad mainās pamatā esošā primitīva, ierīces ekosistēma maina savu sinhronizācijas politiku vai pārlūkprogramma noveco paplašinājumu. Jau no paša sākuma balstoties uz pareizajām abstrakcijām — autentifikācija kā autentifikācija, šifrēšana kā šifrēšana, katrai no tām ir savs atslēgas dzīves cikls — ir pamats, kas ļauj platformām mērogot līdz simtiem tūkstošu lietotāju bez tikšķošas bumbas ar laika degli, kas ir aprakts kriptogrāfiskajā cauruļvadā.

Bieži uzdotie jautājumi

Kāpēc piekļuves atslēgas nevar izmantot, lai šifrētu lietotāja datus?

Piekļuves atslēgas ir paredzētas tikai autentifikācijai, nevis šifrēšanai. Tie paļaujas uz publiskās atslēgas kriptogrāfiju, lai verificētu jūsu identitāti pieteikšanās laikā, taču privātā atslēga nekad neatstāj jūsu ierīci un nav pieejama lietojumprogrammām. Šifrēšanai nepieciešamas stabilas, reproducējamas atslēgas, kas laika gaitā var konsekventi atšifrēt datus. Ieejas atslēgām trūkst šīs iespējas pēc konstrukcijas, tādēļ tās nav pilnībā piemērotas saglabātās lietotāja informācijas aizsardzībai.

Kas notiek, ja tomēr mēģināt šifrēt datus ar piekļuves atslēgām?

Jūs riskējat izveidot trauslu sistēmu, kurā lietotāji tiks neatgriezeniski bloķēti no saviem datiem. Ieejas atslēgas var atsaukt, pagriezt vai nomainīt dažādās ierīcēs bez brīdinājuma. Ja šifrētie dati ir piesaistīti noteiktai piekļuves atslēgai, kas tiek dzēsta vai atjaunināta, atkopšanas ceļa nav. Tas rada katastrofālu datu zaudēšanas scenāriju, kuru nevar droši novērst nekādi inženiertehniskie risinājumi.

Kas izstrādātājiem būtu jāizmanto datu šifrēšanas piekļuves atslēgu vietā?

Izstrādātājiem ir jāizmanto īpaši izstrādāti šifrēšanas risinājumi, piemēram, AES-256 ar pareizu atslēgu pārvaldību, aplokšņu šifrēšanu vai izveidotas bibliotēkas, piemēram, libsodium. Saglabājiet autentifikāciju un šifrēšanu kā atsevišķus jautājumus. Izmantojiet piekļuves atslēgas tam, kas viņiem ir izcils — bezparoles pieteikšanās, un īpašas šifrēšanas atslēgas, kas tiek pārvaldītas, izmantojot drošas atslēgu atvasināšanas un uzglabāšanas sistēmas, lai aizsargātu sensitīvus lietotāju datus.

Kā Mewayz nodrošina uzņēmumu autentifikāciju un datu drošību?

Mewayz nodrošina 207 moduļu biznesa operētājsistēmu, sākot no 19 ASV dolāriem mēnesī, kas atdala autentifikāciju no datu aizsardzības, izmantojot nozares paraugpraksi. Vietnē app.mewayz.com esošā platforma vietā app.mewayz.com ievieš atbilstošus šifrēšanas slāņus līdzās drošām pieteikšanās plūsmām, nodrošinot, ka uzņēmumi var droši aizsargāt klientu datus, neriskējot ar bloķēšanas scenārijiem, kas rodas, ja autentifikācija tiek sajaukta ar šifrēšanu.