Не выкарыстоўвайце ключы доступу для шыфравання дадзеных карыстальніка

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

Аўтэнтыфікацыя і шыфраванне - прынцыпова розныя заняткі

Аўтэнтыфікацыя адказвае на адно пытанне: "Вы той, за каго сябе выдаеце?" Шыфраванне адказвае на зусім іншае пытанне: "Ці могуць гэтыя дадзеныя заставацца нечытэльнымі для ўсіх, акрамя ўпаўнаважаных асоб?" Гэтыя дзве праблемы падзяляюць крыптаграфічныя прымітывы, але інжынерныя патрабаванні рэзка адрозніваюцца. Аўтэнтыфікацыя павінна адбывацца адзін раз за сеанс, яна можа цярпець выпадковыя збоі з вытанчанымі рэзервовымі варыянтамі і не павінна кожны раз ствараць адзін і той жа вынік. Шыфраванне патрабуе дэтэрмінаванага, узнаўляльнага доступу да ключа на працягу ўсяго тэрміну службы даных, які можа доўжыцца гады ці дзесяцігоддзі.

Пры аўтэнтыфікацыі з дапамогай ключа доступу ваша прылада стварае крыптаграфічны подпіс, які пацвярджае, што вы валодаеце закрытым ключом, звязаным з вашым уліковым запісам. Сервер правярае гэты подпіс і дае доступ. Ні ў якім разе сервер — ці нават ваша прыкладанне — не атрымлівае доступу да матэрыялу прыватнага ключа. Гэта функцыя, а не абмежаванне. Уся мадэль бяспекі ключоў доступу залежыць ад таго, каб прыватны ключ ніколі не пакідаў бяспечны анклаў вашай прылады. Але шыфраванне патрабуе, каб вы выкарыстоўвалі ключ для пераўтварэння даных, а пазней выкарыстоўвалі гэты ж ключ (або яго адпаведнік) для зваротнага пераўтварэння. Калі вы не можаце атрымаць надзейны доступ да ключа, вы не можаце надзейна расшыфраваць яго.

Такім платформам, як Mewayz, якія кіруюць канфідэнцыйнай бізнес-інфармацыяй — рахункамі-фактурамі, запісамі аб заработнай плаце, кантактамі CRM, дакументамі кадраў у 207 модулях — патрэбныя стратэгіі шыфравання, пабудаваныя на ключах, якія з'яўляюцца трывалымі, аднаўляльнымі і пастаянна даступнымі. Пабудова гэтага на аснове, створанай спецыяльна для прадухілення доступу да ключоў, з'яўляецца архітэктурнай супярэчнасцю.

Чаму ключы доступу не выкарыстоўваюцца ў якасці ключоў шыфравання

Спецыфікацыя WebAuthn, якая ляжыць у аснове ключоў доступу, была наўмысна распрацавана з абмежаваннямі, якія робяць выкарыстанне шыфравання непрактычным. Разуменне гэтых абмежаванняў паказвае, чаму гэта не той прабел, які можа пераадолець разумная інжынерыя — гэта фундаментальная мяжа дызайну.

