Ga naar inhoud
  • 0

toegangsrechten


jw

Vraag

Het is natuurlijk goed dat Filemaker werkt aan de veiligheid van de bestanden, maar ...

waar ik dan tegen aanloop, als een bestand door FilemakerServer wordt gehost, kan ik het niet zo maar openen.

Dan moet je het eerst goed vinden, anders krijg je foutcode 825 of zo iets.

Wel lastig als je een bestand vervangt of er bij zet. Kun je dat zoietst

vooraf al regelen voordat je het bestand op de Server zet?

aangepast door jw
Link naar reactie

22 antwoorden op deze vraag

Aanbevolen berichten

  • 0

Fout 825 krijg je alleen maar als het bestand geen toestemming heeft gekregen in het bestand waarnaartoe het een referentie legt.

Je lost dat heel simpel op door het nieuwe bestand te hosten en vervolgens meteen in het bestand waarnaartoe wordt gerefereerd toestemming te geven. Die toestemming geef je in het menu: File/Manage/Security/Advanced Settings/File Access.

Let op! Wanneer je een bestand maakt, dan krijgt dat bestand een intern ID en die wordt gebruikt voor deze beveiliging. Dupliceer je het bestand, dan wordt ook die ID meegekopiëerd. Een bestand alleen en andere naam geven is dus niet voldoende, je zal dan de ID ook moeten resetten.

Andersom is het nog wat lastiger: Je maakt een nieuw bestand TripleX.fmp12 om een bestaande te gaan vervangen, dan heeft dat bestand een eigen uniek intern ID. Als je dan het bestand bij jouw klant vervangt, dan zal je in alle bestanden waarheen het nieuwe TripleX referenties heeft, die toestemming opnieuw moeten geven.

Als je dus zaken wilt wijzigen/vervangen en je hebt deze beveiliging aanstaan (je kan het helaas uitzetten), dan is het de beste keuze om het bestaande bestand van de klant als start te gebruiken, dat te wijzigen/uit te breiden en terug te zetten. Voor een geheel nieuw bestand dat je gaat toevoegen moet je in elk geval alle gerefereerde bestanden langs om toestemming te geven.

Link naar reactie
  • 0

Je bent dan inderdaad van het "gedoe" af, maar je hebt wel een beveiligingslek van jewelste. Werk je in je eentje, dan maakt het niet uit, maar in een situatie met meerdere gebruikers is dat een heel ander verhaal.

Als iemand toegang heeft tot gegevens met een gebruikersnaam en password, dan bepaal jij als ontwikkelaar meestal wat ze wel en niet mogen. Sommige delen van de informatie mogen ze niet bewerken, maar wel zien. Van de info die ze mogen zien, mogen ze soms maar één records tegelijk zien (denk hierbij ook aan de AVG/GDPR) en dat kan je prima afdwingen met jouw programmering.

Het probleem is dat ze al toegang hebben tot gegevens en zij kunnen zelf gemakkelijk een nieuw los bestand aanmaken en daarin hun inlog hetzelfde instellen om daarin [Full Access] te hebben. Alle beperkingen die jij in jouw programmering hebt ingebouwd om gegevens te zien én te exporteren kunnen zo worden omzeild.

Ter demonstratie heb ik 3 bestandjes toegevoegd. 
De gebruikers van de beide Data_Beveiligd en Data_Onbeveiligd bestanden zijn 
Admin:admin voor [Full Access] en 
User:user voor Read-Only Access zonder rechten om te printen of te exporteren

Het bestand Interface heeft slechts één gebruiker:
User:user voor [Full Access]
het bestand opent automatisch met deze gebruiker.

Leg nu een koppeling vanuit "Interface" naar "Data_Onbeveiligd", maak een layout met de tabel uit dat bestand en exporteer alle gegevens..... er wordt je geen strobreed in de weg gelegd, want je hebt leesrechten. Je kan niks wijzigen, maar je kan alles zien en exporteren.

Probeer nu een koppeling te leggen met "Data_Beveiligd". Dat gaat alleen lukken als je met Admin:admin toestemming geeft. Daarna kan de gebruiker ook weer alles exporteren, maar dan alleen maar omdat jij daarvoor toestemming hebt gegeven (hij heeft immers met admin-toegang toestemming gekregen om een koppeling te maken)

