Method/Security

Publieke artikelen kunnen privé attachments hebben. En andersom. Als je ingelogd bent, zie je alles. Van buiten (niet ingelogd) zie je als mens vaak niets, maar Google vindt je attachments wel, kan ze indexeren en de url beschikbaar stellen. Kortom: een woud aan onderlinge afhankelijkheden van content en toegangsrechten.

De zaak compliceert verder als redacteuren gevoelige informatie gaan uploaden voor ingelogde gebruikers. Als het CMS nog niet is gefinetuned op dit mechanisme, kan het voorkomen dat gevoelige informatie via een publiek attachment aan een privaat document (artikel!!) toch op straat komt te liggen.

Dit hele speelveld is moeilijk te doorgronden en uit te leggen en er treedt snel spraak verwarring op: tekst, URL, document, bestand, artikel, attachment, privaat, publiek, ....

Aan 2Value experts de taak dit telkens bij een functionele security check (mensenwerk) door te akkeren met de klant. Ook als de klant daar niet expliciet om vraagt. Vroeg of laat worden we namelijk ingehaald door de feiten.

Technische veiligheid versus functionele veiligheid

Technisch is heel vaak niets mis met de beveiliging, toegang en performance. Dat is het vakgebied van de Hosting. Vaak stellen wij vast: Met het gebruikte CMS en met de evt. beïnvloeding van derde systemen door het CMS is vaak alles in orde.

Security is altijd een middenweg tussen factoren als gebruiksgemak, kosten, risico dat je loopt en risico dat je mag lopen.

Het gaat vaak mis in het gebruik van systemen in combinatie met miscommunicatie.

Functionele veiligheid

De functionaliteit dat we per bestand (dat geupload moet kunnen worden bij artikelen) moeten kunnen aangeven of ze publiek dan wel afgeschermd moeten zijn, is een functionele wens. "Veiligheid" is een keuze

Iteraties zijn gevaarlijk...

Eerst dit toelaten dan dat is een gevaarlijke benadering. Je verliest content uit het oog. Meteen goed opzetten luidt het devies.

Vul deze pagina aan met gegevens uit: https://service.2value.nl/elzha/case/21432

Keuze tussen veiligheid en openbaarheid

Veiligheid gaat voor. Dan maar andere digitale manieren aanwenden om documenten op de plek van bestemming te krijgen en daar te beheren; zoals daar zijn:

1. email (niet graag, maar het kan)
2. dropbox
3. box.net
4. googledocs

Praktijkvoorbeeld

De configuratie deugde niet voor de doeleinden waarmee "Klant E" het CMS inzet. 2Value had die analyse in de architectuur ronde beter mee moeten nemen.

Noodzakelijke functionaliteit

De functionaliteit die we per bestand (dat geupload moet kunnen worden bij artikelen) nodig hebben:

we moeten per stuk kunnen aangeven of attachments publiek dan wel afgeschermd moeten zijn

Spraakverwarring voorbeeld

Om de hardnekkigheid van spraakverwarring te illustreren de volgende conversatie intern bij 2Value. De informatie van EEEEE is dan al op straat komen te liggen, gelukkig zonder directe gevolgen.

Waarom geven wij dit voorbeeld openhartig?

Als alle betrokkenen zich beseffen hoe ingewikkeld communicatie over content en inzage/wijzigings-rechten hebben klant en leveranciers samen de eerste slag gewonnen.

HHHHH en BBBBB hebben beide rechtstreeks contact met klant EEEEE, zoals te doen gebruikelijk binnen 2Value.

HHHHH 6/21/11 3:39 PM

ja want dat andere (artikelen) hebben we wel toegezegd

BBBBB 6/21/11 3:39 PM

documenten kunnen prive zijn

6/21/11 3:40 PM

maar je kunt ook publieke documenten met prive bestanden hebben en andersom

BBBBB 6/21/11 3:40 PM

dat is de nieuwe wens

HHHHH 6/21/11 4:04 PM

Cases waar we evt. toezeggingen hebben gedaan over het onderwerp afgeschermde documenten versus publieke documenten:

<lijst>

Check svp nog even of we daar mis zitten, zodat ik EEEEEE kan berichten

6/21/11 4:39 PM

Loopt hier boven geen bloed uit?

BBBBB 6/21/11 4:40 PM

Alles wat "document" heet in EEEEEE is GEEN bestand maar een content-type

6/21/11 4:40 PM

als er dus staat: "document moet verborgen zijn" dan wordt dat content type verborgen

6/21/11 4:40 PM

niet de attachments

HHHHH 6/21/11 4:41 PM

ok, aan mij de eer om het uit te leggen

BBBBB 6/21/11 4:42 PM

en later zijn die "documenten" weer publiek geworden

6/21/11 4:42 PM

toen ze nog verborgen waren kon google ze niet indexeren

6/21/11 4:42 PM

daarna wel

HHHHH 6/21/11 4:43 PM

On 6/21/11, at 4:42 PM, BBBBB wrote:

> en later zijn die "documenten" weer publiek geworden

HHHHH: hiermee bedoel je de attachments?

BBBBB 6/21/11 4:43 PM

nee, dat content type

6/21/11 4:44 PM

dat wilden ze

6/21/11 4:44 PM

verder heeft JJJJJJ in januari juist met die access rights het een en ander gedaan

.....

Conclusie

Duidelijk wordt waar de schoen wringt. Maar 2Value kan niet aan ontwikkelingshobbels bij klanten meebetalen.

We snappen evt. frustratie die niet naar wens werkende systemen kunnen brengen. Het systeem is echter van de klant en zo ook de verantwoordelijkheid voor de juiste keuzes, waar 2Value bij kan helpen. Sterker: 2Value leeft van dat helpen. Omdat in open source geen licentie-inkomsten gelden. We kennen ook geen resultaatverplichting-contract. Die zijn onbetaalbaar.

Zodra er zich problemen voordoen, we willen graag als teamlid bij/met klanten functioneren. En liever niet als kop van Jut. Dat geschreven hebbende, wil 2Value graag onderstrepen dat we blij zijn om met elke klant te mogen werken. En het is veelal erg prettig werken. Doorgaans leren wij in projecten steeds bij over communicatie in het algemeen, in alle gelederen (rollen) van onze organisatie. En dat is welkom en de charme van het teamwerk.

Specialisme verplicht

Formeel geeft een SLA geen dekking voor het (zonder kosten) moeten oplossen van fouten onstaan door functionele onveiligheid. Zelfs de garantieperiode (doorgaans 1 kalendermaand) van een projectvoorstel niet.

De beroepsaansprakelijkheidsverzekering geeft overigens wel gelegenheid om de gevolgen van functionele beveiligingsissue te claimen. Maar dat is geen gezellige route (via de verzekeraar....) En in vele gevallen waar geen daadwerkelijke schade is opgetreden ook weinig vruchtbare route. Omdat het een schade-verzekering betreft en geen (deel-)verantwoordelijkheidsboete o.i.d.