• Без экспарту ключа: прыватныя ключы, згенераваныя падчас рэгістрацыі ключа доступу, захоўваюцца ў абароненых анклавах з апаратнай падтрымкай (TPM, Secure Enclave або эквівалент). Аперацыйная сістэма і API-інтэрфейсы браўзера не забяспечваюць механізмаў здабывання неапрацаванага ключавога матэрыялу. Вы можаце папрасіць ключ падпісаць нешта, але вы не можаце прачытаць сам ключ.
• Генерацыя недэтэрмінаванага ключа: стварэнне ключа доступу для таго ж карыстальніка на іншай прыладзе стварае зусім іншую пару ключоў. Няма ні пачатковай фразы, ні шляху атрымання, ні магчымасці аднавіць той жа ключ на іншай прыладзе. Кожная рэгістрацыя крыптаграфічна незалежная.
• Даступнасць у залежнасці ад прылады: нават пры сінхранізацыі ключа доступу (iCloud Keychain, Google Password Manager) даступнасць залежыць ад удзелу ў экасістэме. Карыстальнік, які зарэгістраваўся на iPhone і пазней перайшоў на Android, можа страціць доступ. Карыстальнік, чыя прылада згублена, украдзена або была скінута да заводскіх налад, сутыкаецца з той жа праблемай.
• Толькі выклік-адказ: API WebAuthn паказвае navigator.credentials.get(), які вяртае падпісанае зацвярджэнне, а не неапрацаваны матэрыял ключа. Вы атрымліваеце подпіс праз выклік, які прадстаўляецца серверам — карысны для пацверджання асобы, бескарысны для атрымання ключа шыфравання.
• Адсутнасць гнуткасці алгарытму: Ключы доступу звычайна выкарыстоўваюць ECDSA з крывой P-256. Нават калі б вы маглі атрымаць доступ да ключа, ECDSA - гэта алгарытм подпісу, а не алгарытм шыфравання. Вам спатрэбяцца дадатковыя пераўтварэнні (узгадненне ключа ECDH, вывядзенне KDF), якія API не падтрымлівае ў гэтым кантэксце.

Некаторыя распрацоўшчыкі прапанавалі абыходныя шляхі — напрыклад, выкарыстанне пашырэння PRF (псеўдавыпадковая функцыя) для WebAuthn для атрымання сіметрычных ключоў падчас аўтэнтыфікацыі. Нягледзячы на ​​тое, што гэтае пашырэнне існуе ў спецыфікацыі, падтрымка браўзера застаецца непаслядоўнай, яно недаступнае на многіх мабільных платформах, і яно па-ранейшаму ўспадкоўвае праблему прывязкі прылады. Ключ, атрыманы праз PRF на адной прыладзе, не можа быць прайграны на іншай прыладзе з іншым ключом доступу, нават для таго ж уліковага запісу карыстальніка.

Сцэнар страты даных, якія ніхто не хоча адпраўляць

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

Пры традыцыйнай аўтэнтыфікацыі страта прылады выклікае нязручнасці. Карыстальнік аднаўляе свой уліковы запіс па электроннай пошце, усталёўвае новыя ўліковыя дадзеныя і працягвае працаваць. Але калі іх дадзеныя былі зашыфраваны з дапамогай ключа, прывязанага да бяспечнага анклава прылады, якая зараз пагружана ў ваду, гэтыя дадзеныя зніклі. Не «цяжка аднаўляць» знікла — крыптаграфічна незваротна знікла. Ніякія білеты ў службу падтрымкі кліентаў, ніякая працэдура аднаўлення ўліковага запісу, ніякая эскалацыя выканаўчай улады не могуць пераламаць матэматыку. Дадзеныя таксама маглі быць выдалены.

Асноўнае правіла распрацоўкі сістэмы шыфравання: калі ў вашай стратэгіі кіравання ключамі ёсць адна кропка адмовы, якая назаўсёды знішчае доступ да карыстальніцкіх даных, вы не стварылі функцыю бяспекі — вы стварылі механізм страты даных з дадатковымі крокамі.

Для бізнесу, які працуе праз платформу — кіраванне ўзаемаадносінамі з 50 кліентамі ў CRM, апрацоўка штомесячнай заработнай платы для 30 супрацоўнікаў, адсочванне парку транспартных сродкаў — незваротная страта даных з тэлефона, які ўпаў, не з'яўляецца нязначнай праблемай UX. Гэта катастрофа бесперапыннасці бізнесу. Менавіта таму архітэктура Mewayz аддзяляе механізмы аўтэнтыфікацыі ад узроўняў абароны даных, гарантуючы, што збой ніводнай прылады не можа паставіць пад пагрозу доступ да важнай бізнес-інфармацыі ў любым з інтэграваных модуляў.

Што вы павінны выкарыстоўваць замест гэтага

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