Wil je het recente débacle van de GGD bij jouw klanten voorkomen, dan zou ik toch nog eens nadenken over het weghalen van die beveiliging.

Beveiligen.zip

Link naar reactie
  • 0

dank je voor jullie antwoorden. Zo valt er nog veel te leren.

Zelf werk ik sinds 1995 met Filemaker en heb ik de veiligheid vanaf het begin een serieuze zaak gevonden. Niet eens omdat iemand kwaad willend iets stuk maakt maar eerst gewoon om de data te beschermen tegen ondoordacht handelen zoals "delete all records" vanuit het menu. Filemaker heeft in de tussen tijd veel toegevoegd aan deze veiligheid en dat is goed en hard nodig.

 

Ik vraag me nog het volgende af:

ik maak bijna geen gebruik van het secrurity-menu. Als ontwikkelaar kan ik alles, de gebruikers krijgen een uitgekleed menu. Iets moet je hebben voor de Page-setup, printen, plakken, knippen en zo nog wat zaken. De rest regel ik geheel in de scripts en eventueel op de layout. Zo regel ik wie iets mag zien en wie iets mag wijzigen afhankelijk van de functie van de medewerker en afhankelijk van status van de gegevens. Voor mij lijkt dit geheel veilig. Als basis regel ik in een tabel wie met welk wachtwoord toegang heeft.

 

Of zijn er onder jullie ontwikkelaats fans om de security van het bestand zelf te gebruiken en alles aan en uit te vinken wie welk veld ziet en mag wijzigen.

Ik ben benieuwd.

Link naar reactie
  • 0

Ik ben fan van de minitieuse controle.

Ik heb in een fabriek te maken met de directie, inkoop, verkoop, financiële administratie, logistiek, hrm, websitebeheer, een chatdienst en productie. Er is toegang via FileMaker, Webdirect en de DataAPI. Simpelweg de zaak beveiligen door alleen scripts en custom-menu's schiet dan m.i. echt tekort.

Medewerkers mogen bijvoorbeeld absoluut niet bij de HRM informatie en als je alleen scripts en beperkte menu-toegang en eventueel curtom-menu's gebruikt is die beveiliging echt niet voldoende. Een ander aandachtspunt is bijvoorbeeld dat je van doorsnee verkoopmedewerkers niet wilt dat ze zomaar de inkoopgegevens kunnen bekijken. In sommige industrieën ligt de inkoop heel gevoelig en als dat te gemakkelijk toegankelijk is, dan worden bedrijfsgeheimen praktisch weggegeven. 

Toegang via webdirect en DataAPI is voor externe medewerkers en applicaties en daarvoor wil je echt alleen maar dat beschikbaar maken waar ze niet zonder kunnen.

Het gaat er niet eens om of medewerkers iets doen of van plan zijn, als je bijvoorbeeld ISO27001 certificering wil te krijgen, zal je aantoonbaar goed moeten beveiligen. Het security-menu van FileMaker kan je daar bij helpen. Je zal voor jezelf test-accounts moeten opzetten met iedere mogelijke privilegegroep en daar mee testen. Hetzelfde geldt voor wanneer je externe authenticatie gebruikt, ook daarvoor moet je privilegesets aanmaken met rechten en beperkingen.

Link naar reactie
  • 0
On 3/21/2021 at 1:11 PM, menno said:

Je bent dan inderdaad van het "gedoe" af, maar je hebt wel een beveiligingslek van jewelste. Werk je in je eentje, dan maakt het niet uit, maar in een situatie met meerdere gebruikers is dat een heel ander verhaal.

Als iemand toegang heeft tot gegevens met een gebruikersnaam en password, dan bepaal jij als ontwikkelaar meestal wat ze wel en niet mogen. Sommige delen van de informatie mogen ze niet bewerken, maar wel zien. Van de info die ze mogen zien, mogen ze soms maar één records tegelijk zien (denk hierbij ook aan de AVG/GDPR) en dat kan je prima afdwingen met jouw programmering.

Het probleem is dat ze al toegang hebben tot gegevens en zij kunnen zelf gemakkelijk een nieuw los bestand aanmaken en daarin hun inlog hetzelfde instellen om daarin [Full Access] te hebben. Alle beperkingen die jij in jouw programmering hebt ingebouwd om gegevens te zien én te exporteren kunnen zo worden omzeild.

 

