Tsja.. Veiliger hoe? Veiliger van datacorruptie? Veiliger omdat backups makkelijker te beheren zijn?

Of een database veiliger is dan losse files is, hangt sterk af van de implementatie voor beide de losse files en de database en zal per situatie verschillen. Als algemene statement zou ik het onzin verklaren, en andersom ook.

Je kunt net zo goed stellen dat databases inherent minder veilig zijn omdat er meer protocollen / clients gebruikt worden dan met plain files, hetgeen de kans op kwetsbaarheden groter maakt.

Non-issue mijns inziens. Appels en peren.

Wat bedoel je met 'losse files'? Een database is meestal ook een verzameling bestanden op een harde schijf.

Wil je bestanden opslaan of records?

Beide hebben hun eigenschappen, goede en slechte.

Een "database" bestaat ook uit files, tenzij je een volledige memory only database hebt en geen swapfile of temporay storage er aan gekoppeld hebt

Binnen een database kun je verschillende toegangspriveleges toekennen: Beheerder/gebruiker en die weer al of niet gesplitst in zien of modificeren/aanmaken van records, velden en scripts/operatoren, maar om het nu persé veel veiliger te noemen? Een database is net zo veilig/onveilig als welk eender digitaal bestand. Het is wel aan de beheerder om de veiligheidsniveau's in te stellen maar als gebruikers hun werkstation verlaten zonder bijvoorbeeld de zaak te vergendelen en het gebeurt niet automatisch na verloop van x-aantal minuten heb je al een potentieel veiligheidsrisico.

Je kan die collega eens vragen waarom hij dat zei.

Of, zoals vroeger wel gebruikelijk, als je het database management systeem een partitie of hele disk zonder filesystem geeft om mee te spelen. Want waarom schrijfopdrachten ook nog eens door het FS in een bestand laten proppen als het DBMS de "zoek er een plekje voor zodat het weer snel terug te vinden is"-taak feitelijk al uitvoert?

Zo bekeken is database-in-bestand(en) risicovoller dan direct zelf een bestand schrijven. Want complexer. Maar dat is het hele verhaal nog niet. Daarvoor moet je kijken naar welke garanties je specifieke FS je geeft en welke garanties je DBMS je geeft. En naar onder welke omstandigheden die garanties ook hard te maken zijn. En zo verder. Kijk naar bijvoorbeeld de garanties samengevat als "ACID"; daar krijg je heel weinig van als je naïef je data in een bestandje propt. (Met regelmatig als gevolg dat ontwikkelaars halve DBMSen slecht heruitvinden om delen van die ACID-garanties alsnog te krijgen.)

En, TS, zoals al aangegeven, het maakt heel er uit wat je bedoelt met "veiliger", in welke zin? Tegen lekken? Een oeps-toevallig-opengelaten mongodb en heel Equador ziet z'n privegegevens over heel de wereld bekendgemaakt. Maar dat kan ook heel goed met een oeps-toevallig-opengelaten NAS waar bestandjes met naam/adres/fotos/etc. op te vinden zijn. Tegen corruptie, hardware failure, software failure, iets anders? Wat?

Je kan hier in het algemeen alleen maar schetsen dat het allemaal heel gecompliceerd is. Dus zul je een specifiekere vraag moeten stellen. En mischien een beetje meer (specifieker) huiswerk doen.

Volgens mijn collega is het het veiligst om je data in de smart blockchain op te slaan.

Heet jouw collega soms Rian?

Ho! Geen kwaad woord over Rian!

@TS, je merkt, je vraag roept nogal wat wedervragen op. Je vraag kan het beste beantwoord worden door te beginnen met kijken naar de informatie die je wilt opslaan. Het is afhankelijk van de eisen die stelt aan beschikbaarheid, integriteit en vertrouwelijkheid van je informatie welk opslagmedium je kiest.

In het algemeen stellen dat een database veiliger is, is hetzelfde als stellen dat je het beste een Audi A5 kunt gebruiken om van Groningen naar Drachten te gaan. In een kleinere auto kom je er echter ook.

Dus vraag terug; "Wat is de soort informatie die je wilt opslaan, welke eisen stel je aan deze informatie"?

@vraagsteller: Je vraag is zo algemeen gesteld en met zo weinig informatie over wat je eigenlijk voor toepassing in gedachten hebt dat hij niet te beantwoorden is. Het is zoiets als de vraag of een kano of een motorfiets veiliger is. Als je een meer gaat oversteken zou ik beslist voor een kano kiezen, maar als je de snelweg opgaat lijkt een motorfiets me een beter idee. Als je dat soort achtergrondinformatie er niet bij geeft valt er geen zinnig woord over te zeggen.

Dus over wat voor gegevens heb je het? En in wat voor omgeving worden ze gebruikt, en hoe moeten ze benaderd kunnen worden? Heb je het over je eigen thuiscomputertje waar verder niemand aankomt of heb je het over een bedrijfsnetwerk met honderden gebruikers die toegang tot de gegevens nodig hebben? Heb je het over je verzameling vakantiefoto's of over de tabellen met klanten, artikelen, voorraden en orders van een bedrijf dat iets verkoopt? Dat maakt nogal wat uit.

