Den Norske Akademiske NettSkyen (NANSen) - Arbeidsgruppens rapport

Størrelse: px
Begynne med side:

Download "Den Norske Akademiske NettSkyen (NANSen) - Arbeidsgruppens rapport"

Transkript

1 Den Norske Akademiske NettSkyen (NANSen) - Arbeidsgruppens rapport Olav Kvittem (UNINETT), Nils Johan Lysnes (UiT), Ole Ingvard Langfeldt (NTNU), Morten Werner Forsbring (UiO), Jarle Bjørgeengen (UiO) 20. desember

2 Sammendrag Denne rapporten er en kombinasjon av drøftinger rundt og anbefalinger for opprettelsen av en ny organisasjonsenhet i UH-sektoren: NANSen. Det anbefales at den nye enheten først og fremst skal stå for en samlet porteføljeforvaltning av sektorens felles IT-tjenester. Det er allerede en sterk vridning, både i og utenfor sektoren, mot at IT-tjenester leveres og konsumeres som skytjenester. Rapporten belyser hva dette innebærer ved å destillere og trekke sammen informasjon fra en rekke kilder, eksempelvis Aagedal-utvalgets arbeid, notat fra Brønmo, eksisterende aktiviteter i sektoren, aktiviteter og rapporter fra UH-relaterte institusjoner i Europa. Sist men ikke minst, referansemateriale fra standardiseringsorganisasjoner og Datatilsynet. Basert på det som ble avdekket i destillasjonsprosessen anbefales det at NANSen har som mål at alle fellestjenester i sektoren, og som dermed er under NANSen sin forvaltning, skal leveres som skytjenester. Dette begrunnes med et ønske om en mer koordinert og samordnet tilnærming til tjenesteleveransene kombinert med økte krav om fleksibilitet og skalering. Vi mener at en slik samordning vil muliggjøre konkurranse med eksterne skyleverandører for en del områder. I kombinasjon med interne leveranser av skytjenester vil dette skape en dynamikk som fremmer effektivitet og maksimal samlet utnyttelse av IT-ressursene i sektoren. En forutsetning for å lykkes med etableringen av NANSen tror vi er at en kritisk masse av institusjoner melder seg på og bidrar med ressurser og forpliktelser inn i NANSen til beste for sektoren. Det anbefales at det i første omgang ansettes/allokeres en daglig leder hvis hovedoppgave vil være å trekke prosessen med etableringen videre i retning av arbeidsgruppens anbefalinger. En viktig del av det videre arbeidet vil være å (re-)etablere velfungerende faggrupper med ressurser fra sektoren. Faggruppenes oppgave vil være å motta styringssignaler fra NANSen og produsere faglige premisser for å understøtte porteføljeforvaltningen. Likeledes vil daglig leder måtte se til tilstrekkelig bemanning til forvaltningen av porteføljen. En viktig del av porteføljeforvaltninen vil være å ha en overordnet oversikt over relevante produkter eksternt og aktiviteter/prosjekter i UH-sektoren både i Norge og ellers i Europa. NANSen må i tillegg sørge for god dialog med institusjonene, både med hensyn til forpliktelser/bidrag og markedsføring av tjenester. I likhet med tjenestene NANSen skal forvalte bør selve organiseringen av NANSen være elastisk og tilpasningsdyktig med hensyn til den til enhver tid eksisterende porteføljen og akiviteter med inn/ut-fasing av tjenester. Det er en forutsetning for å lykkes at NANSen blir tilført tilstrekkelig med ressurser for å komme igang og etterhvert bli til en organisasjon som sørger for kontinuitet, koordinering og kvalitet i sektorens fellestjenester. Som nevnt anbefales det at deler av tjenesteleveransene etableres internt i UH-sektoren. Hovedbegrunnelsen for dette er at det sikkerhetsmessig er opplagt at en del tjenester ikke kan flyttes ut i en offentlig sky. I tillegg har UH-sektoren en stabil og sikker nettverksinfrastruktur med høy kapasitet og lav responstid mot de fleste institusjoner. Dette er en opplagt fordel med hensyn til tjenestekvalitet og tilgjengelighet. Vi anbefaler først og fremst at det jobbes mot å etablere en UH-intern IaaS-sky, med 2

3 påfølgende integrerte PaaS på toppen av denne. Grunnen til dette er at IaaS/PaaS er fundamentale fellesnevnere som må til for å begynne flytting av eksisterende fellestjenester over i en UH-sky og etablering av nye UH-interne skytjenester. 3

4 Innhold 1 Bakgrunn UH-sektoren Aagedal Brønmo Mandat Bakgrunn Hvorfor samarbeid Oppgaver for arbeidsgruppen Arbeidsform og rapportering Leveranser UNINETTs rolle Terminologi og referensearkitektur IBM Cloud Computing Reference Architecture Tjenesteorientering Roller Arkitekturelementer Opprettelse av skytjenester og økosystemer Infrastruktur Common Cloud Management Platform (CCMP) Arkitekturprinsipper ASPIRE - The Adoption of Cloud Services Definisjon av sky/cloud En annerledes verden - skyen og sluttbrukerpress Konsekvenser for forskning og høyere utdanning Forretningsmulighet - felleskapsskyen

5 2.2.5 Skytilkobling - Interoperabilitet via sikret mellomvaresamarbeid Skymegling - Aggregering av behov, leverandørhåndtering, distribusjon og adopsjon Samsvar - juridiske aspekter, personvern og sikkerhet Oppsummering Hvorfor etablere NANSen? Hva er NANSen? Ressurser i sektoren Tjenestekvalitet Styrke samarbeidet i sektoren Samarbeid med Europa Oppsummering Dataklassifisering, sikkerhet og juridiske aspekter Konfidensialitet Integritet Tilgjengelighet Teknisk sikkerhet Klassifisering av data Konklusjon Arkitektur Generelle krav til arkitektur Identitetsforvaltning Åpne standarder og standardiserte APIer Sikkerhet Felles tjenesteforvaltning Cloud Computing Management Platforms

6 5.3.2 Selvbetjeningsportaler Arkitektur i lavere lag IaaS Hybride skytjenester Utvikling av tjenester Databaser Høytilgjengelighet Tjenester i regi av et NANSen Generelle økonomiske aspekter ved skytjenester ecampus tjenester og andre felles IT-løsninger i sektoren Integrasjon Forslag til tjenestetyper Skylagring Virtuelle maskiner (operativsystemer) Personlig lagring Webapplikasjonsrammeverk Digital eksamen LMS-system Backup Arkivering Etablere egne skytjenester Oppsummering Organisering og finansiering av NANSen Kompetanse NANSen bør ha Forslag til organisering av NANSen Forslag til faggrupper

7 7.3 Forhold til institusjoner i sektoren Mulig permanent NANSen-organisasjon Hva er en hensiktsmessig finansiering av oppgaver som NANSen skal utføre Oppsummering Konklusjon og videre arbeid Organisering Etablering av tjenester Etablering av en UH-intern IaaS-sky Ordliste/forkortelser 62 Referanser 63 A Høypålitelig systeminfrastruktur 64 A.1 Pålitelighet A.2 Maskinvare A.3 Driftsmiljø A.4 Høypålitelige tjenester A.5 Felles tjenester

8 1 Bakgrunn Dette kapitlet oppsummerer bakgrunnen for denne arbeidsgruppen og dette avsnittet oppsummerer kapitlet. Denne rapporten er produsert etter et mandat for en arbeidsgruppe nedsatt av UNINETT sammen med IT-ledere ved universitetene i Tromsø, Trondheim og Oslo. Styringsgrupppen består av Stig Ørsje (UiT), Lars Oftedal (UiO), Håkon Alstad (NTNU), Tor Holmen (UNINETT) og Petter Kongshaug (UNINETT). Aagedal-utvalget anbefaler en del tiltak for fellessystemen i sektoren som å dele opp i en kundeside og en leverandør side. Dette er en føring som NANSen bør ta opp i seg og separere produksjonen av skytjenester fra kundesiden. Det legges også vekt på strategier for IT-arbeidet og at UNINETT skal drive med infrastrukturbygging. Ole Brønmo, tidligere leder av Høgskolen i Sør-Trøndelag har på oppdrag fra UNINETT styre skrevet et notat med tittel Nettskyteknologi i UH-sektoren som anbefaler å gå videre med et program for skytjenester. Dette ledet til opprettelse av denne arbeidsgruppen som er sammensatt av de deltakende institusjonene som arbeider etter et mandat gitt nedenfor. Hovedpunktene i Brønmos anbefalinger er tatt inn i mandatet. 1.1 UH-sektoren Aagedal Aagedal-utvalgets rapport Strategi, organisering og styring av de felles administrative IT-systemene i universitets- og høgskolesektoren : [? ]. det anbefales et klarere skille mellom kundesiden og leverandørsiden for internt utviklede systemer det må utvikles en felles IT-arkitektur for sektoren det må bygges løsninger for integrasjon mellom IT-systemene på en mer helhetlig måte gjennom etablering av en integrasjonsplattform Brønmo Anbefalingen i dette notatet [? ] konkluderer med UNINETT bør derfor initiere et program for bruk av skytjenester. Arbeidet bør skje i nært samarbeid med sektoren. For arbeidet bør det settes opp en handlingsplan med tidsrammer. Handlingsplanen bør blant annet inneholde: 8

9 Konsultasjoner med et representativt utvalg institusjoner Etablering av en referansegruppe Etablere statusdokument Utforming av skystrategi Forslag til forretningsmodeller Faglig og økonomisk vurdering av konkrete skytjenester i UH-sektoren Forslag til organisering 1.2 Mandat Bakgrunn En rekke kommersielle skytjenesteleverandører tilbyr sine tjenester i markedet. Dette markedet endres kontinuerlig i form av nye aktører, nye tjenester og ny funksjonalitet. Slike tjenester er attraktive for studenter og ansatte i UH-sektoren og er allerede tatt i bruk i vesentlig grad. Kommersielle skytjenester er et gode for UH-sektoren, men de har også sine negative sider. Den største ulempen er at vi risikerer en rekke ukoordinerte løsninger som hindrer faglig og administrativt samspill innad i de samme UH-institusjoner og mellom UH-institusjoner. Det vil på sikt også bli en kostnadsmessig utfordring når slike tjenester tas i bruk på en ukoordinert måte. Mer bakenforliggende informasjon kan finnes i UNINETT notatet Nettskyteknologi i UH-sektoren. Universitetene og UNINETT ønsker å ta skytjenester i bruk på en omforent måte og vil dermed forsterke de gode sidene og redusere eller fjerne de negative sidene ved skytjenestene. I den anledning ønsker vi å utrede hvordan en nasjonal akademisk nettsky kan hjelpe oss med dette Hvorfor samarbeid Nettskytjenester har en kostnadsside. Til tross for at disse i enkelte tilfeller oppfattes som gratis og i andre tilfeller som billig for den enkelte bruker, så vil kostnaden likevel kunne bli høy dersom man utøver ukoordinerte innkjøp eller dersom disse tjenestene kommer i tillegg til andre tjenester som man også må ha. Et samarbeid omkring anskaffelse og drift av skytjenester vil være kosteffektivt. IKT-kompetanse er en begrenset ressurs i UH-sektoren og i samfunnet forøvrig. I forbindelse med skytjenester vil det også være behov for juridisk og økonomisk kompetanse i tillegg til forhandlingserfaring for anskaffelse av systemer. Kompetanse innen standardisering og driftsorganisering vil også bli nødvendig. Samarbeid vil være nødvendig for at hele UH-sektoren skal kunne forholde seg til den teknologiske utvikling som nå skjer på en effektiv måte. 9

10 Teknologiutviklingen innen skytjenester og generelt innen IKT går nå så raskt at ingen enkelt UH-institusjon kan forventes å holde seg oppdatert på alle områder. I et samarbeid kan man fordele ansvar for ulike teknologiområder og således oppnå en totalkompetanse som vil være unik. Samarbeid er også nødvendig for å kunne framstå som en storkunde når man i fellesskap skal ut og handle kommersielle skytjenester. Skytjenesteleverandører gir betydelige rabatter til kunder av en viss størrelse. Vi kan også benytte UNINETT og NORDUnet til å sørge for kommunikasjonen fram til stedet hvor skyleverandøren produserer sine tjenester og oppnå ytterligere rabatter Oppgaver for arbeidsgruppen 1. Arbeidsgruppen skal utforme en arkitektur for hvordan UH-sektorens skytjenester skal utvikles og drives, og hvordan våre egne skytjenester skal eksistere i samspill med kommersielle skytjenester. 2. Arbeidsgruppen skal vurdere hvilke tjenester som kan inngå i den akademiske nettskyen og foreslå en prioritert rekkefølge for realisering. Tjenester innen UHsektorens primæroppgaver, forskning og undervisning, skal gis prioriter og spesielt skal man vurdere lagringstjenester for data til forskning og utdanning. 3. Arbeidsgruppen skal foreslå organisering og finansiering av arbeidet med både en nasjonal skytjeneste og bruken av kommersielle skytjenester. 4. Arbeidsgruppen skal organisere en workshop hvor arbeidsgruppens konlusjoner presenteres for resten av UH-sektoren Arbeidsform og rapportering Arbeidsgruppens medlemmer skal bruke tilnærmet all sin arbeidstid på oppgaven i perioden fram mot en workshop. Deltakerne skal inngå i et prosjektteam med en utpekt prosjektleder. Arbeidet skjer i fysiske møter, web-møter ol. eller på den måten arbeidsgruppen finner hensiktsmessig. Deltakerne får dekket sine kostnader fra sine respektive hjemmeorganisasjoner. Arbeidsgruppen rapporterer til en styringsgruppe bestående av IKT-direktør ved UiO, NTNU og UiT og adm.dir. i UNINETT. Den initielle forutsetningen om at gruppens medlemmer skulle allokere 100% av sin arbeidstid til å jobbe med denne rapporten har ikke vært mulig å gjennomføre på grunn intern prioritering av oppgaver på den enkeltes arbeidsplass. Dersom det var mulig å allokere 100% av tiden ville man kunnet gått mer detaljert til verks Leveranser Arbeidsgruppen skal levere sin innstilling i form av en rapport. Rapporten skal som et minimum svare på disse spørsmålene: 10

11 (a) Hvorfor bør man etablere NANSen? (b) Hva er en hensiktsmessig organisering av NANSen? (c) Hvilke tjenester bør prioriteres levert av NANSen? (d) Hva er en hensiktsmessig finansiering av de oppgaver som NANSen skal utføre? Til slutt skal rapportens konklusjoner presenteres i en åpen workshop. 1.3 UNINETTs rolle UNINETTs strategi innebærer å forsterke IT-støtte til primærfunksjonene i sektoren som forskning og undervisning. Dette er allerede delvis tilstede gjennom Ecampus-satsningen og støtte til tungregning gjennom UNINETT Sigma. UNINETTs rolle er å bidra til koordinering og å bygge infrastruktur på et bredt grunnlag og bidra til gode IT-tjenester. UNINETT kan trekke på et bredt nettverk av kompetanse innenfor forskningsnettene i verden sammen med standardisering og europeisk IKT-forskning gjennom f.eks. forskningsprogrammer og direkte samarbeid. Denne kompetansen kan vi bidra med i et samarbeid med UH-sektorens mer operative IT-kompetanse og skape infrastruktur for innovative løsninger til nytte for hele sektoren. UNINETT har som et ledd i å forberede satsning på feltet bygget et laboratorium for å teste arkitekturer som man kan bygge høypålitelige skytjenester på. 11

12 2 Terminologi og referensearkitektur Det kan være litt forvirrende å forholde seg til terminologien rundt skytjenester. Ofte benyttes samme uttrykk til å betegne forskjellige konsepter og forskjellige uttrykk for å betegne samme konsept. Hensikten med dette kapittelet er å definere vår forståelse av begrepene slik at rapporten blir tydelig og avgrenset i forhold til mandatet. 2.1 IBM Cloud Computing Reference Architecture 2.0 Gruppa bestemte seg tidlig for å benytte IBMs "Cloud Computing Reference Architecture 2.0"(IBM-CCRA) [? ] som begrepsapparat. Dette fordi dokumentet omtaler en hel del perspektiver og sammenhenger som sammenfaller godt med gruppas forståelse av hva skytjenester er og hvordan det overlapper med og bygger på tanken om tjenesteorientering. Modellen tar også opp i seg NISTs 1 definisjon [? ] av "cloud-computing". Vi vil her gjengi det vi tolker som de viktigste aspektene å ta hensyn til i etableringen av en UH-sky i sammenheng med referansearkitekturen Tjenesteorientering Tjenesteorientering (SOA - service-oriented architechture), er definert av The open group 2 som: An architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services. [? ] I følge NIST er skytjenester, eller cloud computing : A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models [? ] I NISTs definisjon innehar skytjenester fem karakteristiske egeneskaper: On-demand self-service Forbrukeren kan selv sette opp ønskede ressurser uten videre avklaringer med tjenestetilbyder. 1 NIST - National Institute of Standards and Technology 2 The Open Group er en leverandør- og teknologi-uavhengig industrikonsortium som står bak bl.a. POSIX og TOGAF standardene 12

13 Broad network access Mulighet for å tilgjengeliggjøre tjenestene over nettet til standard klient-plattformer. Resource pooling Tjenestetilbyderens ressurser er organisert for å dynamisk kunne betjene mange samtidige forbrukere og deres endrende behov. I utgangspunktet har ikke kunden noe forhold til eksakt plassering av ressursene annet enn eventuelt på et høyere nivå (for eksempel innenfor et land, et fylke eller datasenter). Eksempler på ressurser kan være lagring, CPU, minne og nettverksbåndbredde. Rapid elasticity Kapasitet skal være elastisk, gjerne automatisk, og kunne skaleres etter behov. For forbrukeren virker kapasiteten å være tilnærmet uendelig og skal kunne reserveres i en hvilken som helst størrelse til en hvilken som helst tid. Measured service Ressursforbruk blir automatisk kontrollert og optimalisert i en passende måleenhet for type tjeneste. Ressursuttaket kan overvåkes, kontrolleres og rapporteres, til fordel både for tilbyder og forbruker. Videre definerer NIST tre tjenestemodeller: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) og Software as a Service (SaaS). Tjenestmodellene og det faktum at skytjenester omtales i vendinger som opprettelse, leveranse og forbruk av skytjenester søtter opp under konseptet med tjenesteorientering slik det forstås i forbindelse med SOA. Det finnes mange bedrifter og institusjoner som eksponerer infrastruktur og plattformer og tjenester før de hadde hørt om skytjenster, så begrepet Software as a services er ikke noe som er nytt med skytjenester, men har vært tema i mange år. NIST definerer også fire utrullingsmodeller for skyer som definerer omfanget av skyarkitekturen: Private Skyen er utelukkende administrert og benyttet av en enkelt organisasjon. Community Skyen deles mellom flere lignende organisasjoner. Public Skyen er offentlig tilgjengelig som en tjeneste over internett av de som måtte ønske tilgang. Hybrid kombinasjoner av de over. Det som skybegrepet bringer til bordet, i tillegg til det som er kjent gjennom SOA, er en standardisert arkitektur for leveranse av tjenester som har fleksibilitet og evne til å tilpasse kapasitet til ressurs-behov som er i kontinuerlig endring. Egenskaper som selvbetjening, tilgjengelighet og avregning basert på tjenestebruk viktige tilleggselementer som definerer om noe fortjener merkelappen skytjeneste". The Open group definerer en tjeneste som: en logisk representasjon av en repeterbar forretningsaktivitet som har et gitt utfall (for eksempel sjekk kundekreditt, vis vær-data, oppdater økonomirapport) 13

14 selvstendig kan være sammensatt av andre tjenester fremstår som en svart boks for brukere av tjenesten I henhold til The Open Group s definisjon av SOA er derfor alle skytjenester SOAtjenester. Alle SOA-tjenester er imidlertid ikke skytjenester. Skyarkitekturen er altså mer konkret og omfattende i hva den definerer. Ved å anerkjenne SOA-arven i forbindelse med skyarkitektur kan mye av det som allerede er erfart med SOA gjenbrukes inn i skyarkitekturen, noe som reduserer nødvendigheten av å finne opp nye begreper og metoder. SOA definerer noen gjennomgripende problemer/tema: tjenestekvalitet, integrasjon, informasjon og styresett. På samme måte som disse problemene/temaene er viktig i SOA er de viktige i skyarkitektur, men det er heller ikke flere slike gjennomgripende problemer i skyarkitektur enn i SOA. IBM Cloud Computing Reference Architecture definerer de fundamentale arkitektoniske elementene som utgjør et skytjenestemiljø. Modellen er strukturert på en modulær overordnet måte slik at man kan få konseptuelt overblikk over hvordan ting henger sammen og eventuelt dykke ned i detaljer i de forskjellige modulene etter behov. I denne rapporten tar vi kun for oss det overordnede perspektivet Roller IBM-CCRA [? ] definerer tre hovedroller: Skytjenesteforbruker, skytjenestetilbyder og skytjenesteskaper. Hver rolle kan oppfylles av en enkelt person, en gruppe av personer eller en organisasjon. Intensjonen med disse definisjonen er å fange opp det som vil finnes i alle skymiljø. Det vil ofte være behov for definere i prosjektespesifikke tilleggsroller/underroller i tillegg. En skytjenesteforbruker er en person, eller et IT-system som benytter tjenesteinstanser levert av en bestemt skytjeneste. Begrepet benytter inbefatter: forespørsel, håndtering av kvoter, endring av CPU-kapasitet for en virtuell maskin (VM), endring av antall brukere, osv. Dvs. det som er av tenkelige aspekter ved benyttelse av en tjeneste. Man kan også se på skytjenesteforbrukeren som en super-rolle som representerer den parten som forbruker tjenester. Skytjenesteforbrukeren leser tjenestekatalogen og utløser instansiering og håndtering av tjenester fra denne. En skytjenesteleverandør har ansvar for å tilby skytjenster til skytjenesteforbrukere. En skytjenesteleverandør er definert av eierskapet til et skyhåndteringsrammeverk ( common cloud management platform (CCMP)). Eierskapet kan realiseres ved egen implementering av et CCMP eller ved å forbruke et slikt som en tjeneste. Aktører som innehar skytjenesteleverandør-rollen og skytjenesteforbruker-rollen på samme tid, benytter selv skytjenester for som delressurser i bakkant for sin egen skyleveranse til sine forbrukere. 14

15 En skytjenesteskaper er ansvarlig for å skape en skytjeneste som kan kjøres av en skytjenesteleverandør for å tilby den til skytjenesteforbrukere. Skytjenesteskaperen utnytter funksjonalitet som blirt gjort tilgjengelig fra skytjenesteleverandøren. Administrasjonsfunksjoner som skaperen vanligvis trenger fra leverandøren er definert i den aktuelle CCMP-arkitekturen. En skytjenesteskaper designer, implementerer og vedlikeholder operative og administrative artefakter spesifikk til en skytjeneste Arkitekturelementer Tjenesteintegrasjon mellom tradisjonelle tjenesteleveranser og skyleveranser er viktig, særlig i sammenheng med hybrid-løsninger hvor lagring og/eller prosessering av en tilbudt tjeneste sømløst skal kunne flyte mellom privat og public sky. Plasseringen styres av policy. Skytjenester kan representere en hvilkensomhelst type av IT-funksjonalitet så lenge de oppfyller skysærtrekkene: selvbetjening, nettverkstilgang, levert fra en (eller flere) felles delt IT-ressurs, er elastisk og avregner ihht. forbruk. Administrasjonsfunksjonene i CCMP-arkitekturen er ansvarlig for å levere instanser av skytjenester til forbruker i hvilken som helst kategori av tjenester, den daglige administrasjonen av tjenesteinstansene fra et leverandørperspektiv samt la forbrukere administrere sin instanser vha. selvbetjening. IBM-CCRA definerer fire forskjellige tjenestemodeller: Infrastructure as a service (IaaS), Platform as a service (PaaS), Software as a service (SaaS) og Businessprocess as a service (BPaaS). IaaS Muligheten til å leie prosessorkraft, lagring, nettverk og andre fundamentale maskinressurser hvor kunden er i stand til å opprette, lagre data og/eller kjøre vilkårlig programvare. Dette inkludererer operativsystem og applikasjoner. PaaS Muligheten til å rulle ut applikasjoner laget av forbrukeren i en skyinfrastruktur med støtte for et eller flere programmeringsspråk med varierende rikdom i underliggende funksjonsbibliotek og knytning lisensbetingelser. Her forholder ikke forbrukeren seg direkte til operativsystem eller lagring, men muligens til forskjellige ferdiglagde konfigurasjoner for applikasjons-hosting. SaaS Muligheten til å bruke tilbyders applikasjon som kjører i en skyinfrastruktur og er tilgjengelig fra et utvalg av tynnklient-grensesnitt som for eksempel en nettleser, og/eller apper på nettbrett og mobiltelefoner. Med unntak av helt brukerspesifikke innstillinger styrer ikke brukeren av tjenesten de underliggende elementene i skyinfrastrukturen eller eventuelle rammeverk applikasjonen er bygget i. BPaaS Muligheten for benytte forretningsprosesser som er levert ved bruk av skyteknologi. BPaaS-tilbyderen er ansvarlig for funksjonaliteten. Dette innbærer som 15