Ho, wacht even. Als je je privileges zo inricht dat een gebruiker alleen maar die records kan zien waar hij toegang toe heeft, is er volgens mij geen lek.

Bijvoorbeeld: je voegt een gebruiker 'jan' toe. Deze is lid van de privilegeset 'user'. In deze privilegeset is de beperking opgenomen dat de gebruikers alleen records mogen zien waar in het veld 'sec_view' de naam van de gebruiker voorkomt.

Dus bijvoorbeeld de formule: patterncount ( sec_view ; get ( accountname )) > 0

Dit werkt natuurlijk ook als je een referentie naar het bestand maakt, en ook met de dataAPI, met ODBC, SQL, WebDirect enz enz.

En als je er nog wat tijd in stopt, kun je ook de toegang tot scripts, layouts en velden op de layouts beperken. Ik zie niet hoe je dat kunt omzeilen.

aangepast door hans erik
Link naar reactie
  • 0

 

@hans erik Jouw voorbeeldformule is ook record-level-security en dus maak je dan toch wél gebruik van de security van FM?

Download ook mijn voorbeeldje even, dan weet je wat ik bedoel en anders moeten we er misschien eens een sessie op de fmdg aan wijden. Over het gebruiken van de beveiligingen in FM zijn er veel verschillende meningen en lang niet alle manieren van implementatie van "security" zijn goede.  

Link naar reactie
  • 0

Ja, natuurlijk is dat record-level security die gebruik maakt van de FM security. Helaas gaat het niet op veld niveau (ja, enigszins, via de Layouts. Maar da's niet echt praktisch).

Ik maak ALTIJD gebruik van de FM security. 

Zo'n sessie lijkt me inderdaad prima. Ik heb door de jaren heen van alles geprobeerd en sommige dingen moet je enorm mee uitkijken: in de formule voor de toegang in de privilegeset kun je bijvoorbeeld Global Fields, unstored calculations en Global Variables gebruiken. Maar daar kleven de nodige nadelen aan: security-wise maar ook qua performance. Ik neem echter aan dat een 'get(accountname)' in de formule lokaal door FMserver wordt geëvalueerd, en dus niet heen en weer fietst tussen de client en de server. Zolang de berekening puur binnen de server wordt afgehandeld, lijkt me de security OK (vooropgesteld dat je login niet zomaar gehacked kan worden).

Claris zou best eens de moeite kunnen nemen hier een diepgaand white paper over te publiceren. Je maakt wel slapende honden wakker, maar de meeste slapende honden dat zijn de developers zelf, vrees ik.

Link naar reactie
  • 0

Lijkt mij ook een goed onderwerp voor een sessie. Kom ik ook weer eens. Of is het nu even online? Hopelijk hoeft dat binnenkort niet meer.

Alles via de Security afhandelen is een andere manier van denken over je data. Ik ben benieuwd. Overigens kunnen we ook wel eens een test opzetten om elkaar uit te dagen om van een bestand de data in bveeld te krijgen die je niet zou moeten kunnen zien. Ik zou zo best een opzetje willen maken als ik alles regel via script en layout.

 

Link naar reactie
  • 0

Ha. "Security through Obsurity". Daar zijn al veel developers ingetuind. FileMaker verzint dan nieuwe extended privileges om alles wat beter dicht te stoppen, want dat zijn ook de typisch achterdeurtjes. Da's ook de reden dat je een FileMaker Server die via internet toegankelijk is, best wel op de nieuwste versie houdt, en niet op versie 15, omdat het goedkoper is. Kan je zuur en uiteindelijk duur opbreken, want daar zijn die gaatjes immers niet toegestopt.

"File Access" ( nederlandse versie op aanvraag, sorry ) is een mooie feature, jammer genoeg heb ik er soms veel problemen mee, en ben ik eigenlijk verplicht om het af te zetten. Het loopt nogal mis zodra je met FMDataMigration dingen moet doen met veel bestanden. Niet consistent, da's ook een deel van het probleem. Als je meerdere bestanden migreert, maar sommige gewoon kopieert ( properties, value lsts, templates enz. ) dan zal de situatie nog wat complexer worden.

Ik vind die feature perfect voor een 1-file oplossing, maar naarmate er meer files bijkomen zie ik ook meer en meer problemen ontstaan.

Instinker: LayoutNames (bestandsnaam). Als je met deze functie een bestand aanspreekt dat beveiligd is via File Access, en je hebt nog geen toegang, dan krijg je geen vraag voor een admin paswoord of zo, maar een onduidelijk error nummer. Weet niet meer welk nummer dat was, maar ik ben er effe bezig mee geweest toen.

Link naar reactie
  • 0

Ik ben er naar aanleiding van dit draadje nog eens in gedoken, maar zo te zien is Encryption At Rest een geruisloze dood gestorven. Of heb ik iets gemist? 
Wat betreft Extended Privileges: niet een van de meest heldere interfaces van Filemaker.  Naast de ‘standaard set’ kun je je eigen EP’s aanmaken, maar ik vraag me af wie dat doet en wanneer?

aangepast door hans erik
Link naar reactie
  • 0
12 hours ago, hans erik said:

Naast de ‘standaard set’ kun je je eigen EP’s aanmaken, maar ik vraag me af wie dat doet en wanneer?

Ik gebruik het voor vrijwel elke database die ik maak. Met name omdat er tabellen zijn waarin gebruikers records niet mogen maken/weggooien, en dit is de beste manier om dat te voorkomen.

Link naar reactie
  • 0

Ik dacht dat een 'custom' extended privilege juist bedoeld was om (tijdelijk) een groep gebruikers extra privileges te geven? Dus juist andersom zou ik zeggen. Een voorbeeld uit FileMaker Pro 'The Missing Manual' (opa vertelt :-) )was bijvoorbeeld een rapport dat 1x per kwartaal gedraaid mag worden door meneer x. Er zijn natuurlijk een heleboel manieren om zoiets te realiseren, maar de extended privileges kun je laten aanpassen door een beheerder die verder niks mag.