Door de manier waarop je je vraag stelt bekruipt me het gevoel dat je misschien nog geen begin van een idee hebt wat een database eigenlijk is. Dat je bestanden op een schijf kan opslaan zal iedereen die een computer gebruikt wel min of meer weten, maar denk je misschien dat een database een soort een-op-een-alternatief daarvoor is dat je ongeveer op dezelfde manier gebruikt? Als dat is wat je denkt en je je afvraagt of je bestanden misschien veiliger zijn als je ze in een database zet kan ik kort zijn: nee, dat werkt niet. Niet vanwege veiligheid maar omdat een filesysteem (wat je nu gebruikt voor bestanden) gewoon geschikt voor het doel is en een database voor een ander soort dingen dient.

(Ik kan het nu ingewikkeld maken door uit te wijden over dat databases vaak in bestanden staan, zoals hierboven al is opgemerkt, en dat je een filesysteem waar bestanden in geplaatst worden als een soort hiërarchische database voor ongestructureerde data kan opvatten, maar laat ik daar maar niet te diep induiken ;-) )

Security is afhankelijk van configuratie. Indien je je database internetfacing maakt, en je gebruikt default credentials, die iedereen kan raden - is je database dan veilig ? Een uitspraak doen of databases (danwel losse bestanden) veilig zijn is niet echt mogelijk als je de vraag negeert hoe de informatie beveiligd is, en hoe je systeem geconfigureerd is.

-> Gebruik je veilige credentials ?
-> Gebruik je controls om bruteforce aanvallen te voorkomen ?
-> Is je database encrypted ?
-> Is je database (al dan niet mbv firewall afgeschermd) bereikbaar vanaf het internet ?

Etc....

Het hangt heel sterk af van de features en configuratie van de database en van de features en configuratie van het bestandssysteem (of fileserver).
De eerste vraag is "welk soort veiligheid zoek je?" (beschikbaarheid, integriteit of vertrouwelijkheid) Zijn er andere veiligheidsaspecten van belang (audit-trail)? Hoe wil je authenticatie en autorisatie regelen?

Een ding kan ik je wel vertellen: een database waarvan de datafiles toegankelijk zijn voor gewone gebruikers is onveilig!

Als programmeur zeg ik: Zowel databases als platte files hebben hun toepassingsgebieden. Kies de beste opslagtechniek voor jouw toepassing, rekening houdend met de sterke en zwakke punten van iedere optie.

Ik hoor deze discussie ook wel eens bij management lagen.
Maar meestal gaat deze discussie dan specifiek over:

"File Shares" vs "Sharepoint"

Waar ik argumenten heb gehoord dat Ransomware specifiek wel File Shares kan encrypten, maar niet de bestanden die opgeslagen zijn in SharePoint (dus niet benaderbaar via SMB).

Hier hoor ik dezelfde termen zoals het opslaan van bestanden in een "database"


Dus mee eens dat de context beter moet, en tja wat is "veiliger"...

En een aanvaller van buitenaf kan via een slecht beveilgd account in SharePoint bestanden aanpassen...

Een database voorziet in journalling en logging, het heeft vaker een uitgebreider en begrijpelijker verhaal over groepen en rechten om toegang te verlenen. Met de BLOB objecten in een database kun je de applicaties voorzien in een opslagwijze dat lijkt op een filesysteem. Een distributed verhaal met locking op de objecten maakt het verschil compleet.
Een opslag nar het OS gaat vaak gepaard met encryptie. De os storage beheerder kan weinig met die database files.

Als je het filesysteem voor je applicaties voorziet via een database dan krijg je die database voordelen en bedenk dat je ook de nadelen krijgt. Zo'n database moet weer wel van het filesysteem op het OS gebruik maken voor de fysieke hardware.
Een beperking vind je terug in de limiet van de omvang.

Het argument "file shares" of een "document management systeem" SharePoint is een optie voor dat laatste zoals ook cloud opslag.

Mevrouw Van Rijbroek? Het kwaad aangericht bij Centric en Strukton, door dat paardmeisje, is helaas al geschied:

https://www.security.nl/posting/604274/620+Miljoen+Hack+met+Social+Engineering

Een filesysteem is ook een database.
Een verzameling files op een filesysteem is ook een database.
Een verzameling van gegevens is een database

De term database is heel erg algemeen.

Zelfs de genoemde smart blockchain is een database ;-)

Veilig: ook daar zijn vele definities voor.

Voornaamste vraag is eigenlijk:
- zoals de gegevens nu staan, werkt dat efficient en is duidelijk wie er wel of niet in kan/mag
- is er een backup
- AVG ?
- vallen de gegevens binnen een bepaalde category waardoor deze strenger bewaakt moeten worden
- etc
- etc

@TS, het lijkt me goed dat je de uitnodiging voor wat extra toelichting ter harte neemt. Tot die tijd stel ik voor niet verder te antwoorden op dit topic.