16 regel et sett av applikasjoner som fungerer samme for understøtte en forretningsprosess. Eksempler kan være: fordelsprogrammer for ansatte i en bedrift, håndtering av forretningsreiser, innkjøpssystemer osv. IaaS involverer vanligvis bruk av et virtualiseringsrammeverk på en eller annen måte. PaaS involverer vanligvis bruk av en eller flere multi-tenant mellomvareløsninger. SaaS (Software As A Service) er sluttbruker-applikasjoner levert over nett etter en skymodell. Leveranse av en SaaS bygger som regel helt eller delvis på tidligere nevnte *AAS kategorier, men behøver ikke gjøre det så lenge den oppfyller skyegenskapene definert av NIST. BPaaS finnes kun i IBM-CCRA og er ikke nevnt i NISTs cloud-definisjon Opprettelse av skytjenester og økosystemer Det er viktig å forstå forholdet mellom en skytjeneste og artefaktene som kan skapes innenfor grensene i et økosystem. Det å opprette en skytjeneste krever tilsvarende investeringer i måle og avregningsmodeller samt en organisasjon som understøtter den implisitte tjenesteorienteringen som er nødvendig for at skyarkitekturen skal være til nytte. For eksempel er Amazon EC2 et økosystem som fokuserer på IaaS. Artifaktene i økosystemet er virtuelle maskiner (VMer). EC2 gjør det mulig å laste opp og kjøre virtuelle maskiner og få avregnet bruken av disse. VMene arver nesten alle tekniske og forretningsmessige avgjørelser som allerede ble foretatt da Amazon bestemte seg for å gjøre EC2 tilgjengelig for markedet. VMer kan ha et begrenset antall ytelses-slaer og har et begrenset antall administrative funksjoner (start/stop/reboot etc.) som er forhåndsdefinert av EC2. Det er en god grunn til Amazon tilbyr et begrenset sett egenskapet i EC2: hver ny egenskap har implikasjoner til kostnaden forbundet med å levere tjenesten. Det er vanskelig å forutse kostnader som følger av økt fleksibilitet derfor er det ønskelig å begrense antall funksjoner. Dette illustrerer behovet for å fastslå alle krav til en IaaS-sky på forhånd slik at artefaktene som utvikles på toppen av systemet i etterkant har lite rom for endring i måten IaaS-skyen benyttes på. Dette bør ikke sees på som en ulempe, men tvert imot noe av det som bidrar til å gjøre slike tjenester kostnadseffektive. Dette kombinert med hvor lett det er å utvikle nye artefakter oppå tjenesten vil være avgjørende for suksessen til rammeverket. Det er altså en stor forskjell mellom å utvikle selve rammeverket og det å utvikle artefakter som benytter rammeverket Infrastruktur I dette kapittelet omtales infrastruktur som de fysiske bestanddelene av en skyarkitektur, samt hvordan disse er koblet sammen. Dette inkluderer server, lagring og nettverksressurser. 16

17 Avgjørelsen om hvorvidt virtualisering skal benyttes oppå den fysiske infrastrukturen avhenger av kravene til tjenestene som skal gå der. For mange tilfeller av IaaS vil det være umulig å levere uten å benytte en eller anne form for virtualisering/hypervisor. For andre typer tjenester, som for eksempel store analyseoppgaver og indeksering/søk, kan det være mer formålstjenlig å ikke benytte virtualisering. Dette er ikke nødvendigvis et brudd med arkitektur-prinsippene som tilsier at tjenester skal leveres fra en felles ressurs bygget opp av like komponenter. Det kan gjerne være variasjon mellom leveranseinfrastrukturen i forskjellige skytjenester, men den bør være lik innenfor leveransen av en og samme skytjeneste. Det som derimot er et krav, er et enkelt felles CCMP som styrer plasseringen av de forskjellige tjenesten på riktig infrastruktur. Når det er sagt: desto mindre variasjon det er over infrastrukturen desto mer oppfylles standardiseringskravet til en skyarkitektur. Minimal variasjon er selve grunnlaget for høy grad av automatisering og skalering som er basisegenskaper ved et skymiljø Common Cloud Management Platform (CCMP) CCMP tilbyr et sett av forretnings- og operative (BSS og OSS) tjenester. Disse tjenestene utnyttes av skytjenester hos forbrukere som da kjører sine tjenester hos en leverandør. I tillegg til BSS og OSS tilbyr også CCMP brukergrensesnitt for å tilfredsstille de tidliger omtalte roller. Funksjonaliteten er tilgjengelig via programmeringsgrensesnitt (APIer) som CCMP tilbyr. Som navnet impliserer er CCMP strukturert som en plattform. Administrasjonstjenestene i et CCMP må ikke forveksles med skytjenestene som skapes av skytjenesteskaperne. Det er imidlertid slik at skytjenesteskaperne bør benytte administrasjonstjenestene i rammeverket for å skape storskalaøkonomi vha. automatisk skalering provisjonering, deprovisjonering osv. CCMP er definert som en generell administrasjonsplattform for å støtte adminstrasjon på tvers av I/P/S/BaaS. CCMP er altså et samlebegrep over de verktøy/applikasjoner som tilsammen gjør at en skyarkitektur oppfyller sine krav. Det vil selvsagt også være slik at et CCMP må tilpasses den enkelte skytjeneste implementasjon. Dersom man for eksempel kun leverer IaaS er det naturligvis irrelvant at CCMP har støtte for de andre xaas. Et CCMP er i hovedsak todelt i funksjon: OSS og BSS. De beskriver ikke nødvendigvis en monolittisk todeling, men mer ett begrep om at de aller fleste tjenester i et CCMP vil være av den ene eller den andre typen. Forenklet kan man si at alle tjenester som er nødvndig for at skytjenesteskaperen kan skape en skytjeneste er av typen OSS og alt annet er BSS Arkitekturprinsipper Begrepet arkitekturprinsipper blir vanligvis brukt i arbeid med virksomhetsarkitektur. The open group definerer for eksempel prinsipper som generelle regler og retningslinjer 17

18 som sjelden endres og som informerer og støtter måten en organisasjon utfører sitt oppdrag på [? ]. Til gjengeld kan prinsipper også være kun et element i et strukturert sett av ideer som til sammen definerer og rettleder organsisasjonen, fra verdier via aktiviteter til resultater. Avhengig av organisasjonen defineres arkitekturprinsipper på forskjellig nivå. Prinsippene er et subsett av IT-prinsippene som har med arkitekturarbeid å gjøre. Tanken er at de reflekterer et nivå av konsensus på tvers i organisasjonen og legemliggjør ånden og tankesettet i arkitekturen. I motsetning til en arkitekturmessig beslutning, er et arkitektiurprinsipp en overordnet retningslinje eller paradigme som er styrende for utfallet av mange mindre beslutninger. Arkitekturstandarder på sine side er mer detaljerte og finkornede enn arkitekturprinsipper. Prinsipp 1: Design for effektivitet Motivasjon og fordeler Formålet med skytjenester generelt og IBM-CCRA spesielt er å muligjøre store endringer med hensyn til operasjonell effektivitet (sammenlignet med tradisjonell IT-virksomhet). Det er derfor viktig at ha med dette styrende prinsipp i all utvikling av skytjenester og tolkningen av standarden. Operasjonelle kostnader og vedlikeholdskostnader er for høye i dagens IT-landskap. Det er for mange avhengigheter, for mye kompleksitet som gjør at IT-operasjonen i for stor grad baseres på manuelle rutiner og aktiviteter. I tillegg er endringstakten for dagens IT-systemer for lav i forhold til forretningsmessige forventninger. Konsekvenser og forutsetninger Implementering av en sky i tråd med prinsipper og retningslinjer beskrevet i IBM-CCRA, som skal gi en effektiviseringsgevinst langt utover investeringen, forutsetter høy grad av standardisering med lite variasjon innenfor en skyleveranse. Dette muligjør større grad av automatisering med mindre innsats. Det vil alltid være en avveing mellom kravene til variasjon i skytjenestene som skal benytte rammeverket (funksjonsrikdom) og hensynet til standardisering (kostnad ved etablering og vedlikehold). Målet er å få til mest mulig av begge deler innenfor rammene av eksisterende teknologi og sikkerhetsvurderinger. Prinsipp 2: Støtte for Lean Service management Motivasjon og fordeler Dagens service-managementprosesser er i alt for stor grad basert på individuelt arbeid og langt fra å være automatisert. Dagens service-management teknologier er ikke integrert nok og utfyllende nok til å adressere alle globale servicemanagement funksjoner. 18

19 Konsekvenser og forutsetninger Alle (automatiserte) service management funksjoner må kommunisere og håndtere statusinformasjoner En global status- og styringsfunksjon er nødvendig. Det må minst være en overvåkingsfunksjon for statusinformasjon. Startpunktet og avslutningen av tjenesteleveransen bør baseres på selvbetjening. Driftsorganisasjonen trenger andre ferdigheter enn i dag, spesielt et høyere nivå mht. skyteknologi. Eksisterende implementasjoner av service design må kanskje redesignes til å levere tjenester i tråd med CCMP. Nye tekniske service management komponenter (utover det som er vanlig i tradisjonell datasenter-administrasjon) er nødvendig i CCMP-implementasjoner: for eksempel håndtering av tjenesteadministrasjon og håndtering av livsyklusen til virtuell maskiner. Det er ikke sikkert at produkter man kan kjøpe er nok til å støtte en full CCMPimplementasjon slik den er definert i IBM-CCRA uten tilpasninger og utvidelser. Teknisk variasjon bør begrenses for å gjøre designet mest mulig strømlinjeformet. Muligheten for effektiviseringsgevinst avhenger også av interoperabiliteten og integrasjonen mellom administrasjonsverktøyene som er i bruk. Fundamental restrukturering og strømlinjeforming av IT-administrasjonsprosesser er nødvendig for å maksimere eliminasjon av manuelle datasenteroppgaver. Avhengig av optimaliseringsgraden kan dette også føre til endringer bort fra veletablerte IT-standarder for tradisjonell datasenteradministrasjon (e.g. ITIL). Dette prinsippet handler ikke om gradvis forbedring av administrasjonsprosesseer for datasenter slik som det er drevet frem fra en del optimaliseringsprosesser. Grunnen til dette er at en slik tilnærming med gradvis optimalisering kun vil oppnå 10-15% effektivisering, noe som ikke tilsvarer den størrelsesorden av besparelser som er oppnåelig med et skybasert datasenter. Dette prinsippet handler heller ikke om 1:1 automatisering av eksisterende datasenterprosesset, siden dette for det meste betyr transformering av eksisterende tungvektsprosesser til å bli automatiserte tungvektsprosesser. Et fundamentalt paradigmeskifte må til. Et slikt skifte kan oppnås med eksisterende administrasjonsverktøy (beriket med noen få nye og avgjørende verktøy), men de må brukes på en helt annerledes måte. Hovedforutsetningen for å redusere operasjonell kostnad er å eliminere oppgaver som ikke lenger trengs som resultat av avgrensninger i omfang av hva som skal administreres. Grunntanken er at jo flere oppgaver som blir eliminert og jo mer homogent datasenteret blir, 19

20 desto lettere er det å automatisere hvilkensomhelst administrasjonsoppgave og dermed oppnå en vesentlig reduksjon av kostnader. For eksempel kan en tjenestetilbyder som tilbyr SaaS eliminere administrasjonskostnader for den underliggende maskinvaren og heller kjøpe en IaaS-tjeneste. IaaS tilbydere som leverer til SaaS kan på sin side fokusere på effektivisering i leveransen av IaaS og skape storskalaøkonomi ved å tilby samme type tjeneste til mange tjenesteforbrukere og dermed distribuere kostnader over mange forbrukere og dra nytte av ressursdelinge ved hjelp av konsolidering og standardisering av maskinvare i bakkant. Prinsipp 3: Identifisere og dra nytte av likheter Motivasjon og fordeler Det er for mange funksjoner i dagens IT-landskap som implementeres på individuelle og separate måter. Mangel på koordinasjon fører til redundante funksjoner med helt eller delvis overlapp noe som igjen fører til unødig kompleksitet. Motivasjonen for dette prinsippet er gjenbruk av administrasjons-/ccmp-funksjoner og dermed realisere gevinster ved storskalaøkonomi ved å bruke en felles administrasjonsplattform for å levere og administrere mange skytjenester. Det er nødvendig med en mekanisme som utnytter deling av administrasjonsrammeverk mellom de forskjellige typene xaas og som tilby skyspesifikt omfang og administrasjonsmuligheter. Konsekvenser og forutsetninger En mer generisk design forutsetter mer analytisk design og utviklingsinnsats; det er en viss risiko for over-engineering (hvis de forventede fremtidige krav og bruksscenarioer ikke materialiserers seg) og kan gå på bekostning av brukervennlighet (ansvaret for konfigrasjon av tjenesten for et bestmet formål flyttes til tjenesteforbruker). Dette kan gjøre at produktiviteten lider, spesielt i lys av prinsipp 1, design for skyskala-effektivitet. Prinsipp 4: Definer og administrer skytjenester generisk i deres livssyklusen Motivasjon og fordeler IT-tjenester i dag er vanligvis ikke designet på en generisk måte, men spesifikk for bestemte formål. Et CCMP slik det er definert i denne referansearkitekturen skal kunne skalere og huse flere forskjellige typer skytjenester (xaas). Da er det essensielt å introdusere en modell som tillater skytjenesteutviklere å spesifisere hvordan CCMP-funksjonaliteten blir brukt i sammenheng med deres spesifikke tjenester og hvordan instanser av skytjenesten skal leveres til tjenesteforbrukere (i tråd med klasse/instans tenkemåten i objektorientering). Det er viktig å være spesifikk mht. betydningen av til begrepet tjeneste i de forskjellige sammenhenger/situasjoner. Det er for upresist å kun benytte begrepet tjeneste. Begrepet tjeneste og tjenesteinstans benyttes i IBM-CCRA på følgende måte: en tjeneste er 20

21 ansvarlig for å opprette tjenesteinstanser og beskrive deres runtime context. Tjenesteinstanser slik de er definert i IBM-CCRA er ikke web-tjenester i vanlig forstand. Ingen av disse konseptene passer inn i ITIL-definisjonen av en tjenester heller. I sammenheng med IBM-CCRA er tjenester håndgripelige enheter som det referes til i substantivs form: de er leveranseenheter og administrasjonsenheter. Slike skytjenesteinstanser representerer noe som er levert som en tjeneste (xaas). Alle disse enhetene har en levetid som started med provisjonering og leverense og ender med deprovisjonering. En tommelfingerregel: alt som kan oppstå i en xaas-stakk kan være en tjenesteinstans. Konsekvenser og forutsetninger Skytjenesteskaperen må ha grundig forståelse av funksjonaliteten som tilbys av CCMP og hvordan denne funksjonaliteten kan utnyttes innenfor sammenhengen av de forskjellige skytjenestene. Alle IT-tjenester må være tydelig beskrevet gjennom deres livsløp. For hver IT-tjeneste må det skapes et sett med artefakter på en konsistent måte i tråd med IBM-CCRA cloud service creation. 2.2 ASPIRE - The Adoption of Cloud Services Som avslutning på terminologi og referansearkitektur-kapittelet har vi valgt å presentere rapporten The Adoption of Cloud Services [? ] skrevet av ASPIRE 3 Dette er en rapport som undersøker hvordan høyere utdanning kan trekke fordeler ved å benytte seg av skytjenester og mer spesifikt hvordan NREN 4 kan og bør ta en aktiv koordinerende rolle i forbindelse med avtaler med eksterne leverandører og sørge for opprettelse av community clouds. Her gjengis de sentrale aspekter rapporten peker på som ikke allerede er dekket av tidligere kapitler i denne rapporten Definisjon av sky/cloud Rapporten lener seg også på NIST sin definisjon av cloud [? ] og følger i stor grad (om enn et subsett) av IBM-CCRA En annerledes verden - skyen og sluttbrukerpress Hvorfor presser brukere på mot skytjenester? De er der i dag, og integrerer godt med personlige dingser De fungerer, og brukerer trenger vanligvis ikke å søke om tillatelse fra IT-avdelingen. 3 ASPIRE (A Study on the Prospects of the Internet for Research and Education) - en studie i TERENA-regi 4 National Research and Education Network - UNINETT er NRENet i Norge 21

22 SaaS-tjenester er brukervennlige med mye funksjonalitet. IaaS og PaaS tilbyr ekstrem elastisistet uten behov for investeringer. Studenter presser på for bring your own device (BYOD) og ser på universiteter/høgskoler som et midlertidig stoppested og den høye kapasiteten i NRENs fører til en god brukeropplevelse mot eksterne skytjenester. Særlig de som har god tilkobling til NRENs. e-forskning presser på for skytjenester. Noen e-forskningsapplikasjoner er godt egnet for plassering i skyen, mens andre er avhengig av spesiell programvare eller maskinvare for å virke. En stor oppgave for e-forskning vil være å klassifisere hvilke applikasjoner som med fordel kan flyttes til skyen og hvilke som krever en tradisjonell HPC-arkitektur. En kombinasjon av IaaS og PaaS er første skritt, men SaaS har også et potensial særlig der hovr det finnes RESTful APIer hvor ting kan automatiseres. Etterhvert som Store data blir mer benyttet i akademiske disipliner, øker behover for skalerbar databahandling som skyen tilbyr. Drivere for å flytte tjenester ut i skyen: Finansiering Innovasjon Elastisitet for å tilpasse tilbud til etterspørsel av ressurser. Interessenters ønske om å ta i bruk skymodeller. Sikkerhet, både en styrke og en svakhet. Hindringer: Avregningsmodell vs. finansieringsmodell Kostnader er ikke tydelige. Databeskyttelse og lokalisering av data Konsekvenser for forskning og høyere utdanning Nye muligheter innen skytjenester og IT bringer muligheter ut til sluttbrukere som tidligere ikke var tilgjengelig. Dette er en realitet. IT og infrastruktur pleide å være lite tilgjengelig, nå er den tilgjengelig overalt. Folk har i større grad med seg personlige dingser som de alltid har i nærheten samtidig som data og applikasjoner flyttes vekk fra brukerne og ut i skyen. En skystrategi må ta denne virkeligheten inn over seg og virkningen dette har på brukerne. Tidligere leverte i hovedsak brukernes hjemmeorganisasjon 22

23 mesteparten av IT-tjenestene (arbeidsgiver etc.). Nå velger de i større grad egen maskinvare, programvare/tjenester og hvor de lagrer data. De er ofte teknologisk oppegående og har utmerkede IT-fasiliteter hjemme. De forventer den samme opplevelsen på arbeidsplassen. Dette er mest synlig i trenden bring your own device, eller ta med din egen dings. Organisasjoner som driver med forskning og høyere utdanning er midt oppe i denne utviklingen. De kjenner presset fra brukerne og leverandørene. Leverandører av skytjenester med storskala-infrastruktur henvender seg direkte til brukerne. Brukerne ønsker å velge de IT tjenestene de allerede kjenner og benytter og de ønsker å ha de tilgjengelig hele tiden og overalt. I tillegg er det en utvikling mot økt samarbeide på tvers av institusjoner. IT-avdelingen på sin side fokuserer tradisjonelt på et internt begrenset sett av funksjonalitet som er internt kontrollert og har som et begrenset sett av ressurser til å vedlikeholde tjenestene og betjene brukerne. Dette fører til et gap mellom brukernes forventinger og de nesten uendelige mulighetene som online-tilbudene tilbyr og de begrensede mulighetene som finnes intern i organisasjonen. Skytjenester kan lukke dette gapet. Forskning og høyere utdanning ønsker å vite hvilke IT-tjenester som bør produseres internt og hvilke som bør kjøpes eksternt. Videre ønsker de å vite hvilke tjenester de bør tilby og hvilke tjenester brukerne kan ordne med selv (FIXME: mener vi inkl. finne, kjøpe og bruke på egenhånd eller kun et subsett? bør kanskje bytte ut ordne med selv med noe mer konkret?). Hovedgrunnen til å lage egne interne tjenester er å ha full kontroll og kunne lage spesialtilpassede tjenester/produkter som passer organisasjonens spesifikke behov. I den andre enden av skalaen har vi IT-løsninger uten noen kvalitativ differensiering: hyllevaretjenester. Konsumere - bruk av den offentlige skyen En måte å gjøre dette gapet mindre på er å jobbe mot en tilstand hvor brukerne kan velge fra et rikt tilbud av online hyllevare-tjenester fra den offentlige skyen. Ved å aggregere etterspørselen kan forsknings og utdanningsinstitusjoner oppnå fordeler ved å forhandle frem avtaler på vegne av mange med lignende behov, samt assistere ved risikovurderinger og avtaleverk mht. sikkerhet osv. Dette beskriver et outsourcing-scenario som involverer flere leverandører. Institusjoner tilbyr individuelle brukere å velge mellom et antall offentlige skytjenester i en en-tilmange tilnærming for forbruk av tjenester. Produsere - bli en community-cloud /felleskapssky En annen måte å gjøre gapet mindre på er at institusjoner samarbeider, deler på ressurser og bygger en fellesskapssky og leverer selv: Tjenester som dekker fellesbehov for alle institusjoner for forskning og høyere utdanning. 23

24 Tjenester som har en viss mengde spesialtilpasning, men som likevel kan deles over et antall institusjoner, for eksempel online-læringssystemer, strømming av forelesninger og forskningsverktøy. Tjenester med spesielle sikkerhetsbehov som forbyr bruk av offentlige skytjenester. For eksempel studieadministrative systemer med personopplysninger, resultater osv. eller sensitive data Forretningsmulighet - felleskapsskyen Det finnes mange områder hvor NRENs kan hjelpe deres tilsluttede organisasjoner å dra nytte av skytjenester. Et spørsmål som bør vies spesiell oppmerksomhet er hvorvidt NRENs bør bygge og operere en dedikert skyinfrastruktur og levere skytjenester til de sammensluttede institusjonene. Til forskjell fra en del andre aktiviteter krever det å bygge en skyinfrastruktur vesentlig med ressurser i form av ekspertise og penger. Infrastrukturen skal både bygges og vedlikholdes med høy grad av stabilitet og tilgjengelighet. Videre trengs det en bærekraftig finansieringsmodell på lang sikt. Merk at det samme gjelder for bygging og vedlikholde av stamnett innenfor forskning og utdanning, et område hvor NRENs har demonstrert at de skaper verdi. Det er et pulserend marked for offentlige skytjenester i tillegg til at mange institusjoner velger private skytilnærminger for interne tjenester. Er det da et marked for en felleskapssky? En felleskapssky kan levere alle typer skytjenester, *aas. Det enkleste leveransemessige stedet å starte og der hvor mest arbeid er gjort, er innenfor IaaS. En IaaS kan benyttes til å bygge felleskaps-spesifikke PaaS- og SaaS- tilbud. Det kommersielle marked er meget konkurransdyktig på pris og fullt av interessante tilbud. Store leverandører har bygget enorme infrastrukturer for å understøtte sine tjenester, så det synes opplagt at selv om hele forsknings- og utdanningssektoren slår seg sammen vil det være umulig å skape samme storskalaøkonomi. På den andre side finnes det mange små kommersielle tjenestetilbydere som retter seg mot lokale markeder og nisjer. Dette indikerer at det også er et marked for mindre-skala skytjenester. I andre enden av spekteret finner vi akademiske institusjoner som tar opp skyinspert teknologi som store virtualiseringsløsninger og automatiserte provisjoneringssystemer for å gjøre deres egne IT-sentere mer effektive. Dette kalles ofte for en privat sky. En organisasjon som vurdere å bygge en felleskapssky må derfor være bevisst på at flere av medlemsorganisasjonene, spesielt de store, allerede har opprettet strømlinjeformede miljøer. En fellesskapssky bør posisjonere seg slik at den er levedyktig i et slikt landskap. Hvorfor er felleskapsskyer mer attraktive? Hovedattraksjonen med en felleskapssky vs. en kommersiell, offentlig sky har med tillit og kontroll å gjøre. Det er knyttet risiko til faktorer som offentlig lovgivning, avhengighet mot eksterne leverandører, datasikkerhet, tjenestetilgjengelighet, datatap og portabilitet (exit kostnad). Disse risikomomentene vil bli vesntlig redusert med en felleskapssky, særlig om denne tilbys fra en organisasjon som er godt kjent i felleskapet og som har tillit. 24

