I-6 Software architectuur Deel 3: Perspectives Herziene versie feb 2010.

Presentatie over: "I-6 Software architectuur Deel 3: Perspectives Herziene versie feb 2010."— Transcript van de presentatie:

1 I-6 Software architectuur Deel 3: Perspectives Herziene versie feb 2010

2 I-6 Software architectuur, herziene versie 2010 Perspectives Meer dan… …..functionaliteiten Maar wel heel belangrijk! Hebben stakeholders deze concerns ook genoemd? “Kwaliteiten” zoals: Betrouwbaarheid van informatie  security perspective Waaronder beschikbaarheid  availibility perspective Prestaties van het systeem  performance perspective Ergonomie van het systeem  usabillity perspective Toegankelijkheid tot het systeem  accessibility perspective Flexibiliteit binnen het systeem  evolution perspective …. Kwaliteit is moeilijker te meten dan functionaliteit

3 I-6 Software architectuur, herziene versie 2010 Relatie perspectives - views

4 I-6 Software architectuur, herziene versie 2010 Perspective Security Is hot!.... en belangrijk, wie is daar nog niet van overtuigd Teveel incidenten (oa denial of service attack) Teveel vulnerabilities (virussen, malware, wormen) Teveel patches… Maar het gaat om meer! Desired quality uit het boek is prachtige definitie: reliably control, monitor and audit who can perform what actions Het gaat om “Betrouwbaarheid” Een standaard 3-deling is: Beschikbaarheid Integriteit Exclusiviteit

5 I-6 Software architectuur, herziene versie 2010 Perspective Security Externe bedreigingen Hackers Calamiteiten Storingen Interne bedreigingen Frauderende medewerker Om deze bedreigingen te weerstaan zijn zeer diverse maatregelen nodig Kwaliteit van software Toegang tot data (authenticatie en autorisatie) Kwaliteit van beheer (over de “juiste” instellingen) En meer … Security is niet alleen virussen maar ook goede backups (inclusief de beheerprocedure)

6 I-6 Software architectuur, herziene versie 2010 Security principles Defend in depth Don’t rely on obscurity Use secure defaults Grant the least amount of privilege Mooie principes, maar goed toepassen valt niet altijd mee Gebruik ze vooraf voor je architectuur/ontwerp En check achteraf ook of gerealiseerd

7 I-6 Software architectuur, herziene versie 2010 Security: authenticatie/ identificatie door het systeem Toegang verkrijgen tot het systeem Jezelf identificeren bij het systeem 3 concepten “Wat je weet”  password/ Pincode “Wat je hebt”  token/smartcard/ “Wie je bent”  biometrisch kenmerk Dit is een architectuur keuze! Hiervoor wil je algemene infrastructuur en niet per systeem/applicatie Gebruiksgemak Minder onderhoud

8 I-6 Software architectuur, herziene versie 2010 Security: Autorisatie / wat mag je? Je rechten op toegang tot data Lezen, schrijven, executeren R/W/E Praktijk Via ACL (Access Control List) op een filesystem Via Database autorisaties (zowel voor tabellen als stored procedures) Geldt ook voor RPC’s of webservice calls. beheren via centrale policy’s  implementatie niet altijd eenvoudig!

9 I-6 Software architectuur, herziene versie 2010 Security: access control /toegang tot data Autorisaties binnen een organisatie up-to-date houden is vaak een ramp. Veroorzaakt door vele inlog accounts, veel autorisaties binnen heel veel applicaties. Oplossing: Centrale LDAP server. Single sign on; één keer inloggen Aselect (DigiD),Kerberos helpen hier bij http://a-select.surfnet.nl/doc/aselect1.4.1.ocd.html Integratie van applicaties Internet bankieren en Ideal. Federated identity Identity & access management (IAM) Is dit goed geregeld dan ben je een ENORME stap verder

10 I-6 Software architectuur, herziene versie 2010 Kwaliteit van software Webapplicaties betrouwbaar? All input is bad vergeet de ontwikkelaar te vaak. Kijk eens op http://www.sans.org/top20/ http://www.owasp.org/index.php/Main_Page http://www.owasptop10.nl/ Kwaliteit

11 I-6 Software architectuur, herziene versie 2010 Security, kwaliteit van software Trend van problemen is verschuivend: Van TCP/IP en Windows naar applicaties zoals Acrobat Reader en Quick Time Maar ook naar maatwerk applicaties: Waarom: Minder getest,trager gepatched dus makkelijker target Daarom ook: Liever Third Party Infrastructure voor authenticatie dan zelf bouwen Vergeet niet: Don’t rely on obscurity Bron: SANS

12 I-6 Software architectuur, herziene versie 2010 Security en viewpoints Voorbeeld: Om snel te kunnen patchen en policy’s afdwingen Deployment viewpoint Algemene infrastructuur benodigd Centraal distribueren van software Centraal afdwingen van policy’s (LDAP, Active Directory) Alleen dan gaat het lukken

