Küsimus:
Kuidas saan takistada kasutajal faile teisele kõvakettale kopeerimast?
jackgu1988
2019-06-15 12:45:36 UTC
view on stackexchange narkive permalink

Mul on Linuxi masin, mis sisaldab tundlikke faile. Kasutajad peaksid neile arvutit kasutades juurde pääsema (neid lugema), kuid neil ei tohiks olla võimalust neid teisele kõvakettale (USB-mälupulgale või muule samale masinale lisatud kõvakettale) kopeerida.

Peamine kõvaketas on krüpteeritud, et keegi ei saaks seda välja pakkida ja faile varastada.

Eesmärgi saavutamiseks võin vabalt kasutada SELinuksi või muid lähenemisviise.

UUENDAMINE:

Pärast vastuste lugemist tahaksin täpsustada:

  • ma pole eriti mures kasutajate kohta, kes võivad ekraanilt pilti teha. Tegeliku faili kaitsmine on minu peamine eesmärk.

  • Ehkki iga faili kaitsmine oleks olnud optimaalne, olen ma enamasti mures andmekogumi kui terviku kaitsmise pärast (see on väga suur). Isegi kui mõni fail lekib, on kahjud juhitavad. Pealegi ei ole failide suure hulga tõttu otstarbekas ükshaaval eraldamine ebaotstarbekas.

  • Arvuti kasutajatele ei anta administraatorit privileegid.

