Дзе Linux павінен захоўваць ваш пароль VPN? Не ў профілі
Сцягі сакрэтаў NetworkManager вызначаюць, ці трымае пароль профіль, агент звязкі ключоў ці ніхто. Адказ залежыць ад таго, калі пачынаецца злучэнне.
Пароль VPN мусіць дзесьці жыць: у профілі злучэння, у звязцы ключоў, якую адкрывае працоўны стол, або нідзе. NetworkManager называе гэты выбар сцягам сакрэту, і менавіта няправільны выбар — прычына таго, што злучэнне працуе пасля ўваходу і не працуе як служба. Сцяг — гэта адзін радок канфігурацыі, і ён вырашае, які з трох вынікаў вы атрымаеце.
Тры сцягі пакрываюць амаль усе выпадкі, і рашэнне залежыць ад таго, калі пачынаецца злучэнне.
Тры сцягі сакрэтаў, тры паводзіны
Сцяг 0 азначае, што сакрэт захоўваецца разам са злучэннем, у любым сховішчы, якое трымае профіль. Сцяг 1 робіць яго ўласнасцю агента: сакрэт паступае ад агента сакрэтаў, напрыклад звязкі ключоў працоўнага стала, і NetworkManager пытаецца пра яго пры актывацыі. Сцяг 2 азначае незахаванасць, таму сакрэт ніколі не запісваецца і мусіць падавацца кожны раз. Сцяг 4 пазначае сакрэт як неабавязковы, для злучэнняў, якім ён сапраўды не патрэбны.
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
Задавайце сцягі для кожнага сакрэту, а не для злучэння. Адно злучэнне можа мець пароль ва ўласнасці агента і захаваную фразу-пароль прыватнага ключа.
Вырашайце па часе запуску злучэння
Калі злучэнне запускае ўвайшоўшы карыстальнік, уласнасць агента — разумны тыповы выбар: звязка ключоў разблакоўваецца пры ўваходзе, і сакрэт ніколі не ляжыць у файле. Калі злучэнне мусіць устаць да таго, як хто-небудзь увойдзе, уласнасць агента — няправільны выбар, бо няма звязкі ключоў сеанса, якую можна разблакаваць.
Вось і ўсё рашэнне. Усё астатняе — яго варыянт.
Для службы да ўваходу падтрыманая схема — сховішча сістэмнага ўзроўню або абаронены файл ключа, і абаронай становяцца правы доступу да файла. Не вырашайце задачу ўстаўкай пароля ў shell-скрыпт, які запускаецца пры загрузцы.
Што дае звязка ключоў, а што не
Звязка ключоў трымае сакрэт па-за профілем злучэння і прывязвае яго да сеансу карыстальніка. Яна не робіць сакрэт даступным службе без сеансу і нічога не шыфруе ў сетцы. Гэта асобныя ўласцівасці, якія людзі часта зліваюць. Што яна сапраўды дае — меншы радыус паражэння, калі профільны файл выцеча.
Прыватны ключ, на які спасылаецца профіль, мае свае правы доступу, незалежна ад таго, дзе жыве пароль.
Дыягностыка без зліву сакрэтаў
Назваў злучэння, UUID і сцягаў звычайна дастаткова, каб патлумачыць збой. nmcli connection show пералічвае профіль, а сцягі сакрэтаў падказваюць, адкуль пароль павінен быў узяцца.
Пазбягайце --show-secrets у заяўках і чатах. Як толькі яго ўставілі, гэта ўжо ўліковыя даныя ў стэнаграме.
Захоўванне — не адкліканне
Выдаленне сакрэту з адной звязкі ключоў не анулюе ўліковыя даныя, якія аддалены аператар ужо прыняў. Адкліканне ўліковага запісу — дзеянне на баку сервера, а лакальнае захоўванне — асобная справа з асобным уладальнікам.
Вырашайце абое да інцыдэнту, а не падчас яго. Інтэрактыўнае злучэнне карыстальніка і служба да ўваходу патрабуюць розных адказаў, а агульны shell-скрыпт не падыходзіць ні для аднаго. Дакументацыя NetworkManager пра сцягі сакрэтаў пералічвае ўсе значэнні.