13 I-6 Software architectuur, herziene versie 2010 Performance & Scalability Wat is het verschil? Krijg een idee van je transactie volumes + data volumes! Weet je dit van te voren? Nee alleen ongeveer Denk aan piekbelasting. Die telt! Dus schaalbaar maken! Bottle necks identificeren Scaling up -> zwaardere server Scaling out -> Meerdere servers -> Loadbalancing Maar er kunnen beperkingen zijn, zoals statefull sessions Een beetje overcapaciteit is nooit weg!

14 I-6 Software architectuur, herziene versie 2010 Performance Is te modelleren….. Maar erg lastig Betrouwbare cijfers krijgen is moeilijk Interactief bepalen is mogelijk, kloppen deze gemeten waarden dan In de praktijk: vaak natte vinger methode + testen Maar dan wel met een realistische omgeving + data enz. Stress testen! Vele gebruikers tegelijkertijd Ook oplossingen zijn: Asynchrone verwerking Caching toepassen (maar pas op…, is niet eenvoudig Synchronisatie problemen (oa niet up-to-date zijn, tijdsvertraging)

15 I-6 Software architectuur, herziene versie 2010 Performance Response time Throughput Er is een punt waarop je systeem instort Dit is geen lineaire verband Twee keer zoveel gebruikers is niet een twee zo grote response time

16 I-6 Software architectuur, herziene versie 2010 Availability Kortweg: “het altijd doen”  99.99% beschikbaar! Dus ook bij storingen werken. Robuust zijn! Monitoring (zie je als er storing is?!)  Dashboards Automatisch herstarten (fraaie oplossing?) Ga uit van fouten, en wat doet het systeem dan? Single point of failures Planned downtime, unplanned, time to repair, disaster recovery MTBF, MTTR, Service windows  beschikbaarheids percentage? Change scenario’s  hoe kan (moet) je een change uitvoeren? Backups; beïnvloeden die nog de beschikbaarheid?

17 I-6 Software architectuur, herziene versie 2010 Evolution De mogelijkheid om een systeem aan te passen. “Aanpasbaar bouwen” Vooraf al geschikt zijn of achteraf inbouwen. Uiteindelijk zit je nooit goed (voorbeeld TCP/IP ) Te weinig adressen Maar ook nog voor future use bits. De gedoodverfde (bedrijfs)standaard Wat helpt wel: Duidelijke afgebakende functionaliteit Duidelijk interfaces (Lagen en modules) Open standaarden, die algemeen geaccepteerd zijn. Flexibele interfaces (veldje erbij, methode erbij)

18 I-6 Software architectuur, herziene versie 2010 Evolution Voorbeelden van evolutions: Extranet Beschikbaar komen op je Smart Phone “Real time” (direct afsluiten/ bestellen / overboeken) Hoe kan je je software bij een nieuwe release testen? Release kalender, duidelijk patch beleid Dit is voor de ene architectuur veel makkelijk dan voor de ander. Ook een wijsheid; kies gangbare producten. Niche is altijd een risico.

19 I-6 Software architectuur, herziene versie 2010 Case samenhang viewpoints en perspectives Via een centraal systeem kan een politieagent het opsporingsregister en nog andere essentiële informatie opvragen voor hun werk. Gebleken is dat tijdens calamiteiten de netwerkverbinding niet optimaal is. Hierdoor komt er een nieuwe requirement: de belangrijkste informatie is lokaal altijd opvraagbaar. (dus zonder netwerkverbinding) Welke viewpoints en perspectives worden nu geraakt?

20 I-6 Software architectuur, herziene versie 2010 Andere perspectives Accessibility “Drempels weg”, is geen probleem voor nette websites maar is opeens verplicht voor de overheid. Usability Hoe voorkom je fouten t.g.v. een slechte user interface? Vaak een communicatie issue … (CMD) …maar ook een security aspect Location/ Internationalisation. Andere taal, andere datum/tijd, vreemde valuta Regulation Controleerbaarheid is ook een belangrijke issue Transparantie bijvoorbeeld vereist door wetgever Sarbanes Oxley Act, Basel I en II, AFM, andere toezichthouders

21 I-6 Software architectuur, herziene versie 2010 Case: Nieuwsbrief verzenden Een organisatie heeft de behoefte om een nieuwsbrief verzenden naar potienteel honderdduizenden geïnteresseerde. In de nieuwsbrief staan oa links naar website van deze organisatie. Vraag: Hoe zet je nu een architectuur op en waarom. Hint: Denk vooral aan verantwoordelijkheden

22 I-6 Software architectuur, herziene versie 2010 Viewpoints en Perspectives Hoe nu te gebruiken? Dit is het model van het boek bij dit blok Andere modellen bestaan ook Maar deze modellen zijn in feite een checklist Waar moet je allemaal opletten? En op een overzichtelijk manier gegroepeerd Valkuil van veel modellen zo ook ons model: Backup in welk viewpoint/perspective hoort dit thuis? Zowel bij information, operational, security als availibility hoor je te denken, hoe zit het met mijn backup. Ieder met een iets andere focus

23 De Haagse Hogeschool Academie voor ICT& Media L.c.m.vankoppen@hhs.nl www.dehaagsehogeschool.nl