ÖTP-spåret Sambruks vårmöte 2010-11-09 OETP_2010-11-09_v2.ppt.

En presentation över ämnet: "ÖTP-spåret Sambruks vårmöte 2010-11-09 OETP_2010-11-09_v2.ppt."— Presentationens avskrift:

1 ÖTP-spåret Sambruks vårmöte 2010-11-09 OETP_2010-11-09_v2.ppt

2 Agenda ÖTP-spåret kl 1030 - 1500 Inledning Lägesrapportering ÖTP v2.1 Matchning KSL:s 16 principer Kort presentation av MSKD som exempel på en delarkitektur för en kommun Diskussion kring MSKD och matchning mot ÖTP ÖTP-framtid –Bredda arbetet med ÖTP3 så det involverar flera personer som skapar? –Arkitekturspår OCH upphandlingsspår? –Göra en EA (Enterprise Architecture)? (Tiderna ska inkludera lunch och kaffe)

3 Lägesrapportering ÖTP v2.1

4 ÖTP v2.1 Introduktion till ÖTP –Utgåva kan förslagsvis fastställas Huvuddokument till ÖTP –Erfarenheter från nylig upphandling i Botkyrka kan förslagsvis inkluderas Excel-dokument där de konkreta kraven finns för upphandling. Erfarenheter från nylig upphandling i Botkyrka kan förslagsvis inkluderas

5 Några exempel från ÖTP v2.1 Se dokumenten…

6 Matchning KSL:s 16 principer Ex1: HRM-upphandling Ex 2: SHS-lösning

7 De-16 KSL (Kommunförbundet Stockholms Län) och IT-forum Stockholm –Har gett ut ”De 16 principerna för samverkan” bl.a. som en slags konkretisering till Nationella IT-strategin Det är ont om konkreta riktlinjer – förutom ÖTP – så ”De-16” har gett intresse…

8 Vad är vad? De-16 ger riktlinjer främst för infrastruktur för identifiering, för att samverkan ska kunna komma till stånd –ÖTP har vissa skrivningar om detta De-16 ger inga direkta riktlinjer för applikationssamverkan –ÖTP har omfattande skrivningar om detta Således kompletterar De-16 och ÖTP varann!

9 Ex 1: Jämförelse med De-16 i HRM-upphandlingsarbete Jämförelsen gjordes som bakgrundsmaterial till skapande av icke-funktionell kravspec som i sin tur baserades på ÖTP2.1 Upphandling av nytt HRM-system till Botkyrka Underlaget finns ute på Tend&Sign, leverantörer skriver förhoppningsvis för fullt på sina offerter just nu! Vi hinner här inte detaljerat gå igenom alla detaljer, men gör en snabb ”överflygning” med följande bilder

10 Princip #1 att utgå från SLLs & Stockholms stads metod för informationsklassning och paketera den på ett sådant sätt att den är lättillgänglig och att omvärldskraven tydligt dokumenteras Kommentar: HRM-området har inte i Botkyrka informationsklassats enligt metoden. Dock kan nämnas att HRM-systemet i huvudsak hanterar anställdas information, inte medborgares, samt att kommunens löneuppgifter i grunden är "offentlig handling".

11 Princip #2 att utgå från SLLs & Stockholms stads definition av faktorer och nivåer för informationsklassning och anpassa detta till att spegla en lägsta nivå för kommunen Kommentar: Se #1.

12 Princip #3 att likt Stockholms stad inkludera även spårbarhet som en faktor för informationsklassning Kommentar: Krav ÖTP-GIT-182-SSK-21 i de icke-funktionella kraven gäller spårbarhet.

13 Princip #4 att likställa stark autentisering med 2- faktors autentisering Kommentar: Stark autentisering har inte bedömts krävas för HRM-området.

14 Princip #5 att vid samverkan acceptera följande metoder för stark autentisering; eID, PKI med lagring av nyckelpar på SmartCard eller motsvarande och metoder baserade på engångslösenord, antingen genererade i en fysisk enhet eller säkert distribuerad till fysisk enhet Kommentar: Stark autentisering har inte bedömts krävas för HRM-området.

15 Princip #6 att tillämpa en gemensam certifikat- och utfärdarpolicy, likvärdig med SITHS, som ett minimikrav för egen eller annans PKI Kommentar: Stark autentisering (inkl PKI) har inte bedömts krävas för HRM-området.

16 Princip #7 att sträva mot en autentiseringslösning, framför flera olika, för att realisera stark autentisering i den egna organisationen samt i förekommande fall samordna detta med lösningar för inpassering, lås, flex med flera Kommentar: Stark autentisering har inte bedömts krävas för HRM-området.

17 Princip #8 att enbart acceptera SAMLv2, eller senare, vid identitetsfederering samt tydliggöra att det i förekommande fall är det enda sättet att logga in och säkerställa det inte finns någon bakväg in Kommentar: Krav ÖTP-GIT-107-SSK-16 i de icke-funktionella kraven gäller SAML.

18 Princip #9 att kravställa att varje ny webbaserad tillämpning som kräver autentisering bör ha stöd för SAML och där stark autentisering är nödvändig kräva stöd för SAML Kommentar: Krav ÖTP-GIT-107-SSK-16 i de icke-funktionella kraven gäller SAML.

19 Princip #10 att utfärda SAML-biljetter och konsumera SAML-biljetter i webbaserade tillämpningar som kräver autentisering och har ett samverkansintresse Kommentar: Krav ÖTP-GIT-107-SSK-16 i de icke-funktionella kraven gäller SAML.

