Ötp-spåret sambruks vårmöte 2010-11-09

ÖTP-spåret Sambruks vårmöte 2010-11-09

OETP_2010-11-09_v2.ppt

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)

Lägesrapportering ÖTP v2.1

Ö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

Några exempel från ÖTP v2.1

Se dokumenten…

Matchning KSL:s 16 principer

Ex1: HRM-upphandlingEx 2: SHS-lösning

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…

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!

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

• 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".

• 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.

• 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.

• 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.

• 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


• 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.

• 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


• 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.

• 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


• Princip #10 att utfärda SAML-biljetter och konsumera SAML-biljetter i webbaserade tillämpningar som kräver autentisering och har ett samverkansintresse


• 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.

• 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.)

• 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

• 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

• 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.

• 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.

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...

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

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

• #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

• #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

• #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

• #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

• #13 PKI signering• Ej relevant här, se #4

• #14 Gränssnitt signeringsfunktioner• Ej relevant här, se #4

• #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

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

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

Ötp-spåret sambruks vårmöte 2010-11-09

Documents