aangepast door hans erik
Link naar reactie
  • 0

ik pak het draadje nog even op.

Het gaat weer even over de File ID.

Ik verkoop het zelfde bestand aan meerdere klanten. De klant heeft een "opstart bestandje" op de desktop. Dit bestandje is een fmp12-bestand met één script om het hoofdbestand te openen of netjes een melding te geven dat het niet is gevonden en voorkom ik allerlei interactie via Filemaker-schermen waar ik geen vorm aan kan geven. Het hoofdbestand moet dus ook toegang geven aan het opstartbestandje.

Maar ik doe er goed aan iedere klant een ander File-ID te geven. En daar wordt het ingewikkeld bij het uitleveren van een nieuwe versie.

Ik lees hier niets over. Is er iemand die hier een handige oplossing voor heeft?

Link naar reactie
  • 0

Ik heb de indruk dat je een startscript oid in het hoofdbestand aanroept met dat startbestand. Op deze manier kan je niet upgraden door simpel de data over te zetten met bijvoorbeeld FMDM-tool, je zal altijd in het hoofdbestand weer toestemming moeten geven aan het startbestand.

Heb je voor al die klanten eigen naam/wachtwoord combinaties ingesteld? Dan is een individuele File-ID voor ieder startbestand helemaal niet nodig, want die "FID-bescherming" heb je pas nodig wanneer iemand al toegang heeft met een juiste naam en wachtwoord. 

Hij kan zich dan zonder de aanwezigheid van FID met een eigen bestand via de [Full Access] toegang, meer toegang te geven tot jouw bestand, dan dat jij hebt voorzien. Heb je dan de beveiliging met FileID ingesteld, dan hem dat niet lukken.

 

Link naar reactie
  • 0

Menno, dank voor je antwoord. Ik roep, vanuit een startbestandje niet zozeer een script aan maar roep de database aan, en daarmee trigger ik natuurlijk het startscript. Ik heb een eigen naam-wachtwoord oplossing, die is voor ieder weer anders. Verder zijn de bestanden altijd verborgen op de server. Als ik het FID uitzet werkt alles goed. Het lek blijft dan wel als je weet waar het bestand zich bevindt en hoe het heet, dan kun je via de importfunctie in de database komen.

Ik kom zo wel verder. Dank.

Link naar reactie

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Beantwoord deze vraag...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...