20 Princip #11 att tillämpa ett gemensamt regelverk för att ingå i en federation vilket även skall omfatta alternativ som exempelvis bryggade PKI’er Kommentar: Krav ÖTP-GIT-107-SSK-16 i de icke-funktionella kraven har endast ett "helst-krav" där HRM-systemet skulle vara "master", dvs använda sig av en IdP (eller utgöra IdP). Principen är relativt långtgående, kommunen har inte definierat detta idag.

21 Princip #12 att tillämpa en gemensam katalogpolicy, med utgångspunkt från HSA policy, som ett minimikrav för egna kataloger Kommentar: Principen är relativt långtgående, kommunen har inte definierat detta idag. (I många kommunsammanhang är dessa krav troligen inte relevanta, särskilt om man beaktar kommunområden såsom biblioteket, simhallen, fritidslokalsbokning mm mm.)

22 Princip #13 att se över det egentliga behovet av faktisk PKI signering Kommentar: PKI-signering har inte bedömts krävas för HRM-området

23 Princip #14 att ställa krav på berörda tillverkare att samverka för ett gemensamt gränssnitt mot dess signeringsfunktioner Kommentar: PKI-signering har inte bedömts krävas för HRM-området

24 Princip #15 att sträva mot att all gränsöverskridande kommunikation skall ske över internet Kommentar: Upphandling syftar till en s.k. SaaS-lösning varför principen följs - krav ÖTP- GIT-SSK-1 i de icke-funktionella kraven. Krav ÖTP-GIT-81-SSK-4 vad gäller TEIS är också relevant eftersom TEIS-användningen planeras gå via Internet.

25 Princip #16 att möjliggöra kontroll av trafik till och från den egna infrastukturen i en eller få kontrollpunkter Kommentar: Trafiken planeras gå via Botkyrkas ordinarie brandväggslösning.

26 Erfarenheter Mycket bra med en checklista som De-16 att gå igenom Viktigt att tänka igenom vad av checklistan som är relevant i aktuellt fall –Ca 8 punkter hade relevans just här En hel del av De-16 har inspirerats ifrån vård/omsorg i samverkan med landstinget där kraven är höga – i andra kommunsektorer kan helt andra, lägre krav tänkas gälla. Se även debattinlägget om Facebook för inloggning på www.trendspaning.se...

27 Ex 2: Följer SHS De-16? SHS är myndighetsvärldens specifikation för säker kommunikation över Internet Andra varianter än SHS är förstås tänkbara (Web Services, REST, TEIS…) men fördelen med SHS är att det är ett ”helt paket” som redan från början är väl genomtänkt ur säkerhetssynvinkel och vad gäller formell hantering av myndighetsgränser ÖTP rekommenderar i grunden SHS för interoperabilitet kommun-myndigheter men de andra varianterna kan vara tillämpliga beroende på motpart Sambruks Multifråga (socialtjänsten) använder SHS

28 Följer SHS De-16? SHS handlar om ”samverkan” De-16 handlar om ”samverkan” Alltså logiskt: Sollentuna ville stämma av ifall användning av SHS för kommunikation för ett tidredovisningssystem i vården följer De-16

29 #1 Metod informationsklassning Kommunen använde inte just denna metod för informationsklassning men hade tänkt igenom behövet av hög säkerhet i det här sammanhanget och valde en hög nivå i form av SHS #2 Lägsta-nivå informationsklassning Se #1 Kommentar i efterhand: Lägstanivån i en kommun ska troligen vara låg, med tanke på biblioteket, simhallen, turistinformationen etc

30 #3 Spårbarhet Asynkron SHS ger mycket god spårbarhet #4 Likställa stark autentisering med 2- faktors autentisering Ej relevant, formuleringen har endast med inloggning att göra – SHS jobbar istället med kommunikation maskin-till-maskin Principen ginge att bygga ut även för s.k. trust maskin-till-maskin, sådana resonemang finns i ÖTP

31 #5 Metoder för stark autentisering Ej relevant här, se #4 #6 Certifikat- och utfärdarpolicy Ej relevant här, se #4 Maskin-till-maskin användes dock för SHS normalt Steria-cert med tillhörande policies #7 Sträva mot en autentiseringslösning Ej relevant här, se #4 #8 Enbart SAMLv2 Ej relevant här, se #4

32 #9 Webb-appl bör för SAML Ej relevant här, se #4 #10 SAML-biljetter Ej relevant här, se #4 #11 Regelverk för federation Ej relevant här, se #4 #12 Lägsta katalogpolicy Ej relevant här, se #4

33 #13 PKI signering Ej relevant här, se #4 #14 Gränssnitt signeringsfunktioner Ej relevant här, se #4

34 #15 Sträva mot att all gränsöverskridande kommunikation skall ske över internet Stämmer utmärkt med SHS (det var därför SHS skapades en gång i tiden) #16 Kontroll av trafik till och från den egna infrastukturen i en eller få kontrollpunkter Stämmer utmärkt med hur man brukar sätta upp SHS

35 Erfarenheter Som i ex 1, mycket bra med en checklista som De-16 att gå igenom Viktigt att tänka igenom vad av checklistan som är relevant i aktuellt fall –Ca 4 punkter hade relevans just här De-16 handlar inte så mycket om applikationsintegration, vilket ÖTP och SHS gör

36 MSKD som exempel på en delarkitektur för en kommun