25 Det er noen nettverksrelaterte kommersielle og tekniske årsaker til at NREN-opererte felleskapsskyer er attraktive. Det faktum at NREN kontrollerer nettverket kan hjelpe på mange måter. Reduksjon av kost med tanke på flytting av data, noe som kan være en vesentlig kostnad særlig for stordata -applikasjoner. Kontroll på ytelse både i forhold til gjennomstrømming og ikke minst responstid for å gjøre både dataintensive og interaktive tjenester brukbare. Kontroll på sikkerheten ved at data ikke behøver å bevege seg ut av NREN-nettet eller til og med campus-nett om det er ønskelig. Har NRENs det som skal til for å opprette/administrere skyer? Tatt i betraktning den erfaring NRENs har med å operere stamnett og dagens markedssituasjon, er det naturlig å undersøke mulighetene for å opprette en felleskapssky, men er NRENs i en posisjon som tilsier noen realisme i å ta på seg denne oppgaven? På flere områder er det grunn til å stille spørsmålstegn ved dette: NRENs er begrenset til spesifikke vertikale fellesskap og kan ikke håpe på nå de samme storskala-fordelene som internasjonale skytilbydere. De fleste NRENs har ikke de store mengder maskinvare som kreves og har ingen erfaring med å selge prosesserings- og lagringstjenester (selv om noen NRENs har sterke forbindelser til HPC-miljøer. De fleste NRENs har ikke tilgang til fysisk datasentekapasitet. Det vanlige er at de leier noe plass i datasentrene til de større medlemsorganisasjonene (eller kommersielle leverandører). På andre områder er NRENs godt utstyrt De har relasjoner med felleskapene som går langt bakover i tid og som stoler på de når det gjelder utvikling og drift av nettverksinfrastruktur. Ved å kontrollere stamnettet er NRENs godt posisjonerte til å tilby skytjenester med god og sikker ytelsesgaranti samt lage nettverkssoner med høy tillit som kan integreres med campus-nettene. Så lenge nettskyer er et populært tema i forskningskretser kan NRENs trekke på ekspertise fra forskere innenfor deres egne miljøer. På den andre siden kan de tilby noe unikt til disse Det er en lang historikk/tradisjon med samarbeid mellom NRENs som er et utmerket grunnlag for å lære av hverandre. 25

26 Mulige uønskede konsekvenser Gitt at NRENs skal opprette og administrere skyinfrastruktur på vegne av felleskapet, er det et par ting man bør ha i bakhodet. Muligheten for fremmedgjøring av eksisterende kunder, særlig universiteter, ved å skape en oppfatning av å ville overta og sentralisere det som historisk sett har vært universiteters domene. For å unngå dette bør NRENs fokusere på områder hvor disse IT-organisasjonene allerede vurderer en tjenesteutsetting samt områder hvor det er en opplagt fordel å ha tjenester på tvers av hele felleskapet kontra en pr. campus-tilnærming. En annen felle å gå i, når en infrastruktur allerede er på plass i regi av felleskapet, er sterke insentiver til å bruke denne som standard ( fordi den allerede er der ), på tross av at andre tilbydere tilbyr bedre og billigere tjenester. For å begrense den negative virkningen av dette bør det være transparente avregningsmodeller som gjenspeiler de faktiske kostnadene. NRENs bør ikke forsøke å tvinge felleskapet til å benytte slike tjenester, men heller tiltrekke det med nyttige og økonomiske tjenester som er tilpasset felleskapets behov Skytilkobling - Interoperabilitet via sikret mellomvaresamarbeid Utfordringen for høyere utdanning og forskning er å legge tilrette for valgfrihet, samtidig med et sikkert og tilgjenglig miljø som er tilpasset behovene. Dette er mulig ved å lage en infrastruktur som kobler sammen skytjenester med hverandre og med identitsforvaltningssystemene for de enkelte institusjonene. Ved å gjøre dette kan brukerne få tilgang til skytjenester med kontoene fra sine egne institusjoner. Instituisjonenene styrer selv sine identiteter og deres tilganger til skytjenestene (selvbetjening). En slik infrastruktur er en utvidelse til det fødererte autentiseringssystemet som har kommet på plass over de siste årene. Disse føderasjonene kan utvides ved bringe sammen instituisjonene og skyleverandører i en samarbeidsinfrastruktur. Følgende er nøkkelelementer i et slikt samarbeid: Sikker, føderert brukerautentisering og single-sign-on (SSO) basert på standarder for å oppnå interoperabilitet. Føderasjoner kunne da koble en hel campus til skytjeneste-felleskap. SAML2 5 og oauth 6 er eksempel på ofte brukte protokoller. Enhetlig gruppehåndtering og autorisering. Infrastrukturen lager ett kontrollpunkt hvor brukere kan administrere sine team og en online-applikasjon hvor bruker kan sette opp grupper, invitere team-medlemmer og definere roller og tilganger. Disse gruppenivå-privilegiene blir automatisk oppdatert i alle tilkoblede skytjenester. Dette gjør medlemsskap enkelt å administrere og holder de konsistent. Dette 5 SAML2 - Security Assertion Markup Language oauth - Åpen autentiseringsprotokoll benyttet av skytjenesteleverandører som for eksempel Facebook, Google og DropBox 26

27 gjør det mulig å benytte flere skytjenester samtidig. Grouper, som er utviklet i USA av NSF og Internet2 er et eksempel på en slik applikasjon. Forskning og utdanning er sosiale aktiviteter av natur. For å støtte under de sosiale aspektene bør det være mulig å utveksle data mellom tjenestene. I tillegg ønsker gjerne brukere å gruppere skyapplikasjoner i en portal. OpenSocial gjør dette. Denne åpne standarden er omfavnet av etablerte aktører i markedet. Kombinasjonene av identitetsforvaltning og åpen datautveksling gjøre det mulig for brukere å logge inn på mange forskjellige skytjenester med deres egen legitimasjon/id. De kan samarbeide i sin etablerte gruppetilhørighet via enhetlig gruppehåndtering. Institusjonene kontrollerer tilgjengelige tjenester (vilkår for bruk og distribusjon) samt identits- og tilgangsadministrasjon. Interoperabilitetsfunksjonene (via opensocial) gjør det mulig og kombinere eksisterende tjenester og komponenter etter eget ønske. For å oppnå en slik samarbeidsinfrastruktur er det viktig at NRENs og tjenestetilbydere samarbeider og diskuterer nødvendige protokoller og blir enige om standarder. SURFnet, NREN i Nederland, har etablert en slik samarbeidsinfrastruktur som har egenskapene som er beskrevet ovenfor. Denne kalles SURFconext [? ] Skymegling - Aggregering av behov, leverandørhåndtering, distribusjon og adopsjon Fasilitering av skytjenesteforbruk (public) innebærer aggregering av behov fra medlemsorganisasjonene til NRENs og forhandle med tjenestetilbydere på vegne av dem for å oppnå bedre betingelser enn de enkelte medlemsorganisasjonene klare å oppnå på egenhånd. De må også organisere distribusjon og adopsjon av skytjenester. Dette er en form for megler-og-fasiliteringsrolle. NRENs som vurderer å påta seg en slik rolle bør vurdere egen organisasjonsstruktur nøye først. Nøkkelkomponenter i leverandørhåndtering og skymegling inluderer: Innkjøp Forhandle med leverandører på vegne av medlemmene for å oppnå gode betingelser mht. pris, SLA etc. Infrastruktur Oppnå interoperabilitet via standarder og samarbeidsinfrastruktur for å koble sammen institusjonene med leverandørene og vice versa. Distribusjon Tilby en online -butikk for å vise de tilgjengelig tjenestene og tilby muligheter for brukerene til å anskaffe tjenestene. Adapsjon Opprette og vedlikeholde kommunikasjon og markedsprogram og fasilitere bruk av tjenester 27

28 2.2.7 Samsvar - juridiske aspekter, personvern og sikkerhet. Offentlige skytjenester er begrenset av samme rammeverk som andre tjenester og har begrensninger mht. personvern, samsvar med regler og risikovurdering. Det finnes mange likheter til tradisjonell utsetting av tjenester ( outsourcing ): få tak i revisjonsinformasjon, bevaring av dokumentasjonsspor, tilstrekkelig personvern, unngåelse av innlåsing. Skyer kan være multinasjonale, ofte er de store i skala og kan avhenge av underleverandører. Dette gjør samsvarsspørsmålene forbundet med tjenesteutsetting vanskeligere å få oversikt over etterhvert som skyer driver over internasjonale forskrifts- og sikkerhetsdomener. EU/EEA-forskrifter skiller seg vesentlig fra Amerikas Forente Staters forskrifter, og mange (US) skytilbydere er underlagt EU-forskrifter i Europa. Dette utgjør utfordringer med hensyn til bevaring av konfidensialitet/personvern. Siden disse forskriftene er strengere for NRENs og universiteter enn for individer, er det en tendens til at avgjørelser om bruken av skytjenster skyves fra organisasjoner over på individuelle brukere siden dette lar universiteter slippe av kroken. Mange tjenester i skyen er basert på regler som kan endres ensidig av tjenestetilbyderen. Sosiale media som Facebook forebeholder seg retten til å endre betingelsene og reglene etter eget forgodtbefinnende, og dette er ikke i samsvar med EU-forskrifter. Tjenestetilbydere adresserer dette ved å be brukerne akseptere slike vilkår i avtalen som en betingelse for bruken av tjenesten, noe mange brukere gjør uten engang å lese avtaleteksten. En nøkkelanbefaling til brukere er at de aldri bør legge ut sensitive data, i ukryptert form, utenfor egen organisasjon. Hvis du legger ukrypterte data i skyen kan du anse disse som offentliggjort. Det er det tvilsomme ansvaret til dataeieren å vurdere og balansere hensynet til funksjonalitet opp mot risikoen for eksponering av data. I tillegg er det et risikoelement i det at selve lagringslokasjonen av data er ukjent, men utenfor organisasjonens kjernenettverk. Om kritiske data er lokalisert innenfor ditt eget nettverk, er det stor sannsynlighet for at du kan få tak i de selv om deler av nettverket skulle feile. De fleste er rimelig trygge på at NREN-nettverk og GÉANT 7 leverer pålitelig tilgang til kritiske data. Dette er ikke nødvendigvis tilfelle med data lagret på tjenester i skyen. Fysiske maskiner med unike IP-adresser er i ferd med å bli historie. Addresseoversettenderutere har allerede brukket dette paradigmet i årevis. Med virtualisering og tjenesteorientering oppstår et landskap av sammenkoblede APIer, noe som leder til en komplisert global floke som er umulig for myndigheter å fullt ut forstå, og i langt mindre grad regulere. Hvordan håndterer man risiko under slike omstendigheter? 7 GÉANT - pan-europeisk forskningsnett 28

29 2.3 Oppsummering IBMs referansearkitektur (IBM CCRA), publisert av The Open Group, utgjør en omfattende og detaljert definisjon av hva skytjenester er og knytter skytjenester opp mot tidligere definisjon av tjenesteorientert arkitektur. Bruken av IBM-CCRA gjør det mulig å forstå hva en skyarkitektur er samtidig som den bygger på begreper og definisjoner som er kjent fra før slik at man unngår å finne opp hjulet på nytt. De viktigste elementene i IBM CCRA er: Skyarkitektur har mye overlapp med tjenesteorientert arkitektur. Hovedforskjellen er at skyarkitektur gir en mer omfattende definisjon av hvilke tilleggsegenskaper som må til for å kalle en arkitektur for skyarkitektur sammenlignet med en tjenesteorientert arkitektur. Det defineres tre hovedroller med ansvarsområder: Forbruker, tilbyder og skaper av skytjenester. Det nedfelles et sett med prinsipper som bør være styrende for implementering og drift av en skyarkitektur: Design for effektivitet Støtte for Lean service management Identifisere og dra nytte av likheter Definer og administrer skytjenester generisk i hele livssyklusen. TERENA-panelet ASPIREs rapport The Adoption of Cloud Services knytter skytjenester til muligheter, utfordrigner og begrensninger for Europeiske NRENs og utdanningsinstitusjoner. Det gis en oppsummering av utviklingen de siste årene og en beskrivelse av den nye virkeligheten som trenger seg på som en konsekvens av stadig bedre og billigere offentlige skytjenester kombinert med brukere med egne dingser ( devices ) som forventer kvalitet på tjenester i tråd med det de er vant med. Det påpekes store muligheter for besparelser ved riktig bruk av offentlige skytjenester, behovet for å tenke nytt (og stort) ved implementering av felleskapskyer og behovet for grundige vurderinger når det gjelder risiko både ved bruk av offentlige skytjenester og etablering av felleskapstjenester. Det viktigste poenget i rapporten er behovet for samarbeid om mellomvare-standarder særlig i forhold til autentisering og autorisering. Dette er en forutsetning for høy grad av selbetjening og delegering av myndighet på en effektiv og sikker måte. Videre påpekes behovet for, og muligheten et mellomvare-samarbeid gir for, etablering av samarbeidsløsninger mellom institusjoner i et land og på tvers i Europa. 29

30 3 Hvorfor etablere NANSen? NANSen er et forslag til neste generasjon samarbeidsplattform for tjenesteforvaltning i UH-sektoren. I denne sammenhengen anser vi tjenester videre enn hva definisjonene er i tjenesteorientert arkitektur og NISTs definisjon av skytjeneseter (se kapittel 2.1.1) for å ikke begrense tjenestetilbudet NANSen kan omfatte. Skytjenestetilbyder og skytjenesteskaper kan være UNINETT, enkeltorganisasjoner i sektoren, samarbeid mellom forskjellige organisasjoner i sektoren og kommersielle aktører. Som eier av UH-sektoren vil utdanningsdepartementet være interessert i optimal utnyttelse av ressurser for maksimal mengde og kvalitet på forskning og utdanning. ITvirksomheten er en viktig del av dette bildet. IHR-prosjektet ved UiO [? ] er et godt eksempel på det økende kravet om å levere mer for færre ressurser. IT-leveranser er en stor del av kostnadsbildet i produksjonen av utdanning og forskning. Dersom UH-sektoren kan vise til kostnadseffektiv og profesjonell organisering av IT-leveranser i UH-sektoren vil det skape tillit hos eier og minske nødvendigheten av styrende grep for fremtiden. Etablering av en mer kostnadseffektiv leveransemodell som skalerer oppover kan også åpne for nye muligheter for å konsolidere inn IT-tjenester fra andre deler av det offentlige Norge. Og omvendt dersom noen andre lykkkes bedre med det samme, er det en reell risiko for at UH-sektorens IT-virksomhet selv blir marginalisert. Dette bakteppet bør være med i betraktningen når UH-sektorens IT-ledere velger hvordan man best kan bidra inn i NANSen. 3.1 Hva er NANSen? NANSen er et av UNINETT, NTNU, UiT og UiOs svar på Aagedal-utvalgets [? ] og Ole Brønmos [? ] rapporter hvor det anbefalles endel tiltak for fellessystemer i sektoren og konkrete programmer for skytjenester. Aagedal-utvalget skriver at administrative IT-systemer ikke skal være en konkurransearena for institusjonene i UH-sektoren, men at fellessystemer og fellestjenester gir både sektoren og den enkelte institusjon mulighet til å få bedre kvalitet, høyere tjenestenivå og mindre ressursbruk på denne delen av virksomheten. Vi tror NANSens viktigste misjon er å være en enhet som nettopp samler forvaltning av slike fellestjenester i og for sektoren. Som NANSen-navnet beskriver handler dette om skytjenester, men vi ønsker ikke å begrense NANSen til kun det som av NIST defineres som skytjenester. Også fellestjenester som for eksempel ikke tilfredsstiller NISTs krav til for eksempel skalering eller selvbetjening bør inn under NANSen-paraplyen. Det er et langsiktig ønske om å også gå over til en skyleveransemodell for fellestjenestene for å få mer fleksible og effektive tjenesteleveranser. Vi går i dybden på krav til og hvilke type tjenester vi ser for oss at NANSen skal forvalte i kapittel 6 og forslag til organisering av tjenesteforvaltningen i kapittel 7. 30

31 3.2 Ressurser i sektoren Totalt sett over hele UH-sektoren er det mye ressurser både med tanke på nettforbindelse, IT-utstyr (datahaller, servere, lagringsløsninger) og ikke minst kompetanse på utvikling og drift av store og komplekse IT-tjenester. Idag utvikles og drives disse IT-tjenestene hovedsakelig innenfor hver institusjon, med noen unntak hvor det enten samarbeids om en fellestjeneste eller det samarbeides om teknologi. Her har vi stort potensiale for å få bedre utnyttelse av både utstyr og kompetanse. UNINETT jobber en hel del med innføring av nye tjenester i form av prosjekter. Et eksempel på dette Dette er bra tiltak, men det prosjektene mangler en kontinuerlig UH-felles prosess å overlevere løsninger til slik at prosjektene kan skaleres opp for bruk i hele sektoren og forvaltes på lengre sikt. NANSen bør fylle dette tomrommet ved at NANSen får en styrende og koordineerende rolle i forhold til prioritering av prosjekter, produksjonssetting av piloter/proof-of-concept og livsløpsforvaltning av fellestjenester for UH-sektoren. Det har også vært en del gode initiativer med hensyn til etablering av faggrupper på tvers av sektoren. Noen av disse har vært en suksess og har levd i mange år, mens andre har ebbet ut i løpet av kort tid. NANSen trenger dyp fagkompetanse på alle aspekter av IT for å lykkes i en nøkkelrolle som forvalter av fellestjenester i sektoren. NANSen bør derfor ha en styrende og koordinerende rolle i forhold til opprettelse og vedlikehold av faggrupper i sektoren. NANSen kan bestille faglige vurderinger fra faggrupper etter behov i forbindelse med innkjøp og/eller etablering av fellestjenester. I tillegg vil det være av verdi for institusjoner i sektoren å vedlikeholde et faglig felleskap på tvers, og dermed noe som de enkelte institusjonene lettere kan argumentere for å avgi ressurser til. Se forøvrig kapittel 7 for detaljene rundt dette. Integrasjon For de fleste tjenestene ønsker vi å integrere disse med eksisterende identitetsforvaltningssystemer som brukes i sektoren. Ved å gjøre dette integrasjonsarbeidet felles for hele sektoren vil vi spare ressurser totalt og også gi bedre integrerte tjenester. Mer detaljer om dette kommer i kapittel 6. Det er gjort mye arbeid i sektoren på integrasjon. Feide og eduroam er gode eksempler på dette. Infrastruktur UNINETT har gjennom mange år bygget ut og driftet en veldig god infrastruktur for nett i UH-sektoren. Dette gir mange fordeler og muligheter med tanke på samarbeid om tjenester på tvers av enhetene i sektoren. Det at UNINETT er en del av NORDUnet-samarbeidet som utvider den gode nettinfrastrukturen vi har internt i Norge også utover i norden, Europa og USA gjør oss godt rustet til å i NANSen-sammenheng samarbeide med tilsvarende organisasjoner også utenfor Norge. 31

32 NORDUnet Peering Service NORDUnet Peering Service [? ] er et tilbud til tjenesteleverandører om direkte samtrafikk med NORDUnet for å levere innhold på NOR- DUnets tilstedeværelsespunkter (POP) rundt om i verden. Dette omfatter 11 byer i USA og Europa. Dette kan benyttes til gunstige avtaler med skytjenesteleverandører fordi de ikke trenger å betale for transport av data til oss. Dette vil i tillegg kunne gi bedre ytelse mot disse leverandørene pga NORDUnets gode kapasitet. 3.3 Tjenestekvalitet Tjenestekvalitet her omfatter pålitelighet og ytelse. Pålitelighet har med sannsynlighet for at tjenesten fungerer som den skal. Ytelse har med responstid og datatransportkapasitet å gjøre. Disse parametrene har bidrag fra nett, system og applikasjon. Hvis et system er lenger unna fysisk sett så vil en del operasjoner ta lengre tid. Uformelle eksperimenter med lagring i UNINETT viste store forskjeller i ytelse mot kommersielle leverandører sammenlignet med en lokal løsning. Virtualiserte maskiner har sin kost og forskning fra Rice [? ] sier om en test av Amazon EC2: Our results show that even though the data center network is lightly utilized, virtualization can still cause significant throughput instability and abnormal delay variations. I valget av tjeneste må man da være bevisst hvor dette lagres og sitt kvalitetsbehov. Forskning og utdanning har ofte store datamengder og ytelsesbehov og noen anvendelser trenger høyere kvalitet og dermed ha et behov for tjenester via Nansen. 3.4 Styrke samarbeidet i sektoren UNINETT har arrangert flere faggrupper for spesifikke fagområder for å etablere et samarbeid i sektoren, noen er aktive og bidrar til et aktivt samarbeid og andre er dessverre ikke aktive. Vi tror NANSen bør være en pådriver til å (re-)etablere flere slike arenaer for samarbeid og at dette kanskje kan være et godt grunnlag for å sette opp flere felles IT-tjenester i og for hele sektoren. Gjennom arbeidet med NANSen har arbeidsgruppen sett at rammer for dataklassifisering og regler for behandling av disse stort sett er de samme for hele sektoren, og her bør sektoren også forsøke å samarbeide om å etablere felles retningslinjer. Det er også samarbeidsarenaer i forbindelse med anbudsarbeid og opprettelse av rammeavtaler på forskjellige typer IT-utstyr og programvare hvor sektoren sparer mye ved at prisene presses når flere slår seg sammen om anskaffelser. Slike avtaler/rammeavtaler bør også etableres for kommersiellt tilgjengelige skytjenester i de tilfeller det er behov for 32

33 tjenestene, data som skal behandles i tjenestene tilsier at det er greit å slippe de ut i skyen og det er mer kostnadseffektivt enn å sette opp tilsvarende tjenester selv internt i sektoren. 3.5 Samarbeid med Europa Geant-prosjektet som er et fellesprosjekt for forskningsnettene har flere aktiviteter på å etablere og utvikle skytjenster. Det er viktig at Nansen opererer i tett kontakt med det som skjer på dette feltet. Terena har TF-Storage som er en arbeidsgruppe for lagringsløsninger kan være verdt å følge med. Det er også naturlig å følge med NORDUnet og de Nordiske forskningsnettene med sikte på samarbeid. En Nansen-organisasjon kan dermed hjelpe til med å ta inn det som skjer internasjonalt. 3.6 Oppsummering I UH-sektoren har det historisk sett vært godt med ressurser både av kvalifisert ITpersonell og tilgjengelig infrastruktur. IT-organisasjonene i sektoren får stadig høyere krav til å være mer effektive og levere nye og bedre tjenester. Et samarbeid om tjenesteforvaltning og drift av tjenester i sektoren som skissert i NANSen vil være et godt bidrag for å kunne tilfredsstille disse kravene. Det er mulig å se for seg mange mulige samarbeidskonstellasjoner for de forskjellige enhetene i sektoren, men det er mange likheter mellom enhetene som er sterke argumenter for at samarbeid nettopp i sektoren er riktig: vi leverer veldig mange av de samme tjenestene til våre kunder det er mye samarbeid mellom forskere på de forskjellige institusjonene, og disse vil nyte godt av et felles sett med tjenester hvor samhandling på tvers av institusjonsgrensene er et av designkravene UNINETT bygger og driver en veldig god, felles infrastruktur på nett-siden som spenner hele sektoren vi har allerede en felles løsning for autentisering (FEIDE) Det er tradisjon for samarbeid mellom IT-organisasjonene, og dette bør vi bygge videre på! 33

34 4 Dataklassifisering, sikkerhet og juridiske aspekter Dette kapittelet tar for seg aspekter knyttet til sikkerhet og juss og da særlig i forbindelse med bruk av offentlige skytjenester. Dette fordi bruk av offentlige skytjenester representerer en ny klasse av risikoer sammenlignet med tradisjonell IT. Bruk av en UH-intern sky vil i så måte ligge nærmere tradisjonell IT-virksomhet når det gjelder risikovurdering selv om det vil ligge langt fra tradisjonell IT med hensyn til leveranseeffektivitet osv. Leverandører av offentlige skytjenester tilbyr tjenester med tilsynelatende gunstige betingelser, og i særlig grad mot skole og utdanningssektoren. Dette er en naturlig strategi for endel leverandører siden preferanser for valg av verktøy formes av det man er vant til fra skole/studier og brukere vil senere i arbeidslivet foretrekke verktøy de er kjent med, eller føler at de har en relasjon til. Det er derfor naturligvis attraktivt for institusjoner å se på muligheten for å benytte offentlige skytjenester til å redusere egne kostnader der det er mulig. I dette kapittelet vil vi diskutere rammene for hva vi mener er mulig ut fra et sikkerhets- og juridisk perspektiv. Det finnes flere eksempler på offentlige institusjoner som har inngått avtale om kjøp av offentlige skytjenester (public cloud) den siste tiden. Kommunene Narvik og Moss er eksempler som har vært fremme i media fordi datatilsynet opprinnelig slo fast at avtalene de hadde inngått med skytjenesteleverandører brøt med norsk personvernlovgivning. Narvik kommune forhandlet så frem endringer i avtalen med Google som adresserte de mest konkrete ankepunktene til datatilsynet, noe som gjorde at datatilsynet avsluttet sin sak mot mot kommunen. Tilsvarende skjedde med Moss kommune som inngikk avtale om bruk av Microsofts Office-365-skytjeneste. Vi kan derfor konkludere med at bruk av offentlige skytjenester er akseptert under visse betingelser. 4.1 Konfidensialitet Datatilsynets beslutning [? ] om å avslutte sakene mot kommunene Narvik og Moss kommune har den felles-betingelsen at de data som eksponeres i tjenesten må være av type åpne/offentlige. Det vil si data som allerede er kjent via åpne nettsider, eller som er av en slik art at de kunne vært offentlig publisert uten å bryte personvernloven. Dette stemmer godt overens med den nåværende policy for skytjenester ved UiO [? ]. Risikobildet endres dersom man ønsker å benytte skytjenester til data som har en annen klassifisering enn åpen. Her er det en del regler og EU-direktiver som tilsynelatende slår hverandre i hodet. I følge datatilsynests brev til Narvik kommune (11/ /RTH) er Norge bundet av EU-kommisjonens 2000/520/EF av 26. juli 2000 til å akseptere Safeharbour -sertifisering som tilstrekkelig beskyttelsesnivå med hensyn til overføring av personopplysninger til utlandet. Et annet sted står det at i følge paragraf 15 i personopplysningsloven skal ikke databehandler kunne utlevere data til andre uten etter godkjennelse fra dataeier (hendholdsvis Google og Narvik kommune i dette tilfellet). Det er flere ting som gjør at disse tingene ikke henger sammen rent praktisk. Det ene er at dersom 34

35 SSL uten CA-verifisering CA Internet US jurisdiksjon: Amazon Google MS Azure... Geant Nordunet Uninett UiO SSL SSL SSL Norsk/EU jurisdiksjon Figur 1: Illustrasjon av forskjeller i eksponeringsgrad ved bruk av skytjenester selskap registrert i USA inngår en avtale om å ikke utlevere data uten dataeiers samtykke, inngår de en avtale de umulig kan overholde. Dette fordi lovgivning i USA gjør det mulig for myndighetene der å pålegge enkeltindivider ansatt i amerikanske selskaper å utlevere informasjon de har tilgang til uten å gå veien via en domstol. Samtidig pålegges vedkommende total taushet om at utlevering av slike data har funnet sted. Dette fører i praksis til at man må anse data som behandles av selskaper registrert i USA som fritt tilgjengelig for myndighetene uten at noen andre enn de taushetsbelagte enkeltindivder i databehandlers organisasjon vet i hvilket omfang opplysninger er blitt utlevert. Man kan derfor vanskelig argumentere for at en Safe Harbour -sertifisering faktisk løser dette problemet på tross av at datatilsynet har slått seg til ro med det. Microsoft er mer åpen om dette faktum enn Google. I artikkelen Microsoft: We can hand over Office 365 data without your permission [? ] belyser Zack Whittaker hvordan Microsoft via sitt Trust center samt i tilsvar på direkte spørsmål innrømmer at den såkalte Patriot Act overstyrer Safe Harbour for selskaper registrert i USA. Siden det er umulig å vite noe om omfanget av datainnsamlingsvirksomheten til myndighetene i USA, er i praksis usikkerhetskomponenten i enhver risikovurdering av skytjenester levert av amerikanske selskaper så stor at den utelukker bruk av slike tjenester for noe annet enn åpne data, eller data hvor krypteringen er tilstrekkelig til at databehandler i praksis ikke har tilgang til ukrypterte data. Denne påstanden underbygges av ASPIRE-rapporten (A Study on the Prospects of the Internet for Research and Education) The Adoption of Cloud Services [? ]. Her påpekes forskjellene mellom europeisk og amerikansk regelverk og det advares mot å 35

36 skyve ansvaret for overholdelse av personvernlovgiving ut til enkelt-individer, noe som Narvik kommune i praksis har gjort ved å overlata til den enkelte ansatte å vurdere hva som er persondata. Rapporten påpeker videre den økte risikoen som en konsekvens virtualisering, tjenesteorientering og automatisering utgjør når dette fører til mindre kontroll på lokalisering av data. Surfnet i Nederland har bestilt en uavhengig rapport [? ] fra The Netherlands Institute for Information Law (IViR), en av verdens største forskningssentere på IT-lovgivning, for å belyse problemet med Patriot Act i forskning og høyere utdanning. Rapporten underbygger påstanden om usikkerheten om omfanget av generell datainnsamling i Amerikas Forente Stater. Den påpeker videre at det ikke kun er Patriot Act, men et helt sett av lover som er rotfestet i en generell forskjell mellom Amerikas Forente Stater og Europa med hensyn til kultur for overvåking. Denne kulturforskjellen kombinert med lettvint tilgang på overvåkingsmandater utgjør en stor forskjell i sannsynligheten for generell innsamling av informasjon hos selskaper som er basert i Amerikas Forente Stater og selskaper som er basert i Europa. Rapporten konkluderer med at nederlandske brukere som har data eksponert hos en Amerikansk skytjenesteleverandør har meget liten rettslig beskyttelse mot at vedkommendes data utleveres. Dersom data kun var tilgjengelig for Nederlandske aktører ville vedkommende hatt et sterkere vern pga. forskjellen i lov og rettspraksis mellom landene. 4.2 Integritet Dataintegritet handler om tryggheten på at data ikke er blitt endret på uatorisert vis. Risikoen for uatorisert endring av data øker, i likhet med konfidensialitet, med graden av eksponering. Bruk av offentlige skytjenester utgjør et kvantesprang med hensyn til eksponering av data, noe som i seg selv utgjør en økt risiko mht. integritet og konfidensialitet. Forskjellen på integritet og konfidensialitet er at integritet utgjør en risiko selv for åpne data. Selv for data som er klassifisert som åpne, er det viktig at endringer kun foregår på autorisert vis. Et eksempel vil være uatorisert endring av telefonnummer til ansatte i en bedrift, slik at telefoner som er tiltenkt en beslutningstaker blir omdirigert til en person som utgir seg for å være bedriftens person og kan gi falske opplysninger som tilsynelatende kommer fra bedriften. Man bør være bevisst på den økte risikoen for uautoriserte endringer som følge av bruk av offentlige skytjenester, og gjøre mottiltak for eksempel sjekksumming av data for å verifisere integritet. 4.3 Tilgjengelighet Det er åpenbart at det er flere avhengigheter involvert i å aksessere data som ligger offentlige skytjenester enn data som ligger nærmere brukerne og da særlig innenfor et høykapasitets og redundant NREN som UNINETT. Dette er viktig å ha med i risikovurderingen når man vurderer offentlige skytjenester. 36

37 ASPIRE-rapporten The Adoption of Cloud Services [? ] underbygger dette og konkluderer med at risikoen for utilgjengelighet som følge av nettverksbrudd er vesentlig mindre om en tjeneste er innenfor et NREN eller i NORDUnet enn om den ligger i en offentlig sky. Det er imidlertid flere faktorer som avgjør tilgjengelighet, blant annet redundans i forhold til datalagring og fysisk prosesseringskapasitet. På dette området kan en offentlig skytilbyder være bedre enn det man kan få til internt på institusjoner/nren på grunn av skalering og replikering over flere lokasjoner. Dette er noe som må vurderes i hvert enkelt tilfelle, men som også gjør arbeidet med selve vurderingen mer omfattende. Et annet aspekt som ved å ta ibruk offentlige skytjenester er at trafikken som går inn og ut av NRENs øker, noe som kan føre til økte kostnader til investering i kapasitet i tilkoblingspunkter mot Internet og eventuelt direkte om skyleverandøreres nett. Kostnad som er vanskelig å fastsette, men som er reell nok er såkalt exit-kostnad, det vil si kostnad ved å flytte tjenester vekk fra en skyleverandør. Her spiller aspekter som åpne standarder og dataformater en viktig rolle. Det finnes i tillegg eksempler på at leverandører underkommuniserer i hvilken grad standarder er støttet, og bruker merkelapper med støtte for åpne standarder mer som et innsalgsargument enn reell funksjonalitet. Dette utgjør kostnadsrisiko som fort kan bli større enn forventet og som det er knyttet usikkerhet til estimeringen av. Graden av observert og erfaringsmessig innlåsing hos de forskjellige leverandører bør bidra til å øke vurdert risiko i forhold til bruk av offentlige skytjenester og eventuell usikkerhet i vurderingen bør trekke i samme retning. 4.4 Teknisk sikkerhet Mange synes å ta for gitt at systemer er sikre dersom de kommuniserer over akseptert sikre forbindelser, typisk SSL 8 i Internet-verdenen. Forskning [? ] viser imidlertid at mange implementasjoner som benytter SSL har store mangler eller ikke gjør det man forventer i sin implementasjon av krypterte autentiserte forbindeleser. Det viser seg at det aller meste av verktøy som implementerer SSL-kode for sikring av kommunikasjon, med unntak av nettlesere, gjør dette på feil måte slik at man ikke sikres mot såkalt man-in-the-middle - angrep som man skulle forvente. Dersom man er sårbar for man-in-the-middle -angrep uten å vite det, fordi man benytter programvare som er for dårlig testet, øker sannsynligheten for faktiske angrep med nettverks-avstanden og antall aktører man passerer mellom sender og mottaker. Eksempelvis vil det være mindre eksponering innenfor et NREN, enn mot Amazon eller Google. I praksis vil man ofte stole på produkter eller programvare som har implementert SSL for sikring av trafikken siden SSL er de facto standard for kryptering på Internet. Forskningsarbeidet [? ] viser imidlertid at det er god grunn til å være føre var når det 8 Secure Socket Layer (SSL) - benyttes for kryptering og autentisering av nettforbindelser 37

38 gjelder kompleks krypterings-teknologi, og at implementasjoner i praksis testes for dårlig før de tas i bruk. SSL-kryptering er i tillegg den mest vanlige metoden for sikring av forbindelser mellom webtjenester i en tjenesteorientert arkitektur. Forskningsresultatene viser at det er nødvendig med grundigere testing av sikkerheten i webtjenester. 4.5 Klassifisering av data Så langt har vi snakket om risko som en funksjon av dataklassifisering, og tatt for gitt at data er klassifisert. Virkeligheten er imidlertid slik at det aller meste av data på institusjoner ikke er klassifisert, ihvertfall ikke på en konsistent måte og i henhold til lover og forskrifter. Det blir derfor vanskelig å avgjøre hvilke data som kan benyttes i offentlige skytjenester bare ved å vedta at data klassifisert som åpne kan eksponeres i slike tjenester. For å kunne beslutte dette må man foreta klassifiseringen slik at man konkret vet hva slags klasse den konkrete informasjonen befinner seg i. Men for å foreta klassifisering må man ha retningslinjer for å bestemme klasse, samt en prosess som sikrer at jobben blir gjort. Noen institusjoner har laget retningslinjer for klassifisering, men mangler prosesser for å sikre at så blir utført i henhold til retningslinjene. En del institusjoner mangler sågar retningslinjer for klassifisering. Konsekvensen er at det blir opp til den enkelte å avgjøre dette ut fra sin egen forståelse og kunnskap om personvernloven og offentlighetsloven. Kvaliteten på klassifiseringsarbeidet blir dermed veldig varierende. Korrekt klassifisering er en forutsetning for å vite om bestemte typer data er åpne eller begrenset, implisitt om de kan eksponeres i offentlige skytjenester eller ikke. Det er lite sannsynlig at regelverket for hvordan data skal klassifiseres er forskjellig mellom de forskjellige institusjonene. Det er derfor naturlig at det utarbeides et felles regelverk for UH-sektoren for hvordan klassifisering skal gjøres og hvilke kriterier som skal brukes. De enkelte institusjonene bør benytte dette felles regelverket i sine prosesser for å sikre at data blir klassifisert korrekt. Siden det er en forutsetning med riktig klassifisering av data i risikovurdering ved bruk/innkjøp av avtaler om offentlige skytjenester, er det i NANSens interesse å være pådriver for at et slikt felles regelverk blir etablert og tatt i bruk. Arbeid med etablering av et slikt regelverk er påbegynt av Sekreteriatet for Informasjonssikkerhet hos UNINETT [? ]. Det er derfor naturlig med et godt samarbeid mellom NANSen og sekretariatet med hensyn til innføring og vedlikehold av og samsvar med klassifiseringsreglene. 4.6 Konklusjon Vi argumenterer for at klassifisering av data er nødvendig for å ta stilling til hvorvidt data kan eksponeres i den offentlige skyen. Videre at det er sprikende og mangelfull 38

39 praksis når det gjelder klassifisering i sektoren. Vi påpeker behovet for et felles regelverk samt sikring av oppfølging ved institusjoners egne prosesser. Før et velfungerende system for klassifisering av data er på plass er det vanskelig, og forbundet med stor usikkerhet, å vurdere om konkrete data kan eksponeres i en offentlig skytjeneste. Etablering av et regelverk for klassifisering og sikring av oppfølging fra institusjoner bør være en høyt prioritert oppgave for NANSen på grunn av tidligere nevnte avhengigheter. Videre argumenterer vi for at, når data er klassifisert, er det kun data som har klassen offentlig/åpen som kan eksponeres i offentliger skytjenester såfremt data ikke er tilstrekkelig beskyttet med kryptering 9. Dette på grunn av stor usikkerhet i teknisk sikring av skytjenester, og at skytjenester levert av selskaper registrert i USA ikke kan garanterer for konfidensialitet på en måte som i praksis tilfredsstiller norsk lov. Klassifisering er ikke kun viktig ifm. valget om plassering av tjenester i offentlig sky, men er også viktig med hensyn til graden av nødvendig sikring i sektorens interne systemer. Det gjør arbeidet med risikovurdering mer håndgripelig og konkret i all IT-virksomhet, også den sektor- og institusjonsinterne. 9 Sterk kryptering hvor leverandør ikke besitter nøkkelen 39

40 5 Arkitektur I dette kapittelet tar vi for oss teknisk arkitektur. Vi presiserer at det ikke er snakk om en teknisk arkitektur for hele NANSen, men forskjellige arkitekturer avhengig av hvilke lag i verdikjeden man ser på. Eksempelvis vil det være egen arkitektur for lagring og egen arkitektur for virtuelle maskiner, selvom begge ligger innenfor tjenestemodellen Infrastructure as a Service. Virksomhetsarkitektur omtales i kapittel Generelle krav til arkitektur Før vi tar for oss spesielle arkitekturer og krav til disse går vi gjennom noen områder som går igjen som krav uavhengig av hvilke arkitekturer man jobber med. For noen tjenester er dette bare ønskelige krav, mens for andre er det absolutte krav. En av egenskapene NIST bruker for å definere skytjenester er at man betaler for det som brukes. For de tjenestene som settes opp med et ønske om slik finansiering er det viktig at tjenestene har mekanismer for å rapportere bruken på en slik måte at det kan brukes som grunnlag for fakturering. Vi vil i kapittel 7 gå nærmere inn på forslag til finansiering av NANSen Identitetsforvaltning En arkitekturmessig forutsetning for maksimal utnyttelse av både eksterne skytjenester og en felleskapssky er integrasjon med eksisterende systemer for identitsforvaltning (IDM). Det er både tilgang til selvbetjeningsportaler, selve tjenestene og adminstrasjonsgrensesnitt for tjenestene som integrasjonen med IDM-systemene skal støtte opp under. Det ligger en hel del forretningslogikk innbakt i institusjonenenes identitsforvaltningssystemer i form av blant annet organsiasjonstilhørighet og rolledefinisjoner. Denne informasjonen bør gjenbrukes og de nødvendige delene av den bør eksponeres mot skyarkitekturen slik at det kan lages overordnede policies for å styre tilganger. Når policies er knyttet til personers organisasjonsroller vil basis-privilegier for hva den enkelte har lov til å gjøre i en skyarkitektur være gitt av registrering i ansatt- og studentadministrasjonssystemer. Gjenbruk av informasjon på dette viset er den sikreste og mest effektive måten forbruke skytjenester på. Disse idèene er langt fra nye i sektoren. Cerebrum-prosjektet ved UiO [? ] og integrasjonen med blant andre SAP, FS, AD og LDAP er et godt eksempel på automatisk gjenbruk av iboende forretningslogikk til å styre tilganger og forpliktelser i IT-systemer. Et skyrammeverk bør ha sikre koblinger mot identitsforvaltningssystemene hos de forskjellige institusjonene. For å sikre kompabilitet og dermed størst mulig sannsynlighet for gjenbruk, bør det etableres standard SOA-type APIer mot disse systemene. 40

41 Det er rimelig å anta at mye av det arbeidet som er gjort i forbindelse med Feide, eduroam, UWAP [? ] og SURFConext [? ] kan gjenbrukes i integrasjonen med IDM-systemer som brukes av institusjonene i UH-sektoren, og dermed skape et godt fundament for velfungerende integrasjon mot nye tjenester i regi av NANSen Åpne standarder og standardiserte APIer For å sikre at implementasjonskostnaden ved tjenester så vel som skytjenesteoverbygg (eksempelvis selvbetjeningsportalen) blir så lav som mulig bør man undersøke marked/- community for eksisterende løsninger som har god støtte for åpne standarder og standardiserte API-er og autentiseringsmekanismer. oauth benyttes og støttes nå av flere av de aller største cloud-aktørene og har funksjonalitet og åpenhet som vil sikre interoperabilitet. oauth bør derfor være en sterk kandidat som autentiseringsprotokoll i etableringen av tjenester og selvbetjeningsportal og videre mot API-er ute hos institusjonene. 5.2 Sikkerhet Det å ta i bruke skytjenester i stor skala vil også si en stor grad av konsolidering av løsninger inn på de samme bakenforliggende systemene. Dette krever mer oppmerksomhet på sikkerheten i disse bakenforliggende systemene enn hvis alle tjenestene kjørte på separate, fysiske maskiner. Det samme gjelder når man konsoliderer flere brukere og organisasjoner inn i samme tjenesteinstanser (SaaS). Sterk separasjon mellom tjenester og instanser av tjenester er derfor viktig. Systemene som sørger for tilgangskontroll må være gode og ikke gi uvedkommende adgang til tjenester eller deler av tjenester de ikke skal ha tilgang til. Begrepet feature creep brukes om det at nye og utvidede funsjoner stadig innføres i løsninger/tjenester. Dette er vanlig i endel typiske skytjenester da utrullingen er enklere og raskere enn ved tradisjonell programvare. Ulemper kan være større risiko både kostnadmessig og sikkerhetsmessig. Kostnadsmessig fordi implikasjoner ved disse endringene kanskje kan medføre behov for endringer i andre tjenester/løsninger som er avhengige av tjenestene får nye og/eller endrede funksjoner (se kapittel 2.1.4). Sikkerhetsmessig er det ofte høyere risiko ved innføring av nye funksjoner eller utvidelse av eksisterende i en tjeneste. Ved bruk av eksterne leverandørers skytjenester som byggeklosser for viktige tjenester bør man vurdere å sjekke ut om leverandørene etterlever standarder som for eksempel PCI DSS 10, HIPAA 11 and SOX PCI DSS - properitær informasjonssikkerhetsstandard for bedrifter som håndterer opplysninger om blant annet kredittkort 11 HIPAA - Amerikansk standard som adresserer sikkerhet og personvern i forbindelse med helseopplysninger 12 SOX - Amerikansk lov som skal styrke internkontrollen over finansielle opplysninger i selskaper som 41

42 5.3 Felles tjenesteforvaltning ASPIRE-rapporten [? ] (se kapittel 2.2) nevner distribusjon som en av nøkkelkomponentene i leverandørhåndtering og skymegling. Dette kan være i form av en online -butikk for å vise tilgjengelige tjenester og gi brukerne muligheter for å anskaffe tjenestene. Arbeidsgruppen ser på dette som et utvidet tjenesteregister med autoritativ informasjon om tjenestene tilbudt av NANSen. Vi har ikke gått i detaljer på hvordan en slik løsning bør være bygget opp, men det blir viktig å lage en kravspesifikasjon før man begynner å lete etter passende løsninger. Viktige elementer er også her åpne standarder og standardiserte APIer for å kunne integreres både med sektorens identitsforvaltningssystemer eller APIer til disse. Arbeidsgruppen ser for seg at NANSens tjenester organiseres i en slik online -butikk eller en felles løsning for tjenesteforvaltning. Figur 2: Forslag til overordnet arkitektur Figur 2 forsøker å illustrere hvordan en felles løsning for tjenesteforvaltning har oversikt over alle tjenestene som tilbyes i NANSen og de forskjellige institusjonene som kan forbruke tjenester. Ikke alle forbrukere har tilgang til alle tjenester. Vi ser også av figur 2 at noen tjenester benytter andre tjenester som er mer fundamentale enn seg selv. Et eksempel i figuren er her at en samhandlingsplatform både bruker virtuelle maskiner som en IaaS-tjeneste og lagring som en annen IaaS-tjeneste. Jo mer fundamental en tjeneste er, jo flere andre tjenester kan gjenbruke denne tjenesten som en del av sin arkitektur. Det er da viktig at den er så elastisk og skalerbar som mulig. er omfattet av loven 42

43 5.3.1 Cloud Computing Management Platforms Cloud Computing Management Platform (CCMP) (se kapittel 2.1.6) er et samlebegrep for forretningsmessige og operative tjenester. IBM-CCRA [? ] tar hovedsakelig for seg frittstående skyløsninger, både private, community og public, og går ikke i dybden på totalforvaltning av helt forskjellige skytjenester. Arbeidsgruppen tror ikke det finnes et CCMP som vil dekke alle tjenestene som skal tilbys i NANSen, og at NANSen derfor må belage seg på å jobbe med flere paralelle CCMPer. Det er da ønskelig at det er mulig å integrere CCMPene med løsningen for felles tjenesteforvaltning beskrevet tidligere i kapittelet. Videre påpekes det i IBM-CCRA [? ] at det ikke finnes noen leverandører som er i stand til å levere et komplett ferdigpakket CCMP, men at det alltid vil være deler som må tilpasses og utvikles i hvert enekelt tilfelle. Det er derfor viktig å påse at valgt(e) CCMPer benytter åpne standarder og standardiserte APIer og fortrinnsvis er modulær med tanke på de forskjellige komponentene i et CCMP og samspillet mellom disse. Det å kunne bytte ut en komponent i et CCMP og som et eksempel bruke samme komponent for fakturering på tvers av forskjellige CCMPer vil kunne gi store gevinster for NANSen Selvbetjeningsportaler En selvbetjeningsportal er en sentral komponent i et CCMP. Det er derfor meget viktig at man tenker på interoperabilitet og fleksibilitet i valget av selvbetjeningsportal(er). Disse portalene bør ha integrasjon mot et felles tjenesteforvaltningssystem for å ha oversikt over hvilke institusjoner og hvilke brukere og/eller grupper som har hvilke rettigheter til bestilling og bruk av tjenestene som tilbys i portalen. 5.4 Arkitektur i lavere lag Spesielt for fundamentale tjenestene lengre ned i lagene er det viktig med åpne standarder og standardiserte APIer da disse tjenestene ofte er byggeklosser for andre tjenester i lagene over IaaS IaaS er som nevnt i kapittel fundamentale maskinressurser hvor man ofte kjører programvare eller lagrer data. Disse tjenestene brukes ofte som byggeklosser i PaaS- eller SaaS-tjenester. Virtuelle maskiner Det er idag et utbredt kommersielt tilbud for virtuelle maskiner i form av IaaS. Noen av disse har et åpent grensesnitt som tredjepartsleverandører har laget programvare for å styre (for eksempel Compatibleone og Deltacloud). Dermed kan 43

44 man sette opp et leverandøruavhengie grensenitt og til enhver tid tilby den mest optimale skytjenesten og kanskje da kunne plassere også med hensyn på kriterier som sikkerhet og kapasitet f.eks. Vi trenger å gjøre oss kjent med og evaluere disse tjenestene og programvaren så i en første fase er dette ikke aktuelt. Vi kan se for oss tre faser: 1. Avtale om et initielt IaaS hos en kommersiell leverandør 2. Bygge en UH-intern IaaS tjeneste 3. Forene disse med et virtualisert IaaS Figur 3: Hybrid skytjeneste Lagring Et godt eksempel på en hybrid skytjeneste som benytter seg av lagring i en offentlig sky (eller internt i en private- eller community-sky), men hvor selve tjenesten kjøres internt er TERENAs pilot-prosjekt Trusted Cloud Drive [? ]. Her kan selve dataene lagres i en eller flere forskjellige skyer og man har mulighet til å flytte data mellom skyer basert på policy. Som vi ser at figur 4 er gjøres selve datalagringen utenfor løsningen selv, og det spiller ingen rolle for tjenesten om den ligger på en lokal lagringsløsning eller hos for eksempel Amazon. Dataene som ligger ute i skyen er krypterte, mens metadataene er lagret sammen med tjenesten. Med en slik arkitektur kan man, gitt at krypteringen som brukes anses som god nok også legge data som er klassifisert på en slik måte at den normalt sett må plasseres i en privat- eller community-sky nå ligge i en offentlig sky. 44

45 Figur 4: Arkitektur for TERENA Trusted Cloud Drive Mange tjenester gjør som TERENA Trusted Cloud Drive og bruker WebDAV som protokoll mot lagring. WebDAV er en standard protokoll og fungerer kryssplattform, og de fleste applikasjoner støtter WebDAV. Men det er en stor forskjell på å bruke WebDAV direkte eller bare som bakenforliggende protokoll som bakes inn i en tjeneste/applikasjon hvor man må bruke denne spesifikke tjenesten/applikasjonen for å få tilgang til dataene (lock-in). Det vil derfor være å foretrekke de mest fleksible løsningene som tilbyr lagring over standard protokoller som eksempelvis WebDAV og hvor man har full fleksibilitet på å velge klient for å benytte seg av lagringen. 5.5 Hybride skytjenester Forskjellige skytjenester kan ha sterke elementer av leverandørlåsing som gjør at at man vanskelig kan bytte leverandør eller kombinere tjenester fra flere leverandører. Noen skyløsninger tilbyr åpne grensesnitt som gjør det mulig å bygge en metatjeneste på toppen av disse grensesnittene og i praksis gi en bruker en transparent aksess til en tjeneste, men ha mulighet til å styre fra hvilken leverandør eller løsning denne leveres. Denne muligheten for hybride tjenester ser man på forskjellige tjenester, men kanskje spesielt på tjenester i de lavere lagene. Dette kan brukes til styring av hvor dataene går ved at brukerene har et felles grensesnitt og så kan man plassere dataene etter klassifisering i en intern, felles eller ekstern sky. Dette kan dermed bli et verktøy for å hjelpe til med kontroll over informasjonssikkerheten, ved at dataene lagres og behandles på riktig sted utfra sin klassifisering. Integrere on-premise-tjenester med offentlige skytjenester Det kan av forskjellige grunner være ønskelig å benytte leverandører av offentlige skytjenester for deler av dataene man skal behandle i en tjeneste. Andre deler av dataene er ikke klassifisert slik 45

46 at de kan behandles i en offentlig sky og må derfor behandles i en privat- eller communitybasert sky internt i sektoren. Noen tjenester man kan kjøpe av i de offentlig tilgjengelige skyene kan også drives onpremise, det vil si at man har mulighet til å kjøre tilsvarende tjeneste på ressurser internt i en organisasjon eller internt i sektoren. En hybrid variant av dette vil være å bruke både offentlige skytjenester og tilsvarende on-premise-tjenester internt med mulighet for å flytte data inn og ut basert på definerte policies. 5.6 Utvikling av tjenester Det foregår endel utvikling (les: programmering) av egne tjenester i sektoren. Flere av disse løsningene vil det være ønskelig å kunne tilby til flere enn en organisasjon, eller man ønsker av andre grunner å rulle disse ut ved hjelp av komponenter i en skyløsning (IaaS eller PaaS). Det vil i de fleste tilfeller da kreves endel omskriving for å få tilpasset løsningene så de får de egenskaper som er definert av blant annet NIST for skytjenester (se kapittel Det vil være forskjellige krav til arkitektur avhengig av hvilken tjenestemodell man ønsker å bruke for utrulling av applikasjonen. Hvis man benytter IaaS til å deploye applikasjoner kan man ofte fortsette nesten som idag, mens hvis man skal bygge en SaaS-applikasjon som skal leve i skyen blir det helt nye måter å bruke ressurser på (veldig ofte API-baserte). Eksempelvis får ikke SaaS-applikasjoner tilgang til interne tjenester og databaser, men må benytte seg av integrasjonsprotokoller eller APIer for tilgang til disse dataene. Disse protokollene er gjerne basert på REST, SOAP eller JSON over HTTP(s). Fordeler ved å benytte åpne standarder og standardiserte protokoller applikasjonene er at man får fleksibilitet og kan kjøre applikasjonen uavhengig av leverandør av de underliggende skytjenestene. Utvikling kan for eksempel gjøres med ressurser hos Rackspace eller Amazon, mens produksjon kanskje må kjøres internt i UH-sektoren på grunn av klassifiseringen på data som applikasjonen behandler. Det viktige er at utviklerne er oppmerksomme på forskjellene på å skrive tradisjonelle applikasjoner og å utvikle som en del av skyen, og jobber med å utnytte de nye mulighetene som ligger i skyteknologien Databaser Tradisjonelle relasjonsdatabaser passer ikke så godt inn i SaaS-applikasjoner som lever i skyen. De er ofte ikke elastiske og skalerer ikke så godt, derfor har de siste årene sett andre alternativer til tradisjonelle relasjonsdatabaser vokse frem. Disse går under betegnelsen NoSQL-databaser og eksempler er Apache Cassandra, CouchDB and MongoDB. Typiske IaaS-, PaaS- og SaaS-leverandører leverer også det de kaller DbaaS (Database as a Service) som gjerne er API-baserte. 46

47 5.7 Høytilgjengelighet Påliteligheten til skytjenester må vurderes nøye i forhold til det behov man har. Det er ikke gitt at man har backup av dataene hvis lagringsmaskinen(e) i skyen feiler eller at data repliseres automatisk slik at de er umiddelbart tilgjengelig når noe feiler. Man må derfor regne med tiltak for å skaffe høy nok pålitelighet inn prisen for en gitt skytjeneste. Den skalerbare teknologien som nå er tilgjengelig for å bygge skytjenester gjør det også mulig å replisere og migrere data mellom maskiner og installasjoner på en fleksibel og automatisk måte som vil tillate at man alltid kan ha tilgjengelig en kopi av dataene hvis primærlageret feiler. Dette gjør at det mulig å tilby høypålitelige tjenester som fortsetter uavhengig av at enkeltkomponenter eller til og med hele installasjoner går ned hvis det er kopier av data og kode andre steder. Det gjør at denne teknologien kan dekke mye av behovet for backupsentre. Man vil selvsagt kunne miste data i det et system rammes, men da er et viktig at transaksjonene er robuste og kan restartes et annet sted. Hvis vi innfører denne teknologien i en UH-sky kan vi få alle disse egenskapene og dette vil ikke bare komme brukerne til gode. Det vil også påvirke utviklingsmiljøet og vil gi mye gratis med replikering og lastfordeling, men det vil koste litt i robustifisering av transaksjoner for omstart og ryddighet i oppdateringer. I forbindelse med skyteknologi har man fått en ny måte å tenke disaster recovery på, man tenker heller at det ikke er ønskelig med noen failover til sekundær-site, men at applikasjonene skal fortsette å kjøre selvom en av datasentrene den bruker ressurser i skulle gå ned. På driftssiden vil dette kunne føre til et mindre krevende driftsmiljø, siden feilende komponenter kan byttes ved leilighet og omlegginger kan gjennomføres i arbeidstiden. Skaleringen gjør at man trenger færre til å gjøre operative grep og kan overføre mer til utvikling av moderne systemer. UNINETT har demonstrert flere eksempler på slike høypålitelige systemer blant annet for FEIDE og UNINETT Sanntid. Se mer om dette i vedlegg A. Vi har stor tro på at det kan være verdt å satse mot et slik framtidig driftsmiljø for sektorens felles og gjerne spesifikke applikasjoner. Dette kan da kombineres med webteknologi som [? ] som har med fellesfunksjoner for felles data utover FEIDE og muligjør mer avanserte og integrerte applikasjoner enklere. 47

48 6 Tjenester i regi av et NANSen En rekke kommersielle skytjenesteleverandører tilbyr i dag sine tjenester i markedet. Tjenestene er attraktive for studenter og ansatte i UH-sektoren og er allerede tatt i bruk i vesentlig grad, både på privat basis og gjennom at intitusjonene har inngått egne avtaler om kjøp av offentlige skytjenester. Microsoft og Google tilbyr løsninger som er spesielt interessante for studentene, med pakkeløsninger som blant annet inkluderer e-post, samhandlingsverktøy, lagring med mer. Dette er løsninger som utvilsomt er etterspurte og som de færreste IT-avdelinger i dag er i stand til å levere alene. Brukerne «våre» er opptatt av tilgjengelighet til sine data, fra hvor som helst og fra alle typer enheter, og benytter i stadig mindre grad det tradisjonelle hjemmeområdet sitt som IT-avdelingene tilbyr og som ofte er vanskelig å nå. NANSen bør i første omgang etablere og ha en slags skymeglerrolle som forhandler frem gunstige avtaler på vegne av sektoren. NANSen vil på vegne av sektoren kunne koordinere og sikre et godt samarbeid omkring slike anskaffelser og vil her kunne oppnå gode avtaler og priser på grunn av storskala-fordeler. NANSen vil også kunne assistere institusjonene med hendhold til rådgivning rundt bruk av slike tjenester, klassifisering av data, sikkerhet, jus og databehandleravtaler. Markedet endres kontinuerlig i form av nye aktører, nye tjenester og ny funksjonalitet, og det vil være viktig å ha en god oversikt over hva som finnes og hva som kommer av tjenester og funksjonalitet. NANSen bør ha en prosess som overvåker markedet, og som har oversikt over markedets muligheter og begrensninger. Samtidig blir det viktig med god kontakt med institusjonene, slik at en kan tilby og levere tjenester som etterspørres. Det bør etableres en tjenestekatalog, med oversikt over hva som finnes av tjenester og hva som vurderes/er under anskaffelse. Etablerte tjenester må synligjøres og markedsføres godt overfor institusjonene. 6.1 Generelle økonomiske aspekter ved skytjenester Som regel er det en inntektsmessig sammenheng mellom antall sluttbrukere til en SaaS og deres aktivitet. Hvis man for eksempel driver en nettbutikk vil økt aktivitet i nettbutikken som regel være et tegn på økt omsetning og dermed økte inntekter. Dersom butikkene ikke er skalert ihht. til aktiviteten opplever kunder dårlige responstider og lav kvalitet på tjenesten. Forretningsmessig er det derfor meget fordelaktig for operatører av slike tjenester at kostnadene ved å levere tjenestene følger variasjonene i inntekt. Man betaler for det minimum av ressurser som er nødvendig for å levere en god tjeneste til sine brukere samtidig som man sikrer maksimal inntjening under perioder med høy aktivitet ford ressursene er elastiske. Denne måten å operere på eliminerer investeringskostnader og sikrer at kostnadene aldri overstiger inntektene forutsatt en effektiv implementasjon. De som implementerer og leverer ressurser (IaaS) som en tjeneste eliminerer investeringskostnaden til sine kunder ved sin leveranse. IaaS-leverandøren investerer på sin side i fysisk infrastruktur og får dermed selv en viss investeringskostnad. IaaS-leverandørens 48

49 strategi er å påta seg risiko ved investering i infrastruktur og holde sine egne kostnader nede ved strategiske storinnkjøp av maskinvare, massiv konsolidering av ressurser og effektive metoder for logistikk (automatisering, standardisering osv.) Slik konsolidering og oppskalering av leveransen er en forutsetning for å få ned kostnadene tilstrekkelig for å være konkurransedyktig. Det er viktig å merke seg at begrepet konsolidering her ikke nødvendigvis er ensbetydende med fysisk samlokalisering av fysisk IT-infrastruktur. I mange tilfelle vil distribuering av infrastruktur være å foretrekke, men at metodikk, innkjøp, implementasjon og utfasing utføres på en koordinert (konsolidert) måte. 6.2 ecampus tjenester og andre felles IT-løsninger i sektoren Uninett har i senere tid, spesielt gjennom ecampus programmet etablert og fått på plass flere tjenester/verktøy innenfor sektoren som Adobe Connect (Pc basert videokonferanse/samhandlingsverktøy), MediaSite(opptak av video), Camtasia og CloudStore. Etablering av slike felles sektorbaserte tjenester har innefor disse områdene vært nyttig og besparende for hver enkelt institusjon. Tjenestene driftes i dag gjennom ecampus programmet (5-årig), og det vil etterhvert bli nødvendig i finne gode løsninger for finansiering, drift, videreutvikling, vedlikehold osv. av disse og eventuelt andre tjenester som opprettes og etableres på samme måte. NANSen kan være overordnet porteføljeforvalter for alle slike fellestjenester på dette nivået. I forbindelse med en eventuell etablering av NANSen vil det være naturlig å starte med å se på hvordan NANSen kan løse disse utfordringene, og skape en felles plattform og et rammeverk for drift, vedlikehold og videreutvikling av allerede etablerte sektorbaserte IT-tjenester. NANSen bør også tilrettelegge for, og oppfordre til deling i de tilfeller der det finnes tjenester på institusjonsnivå som kan tilbys/deles med andre i sektoren. Dette han være alt fra egenutviklede tjenester/løsninger som kan videreutvikles til nasjonale tjenester, til lagring, backup, virtualiseringstjenester ol. som kan tilbys gjennom NANSen. 6.3 Integrasjon For å kunne etablere gode løsninger bør tjenester som legges inn under NANSen kunne integreres med andre tjenester det er naturlig å integrere med. For å sikre at implementasjonskostnadene ved innføring av tjenester blir så lav som mulig blir det derfor viktig at disse har god støtte for åpne standarder, API-er og autentiseringsmekanismer. Som et minimumskrav må tjenestene kunne integreres med FEIDE. NANSen bør tilby en integrasjonstjeneste /inneha integrasjonskompetanse for applikasjoner og tjenester som tas i bruk innenfor sektoren. 49

50 6.4 Forslag til tjenestetyper Arbeidsgruppen definerer her tjenester veldig vidt, noe som på sikt vil kunne omfatte alt fra infrastrukturkomponenter (IaaS), til PaaS og SaaS. På kort sikt mener arbeidsgruppen det er viktig å få på plass avtaler rundt tjenester/ modne frukter som etterspørres innenfor sektoren. Det er i dag stor etterspørsel etter samhandlingsverktøy og enkle, lett tilgjengelige skybaserte lagringstjenester som gjør det mulig å dele data med andre. Noen eksempler på slike tjenester er Dropbox, Box, Skydrive, Microsoft Office 365 og Google Apps. Mange av institusjonene innenfor sektoren har allerede etablert eller holder på med å etablere slike tjenester fra det offentlige skytjenestemarkedet. NANSen vil her kunne spille en viktig rolle mht til å få på plass gode avtaler og løsninger for sektoren. Det er også viktig å sjekke ut muligheter for on premise behandling av data og avklaring av leverandørers tilgang til data, da dette er av betydning for hvilken type data disse tjenestene kan benyttes til. I et langsiktig perspektiv bør NANSen kunne omhandle alle felles IT tjenester innenfor sektoren, samt tjenester som i dag leveres av de ulike Uninett-selskapene og deres utlysing av utviklings- og drifts-oppdrag til institusjoner. Eksempler på slike tjenester er Bibsys, FS, CRIStin, FEIDE, eduroam. I tillegg kommer videotjenestene (nevnt over) som i dag ligger under ecampus prosjektet. Etter hvert som disse fases inn under NANSen bør de tilpasses skyen slik at de på sikt kan tilbys gjennom en eventuell egen felles akademisk skytjeneste (NANSen). En forutsetning for at eksisterende fellestjenester i sektoren skal kunne leveres i form av skytjenester er imidlertid at det etableres en elastisk basis-infrastruktur for dette i form av IaaS, og muligens også PaaS Skylagring Lagring av data er essensielt i enhver IT-infrastruktur. Måten data lagres og presenteres på varierer med brukere og systemers behov i forhold til tilgjengelighet, redundans, og ytelse. I en skyinfrastruktur presenteres de grunnlegende lagringsressursene via standardiserte programgrensesnitt (API er), noe som gjør det mulig å styre lagringsmengde,lokalisering og kvalitetsnivå vha. forhåndsefinerte regler. Dette er en sentral egenskap som understøtter skyleveransemodellen mht. automatisk skalering og elastisitet. Implementasjonen til de underliggene fysiske lagringsressursene (disk, tape, osv. ) varierer, men skaleringskrav og økende kostnadspress har resultert i økende bruke av distribuerte løsninger som nyttigjør seg standard PC-baserte tjenere med billig disk hvor redundans og konsistensjekking ofte løses i intelligent styringsprogramvare som ligger mellom presentasjonslaget og det fysiske laget. Det har vist seg at presentasjon av billig lagring vha. relativt enkle grensesnitt har en veldig høy gjenbruksverdi både når det gjelder lagring av virtuelle maskiner og lagring av applikasjons- og brukerdata. Programgrensesnittene gjør det mulig for applikasjoner/saastjenester å automatisk skalere opp (og ned) lagringsressurser i bakkant etterhvert som bruksmønsteret inn mot tjenesten endrer seg. 50

51 Hovedbegrunnelsen for å etablere en skylagringsinfrastruktur innenfor UNINETT, Nordunet evt. Geant vil være at det muligjør lagring av data som sikkerhetsmessig er utelukket å plassere i en offentlig sky 4.6. Med den allerede eksisterende nett-infrastrukturen med høy kapasitet og lav responstid, er det likevel ikke umulig at en UH-intern skylagringstjeneste på sikt kan bli konkurransedyktig også på kostnad. Dette gjelder særlig dersom man får til et nordisk eller europeisk samarbeid. Et annet argument for å etablere en UH-intern skylagringstjeneste er at det er en sentral forutsetning for å muligjøre leveranse av eksisterende fellestjenester etter skymetoden. Det finnes flere eksempler på gode fellestjenester som leveres i sektoren i dag, som kan bli enda bedre og mer effektive dersom de leveres på en mer elastisk og fleksibel måte (skymetoden). Viktige egenskaper ved lagring er sikkerhet mot feilende komponenter og repliserende lagring. Graden av redundans avhenger av behovet for tilgjengelighet Virtuelle maskiner (operativsystemer) Sammen med lagring og nettverk utgjør virtuelle maskiner (VM er) IaaS. Et komplett IaaS-tilbud forutsetter derfor et rammeverk for livsløpshåndtering av virtuelle maskiner. For å være til nytte trenger VM er nettverkstilkobling og lagring. For at infrastrukturen skal være effektiv er det også nødvendig med stor grad av delegering av myndighet til å opprette maskiner samt automatikk som abstraherer kompleksiteten i infrastrukturen å presenterer ressurser på rett måte. Lagring som understøtter VM er kan gjerne være tidligere nevnte skylagringstjenester. Dette muligjør størst grad av automatisering og standardisering i provisjoneringsprosessen av VM er. I tillegg er det nødvendig med en virtuell nettverksinfrastruktur slik at provisjoneringsprosessene også kan foreta riktig nettverkstilkobling uten manuell medvirkning. Det vil være nødvendig med en hel del utvikling for å etablere en slik infrastruktur av VM er, men mengden nødvendig utvinkling vil kunne reduseres med stratigiske valg av basis-plattform. Det finnes mange plattformer å velge imellom med varierende grad av leverandørstøtte, åpenhet og iboende muligheter. Arbeidsgruppen har hatt for kort tid på seg til å kunne vurdere konkrete rammeverk opp mot hverandre, men det er viktig å bruk litt tid på denne vurderingen da det kan spare inn mye på senere utviklingskostnader og vedlikeholdskostnader. Flere av rammeverkene inneholder også infrastrukturkomponenter for lagring og nett som skytjenester og utgjør dermed i varierende grad komplette IaaS-systemer. Vurdering og valg av produkter/prosjekter for de forskjellige IaaS komponentene bør være høyt på prioriteringslista i det videre arbeidet til NANSen Personlig lagring Personlig lagring har nå mange kommersielle løsninger i nettskyen. Disse gir transparent aksess til data fra smartelefoner, nettbrett og PC er. Fellesløsninger for sektoren bør være organisasjonsorinterte og støtte deling i grupper og organisasjoner og helst mellom organisasjoner for samarbeid. 51

52 Personlig lagring i denne sammenheng er som regel tett knyttet til den aktuelle SaaS (Google, Facebook etc.), men kan også være at SaaS en er en ren personlig lagringstjeneste som for eksempel DropBox. En undersøkelse av trafikk nordafjells i UNINETT med netflow viste at de Google Drive hadde fleste aktive IP-adresser(86143), fulgt av Dropbox med 36480, mens box.net hadde 423. For Google sin del er det rimelig å anta at mye av trafikken forårsakes av studenter og ansattes private bruk av gmail, gcalender osv., noe som i prinsippet er helt greit. Når det gjelder DropBox er det grunn til å være noe mere skeptisk til bruksområdet. Det er umulig å si noe om fordelingen mellom ansatte og studenter ut fra tallene over. Det er naturligvis også umulig å si om det som lagres i DropBox av den enkelte ansatte er i tråd med IT-sikkerhetsforskriftene (dersom slike finnes for bruk av skytjenester). Vi tror at UH-sektoren har en jobb å gjøre både i forhold til etablering av regler/policy for bruk av skytjenester og effektiv kommunikasjon av disse. Det er samtidig viktig med en åpen dialog om behovene slik at disse kan dekkes på den mest kostnadseffektive måten uten å gå på bekostning av sikkerhet. Tallene over og signaler som har kommet inn til arbeidsgruppen tyder på at det er et reelt behov for den typen funksjonalitet som DropBox tilbyr. Enkelte av institusjonene vurderer derfor å kjøpe inn slike tjenester fra box.com som hevder å være et tilsvarende, men sikrere produkt rettet mer mot virksomheter enn privatpersoner. Vi tror det er lurt at institusjonene først og fremst sikrer seg mot at data kommer på avveie, tukling med data og tap av data ved etablering av regler og tydelig kommunikasjon av disse og at risikovurdering og eventuelt fellesinnkjøp av tjenester fra box.com eller andre overlates til NANSen. På den måten sikres det best mulige betingelser for innkjøpet og en faglig godt begrunnet risikovurdering av produktet og anbefaling av egnet bruksområde. Forutsetningen er naturligvis en vellykket etablering av NANSen i tråd med anbefalingene fra arbeidsgruppen. Dette kan ta noe tid og det kan være fristende å gjøre innkjøp som løser behov på kort sikt. Risikoen er likvel at data kommer på avveie og man må drive brannslukking og skadebegrensning istedenfor proaktiv planlegging for å unngå at dette inntreffer. Et annet aspekt er at dersom det uansett er et behov for en intern løsning for noen data (slik vi forutsetter), vil innkjøp av en tjeneste som kun kan inneholde et subsett av sektorens data-klasser føre til at brukere må forholde seg til to systemer. Brukerne må selv ta stilling til hva som kan ligge hvor på individuell basis. Dette er ikke særlig brukervennlig. Om man implementerer en løsning internt har man kontroll på hvordan data lagres i bakkant, og man kan lage automatikk for plassering av data i UH-intern sky eller offentlig sky basert på forhåndsdefinerte regler og klassifisering. Slikt vil antagelig være vanskeligere i en ferdigkjøpt løsning med begrensede muligheter. 52

53 6.4.4 Webapplikasjonsrammeverk Tjenester i sektoren og ellers i IT-industrien er ofte sammensatt av et sett av webtjenester i en tjenesteorientert arkitektur. I forbindelse med skytjenester er det i følge IBM CCRA 2.1 en viktig forutsetning at skytjenestene leveres som og ved hjelp av en tjenesteorientert arkitektur. En viktig byggekloss i en tjenesteorientert arkitektur er ett eller flere applikasjonsrammeverk med støtte for å bygge standardiserte web-tjenester på en modulær måte. Eksempelvis: Spring/Java/tomcat/jboss-seam Ruby on Rails Asp.Net Django (python-basert) Mojolicius/Dancer/Mason (perl basert) Slike rammeverk kan bakes inn i IaaS en og leveres som en PaaS. Slik pakking og standardisert provisjonering av web-applikasjonsrammeverk. Vil gjøre det mulig/lettere å flytte eksisterende tjenester over til en skyleveransemodell. Det vil også forenkle utvikling av nye tjenester i sektoren og videreutvikling av eksisterende tjenester. UNINETT webapp-farm [? ] er en interessant demonstrasjon på hvilke muligheter som ligger i kombinasjonen PaaS/IaaS for rask utvikling av nye tjenester og enkel gjenbruk av autentisering og autoriseingsmekanasmer. Surfconext [? ], et initiativ fra Nederlanske Surfnet, er et annet eksempel hvor det allerede er etablert fungerende samarbeidsverktøy ved bruk av PaaS og integrasjon med sektorens eksisterende autentiseringssystemer. Det vil være være i NANSens interesse å etablere et tett samarbeid med disse fagmiljøene med hensyn på gjenbruk av metode, kode og samordnet/føderert leveranse av tjenester Digital eksamen Flere av sektorens institusjoner har tanker om, eller har startet aktiviteter relatert til, digital eksamen. Et administrativt system for avvikling av digital eksamen er et eksempel på en tjeneste som alle institusjoner vil ha nytte av, og hvor det er naturlig å konsolidere innsatsen med etablering og vedlikehold i NANSen. Et slikt system må kunne håndterere hele eksamensprosessen digitalt, dvs. alt fra planlegging, administrasjon, utlevering av oppgaver, innlevering av besvarelse, tilgang til eksterne sensorer, digital sensur/retting, eksamensprotokoll osv. Et slikt system må også være tett 53

54 integrert med studieadministrative system(fs) slik at man unngår dobbeltarbeid, dvs. det som settes opp i FS rundt eksamen må flyte over i systemet for eksamen og omvendt. Det hersker liten tvil om at dagens eksamensform, skoleeksamen med penn og papir må erstattes med alternative digitale eksamesformer der dette er mulig. I vårt naboland Dannmark har de gjort dette, der er ca. 90% av alle eksamener digitale innleveringer i en eller annen form, de resterende 10% er skoleeksamener, skriftlig og muntlig. Ved Universitetet i Århus er det de siste årene utviklet et system som håndterer hele eksamenssprosessen fra A-Å digitalt. Systemet heter Wiseflow, tidligere DigEx. Vi tror det vil være store kostnadsbesparelser ved å konsolidere innsatsen med digital eksamen inn i NANSen for å unngå dobbeltarbeid på institusjonene med aktiviteter som er av alles interesse LMS-system I dag domineres leveransen av LMS 13 -systemer av Fronter og itslearning. Arbeidsgruppen lurer på om det kan være vel verdt å undersøke muligheten for å levere LMS som en skytjeneste i regi av NANSen. Det kan tenkes at det å drive en slik tjeneste selv vil være mer kostnadseffektive og gi vesentlig bedre integrering mot andre systemer enn hva vi får idag. Det finnes en rekke fri programvare-alternativer som med moderate mengder tilpasning kan fylle LMS-behovet. Moodle [? ] er det mest brukte rammeverket, men det finnes flere alternativer. Implementert på en elastisk IaaS/PaaS kan det tenkes at det kan skapes en god og skalerbar løsning som kan vedlikeholdes mer kostnadseffektivt enn ved innkjøp fra LMS-leverandører Backup En UH-intern IaaS kan danne fundament for en nettbasert backup-tjeneste forutsatt at det anskaffes og/eller utvikles en backup-saas som benytter virtuelle maskiner, skylagring og nett på en smart måte. En sentral backup-tjeneste er allerede etterspurt i sektoren, men behovet for backup endrer seg også etterhvert som lagringsløsninger har innebygget snapshot og replikeringsfunksjonalitet Arkivering Arkivering kan være en interessant tjeneste som innbefatter metadata-lager og lagring av selv dataene. Vi snakker da om langtidslagring av data med veldig lav kostnad. Amazon tilbyr nå slik lagring i form av sin Glacier-tjenester. Det er ikke urealistisk at UH-sektoren kan tilby tilsvarende tjeneste for eksempel ved å integrere tape-bibloteker som fysisk lagring bak deler av skylagringen. 13 Learning Management System 54

55 6.5 Etablere egne skytjenester Kjøp av tjenester (som for eksempel box.com) kan være en god løsning på kort sikt, men vil ofte innebære låsing av funksjonalitet til det som leverandøren til enhver tid tilbyr. I tillegg kan det være risiko for innlåsing av data ved bruk av proprietære eller pseudo-åpne dataformater og protokoller. Det er derfor viktig at så snart NANSen er etablert som en koordinerende organisatorisk enhet, bør enheten initiere arbeid med mål om opprettelse av en UH-intern IaaS sky. Mulighetene dette skaper er omtalt i tidligere kapitler. I tillegg er det en viktig forutsetning for å kunne starte bygging av skalerbare og elastiske SaaS er selv eksempelvis en tjeneste av samme type som box.com leverer, men med full fleksibilitet og mulighet for styring av data-plassering for alle klasser av data innenfor samme system. 6.6 Oppsummering Sektoren har allerede mange felles IT tjenester som vi i dag er driftet, finansiert og organisert på ulike måter. Samtidig oversvømmes markedet med nye delvis konkurrenrende offentlige skytjenester som er attraktive for brukerne våre. Brukere begynner å ta disse i bruk på privat basis, og enkelte institusjoner har eller er i ferd med å inngå egne avtaler med hendhold til bruk av disse. Arbeidsgruppen mener derfor det er viktig at man innenfor UH-sektoren på kort sikt: får etablert en portefølgestyring får på plass avtaler med aktuelle offentlige skytjenesteleverandører får etablert en tjeneste som følger med på og overvåker markedet På mellomlang til lengere sikt (men planlegging bør starte allerede nå): etablere en UH-intern IaaS/PaaS Tilpasse eksisterende tjenester til skyen (UH-IaaS/PaaS) Vurdere utvikling av nye egne skytjenester: Digital eksamen, LMS, Samarbeidsløsnigner etc. Se på muligheten for hybridløsninger, med for eksempel offentlige skytjenester som lagrer sine data hos oss. 55

56 7 Organisering og finansiering av NANSen I dette kapittelet kommer vi med innspill på hvordan UH-sektoren kan organisere og finansiere skytjenester. UH-Sektoren må ta i bruk skytjenester på for å kunne tilby moderne og kostnadseffektive tjenester. Etablering av en organisasjon som skal levere skytjenester en klar utfordring, det er mange behov som skal tilfredsstilles, og det krever nye leveransemodeller. I UH-sektoren er det lang tradisjon for at en gjør ting i fellesskap. Det er mange gode eksempler på dette, og UNINETT har vært sentral i mange av disse samarbeidene. Derfor har de laget en beste praksis [? ] for å jobbe med kundefinansierte prosjekt, som vi mener at en bør kunne basere organisasjonene til NANSen på. Her er det også modeller for finansiering som NANSen bør kunne benytte, men det må tilpasses til leveranse av skytjenester. UNINETT-modellen legger vekt på at samarbeidet er kundedrevet, dette også er meget viktig i NANSen sammenheng. Dette sikres gjennom at institusjonenes behov og krav er styrende for beslutningene som gjøres i alle faser. Videre etableres det styringsgrupper for prosjektene, som koordinerer med arkitekturåd og andre premissgivere i sektoren. I forvaltningsfasen koordineres arbeidet av et prioriterings råd. Modellen bør også implementeres i en NANSen organisasjon. Når en ser på kompleksitetene i skytjenester (se kapitlene 4 og 5), ser en at alle i UHsektoren trenger å hjelpe hverandre. Det er mange fallgruver, og mye arbeid som må gjøres. NANSen må ta mål av seg å være kompetansesenteret for skytjenester i UH-sektoren. Dette betyr at NANSen må ha bred og god kompetanse på syktjenester og omkringliggende felt. Nansen bør ta en rolle som skymegler, se kapittel 2.2. Dette er en oppgave som ingen i UH-sektoren har tatt på seg tidligere og er naturlig at en sentraliserer for UH-sektoren. Ut i fra diskusjonene tidligere i rapporten ser vi for oss at NANSen starter opp med følgende aktiviteter: 1. Megler av skytjenester Porteføljestyringen er en vesentlig del av dette arbeidet 2. Rådgiving med hensyn på klassifisering av data/informasjon 3. Kartlegge mulig IaaS tjeneste som benytter seg av tjenester i forskningsnettet og en eventuell felleskapssky for å skape nye tjenester Som en ser av figuren over må institusjonene og NANSen å jobbe tett sammen. Det må bli nye samarbeidsmåter i sektoren. NANSen må levere komplette løsninger som institusjonenes IT avdelinger må implementere og integrere. Denne type av organisasjon blir en hybrid IT organisasjon, hvor NANSen og institusjonenes IT avdelinger blir ansvarlig sammen om leveransene. 56

57 Figur 5: Plassering av skymegler rollen sammen med institusjonenes IT avdelinger 7.1 Kompetanse NANSen bør ha Skytjenestene er komplekse og det vil komme krav om integrasjon mellom interne systemer og eksterne skytjenester. Kompetanse som kreves for å lykkes med integrasjon er omfattende. Det meste av kompetansen finnes i sektoren men den er spredt på mange institusjoner. Kompetansebehov for å starte opp er: Porteføljestyring Salg og markedsføring Leverandør av tenester Integrasjon av tjenester Prosess (ITIL, TOAF) Interasjonal og nasjonal juridisk kompetanse Innkjøp Informasjons-sikkerhet/policy Endringskompetanse Programvare utviklings kompetanse Infrastruktur kompetanse (NB ikke bare nett, men serverdrift etc) 57

58 7.2 Forslag til organisering av NANSen Kompetanse-behovene i NANSen kan ikke løses i en statisk organisasjon. NANSen må ha samme krav til elastisitet i organisasjonen som skytjenester har til elastistet for leveranse av tjenester. Det er helt klart at NANSen bør ha en ansatt leder med ett sekretariat. Fagkompetansen for å få NANSen opp å stå, må i stor grad komme fra sektoren. Gruppen ser for seg at en kan organisere en del av behovet for kompetanse i faggrupper fra sektoren. NANSen må definere hvilke faggrupper det er behov for, og så får institusjonene i sektoren tilordne ressurser til gruppene. Disse gruppene kan jobbe med spesialiserte felt. Ta for eksempel feltet rundt lovgiving. Lovene er meget komplekse (se kapittel 4.6). Det er viktig å at sektoren har kompetanse på juss rundt skytjenester. Lovene rundt personvern og informasjonsikkerhet er for eksempel styrt fra det landet hvor dataene laget ( Eksempel USA PATRIOT Act). Det betyr at det ikke er nok å ha kun kunnskap om Norsk lovgiving. Lager en da en faggruppe av jurister som har som fokus på lovgiving rundt skytjenester nasjonalt og internasjonalt, kan denne kompetansens også brukes utenfor UH-sektoren. Faggruppene kan lage anbefalinger for sektoren, slik som det er gjort for nettverk og datarom Forslag til faggrupper Når en setter sammen faggrupper er det viktig at det ikke er noen får institusjoner som stiller med alt personellet. Alle institusjoner bør bidra. Det er også viktig at en finner en god måte å kreditere arbeidet på. Det er viktig at institusjonene ser på dette som utviklende for de ansatte. Har sektoren slike faggrupper er det også enklere å få kontakt å kunne bidra på i ett europeisk nivå (eksempel TERENA). Dette er en måte for de ansatte å utvikle seg faglig på, til det beste for institusjonene en arbeider på, og for hele UH-sektoren. Det er også viktig å benytte de organene som allerede er i sektoren. Som for eksempel Sekretariatet for informasjonssikkerhet og IKT-arkitekturråd for norske universiteter og høgskoler med flere. Hvilke faggrupper kan en da se for seg: Nye skytjenester Juss og sikkerhet Skyarkitektur/skyinfrastruktur Felleskapssky Viritualisering Porteføljestyring Infrastruktur som en tjeneste (IaaS) Platform som en tjeneste (SaaS) med flere 58

59 7.3 Forhold til institusjoner i sektoren For å lykkes med prosjektet NANSen er det meget viktig at samarbeidet med institusjonene er meget godt. Tjenestene som leveres krever profesjonalitet i alle ledd. I kapittelet 6 listes det opp noen viktige tjenster som NANSen bør ta tak i. En av disse oppgavene er porteføljestyring som er meget viktig for at sktoren skal lykkes med skytjenester. Det er viktig at porteføljestyring er noe av det første som kommer på plass. Dette er viktig for da er det mulig å definere tjenestene på en skikkelig måtte. Direktoratet for forvaltning og IKT (difi) og Helse Sør-Øst har laget en figur for porteføljestyring (se figur 6). NANSen og institusjonene bør ta innover seg en slik modell, ellers vil ikke samarbeidet kunne fungere. Figur 6: Porteføljestyring definert av Difi og Helse Sør-Øst Office of Government Commerce (OGC) har utarbeidet et rammeverk for prosjekt-, program- og porteføljestyring som representerer beste praksis fra en stort antall offentlige virksomheter i Storbritannia. I følge OGC består en portefølje av alle investeringer i virksomheten (eller en del av denne) som kreves for at virksomheten skal nå sine strategiske mål. 7.4 Mulig permanent NANSen-organisasjon Den organisasjonen som er skissert over er en forholdsvis løs organisasjon, med faggrupper. En kan se for seg en mer permanent organisasjon som skissert i figur 7). 59

60 Figur 7: Skisse av roller/oppgaver i NANSen 7.5 Hva er en hensiktsmessig finansiering av oppgaver som NANSen skal utføre I kapittel 6 diskuteres det en del utforinger rundt kostnader og betalinger av skytjenester. Brukerne våre har ofte troen på at skytjenester er gratis og vil ikke betale for det. Derfor er det viktig som nevnt i 2.2 at det er transparente avregningsmodeller som gjenspeiler de faktiske kostnaden. Det er også klart at det kan være hensiktsmessig å lage en felleskapssky, selv om kostnadene kan bli høyere enn i en offentlig sky. Utfordringen blir da hvordan selge inn at en skal betale mer for en tjeneste internt enn det brukeren får den for eksternt. Hva er det som må finansieres? En kan se for seg å å dele arbeidet til NANSen i faser/oppgaver. Etablere en ledelse, sekretariat og tjenester UH-sektoren definerer inn Dele arbeid ut på institusjonene (fagrupper) Prosjektarbeid (oppstart av nye tjenester eks. oppsett av en IaaS tjeneste) For det ledelse og sekreteriat bør en finne en permanent finansiering. Denne finansieringer kan komme som en eventuell medlemsavgift til NANSen. 60

61 Det er viktig at hvis en setter ut arbeid til institusjoner at de får dette kompensert. Eksempelvis kreditering for frikjøp av personell. Prosjektarbeid må en finne andre måter å finansiere på. Skal en for eksempel sette opp en IaaS-infrastruktur er det ingen i UH-sektoren som kan sette dette opp uten å få betalt for prosjektet. Det vil fort bli mange millioner for å sette opp en IaaS tjenste. Hvis en skal sette opp slike tjenester bør en se etter ekstern finansiering (KD eller andre) For eksempel et samarbeids prosjekt med en Iaas-leverandør, eller sental finansiering (KD). Det er behov for integrasjon av tjenester. Hvis det er mange som skal ha samme skytjenesten, for eksempel en skymailtjeneste (eks. Google apps, Office 365) er det naturlig at en finner en fordelingsnøkkel for integrasjons- og rådgivnings-arbeidet. Uttak av tjenester som benyttes, bør den enkelte institusjonen betale for selv. Eksempelvis hvis NANSen tilbyr Box.com som en tjeneste bør den enkelte institusjon betale direkte til Box.net. Direkte avtale kan desverre ødelegge for volumprising. Det er derfor viktig at avtaleform vurderes for hver tjeneste. Hvis det settes opp en felleskapssky er en av de viktige tingene der å få satt opp en automatisk belasting for bruk. Tjenestene må automatisk lage kostnadsunderlaget. Det er viktig at det ikke lages en stor organisasjon for å fakturere for tjenester i NANSen. Arkitekturen i en eventuell felleskapssky må ta høyde for automatisk betalingsformer. 7.6 Oppsummering Det er mulig å sette i gang en god del arbeid i UH-sektoren som ikke har store kostnader. For eksempel utrede hvordan en felleskapssky kan settes opp. Et forslag til hvordan porteføljestyring skal organiseres, og overvåking av markedet. Det anbefales at NANSen starter med å organisere faggrupper innenfor: Skyarkitektur/Skyinfrastruktur Fellesskapssky Porteføljestyring Det er viktig at NANSen fokuserer på arbeid som raskt gir resultater. Slik som markedsovervåking og rådgiving angående sikkerhet og klassifisering av informasjon. 61

62 8 Konklusjon og videre arbeid Denne rapporten er arbeidsgruppens forslag til etableringen av NANSen, ihht. føringene i mandatet 1.2, tidligere utredninger 1 og virkeligheten i sektorens IT-virksomhet. I lys av de muligheter og begrensninger som er beskrevet anbefaler arbeidsgruppen hvilke aktiviteter som bør startes, av hvem og hvordan de bør prioriteteres. 8.1 Organisering Etableringen av NANSen fordrer en annen og mer koordinert tilnærming til leveranse av IT-tjenester enn det som har vært tradisjonen i UH-sektoren frem til nå. Kapittel 7 påpeker at profesjonell porteføljestyring er en viktig forutsetning for å lykkes med å realisere en del av prinsippene for en vellykket skyorganisering som er omtalt i IBM- CCRA (se kapittel 2.1). En viktig del av porteføljestyringen vil være å overvåke markedet kontinuerlig og vedlikeholde en god oversikt over eksterne skytjenester, deres egenskaper og kostnader slik at disse kan vurderes opp mot tjenester sektoren (også Norden og Europa) og eventuell oppstart av prosjekter for opprettelse av nye tjenester. Det er viktig at portføljeforvaltningen har et langsiktig perspektiv og fokus på forutsigbarhet i sine prioriteringer og tar høyde for at eksterne leverandører kan endre seg og sine premisser over tid. For at ikke NANSen skal føye seg inn i rekken av ukoordinerte initiativer foreslår vi at NANSen etablererer en organisasjon hvis en primær oppgave skal være å ha full oversikt og myndighet til å prioritere og samordne initiativer på tvers av sektoren. Dette forutsetter imidlertid at en viss kritisk masse av IT-ledere fra institusjonene gir avkall på noe kontroll over egne beslutninger og ressurser for å tjene et bedre og mer koordinert samarbeid om IT-tjenester i sektoren. Et potensielt langsiktig insentiv for å bidra inn i NANSenprosessen er økte krav om å levere flere tjenester med færre midler. Se kapittel 3. Det er viktig at NANSen som porteføljeforvalter og koordinator for sektoren produserer beslutninger som er grundig faglig forankret. I kapittel foreslår vi en mer formell og kontinuerlig opprettholdelse av faggrupper på tvers i sektoren. Vi mener at faggrupper er til nytte for deltagende institusjoner uavhengig av NANSen, men at NANSen har ekstra stor interesse av faggruppenes eksistens og kompetanse. Vi foreslår derfor at NANSen får mandat til å opprette og samordne aktiviteten til infrastruktur-relaterte faggrupper i sektoren. I kapittelet nevnes fire organisasjonsmessige prinsipper som vi mener bør være styrende for hvordan NANSen skal operere. Prinsippene gjengis i korthet her: design for effektivitet støtte for Lean Service management 62

63 identifisere og dra nytte av likheter definer og administrer skytjenester generisk i deres livssyklusen 8.2 Etablering av tjenester Vi overlater i hovedsak til den tidligere beskrevne porteføljeforvaltningen å ta stilling til konkrete prioriteringer og tidsrammer for innføring av de forskjellige tjenestene. I kapittelet 6 har vi likevel drøftet forskjellige tjenestetyper innenfor konteksten av NANSen. Etableringen av en intern IaaS/PaaS-arkitektur er nok størst i omfang, men vi foreslår i tillegg at følgende tjenester vurderes: administrativt system for digital eksamen generell personlig lagringstjeneste à la DropBox samarbeidsløsninger à la Surfconext eksisterende fellesadminstrative systemer eksisterende tjenester innenfor ecampus LMS-system som på sikt kan erstatte Classfronter og Itslearning 8.3 Etablering av en UH-intern IaaS-sky I kapittel 6 foreslår vi at eksisterende fellestjenester i sektoren tas inn i under NANSenparaplyen. På sikt bør disse tjenestene også bygges om slik at de samsvarer med egenskapene NIST tillegger skytjenester (se kapittel 2.1.1). En viktig forutsetning for å levere eksisterende fellestjenester som skytjenester er en elastisk basis-infrastruktur i form av IaaS og muligens PaaS oppe på IaaS. Det finnes flere offentlige leverandører av IaaS hvorav Amazon er den mest kjente. Et grunnpremiss fra kapittel 4 er at kun åpne data bør eksponeres i en offentlig skytjeneste for øyeblikket. Det bør derfor etableres en UH-intern IaaS-sky for virtuelle lagrings-, prosessor-, minne- og nettverks-ressurser som legger til rette for en elastisk leveransemodell til tjenester som ikke kan legges i en offentlig skytjeneste. Det er en omfattande oppgave å etablere en slik IaaS-sky. Tekniske løsninger skal vurderes og anskaffes, og integrasjon mot back end systemer i sektoren skal på plass. Den tildligere omtalte profesjonaliseringen av IT-leveranser i sektoren vil være en viktig forutsetning for å lykkes med etableringen av en IaaS-sky. Det er ikke nødvendigvis slik at NANSen selv skal levere en UH-intern IaaS/PaaS-sky, men snarere koordinere ressurser for at så skjer på en måte som sikrer at leveransen tilfredsstiller de kravene som settes. Kanskje det kan utlyses interne konkurranser i UH-sektoren for å levere disse tjenestene 63

64 på samme måte som det gjøres i forbindelse med vitenskapelig databehandling? Slik utlysning fordrer imidlertid grundig forarbeid og faglig forankring (i tidligeree nevnte faggrupper) slik at man sikrerer forståelse for hva som skal leveres og hvordan leveransen kompenseres/finansieres. I tillegg til å vurdere eksterne prosjekter/produkter til å fylle ut de forskjellige komponentene i en teknisk IaaS/PaaS skyinfrastruktur, er det verdt å nevne at UNINETT har flere interessante pilotprosjekter som bør vurderes. Vi tenker spesielt på prosjektet for HA-lagring (se appendix A) og aktivitetene rundt UNINETT Webapp Park [? ]. 64

65 Ordliste/forkortelser Amazon S3 (Amazon) Simple Storage Service ASPIRE A Study on the Prospects of the Internet for Research and Education AWS Amazon Web Services BPAAS Business Process As A Service BSS Business Support System BYOD Bring Your Own Device CCMP Common Cloud Management Platform EBS (Amazon) Elastic Block Store EC2 (Amazon) Elastic Compute Cloud HPC High Performance Computing HIPAA Health Insurance Portability and Accountability Act IAAS Infrastructure As A Service IBM CCRA IBM Cloud Computing Referance Architecture IDM IDentity Management ITIL Information Technology Infrastructure Library Multi tenant Flere samtidige brukere som deler fysiske ressurser NAS Network Attached Storage NIST National Institute of Standards and Technology NREN National Research and Education Network (Uninett i Norge) NSF National Science Foundation NANSen den Norske Akademiske NettSkyen oauth An open standard for authorization OpenSocial A public specification directed towards social software web applications. OSS Operational Support System PCI DSS Payment Card Industry Data Security Standard REST Representational State Transfer 65

66 PAAS Platform As A Service POSIX Portable Operating System Interface SAML2 Security Assertion Markup Language 2.0 SAN Storage Area Network SAAS Software As A Service SOA Service Oriented Architecture SOX Sarbanes Oxley Act SLA Service Level Agreement SSO Single Sign On TOGAF The Open Group Architecture Framework TERENA Trans-European Research and Education Networking Association UWAP Uninett WebApp Park 66

67 Referanser [] Universitets og høgskolerådets utvalg for felles administrative systemer (Aagedals-utvalget). Strategi, organisering og styring av de felles administrative it-systemene i uh-sektoren. URL utvalg/administrasjonsutvalget/oppgaver_utvalg/fellesadministrative_ systemer. [] Ole Brønmo. Nettskyteknologi i uh-sektoren. URL denne.mon.tro.no/. [] Michael Behrendt, Bernard Glasner, Petra Kopp, Robert Dieckmanni, Gerd Breiter, Stefan Pappe, Heather Kreger, and Ali Arsanjani. Introduction and Architecture Overview, IBM Cloud Computing Reference Architecture 2.0, URL https://www.opengroup.org/cloudcomputing/uploads/40/23840/ CCRA.IBMSubmission doc. [] T. Grance and P. M. Mell. The NIST Definition of Cloud Computing, URL [] The Open Group. Soa definition,. URL def.htm. [] The Open Group. Architecture principles,. URL architecture/togaf8-doc/arch/chap29.html. [] The ASPIRE panel. The adoption of cloud services. URL org/activities/aspire/docs/clouds_aspire_v4.pdf. [] SURFnet. Surfconext. URL default.aspx. [] UiO IHR-rposjektet. Internt handlingsrom. URL for-ansatte/arbeidsstotte/prosjekter/internt-handlingsrom/. [] NORDUnet A/S. Nordunet peering service. URL news events_attchmt/nordunet%20-%20peering%20service.pdf. [] Rice University Guohui Wang T. S. Eugene Ng. The impact of virtualization on network performance of amazon ec2 data center. URL papers/infocom10-ec2.pdf. [] Datatilsynet. Datatilsynet åpner for bruk av skytjenester. URL datatilsynet.no/nyheter/2012/bruk-av-nettskytjenester/. [] Martha Felton. Uios retningslinjer for skytjenester. URL tjenester/it/sikkerhet/handbok/prosedyrer/15-4.html. [] Zack Whittaker. Microsoft: We can hand over office 365 data without your permission. URL microsoft-we-can-hand-over-office-365-data-without-your-permission/

68 [] IViR. Cloud computing in higher education and research institutions and the usa patriot act. URL Patriot_Act_2012_EN.pdf. [] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V. Shmatikov. The most dangerous code in the world: validating ssl certificates in non-browser software. In Proceedings of the 2012 ACM conference on Computer and communications security, pages ACM, [] Øivind Høiem. Utkast til retningslinjer for klassifisering og oppbevaring av informasjon. URL https://openwiki.uninett.no/nansen:start?&#rapporten. [] Universitetet i Oslo. Cerebrum. URL [] Andreas Solberg. Uninett webapp park. URL https://rnd.feide.no/category/ uwap/. [] TERENA. Terena trusted cloud drive. URL https://confluence.terena.org/ display/cloudstorage/terena+trusted+cloud+drive. [] Moodle. Moodle lms. URL https://moodle.org/. [] Alf Hansen. Generelt om uninetts samarbeidsmodell for kundefinansierte, felles iktløsninger i uh-sektoren. URL https://openwiki.uninett.no/nansen:start?&# rapporten. 68

69 A Høypålitelig systeminfrastruktur Her skisseres en arkitektur for hvordan man kan bygge en privat eller sektorbasert skytjeneste med gode egenskaper med hensyn til pålitelighet, skalering, fleksibilitet og driftsforenkling. De samme infrastrukturen vil kunne brukes til både IaaS/PaaS og SaaS. Opgavene rundt drift og utvikling kan fordeles etter evne og interesse i sektoren. Man kan tenke seg en dugnadsmodell hvor man yter etter evene og tar ut etter behov med en kostnadsfordelingsmodell i bunnen. Skybaserte tjenester betyr vanligvis ikke høypålitelige systemer hvor alle komponenter er replisert geografisk og uavhengige slik at systemet overlever enkeltfeil. Dette konseptet som vi beskriver nedenfor gjør høypålitelige skytjenester mulig. A.1 Pålitelighet Alle komponenter vil kunne feile en gang uansett hvor påkostet de er. Dette gjelder nett, kabler, maskiner, disker, strøm, programvare osv. Den samlede sannsynligheten for å feile er da i prinsippet summen av sannsynligheten for alle komponentene. Ved å plassere flere enkle maskiner på flere uavhengige steder kan man få høyere pålitelighet enn om man setter en kompleks løsning på et sted. Ved å systematisk replisere data kan man da gjøre tjenesten uavhengig av at enkelt-komponenter eller til og med hele installasjoner faller ut. Hvis en PC har ca 99% oppetid, så vil 3 helt uavhengige gir teoretisk % for at minst en er oppe. A.2 Maskinvare Den billigste måten å bygge lager på idag er å sette enkle PC er fulle med disker. Dette er ca en faktor på 3 billigere enn tilsvarende SAN/NetApp type løsninger. Disse løsningene og bladløsninger har gjerne påkostet spesiell hardware som man ikke trenger når man har et raskt nett. Dette kan brukes både til lagring og storskala databehandling. Istedet for å replisere data med lokal speiling i RAID så kan man replisere data mer distribuert mellom maskiner til uavhengige lokasjoner. Derfor så trenger man ikke dyre og kompliserte løsninger, men kan kjøpe enkle og billige løsninger. UNINETT har bygd en slik lab med 3 veis replisering med tjenere fulle med disker til under 10kkr per maskin. I bunnen av et slikt datalager legges et distribuert filsystem som automatisk repliserer data til forskjellige maskiner og som automatisk rekonfigurerer seg når en feil oppstår. A.3 Driftsmiljø Siden den nominelle påliteligheten blir så høy synker kravene til betjening. Man trenger bare ta en feilende komponent ut av systemet når det skjer noe og dette vil ofte kunne 69

70 skje automatisk. Man trenger derfor ikke stresse med å reparere, men kan ta det når det passer når man likvel skal fase inn noe nytt f.eks. Dette gjør også at man ikke trenger vedlikeholdskontrakter med erstatningskomponenter men kan nøye seg med leveranseavtaler og bestille ved behov. Filsystemene kan automatisk migrere data mellom lokasjoner og til nye plattformer uten at man trenger å stoppe driften. På den måten så kan mer skje i kontortiden og oppetid går opp også off-hours pga redusert tid til vedlikehold. A.4 Høypålitelige tjenester Tjenester må normalt tilpasses for å kunne kjøre i et parallellt distribuert miljø. Lesing er uproblematisk fordi forskjellige brukere ikke alltid trenger helt samme data og man kan spre aksessene til forskjellige kopier og dette skalerer bra. Oppdatering krever ofte at man oppdaterer på samme sted. I første rekke setter man fordelingsmaskiner som en bruker når via anycast og hvis en av dem feiler så sørger ruting for at man kommer til neste neste gang man prøver. Dette er en av fordelene med at vi kontrollerer nettet selv. Fordelingsmaskinene kan se på transaksjonene og fordele riktig transaksjon til riktig betjeningsmaskinen, f.eks. en web frontend. Disse vil så kunne hente dataene fra et distriburt filllager eller en database. Klassiske relasjonsdatabasesystemer har mulighet for passive repliseringer som man kan aktivere hvis en primær database feiler. Trenger man skalering kan man dele opp databasene etter nøkler på maskiner(sharding). Nyere databasesystemer (NoSql), har mindre avhengigheter og man fordeler dataene etter nøkler på maskiner og disse kan opptre uavhengig. Felles for et slikt system er at det meste skalerer bra horisontalt - dvs at man kan legge til nye noder og øke kapasiteten lineært. UNINETT har bygd og demonstrert flere slike HA-systemer som FEIDE, UNINETT Sanntid og Eske/OwnCloud og Variations. Erfaringene er gode. A.5 Felles tjenester Mange har et behov for kopi av data ut av huset og også tilgang på maskiner hvis eget datasenter går ned. Med HA-organisering kan man tenke seg en modell hvor man plasserer klynger av data på flere steder, gjerne med en i eget hus som brukes primært, men med replisering til klynger andre steder og vise versa - andre lagrer kopier av sine data hos deg. Når eget anlegg går ned så tas bare maskinene ute hos andre i bruk og tjenestene fortsetter uendret. 70

71 Figur 8: HA arkitektur Dette kan organseres som gjensidig samarbeid, men også som en del av et Nansen fellestjeneste hvor institusjoner kan bidra med en klynge maskiner inn i et felles system eller bare kjøpe tjenester i systemet. Bidrar så må man få godtgjort dette. Hvis etterspørsel blir større enn bidrag så må Nansen kjøpe kapasitet for nye klynger der det måtte være best. Driften av slike tjenester vil da kunne være delt etter funksjon og sted : 1. Første-linje brukerkontakt 2. Tjenstedrift 3. Basis operering av klyngesystemene 4. Systemutvikling og avansert feilretting Brukerkontakten kan drives per institusjon og også maskinvare for de som har det, mens systemutviklingen gjøres av en gruppe satt sammen av ressurser fra sektoren. På den måten kan vi få god skalering på driften. 71

Skytjenester. - Gevinster og utfordringer. Petter Kongshaug, UNINETT

Skytjenester. - Gevinster og utfordringer. Petter Kongshaug, UNINETT Skytjenester - Gevinster og utfordringer Petter Kongshaug, UNINETT Tradisjonell IKT i endring 14. november 2013 SLIDE 2 Google compute plants 14. november 2013 SLIDE 3 Universitet IKT i endring WiFi Cloud

Detaljer

IaaS / OpenStack. UNINETT-konferansen 2013. Trond Hasle Amundsen. 1. oktober 2013. GSD/GD/IT-DRIFT/USIT Universitetet i Oslo

IaaS / OpenStack. UNINETT-konferansen 2013. Trond Hasle Amundsen. 1. oktober 2013. GSD/GD/IT-DRIFT/USIT Universitetet i Oslo IaaS / OpenStack UNINETT-konferansen 2013 Trond Hasle Amundsen GSD/GD/IT-DRIFT/USIT Universitetet i Oslo 1. oktober 2013 Dagens tema Begreper og konsepter Tradisjonell vs. moderne workload OpenStack Gluster

Detaljer

Rapport fra spørreundersøkelse gjennomført i oktober/november 2013

Rapport fra spørreundersøkelse gjennomført i oktober/november 2013 Rapport fra spørreundersøkelse gjennomført i oktober/november 2013 1 Innhold Oppsummering... 3 1 Bakgrunn... 4 1.1 Antakelse og innhold i en spørreundersøkelse... 4 2 Resultater spørreundersøkelse... 4

Detaljer

Cloud computing. Bruk av skytjenester krever en klar strategi

Cloud computing. Bruk av skytjenester krever en klar strategi Cloud computing Bruk av skytjenester krever en klar strategi KORT OM SELSKAPET ASP Norge er et uavhengig rådgivingsselskap Vi har spisskompetanse på forretningstyrt og strategisk bruk av IT Selskapet ble

Detaljer

Finne, tilpasse og tilby skyjenester til sektoren...på lengre sikt levere alle felles IT-tjenester til sektoren. 12. mars 2015 2

Finne, tilpasse og tilby skyjenester til sektoren...på lengre sikt levere alle felles IT-tjenester til sektoren. 12. mars 2015 2 12. mars 2015 1 Finne, tilpasse og tilby skyjenester til sektoren..på lengre sikt levere alle felles IT-tjenester til sektoren 12. mars 2015 2 Tjenestekatalog https://www.uninett.no/portal/skytjenester

Detaljer

Struktur og arkitektur

Struktur og arkitektur Struktur og arkitektur Sammenhengen mellom strukturmeldingen og arbeidet med IT-arkitektur i sektoren. Kan arkitektur bidra til at strukturendringer forenkles? Konsentrasjon for kvalitet En formidabel

Detaljer

Prosjektplan UH-intern IaaS

Prosjektplan UH-intern IaaS 1 Bakgrunn... 3 2 Prosjektmål... 4 3 Overordnet framdriftsplan... 7 4 Budsjett... 7 5 Organisering prosjekt... 9 6 Risiko... 9 7 Andre opplysninger... 9 Begreper... 11 UH-sky Page 2 1 Bakgrunn Planen beskriver

Detaljer

SUHS-2014 Med UNINETT i en digital fremtid. Petter Kongshaug, Adm. Dir.

SUHS-2014 Med UNINETT i en digital fremtid. Petter Kongshaug, Adm. Dir. SUHS-2014 Med UNINETT i en digital fremtid Petter Kongshaug, Adm. Dir. UNINETTs rolle i sektoren Vi er sektorens verktøy med spisskompetanse på å få til samarbeid om fellesløsninger gjennom; - Prioriteringsråd/Styringsgrupper

Detaljer

Software, hardware, elsewhere or vaporware?

Software, hardware, elsewhere or vaporware? Software, hardware, elsewhere or vaporware? Offentlige IKT tjenester i skyen John Krogstie Professor i informasjonssystemer NTNU NOKIOS 2010, 28/10 2010 krogstie@idi.ntnu.no Agenda Hva bruker norske virksomheter

Detaljer

Systemleverandører anno 2011

Systemleverandører anno 2011 Systemleverandører anno 2011 Er de klare for skyen? M.Sc. Bo Hjort Christensen Industrial Professor/Associate Dean BI Business School Institutt for ledelse og organisasjon Bedriftsrådgiver BHC A/S bo.h.christensen@bi.no

Detaljer

Moderne integrasjonsarkitektur for B2C og B2E. Steinar Kolnes, Senior utvikler

Moderne integrasjonsarkitektur for B2C og B2E. Steinar Kolnes, Senior utvikler Moderne integrasjonsarkitektur for B2C og B2E Steinar Kolnes, Senior utvikler Følg presentasjonen via egen enhet Dagens agenda BYOD som eksempel på moderne integrasjonsarkitektur for B2E og B2C Historikk

Detaljer

Skyløsninger. Sikkerhet og leveransemodell

Skyløsninger. Sikkerhet og leveransemodell Skyløsninger Sikkerhet og leveransemodell Per Christian Berg per.christian.berg@visma.com 977 07 330 Agenda Hva er skytjenester? Litt bakgrunn Visma Enterprise BI, arkitektur og sikkerhet Personopplysninger

Detaljer

Digitaliseringsstrategi 2014-2029

Digitaliseringsstrategi 2014-2029 Digitaliseringsstrategi 2014-2029 Stavanger kommune Stavanger kommune skal gi innbyggerne og næringsliv et reelt digitalt førstevalg. Den digitale dialogen skal legge vekt på åpenhet og tilgjengelighet.

Detaljer

LMS-administrator i går, i dag og i morgen. UiA / SUHS-Trondheim 5/11-2014 Claus Wang

LMS-administrator i går, i dag og i morgen. UiA / SUHS-Trondheim 5/11-2014 Claus Wang LMS-administrator i går, i dag og i morgen UiA / SUHS-Trondheim 5/11-2014 Claus Wang LMS - hva er det? WIKIPEDIA: «En digital læringsplattform (ofte omtalt som forkortelsen LMS) er et system for å administrere

Detaljer

Strategi Samarbeidstiltaket og systemet FS (Felles studentsystem)

Strategi Samarbeidstiltaket og systemet FS (Felles studentsystem) Strategi Samarbeidstiltaket og systemet FS (Felles studentsystem) Versjon 10. juni 2013 1 Bakgrunn Samarbeidstiltaket FS er et samarbeid mellom norske universiteter og høgskoler med ansvar for å videreutvikle

Detaljer

ecampus Norge en moderne infrastruktur for forskning, undervisning og formidling

ecampus Norge en moderne infrastruktur for forskning, undervisning og formidling Idé, design og trykk: Tapir Uttrykk Nasjonalt sertifikat: 1660 Grafisk design og trykk: Tapir Uttrykk Nasjonalt sertifikat: 1660 Produksjon: Tapir Uttrykk Nasjonalt sertifikat: 1660 Tapir Uttrykk Nasjonalt

Detaljer

Digitaliseringsstrategi for Buskerud fylkeskommune 2015-2017 Buskerud fylkeskommune Vedtatt av administrasjonsutvalget 14.

Digitaliseringsstrategi for Buskerud fylkeskommune 2015-2017 Buskerud fylkeskommune Vedtatt av administrasjonsutvalget 14. Digitaliseringsstrategi for Buskerud fylkeskommune 2015-2017 Buskerud fylkeskommune Vedtatt av administrasjonsutvalget 14.april 2015 Innhold 1. INNLEDNING... 3 2. GJENNOMFØRING... 4 3. SATSINGSOMRÅDER...

Detaljer

OBC FileCloud vs. Dropbox

OBC FileCloud vs. Dropbox OBC FileCloud vs. Dropbox Whitepaper Innledning: utfordringer Ansatte tyr stadig oftere til usikrede, forbrukerrettede fildelingstjenester i nettskyen for å få tilgang til arbeidsdokumenter fra flere utstyrsenheter

Detaljer

Virksomheter som tar i bruk skytjenester er juridisk ansvarlige, og må sørge for at personopplysningene behandles i tråd med personvernregelverket.

Virksomheter som tar i bruk skytjenester er juridisk ansvarlige, og må sørge for at personopplysningene behandles i tråd med personvernregelverket. CLOUD COMPUTING En veiledning i bruk av skytjenester, 2014 Skytjenester Virksomheter som tar i bruk skytjenester er juridisk ansvarlige, og må sørge for at personopplysningene behandles i tråd med personvernregelverket.

Detaljer

IaaS / UH-sky. Agenda. Trender Hvorfor sky? UH-sky, UiO-skyen Utvikling i skyen OpenStack Demo. Utviklerforum USIT, UiO Mai 2014

IaaS / UH-sky. Agenda. Trender Hvorfor sky? UH-sky, UiO-skyen Utvikling i skyen OpenStack Demo. Utviklerforum USIT, UiO Mai 2014 IaaS / UH-sky Utviklerforum USIT, UiO Mai 2014 Trender Hvorfor sky? UH-sky, UiO-skyen Utvikling i skyen OpenStack Demo Agenda Trender Software-Defned Data Center Software-Defned Networking Software-Defned

Detaljer

NOTAT: Samarbeid om Utdanningssky

NOTAT: Samarbeid om Utdanningssky NOTAT: Samarbeid om Utdanningssky INNHOLD 1 SAMMENDRAG 2 2 BAKGRUNN 3 2.1 OM SKYTEKNOLOGI 3 2.2 UTFORDRINGER I GRUNNOPPLÆRINGEN 3 2.3 FELLES UTFORDRINGER FOR GRUNNOPPLÆRINGEN OG UHSEKTOREN 4 2.4 STOR INTERESSE

Detaljer

Hva betyr tjenesteorientert arkitektur for sikkerhet?

Hva betyr tjenesteorientert arkitektur for sikkerhet? Hva betyr tjenesteorientert arkitektur for sikkerhet? Torbjørn Staff Architecture Innovation Group Accenture, its logo, and High Performance Delivered are trademarks of Accenture. Agenda Arkitekturevolusjonen

Detaljer

Fleksible og fremtidsrettede it-løsninger for Moss Kommune. Veien til nettskyen v/bjarne I. Blom

Fleksible og fremtidsrettede it-løsninger for Moss Kommune. Veien til nettskyen v/bjarne I. Blom Fleksible og fremtidsrettede it-løsninger for Moss Kommune Veien til nettskyen v/bjarne I. Blom Moss kommune: 32.000 innbyggere og 2.500 ansatte 65 lokasjoner på egen fiber 1 Gb internettlinje med 100Mb

Detaljer

Er du trygg i nettskyen 31. Mai 2011 Advokat Herman Valen

Er du trygg i nettskyen 31. Mai 2011 Advokat Herman Valen Er du trygg i nettskyen 31. Mai 2011 Advokat Herman Valen Innledning Hva er cloud computing? IaaS, PaaS, SaaS osv Skyen er en forretningsmodell som bygger på noen prinsipper: Standardisering (tjenester,

Detaljer

Morgendagens digitale muligheter: programmet ecampus

Morgendagens digitale muligheter: programmet ecampus Morgendagens digitale muligheter: programmet ecampus Seminar: den digitale tilstand i private høgskoler 2012 Ingrid Melve, Teknisk direktør, tjenester, UNINETT UNINETT Det norske forskningsnettet Organisert

Detaljer

Felles studieadministrativt tjenestesenter FSAT. Strategi 2016-2019

Felles studieadministrativt tjenestesenter FSAT. Strategi 2016-2019 Felles studieadministrativt tjenestesenter FSAT Strategi 2016-2019 Strategiske mål 1. FSAT skal være en profesjonell leverandør av tjenester og systemer av høy kvalitet til norske utdanningsinstitusjoner.

Detaljer

Intern arbeidsfordeling i helse vest IKT. ITIL beste praksis i IKT forvaltning John Kåre Knudsen, gruppeleder kliniske systemer

Intern arbeidsfordeling i helse vest IKT. ITIL beste praksis i IKT forvaltning John Kåre Knudsen, gruppeleder kliniske systemer Intern arbeidsfordeling i helse vest IKT ITIL beste praksis i IKT forvaltning John Kåre Knudsen, gruppeleder kliniske systemer Mål med presentasjonen Forsøke å gi et innblikk i hvordan verden ser ut for

Detaljer

Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet?

Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet? Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet? HelsIT 2011 Roar Engen Leder for arkitekturseksjonen,teknologi og ehelse, Helse Sør-Øst RHF Medforfatter: Jarle

Detaljer

ecampus program 2011-2015 (16.02.2010)

ecampus program 2011-2015 (16.02.2010) ecampus program 2011-2015 (16.02.2010) Norge står overfor flere store undervisningsrelaterte utfordringer i de nærmeste årene, og noen av de kravene som må håndteres for å opprettholde vår kunnskapsbaserte

Detaljer

Drifte selv eller sette bort - pro et contra.

Drifte selv eller sette bort - pro et contra. Drifte selv eller sette bort - pro et contra. Hvorfor er du her Som ephorte-kunde kan du velge mellom flere driftsmodeller. I denne workshopen går vi igjennom mulighetene du har og fordeler og ulemper

Detaljer

Rammeverk for anskaffelse av tjenester i skyen.

Rammeverk for anskaffelse av tjenester i skyen. Rammeverk for anskaffelse av tjenester i skyen. Et porteføljeperspektiv Ivar Aune 19. januar 2012 2010 Dobbelt så bra, på halv tid, til halv pris.. 2 Mitt Transportselskap AS Lagerstyring (WMS) i skyen

Detaljer

Samarbeid om utvikling Integrasjonsarkitektur

Samarbeid om utvikling Integrasjonsarkitektur Kunnskap for en bedre verden IT for et bedre universitet Samarbeid om utvikling Integrasjonsarkitektur SUHS-konferansen 2014 Carl-Fredrik Sørensen IDI, NTNU Agenda Integrasjonsarkitektur Tjenesteorientering

Detaljer

Andreas Åkre Solberg, fredag 21. mars 2014. Feide Connect Notat. Side 1 av 9

Andreas Åkre Solberg, fredag 21. mars 2014. Feide Connect Notat. Side 1 av 9 Andreas Åkre Solberg, fredag 21. mars 2014 Feide Connect Notat Side 1 av 9 Feide Connect 1 Innledning 3 Prosjekt for implementasjon og utrulling 3 Gevinstrealisering og kobling til andre UNINETT-prosjekter

Detaljer

Strukturendringer i universitets- og høgskolesektoren

Strukturendringer i universitets- og høgskolesektoren Strukturendringer i universitets- og høgskolesektoren IKT som sentralt virkemiddel for å nå målsetningene for strukturendringene Viseadm. dir Tor Holmen. UNINETT AS UH-sektoren, noen tall Pr. dato; 33

Detaljer

ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør

ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør www.steria.com Stein Aarum Leder for arkitekturfagområdet Steria www.steria.com Innhold Hva vi mener med arkitektur Vår viktigste rolle

Detaljer

Derfor er forretningssystemet viktig for bedriften

Derfor er forretningssystemet viktig for bedriften Innhold Derfor er forretningssystemet viktig for bedriften... 2 Når er det på tide å bytte forretningssystem?... 2 Velg riktig forretningssystem for din bedrift... 3 Velg riktig leverandør... 4 Standard

Detaljer

fokus på operasjonell versus strategisk risiko

fokus på operasjonell versus strategisk risiko Risikovurderinger ved bruk av SaaS; fokus på operasjonell versus strategisk risiko 18. februar 2015 Bo Hjort Christensen Sivilingeniør/Bedriftsøkonom Høyskolelektor; Handelshøyskolen BI Institutt for ledelse

Detaljer

Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur

Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur 14. juni 2010 Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur Lill Kristoffersen lill.kristoffersen@ssb.no Statistisk sentralbyrå IKT Abstract:

Detaljer

Skytjenester Status for Riksarkivets arbeid. Ta styringen! Norsk Arkivråds seminar 16. - 17. mars 2015 i Trondheim. Olav Sataslåtten Riksarkivet

Skytjenester Status for Riksarkivets arbeid. Ta styringen! Norsk Arkivråds seminar 16. - 17. mars 2015 i Trondheim. Olav Sataslåtten Riksarkivet Skytjenester Status for Riksarkivets arbeid Ta styringen! Norsk Arkivråds seminar 16. - 17. mars 2015 i Trondheim Olav Sataslåtten Riksarkivet 1 Utfordringene Arkivloven pålegger offentlige organer å ha

Detaljer

MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen

MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen If you think education is expensive... try ignorance! MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen Styrende verdier i MindIT:

Detaljer

FIBER - SIKKER TRANSPORT TIL OG FRA SKYEN. UTFORDRINGER OG MULIGHETER MED FIBER VIDAR.MYRER@KVANTEL.NO 40 80 00 90

FIBER - SIKKER TRANSPORT TIL OG FRA SKYEN. UTFORDRINGER OG MULIGHETER MED FIBER VIDAR.MYRER@KVANTEL.NO 40 80 00 90 FIBER - SIKKER TRANSPORT TIL OG FRA SKYEN. UTFORDRINGER OG MULIGHETER MED FIBER VIDAR.MYRER@KVANTEL.NO 40 80 00 90 KVANTEL AS 50 ansaae 170 millioner i omsetning Historien Llbake Ll 1997, Eltele Øst, Eltele

Detaljer

Fra innkjøpsstrategi til handling et rammeverk som sikrer effektiv og vellykket gjennomføring

Fra innkjøpsstrategi til handling et rammeverk som sikrer effektiv og vellykket gjennomføring Mange organisasjoner opplever i dag et gap mellom strategiske innkjøpsmål og operativ handling. Det gjennomføres en rekke initiativer; herunder kategoristyring, leverandørhåndtering og effektivitet i innkjøpsprosessene

Detaljer

Felles studieadministrativt tjenestesenter FSAT. Strategi 2016-2019

Felles studieadministrativt tjenestesenter FSAT. Strategi 2016-2019 Felles studieadministrativt tjenestesenter FSAT Strategi 2016-2019 Strategiske mål 1. FSAT skal være profesjonell leverandør av raske, brukertilpassede tjenester av høy kvalitet til sine brukere 2. FSAT

Detaljer

Fleksible og fremtidsrettede it-løsninger for Moss Kommune. Veien til nettskyen v/bjarne I. Blom

Fleksible og fremtidsrettede it-løsninger for Moss Kommune. Veien til nettskyen v/bjarne I. Blom Fleksible og fremtidsrettede it-løsninger for Moss Kommune Veien til nettskyen v/bjarne I. Blom Moss kommune: 32.000 innbyggere og 2.500 ansatte 65 lokasjoner på egen fiber 1 Gb internettlinje med 100Mb

Detaljer

www.steria.no Steria as a Service En norsk skytjeneste Steria

www.steria.no Steria as a Service En norsk skytjeneste Steria www.steria.no Steria as a Service En norsk skytjeneste Steria Steria as a Service - Agenda Kort presentasjon av Steria Sterias utfordringer i drift Sterias målsetninger for drift Prosjektet IT Factory

Detaljer

Cloud Computing. Monaco 26.05.2014. Dette bør være forsiden på din presentasjon. Et lybilde med program etc. Kan komme før Ola prater.

Cloud Computing. Monaco 26.05.2014. Dette bør være forsiden på din presentasjon. Et lybilde med program etc. Kan komme før Ola prater. Cloud Computing Monaco 26.05.2014 Dette bør være forsiden på din presentasjon. Et lybilde med program etc. Kan komme før Ola prater. Dette fikser jeg i morgen 2 Agenda: Paradigmeskiftet Hva er Cloud Computing?

Detaljer

Fleksible og fremtidsrettede it-løsninger for Moss Kommune. Veien til nettskyen Terje Jensen, sikkerhetsansvarlig Moss kommune

Fleksible og fremtidsrettede it-løsninger for Moss Kommune. Veien til nettskyen Terje Jensen, sikkerhetsansvarlig Moss kommune Fleksible og fremtidsrettede it-løsninger for Moss Kommune Veien til nettskyen Terje Jensen, sikkerhetsansvarlig Moss kommune Moss kommune: 32.000 innbyggere og 2.500 ansatte 65 lokasjoner på egen fiber

Detaljer

Bilag 6 Vedlegg 3 Definisjoner

Bilag 6 Vedlegg 3 Definisjoner Bilag 6 Vedlegg 3 Definisjoner Saksnummer 13/00203 1 / 7 Versjonshåndtering Versjon Dato Initiert av Endringsårsak 0.1 16.05.2013 Difi Dokument distribuert til tilbydere 02. 01.11.2013 Difi Ny definisjon

Detaljer

Strategi for universitetets IT-virksomhet

Strategi for universitetets IT-virksomhet Allmøte 16. januar 2014 Strategi for universitetets IT-virksomhet IT-direktør Lars Oftedal Universitetsstyret 11. mars 2014 Diskusjonssak Fokus: Strategiske veivalg og prioriteringer for IT-virksomheten

Detaljer

Cloud computing er ikke bare en elastisk leveransemodell av it-tjenester men også mye mer...

Cloud computing er ikke bare en elastisk leveransemodell av it-tjenester men også mye mer... Cloud computing er ikke bare en elastisk leveransemodell av it-tjenester men også mye mer... NOKIOS 2009 Tom Rojahn IBM Chief Technologist tom.rojahn@no.ibm.com Twitter: @rojahn Hva skal vi snakke om??

Detaljer

NOVUG 3 februar 2009

NOVUG 3 februar 2009 NOVUG 3 februar 2009 Tjenestekatalog og CMDB En kombinasjon som fungerer i praksis 2008 Prosesshuset AS All tillhørende informasjon kan bli endret uten varsel 1 Introduksjon Stig Bjørling Ellingsen Gründer

Detaljer

Fri programvare og 3.parts hosting

Fri programvare og 3.parts hosting NITH 2.0 Internett og intranett Komponentsammensetting for fit-to-use Fri programvare og 3.parts hosting Cloud Computing Målsetning Målene var klare. Det var nødvendig med enklere informasjonsflyt mot

Detaljer

Høring - Hindre for digital verdiskapning - Rapport fra utvalg som har vurdert muligheter og hindringer for digital verdiskapning

Høring - Hindre for digital verdiskapning - Rapport fra utvalg som har vurdert muligheter og hindringer for digital verdiskapning Fornyings-, administrasjons- og kirkedepartementet 0030 OSLO Deres ref Vår ref Dato 13/142 13/258-02.05.2013 Høring - Hindre for digital verdiskapning - Rapport fra utvalg som har vurdert muligheter og

Detaljer

Veikart for nasjonale felleskomponenter

Veikart for nasjonale felleskomponenter Sesjon 3A Veikart for nasjonale felleskomponenter Nokios 2014 30.10.14 vidar.holmane@difi.no Introduksjonen Felleskomponenter som tema 2006 2007 2008 2009 2010 2011 Hva det handler om Noen digitale tjenester

Detaljer

Felles. Telefonistrategi

Felles. Telefonistrategi Kongsbergregionen - Felles Telefonistrategi 2010 2012 - side 1 av 5 Felles Telefonistrategi Utkast til godkjenning i rådmannsutvalget Kongsbergregionen - Felles Telefonistrategi 2010 2012 - side 2 av 5

Detaljer

NetNordic 365. Dine nettverks- og samhandlingsløsninger i trygge hender C L O U D D R I F T SUPPORT KONSULENT

NetNordic 365. Dine nettverks- og samhandlingsløsninger i trygge hender C L O U D D R I F T SUPPORT KONSULENT 365 Dine nettverks- og samhandlingsløsninger i trygge hender C L O U D D R I F T SUPPORT KONSULENT Å være kundens «Best Companion» forplikter Det innebærer blant annet å tilby «best-of-breed» løsninger

Detaljer

Standarder for sikker bruk av VPN med og i offentlig sektor

Standarder for sikker bruk av VPN med og i offentlig sektor Standarder for sikker bruk av VPN med og i offentlig sektor Standardiseringsrådsmøte 23.-24. november 2011 beslutningssak Bakgrunn Grønn IKT (Hjemmekontor, videokonferanser) Fjernarbeid og distribuert

Detaljer

Forprosjekt gruppe 13

Forprosjekt gruppe 13 Forprosjekt gruppe 13 Presentasjon Tittel: Oppgave: Periode: Gruppemedlemmer: Veileder: Oppdragsgiver: Kontaktperson: Mobilbillett i HTML5 Utvikle en mobil billettautomat innenfor kategorien dedikert web

Detaljer

Styret Helse Sør-Øst RHF 19. april 2012

Styret Helse Sør-Øst RHF 19. april 2012 Saksframlegg Saksgang: Styre Møtedato Styret Helse Sør-Øst RHF 19. april 2012 SAK NR 028-2012 REGIONAL ANSKAFFELSE AV ØKONOMI- OG LOGISTIKKSYSTEM Forslag til vedtak: 1. Styret slutter seg til at det gjennomføres

Detaljer

Hvordan lage forespørsler for cloud-baserte tjenester og utarbeidelse av avtaler. 27.10.2011 Advokat Herman Valen

Hvordan lage forespørsler for cloud-baserte tjenester og utarbeidelse av avtaler. 27.10.2011 Advokat Herman Valen Hvordan lage forespørsler for cloud-baserte tjenester og utarbeidelse av avtaler 27.10.2011 Advokat Herman Valen 2 Innledning Regelverket for offentlige anskaffelser Kjennetegnet ved cloud-tjenester Standardiserte

Detaljer

Vi prioriterer næringslivet, bekjempelse av svart økonomi og sikker ID-forvaltning

Vi prioriterer næringslivet, bekjempelse av svart økonomi og sikker ID-forvaltning Vi prioriterer næringslivet, bekjempelse av svart økonomi og sikker ID-forvaltning Næringslivet opplever likere konkurransevilkår og betydelig redusert byrde Gjennom et slagkraftig samarbeid legger vi

Detaljer

Bimodal. Lang vs kort sikt i produksjon og tjenesteforvaltning Nokios - 2015. Delivering Transformation. Together.

Bimodal. Lang vs kort sikt i produksjon og tjenesteforvaltning Nokios - 2015. Delivering Transformation. Together. Bimodal Lang vs kort sikt i produksjon og tjenesteforvaltning Nokios - 2015 Delivering Transformation. Together. Mål for WS: 1. Kjenne til hva «bimodal» er 2. Få praktiske råd for å komme i gang 3. Prøve

Detaljer

Bergvall Marine OPPGAVE 3. Jon Vegard Heimlie, s162110 Vijitharan Mehanathan, s171645 Thore Christian Skrøvseth, s171679

Bergvall Marine OPPGAVE 3. Jon Vegard Heimlie, s162110 Vijitharan Mehanathan, s171645 Thore Christian Skrøvseth, s171679 2013 Bergvall Marine OPPGAVE 3 Jon Vegard Heimlie, s162110 Vijitharan Mehanathan, s171645 Thore Christian Skrøvseth, s171679 Innhold Oppgave 1.... 2 Oppgave 2.... 7 Oppgave 3.... 9 Oppgave 4.... 10 Kilder:...

Detaljer

BIRD - Administrasjon av forskningsdata (Ref #2219b941)

BIRD - Administrasjon av forskningsdata (Ref #2219b941) BIRD - Administrasjon av forskningsdata (Ref #2219b941) Søknadssum: 1 000 000 Varighet: Toårig Kategori: Innsatsområder Samarbeid og partnerskap Opplysninger om søker Organisasjonsnavn / nr Handelshøyskolen

Detaljer

Saksframlegg. Styret Helse Sør-Øst RHF 22. november 2012 SAK NR 076-2012 STRATEGI FOR NASJONAL IKT 2013-2016. Forslag til vedtak:

Saksframlegg. Styret Helse Sør-Øst RHF 22. november 2012 SAK NR 076-2012 STRATEGI FOR NASJONAL IKT 2013-2016. Forslag til vedtak: Saksframlegg Saksgang: Styre Møtedato Styret Helse Sør-Øst RHF 22. november 2012 SAK NR 076-2012 STRATEGI FOR NASJONAL IKT 2013-2016 Forslag til vedtak: Styret gir sin tilslutning til Nasjonal IKTs strategi

Detaljer

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Sentralisert Node

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Sentralisert Node PRODUKTBESKRIVELSE INFRASTRUKTUR NRDB Sentralisert Node Versjon 3.0 11/10/04 Nasjonal referansedatabase AS 14/10/04 Page 1 of 10 Innholdsfortegnelse 1 INNLEDNING...3 1.1 NUMMERPORTABILITET...3 1.2 VIDERESALG

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

Forretningsutvikling og innovasjon med IT: Trender og muligheter

Forretningsutvikling og innovasjon med IT: Trender og muligheter Forretningsutvikling og innovasjon med IT: Trender og muligheter Teknologiutvikling som drivkraft Utfordringer i programvaremarkedet CIO = Chief Innovation Officer? Ragnvald Sannes (ragnvald.sannes@bi.no)

Detaljer

Mandat. Ma lbilder og strategier for fellesløsninger i offentlig sektor

Mandat. Ma lbilder og strategier for fellesløsninger i offentlig sektor Mandat Ma lbilder og strategier for fellesløsninger i offentlig sektor Innhold Bakgrunn... 2 Formålet med felles målbilder og strategier... 2 Mål for arbeidet... 3 Leveranser 2015... 4 Del 1: Visjon og

Detaljer

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Lokal Node (VPN)

PRODUKTBESKRIVELSE INFRASTRUKTUR. NRDB Lokal Node (VPN) PRODUKTBESKRIVELSE INFRASTRUKTUR Lokal Node (VPN) Versjon 3.0 11/10/04 Nasjonal referansedatabase AS 14/10/04 Page 1 of 11 Innholdsfortegnelse 1 INNLEDNING...3 1.1 NUMMERPORTABILITET...3 1.2 VIDERESALG

Detaljer

Hvorfor bør det etableres en felles systemarkitektur for helseforetakene? Helse IT 2007 Per Olav Skjesol Avdelingsleder Anvendelse Hemit

Hvorfor bør det etableres en felles systemarkitektur for helseforetakene? Helse IT 2007 Per Olav Skjesol Avdelingsleder Anvendelse Hemit Hvorfor bør det etableres en felles systemarkitektur for helseforetakene? Helse IT 2007 Per Olav Skjesol Avdelingsleder Anvendelse Hemit Prosjektansvarlig Nasjonal IKT for arkitektur Innhold Hvorfor jobbe

Detaljer

Trender: Cloud teknologi hva er nytten for deg? Heidi Berg, Vianova Systems og Jan Tore Bugge, Cad-Q

Trender: Cloud teknologi hva er nytten for deg? Heidi Berg, Vianova Systems og Jan Tore Bugge, Cad-Q Trender: Cloud teknologi hva er nytten for deg? Heidi Berg, Vianova Systems og Jan Tore Bugge, Cad-Q Wikipedia: Nettskyen(eng:cloudcomputing) Er en betegnelse for alt fra dataprosessering og datalagring

Detaljer

Stian Estil IT TRENDER 2011

Stian Estil IT TRENDER 2011 Stian Estil IT TRENDER 2011 Cloud Computing/Nettskyen Cloud computing Cloud Computing definisjon Nettskyen Fra Wikipedia, den frie encyklopedi (Omdirigert fra Cloud computing) Gå til: navigasjon, søk

Detaljer

Deres/Your ref.: UU022/14FB Vår/Our ref.: Freddy Barstad Trondheim, 29/12014

Deres/Your ref.: UU022/14FB Vår/Our ref.: Freddy Barstad Trondheim, 29/12014 Studieavdelingen v/studiesjef Deres/Your ref.: UU022/14FB Vår/Our ref.: Freddy Barstad Trondheim, 29/12014 INVITASJON TIL DELTAKELSE FRA UNIVERSITET OG HØGSKOLENE I NASJONALT PROSJEKT FOR DIGITAL EKSAMEN,

Detaljer

Tjenester i skyen hva må vi tenke på?

Tjenester i skyen hva må vi tenke på? Tjenester i skyen hva må vi tenke på? Renate Thoreid, senioringeniør Datatilsynet, Tilsyn og sikkerhetsavdeling Side 1 Visjon: Datatilsynet i front for retten til selvbestemmelse, integritet og verdighet

Detaljer

KJAPPE, BILLIGE SKYTJENESTER MEN HAR DU KONTROLL?

KJAPPE, BILLIGE SKYTJENESTER MEN HAR DU KONTROLL? KJAPPE, BILLIGE SKYTJENESTER MEN HAR DU KONTROLL? 5. mai 2015, Ivar Aasgaard LITT BAKGRUNNSINFORMASJON Steria ble i 2014 en del av Sopra Steria-konsernet 35.000 medarbeidere i 20 land Proforma omsetning

Detaljer

Capgemini Bergen. og vi snakker om... Simply. Business Cloud. Rolf Wangsholm regiondirektør

Capgemini Bergen. og vi snakker om... Simply. Business Cloud. Rolf Wangsholm regiondirektør Capgemini Bergen. og vi snakker om... Simply. Business Cloud Rolf Wangsholm regiondirektør Agenda Kort om Capgemini Cloud Skytjenester. Endelig modent? Business Cloud 7 th December, 2012 Copyright Capgemini

Detaljer

NETWORK FUNCTION VIRTUALIZATION (NFV) HVA OG HVORFOR?

NETWORK FUNCTION VIRTUALIZATION (NFV) HVA OG HVORFOR? NETWORK FUNCTION VIRTUALIZATION (NFV) HVA OG HVORFOR? Morten Kveil Alcatel-Lucent Trondheim, Januar 10th 2014 AGENDA Network Function Virtualization (NFV) Hva og hvorfor? Hva menes med NFV og hva er driverne

Detaljer

Fra data til innsikt. Om prosjektet

Fra data til innsikt. Om prosjektet Fra data til innsikt DEFINERE FOKUS Om prosjektet De store produksjonsselskapene innen olje og gass må hele tiden strebe etter å effektivisere drift og øke sikkerheten på sine installasjoner. For å støtte

Detaljer

Box: erfaringer med UNINETTs første internasjonale skytjeneste. Jan Meijer, UNINETT

Box: erfaringer med UNINETTs første internasjonale skytjeneste. Jan Meijer, UNINETT Box: erfaringer med UNINETTs første internasjonale skytjeneste Jan Meijer, UNINETT UNINETT Norges forskningsnett KDs verktøy for felles IKT infrastruktur i norsk UH 85 årsverk omsetning 180 millioner ca.

Detaljer

Om UNINETT FAS F e l l e s A d m i n i s t r a t i v e S y s t e m e r f o r u n i v e r s i t e t e r o g h ø g s k o l e r 1

Om UNINETT FAS F e l l e s A d m i n i s t r a t i v e S y s t e m e r f o r u n i v e r s i t e t e r o g h ø g s k o l e r 1 Om UNINETT FAS F e l l e s A d m i n i s t r a t i v e S y s t e m e r f o r u n i v e r s i t e t e r o g h ø g s k o l e r 1 Vår oppgave UNINETT FAS sitt samfunnsoppdrag er å bidra til bedre og mer effektiv

Detaljer

Arkivloven og skyen. Senioradvokat, Malin Tønseth 17. Mars 2015 www.svw.no

Arkivloven og skyen. Senioradvokat, Malin Tønseth 17. Mars 2015 www.svw.no Arkivloven og skyen Senioradvokat, Malin Tønseth 17. Mars 2015 www.svw.no Arkivloven Arkivloven 9 offentlige arkiv "Utan i samsvar med føresegner gjevne i medhald av 12 i denne lova eller etter særskilt

Detaljer

Anbefalinger til Standardiseringsrådet vedrørende utredning av standarder for informasjonssikkerhet

Anbefalinger til Standardiseringsrådet vedrørende utredning av standarder for informasjonssikkerhet Anbefalinger til Standardiseringsrådet vedrørende utredning av standarder for informasjonssikkerhet Bakgrunn Utredningen av standarder for informasjonssikkerhet har kommet i gang med utgangspunkt i forprosjektet

Detaljer

IT strategi for Universitet i Stavanger 2010 2014

IT strategi for Universitet i Stavanger 2010 2014 IT strategi for Universitet i Stavanger 2010 2014 1 Visjon Profesjonell og smart bruk av IT Utviklingsidé 2014 Gjennom målrettet, kostnadseffektiv og sikker bruk av informasjonsteknologi yte profesjonell

Detaljer

ASKER. Bilder og dokumenter som en kun har lagret på kun én PC, ett Nettbrett, eller i én Telefon vil før eller senere gå tapt!

ASKER. Bilder og dokumenter som en kun har lagret på kun én PC, ett Nettbrett, eller i én Telefon vil før eller senere gå tapt! ASKER Temadag høsten 2015 Back-up Bilder og dokumenter som en kun har lagret på kun én PC, ett Nettbrett, eller i én Telefon vil før eller senere gå tapt! I dag finnes det mange alternativer for back-up.

Detaljer

Samhandlingsplattform

Samhandlingsplattform Fra Samhandlingsarkitektur til Samhandlingsplattform HelsIT 2011 Radisson Blu Royal Garden Hotel, Trondheim Forfattere: Hans-Olav Warholm og Bjarte Aksnes www.kith.no Helt kort om oss Hans-Olav Warholm:

Detaljer

1. Intro om SharePoint 2013

1. Intro om SharePoint 2013 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Intro om SharePoint 2013 Stein Meisingseth 09.08.2013 Lærestoffet er utviklet for faget LO205D Microsoft SharePoint 1. Intro om SharePoint

Detaljer

IHE i Norge. Petter Østbye. Adm. dir. Sectra Norge AS. Medforfattere: Espen Møller, Roald Bergstrøm, Aslak Aslaksen

IHE i Norge. Petter Østbye. Adm. dir. Sectra Norge AS. Medforfattere: Espen Møller, Roald Bergstrøm, Aslak Aslaksen IHE i Norge Petter Østbye Adm. dir. Sectra Norge AS Medforfattere: Espen Møller, Roald Bergstrøm, Aslak Aslaksen Doc. No/Page 1(xx) Innhold Introduksjon Føringer innenfor informasjonsutveksling Utfordringen

Detaljer

Identitetsstyring og tilgangskontroll innenfor et SOA-regime. Ragna Fossen, 05.03.2009

Identitetsstyring og tilgangskontroll innenfor et SOA-regime. Ragna Fossen, 05.03.2009 Identitetsstyring og tilgangskontroll innenfor et SOA-regime Ragna Fossen, 05.03.2009 On the Internet, nobody knows you re a dog. SOA-løsninger er på full fart inn i ITarkitekturen et effektivt verktøy

Detaljer

ELCOM deltagerprosjekt: Elektronisk strømmarked. Siri A. M. Jensen, NR. Oslo Energi, 3.desember 1996. Epost: Siri.Jensen@nr.no.

ELCOM deltagerprosjekt: Elektronisk strømmarked. Siri A. M. Jensen, NR. Oslo Energi, 3.desember 1996. Epost: Siri.Jensen@nr.no. ELCOM deltagerprosjekt: Elektronisk strømmarked Siri A. M. Jensen, NR Oslo Energi, 3.desember 1996 1 Hva gjøres av FoU innenfor Elektronisk handel og markedsplass? Elektronisk handel -> Information Highway

Detaljer

Må man være syk i hodet for å ha helseopplysninger i skyen?

Må man være syk i hodet for å ha helseopplysninger i skyen? Må man være syk i hodet for å ha helseopplysninger i skyen? Martin Gilje Jaatun Norm-konferansen 14/10 2015 @seniorfrosk SINTEF ICT 1 Utfordringer i nettskyen Lange leverandørkjeder Kompleksitet Skala

Detaljer

Haraldsplass. Svar på varsel om vedtak - Uautorisert uthenting av helseopplysninger gjennom leverandørenes fjerntilgang.

Haraldsplass. Svar på varsel om vedtak - Uautorisert uthenting av helseopplysninger gjennom leverandørenes fjerntilgang. Haraldsplass DIAKONALE SYKEHUS Bergen Diakon isse k j em Datatilsynet Postboks 8177 Dep 0034 Oslo Deres ref: 12/00302-1 /HVE Vår ref: Bergen, 13.04.2012 Svar på varsel om vedtak - Uautorisert uthenting

Detaljer

Nettbasert skoleadministrasjon. 1 Visma FLYT Skole

Nettbasert skoleadministrasjon. 1 Visma FLYT Skole Visma FLYT Skole Nettbasert skoleadministrasjon 1 Visma FLYT Skole Visma FLYT Skole De gode grunnene: Effektiviserer administrasjonen av norske skoler Lar lærerne bruke mer tid på undervisning Sørger for

Detaljer

Innovativ Ungdom. Fremtidscamp 2015

Innovativ Ungdom. Fremtidscamp 2015 Innovativ Ungdom Fremtidscamp2015 TjerandAgaSilde MatsFiolLien AnnaGjersøeBuran KarolineJohannessenLitland SiljeKristineLarsen AnetteCelius 15.mars2015 1 Sammendrag Innovasjon Norge har utfordret deltagere

Detaljer

Datasenterstrategi i SpareBank 1 Hvilke valg finnes mellom skyen og egen kjeller?

Datasenterstrategi i SpareBank 1 Hvilke valg finnes mellom skyen og egen kjeller? Datasenterstrategi i SpareBank 1 Hvilke valg finnes mellom skyen og egen kjeller? Eivind Gjemdal Konserndirektør IT 26.11.2015 Klassifisering : ÅPEN Idégrunnlaget for SpareBank 1 Alliansen Bakgrunn Overordnede

Detaljer

Grid computing for radiologi

Grid computing for radiologi Grid computing for radiologi Wolfgang Leister Sjefsforsker, Norsk Regnesentral PACS 2005, Trondheim Grid computing for radiologi Hva er grid? Hva kan grid bidra for radiologi? Hvilke fordeler har bruk

Detaljer

Tilbakemeldinger fra Skattedirektoratet v/sits på rapporten Metoder og standarder for tjenesteorientert arkitektur i offentlig sektor.

Tilbakemeldinger fra Skattedirektoratet v/sits på rapporten Metoder og standarder for tjenesteorientert arkitektur i offentlig sektor. Tilbakemeldinger fra Skattedirektoratet v/sits på rapporten Metoder og standarder for tjenesteorientert arkitektur i offentlig sektor. Generelle tilbakemeldinger som er diskutert i dokumentgjennomgangsmøte:

Detaljer

Kunnskapsdepartementet ønsker en sikker identifisering av elever og lærere. Løsningen er Feide (Felles Elektronisk IDEntitet)

Kunnskapsdepartementet ønsker en sikker identifisering av elever og lærere. Løsningen er Feide (Felles Elektronisk IDEntitet) Kunnskapsdepartementet ønsker en sikker identifisering av elever og lærere Løsningen er Feide (Felles Elektronisk IDEntitet) Senter for IKT i utdanningen har et ansvar for innføring av Feide i grunnopplæringa

Detaljer

Smart integrasjon i offentlig sektor

Smart integrasjon i offentlig sektor Smart integrasjon i offentlig sektor En konseptuell tilnærming Rolf Jacobsen, Fagdirektør ved Brønnøysundregistrene Produktsjef Altinn Integrasjonsdagene i Halden, 4-5. september 2014 Noen eforvaltnings

Detaljer