IT-ARKITEKTUR Overordnet it-arkitekturdokument Dato: 04.05.2011 Dette dokumentet gir en overordnet arkitekturbeskrivelse av infrastrukturen til DGI. Alle som er direkte involvert i vurderinger av IKT-løsninger og tilbydere av IKT-tjenester, samt driftsleverandører og systemintegratorer må rette seg etter dette dokumentet. Postadresse: Postboks 45 2065 Gardermoen Besøksadres se: Gardermoen Business Centre Balder Allé 2 2065 Gardermoen Telefon: 64 00 90 01 Telefaks: 64 00 90 02 E-post: firmapost@dgi.no Internett: http://www.d gi.no Bankgiro: 6201.05.4108 0 Org.nr.: 987 059 389
DOKUMENTHISTORIKK VERSJON DATO UTFØRT AV ENDRINGSBESKRIVELSE 2.0 10.12.2008 BJØRN AUNE FULL REVISJON 3.0 04.05.2011 ERIK TOTLUND SYSTEMREVISJON KONTAKTPERSON VEDRØRENDE DETTE DOKUMENTET Jan Sverre Larsen Leder - Tjenesteleveranse/Leder - Sikkerhet Digitale Gardermoen IKS Side 2
INNHOLDSFORTEGNELSE 1 Innledning... 5 2 Arkitektur prinsipper... 5 2.1 Tjenesteorientering... 6 2.2 Interoperabilitet... 6 2.3 Tilgjengelighet... 6 2.4 Sikkerhet... 6 2.5 Åpenhet... 7 2.6 Fleksibilitet... 7 2.7 Skalerbarhet... 7 2.8 Enhetlig brukergrensesnitt... 7 3 Retningslinjer for IT-arkitektur... 8 3.1 Forretningsarkitektur... 8 3.2 Informasjonsarkitekturen... 8 3.3 Overordnet beskrivelse av løsning... 8 3.4 Planlegging av IT-infrastrukturen... 8 4 Fellestjenester... 8 4.1 Innledning... 8 4.2 Definisjon av felles tjenester... 9 5 IT Arkitektur - Generelt... 9 5.1 Bakgrunn... 9 5.2 Målgruppe... 10 5.3 Suksessfaktorer... 10 5.3.1 Forankring... 10 5.3.2 Iterativ prosess... 10 5.4 Målsetting... 10 6 Retningslinjer for IT-arkitektur... 12 6.1.1 Innledning... 12 6.2 Applikasjonsarkitektur... 13 6.2.1 Innledning... 13 6.2.2 Strategier... 14 6.3 Integrasjonsarkitektur... 14 6.4 Dataarkitekturen... 17 6.4.1 Innledning... 17 Side 3
6.5 Driftsarkitektur... 18 6.5.1 Beskrivelse av driftsarkitektur... 19 6.6 Teknologiarkitektur... 23 6.7 Sikkerhetsarkitektur... 23 6.7.1 Innledning... 23 6.7.2 Autentisering (Authentication)... 24 6.7.3 Sikkerhetsbarrierer... 24 6.7.4 Autorisering (Authorization)... 24 6.7.5 Logging (Accouting)... 25 6.7.6 SSO (Single Sign On)... 25 6.7.7 Kryptering og bruk av PKI... 25 Side 4
1 Innledning I dette dokumentet er den totale IT arkitektur til Digitale Gardermoen IKS, heretter kalt selskapet, beskrevet. Dokumentet beskriver føringer som leverandør av IT systemer til selskapet må ta hensyn til. Dette dokumentet er rettet mot alle som er involvert i vurderinger av IKTløsninger for selskapet, tilbydere av IKT-tjenester til selskapet, samt Driftsleverandører og Systemintegratorer. Dokumentet har følgende funksjoner: Være rettledende for selskapet i forhold til veivalg knyttet til IT arkitektur fremover. Gi leverandør en informasjon om hvordan selskapet ønsker å bygge og videreutvikle sin IT arkitektur. Danne grunnlag for videre utvikling av IT arkitektur gjennom kontraktens utløp. Være en del av kravspesifikasjonen ved kjøp av IT tjenester. Danne grunnlag for utvelgelse av leverandør i anbudsfasen. Dokumentet skal kunne bli brukt som vedlegg til senere anskaffelser som selskapet skal gjøre. 2 Arkitektur prinsipper Viktige grunnprinsipp for arkitektur finnes nedfelt i St. meld. nr. 17 (2006-2007) avsnitt 7.3.2. Her står, blant annet: Den overordna IKT-arkitekturen i det offentlege skal vere fleksibel og tilpasningsdyktig, slik at den i størst mogeleg grad samspeler med dei IKTarkitekturar som eksisterer innan einskildsektorar og den einskilde verksemda. Dei noverande systema er ofte verksamhetskritiske. Omstillingsarbeide må kunne skje under føresetnad av at løpande forvaltning og produksjon kan gå normalt. Føringane frå overordna IKT-arkitektur skal i minst mogeleg grad vere til hinder for endringar i verksemdenes oppgåveløysing og organisering I tiltak 7.4 står det mer konkret at: Arkitekturen skal vere lagdelt og vil minimum bestå av eit presentasjonslag, ein felleskomponentlag og eit verksomhetslag. Arkitekturen skal i størst mogeleg grad baserast på opne standardar og eit regime for informasjonstryggleik [..] Sektoranes og verksemdenes IKT-strategiar og store offentlege IKT-prosjekt, skal byggje på og understøtte desse. Side 5
2.1 Tjenesteorientering Tjenesteorientert arkitektur er et konsept der applikasjoner og prosesser har tilgang til standard tjenestegrensesnitt uten at det krever programmering eller kunnskap om programmene på detaljert nivå. Tjenesteorientert utvikling skal være grunnprinsippet for alle nye IT-systemer innenfor de problemstillinger som egner seg for denne tilnærmingen der resultatet skal være gjenbruk og deling. Tjenesteorientert arkitektur forutsetter en systematisk trelagsarkitektur. Presentasjonslaget er ofte representert i html basert portalapplikasjon. Mellomlaget ligger tjenestene og integrasjonsteknologien. Det nederste laget er informasjonssystemene og registreringssystemene. Løsninger som utvikles for å være felles må utvikles med prinsipper i tjenesteorientert arkitektur. 2.2 Interoperabilitet I arkitektursammenheng handler Interoperabilitet mest om at det er helt nødvendig med felles integrasjonsprinsipper og standarder for utveksling av informasjon og data mellom systemene. Interoperabilitet kan deles i 3 deler: teknisk, organisatorisk og felles begrepsmodeller. Teknisk oppnås dette ved felles standarder Organisatorisk oppnås dette ved felles arbeidsprosesser. Begrepsmodeller oppnås ved å opprette en felles grunndata modeller. Alle tjenester som etableres skal designes for interoperabilitet. 2.3 Tilgjengelighet Alle tjenester som realiseres skal være mulig å bruke vha. IKT av kommunens innbyggere og næringsliv når behovet finnes uten å være begrenset av tidspunkt, bruksmåte og plassering. IKT-tjenester skal være forutsigbar og ikke være begrenset av en bestemt teknologi. 2.4 Sikkerhet Sikkerhetsarkitekturen skal ta utgangspunkt i de forretningsmessige krav til arbeidsflyt, informasjonens følsomhet, krav til konfidensialitet, integritet og tilgjengelighet samt analyse av det aktuelle risikobildet. Sikkerhetsarkitekturen skal oppfylle de lovmessige krav, borgernes rimelige forventning om en sikker informasjonsbehandling og kommunens behov for å yte effektiv saksbehandling og god service. Side 6
Sikkerhetsarkitekturen skal ivareta elementer igjennom hele verdikjeden ved innføring av ny tjeneste, fra strategi og komponenter, til operative kontroller for å ivareta samsvar med lovkrav. Sikkerhetsarkitekturen skal være fleksibel, dynamisk og åpen nok til og støtte ulike sikkerhetsnivåer, avhengig av beskyttelsesbehov. Sikkerhetsarkitekturen skal understøtte konseptet sikkerhet i dybden, igjennom løsningsdesign som reduserer sårbarheter og konsekvensene ved å dekke - Forebygging - Detektering - Begrensning - Gjenoppretting Sikkerhetsarkitekturen skal understøtte tjenesteleverandørens sikkerhetsstrategi: Sikkerhet, alltid tilstede aldri til hinder. 2.5 Åpenhet Tjenestene kan tas i bruk uten spesielle krav til teknologi og at tjenestens innhold og virkemåte er tilgjengelig. Det er avgjørende at det anvendes åpne standarder for datagrensesnittet slik at det er mulig å overføre data mellom ulike systemer uten tap av data. 2.6 Fleksibilitet Arkitekturen bør tenke i et modulært design slik at all funksjonalitet utvikles i separate moduler. De enkelte moduler kan løpende tilpasses til nye krav. De enkelte moduler kan ofte benyttes i flere sammenhenger, også i eksterne tjenester og på den måten implementeres i nye systemer. 2.7 Skalerbarhet Skalerbarhet er ikke et krav om en bestemt kapasitet, men et prinsipp om at systemet skal kunne bygges ut (eller nedskaleres) slik at det dekker det aktuelle behovet på en optimal måte. Eksempler: Datalagring skal skje i et SAN og ikke på lokale harddisker som ikke kan bygges ut. Servere skal organiseres i klynger som kan utvides ved behov 2.8 Enhetlig brukergrensesnitt Tjenester som settes i drift skal være forutsigbart og gjenkjennelse mhp utforming og bruk. Det betyr ikke nødvendigvis at skjermbilder skal være like i form og farge, men den funksjonelle bruken skal brukeren kjenne seg igjen. Side 7
3 Retningslinjer for IT-arkitektur IT-arkitekturarbeidet skal følge felles retningslinjer som beskriver hvordan de strategiske arkitekturvalg bør gjøres og definere de felles valg av grensesnitt og andre arkitekturkomponenter. 3.1 Forretningsarkitektur Hver enkelt løsning bør ta utgangspunkt i dagens arbeidsflyt som skal støttes av IT-løsningen. Før man setter i gang med design av IT-løsningen bør man undersøke om arbeidsflyten kan forenkles eller effektiviseres. Konsekvensene av de anbefalende endringene bør beskrives. Når valgene er tatt beskrives arbeidsflyten og den IT-støtte som det vil være behov for. Retningslinjene skal angi generelle metoder til analyse og beskrivelse. 3.2 Informasjonsarkitekturen Det skal utarbeides en overordnet beskrivelse av informasjonsarkitekturen. Dette valget skal begrunnes. For alle datastrukturer som skal utveksle informasjon med andre systemer skal det undersøkes om det eksisterer en standard som kan brukes. Er det behov for å lage en egen datastruktur for utveksling av data mellom systemer skal denne beskrives og dokumenteres. 3.3 Overordnet beskrivelse av løsning Det skal utarbeides en overordnet beskrivelse av løsningen, dvs. de funksjonelle komponenter med begrunnelse for disse valgene som er gjort. Et enkelt prinsipp gjelder gjenbruk før kjøp, kjøp før utvikling. Er det behov for å lage en ny komponent skal denne beskrives og dokumenteres. 3.4 Planlegging av IT-infrastrukturen Planlegging av infrastrukturen skal baseres på valg av løsninger som er spesielt for det enkelte system og tjeneste som kan brukes av ulike applikasjoner. Felles valg på IT-infrastrukturen kan enten implementeres på en enhetlig måte i de enkelte systemer eller de kan implementeres som en felles tjeneste i infrastrukturen til bruk for flere IT-systemer. Formålet er å skape større sammenheng mellom IT-systemene samtidig med at utgiftene til utvikling av komplementære tjenester minker. IT-infrastrukturens tjenester som stilles til rådighet for IT-systemer på ulike områder skal tilby standardiserte åpne grensesnitt. 4 Fellestjenester 4.1 Innledning I en arkitekturmodell der forskjellige systemer tilbyr et sett av tjenester er det også naturlig at en del tjenester er felles og tilbys alle systemer. Eksempler: Organisasjonsinformasjon Infrastrukturtjenester Side 8
Sikkerhetsfunksjoner slik som autorisasjon og autentisering. Aktivitetslogging i form av tjenester som kan spore hva som er gjort, av hvem og når. Tracing. Dvs. tjenester som kan kalles opp for å utføre feilsøking på flere valgfrie nivå. Denne tjenesten må være slik at den kan nåes mens systemet er i full drift. Kommunikasjon. Tjenestene skal ikke bry seg med hvordan kommunikasjonen foregår mellom de forskjellige lagene. Dette skal ligge som et grunnlag som tjenestene skal benytte seg av. Tjenestene ligger som en basis i arkitekturmodellen, og de skal kunne benyttes av alle systemer. 4.2 Definisjon av felles tjenester All IKT-infrastruktur i form av kabling, nettverkselektronikk, svitsjer, leide linjer, loggefunksjoner er å anse som felles IKT-teknologi. Alle deler av sikkerhetsløsningen er å anse som en del av fellessystemene, f. eks, brannmur, IDS system, sentral logging, brukerkatalog med autentisering/autorisasjon, SPAM og virusfiltere. Alle datasystemer som støtter forretningsprosesser som er gjennomgående i selskapet gruppen er å anse som et fellessystem. Dette gjelder f eks elektronisk post, internett aksess, intranett, fillager, søketjenester, økonomisystem, prosjekthotell. 5 IT Arkitektur - Generelt Alle løsninger som anskaffes og implementeres skal tilfredsstille krav til nåværende og framtidige interoperabilitet basert på en systemorientert arkitektur, internasjonale og åpne standarder og de standarder og kravspesifikasjoner som løpende etableres av norske myndigheter. IT-arkitektur består av IT-infrastrukturlag (nettverk, servere, pc er, styresystemer, sikkerhetsstyring) Applikasjoner (IT-tjenester, der understøtter forretningsprosessene) 5.1 Bakgrunn Selskapet har i sin IT-strategi sentrale virksomhetsmål og IT suksessfaktorer. I den forbindelse med spesifikasjon av utstyr og systemanskaffelser, samt etablering av et driftssenter som skal levere IKT-tjenester til kommunale kunder, er det definert et behov for å utvikle en hovedarkitektur for all IT forvaltning. En fornuftig arkitektur er en forutsetning for en vellykket implementering av en helhetlig IT-strategi. Mange private og offentlige virksomheter etablerer arkitektur på virksomhetsnivå, dvs. at arkitektur etableres mer helhetlig i virksomheten og innenfor de enkelte applikasjoner som tidligere(monolittisk arkitektur). De viktigste fordelene med dette er flere synergier mellom ulike Side 9
applikasjoner, mindre avhengigheter mellom kunde og leverandør og mer kostnadseffektiv integrasjon mellom fagapplikasjoner. IT arkitekturen inneholder retningslinjer for hvordan nye systemer skal etableres, hvordan se skal benytte standard fellestjenester, hvordan systemer, tjenester og arbeidsprosesser skal dokumenteres og hvordan en felles driftsarkitektur skal se ut. 5.2 Målgruppe Det er identifisert ulike interessenter som kan ha en eller annen interesse av IT arkitekturen: Eierne Ledelse Medarbeidere Utviklere Driftspersonell Sikkerhetsansvarlig Eksterne leverandører Eksterne samarbeidsparter Myndigheter 5.3 Suksessfaktorer 5.3.1 Forankring Det er avgjørende at IT arkitekturen er forankret i ledelsen hos eierne, samt ledelse i selskapet. Alle involverte må føle eierskap til denne og en forståelse av arkitekturen. Dette innebærer at dokumentet ved revisjon skal godkjennes av ledelsen. 5.3.2 Iterativ prosess Utarbeidelse av en arkitektur er en iterativ prosess. Etter hvert som man anvender arkitekturen vil man gjøre seg erfaringer og man vil erfare at teknologien endrer seg og nye muligheter dukker opp. 5.4 Målsetting Selskapet søker fokus på IT-tjenester ved etablering av tjenestebasert arkitektur. Den tjenestebaserte arkitekturmodellen menes at alle systemer tilbyr sin funksjonalitet via standard tjenestegrensesnitt. Denne tjenesten kan konsumeres av andre tjenester eller systemer uten at man trenger programmering eller kunnskap på lavere nivå. Selskapet skal ha en kostnadseffektiv og fleksibel infrastruktur tilpasset virksomhetens behov. Standard systemer og komponenter skal velges. Systemer og komponenter skal være skalerbare og robuste. Side 10
Krav til informasjonssikkerhet dokumentert gjennom sikkerhetsreglement og policydokumenter skal ligge som krav ved alle anskaffelser og endringsprosjekter innenfor IKT. Side 11
6 Retningslinjer for IT-arkitektur Forretningsarkitektur Informasjonsarkitektur Figur 1 Forretningsarkitektur 6.1.1 Innledning Representerer de reelle forretningsprosessene som virksomheten gjennomfører, uavhengig av system- eller implementasjonshensyn. Denne arkitekturen kan f.eks. inneholde forretningsentiteter, -prosesser, -ressurser, o.l. Det vi ser er at systemer levert til nå ikke er designet for samhandling. Det igjen betyr at det er svært kostnadskrevende å skape den nødvendige samhandlingen. Behovene som melder seg ute i kommunene er at antall elektroniske tjenester og systemer vokser raskt. Av den grunn er behovet om samhandling meget viktig for å gevinstrealisere investeringer. Samtidig med at samhandling av systemer og tjenester melder seg øker kompleksiteten. Samt raskere utrulling av nye tjenester. For å kunne gi en bedre tilpasning til virksomhetens mål fokuserer forretningsarkitekturen ovenfra og ned på de viktige IKT investeringene. Forretningsarkitekturen gir en hurtigere reaksjon på endringer og utrulling av nye tjenester. Side 12
6.2 Applikasjonsarkitektur Figur 2 Felles applikasjonsarkitektur 6.2.1 Innledning Representerer en logisk (teknologi- og implementasjonsnøytral) modell av systemer/tjenester som støtter opp under forretningsarkitekturen. Dette kan være modeller av automatiserte tjenester som støtter opp under forretningsprosessene, avhengigheter mellom de ulike applikasjonene i virksomheten, planer for nye applikasjoner som vil støtte fremtidige behov, o.l. Side 13
6.2.2 Strategier Alle applikasjoner som skal driftsettes i selskapet sitt driftsmiljø skal kjøres på virtuelle servere, pakkes i Softgrid og eksponeres ut via Web grensesnitt i en Citrix Ica klient. Løsningen skal kunne kjøres som tynnklient. Vi bruker i tillegg Powerfuse for administrasjon av tilganger og tilpasninger av brukermiljøet. 6.3 Integrasjonsarkitektur Selskapet har valgt å nyte Microsoft BizTalk som integrasjonsnav. DGI Integrasjon Sone (NY) Biztalk Farm Integration Platform Monitor Norsk Helsenett ebxml\pki Biztalk 2009 Enterprise Server 1 Biztalk 2009 Enterprise Server 2 Message Tracking Monitor Microsoft SQL 2008 Enterprise Server Node A Aktiv (Biztalk) Node B Passiv (Biztalk) Message Tracking Monitor DGI DMZ Sone DGI Ekstern Sone DGI Intern Sone DGI Sikker Sone Figur 3 Integrasjonsarkitektur Det er opprettet en egen integrasjon sone hvor hele det miljøet er installert. Løsningen kan forsvares sikkerhetsmessig ved at all kommunikasjon bli initiert av BizTalk i den sikre integrasjonssonen. Det er hele tiden BizTalk som vil spørre i de andre sonene om det finnes tilgjengelig informasjon som skal behandles og som også sender en forespørsel om å sende informasjon når dette er aktuelt. All kommunikasjon med andre helse aktører f. eks epikriser fra ett sykehus vil skje via Norsk Helsenett som er ett eget lukket nettverk opprettet for bruk av aktører innen norsk helsevesen Side 14
Økt sikkerhet: Ved å installere det nye integrasjonsmiljøet i en ett eget nettverk er det lettere og begrense tilgangen til innsyn av data enn det er i dagens løsninger Løsningen består av følgende:*- 2 stk. Biztalk Server 2010 Enterprise Edition (lastbalansert) 2 stk. SQL server 2008 Enterprise Edition som kjører på ett Windows server 2008 cluster hvor en lisens aktiv mens den andre er passiv. 1 Message Tracking Monitor(MTM) fra Communicate Norge for meldingsovervåking 1 ebxml\pki modul fra Communicate Norge for å kunne kommunisere i henhold til de krav som Norsk Helsenett har satt for meldingssikkerhet. Modulen er godkjent av KITH. 1 Integration Platform Monitor (IPM) fra Communicate Norge for enkel og oversiktig overvåking av Biztalk sine porter, orkestreringer, applikasjoner og hoster. Selskapets driftssenter er meget omfattende sammenlignet med andre kommuner rundt omkring i Norge og vil forventes å øke både i omfang og tjenester i årene som kommer. Mye av utfordringen framover vil ligge i integrasjon på ulike plan: skape en integrert brukeropplevelse basert på en felles informasjonsarkitektur, gode navigasjons- og søkemuligheter og et moderne og tiltalende utseende integrasjon av gammelt og nytt innhold teknisk integrasjon av web-tjenester Side 15
Figur 3 Konseptuelt eksempel av "Enterprise Servise Bus" arkitekturen. Selskapet har valgt BizTalk Server som plattform for integrasjon og realisering av forretningsprosesser. Ved bruk av BizTalk Server gir det mulighet for å eksponere gamle systemer som web services, samt integrasjon mot eksterne systemer. I hovedsak vil det være system-til-system integrasjon og automatiserte forretningsprosesser. Den grafiske modelleringen av forretningsprosessene er med på lukke gapet mellom systemutviklere og forretningsutviklere. Dette gir samtidig forretningsreglene synlige og tydelige. Integrasjonsarkitektur beskriver hvordan systemer kobles sammen for å kunne dele informasjon og støtte forretningsprosesser som dekker flere systemer og del-systemer. Integrasjonsarkitekturen skal sørge for at systemer kan integreres på en optimal måte i forhold til virksomhetens prosesser og behov for samhandling internt i virksomheten og med eksterne aktører. Side 16
6.4 Dataarkitekturen DATABASE Tjeneste Sikker Sone Ms-SQL baserte tjenester SSI-082 10.8.32.13 Ms SQL2005 Link 1 AD Tjenester Lagringstjeneste SAN Figur 4 Dataarkitekturen 6.4.1 Innledning Hensikten med dataarkitekturen er å etablere en tilpasset infrastruktur som gjør det enklere å gi tilgang, definere, styre, sikre data integriteten i kommunene. Informasjon og data er en viktig ressurs for kommunene. Dataarkitekturen etablerer en infrastruktur som gir høy kvalitet og konsistente data uansett behov. Det er en forutsetting at infrastrukturen oppfyller kravene for enkel tilgang og at den er forstått av brukere og applikasjoner i kommunene. Det eksisterer redundante databasehoteller på to plattformer i selskapets infrastruktur. Microsoft SQL 2005 Oracle 10.G2 Begge databaseløsningene har lagringslokasjon på et sentralt SAN. Selskapet er ansvarlig for installasjon av databaser, instanser og tilhørende databaseservicer. Dette i samråd med leverandør for å sikre rett patch-nivå. Side 17
6.5 Driftsarkitektur Med driftsarkitektur mener vi det fysiske driftsmiljøet som IT løsninger skal kjøre i hos selskapet. Dette er en fysisk lagdelt arkitektur fordelt over 3 lag; web-, app- og datalag, hver med klart definerte tilgangsoner. INTERNETT Databaser SQL Perimeter.dgi.no FTP PROXYTJENESTER WWW.KOMMUNE.NO DMZ SMTP Relay Applikasjonsserver Ytre Barriere KLIENTNETT MPLS Sikre Interne Elev Public KLIENTNETT WIFI Elev nett APPLIKASJONS servere ad.dgi.no FTP Utskriftsservere APPLIKASJONS servere ad.dgi.no BizTalk INTRANETT.KOMMUNE.NO Intern sone Sikker sone EXCHANGE Veritas Cluster FILSERVERE Veritas Cluster CITRIX Farm BizTalk FILSERVERE Veritas Cluster CITRIX Farm Utskriftsservere DATABASE Sone Intern DATABASE Sone Sikker MS SQL 2005r ORACLE 10g R2 ORACLE RAC Indre Barriere MS SQL 2005 Management DHCP / Altiris Trend Lisenssrv OfficeScan Citrix Management Servere div tjenester APPLIKASJONS servere Elev.dgi.no Management Servere div tjenester ELEV / LÆRER Sone FILSERVERE Veritas Cluster Utskriftsservere Figur 5 Driftsarkitekturen Side 18
6.5.1 Beskrivelse av driftsarkitektur Selskapet har valgt å virtualisere med Vmware og Citrix XenServer på de fleste servere i vårt driftsmiljø. De eneste servere som kan installeres på fysiske servere vil være veldig I/O intensive som for eksempel databaser og andre servere som basert på ytelse ikke egner seg i det virutaliserte miljøet. Dette er en vurdering som tas i det i det enkelte tilfellet. Selskapet har som krav til alle leverandører om at alle IT løsninger (menes også leveranse av applikasjoner internt i sikkersone) skal leveres via Citrix Online Plugin. Selskapet har som mål å viritualisere servere og applikasjoner for å kostnadseffektivisere drift basert på best mulig utnyttelse av HW og enklere administrasjon. All internett tilgang skal skje via proxy med innholdsfiltrering. All lagring av applikasjonsdata skal lagres på SAN. Dette for å lette administrasjon og sikkerhetskopiering. Selskapet har valgt Microsoft Windows 2008 som standarden operativsystem. Dette er ikke et absolutt krav dersom ikke en tjeneste lar seg installere på Microsoft Windows 2008 eller tjenesten fungerer bedre på et annet operativsystem. Selskapet har valgt å styre tjenester og applikasjoner med Microsoft Application Center Server. Med dette verktøyet skal de håndtere livssyklus, utrulling og skalering av komponenter. Dette betyr at alle komponenter og tjenester som utvikles og eventuelt anskaffes av selskapet skal kunne håndteres gjennom applikasjonssenteret. De må likeledes være av en art som gjør det mulig å skalere etter behov ved hjelp av cluster og lastbalanseringsteknologi. Tjenester som opprettes på integrasjonsverktøyet, BizTalk Server, skal også kunne håndteres gjennom Microsoft Application Center. Selskapet har valgt å dele inn nettverket i flere soner. 6.5.1.1 DMZ sone Her finnes alle servere og tjenester som kan nåes eksternt. Det innbefatter webservere, SQL server, epost, DNS, proxy server. I tillegg finnes det en Active Directory, heretter kalt AD, kontroller dedikert for denne sonen. Data som lagres i denne sonen: Data som er publisert på kommunenes hjemmesider, ikke sensitivt Data relatert til prosjekter som skal nåes utenfra. 6.5.1.2 Intern sone Her finnes alle server og tjenester for leveranse av intern applikasjoner: terminal-, applikasjon-, fil-, print-, AD-, epost-, DNS- og webservere. Side 19
All tilgang skjer via ICA-protokoll og alle applikasjoner tilgjengeliggjøres via Citrix Online Plugin. Brukere autentifiseres i AD. Brukere i intern sone har ikke tilgang til sikker sone. 6.5.1.2.1 Terminalservermiljøet i intern sone Selskapet leverer applikasjoner via terminalserver, applikasjonene streames via Microsoft AppV 4.5 eller nyere. Powerfuse benyttes til administrasjon av tilganger og tilpasninger av brukermiljøet. Terminalmiljøet er basert på Win2008, Powerfuse, AppV, Citrix XenServer, Provisioning og XenApp. Terminalserverne er virtualisert. Selskapet skal levere alle applikasjoner via terminalserver til tynnklient der hvor dette er mulig. Enkelte applikasjoner blir levert via Citrix XenDesktop eller som lokalt installert på PC men via Selskapets distribusjonsmekanisme (SCCM). Data som lagres i denne sonen regnes ikke som fortrolig. Dog finnes det data som er sensitive og unntatt offentligheten, men ikke av en art som gjør at de må lagres i sikker sone. E-post er basert på MS-Exchange. Fildata leveres fra Win2008. Applikasjoner må støtte: Citrix XenApp/XenServer teknologi Windows 2008 R1/R2 UNC filbaner Roaming Profiles Single-Sign-On.NET Framework 2.0 eller senere. Database plattform må være minimum være supportert på MS-SQL 2005 6.5.1.3 Intern database sone Database servere for intern data ligger i denne sonen. Tilgang styrt via brannmur. Database miljøet er splittet i 2, Oracle og MS-SQL 6.5.1.4 Administrasjon sone Denne sonen inkluderer styringsverktøy for servere/tjenester, type patch, antivirus og overvåking. 6.5.1.5 Elev/lærer sone Denne sonen inkluderer autentifisering, fil, print, styring, antivirus tjenester for elever og lærere. Side 20
6.5.1.6 Sikker sone Her finnes alle server og tjenester for leveranse av applikasjoner med sensitiv eller fortrolig informasjon: terminal-, applikasjon-, fil-, print-, AD-, epost-, DNSog webservere. All tilgang til sonen skjer via ICA-protokoll og alle applikasjoner tilgjengeliggjøres via Citrix Online Plugin. Brukere autentifiseres fra AD og klienten må befinne seg i en sone definert som sikker. Sikker sone har tilgang til intern sone. 6.5.1.6.1 Terminalservermiljøet i sikker sone Selskapet leverer applikasjoner via terminalserver, applikasjonene streames via Microsoft AppV 4.5 eller nyere. Powerfuse benyttes til administrasjon av tilganger og tilpasninger av brukermiljøet. Terminalmiljøet er basert på Win2008, Powerfuse, AppV, Citrix XenServer, Provisioning og XenApp. Terminalserverne er virtualisert. Selskapet skal levere alle applikasjoner via terminalserver til tynnklient der hvor dette er mulig. Enkelte applikasjoner blir levert via Citrix XenDesktop eller som lokalt installert på PC men via Selskapets distribusjonsmekanisme (SCCM). Data som lagres i denne sonen blir å regne som fortrolige. Applikasjoner i denne sonen må støtte: Citrix XenApp/XenServer teknologi Windows 2008 R1/R2 UNC filbaner Roaming Profiles Single-Sign-On.NET Framework 2.0 eller senere. Database plattform må minimum være supportert på MS-SQL 2005 6.5.1.7 Sikker database sone Database servere for sensitive data ligger i denne sonen. Tilgang styrt via brannmur. Database miljøet er basert på MS-SQL. 6.5.1.8 IP-tjenester IP-tjenestene er en del av felles tjenestene og er bærer for leveranser av tjenestene over nettet. 6.5.1.9 Nettverk Alle lokasjoner er knyttet sammen i et fibernettverk. Alle lokasjoner har en kantsvitsj hvor Selskapet terminerer sin trafikk og lokasjonen har eget LAN bakenfor dette. De henter data fra Selskapets kantsvitsj. Side 21
NANNESTAD HURDAL GJERDRUM Aksessnett Datasenter 101228 Internett TDC/Song DAL ULLENSAKER Internett BaneTele EIDSVOLL NES Figur 6 Nettverkstopologi 6.5.1.10 Telefoni Det er satt opp et IP-telefonisystem med sentral management i form av 3 stk Cisco Callmanagere for optimal redundans. Disse er basert på VMware sin infrastruktur for bedre å kunne møte utfordringer og frigjør serverne fra knytningen til hardware som dette tradisjonelt har vært bundet til. Dette gjør at ved hardwarefeil vil den eller de Callmanagerene som står på feilende hardware kunne raskt flyttes over på annen hardware med minimale forstyrrelser for kunde. Det er også satt opp støttesystemer for køing til sentralbord, opplest fravær, voicemail, åpningstider, tastemenyer og lignende. Støttesystemene snakker med sentral infrastruktur som Active Directory og Exchange for kalendersynkronisering av avtaler inn i telefonisystemet slik at kunder med avtaler i kalender automatisk blir viderekoblet til opplest fravær. Tilstedeværelse (presence) er også integrert mellom forskjellige systemer slik at sentralbordet har oversikt over kalender, om det er opptatt i telefonen og, dersom det er aktivert og registrert, om det er opptatt på mobiltelefonen til brukeren (intern memo: kommer etter valg av ny teleoperatør). Løsninger mot dette må støtte: standarder som SIP, SCCP, CDP, TCIP/IP, H.323, MGCP, RTP og lignende. må ha sentral management med mulighet for tilkobling av støttesystemer via webservicer. Side 22
Apparater må støtte 802.11af, mens analoge overganger tillates det bruk av ekstern strømadapter. Støttesystemer må kunne levere talepost, sentralbordklient til PC, katalogtjenester for sentralbord og søk, websider for sluttbrukere for selvbetjening, linjestatus å telefoner og mobiler og lignende. 6.6 Teknologiarkitektur Teknologiarkitekturen fastlegges av samspillet mellom servere og nettverk. Komponentene utgjør hver for seg en flaskehals i et sammenhengende system, som betyr at det er helt avgjørende at komponentene kan samarbeide. Er nettverket for lite hjelper det ikke å kjøpe kraftige servere. Nettverk skal være et stabilt element i teknologiarkitekturen som binder det maskinelle sammen. Representerer en modell av maskinvare og programvare som støtter opp under applikasjons- og informasjonsarkitekturen. Dette representerer et mer fysisk syn på virksomhetsarkitekturen. 6.7 Sikkerhetsarkitektur 6.7.1 Innledning Arkitektur for samhandling i selskapet legger til grunn enhetlige sikkerhetsløsninger blant annet innenfor autentisering, sporing og skjerming. I forbindelse med økende krav til integrasjon mot andre aktører i samfunnet, som samarbeidspartnere og publikum, samt den stadige økende bruken av mobile løsninger i kommunesektoren har behovet for sikre løsninger blitt stadig viktigere. En sikkerhetsarkitektur skal gjenspeile hva selskapet legger vekt på når det gjelder autorisasjon og autentisering. Den skal inneholde opplysninger om hver enkelt bruker, hver enkelt tjeneste og tilgangen til disse. Sikkerhetsarkitekturen vil inneholde tjenester for pålogging, definering av roller, definering av tilgang til tjenester, sertifikathåndtering etc. I dagens situasjon er det slik at enhver applikasjon vedlikeholder sin egen sikkerhetsstruktur med brukernavn/passord, roller og autorisasjon. Brukerne logger seg på nettet med brukernavn/passord og må deretter logge seg på alle de applikasjoner som vedkommende skal bruke. Dette medfører at de må huske på en hel rekke brukernavn/passord. Dette er en stor risikofaktor med henblikk på sikkerhet og for brukerne oppleves dette som tungvint. For administratorene medfører dette et stort vedlikehold for å holde applikasjonene à jour med brukere/passord og roller. Ved å etablere en sentral sikkerhetstjener vil selskapet få en sikkerhetsinfrastruktur som håndterer elementer som autentisering, autorisasjon, Single SingOn (SSO) og rollemodeller. En skal likevel være klar over at SSO introduserer nye sårbarheter i infrastrukturen som må håndteres. I dag benyttes AD for brukerautentisering i selskapet. Det er naturlig at en sikkerhetstjener hos selskapet bygger på AD. Side 23
6.7.2 Autentisering (Authentication) AD benyttes for autentisering. Autentisering skal gjøres ved å benytte integrert sikkerhet med AD. Bruker logger seg på mot AD, og skal ikke møte flere spørsmål om brukernavn og passord. Alle applikasjoner skal derimot benytte informasjon om pålogget bruker for å identifisere og verifisere brukerens tilgang. En tjenesteorientert arkitekturmodell ligger vel til rette for rollebasert autentisering. Sikkerhetsmessig er anonyme PC-er i nettet som flere brukere benytter i fellesskap en sikkerhetsrisiko. Sikkerhetsarkitekturen legger derfor til grunn at alle brukere skal autentisere seg med personlig og unik pålogging. Evt. problemer forbundet med tid til pålogging og lasting av profil må løses. Alle løsninger skal benytte AD som brukerkatalog og benytte integrert pålogging mot AD. 6.7.3 Sikkerhetsbarrierer Det er etablert virtuelle brannmurer for å ivareta de forskjellige soneinndelingene. Dette kombinert med virtuelle nettverk (VLAN) skiller datatrafikk på det logiske lag. Sentral drift av tilgangsregime på tvers av brannmurer (ACL) er etablert med en felles sentral logging for trafikk kontroll. Videre er løsningen satt opp med logiske løsninger som vekter trafikk mønster for å detektere og skille ut uønsket eller skadelig trafikk (IPS) Eksterne tilganger er sikret med krypterte forbindelser med 2 faktor autentisering (VPN) Løsninger mot dette må støtte: Levere sentraladministrerte virtuelle brannmurer Hoste IDS som en integrert del av løsningen slik at administrasjon forvaltes i ett grensesnitt. Logging med live og historiske data må være sentralisert i ett grensesnitt. Fjerntilganger må kunne leveres via web ssl VPN og klientbasert VPN og administrasjonen kunne gjøres fra samme driftsplattform som øvrige brannmurer. 6.7.4 Autorisering (Authorization) Ved å ha autentisering og autorisasjon opp mot AD i alle lag i en tjenesteorientert arkitektur oppnår vi sikkerhet i flere lag før bruker når frem til datatjenestene. Dette er et bærende prinsipp i selskapets arkitekturmodell. Side 24
Arkitekturmodellen muliggjør aksess fra brukere utenfor kommunene og skolene. Sikkerhetsregleverket i AD kan spesifisere eksakt hvordan eksterne henvendelser skal håndteres. Dette inkluderer hva de skal få lov til å gjøre og hvilke data de har tilgang til. Dette kan f eks være barnevernet, lærer, elever, rådmenn etc. Disse vil autentiseres og deretter få tilgang til spesielle tjenester som er autorisert for en begrenset del av dataene. 6.7.5 Logging (Accouting) Det er en felles logg- og overvåkningstjeneste. Dette for å sikre enklere og mer enhetlig overvåkning av framtidige systemer. Alle systemer skal logge til Webtjenesten eller logge mot standard Windows Event Log. 6.7.6 SSO (Single Sign On) Et mål med arkitekturmodellen er innkapsling og tilgjengeliggjøring av gamle applikasjoner i nye løsninger. Et flertall av disse har egne brukerdatabaser med brukerinformasjon som brukernavn og passord. For å få til en lettere tilgang til applikasjonene, er det innført en tjeneste for Single Sign On (SSO) som en del av sikkerhetsarkitekturen. Det nyttes Citrix Single Sign-On som løsning for å oppnå dette. SSO letter situasjon med mange brukernavn og passord som brukerne må forholde seg til. Dette bedrer brukervennligheten og gir også økt sikkerhet. I tillegg er det kunne påregnes langt færre supporthenvendelser, idet brukerne bare har ett brukernavn og passord å huske og å forholde seg til. En SSO etableres som en del av sikkerhetstjeneren og er integrert med AD. Autorisasjon implementeres mot AD. Arkitekturmodellen åpner opp for andre former for både autorisasjon og autentisering enn brukernavn/passord. Dette kan være løsninger rundt smartkort og bruk av digitale sertifikater. Modellen legger også til rette for bruk av PKI for signering og kryptering av informasjon fra brukere og mellom bestanddeler i en løsning. 6.7.7 Kryptering og bruk av PKI Arkitekturmodellen åpner opp for andre former for både autorisasjon og autentisering enn brukernavn/passord. Dette kan være egnede sikre løsninger som benytter tofaktor-autentisering og/eller PKI-BASERTE TEKNIKKER. Modellen legger også til rette for bruk av kryptering av lagret informasjon eller informasjon som overføres mellom brukere, eller mellom superbrukere og utstyr som administreres. Selskapet har valg å basere seg på teknologi fra Microsoft. Microsoft tilbyr løsninger for PKI gjennom Windows Server integrert med AD. Side 25