Molnlösning i praktiken (del 3) Presentation SWEAN, 2014-01-29 Mikael Ekman, Transportstyrelsen Myndighetsövergripande IT Arkitekt, Infrastruktur
Agenda Transportstyrelsens angreppssätt Utmaningar Findings, Rekommendationer Diskussion, Q&A
Transportstyrelsens angreppssätt Molntjänst IT funktion som tjänst Styrande dokument i form av en rutinbeskrivning med beslutsgång:
Många lagar och interna riktlinjer Arkivlagen (SFS 1990:782) Säkerhetsskyddslag (SFS 1996:627 ) Offentlighets- och sekretesslagen (SFS 2009:400) Tryckfrihetsförordningen (SFS 1949:105) Personuppgiftslagen (SFS 1998:2004) EU:s dataskyddsdirektiv [EUDS01] Riktlinje för mål och styrning inom IT-området Riktlinje för IT-försörjning Riksarkivets föreskrifter Riktlinje för Transportstyrelsens informationssäkerhet Riktlinje för krav på informationssäkerhet Rutinbeskrivning för genomförande av informationsklassning Rutinbeskrivning - Styrning, mätning och revision av informationssäkerheten O.S.V..
Geografi - var informationen lagras - varifrån informationen hanteras On site: Off-site kategori 1: Off-site kategori 2: Informationen lagras i eget lokalt datacenter eller hanteras från/i en lokal kontrollerad av Transportstyrelsens skalskydd. Informationen lagras i datacenter placerat inom, respektive hanteras från plats inom, Sveriges gränser. Informationen lagras i datacenter placerat inom, respektive hanteras från plats inom, EU/ESS. Off-site kategori 3: Informationen lagras i datacenter placerat utanför, respektive hanteras från plats utanför, EU/ESS, d.v.s. i 3:e land. Ur PuL perspektiv: On site: Personuppgiftsbiträdesavtal Off site kat 1: Personuppgiftsbiträdesavtal Off site kat 2: EU:s dataskyddsdirektiv motsv..pul, dock ej sekretess Off site kat 3: Undantag som EU modellklausuler eller Safe-Harbor
Mer att hämta från Cloud Swedens Juridisk checklista för köp av molntjänster [CS01] Datainspektionens faktablad Molntjänster och PUL [DI01] MSB:s Vägledning informationssäkerhet i upphandling [MSB01] E-delegationens Juridisk vägledning för verksamhetsutveckling inom e- förvaltningen [EDEL01].
Utmaningar för organisationen -Hur ska vi kunna förutse kostnaderna? Pricing Overview for Windows Azure in Enterprise Programs Kalkylatorroll? Kostnadsfördelning? -Vägen till bredare nyttjande på utvecklingsenheten kräver styrning. Anpassning till befintliga processer eller kanske nya? Nya roller? -Att ta in t ex Azure som en produktionsplattform kräver utbildning för leveransgrupperingarna inom Drift & Infra. Anpassning av befintliga processer? (IM/CM/PM/RM o s v) Nya roller?
Utmaningar fortsättning - Informationsklassning Kravprofiler? -Backup / Gallring / Arkivering Tappa information vs inte kunna garantera att information raderats enligt lagkrav (delvis samma problem som vanligt) -Övervakning -Exit - etc.
Frågeställningar - Vilka är de olika delarna i kommunikationskedjan mot en extern (moln)tjänst? - Går det att kontrollera och förutse egenskaperna på kommunikationen över internet? - Har datahallarnas geografiska placering någon betydelse? - Vem äger internet och är motpart för ett SLA? - Finns det lösningsmönster som är att föredra / undvika?
Exempel på anropssekvens Intern användare Molntjänster 1. 2. 3. 4. Intern tjänst = Local Area Network WAN = Wide Area Network ISP = Internet Service Provider
Ingen kedja är.. INTERN ANVÄNDARE EXTERN INTERN (klient) WAN (server) ISP 1 INTERNET ISP 2 (server) MOLN
ISP Internet Service Provider INTERN ANVÄNDARE EXTERN INTERN (klient) WAN (server) ISP 1 INTERNET ISP 2 (server) MOLN
INTERNET INTERN ANVÄNDARE EXTERN INTERN (klient) WAN (server) ISP 1 INTERNET ISP 2 (server) MOLN
SLA Servicenivåer på flera punkter INTERN ANVÄNDARE 8 7 7 6 INTERN 4 (klient) WAN 5 4 (server) ISP 1 3 INTERNET SLA 1: Molntjänsten SLA 2: ISP 2 (kan inte tecknas av slutkund) SLA 3: ISP 1 SLA 4: -leverantör SLA 5: WAN-leverantör SLA 6: Leverantör av serverdrift/plattformsdrift SLA 7: Leverantör av applikationsdrift SLA 8: Leverantör av klientplattform ISP 2 2 1 (server) EXTERN MOLN
SLA? INTERN ANVÄNDARE EXTERN INTERN (klient) WAN (server) ISP 1 INTERNET INGEN SLA! ISP 2 (server) MOLN
INTERNET - Routing
INTERNET QoS (Quality of Service) INTERNET
Jitter och hopp JITTER HOPP
Bandbredd kontra Latens Länk: Latens: Bandbredd: data 10 mbit 1 ms data väntetid överföring tid 10 mbit 30 ms tid
Prestanda - slutsatser och rekommendationer Slutsats P1: Rek P1: Slutsats P2: Rek P2: Slutsats P3: Rek P3: Avstånd och placering av de olika tjänsterna är avgörande för det sammansatta systemets funktion och prestanda. Det är alltså inte bara en fråga om lagar, integritet och säkerhet. Man måste kunna kontrollera och styra var tjänsterna produceras för att kunna skapa marginaler och förutsägbarhet. Det är alltid skillnad mellan teori och praktik och det går inte att förutsäga alla egenskaper på kommunikationen eftersom de kan variera över tid. Mät och kontrollera länkarnas kvalité och värden i redan i designfasen. Mät och monitorera sedan kontinuerligt under livscykeln för att upptäcka proaktivt istället för att felsöka reaktivt. Latensen har högre inverkan på prestandan än bandbredden och längre kommunikationsförbindelse har normalt alltid latens. Efterfråga inte högre hastighet om det är latens som är problemet. Kalkylera med eventuell och varierande latens vid design och ta reda på de verkliga orsakerna vid ev tveksamheter.
Tillgänglighet - slutsatser och rekommendationer Slutsats T1: Rek T1: Slutsats T2: Rek T2: Du kan inte avtala servicenivåerna hela vägen över internet till en molntjänst. Var medveten om faktumet. Avtala servicenivåer där det är viktigt för användarna eller systemets nytta. Definiera användningsfall och mätpunkter och etablera applikationsövervakning och följ upp servicenivåerna på den. Komplettera sen med mer tekniknära övervakning för att proaktivt kunna se och åtgärda förändringar eller funktionsbortfall som kan påverka systemets egenskaper. Internet är inte en optimal plattform för sammansatta onlinetjänster där resultat ska hämtas från olika deltjänster eftersom svarstiderna kan variera mellan deltjänsterna Designa med cache där det är möjligt för och bygg in tolerans för svar med olika leveranstid eller tom helt uteblivna svar.
Förvaltningsbarhet - slutsatser och rekommendationer Slutsats F1: Rek F1: Slutsats F2: Rek F2: Om du vill behöver portabilitet eller är orolig för inlåsning hos en speciell leverantör av molntjänster måste det tas hänsyn till redan vid design. Är det en IaaS så välj en leverantör som följer Open Stack standarden. Ska integration utföras i form av meddelandehantering så välj öppna standarprotokoll. Kapsla in leverantörens API:er och presentera egna gränssnitt mot applikationen om det verkligen ställs höga krav på portabilitet eftersom det kan hjälpa till att undvika förändringar i applikationskoden vid en flytt. Olika delar i systemet kan hålla data som säkerhetskopieras med olika metoder. Detta kan innebära att informationen vid återläsning av olika delar kommer ur synk. För att försäkra sig om att man kan återläsa flera olika säkerhetskopior till en gemensam återställningspunkt måste det testas ut och tillvägagångssättet beskrivas på ett lättförståeligt sätt i driftdokumentationen.
Tillförlitlighet - slutsatser och rekommendationer Slutsats Ti1: Rek Ti1: Internet är inte en optimal grund för lösningar med spridda tjänster som kräver så kallade allt eller inget uppdateringar (ACID*). Därför krävs speciella designval göras för att säkra tillförlitligheten. Om krav ställs så hög tillförlitlighet så satsa på: a) asynkrona lösningar med till exempel leveransskydd i form av asynkront returflöde med dubletteliminering b) design enligt konceptet BASE* c) säker köhantering / avancerad omsändningshantering *ACID = Atomicity, Consistency, Isolated, Durability *BASE = Basically Available, Soft state, Eventually consistent
Bubblare - NSA och Snowden effekten - Uppdelning till mer regionalt Internet med större inflytande från enskilda stater eller FN - Alternativa Internet, betala för garanterad kapacitet
Diskussion Q & A