Recently in Speciale Weblog Category
Så blev det min tur til at annoncere at være kommet i arbejde.
Jeg er blevet ansat af IBM med start i januar - hvilket vil sige straks efter at være kommet hjem fra Thailand (hvor jeg er nede på et, synes jeg selv, 70% arbejds og 30% ferie ophold).
Jeg har brugt en del tid på at overveje min beslutning da begge de virksomheder jeg var i kontakt med, sidder med meget interessante opgaver, som ligger i forlængelse af mit speciale. Det som jeg dog har lagt vægt på ved IBM er de langsigtede karrieremuligheder og dét faktum at processen bliver fuldt lidt mere til dørs hos IBM samt at IBM har en enddog meget overbevisende position indenfor føderal identitet ligesom jeg kan lide deres holdning indenfor åbne standarder og open source.
Jeg glæder mig enormt meget til at komme i gang og jeg regner stadig med at holde liv i denne BLOG dog med nogle få ændringer - mere om det senere.
Jeg er blevet ansat af IBM med start i januar - hvilket vil sige straks efter at være kommet hjem fra Thailand (hvor jeg er nede på et, synes jeg selv, 70% arbejds og 30% ferie ophold).
Jeg har brugt en del tid på at overveje min beslutning da begge de virksomheder jeg var i kontakt med, sidder med meget interessante opgaver, som ligger i forlængelse af mit speciale. Det som jeg dog har lagt vægt på ved IBM er de langsigtede karrieremuligheder og dét faktum at processen bliver fuldt lidt mere til dørs hos IBM samt at IBM har en enddog meget overbevisende position indenfor føderal identitet ligesom jeg kan lide deres holdning indenfor åbne standarder og open source.
Jeg glæder mig enormt meget til at komme i gang og jeg regner stadig med at holde liv i denne BLOG dog med nogle få ændringer - mere om det senere.
I dag var jeg oppe til eksamen hvor mit speciale blev evalueret med en karakter på 10.
Det er jeg søreme godt tilfreds med! Og jeg jeg ikke mindst glad for at specialet er afsluttet og jeg nu kan kalde mig candidatus informationis technologiae (e-buss) :-D . Hvorvidt arbejdet med specialet stopper her eller om jeg tager det videre, vil jeg bruge den næste tid til at beslutte.
At området er interessant og relevant fremgår ret tydeligt af den interesse mit speciale allerede har opnået. To firmaer har rettet henvendelse efter at være blevet gjort opmærksom på specialet og min situation (tak Signe og John!).
Det gode er at som det ser ud nu, så er der gode muligheder for at jeg kan fortsætte med at arbejde indenfor netop det samme område som specialet behandler. Det er netop det jeg ønsker så jeg er fortrøstningsfuld for fremtiden.
Det er jeg søreme godt tilfreds med! Og jeg jeg ikke mindst glad for at specialet er afsluttet og jeg nu kan kalde mig candidatus informationis technologiae (e-buss) :-D . Hvorvidt arbejdet med specialet stopper her eller om jeg tager det videre, vil jeg bruge den næste tid til at beslutte.
At området er interessant og relevant fremgår ret tydeligt af den interesse mit speciale allerede har opnået. To firmaer har rettet henvendelse efter at være blevet gjort opmærksom på specialet og min situation (tak Signe og John!).
Det gode er at som det ser ud nu, så er der gode muligheder for at jeg kan fortsætte med at arbejde indenfor netop det samme område som specialet behandler. Det er netop det jeg ønsker så jeg er fortrøstningsfuld for fremtiden.
Ja - så nåede jeg et godt stykke nærmere vejs ende for dette speciale. Det har været en hård, men utrolig lærerig proces og jeg glæder mig faktisk lidt til at gå op og forsvare opgaven og få noget feedback på den.
Nu skal jeg bare finde et job hvor jeg kan fortsætte med samme emne, men den type niche hænger desværre ikke på træerne. Men jeg vil i hvert fald forsøge.
Specialet er frit tilgængeligt - og kan hentes via linket i venste kolonne. Jeg har dog frivilligt valgt at censurere begrebsafklaringerne fra mine interviews af respekt for mine interviewpersoner.
Konklusionen som er bragt nedenfor skulle give et hurtigt, men forenklet, overblik over opgavens fund.
Nu skal jeg bare finde et job hvor jeg kan fortsætte med samme emne, men den type niche hænger desværre ikke på træerne. Men jeg vil i hvert fald forsøge.
Specialet er frit tilgængeligt - og kan hentes via linket i venste kolonne. Jeg har dog frivilligt valgt at censurere begrebsafklaringerne fra mine interviews af respekt for mine interviewpersoner.
Konklusionen som er bragt nedenfor skulle give et hurtigt, men forenklet, overblik over opgavens fund.
Konklusion
I dette afsnit opsummeres resultaterne af analysen og diskussionen, som blev udarbejdet i et svar på følgende problemformulering:
Hvorledes sker den gensidige påvirkning mellem serviceorienteret arkitektur og it-sikkerhed?
Tidligt i opgaven blev det klarlagt, at it-sikkerhed typisk indgår som et element i it-arkitekturen. Derfor er det grundlæggende arkitekturvalget, som påvirker it-sikkerhed og ikke omvendt. Samtidig blev der påvist et klart mønster, hvor it-arkitekturen bestemmer it-sikkerhedsforanstaltningerne, som dog reflekterer tilbage på it-strategien og efterfølgende påvirker it-arkitekturen, hvorved der opstår en evolutionær cyklus, som langsomt tilpasser og modner de to områder.
Fire vanskeligheder fra Frederick P. Brooks' klassiske essay, No Silver Bullet, blev anvendt til at analysere den nærmere påvirkning imellem it-sikkerhed og SOA. Af disse essentielle vanskeligheder blev kompleksitet fundet som et centralt element i og med at kompleksitet kan være en væsentlig selvforstærkende sikkerhedstrussel samt fordi kompleksitet er et symptom på Brooks' tre resterende vanskeligheder. SOA blev i den forbindelse identificeret som en katalysator til at nedbringe kompleksitet primært gennem genbrug; standarder, abstraktion og gradvis tilbygning af ny funktionalitet. Da kompleksitet blev identificeret som en it-sikkerhedsmæssig risiko, kunne det derfor konkluderes at SOA, under forudsætning af styring, vil styrke it-sikkerheden.
Den mest grundlæggende påvirkning, som SOA har på it-sikkerhed, er kravet om interoperabel it-sikkerhed, som kan støtte SOA på et overordnet niveau. Til dette blev især standarder og politikker og kontrakter fundet altafgørende. Servicekontrakten blev især fremhævet som det serviceelement, der gør det muligt at implementere it-sikkerhed i SOA, uden at bryde den løse kobling. Kontrakterne besidder den fordel, at de kan aggregeres og nedbrydes på samme måde som services og derfor er fleksible til at indgå i alle servicens led. Kontrakten skal være udgangspunktet for servicen for at sikre en så løs kobling som mulig. Det er vigtigt, da kontrakten således også indgår i en top-down styring, som tager udgangspunkt i overordnede politikker og igennem større og større specialisering sætter rammerne for servicepolitikken.
Usynlighed blev identificeret som en essentiel vanskelighed, hvor SOA vil påvirke it-sikkerhed i en markant anderledes retning. SOA vil således i væsentligt grad forøge usynligheden i it-systemer, hvilket understreger nødvendigheden af en ny tilgang til it-sikkerhed, risikoanalyse og ikke mindst brugerstyring. Derfor blev en markant anderledes brugerstyringsmodel fremlagt - i opgaven præsenteret som 'referencemodellen for agil it-sikkerhed', der understøtter eksternalisering af sikkerhedsservices i et føderalt netværk, hvor der ikke er forskel på interne og eksterne brugere. Særligt tilføjer den nye model sikkerhedselementer såsom tillid og eksterne efterretninger.
Den agile model er oppe imod den traditionelle perimetermodel, som blev fundet fast forankret iblandt danske organisationer herunder også Sundhedsportalen. På baggrund af perimetermodellens infleksibilitet i håndteringen af især meget moden SOA vurderes det at skiftet imod den agile model vil ske evolutionært, men næppe hurtigt. Derfor forventes det, at den perimeterbaserede model i overgangsperioden vil påvirke SOA negativt ved at opstille for restriktive regler. Denne påstand underbygges bl.a. af et eksempel fra statens kommende it-sikkerhedsstandard DS484, der krævede perimetermodellen indført.
På trods af dette påvirker it-sikkerhed, i skikkelse af DS484, også SOA i en positiv retning. Dette sker bl.a. i kraft af DS484's status som kommende it-sikkerhedsstandard for staten, hvilket vurderes at skabe bedre sammenhæng og interoperabilitet igennem en ensartet tilgang til it-sikkerhed. Dog blev fremhævet nødvendigheden af en større bredde, der inkluderer alle offentlige forvaltninger i aftalen og ikke mindst en større konsekvens ved brud på, eller useriøs optagelse af standarden. Sundhedsportalens krav om overholdelse af DS484 overfor sine leverandører blev fremhævet som en god løsning til at udbrede sikkerhedsstandarden, og udgør, på sigt, en mulighed for at it-sikkerhed kan lægge til grund for en større udbredelse af SOA.
Sundhedsportalens rolle i opgaven var at fremstå som en praktisk pendant til den megen teori, der blev behandlet. Vurderingen af Sundhedsportalens brugerstyringstilgang og sikkerhedsmodel endte med at konkludere, at Sundhedsportalens brugerstyringsmodel har hvad der skal til for at kunne indgå i en større sammenhæng, men at den har lavet et kraftigt lock-in på Sundhedsdatanettet, hvilket betyder væsentligt mindre fleksibilitet. Sundhedsportalen blev også identificeret til at være en klar perimetermodel i kraft af en stærk mur udadtil og få interne sikkerhedsforanstaltninger, hvilket blev fremhævet som havende betydning for fleksibilitet og ikke mindst kompleksitet, hvis disse skal tilføjes efterfølgende. Således blev Sundhedsportalen et praktisk eksempel på et scenario, hvor it-sikkerhed kan være med til at påvirke SOA i en negativ retning.
Opgaven afsluttede med konstruktionen af en referencemodel for agil it-sikkerhed. Modellen opstiller syv principper, som blev fundet vigtige i forhold til at understøtte den agile it-sikkerhed. Selve referencemodellen blev opstillet som en udbygning af den traditionelle brugerstyringsmodel, men med den klare distinktion at den agile model vil skulle kunne operere i et føderalt netværk og således ikke være afhængig af en perimeter.
I hvad der kan betegnes som opgavens egen perimeter, blev spørgsmålet omkring borgerens retsstilling i en SOA kort diskuteret. Diskussionen fremhævede at it-arkitekter og jurister bør finde en middelvej hvor borgerens retsstilling ikke lider skade i et it-arkitekturarbejde der stadig har til mål at skabe en så sammenhængende it-arkitektur som muligt. Det blev vurderet at med den rette omtanke, kan det der nu virker som kompleksitetsforøgende faktorer, anvendes til fordel for it-arkitekturarbejdet såvel indenfor det offentlige som det private.
Sidst fandt opgaven en gennemgående forhindring, som er af allerstørste vigtighed. Uden en holdningsændring i processen fra den traditionelle perimeterbaserede, kontrolfikserede model til en tankegang med fuld forståelse for, hvorledes it-sikkerhed skal fungere side om side med SOA, ender man ikke blot op med en SOA's uden agilitet og deraf en række mistede forretningsmuligheder; men også en it-sikkerhedsmodel, som fortsat vil være reaktiv, ufleksibel og usikker. Derfor vurderes oplysning og uddannelse som nøgleelementer i at få spredt viden om, hvad der kræves for at få en sikker tilgang til SOA og en agil tilgang til it-sikkerhed.
Jeg synes godt at jeg vil bruge lidt kræfter på at bringe fokus på Jericho Forums arbejde med hvad de kalder "de-perimeterisation" - afperimeterlisering (forslag til en bedre oversættelse modtages gerne).
Denne blog-post er een ud af to. Dette første afsnit beskriver Jericho Forum og er taget fra et foreløbigt kapitel i min opgave. I den anden del vil jeg gennemløbe de indslag der er kommet til "The Jericho Forum Challenge" som er en nyligt afløbet konkurrence for til bedst at beskrive hvordan en arkitektur bygget over Jericho Forums principper, kan håndtere fremtidens problemstillinger. Men mere om det senere.
En gennemgang af Jericho Forum
Jericho Forum er et forum der opererer under Open Group.
Medlemmerne i forummet deler visionen, at i en verden hvor forretning og teknologi i stadig større grad sker over et globalt netværk, vil der på sigt blive diskrepans imellem nuværende sikkerhedsmetodikker og de nye krav og udfordringer som organisationer står overfor.
Vigtigt for udviklingen er det, at der sker overensstemmelse imellem sikkerhedsarkitekturen og it-arkitektur. Dette betyder at sikkerhedsarkitekturen skal understøtte organisationens forretningsprocesser såsom samarbejde og handel over åbne netværk, uden at skelne imellem om processen finder sted indenfor eller udenfor organisations fysiske mure. Mere specifikt går udviklingen imod:
Det primære problem med den eksisterende tilgang til it-sikkerhed, mener Jericho Forum, er afhængigheden af en netværksperimeter (typisk en firewall eller proxyserver) som en beskyttelse af det 'indre' imod det 'ydre'. Denne perimeterbaserede tilgang er ufleksibel og har ikke vist sig tilstrækkelig til at dæmme op omkring et stadig voksende antal angreb som får uanfægtet adgang til organisationen igennem autoriserede porte i perimeteren.
Problemerne afstedkommer på baggrund af ændrede krav fra forretningsmiljøet. De forretningsmæssige fordele ved outsourcing og serviceorienteret arkitektur stiller især krav om fleksibilitet og interoperabilitet igennem løst koblede systemer; in- og outsourcing af services; distribuerede brugere, etc. Men der er meget der tyder på, at det kræver en væsentlig holdningsændring for at sikre udveksling af transaktioner og kritisk forretningsdata under disse nye forhold.
Moulds & van Someren (2005: 2) forstærker, med følgende situationsbeskrivelse, synspunktet om, at der er behov for et holdningsskifte i tilgangen til it-sikkerhed.
Ifølge Jericho Forum, er løsningen, at trække perimeterbeskyttelsen ind til de individuelle netværksserver og apparater på netværket og i sidste ende autorisere på individuelt data. Således er målet at fingranulere autorisation til ressourcer, hvilket står i modsætning til trenden indenfor it-arkitektur, som går imod stadig større granulering af beskeder.
Jericho Forum kalder udviklingen for "de-perimeterisation" (afperimeterlisering). Selve ordbruget formodes valgt for at skabe debat fordi, som vist i denne gennemgang, er formålet ikke at fjerne perimeterafgrænsningen, men i stedet at hver applikation har dens egen perimeterbeskyttelse som bygger på en overordnet sikkerhedsmodel.
Dette er dog en model, som skal gennemtænkes grundigt hvis resultatet ikke skal blive en administrativt tungere, og mere usammenhængende sikkerhedsmodel. Derfor er interoperabilitet igennem åbne standarder en nødvendighed for at skabe sikre løsninger som understøtter ovenstående udvikling. En sådan løsning fordrer sandsynligvis adoptionen af føderale brugerstyringsmodeller da det synes logisk at identitetsstyringen bliver det centrale element i fremtidens sikkerhedsperimeter. Men behold firewall'en indtil vi er så langt.
Denne blog-post er een ud af to. Dette første afsnit beskriver Jericho Forum og er taget fra et foreløbigt kapitel i min opgave. I den anden del vil jeg gennemløbe de indslag der er kommet til "The Jericho Forum Challenge" som er en nyligt afløbet konkurrence for til bedst at beskrive hvordan en arkitektur bygget over Jericho Forums principper, kan håndtere fremtidens problemstillinger. Men mere om det senere.
En gennemgang af Jericho Forum
Jericho Forum er et forum der opererer under Open Group.
Medlemmerne i forummet deler visionen, at i en verden hvor forretning og teknologi i stadig større grad sker over et globalt netværk, vil der på sigt blive diskrepans imellem nuværende sikkerhedsmetodikker og de nye krav og udfordringer som organisationer står overfor.
Vigtigt for udviklingen er det, at der sker overensstemmelse imellem sikkerhedsarkitekturen og it-arkitektur. Dette betyder at sikkerhedsarkitekturen skal understøtte organisationens forretningsprocesser såsom samarbejde og handel over åbne netværk, uden at skelne imellem om processen finder sted indenfor eller udenfor organisations fysiske mure. Mere specifikt går udviklingen imod:
- Stigende online kollaboration og samhandel på tværs af et mangefold af forretningsentiteter - herunder håndtering af sensitiv og forretningskritisk information.
- Globale trends går imod en stigende anvendelse af outsourcing og offshoring af supportaktiviteterne i virksomhedernes værdikæde
Det primære problem med den eksisterende tilgang til it-sikkerhed, mener Jericho Forum, er afhængigheden af en netværksperimeter (typisk en firewall eller proxyserver) som en beskyttelse af det 'indre' imod det 'ydre'. Denne perimeterbaserede tilgang er ufleksibel og har ikke vist sig tilstrækkelig til at dæmme op omkring et stadig voksende antal angreb som får uanfægtet adgang til organisationen igennem autoriserede porte i perimeteren.
Problemerne afstedkommer på baggrund af ændrede krav fra forretningsmiljøet. De forretningsmæssige fordele ved outsourcing og serviceorienteret arkitektur stiller især krav om fleksibilitet og interoperabilitet igennem løst koblede systemer; in- og outsourcing af services; distribuerede brugere, etc. Men der er meget der tyder på, at det kræver en væsentlig holdningsændring for at sikre udveksling af transaktioner og kritisk forretningsdata under disse nye forhold.
Moulds & van Someren (2005: 2) forstærker, med følgende situationsbeskrivelse, synspunktet om, at der er behov for et holdningsskifte i tilgangen til it-sikkerhed.
In fact, the majority of the IAM (Identity & Authorization Management) market seems firmly rooted in the traditional perimeter world focused on administrative functions associated with weak password based authentication of users. Products place relatively little emphasis on security and are deployed âsafely' behind the perimeter. In some deployments security does come into play in the context of strong authentication i.e. the use of legacy tokens or smart cards, but here the emphasis is placed on authenticating select groups of remote users through the perimeter or providing physical building access to secure facilities. Rarely do these deployments extend to strengthening the collaboration and commercial activities that take place once initial access has been granted.
Ifølge Jericho Forum, er løsningen, at trække perimeterbeskyttelsen ind til de individuelle netværksserver og apparater på netværket og i sidste ende autorisere på individuelt data. Således er målet at fingranulere autorisation til ressourcer, hvilket står i modsætning til trenden indenfor it-arkitektur, som går imod stadig større granulering af beskeder.
Jericho Forum kalder udviklingen for "de-perimeterisation" (afperimeterlisering). Selve ordbruget formodes valgt for at skabe debat fordi, som vist i denne gennemgang, er formålet ikke at fjerne perimeterafgrænsningen, men i stedet at hver applikation har dens egen perimeterbeskyttelse som bygger på en overordnet sikkerhedsmodel.
Dette er dog en model, som skal gennemtænkes grundigt hvis resultatet ikke skal blive en administrativt tungere, og mere usammenhængende sikkerhedsmodel. Derfor er interoperabilitet igennem åbne standarder en nødvendighed for at skabe sikre løsninger som understøtter ovenstående udvikling. En sådan løsning fordrer sandsynligvis adoptionen af føderale brugerstyringsmodeller da det synes logisk at identitetsstyringen bliver det centrale element i fremtidens sikkerhedsperimeter. Men behold firewall'en indtil vi er så langt.
Ok - tingene går hurtigt ...
I en pressemeddelse 1. aug. annoncerede Oasis-Open.org deres eget OASIS Service Oriented Architecture Adoption Blueprints Technical Committee.
Mon ikke dette betyder enden for SOACenter.com.
På den anden side så kunne det betyde at Oasis-Open kan tilbyde den "fulde sandhed" for SOA - lige fra det konceptuelle til det normative. Men der går nok noget tid før det sker.
I en pressemeddelse 1. aug. annoncerede Oasis-Open.org deres eget OASIS Service Oriented Architecture Adoption Blueprints Technical Committee.
Mon ikke dette betyder enden for SOACenter.com.
På den anden side så kunne det betyde at Oasis-Open kan tilbyde den "fulde sandhed" for SOA - lige fra det konceptuelle til det normative. Men der går nok noget tid før det sker.
En række SOA interessenter (BEA, Cap Gemini, HP, Credit Suisse First Boston etc.) er gået sammen og har sat sig for at skabe et SOA blueprinting center.
Ideen er at fremhæve "best practices":
SOA Blueprints is an industry effort designed to help organizations more easily and affordably build applications using service-oriented architecture (SOA). SOA Blueprints highlights best practices through GeneriCo, a fictitious business entity, described in a functional and behavioral specification to demonstrate how SOA can solve real-world issues. SOA Blueprints creates a common vocabulary to discuss SOA in an architecturally neutral way allowing comparable implementations to be crafted using different technology sets including J2EE, .NET and Web Services.
Ligesom SOA-RM, er SOA-blueprints med til at tage brodden af alt den hype som mange virksomheder er med til at skabe (incl. SOAcenters egne medlemmer). Jeg håber bare at de vil understøtte hinanden i stedet for at skabe yderligere forvirring blandt os stakkes dødelige.
Ideen er at fremhæve "best practices":
SOA Blueprints is an industry effort designed to help organizations more easily and affordably build applications using service-oriented architecture (SOA). SOA Blueprints highlights best practices through GeneriCo, a fictitious business entity, described in a functional and behavioral specification to demonstrate how SOA can solve real-world issues. SOA Blueprints creates a common vocabulary to discuss SOA in an architecturally neutral way allowing comparable implementations to be crafted using different technology sets including J2EE, .NET and Web Services.
Ligesom SOA-RM, er SOA-blueprints med til at tage brodden af alt den hype som mange virksomheder er med til at skabe (incl. SOAcenters egne medlemmer). Jeg håber bare at de vil understøtte hinanden i stedet for at skabe yderligere forvirring blandt os stakkes dødelige.
Morgenens indbakke bød på flere interessante artikler:
ZapThink lagde ud med at fortælle om den mest almindelige faldgrube i arbejdet med at prøve SOA af. Ikke som den store overraskelse var det forvekslingen imellem Webservices og SOA som kom ud som #1.
The Zapthink Take
If you're an IT manager, the best thing you can do to avoid the SOA pilot pitfall is to put a seasoned architect in charge of the pilot project. Never forget that SOA is architecture -- you can't buy it from a vendor, and you can't build it with programming code. Architecture is a set of best practices that guide your implementations, regardless of the technologies you choose to implement them. No one but an architect will have the expertise to drive the architectural parts of the SOA pilot.
In practice, however, SOA pilots rarely if ever consist entirely of architecture. To achieve the goals of the pilot, you must put SOA into practice with a working implementation. Never mistake the implementation, however, for the architecture. If you do, you'll be joining all the other failures in the SOA pilot pitfall.
Den næste artikel var fra networkworld.com og bestod mest af alt af en rundspørge ibland security-managers omkring holdningen til nedbrydning af perimetrene som foreslået af Jericho Forum
The firewall is good at keeping out script kiddies and denial-of-service attacks, but otherwise it's really not a good security boundary with the Web and e-mail coming in," says Paul Simmonds, global information security director at chemicals and paints manufacturer ICI in the U.K., which is a Jericho Forum member.
Men udviklingen trækker også i den anden retning (Network devices simplify integration - web services security)
Flere of flere firewall leverandører kommer i disse dage ud med bokse som er specielt optimeret til XML og WS-Security. For mange af disse kører programmet på hardware hvilket nok er godt rent performance-wise.
British American Tobacco, based in London, has been using Cast Iron routers since 2003. "Software middleware was costing us too much to run, and it was too time-consuming to build new integrations," said Kevin Poulter, application technology manager. "In terms of taking us toward a more service-oriented architecture, [a software-based approach] would've cost us a significant investment of extra product[s]."
Compared with traditional middleware solutions, "there is little or no programming, it's all graphical; and the adapters come bundled with the appliance, so there's no additional cost," Poulter said. "It doesn't matter how many SAP systems we connect with, it's the same cost. With the old-school adapter model you connected two SAP systems and that was twice the money."
...der jo så lige den lille pointe at selvom disse firewalls er avancerede så har de stadig ingen virkning overfor den fintkornede brugerautorisation. Men som en metode til at lave END-to-END security ser jeg dem som meget værdifulde.
Problemet synes at ligge i netop den faldgrube som Zapthink snakker om: Den tekniske vs. den arkitektoniske.
Den tekniske løsning virker hurtigt og man ved at man får noget for pengene, hvorimod arkitekturarbejdet tager tid og er i fare for at ende som et skuffe-produkt.
Her ser jeg Jericho Forum som en måde at udforme en del af en agil sikkerhedsarkitektur således at hele løsningen kan svare overens med organisationens SOA.
ZapThink lagde ud med at fortælle om den mest almindelige faldgrube i arbejdet med at prøve SOA af. Ikke som den store overraskelse var det forvekslingen imellem Webservices og SOA som kom ud som #1.
The Zapthink Take
If you're an IT manager, the best thing you can do to avoid the SOA pilot pitfall is to put a seasoned architect in charge of the pilot project. Never forget that SOA is architecture -- you can't buy it from a vendor, and you can't build it with programming code. Architecture is a set of best practices that guide your implementations, regardless of the technologies you choose to implement them. No one but an architect will have the expertise to drive the architectural parts of the SOA pilot.
In practice, however, SOA pilots rarely if ever consist entirely of architecture. To achieve the goals of the pilot, you must put SOA into practice with a working implementation. Never mistake the implementation, however, for the architecture. If you do, you'll be joining all the other failures in the SOA pilot pitfall.
Den næste artikel var fra networkworld.com og bestod mest af alt af en rundspørge ibland security-managers omkring holdningen til nedbrydning af perimetrene som foreslået af Jericho Forum
The firewall is good at keeping out script kiddies and denial-of-service attacks, but otherwise it's really not a good security boundary with the Web and e-mail coming in," says Paul Simmonds, global information security director at chemicals and paints manufacturer ICI in the U.K., which is a Jericho Forum member.
Men udviklingen trækker også i den anden retning (Network devices simplify integration - web services security)
Flere of flere firewall leverandører kommer i disse dage ud med bokse som er specielt optimeret til XML og WS-Security. For mange af disse kører programmet på hardware hvilket nok er godt rent performance-wise.
British American Tobacco, based in London, has been using Cast Iron routers since 2003. "Software middleware was costing us too much to run, and it was too time-consuming to build new integrations," said Kevin Poulter, application technology manager. "In terms of taking us toward a more service-oriented architecture, [a software-based approach] would've cost us a significant investment of extra product[s]."
Compared with traditional middleware solutions, "there is little or no programming, it's all graphical; and the adapters come bundled with the appliance, so there's no additional cost," Poulter said. "It doesn't matter how many SAP systems we connect with, it's the same cost. With the old-school adapter model you connected two SAP systems and that was twice the money."
...der jo så lige den lille pointe at selvom disse firewalls er avancerede så har de stadig ingen virkning overfor den fintkornede brugerautorisation. Men som en metode til at lave END-to-END security ser jeg dem som meget værdifulde.
Problemet synes at ligge i netop den faldgrube som Zapthink snakker om: Den tekniske vs. den arkitektoniske.
Den tekniske løsning virker hurtigt og man ved at man får noget for pengene, hvorimod arkitekturarbejdet tager tid og er i fare for at ende som et skuffe-produkt.
Her ser jeg Jericho Forum som en måde at udforme en del af en agil sikkerhedsarkitektur således at hele løsningen kan svare overens med organisationens SOA.
Så fik jeg første case i hus. Det handler om brugerstyring og tager udgangspunkt i - Sundhed.dk - den fællesoffentlige sundhedsportals måde at foretage brugerstyring indenfor det offentlige og med anvendelse af OCES certifikatet (den digitale signatur).
Sundhed.dk anvender i dag en brugerstyringsmodel hvor de lader OCES tage sig af autentikationen af borgere og sundhedsfaglige - dette sker via en webservice ved at tjekke den offentlige nøgle i certifikatet op imod TDC's register.
Adgangen er forskellige imellem borgere og sundhedsfaglige - borgere får bare tjekket at deres certifikat er valid og seneste version etc. men de sundhedsfaglige - som anvender et virksomhedscertifikat - får tjekket at det CVR nummer de er hæftet på, nu også eksisterer i sundhed.dk's register over tilladte sundheds organisationer i Danmark (registreret er for en stor dels vedkommende taget fra amter og sundhedsstyrelsens autorisationsregister)
Selve autorisationen sker delvist hos sundhed.dk og delvist administreret af lokale administratorer ude i sundhedsinstitutionerne - de såkaldte LRA (Local Representative Authority). Dette er nok noget af det mest "avancerede" large-scale brugerstyring som vi kan vise i dag hvilket gør casen endnu mere interessant. Rent praktisk har problemerne mest været centret omkring uddannelse af LRA'erne og en decideret holdningsændring hos beslutningstagerne indenfor primært amterne hvor der stadigvæk synes at herske en smule teknologisk mistro (hvilket heller ikke er helt usundt)
Med hensyn til fremtiden vil sundhed.dk være en interessant kandidat til den "sande" føderale identitetsstyringsmodel hvor man opererer med en klassifikationsordning og information så er klassificeret i forhold til f.eks. hvor følsomt indholdet er. Men da OCES allerede anvendes er der noget der tyder på at det vil primært være systemerne indbyrdes som kommer til at anvende dette - f.eks. i forhold til integration med elektronisk patient journaler når de er klar.
Sundhed.dk anvender i dag en brugerstyringsmodel hvor de lader OCES tage sig af autentikationen af borgere og sundhedsfaglige - dette sker via en webservice ved at tjekke den offentlige nøgle i certifikatet op imod TDC's register.
Adgangen er forskellige imellem borgere og sundhedsfaglige - borgere får bare tjekket at deres certifikat er valid og seneste version etc. men de sundhedsfaglige - som anvender et virksomhedscertifikat - får tjekket at det CVR nummer de er hæftet på, nu også eksisterer i sundhed.dk's register over tilladte sundheds organisationer i Danmark (registreret er for en stor dels vedkommende taget fra amter og sundhedsstyrelsens autorisationsregister)
Selve autorisationen sker delvist hos sundhed.dk og delvist administreret af lokale administratorer ude i sundhedsinstitutionerne - de såkaldte LRA (Local Representative Authority). Dette er nok noget af det mest "avancerede" large-scale brugerstyring som vi kan vise i dag hvilket gør casen endnu mere interessant. Rent praktisk har problemerne mest været centret omkring uddannelse af LRA'erne og en decideret holdningsændring hos beslutningstagerne indenfor primært amterne hvor der stadigvæk synes at herske en smule teknologisk mistro (hvilket heller ikke er helt usundt)
Med hensyn til fremtiden vil sundhed.dk være en interessant kandidat til den "sande" føderale identitetsstyringsmodel hvor man opererer med en klassifikationsordning og information så er klassificeret i forhold til f.eks. hvor følsomt indholdet er. Men da OCES allerede anvendes er der noget der tyder på at det vil primært være systemerne indbyrdes som kommer til at anvende dette - f.eks. i forhold til integration med elektronisk patient journaler når de er klar.
Wickedpixel har været nede i nogle dage hvilket naturligvis har gjort at emails og blog har været ude af drift.
Anyway - jeg har selv haft travlt med diverse ting.
d. 31.12 var jeg til OIOXML Forum i Bredgade hos IT & Telestyrelsen. Forummet er lidt et nørdforum hvor der bliver heppet hver gang der bliver vist en XML streng.. men det er nu heller ikke at foragte da det giver et bedre indblik i XML standarderne. Denne gang var det mest interessante oplæg omkring
OIO Standardaftale for WebServices. Standardaftalen er en slags udvidet service level agreement (SLA) til offentlige myndighed, som meget nøjagtigt udpeger hvilke kontraktsmæssige områder det er vigtigt, at have på plads INDEN man kaster sig ud i ekstraorganisatorisk Webservices.
Aftalen er udarbejdet ud fra holdningen, at uden en kontraktslig aftale vil SOA aldrig komme op på benene fordi der skal være noget, som kan kontraktsligt binde service-leverandør og -aftager.
d. 1. juni havde jeg møde med Kåre Kjelstrøm fra
Silverbullet som har være involveret i mange offentlige projekter men var især interessant for sit inblik i sikkerhedsmodellen for Sundhed.dk og sit ellers pragmatiske syn på SOA.
- Kåre har en teknisk baggrund, men har også arbejdet som arkitekt på ovennævnte projekter og var således ideel for at give et teknisk indblik i hvordan man overholder de strenge krav der er til behandling af personfølsomme oplysninger.
Samtidig snakkede vi meget om brugerstyring indenfor sundhed.dk. Det er vist alment kendt at den digitale signatur har en svaghed når en person har flere roller. F.eks. når en læge arbejder på to forskellige sygehuse. Hos sundhed.dk validerer man den digitale signatur og derefter bruger man cpr-# på lægen til at bestemme autorisationen - ie. hvad den pågældende læge har ret til i systemet.
I alt snakkede vi 1½ time og det gav 8 siders summary.
Over den næste uges tid skal jeg ud og snakke med Niels Dalhoff Andersen som sidder ude på sundhed.dk og dagen efter har jeg været så heldig at få et møde med Henrik Pedersen & Steen Deth fra Gentofte Kommune som kan give mig noget indblik i kommunalreformen fra et it-arkitektonisk synspunkt.
Derefter er jeg nødt til at gå over i eksamens-mode da jeg jo tog T8 som et ekstra fag (det fortryder man nemt nu :-? )
Anyway - jeg har selv haft travlt med diverse ting.
d. 31.12 var jeg til OIOXML Forum i Bredgade hos IT & Telestyrelsen. Forummet er lidt et nørdforum hvor der bliver heppet hver gang der bliver vist en XML streng.. men det er nu heller ikke at foragte da det giver et bedre indblik i XML standarderne. Denne gang var det mest interessante oplæg omkring
OIO Standardaftale for WebServices. Standardaftalen er en slags udvidet service level agreement (SLA) til offentlige myndighed, som meget nøjagtigt udpeger hvilke kontraktsmæssige områder det er vigtigt, at have på plads INDEN man kaster sig ud i ekstraorganisatorisk Webservices.
Aftalen er udarbejdet ud fra holdningen, at uden en kontraktslig aftale vil SOA aldrig komme op på benene fordi der skal være noget, som kan kontraktsligt binde service-leverandør og -aftager.
d. 1. juni havde jeg møde med Kåre Kjelstrøm fra
Silverbullet som har være involveret i mange offentlige projekter men var især interessant for sit inblik i sikkerhedsmodellen for Sundhed.dk og sit ellers pragmatiske syn på SOA.
- Kåre har en teknisk baggrund, men har også arbejdet som arkitekt på ovennævnte projekter og var således ideel for at give et teknisk indblik i hvordan man overholder de strenge krav der er til behandling af personfølsomme oplysninger.
Samtidig snakkede vi meget om brugerstyring indenfor sundhed.dk. Det er vist alment kendt at den digitale signatur har en svaghed når en person har flere roller. F.eks. når en læge arbejder på to forskellige sygehuse. Hos sundhed.dk validerer man den digitale signatur og derefter bruger man cpr-# på lægen til at bestemme autorisationen - ie. hvad den pågældende læge har ret til i systemet.
I alt snakkede vi 1½ time og det gav 8 siders summary.
Over den næste uges tid skal jeg ud og snakke med Niels Dalhoff Andersen som sidder ude på sundhed.dk og dagen efter har jeg været så heldig at få et møde med Henrik Pedersen & Steen Deth fra Gentofte Kommune som kan give mig noget indblik i kommunalreformen fra et it-arkitektonisk synspunkt.
Derefter er jeg nødt til at gå over i eksamens-mode da jeg jo tog T8 som et ekstra fag (det fortryder man nemt nu :-? )
I dag brugte jeg et par timer på at lege med webservices i PHP... and boy is that easy!
Et kort besøg hos google; installering ad PEARs SOAP bibliotek; copy/paste 5 linier af kode og tadaaa:
Direkte adgang til google
... og så er adgangen med RPC ikke meget mere kompliceret...
Et kort besøg hos google; installering ad PEARs SOAP bibliotek; copy/paste 5 linier af kode og tadaaa:
Direkte adgang til google
... og så er adgangen med RPC ikke meget mere kompliceret...