Millised failid?Kas kõigi liideste füüsiline turvamine on elujõuline võimalus, nt.lukustada arvuti kasti ja lubada kasutajatel pääseda juurde ainult klaviatuurile ja ekraanile?Üldiselt on usaldusväärse kasutaja tahtliku kopeerimise eest kaitsmine äärmiselt keeruline.
Peamiselt PDF-failid.Ideaalis ei ole arvuti füüsiline turvamine see, mida ma tahaksin saavutada, kuid seda saab teha, kui miski muu ei toimi.Mõtlesin takistada kasutajatel USB- või muude draivide paigaldamist (pole kindel, kas / kuidas see on võimalik töölaua keskkonda kasutades).
Kommentaarid pole pikendatud arutelu jaoks;see vestlus on [vestlusesse teisaldatud] (https://chat.stackexchange.com/rooms/95019/discussion-on-question-by-jackgu1988-how-can-i-prevent-a-user-from-copying-failid).
On öeldud, et proovimine teha baite, mida ei saa kopeerida, on nagu proovida teha vett, mis pole märg.
Kaheksa vastused:
vidarlo
2019-06-15 15:28:14 UTC
view on stackexchange narkive permalink

USB-mäluseadme saab Linuxis keelata, lisades mooduli musta nimekirja. 

  modprobe -r usb-storageecho must nimekiri usb-storage >> /etc/modprobe.d/10-usbstorage-blacklist.confecho must nimekiri uas >> /etc/modprobe.d/10-usbstor .conf

Kui teie kasutajatel on seadmele füüsiline juurdepääs ja nad teavad krüptovõtmeid, on mäng üleval, hoolimata sellest, mida te tarkvaraliselt teete.

Minu soovitus oleks piirata juurdepääsu masina füüsilistele liidestele. Lukustage see kasti sisse ja laske kasutajatel suhelda ainult klaviatuuri, hiire ja ekraani kaudu.

Samuti peaksite arvestama, et te ei saa takistada kasutajal midagi kopeerimast. Halvimal juhul? Võtke telefon kätte ja pildistage ekraani, kui need faile läbi sõeluvad. Andmete kadumise vältimine peaks minu arvates olema suunatud juhusliku ebausaldusväärsetesse seadmetesse kopeerimise peatamiseks.

Kommentaarid pole pikendatud arutelu jaoks;see vestlus on [vestlusesse teisaldatud] (https://chat.stackexchange.com/rooms/95089/discussion-on-answer-by-vidarlo-how-can-i-prevent-a-user-from-copying-failid-a-le).
VL-80
2019-06-16 20:27:21 UTC
view on stackexchange narkive permalink

Kliendi-serveri arhitektuur

See on veel üks lähenemisviis, mis võib failide kopeerimise palju raskemaks muuta, kuid see nõuab teie poolelt rohkem pingutusi.

Juurdepääsu teabele võiks seadistada kliendi-serveri arhitektuuri alusel koos teabega, mis on salvestatud kaugserveris turvalises asukohas asuvasse andmebaasi (nt MySQL või PostgreSQL).

Seejärel andke juurdepääsujaamad, mis käivitaksid kliendirakenduse, mis hangib serverist pärinevat teavet ja kuvab seda kasutajatele.

Seega, selle asemel, et võimaldada kasutajatel teabele otse juurde pääseda, edastate selle neile.

Võite muuta kasutajate kopeerimise raskemaks andmeid, piirates töölauakeskkonna võimalusi, keelates USB-pordid jne. Samuti võib teie rakendus kuvada teavet pildina, mitte teksti, kuid see sõltub sellest, kas see on kasutatavuse seisukohalt asjakohane või mitte.

Kuid see kõik eeldab, et ainsad hostid, kellel on juurdepääs andmebaasile, on lukustatud kliendijaamad, mis pakute kasutajatele ja et nad on kontrollitud keskkonnas, et nad ei saaks juurdepääsu jaamasid rikkuda ega oma seadmeid võrku ühendada.

Kas see on hea või mitte Kasutusjuhendi lähenemine sõltub teie ohumudelist ja sellest, kui palju jõupingutusi olete valmis sellesse investeerima.

+1 - see, mida muud lahendused ei suuda, on juurdepääsetavate failide arvu piiramine.Kui paari faili lugemine on normaalne, samal ajal kui kogu andmekogumi allalaadimine on väärkasutus, saab seda serveri poolel lihtsalt jõustada.
mentallurg
2019-06-15 15:47:34 UTC
view on stackexchange narkive permalink

Lisaks USB-i blokeerimisele (vaadake teisi ülaltoodud vastuseid):

Keelake võrguühendus, kuna ...

  • ... muidu kasutab kasutaja teie arvutile kaugjuurdepääsu masin, nt scp või ftp kaudu ja kopeerige failid oma masinast.
  • ... vastasel juhul saavad sisselogitud kasutajad faile võrgu kaudu teie masinast scp , ftp , samba , http.
kaudu mõnda teise masinasse
jah, blokeeri võrk: failide teisaldamiseks saab kasutada ka "posti", "telnet", "lpr" ja "netcat", lisaks saab andmete väljafiltrimiseks kasutada isegi DNS-i otsinguid.
Ja saate ka taskuarvuti, mille ühendate, masina Ethernet-porti, kui see pole füüsiliselt suletud
@Falco Ja kui sellega tegelete, on parem füüsiliselt sulgeda juurdepääs klaviatuurile ja monitori pordidele / kaablitele.Kõigest, mis pakub arvutisse mingil viisil sisendit / väljundit, saab kõrvale hiilida kõigest, mida saab piisavalt sihikindla ründaja jaoks teha mis tahes muu sisendi / väljundiga.Ja muidugi saab ka siis sama teha füüsiliselt klaviatuuri ja hiirega.Üldisem on see, et kui inimese silmad suudavad andmeid lugeda, siis ei saa te takistada nende andmete varastamist.
Vilx-
2019-06-16 22:00:47 UTC
view on stackexchange narkive permalink

Olgu, ma pole täiesti turvaekspert ja võib-olla on see täiesti märkidest väljas (andke mulle sellest kommentaarides teada!), kuid ...

Kui saate kasti füüsiliselt turvata ( muidu on kõik panused välja lülitatud), siis võite lubada kasutajal sisse logida ainult kasutaja A abil. Kõik tundlikud failid kuuluvad siiski kasutajale B ja neile ei pääse kasutaja A juurde. VÄLJA ühe programmi "PDF Viewer" jaoks, mis kuuluks samuti kasutajale B , kuid koos bitikomplektiga setuid , nii et käivitamisel töötaks see kasutaja B ja pääsete failidele juurde. Kuna tegemist on vaatajaga, saab ta faile näidata, kuid neid mitte kopeerida.

Või midagi sellist. Trikk on bitt setuid .

Huvitav lähenemine.Kuid kui salvestate vaataja siseselt, kas see ei saa faili täpset koopiat kohapeal salvestada?
@jackgu1988 - noh, jah, peate leidma vaataja, millel pole funktsiooni "Salvesta kui".Või võtke mõni olemasolev openource ja muutke seda.
@jackgu1988 - Oh, aga sa ütlesid, et nende ükshaaval väljavõtmine on ebapraktiline, kas pole?
Jah, aga kui „salvesta kui” on otsetee, võib see olla väga kiire või isegi automatiseeritud.
@jackgu1988 - jah, see on tõsi.
Setgid võib olla veelgi parem lahendus, kuid samade piirangutega.Võib-olla on olemas kaasaegsemad võimalused.(ACL?) Võite seda kombineerida ka selle kasutaja või rühma kirjutamisõiguse piiramisega teatud kataloogidele, nt.nad ei pruugi USB-draivi kirjutada.Tõenäoliselt ei aita see võrgule juurdepääsu puhul siiski. Kas saaksite anda rohkem teavet failitüüpide või programmide kohta, mis peavad nendele failidele juurde pääsema?
@idspispopd - kusagil mujal selles teemas väitis OP, et tegemist on PDF-failidega ja neist on olemas suur hulk.Mõni lekkinud pole suur asi, kuid suur kogus siiski.
PDF-faile saab "_kaitse_" erineval tasemel hoida ja see takistab "salvestada kui ..." ja / või takistab teksti või pildi kopeerimist lõikelauale, takistab printimist jne ... Need seaded, kui neid rakendatakse algsetel PDF-dokumentide tasemetel,rakendub olenemata PDF-i vaataja võimalustest.
@Hoki: PDF-i kaitsed / load erinevatel tasanditel on kõik mõttetud nende vastu, kes teavad, mida nad teevad, ainult PDF-i krüptimine on eemalt kasulik.
@LieRyan - sel juhul võib see tegelikult töötada, kuna nad ei pääse failidele otse juurde ja on sunnitud pakutavat tarkvara kasutama.
@LieRyan, Ma tean, et teadmisi omavate inimeste poolt on neid võimalik häkkida, kuid neil oleks selleks vaja tööriistu, mis ei tohiks olla kättesaadavad keskkonnas, millest OP räägib.
Kasutajal A ei pea vaataja avamiseks olema kuskil kirjutamisõigust.Võib-olla suudavad SELinuksi reeglid või Linuxi konteinerid jõustada failisüsteemide kirjutuskaitstud (isegi USB kaudu) ja keelata võrgule juurdepääsu.
@Vilx: minu kommentaar ei olnud suunatud teie vastuse poole.Teie vastus on enamasti hea;setuid Viewer on üks ülioluline osa selle kohta, mida OP küsis, kuigi see võib kasutada natuke täpsustusi, kuna traditsioonilised Unixi failiload ja setuid pole piisavad, et teatud stsenaariume täielikult ära hoida.Minu kommentaar oli suunatud Hoki väitele, et PDF-i load "... kehtivad olenemata PDF-i vaataja võimalustest".See pole üldse tõsi.
Kui kasutaja B ei saa faile kuhugi kirjutada, siis ei tohiks selle suur probleem olla.Nii et peate turvama kirjutatavad kataloogid nagu "/ home / B", "/ tmp", "/ var / tmp" ja "/ dev / shm" ja tõenäoliselt mõned teised.Selliste tööriistade nagu selinux või liivakastide nagu firejail kasutamine ei tohiks kirjutamisõiguse keelamine olla liiga raske.
VL-80
2019-06-17 17:40:26 UTC
view on stackexchange narkive permalink

VNC

Teie faile võidakse arvutis turvalises kohas salvestada.

Seadistage VNC-server ja keelake failiedastusvõimalused. Selle küsimuse kohta ServerFault'is saab seda teha TightVNC-s.

Veenduge, et teie faile salvestavas arvutis poleks avatud ühtegi teist pordi. kliendijaam ja lukustage see:

  • keelates I / O-pordid OS-is ja BIOS-i tasemel
  • asetades korpusele luku
  • töölaua keskkonna funktsioonide piiramine
  • tugeva parooli määramine juurkontole
  • kasutaja konto piiramine

See peaks muutma selle raskemaks kasutajatel teavet kopeerida, pakkudes neile samal ajal mugavat viisi failidega suhtlemiseks. VNC võib töötada täisekraanrežiimis, jättes kasutajatele mulje, nagu nad suhtleksid kohaliku jaama failidega.

On olemas ettevõttelahendusi nagu Citrix, Xen Desktop, SPICE, mis seda enam-vähem teevad.On isegi selliseid, millel on brauseripõhine klient, mis välistaks ootamatu IO või avatud portide võimaluse.
borizzzzz
2019-06-15 15:39:08 UTC
view on stackexchange narkive permalink

Kui soovite lihtsalt kõik USB-seadmed keelata, vaadake lehte usb-storage.ko (USB-massmälu draiver Linuxi all). Draiveri keelamine mõjutab kõiki USB-seadmeid, kaasa arvatud klaviatuure / hiiri. Draiveri keelamiseks võite selle musta nimekirja lisada, muutes faili /etc/modprobe.d/blacklist.conf. Lisage lihtsalt rida: 

  must-usb-storage

See lahendus eeldab, et teistel kasutajatel pole sudo õigusi.

Kui kasutajal on administraatoriõigused, on kõik panused välja lülitatud.
@vidarlo Mitte koos tuuma lukustuse plaasteriga ja `kernel.modules_disabled = 1`.
binarym
2019-06-17 20:18:19 UTC
view on stackexchange narkive permalink

Põhimõtte "annab ainult ühele tema ülesande täitmiseks vajalikud õigused" järgimine võib-olla saate rakendada piiratud kestat, mis paneb teie süsteemi kasutajad maksma ainult seda, mida lubate.

Kui teie kasutajad ei saa:

  • scp
  • ühendada
  • käivitada mis tahes võrguutiliit (Firefox, Netcat, Curl)
  • Võrgu voo avamiseks kasutage sisseehitatud basseine.

Siis saavad ainsad võimalused andmeid välja filtreerida, häkkides ühte käsku, mida neil on lubatud käitada ...

Piiratud kesta saab rakendada üsna lihtsalt: jah, käivitage see.

Pealegi on GNU / Linuxi jaoks saadaval hulgaliselt piiratud kestaga koopiaid.

Steve Sether
2019-06-17 20:47:15 UTC
view on stackexchange narkive permalink

Kuidas oleks midagi sellist nagu inimese kitsaskoht protseduuri kaudu, mitte automatiseerimine ja juurdepääs kõigile failidele korraga? Kõik pakutavad lahendused pakuvad arvutile juurdepääsu piiramist. Seda vaevab probleem, et arvutid on kõige madalamal tasemel rumalad ja teevad seda, mida neile öeldakse. Kuna HD kasutab kogu ketta krüpteerimist, on kõik failid selgesõnaliselt saadaval, kui masin on sisse lülitatud.

Lisaks täielikule ketta krüpteerimisele krüpteerige kõik kõvakettal olevad failid, millel kõigil on erinevad juhuslikult genereeritud parool, kuid teenusel index on siiski mingisugune märksõnaotsingu võime. Selleks, et kasutaja saaks faili taotleda, peab ta pöörduma administraatori poole. Paroolid salvestatakse võrguühenduseta mõnes ressursis, mis pole kasutajale kättesaadav. Seejärel saab administraator taotletud failide jaoks parooli (paroolid), sisestab parooli ja dekrüpteerib failid kasutaja jaoks. Sõltuvalt vaatamistarkvarast võite isegi sundida faili olema ainult mälus, mitte kettal. Administraatorit võiks käskida dekrüpteerida ainult piiratud arv faile päevas.

See oleks lisaks ülaltoodud meetoditele, näiteks USB / Network / etc juurdepääsu keelamine. Selle meetodi eeliseks on see, et see piirab oluliselt kõiki kopeerimismeetodeid. Kopeerimismeetodi avastamisel piirduvad kahjustused ainult failidega, mida on dekrüpteeritud.

Sõltuvalt teie stsenaariumist pole see muidugi teostatav, kuid pakub väga kõrget turvalisust, kuna iga fail on eraldi kaitstud.

Miljonite krüpteeritud võtmete haldamine oleks problemaatiline.Pealegi ei lahenda see tõenäoliselt probleemi tegelikult, kuna kasutaja, kellele OP viitab, on tõenäoliselt keegi, kes peaks tegema teie pakutava administraatori rolli.Seejärel liigutate probleemi arvuti või mõne muu administraatori omamiseks, kes peab dekrüpteerimisvõtmete väljastamist piirama.
@LieRyan Ma pole kindel, et olen nõus.Keegi, arvatavasti on selle seadistajal juurdepääs nendele failidele.Nad _ võivad_ neid kopeerida, kui nad seda otsustavad, nii et peate usaldama kedagi, kellel on juurdepääs.Samuti pole miljon lihtsalt väga suur arv.Kindlasti ei oleks keeruline kõiki neid paroole ka arvutisse krüptida.
Kui salvestate paroole mõnes teises arvutis, siis miks mitte lihtsalt salvestada failid sellesse teise arvutisse ja loobuda kogu krüptimisskeemist (või krüptida need kõik sama võtmega).Kasutaja (kes kontrollib ainult kliendimasinat) taotleb faili ja administraator (kes kontrollib serverimasinat) volitab faili kasutajale saatma.Samuti pole vaja inimese administraatorit.Server saab kiiruse piiramisega ise hakkama.
@JonBentley Mõlema administraatorimasinasse salvestamine tähendaks, et fail tuleks kasutajate masinasse kopeerida.Täpselt stsenaarium, mida üritatakse vältida.Samuti on siin välditav risk automatiseerimine ja tarkvara juhtimine.Hästi koolitatud inimesi ja usaldusväärseid inimesi usaldatakse rohkem kui automatiseerimist.Üldiselt loome automaatika seetõttu, et see on odavam, mitte sellepärast, et see oleks turvalisem.
Stsenaarium, mida üritatakse vältida, ei ole failide ** kopeerimine ** kasutaja masinasse, vaid failide kopeerimine ** kasutaja masinast ** (nt välisele draivile).OP eeldab, et kasutaja masinal on failide koopiad.Ma ei nõustu teie väitega, et hästi koolitatud inimesed ja usaldusväärsed inimesed on serveritest turvalisemad.Hästi koolitatud inimesed võivad teha vigu ja tänapäeval võivad usaldusväärsed inimesed usaldamatuks muutuda.Servereid saab programmeerida valesti, kuid neile võib alati usaldada seda, mida nad olid programmeeritud.Mõlemad võivad olla teistest turvalisemad, sõltuvalt faktidest.
@JonBentley Kuna me oleme hakanud juurdepääsu ja inimeste füüsilise juurdepääsu kontrollimiseks lootma rohkem tarkvarale, oleme liikunud väheste suuremahuliste andmetega põlvpükside ajastust ajastusse, kus see toimub pidevalt.Üks laiaulatuslik andmeturvalisuse põlvkond enne laialdast teabe automatiseerimist, mida ma mõelda saan, oli Daniel Elsberg ja Pentagon Papers.Automaatika ajastul viisid Chelsea Manning ja Edward Snowden Elsbergi välja nagu väike vahejuhtum.Rääkimata SS-i massilisest lekkimisest Experianilt, tohutu Sony Picturesi andmete lekkimisest ja lugematust arvust muudest andmetest.
@SteveSether korrelatsioon! = Põhjuslik seos.Jah, andmerikkumisi on olnud rohkem, kuid varastada on ka * palju * rohkem andmeid kui kunagi varem.Rääkimata sellest, et suur osa rikkumistest tuleneb pigem usaldusväärsete inimeste vigadest kui tarkvara probleemidest.Näiteks juhtus Sony rikkumine seetõttu, et töötajad lasid häkkerid hoonesse ja nende sisemine tarkvara turvalisus oli kohutav.Kui neil oleks olnud parem automatiseeritud turvalisus, oleks see võib-olla ära hoitud


ⓘ
See küsimus ja vastus tõlgiti automaatselt inglise keelest.Algne sisu on saadaval stackexchange-is, mida täname cc by-sa 4.0-litsentsi eest, mille all seda levitatakse.
Loading...