Адміністраванне NAS праз VPN: захавайце імя, адмоўцеся ад публічнага порта
Дасягайце старонкі адміністравання праз тунель, а не праз новы публічны порт. Развяжыце сапраўднае імя, супастаўце з ім сертыфікат і дазвольце адну службу з адной крыніцы.
Старонка адміністравання NAS працуе дома і перастае працаваць у той момант, калі адміністратар едзе, таму нехта адкрывае порт, і праблема знікае разам з прыватнасцю. Для гэтага ёсць лепшая форма. Пакіньце старонку там, дзе яна ёсць, дайце тунелю забяспечыць дасяжнасць і зрабіце тое, што вы дакументуеце, поўным URL з названым шляхам дазволу, а не адрасам прылады, які выпадкова адказвае. Кожнае рашэнне ніжэй, ад імені да сертыфіката і адзінага дазволенага порта, вынікае з такога запісу.
Адзінка праектавання — URL, а не адрас
Запішыце пункт уваходу як поўны URL з яго портам і схемай, затым далучыце ўмовы: каму можна ім карыстацца, з якой сеткі і праз які шлях. Прыкладам можа быць https://nas.corp.example:8443, апублікаваны толькі для адабраных прыватных кліентаў, дзе імя і порт замяняюць тое, што прылада фактычна слухае.
Такая пастаноўка прымушае прымаць рашэнні рана. URL мяркуе імя, імя мяркуе сертыфікат, а сертыфікат мяркуе дамоўленасць аб даверы. Адрас не мяркуе нічога з гэтага, і менавіта таму варыянт толькі з адрасам жыве да першага папярэджання браўзера, а затым ператвараецца ў звычку націскаць «працягнуць».
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
Захавайце імя, для якога выдадзены сертыфікат
Кліенту патрэбен дазволены маршрут да прыватнага адраса NAS, і прыватная схема DNS можа развязаць патрэбнае імя хоста ў гэты адрас, захоўваючы імя, якое чакае служба HTTPS. Важныя абодва бакі: маршрут дастаўляе пакеты туды, а імя паведамляе кліенту, якую асобу правяраць.
Калі ўвесці замест гэтага лікавы адрас, патрабаванне да асобы змяняецца. RFC 9525 аддзяляе імя, з якім кліент мае намер звязацца, ад асобы, якую прадстаўляе служба, таму сертыфікат, выдадзены для nas.corp.example, можа цалкам законна не прайсці, калі браўзер накіраваны на 10.20.0.15. Папярэджанне правільнае, і выпраўленне — гэта імя, а не выключэнне.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleВыканайце абодва перад тым, як вінаваціць тунель. Першы паказвае, ці развязваецца прыватнае імя там, дзе вы думаеце, а другі — які сертыфікат і якія альтэрнатыўныя імёны суб'екта служба фактычна прадстаўляе. Прыватны CA можа быць цалкам кіраваным выбарам; звычкай не павінна станавіцца навучанне людзей ігнараваць папярэджанні аб асобе.
Абмяжуйце шлях кіравання
Дазвольце менавіта службу кіравання з патрэбнай крыніцы — і на шлюзе, і на NAS. Гэтае сказ хавае дэталь, якая кусаецца: пул маршрутызаваных кліентаў і шлюз з трансляцыяй крыніцы прыходзяць на NAS з рознымі адрасамі крыніцы, таму правіла дазволу, напісанае для аднаго, моўчкі не спрацоўвае для другога.
NAS таксама патрэбен зваротны шлях, а браўзер павінен выкарыстоўваць наладжаны порт і схему, а не стандарт пастаўшчыка з допісу на форуме. Дасягнуць прылады — не дазвол дасягаць кожнага яе порта. Разрыў паміж прыладай, якая адказвае на ping, і старонкай адміністравання, якая загружаецца, — гэта разрыў паміж двума асобнымі правіламі. Запішыце іх як два правілы з двума каментарыямі, каб наступны чалавек бачыў, чаму існуюць абодва.
Аддзяліце допуск да VPN ад прывілеяў NAS
Быць дапушчаным праз тунель — не тое ж самае, што мець дазвол кіраваць прыладай. Карыстальнік, якому законна патрэбна файлавае сховішча, не павінен атрымліваць у спадчыну кіраванне прыладай толькі таму, што абодва знаходзяцца за адным шлюзам, і менавіта мадэль уліковых запісаў NAS — месца, дзе гэтае раздзяленне трэба забяспечыць.
Агульны або трансаваны адрас выхаду таксама не можа ідэнтыфікаваць асобнага адміністратара. Калі журнал аўдыту павінен назваць чалавека, асоба павінна паходзіць з аўтэнтыфікаванага ўліковага запісу, а не з адраса крыніцы тунеля, якім карыстаюцца шматлікія людзі.
Што не трэба публікаваць выпадкова
Публічны зваротны проксі і рэлей пастаўшчыка — абедзве рэальныя архітэктуры, і кожная нясе свае рашэнні аб даверы і экспазіцыі. Ні адна не становіцца неабходнай таму, што адміністратар знаходзіцца не дома, і ні адна не павінна з'яўляцца пабочным эфектам адкрыцця медыясервера або агульнага файлавага рэсурсу.
Задакументуйце чатыры рэчы і спыніцеся: прыватнае імя, слухач, да якога яно адлюстроўваецца, група, якой дазволена карыстацца, і шлях аднаўлення, калі тунель недаступны. Гэтыя чатыры таксама адказваюць на пытанні, якія задасць разбор інцыдэнту, чаго нельга сказаць пра здымак экрана старонкі перанакіравання порта. У выніку вы атрымліваеце адзіны стабільны пункт адміністрацыйнага ўваходу, а не прыладу, кожная функцыя якой глядзіць у інтэрнэт.