Method/Security

Language:	Nederlands

Subpages Method/Security

• %TITLE%
• %TITLE%

Security kent een aantal aspecten. We noemen hier 2 hoofdgroepen: Toegang voor werkzaamheden en Content op sites.

Toegang voor werkzaamheden

Medewerkers komen en gaan, werkzaamheden starten en eindigen. De praktijk leert dat bij de komst van medewerkers toegangen worden verstrekt, maar slecht zelden worden ingetrokken als de klus is geklaard of de medewerker(s) vertrokken. Dat wil 2Value beter doen.

Zorg

Klanten, partners en associates dragen zelf de zorg over ondermeer de veiligheid van haar eigen systemen. 2Value zorgt dat:

associates die werken onder 2Value vlag een een overeenkomst hebben ondertekend, waar deugdelijk werken en minimale voorzichtigheid is overeengekomen.

er interne standaarden, richtlijnen en methodieken zijn

alle partijen zich bewust zijn van de gecalculeerde risico's van bepaald handelen

Veiligheid is niet absoluut

De inrichting van veiligheid is het midden tussen risico, benodigde inspanning en geschatte gevolgen bij calamiteiten. De verschilt per situatie.

Associate richtlijnen

Zie associate richtlijnen voor het kundige beheer van:

eigen wachtwoorden

wachtwoorden van 2Value

wachtwoorden van klanten

2Value interne richtlijnen

Het management van de Toegang voor werkzaamheden en veilige exploitatie van Content op sites: intern 2Value

Content op sites

Met content op publieke sites moeten we voorzichtig omspringen. Net als met verloren USB-sticks en weg gegooide harddisks. Mensenlijke fouten voorkomen. Functionele veiligheid nastreven is de positieve benadering.

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. Het kan dan voorkomen dat gevoelige informatie op straat komt te liggen. Bijvoorbeeld via een publiek attachment aan een privaat artikel.

Dit hele speelveld is moeilijk te doorgronden voor klanten. En moeilijk uit te leggen door IT'ers. Er treedt snel spraak verwarring op. Kijk alleen al even naar de termen: tekst, URL, document, bestand, artikel, attachment, privaat, publiek, ....

Richtlijn

Voor 2Value experts is een belangrijke taak weggelegd.

Wij kunnen dit wel, omdat we anticiperen!

Telkens dienen we de functionele security check (mensenwerk!) door te lopen met de klant. Ook als de klant daar niet expliciet om vraagt. Vroeg of laat worden we namelijk ingehaald door de feiten.

Zie de onderstaande paragrafen en handel naar de laatste "Specialisme verplicht":

1. Technische veiligheid versus functionele veiligheid
2. Functionele veiligheid ons terrein van initiatief
3. Specialisme verplicht en daarom houvast, verder uitgewerkt in een Position contract Functionele security check

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.

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

Hoe lossen we binnen 2Value problemen op met ge hackte sites? : Site hack oplossen

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

Functionele veiligheid

Formeel geeft een SLA geen dekking voor het (zonder kosten) moeten oplossen van fouten onstaan door functionele onveiligheid. Zelfs tijdens de garantieperiode (doorgaans 1 kalendermaand) van een project 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.

Technische veiligheid

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

De beroepsaansprakelijkheidsverzekering geeft overigens wel gelegenheid om de gevolgen van technische 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.

Technische security versus privacy

Dat je als anonieme bezoeker geen bestanden aan artikelen kunt openen is vaak een gevolg van technische ingrepen/instellingen: tekst (content) en bestanden (attachments) moeten worden afgeschermd. Privacy gaat boven beschikbaarheid.

Private versus public

Er is dus een heel belangrijk verschil:

1. Publieke content versus private (na inloggen en passend bij je rechten) content.
2. Publieke bestanden (attachments) versus private bestanden (attachments).

Maak dit de klant glashelder!

Articles versus Attachments

Documenten hebben in sommige CMS'en een dubbele betekenis. Het kan zowel betrekking hebben op een content (article, document) als op bijlages, bestanden, attachments... Maak dit glashelder naar de klant!

Logged in versus anonymous

Een anonieme gebruiker is een webpagina-bezoeker die niet is ingelogd.

Ingelogd zijn, betekent nog niet dat je zo maar rechten hebt op bepaalde content.

En als je al rechten hebt op bepaalde content, zou het ook nog wel eens zo kunnen en moeten zijn dat deze gebruikers de attachments bij die content per stuk in hun rol wel/niet mogen zien en downloaden.

Maak dit allemaal helder voor de klant en dubbelcheck dat het is begrepen door hen voorbeelden te laten reproduceren.