Programma's ontwerpen: Veiligheid als principe

“But who does hawk at eagles with a dove?”
                                                            - C. Herbert

Veiligheidslekken zijn aan de orde van de dag en bedrijfsoplossingen zijn geen uitzondering op de regel. Maar wat verstaan we onder veiligheid als het aankomt op industriële oplossingen? En nog belangrijker; hoe nemen we beveiliging mee in het ontwerp?

Er zijn 4 facetten van veiligheid in de software ontwikkeling:

-       integriteit van informatie

-       zichtbaarheid van informatie

-       structurele mechanismen en hun robuustheid

-       omgeving en ecologische omstandigheden.

Wanneer we met informatie werken, willen we dat deze informatie niet corrupteerd. Dat wil zeggen dat gegevens niet onbeheersbaar aangepast zouden mogen worden, vooral wanneer er privacy gevoelige informatie gebruikt wordt door de oplossing. Wanneer de database bijvoorbeeld niet goed wordt afgeschermd kan het drastische gevolgen hebben, zoals diefstal en/of verlies van gegevens.

Ook willen we niet dat informatie kan worden ‘afgeluisterd’ dan de bestemde kanalen. De transmissie van gegevens kan misbruikt worden door relatief eenvoudige methoden, maar ook de informatie die in bestanden worden opgeslagen zijn een veiligheidsgevaar.

Soms zijn er briljante oplossingen met technische mechanismen, die niet getest worden op misbruik; per ongeluk ontdekt men opeens dat ongewenste resultaten mogelijk zijn met desastreuze gevolgen van dien. De robuustheid van de oplossing valt van een degelijk en goed product neer op de harde bodem van onbetrouwbaar.

Als laatste aspect zijn er van allerlei adders in het gras waar je als ontwerper geen controle over hebt: het systeem en platform waar de oplossing zich in bevind. Een slecht afgebakend systeem is als een programma vol veiligheidslekken, en omdat je oplossing werkt als een subproces op dat systeem, betekent dat het moederproces hogere toegangsrechten kent dan de eigen oplossing.

Nu is informatiebeveiliging een vak op zichzelf, maar zou iedere ontwerper vanaf het begin af aan een aantal principes moeten toepassen. Naast het inlichtingen inwinnen van een deskundige, is het goud waard om het Sam Rain Security Principe ten harte te nemen.

Het Sam Rain Security Principe

1.     als je het systeem niet vertrouwd, is je applicatie ook niet te vertrouwen. (iedere ‘hacker’ wilt de hoogste systeemprivileges, voor totale controle)

2.     vertrouw geen enkele  invoer van een gebruiker dat informatie is voor de database en met name speciale symbolen. (databases hebben een eigen programmeeromgeving en doen geen speciale controles op aanvragen en commando’s)

3.     gebruik gegevensversleuteling (encryptie) voor het versturen en ontvangen van gevoelige informatie, zoals inlogprocedures (informatie over een netwerk vliegt in het rond en kan opgevangen worden)

4.     laat een oplossing gestress-test worden door een deskundige. (laat niets aan toeval over, een productie oplossing is moeilijk stil te leggen voor een plakband en nietjes oplossing)

5.     vertrouw geen enkele gebruiker, alleen een beheerder voor onderhoud geniet hoge privileges, werk met rollen en verantwoordelijkheden (directeuren en managers zijn zelden techneuten, maar altijd mensen).

Om een boekje open te doen: de meeste industriële software die ik ‘ontworpen’ heb zien worden sloegen óf deze punten over óf namen deze niet serieus óf schoven deze zover vooruit dat het te moeilijk was om alsnog te realiseren. *kuch* banken, *kuch* overheden, *kuch*’specialisten’.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Veiligheid

Technische Oplossingen Begrijpen: De 'Platform' Technologieen

“Wanneer een man van lopen naar rennen gaat is het vooruitgang; pas wanneer hij schoenen aantrekt, praten we over technologie”
                                                                                                                      - Sam Rain

Als het aankomt op technologie denkt men eerder aan nieuwe Apple™ producten, ruimteschepen en lasers. Technologie kan ook in hele kleine wonderen komen, zoals in de vorm van programma’s. Bij programma’s denkt men snel in applicaties, zoals Word™ of Outlook™; soms kan een programma zo klein zijn dat een gebruiker het nooit zou opmerken. Echter op het moment dat een programma een taak verricht valt het onder technologie, praktisch of niet.

Een platform staat bol van technologieën; uiterst complexe programma’s voor het verwerken van allerlei taken, echter in zijn geheel losgekoppeld. Feitelijk zijn het zelfstandige, van elkaar uistaande modulen. Dankzij deze methode werken ze uitzonderlijk snel en kan een software architect bepaalde functionaliteit ontwerpen met hulp van deze ‘bouwstenen’. Het platform is dan een grote collectie van materiaal, samengesteld om een specifiek doel te dienen. Zonder deze technologieën zou er geen platform zijn en zou alle functionaliteit eerst geproduceerd moeten worden; een kostbare en tijdrovende zaak.

Een module van technologie is het beste te omschrijven als een apparaat. Wanneer een knop van een afstandsbediening wordt ingedrukt als deze op een televisie is gericht, verandert het kanaal. De complexiteit hoeft niet begrepen te worden om het te gebruiken. Deze manier van werken wordt daarom ook ‘black-boxing’ genoemd; een ‘vriendelijk’ mechanisme wordt in plaats gezet wat het gebruik mogelijk maakt. Dit mechanisme heet in technisch vakjargon de ‘interface’. De werking van de interface en het resultaat staan in de module documentatie.

Een platform heeft al deze modulen gerangschikt; sommige modulen zijn benodigd om fundamentele taken op te lossen, zoals communicatie tussen de applicatie server en een database. Andere modulen werken nauw samen met andere modulen voor bijvoorbeeld het converteren van bestandstypen; van een Word™ document een printbare versie formaat (PDF) maken kan zo’n conversie zijn. Dit zijn dan vanzelfsprekende modulen; ze hebben weinig verandering nodig, omdat ze een op zichzelf staand proces voltooien.

Platformen hebben meestal een primair doel: ze ondersteunen software architecten en uitvoerders bij een bepaalde strategie. Zo zijn er platformen die hele complexe berekeningen kunnen uitvoeren met behulp van modules, sommigen bieden technologieën die schematische processen kunnen omzetten naar een oplossing (BPM), distributie en integratie van informatie kunnen beheren (EAI) of een arsenaal aan wet technologie ter beschikking stellen (Foundation Classer). Omdat modulen niet zelfstandig starten, worden ze beheerd door applicatie servers; een platform garandeert daarom dat alle modulen tot dezelfde technologie behoren zodat ze ook door de applicatie server begrepen worden.

Een platform houdt ook actief bij welke ‘versies’ van een module gebruikt wordt. Zo wordt er gezorgd voor een industrie standaard en voorkomen dat oplossingen onverwachte resultaten opleveren. Het is mogelijk om eigen catalogi van modulen toe te voegen aan een platform, echter vallen deze buiten het ondersteuningsbeleid van de leverancier. Er zijn namelijk ook gespecialiseerde bedrijven die modulen voor platformen maken en daar wel ondersteuning voor leveren. Hoewel de voorkeur zou moeten zijn voor aanvulling vanuit de leverancier.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Platform Technologieen