Шыфраванне на баку сервера з кіраванымі ключамі застаецца найбольш практычным выбарам для пераважнай большасці прыкладанняў. Ваша платформа шыфруе даныя ў стане спакою з дапамогай ключоў, якія кіруюцца праз належную службу кіравання ключамі (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault або аналагі. Карыстальнік аўтэнтыфікуецца (з ключамі доступу, калі хочаце!), а сервер празрыста апрацоўвае шыфраванне і дэшыфраванне. Такім чынам большасць платформаў SaaS абараняюць даныя, і гэта працуе, таму што ключы трывалыя, захоўваюцца ў рэзервовых копіях, іх можна паварочваць і не залежаць ад любой прылады карыстальніка.

Ключы шыфравання, атрыманыя з дапамогай пароля (з выкарыстаннем Argon2id або scrypt для вываду ключа) падыходзяць, калі вам патрэбна сапраўднае шыфраванне без ведаў, калі нават сервер не можа прачытаць дадзеныя карыстальніка. Кампраміс заключаецца ў тым, што страта пароля азначае страту даных, але паролі можна запамінаць, запісваць і захоўваць у менеджэрах пароляў — яны не зачыненыя ўнутры апаратнага анклава. Такія сэрвісы, як 1Password і Standard Notes, эфектыўна выкарыстоўваюць гэты падыход.

1. Выкарыстоўвайце ключы доступу (ці любы надзейны метад) для аўтэнтыфікацыі — праверкі асобы карыстальніка.
2. Пасля аўтэнтыфікацыі атрымлівайце або атрымлівайце ключы шыфравання праз асобную, спецыяльна пабудаваную сістэму кіравання ключамі.
3. Укараніць механізмы дэпаніравання або аднаўлення ключоў — ключы аднаўлення, сінхранізацыя ключоў на некалькіх прыладах або захоўванне ключоў арганізацыі для бізнес-акаўнтаў.
4. Шыфраванне даных у стане спакою і перадачы з дапамогай AES-256-GCM або XChaCha20-Poly1305 з дапамогай ключоў ад вашай KMS.
5. Перыядычна мяняйце ключы і падтрымлівайце зашыфраваныя рэзервовыя копіі ключоў, якія вытрымліваюць любы момант адмовы.

Такі падзел задач з'яўляецца не проста лепшай практыкай — гэта адзіная архітэктура, якая дазваляе абнаўляць метады аўтэнтыфікацыі незалежна ад вашай стратэгіі шыфравання. Калі ключы доступу ў рэшце рэшт развіваюцца або замяняюцца чымсьці лепшым, вашы зашыфраваныя даныя застаюцца цалкам даступнымі.

Пашырэнне PRF: абяцанні і падводныя камяні

Распрацоўшчыкі, якія ўважліва прытрымліваюцца спецыфікацыі WebAuthn, могуць паказваць на пашырэнне prf як на патэнцыйны мост паміж ключамі доступу і шыфраваннем. Гэта пашырэнне дазваляе давяраючаму боку запытваць псеўдавыпадковае значэнне, атрыманае з сакрэтнага матэрыялу ключа доступу падчас цырымоніі аўтэнтыфікацыі. Тэарэтычна гэта значэнне можа служыць ключом шыфравання або пачатковым элементам.

На практыцы пашырэнне PRF сутыкаецца са значнымі бар'ерамі прыняцця. Па стане на пачатак 2026 года падтрымка рэзка адрозніваецца ў розных браўзерах і платформах. Рэалізацыя Safari адрозніваецца ад Chrome. Многія прылады Android наогул не падтрымліваюць яго. Апаратныя ключы бяспекі маюць непаслядоўную падтрымку. Для любой платформы, якая абслугоўвае разнастайную базу карыстальнікаў — а Mewayz абслугоўвае больш за 138 000 карыстальнікаў з рознымі аперацыйнымі сістэмамі і тыпамі прылад — стварэнне шыфравання на функцыі з няроўнай даступнасцю з'яўляецца аператыўна невыканальным.

Больш прынцыпова, PRF не вырашае праблему некалькіх прылад. Псеўдавыпадковы вынік атрымліваецца з пэўнага ключа доступу на канкрэтнай прыладзе. Карыстальнік, які рэгіструе ключы доступу як на ноўтбуку, так і на тэлефоне, атрымлівае два розныя выхады PRF для аднаго ўліковага запісу. Вам трэба было б зашыфраваць даныя з дапамогай ключа, атрыманага з адной прылады, а потым нейкім чынам паўторна зашыфраваць або падзяліцца гэтым ключом з іншай прыладай — што ў любым выпадку вяртае вас да стварэння належнай сістэмы кіравання ключамі. У гэты момант ключ, атрыманы з ключа доступу, дадае складанасці без дадатковай бяспекі.

Урокі для будаўнікоў: выкарыстоўвайце правільны інструмент для патрэбнага пласта

Спакуса выкарыстоўваць ключы доступу для шыфравання зыходзіць з добрага інстынкту — распрацоўшчыкі хочуць выкарыстоўваць моцную крыптаграфію і паменшыць колькасць сакрэтаў, якімі трэба кіраваць карыстальнікам. Але інжынерыя бяспекі прынцыпова заключаецца ў выкарыстанні правільнага прымітыва на правільным узроўні. І замок, і сейф абараняюць каштоўнасці, але вы не сталі б усталёўваць засаўку ў сховішча або спрабаваць насіць сейф у кішэні.

Клічы доступу выдатна спраўляюцца са сваім прызначэннем. Яны скарацілі захоп уліковых запісаў, звязаных з фішынгам, да 99,9% ва ўнутраным разгортванні Google. Яны цалкам ліквідуюць атакі падкіду ўліковых даных. Яны забяспечваюць уваход у сістэму, які адначасова больш бяспечны і зручны, чым паролі. Гэта выдатнае дасягненне, і гэтага дастаткова. Запытваць ключы доступу для вырашэння шыфравання падобна на тое, каб папрасіць ваш брандмаўэр таксама служыць вашай сістэмай рэзервовага капіравання — ён няправільна разумее архітэктуру.

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

Правільная бяспека, не ўскладняючы яе

Для большасці прыкладанняў SaaS і бізнес-платформаў практычная рэкамендацыя простая: з энтузіязмам прымяняйце ключы доступу для аўтэнтыфікацыі і выконвайце шыфраванне цалкам на серверы з дапамогай кіраванага KMS. Гэта дае вашым карыстальнікам найлепшы вопыт уваходу, даступны сёння, адначасова абараняючы іх даныя з дапамогай інфраструктуры, распрацаванай спецыяльна для трываласці і аднаўлення.

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

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

Часта задаюць пытанні

Чаму ключы доступу нельга выкарыстоўваць для шыфравання дадзеных карыстальніка?

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

Што адбудзецца, калі вы ўсё роўна паспрабуеце зашыфраваць даныя з дапамогай ключоў?

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

Што распрацоўшчыкі павінны выкарыстоўваць замест ключоў доступу для шыфравання даных?

Распрацоўшчыкі павінны выкарыстоўваць спецыяльныя рашэнні для шыфравання, такія як AES-256, з належным кіраваннем ключамі, шыфраваннем канверта або стандартнымі бібліятэкамі, такімі як libsodium. Трымайце аўтэнтыфікацыю і шыфраванне асобнымі праблемамі. Выкарыстоўвайце ключы доступу для таго, у чым яны вылучаюцца - уваход без пароля - і спецыяльныя ключы шыфравання, якія кіруюцца з дапамогай бяспечных сістэм атрымання ключоў і захавання для абароны канфідэнцыяльных даных карыстальнікаў.

Як Mewayz спраўляецца з аўтэнтыфікацыяй і бяспекай даных для прадпрыемстваў?

Mewayz забяспечвае бізнес-АС з 207 модуляў ад 19 долараў у месяц, якая аддзяляе аўтэнтыфікацыю ад абароны даных з выкарыстаннем перадавых практык галіны. Замест таго, каб злоўжываць ключамі доступу, платформа на app.mewayz.com укараняе належныя ўзроўні шыфравання разам з бяспечнымі патокамі ўваходу, гарантуючы, што прадпрыемствы могуць надзейна абараняць даныя кліентаў без рызыкі блакіроўкі, якая ўзнікае ў выніку змешвання аўтэнтыфікацыі з шыфраваннем.