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.
Contents
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:
- email (niet graag, maar het kan)
- dropbox
- box.net
- 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. We kunnen niet alles op miscommunicatie (punt 3) wegschrijven, wij zijn de experts en wij hadden het functionele beveiligingsissue van de attachments op de agenda moeten zetten. Ook al wordt het niet als zodanig door de klant gememoreerd. En ook als de klant geen tijd wil investeren in deze analyse overigens (dat is bij "Klant E" niet het geval, men zou er direct ontvankelijk voor zijn geweest); het is voortaan een must bij 2Value. Functionele beveiliging is vanaf nu een vast onderdeel van onze Methodiek.
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
- Henk van Cann 6/21/11 3:39 PM
- ja want dat andere (artikelen) hebben we wel toegezegd
- Bas Vredeling 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
- Bas Vredeling 6/21/11 3:40 PM
- dat is de nieuwe wens
- Henk van Cann 6/21/11 4:04 PM
- Cases waar we evt. toezeggingen hebben gedaan over het onderwerp afgeschermde documenten versus publieke documenten:
- Check svp nog even of we daar mis zitten, zodat ik WWWWWW kan berichten
- 6/21/11 4:39 PM
- Loopt hier boven geen bloed uit?
- Bas Vredeling 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
- Henk van Cann 6/21/11 4:41 PM
- ok, aan mij de eer om het uit te leggen
- Bas Vredeling 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
- Henk van Cann 6/21/11 4:43 PM
- On 6/21/11, at 4:42 PM, Bas Vredeling wrote:
- > en later zijn die "documenten" weer publiek geworden
- Henk: hiermee bedoel je de attachments?
- Bas Vredeling 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