Als je een database filesysteem bedoeld is dit waar, maar verder is dit meestal niet waar!

Een database is speciaal georganiseerd/gestructureerd en geoptimaliseerd (met speciale database management software) om snel te kunnen vinden wat je zoekt en toegang te krijgen. En dat gaat lang niet voor ieder filesysteem op.

Toch wel. Je hebt sleutels in de vorm van bestandsnamen en je krijgt er waarden voor terug in de vorm van de bestandsinhouden.

Als je kijkt naar de verschillende soorten database software dan varieert dat van simpel tot erg ingewikkeld. Lang niet alle databases vallen onder het "relationele" model, met tabellen en relaties enzo. Of "objecten", of "documenten", of wat dan ook. Er zijn er ook genoeg die bijvoorbeeld niet meer doen dan een sleutel aan een waarde hangen ("key/value store"). Maar er zijn er ook die veel meer features bieden. Bestandssystemen net zo.

Bij het woord "database" hebben verschillende mensen verschillende ideeën; met name omdat ze verschillende definities gebruiken. Ik gebruik het zowel is losse zin (gestructureerde gegevensverzameling in een groep bestanden) als in strike zin (SQL-database). Naast de relationele (SQL) database zijn er nog andere (hiërarchische en netwerk) databases. Keus genoeg.

Je hebt alsnog SharePoint (On-Premise) voor bijvoorbeeld alleen Intern... en SharePoint Online...
Beide zijn goed te beveiligen.

Een slecht beveiligd account heb je in beide situaties een probleem lijkt mij?

Sharepoint Online is ook goed te beveiligen i.c.m. Intune en MFA.

Toch niet.
https://duckduckgo.com/html?q=difference%20filesystem%20database

Toch wel als de goede vraag stelt.
Gebruik ook de term document management system
https://www.sqlservercentral.com/articles/dbms-vs-file-management-system

Een file-management-system is wat anders dan een file-system.
https://www.techopedia.com/definition/1832/file-management-system

Helaas,
leuk geprobeerd

Lees de vraag bovenin van TS nog eens.
Losse files (file systen) of een database ofwel document management systeem. Losse files worden in policy documentatie vaak aangeduid als "documenten"

Je kan de makkelijk ds relaties tussen documenten en meer invullen. Je moet luisteren naar wat de achterliggende vraag is. Dat zonder op het woordgebruik met andere betekenissen vast te zitten.
De C van communicatie is niet overbodig in ICT.
https://www.techopedia.com/definition/12769/electronic-document-management-system-edms

Ik weet niet of je het door hebt, maar ik reageerde oorspronkelijk op de reactie van anoniem 20-09-2019, 11:47.
"Een filesysteem is ook een database." En ik heb in eerdere posts aangegeven waarom dit niet zo is.
(Je moet wel even opletten waar precies op werd gereageerd)

Nee ik had het niet door zoals je doorhebt. r.

Nu heb ik die discussie moet een database oplossing worden mag geen files system gebruiken wat vaak aan de hand gehad.
DBA's die alles in hun tool willen hebben omdat het zo hoort. Als dan losse files of hun tool niet het meest voor de hand liggende is gaan ze steigeren.

Hadoop https://hadoop.apache.org/docs/current/api/org/apache/hadoop/fs/FileSystem.html werd met het datalake lang als de oplossing voor database problemen gezien. Is hadoop nu een filesystem of door Pig een database.
hhttps://www.tutorialspoint.com/apache_pig/apache_pig_architecture.html Het zijn technische vragen die met een bepaald soort gebruik samen hangen.

Hier nog even de anoniem van 20-09-2019, 11:47 ;-)

Er zijn inderdaad vele definities voor het woord database.
Maar in basis is een database: een collectie van gerelateerde data ( electronisch opgeslagen ) (ongeacht de opslag methode)
Daarmee is een filesysteem per definitie een database.

https://www.dictionary.com/browse/database

Het is geen (R)DBMS ( Relationeel DataBase Management Systeem ) dus daar geen ik iedereen gelijk in, maar dat was ook niet de vraag van de TS ;-)

Zo nu jullie weer

ROFL:ROFL:ROFL:ROFL
___^___ _
L __/ [] \
LOL===__ \
L \___ ___ ___]
I I
----------/

toch mooi de hele discussie, zonder enige feedback van TS.

Ehm... ik zie er wel wat in om "datalake" op deze site voortaan te beschouwen als de overtreffende trap van "datalekken",
maar goed, dat is weer heeeeeel wat anders. ;)

To the point nu: interessant dat je dit aandraagt.
Er bestaat wel zoiets als een "database-based file system":
https://en.wikipedia.org/wiki/File_system#Database_file_systems
Dus dit kan. Daar hield ik eerder ook wel rekening mee:


Yep! En een skelter is een auto, want een skelter heeft ook 4 wielen en een stuur. ;)
https://www.skelters.nl/images/skelters_audi_skelter_rood.jpg