Peto pri VPN-aliro ofte kaŝas unu dosierujon kaj unu dosieron malantaŭ si. Doni itineron al la tuta oficeja reto respondas la peton kaj transdonas multe pli ol la tasko postulas. Anstataŭigi mapitan kundividon per alŝuta paĝo povas esti same malĝusta en la alia direkto, ĉar ĝi ŝanĝas kiel homoj laboras. La decido komenciĝas per tio, kio devas okazi al la dosiero.

Tri postuloj aspektas similaj ĉi tie kaj kondutas tre malsame: kopii pretan PDF, redakti dokumenton surloke kaj ruli aplikaĵon kontraŭ kundividita dosierujo.

Komencu de la redaktado, ne de la dosierujo

Se la dosiero estas preta kaj nur bezonas legadon, transiga konto sufiĉas. Se ĝi estos redaktata, la demando fariĝas kiu alia redaktas ĝin kaj kiel konfliktoj solviĝas, kio estas demando pri laborfluo, ne pri reto. Se la aplikaĵo malfermas dokumentojn rekte el la dosierujo, gravas la latenteco kaj la ŝlosila konduto de la stoktavolo. Respondi tion unue malhelpas solvon, kiu konektiĝas perfekte kaj tamen ne uzeblas.

Komuna redaktado enkondukas problemon, kiun neniu transigo povas solvi. Uzanto elŝutas kalkultabelon, redaktas ĝin senrete kaj alŝutas ĝin post kiam iu alia ŝanĝis la originalon, kaj la ĉifrita konekto havas neniun opinion pri la superskribo. Interkonsento pri superskribo, konflikto aŭ versiigado devas ekzisti antaŭ la alirmetodo.

SFTP estas transiga protokolo, ne kundivido

SFTP movas dosierojn per ĉifrita SSH-transporto, kio estas ĝuste tio, kion kopio bezonas, kaj ne tio, kion mapita disko bezonas. Ĝi ne estas FTP, kaj produkto ofertanta FTPS ofertas alian protokolon anstataŭ SFTP. Munti SFTP-dosierujon per tavolo de dosiersistemo ne promesas la ŝlosilan, permesan aŭ aplikaĵan konduton de la originala kundivido. Kontrolu la postulojn de la klienta aplikaĵo antaŭ ol nomi tion rektan anstataŭaĵon.

sftp [email protected]
put report.pdf /upload/report.pdf
get /shared/template.docx

Tio estas la tuta laborfluo por preta dosiero: konekti, meti, preni. Konto nur por transigo ankaŭ bezonas limigitan SSH-servon, ne nur la dosiersistemon. chroot aŭ ForceCommand internal-sftp limigas kion la seanco povas ruli, kaj malŝalti TCP-plusendadon kaj tuneladon fermas la vojojn, kiuj alie igus dosierkonton reta enirpunkto. Limigi nur la videblan dosierujon pruvas nenion pri tio, kion la konto povas atingi.

Se vi bezonas la kundividon, ne publikigu ĝin

Kelkfoje la originala kundivido vere estas la postulo, kaj la respondo ne estas elmeti SMB al arbitraj interretaj klientoj. La gvidado de Microsoft estas bloki rektan SMB-trafikon ĉe la limo, kaj kun bona kialo: la protokolo ne estis konstruita por alfronti nefidindajn retojn. Ekzistas SMB super QUIC kaj kompareblaj dezajnoj, kun specifaj platformaj postuloj ĉe ambaŭ finoj, kaj ili ne estas universala ŝaltilo por arbitra Samba-servilo. Se neniu aplikiĝas, la laboro estas provizi subtenatan alirvojon anstataŭ plusenditan pordon.

La retumila opcio estas legitima tria respondo kiam la laboro taŭgas por ĝi. Ĝi alportas siajn proprajn decidojn: kontoj, kundividaj ligiloj, eksvalidiĝo, konservitaj versioj kaj kiu kopio estas aŭtoritata. Ligilo, kiun iu ajn povas malfermi, kaj laborspaco, kiu postulas ensaluton, reprezentas malsamajn alirpolitikojn, kaj neniu el ili devus esti elektita hazarde.

Kion kontroli antaŭ transdoni aliron

sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx"
ssh [email protected] "cat /etc/passwd"

Kiun ajn dezajnon vi elektas, limigu ĝin al la celitaj datumoj kaj la celitaj operacioj. La unua komando devus sukcesi kaj la dua devus esti rifuzita; se ambaŭ sukcesas, la konto estas pli larĝa ol la tasko. Poste forigu la konton kaj ripetu la unuan, kiu nun devus malsukcesi. Tenu la posedanton de la fontdosieroj identigebla, por ke posta demando pri la aŭtoritata kopio havu respondon. La rezulto inda je registrado estas uzebla kaj revokebla dosiera laborfluo, ne mankanta konekta ikono.

Notu, kiun protokolon la aplikaĵo de la uzanto fakte bezonas, kaj kiujn tri testojn vi faris. Tiuj du linioj malhelpas la plej grandan parton de la relaboro.

Rilataj artikoloj