July 2005 Archives
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.
Da åbne standarder er et emne jeg behandler i forhold til sikkerhedsproblematikken, har jeg skrevet et lille kapitel omkring åbne standarder som jeg gerne vil dele. Kommentarer modtages gerne.
Åbne standarder
Jensens (2004) principper for SOA, stemmer meget godt overens med Rosen & Lublinsky (2005), men som en interessant distinktion trækker Jensen åbne standarder (open-standards) frem som en af de mest fundamentale drivkræfter for SOA.
I denne gennemgang vil åbne standarder kort blive beskrevet hvorefter deres anvendelighed i forhold til SOA og sikkerhed diskuteres.
Standard definition
En teknisk standard kan betegnes som en kodifikation beskrivende en implementation eller procedure som anvendes med øje for sammenligning. (Krechmer, 2002)
_QUOTEC
Åbne standarder
Jensens (2004) principper for SOA, stemmer meget godt overens med Rosen & Lublinsky (2005), men som en interessant distinktion trækker Jensen åbne standarder (open-standards) frem som en af de mest fundamentale drivkræfter for SOA.
I denne gennemgang vil åbne standarder kort blive beskrevet hvorefter deres anvendelighed i forhold til SOA og sikkerhed diskuteres.
Standard definition
En teknisk standard kan betegnes som en kodifikation beskrivende en implementation eller procedure som anvendes med øje for sammenligning. (Krechmer, 2002)
_QUOTEC
En nærmere bestemmelse af standarder bygger dog på en opdeling som anvist i figur 5.
Vertikalt kan standarder plottes afhængig af standardens kodifikation som anfører i hvor høj grad den pågældende standard er udarbejdet igennem en standardiseringsorganisation (SDO ) som tilfældet er for de-jure standarder, eller gradvist er blevet en standard igennem brug, uden decideret indblanding fra en standardiseringsorganisation, som tilfældet er for de-facto standarder.
For både de-facto og de-jure standarder gælder det at de starter ud som specifikation, men i kraft af bred anvendelse bliver specifikationen til en standard.
På den horisontale akse er distinktionsparameteren tilgængelighed, og der skelnes imellem åbne og patenterede standarder. Modellens værdi som en grafisk repræsentation for standarders status vil blive diskuteret senere.
Patenterede standarder er i sig selv en antitese (Krechmer, 2005). Et patent er en metode til at værdisætte det unikke, men standarder er det tekniske samfunds middel til at definere det ensartede. Således er der en basal modsætning imellem det ensartede og det unikke, hvilket skaber grundlag for et politisk spørgsmål om hvorledes der prioriteres imellem de ene af de to.
Åbne standarder er sværere at definere. Perens' (2005) seks principper for åbne standarder er nok de mest anvendte: Availability, Maximize End-User Choice, No Royalty, No Discrimination, Extension or Subset, Predatory Practices. Disse principper udgør et godt fundament for at fastlægge åbne standarder, men de håndterer ikke distinktionen imellem forskellige grader af åbenhed.
Åben definition
Den generelle konsensus er, at "åben" skal ses som offentligt tilgængelige specifikationer, der kan adopteres uden restriktioner. ITST (2004) fortolker "åben" til at standarden skal være, og forblive, gratis og tilgængelig i sin helhed således, at andre kan anvende den samme standard for deres egne produkter.
Derved skelner ITST ikke imellem standarder, som er frembragt på baggrund af en offentlig proces og de som er fremkommet fra en lukket proces og derefter frigivet.
_QUOTEC
Grundlæggende kan man argumentere at åben er en tilstand - enten er noget åben eller lukket. Men denne opstilling vil være for rigid og kan hindre standarders udvikling i sidste ende. Er Microsofts nye "Åben Format" (Open Format) f.eks. lige så åbent som Oasis' Open Document?
Begge filformater er i dag gratis og tilgængelige, men de er ikke begge opstået på baggrund af en offentlig proces. Dette betyder bl.a., at specifikationerne ikke har været bearbejdet således, at en bred konsensus er opnået på tværs af standardens interessenter.
Ifølge et interview med IBM (IBM, 2005, 0:33:00) er åbne standarder et salgsargument i kraft af den handlingskraft det giver kunden overfor leverandørerne. Derfor kan det forventes, at flere organisationer forsøger at deklarere deres formater som åbne standarder, på trods af forskellige specifikationstilgange. I takt med at åbne standarder bliver et mere betydningsfuldt salgsargument, er der også risiko for at der sker en udvanding af begrebet.
_QUOTEC
Der findes dog måder at måle openhed på. Krechmer (2005b) har opstillet ten rights that enables open standards, som opstillet i tabel 1. Disse er rettigheder der spænder fra delagtigørelse i specifikationsfasen til løbende support af standardens anvendelse. Opsætningen af principper giver mulighed for at rangdele eller klassificere standarder i forhold til deres åbenhed, ved at vægte hvert princip med en faktor kan der opstilles en resultattabel som gør det muligt at benchmarke standarder.
Igennem en overordnet certificerings-instans, vil resultatet kunne danne grundlag for, at en bedømmelse af standarders åbenheden. Samtidig vil standarderne kunne mappes ind i modellen (figur 6) for at give et grafisk overblik.
En relateret metode til evaluering af standarder er, at adoptere licens-strukturen for open-source. Open-source har også været nødt til at gradbøje begrebet "åben", men gør det igennem forskellige typer licenser. For hver licens eksisterer der forskellige former for kontrol og frihed og således kan ophaver af en open-source applikation, selv bestemme i hvor høj grad, hun ønsker at give applikationen fri. For standarder vil en lign. model f.eks. indikere hvor åben specifikationsfasen for standarden har været og i hvor høj grad standarden kan anvendes som model for andre standarder.
Åbne fordele
Åbne standarder besidder en række fordele i forhold til proprietære standarder. Mest oplagt, er åbne standarder en katalysator for interoperabilitet. Dette sker i kraft af offentlige tilgængelige specifikationer, som giver alle systemleverandører mulighed for at basere deres produkter på disse tilgængelige specifikationer.
Værdien af interoperabilitet ligger i den netværkseffekt, som der dannes i kraft af at flere anvender en standard. På kort sigt er der dog ikke noget krav om åbne standarder for at opnå interoperabilitet (hvilket mange af Microsofts produkter er eksempler på), men på længere sigt kan en standards åbenhed have stor betydning for dens udbredelse og accept.
Interoperabilitet opnås igennem en række forskellige måder: Igennem lovmæssig tvang kan der skabes interoperabilitet, hvilket dog derved sætter markedskræfterne ud af spil og den valgte løsning er måske ikke den mest ideelle. Monopol kan fordre interoperabilitet.
Monopoler og lovmæssig tvang er meget lig hinanden, men har dog den væsentlige forskel, at love formodes fremsat for at fordre samfundets bedste tarv hvorimod monopoler mest gavner organisationen der besidder monopolet. Patenter anses i denne forstand som et forsøg på at monopolisere den teknik man besidder.
Åbne standarder kan være med til at fjerne det lock-in som leverandører har haft i kraft af deres proprietære protokoller. Den medfølgende leverandøruafhængighed påvirker fleksibiliteten af systemet, idet der nu vil være større valgfrihed til at vælge netop den leverandør der kan levere det produkt som bedst passer til organisations krav.
Åbne standarder medfører også en række sikkerhedsmæssige fordele som opstår i kraft af at sprede risikoen for at en leverandør går konkurs imellem flere leverandører. Dog er der ikke noget som tyder på at forskellige systemer er mere sikre overfor angreb. Tværtimod vil flere systemer kræve en større serviceindsats at holde opdateret.
