Arkitekturspecifikation GoS

Transkript

1 SW E D I SH E N V IR O N M EN T A L P R OT E C T IO N AG E NC Y kundtjanst@naturvardsverket.se Ärendenr: NV Arkitekturspecifikation GoS Kallonen, Kim [Datum]

2 1 (45) Innehåll 1. Introduktion Dokumentets syfte Ordlista Historik arkitektur för tillgängliggörande AFT Nyläge GVU-MCP Referenser Verksamhetsperspektiv Beskrivning av systemets mål och syfte Processbeskrivningar Behörighet och åtkomst Juridiskt perspektiv Underrättelse av anläggningsinformation Identitet och åtkomst Informationsperspektiv Övergripande beskrivning Hantering av versioner och historiska data Beskrivning Bastjänst för anläggningsuppgifter (BTSNA) Beskrivning Bastjänst för aktörsuppgifter (BTAU) Beskrivning Bastjänst för Kodlistor (BTKL) Beskrivning av sammansatt bastjänst (SSBTSNA) Kontrakt Tekniskt perspektiv Arkitektur för tillgängliggörande AFT Koncept tillfällig lösning åtkomst och behörighet GoS 1.0/MCP-release E-tjänstens integration med extern part SSBTGU samt Navet Översikt lösning BTIU Bastjänst samt BTIU Webb Tjänstebeskrivning Teknisk dokumentation SNA Informationsutbytesflöden och metoder Dokumenthistorik... 45

3 2 (45) 1. Introduktion Dokumentet beskriver, utifrån ett verksamhets-, juridiskt-, semantiskt- och tekniskt perspektiv det sammantagna arbetet som gjorts inom projekten Gemensamt gränssnitt för verksamhetsutövare, Steg 1 MCP (GVU) och Samlade nationella anläggningsuppgifter (SNA). Därav benämningen GoS (GVU och SNA). Avgränsningen har varit att hålla sig inom arkitekturdisciplinen samt att delvis beskriva och sammanfatta arbetet utifrån ett projektperspektiv. I projektens slutrapporter sammanställs samlade projekterfarenheter. En stor mängd detaljer, t. ex. textbeskrivningar för olika modeller återfinns i Sparx Enterprise Architect. Likaså kompletta arkitekturella beskrivningar ur olika perspektiv och kontext. I dokumentet har några få arkitekturella beskrivningar valts ut och ansatsen är att beskriva perspektiven för GoS 1.0/MCP-release uppdelat inom samma abstraktionsnivå och minimera hopblandningen av dessa. Inledningsvis beskrivs nylägen såsom målkoncept i stort. Därefter beskrivs underliggande abstraktionsnivåer om det finns ett behov att sätta GoS 1.0/MCPrelease nivån i ett sammanhang. Dokumentet beskriver också: Det sammantagna arbetet som gjorts vad gäller behörighetsbehov och åtkomstlösningar avgränsning är dels GoS (dvs inte hela miljösverige) och dels GoS 1.0/MCP-release. Vidareutvecklingen som gjorts inom bastjänst för inlämnade uppgifter, BTIU, och arkitektur för sammansatt bastjänst för att nå data inkommet till myndighet, SSBTIU. I denna version fokuseras inlämnande av grunduppgifter för miljöfarlig verksamhet även kallat administrativa data för verksamhetsutövare. Det tekniska perspektivets detaljerade innehåll för GoS 1.0/MCP-release återfinns inte i detta dokument. För det refereras respektive ingående tjänsts Tjänstebeskrivning Teknisk Systemdokumentation Dokumentets syfte Skapa en sammanhållen arkitekturell beskrivning av de fyra olika skikten som kan användas för att kvalitetssäkra arbete framåt, göra avvägningar inför framtida verksamhetsprioriteringar, projektavgränsningar, arkitekturella strategival samt utgöra en grund för framtagande av användarfall och onboarding till nya arkitekturen. Syftet är också att beskriva viktiga avsteg mot arkitektur inklusive motiveringar för avstegen. För en fullständig förteckning, se dokumenten som beskriver gap gentemot arkitekturen, [ref 9], samt projektens godkända och beslutade restlista, [ref 10].. Ordlista Se s IT-ordlistan: Historik arkitektur för tillgängliggörande AFT

4 3 (45) Arkitektur För Tillgängliggörande (AFT) redovisar vilka komponenter arkitekturen består av och vilka krav och styrningar som finns på arkitekturen. Arkitekturen vilar på underliggande definitioner av lösningsmönster för ingående komponenter. Genom att kombinera arkitekturens komponenter med lösningsmönster kan tydliga vyer skapas för förståelse av "nuläge/mållösning/målarkitektur".

5 4 (45) I den mån existerande tekniska lösningar är stabila, redan förankrade och har låg sannolikhet för utbyte i närtid, kan de också ingå i en mållösningsbeskrivning för att skapa ytterligare tydlighet. På lokalt plan (hos respektive myndighet) konkretiseras tekniska lösningar med utgångspunkt från faktiska behov/initiativ för att beskriva ett nuläge eller ett kommande läge.

6 5 (45) Diagrammet vill påvisa tre stora tekniska områden som definierats och som syftar till att transformationen mot en mer digitaliserad hantering av information ska kunna genomföras mer effektivt: Stöd för verksamheten (handläggning, in-/utrapportering etc) Stöd för tillgängliggörande (delning av gemensamma och öppna resurser) Stöd för kommunikation och visualisering (Webbar och sociala medier) Diagrammet nedan visar en konceptuell digital lösning för försörjning av miljöinformation genom informationsutbyten med verksamhetsutövare (VU/GVU), berörd allmänhet (BA/GBA) och andra myndigheter. Konceptet har som målsättning att påvisa alla viktiga delfunktioner för den samlade informationsförsörjningen och utgöra diskussioner om funktionalitet, delmål, transitionsplanering etc. Notera1: en viktig del i AFT är de styrande principerna dokumenterade i Sparx (referens: Arbetsmaterial.Digitalisering Nv.Krav, Principer, Vägledningar, Guider.Principer säkerhet, bastjänster, sammansatta bastjänster, information). Notera2: Arkitekturspecifikationen lyfter fram flera viktiga avsteg mot målkonceptarkitekturen. För en komplett lista se dokument GAP_analys_mål_nov2018, [ref 9]. Informationsväxel (ESB) ingår inte i denna release och därför inte heller i gap-analysen. ESB återstår till stor del att analysera och planera för.

7 6 (45) 1.4. Nyläge GVU-MCP Hur e-tjänster respektive bastjänster i GoS 1.0/MCP-release passar in i denna målarkitektur, dvs var olika tjänster hör hemma i målarkitekturen framgår av innehållet i avsnitt 5, t. ex. 5. GVU-MCP koncept och målbild Referenser Nr. Titel Plats 1. Eget utrymme är numera accepterat i esam lagmotiv men vilka juridiska krav ställs på eget utrymme? 2. Verksamhetsutveckling inom e- förvaltning 3.0 esam 3. Lösningsbeskrivning_MCP_juridik_v Modena ärende NV och NV Rättsliga förutsättningar för digitalt i esam första hand. 5. Referensarkitektur för Identitet och Inera Åtkomst. 6. Förstudie om kontaktuppgifter för 1.0 esam privatpersoner Mina kontaktuppgifter 7. Strukturerad omvärldsbevakning inom Inera arkitektur för digital utveckling 8. Juridik som stöd för förvaltningens digitalisering Statens offentliga utredningar. 9. GAP_analys_mål_nov Modena ärende NV och NV Restlista och synpunkter 1.0 Modena ärende NV och NV Bilaga Användningsfall SSBTSNA 1.0 Modena ärende NV Checklistetest BTAU infoägarskap Modena ärende NV Tjänstebeskrivning Teknisk Systemdokumentation SNA P1.3 Modena ärende NV Tjänstebeskrivning Bilaga APIbeskrivning SSBTSNA 1.0 Modena ärende NV Modena ärende BTIU Kontraktdokument NV Modena ärende BTIU Systemdokumentation NV

8 7 (45) Nr. Titel Plats Modena ärende Funktionsbeskrivning_steg P NV Verksamhetsperspektiv 2.1. Beskrivning av systemets mål och syfte Bastjänster för samlad hantering av anläggningsuppgifter på nationell nivå som möter framtida behov utifrån den svenska miljölagstiftningen är en grundsten i det digitaliserade arbetssätt som planeras inom regeringens initiativ Digitalt först - Smartare miljöinformation. Masterdatahantering av anläggningar och verksamheter inom ramen för miljöbalken och övrig miljölagstiftning ökar kvalitén på de uppgifter som hanteras inom ramen för prövning, tillsyn samt nationell och internationell rapportering. Bastjänsterna kan hålla information om många typer av anläggningar i verksamheter vilka är anmälnings- eller tillståndspliktiga, registrerings- och/eller rapporteringsskyldiga i enlighet med olika lagar och direktiv inom miljöområdet. På sikt ska bastjänsterna innefatta många olika typer av anläggningar inom miljöområdet, men initialt innefattas miljöfarlig verksamhet så att: SMP kan ersättas (A-, B-, IED-, E-PRTR- och andra anläggningar som finns idag) EU och nationell rapportering kan hanteras MCP-direktivets krav på registrering av anläggningar hanteras. Tre bastjänster har utvecklats: en bastjänst för lagring av uppgifter om anläggningar och verksamheter (BTSNA), en bastjänst för lagring av uppgifter om aktörer (BTAU) och en bastjänst för lagring av kodlistor (BTKL), samt en sammansatt teknisk bastjänst (SSBTSNA) som ger ett samlat gränssnitt för att lämna och hämta uppgifter i de tre bastjänsterna. På sikt ska bastjänsterna stödja flera olika processer, vilket nedanstående bild visar:

9 8 (45) Prövningsmyndighet Handläggning tillstånd Operativ Tillsynsmyndighet Handläggning (i Miljöreda, Castor, Ecos ) VU Företag Ansöka/Anmäla om verksamhet Underrätta om verksamhet Komplettera ansökan/anmälan/ underrättelse Lämna in miljörapport Skyltfönster (Webbplatser) e-tjänst för Ansökan/ anmälan av verksamhet e-tjänst för nya & ändrade grunduppgifter GVU e-tjänst för miljörapport Informationsväxel SNA Verksamheter Aktörer Kodlistor Samlade Nationella Tillständsuppgifter Samlade Nationella Inrapporter Process - berörd Process del av målbild IT-komponenter - initierad IT-komponenter ej initierad Bastjänst - initierad Bastjänst ej initierad Bild. Processer bastjänsterna ska stödja Behöriget/Säkerhet SMP Rapportera nationellt och internationellt Rapporteringsansvarig myndighet Tillgängliggöra information publikt Uppgifterna som lagras i bastjänsterna har lämnats in av verksamhetsutövaren, till den operativa tillsynsmyndigheten (en länsstyrelse eller en kommun) via en nationell e-tjänst eller en lokal e-tjänst och utgör del av den operativa tillsynsmyndighetens tillsynsobjektregister (enligt 7 miljötillsynsförordning (2011:13)). Genom den sammansatta tekniska bastjänsten (SSBTSNA) kan tillsynsmyndighetens verksamhetsstödsystem hämta och lämna uppgifter i de enskilda bastjänsterna (BTSNA, BTAU och BTKL). De olika tillsynsmyndigheternas information hålls separerad med hjälp av behörighetsstyrning. Rapporteringsansvarig myndighet kan också via SSBTSNA hämta uppgifter från de enskilda bastjänsterna efter att respektive tillsynsmyndighet som äger informationen i bastjänsterna BTSNA och BTAU godkänt detta.

10 9 (45) 2.2. Processbeskrivningar Konceptvy Miljöskydd Kapitlet beskriver översiktligt processen vid registrering av MCP-anläggningar, vilket är den tjänst som realiseras i GoS 1.0/MCP-releasen av GVU/SNA IED och MCP direktivet (GoS 1.0/MCP-release) När en verksamhetsutövare (VU) anmäler en anläggning/ansöker om tillstånd har det tidigare ofta varit länsstyrelsen som skapat objektet/anläggningen i enlighet med prövningsprocessen. Det är då tydligt vilken tillsynsmyndigheten är från början. Enligt MCPD ska VU underrätta om medelstora förbränningsanläggningar själv utan Samrådsförfarande. Det betyder att VU behöver kunna ange tillsynsmyndighet på den inlämnade uppgiften baserat på verksamhetens geografiska placering. Tillsynsmyndigheten kan vara en kommun eller en länsstyrelse Användningsfall för realiserade anrop Rutiner och logik som behövs för att söka, läsa, och spara data i bastjänsterna beskrivs i Bilaga Användningsfall SSBTSNA,[ref 11].

11 10 (45) Lämna in uppgifter 1. Logga in Uppgiftslämnarens identitet kontrolleras med hjälp av e-legitimation. 2. Välj organisation att lämna in uppgifter för En uppgiftsinlämnare kan ha flera organisationer och anläggningar att lämna in uppgifter för. Uppgiftslämnaren väljer det engagemang (lagrat som uppdrag i BTAU) som ska användas. Verksamhetsutövare kan även välja att skapa ett nytt engagemang. 3. Ange uppgifter Om ett tidigare skapat engagemang används förifylls uppgifter från detta. Uppgifter kan också hämtas från Bolagsverket. Följande grundläggande uppgifter hämtas då genom e-tjänsteplattformens Bolagsverkskomponent: o UD Belägenhetsadress till företaget o UD Belägenhetsadress till företagets arbetsställen o UD Benämning på företagets arbetsställen o UD Enskild näringsidkares folkbokföringsadress o UD Juridisk person postadress o UD Kommunkod säte o UD Postadress till företagets arbetsställen o UD Registrerat företagsnamn o UD SNI-koder företag o UD SNI-koder för företagets arbetsställe I övrigt anges uppgifter om anläggningen manuellt enligt nedan:

12 11 (45) Varje e-tjänst har ett specifikt syfte och vanligtvis en uppsättning specifika uppgifter som ska fyllas i. Om arbetet med att fylla i uppgifter inte avslutas vid ett och samma tillfälle finns möjligheten att mellanlagra inmatade uppgifter (arbetsmaterial) i ett sk "eget utrymme". Arbetsmaterialet kan sedan arbetas vidare med vid ett senare tillfälle. 4. Validera angivna uppgifter Steget innebär att den som lämnar in uppgifter kontrollerar och verifierar uppgifterna innan de skickas in (till den grad som tillåts med automatik). 5. Skicka in uppgifter Efter det att de uppgifterna kontrollerats skickas de in till mottagande myndighet som registrerar lämplig diariehändelse i förhållande till inrapporteringen. Inlämnade uppgifter blir därmed en inkommen handling till angiven myndighet. 6. Erhåll kvittens När underskrift har utförts och uppgifterna har skickats in erhålls kvittens på att uppgifterna är inkomna till mottagande myndighet.

13 12 (45) Godkänna/avslå. I MCP-direktivet anges att tillsynsmyndigheter har en månad på sig att ta ställning till inlämnade uppgifter. Sedan anses uppgifterna vara gällande och informationsstatus för ingående objekt sätts till Granskad automatiskt. Tillsynsmyndigheten kan inom en månad begära korrigering/komplettering, se flöde Hantera inlämnade uppgifter, och då inväntas svar från verksamhetsutövaren. Funktionen för att automatiskt godkänna uppgifter har inte implementerats Hantera inlämnade uppgifter. 1. Tillsynsmyndigheten diarieför inkommen handling och kvitterar till verksamhetsutövaren.

14 13 (45) Tillsynsmyndigheten som tar emot uppgifterna diarieför och hanterar inkommen handling. 2. Kvittera till verksamhetsutövaren Verksamhetsutövaren (och den aktör som eventuellt verkar för dennes räkning) får ett kvitto på att uppgifterna kommit in via kanal som aktören valt. I detta steg också hämtas diarienummer från myndighetens ärendehanteringssystem så att ärendet kan åberopas och följas av aktören. Kompletteras/ändras inlämnade uppgifter kan uppdaterade uppgifter kopplas till det påbörjade ärendet som ny inkommande handling. Se även avsnitt 3.1 Underrättelse av anläggningsinformation. 3. Inlämnade uppgifter OK? Tillsynsmyndigheten kan granska inlämnade uppgifter och avgöra om ändringar eller kompletteringar behövs. Kontroll av uppgifter som lämnas in kan avse kontroll av att obligatoriska fält i formuläret är ifyllda och att innehållet har rätt format. Kontrollen kan också avse att lämnade uppgifter är rimliga, t.ex. att givna koordinater ligger i Sverige. Normalflöde: Tillsynsmyndigheten granskar och accepterar uppgifterna. Alternativflöde: Tillsynsmyndigheten begär komplettering eller korrigering av inlämnade uppgifter. 4. Komplettera/ändra inlämnade uppgifter Trots automatiserade kontroller av uppgifterna kan det finnas anledning att begära ändringar eller kompletteringar. Ändring eller komplettering leder till att ny handling inkommer och hanteras i Aktivitet Registrera inlämnade uppgifter Då uppgifterna behandlats av tillsynsmyndigheten och godkänts, registreras uppgifterna genom att status ändras i registret Behörighetsperspektiv - användarscenario: Lägga upp företagarkonto inkl. verksamhetskomplex första gången. Aktivitetsdiagrammet nedan matchar processen beskriven i avsnitt Lämna in uppgifter och är en temporär första version på lösning för aktörshantering. Inget data migreras från SMP i denna release av SNA. GVU levererar inte heller en Ombudsfunktion för delegering av uppdraget att underrätta om MCP till annan uppgiftslämnare än juridiskt ansvarig. Det innebär att en användare som har loggat in med e- legitimation kan lämna in uppgifter utan att ha juridisk/avtalad rätt att göra så. För att underlätta tillsynsmyndigheters handläggning och eventuellt behov av verifiering märks den inlämnade handlingen med en status, som anger om aktörsuppgifter har förifyllts eller angivits manuellt.

15 14 (45) E-legitimeringen identifierar en fysik person. Är uppgiftslämnarens bolagsuppgifter förifyllda via Bolagsverket (SSBTGU) och grunduppgifter för bolagsfälten är låsta för modifiering

16 15 (45) anses kontot vara verifierat eftersom uppgifterna är registrerade hos Bolagsverket. Uppgiftslämnarens uppgifter kan därmed taggas som kvalitetssäkrade. Då valideringen finns företag att knyta till person båda har samma utgång oavsett om personen är firmatecknare eller inte är behovet av att tillåta företrädare att lämna in anläggningsinformation hanterat. Informationen om personen som lämnat in uppgiften är behörig att göra detta eller inte läggs automatiskt inbäddat i den inlämnade handlingen. Handlingen stämplas med information om status på förifyllnad. (Notera att informationen om förifyllnad inte läggs som metadata i syfte att hålla BTIU generell). Tillsynsmyndigheten ges därmed information om personen validerats eller inte och kan kontrollera uppgiftslämnaren genom att ringa till personen eller företaget. Attribut/status för inlämnad handling sätts default till Inlämnad (=NY) på handlingens metadata vid inlämnande. Tillsynsmyndigheten kan sedan uppdatera status till "Granskad" (=OK) respektive "Borttagen" (=NOK) på metadatat. (Notera att handlingen i sin helhet får statusen). Den status som sätts på den inlämnade handlingen sätts också på Verksamhetkomplex och Uppdrag via SSBTSNA. Väljer Tillsynsmyndigheten att inte godkänna den inlämnade handlingen motsvarar det att avveckla administratörkonton i avsnitt Administrera användare nedan. Notera att personuppgifterna i BTAU inte tas bort, det är endast tillhörande uppdrag och verksamhetskomplex som sätts som makulerade. Det beror på att samma person kan hantera flera anläggningar. E-tjänsten GVU/MCP stödjer inte andra språk än svenska, vilket behövs för att stödja eidas. Anledningen är tidsbrist såväl vad gäller att ändra hanteringen av svenska personnummer till generiskt ID som att komplettera med stöd för andra språk, t.ex. engelska. Konsekvensen är att även om en giltig e-legitimation valideras för en utländsk verksamhetsutövare tilldelas inte verksamhetsutövaren åtkomst till e-tjänsten för MCP. Verksamhetsutövaren hamnar istället i ett väntrum där det framgår kontaktinformation Diariehantering Eftersom lösningen i GoS 1.0/MCP av GVU/BTIU endast stödjer att skicka in nya handlingar i sin helhet samt att grafiskt gränssnittsstöd för aktörsadministration av behörigheter och kontaktinformation saknas blir eventuella uppdateringar av uppgifter som inte betraktas som väsentliga enligt MCPD-direktivet ändå diarieförda och hanterade som inkommen handling hos myndigheten Behörighet och åtkomst ska tillhanda IT-baserade funktioner för inloggning åt EU-medborgare, verksamheter och andra myndigheter Behoven är bl.a. att: 1. Hantera federativ/distribuerad administration av behörigheter. För utförliga detaljer, se Referensarkitektur för Identitet och Åtkomst, [ref 5]. T.ex. avsnitt 3.2 och styrande principer där IA4 t. ex. säger att:

17 16 (45) e-tjänster använder federerad identitetsdata och behörighetsgrundande information i utgivet identitetsintyg som bas för en behörighetsprofil i e-tjänsten. Vid behov kompletterar e-tjänsten med ytterligare uppgifter kopplat till användaren för att avgöra de rättigheter användaren ska ha till information och funktioner i e-tjänsten. Motiv: en gemensam bas för identitet och behörighet skapar förutsättning för god skalbarhet och minskad administrativ börda i verksamheterna. Identitets- och behörighetsadministration kan konsolideras till en funktion där en användare samlat kan ges grundläggande rättigheter att arbeta med de IT-system och den information som hens arbete eller individuella behov kräver. Även borttag av rättigheterna (t.ex. när medarbetare slutar anställning) underlättas Logga in en gång single sign on (SSO). Maskin-till-maskin (M2M). I GoS 1.0/MCP endast för GVU och manuell hantering av åtkomst se avsnitt Tillfällig API-säkerhetslösning. 2. Support för e-legitimation s.k. stark autentisering, tvåfaktorsautentisering. 3. Självbetjäning avseende administration av behörigheter är ett viktigt behov som saknas i GoS 1.0/MCP. Att ha kontroll över behörigheter, att administrera och presentera vem som har vilka behörigheter, kommer att behöva realiseras inom kort. Se vidare avsnitt Administrera användare nedan. 4. Mellan myndigheter stödja lösningsmönstret för Utlämnande på medium för automatiserad behandling, [ref 2], och möjligheten för informationsägande myndighet att reagera. Tolkningen av lösningsmönstret för utlämnande på medium är att reagera görs automatiskt vid behörighetsverifiering vid varje anrop (fortsatt giltig access eller inte) tillsammans med loggning av vem som gjort vad Ändamål Ändamålet vad gäller aktörsuppgifter i GoS 1.0/MCP är att: 1. Hantera grunduppgifter för verksamhetsutövare och Tillsynsmyndigheter/Handläggare. Hanteringen av aktörsuppgifter i denna version görs inte direkt i ett administrationsgränssnitt för aktörsuppgifter enligt punkt 4 nedan utan sker inbäddat i flödet Behörighetsperspektiv - användarscenario: Lägga upp företagarkonto inkl. verksamhetskomplex första gången. Se avsnitt ovan inklusive Diariehantering. Ändamålen vad gäller aktörsuppgifter efter GoS 1.0/MCP är att hantera: 2. Årlig Miljörapport. 3. s rapportering till bl.a. EU, som sannolikt kommer att innehålla aktörsuppgifter. 4. Administration av aktörer.

18 17 (45) 4.1. tillhandahåller (och finansierar) stödfunktionalitet avseende aktörers behörighet (roll) och information ( visitkort ) Administrera användare Administration av användare inom IED och MCP direktivet release GoS 1.0/MCP innebär att: 1. Användaridentiteter för administratörer läggs upp och kopplas till aktuellt verksamhetskonto med tillhörande uppgift samt roller. 2. Avveckling av administratörkonton handlar (minst) om att: 2.1. Stänga av administrativa användaridentiteter och alla de användaridentiteter som ärver rättigheter via den administrativa användaridentiteten. Administration av användare efter IED och MCP direktivet release GoS 1.0/MCP innebär att avveckling av administratörkonton handlar om att: 2.2. Ta reda på om och vad som behöver bevaras i förhållande till den administrativa användaridentiteten Ta bort all överskottsinformation (gallring). Diagrammet visar identifierat behov av huvudsakliga administrationsflöden med ytterligare uppdelning i delaktiviteter Användarscenario och aktiviteter. Användarscenario som supportas inom IED och MCP direktivet release GoS 1.0/MCP:

19 18 (45) (De utgråade elementen representerar fler användarscenarios som behöver supportas efter release GoS 1.0/MCP.) Aktiviteter i samband med MCP underrättelse. Lägga upp företagarkonto inklusive verksamhetskomplex första gången, se avsnitt Behörighetsperspektiv - användarscenario: Lägga upp företagarkonto inkl.

20 19 (45) verksamhetskomplex första gången. som är en temporär lösning för GoS 1.0/MCP. I framtiden är VUAdmin respektive Uppgiftslämnare två olika roller, en roll lämnar in uppgifter och den andra rollen lägger upp i VU-konto. Detta ska kunna göras separat eller ihop. 3. Juridiskt perspektiv Se Lösningsbeskrivning MCP juridik v1.0, [ref 3], för juridisk beskrivning av respektive tjänst. Kommande avsnitt i detta kapitel syftar till att lyfta fram vad som levereras i GoS 1.0/MCP och behov av vidareutveckling i kommande releaser Underrättelse av anläggningsinformation Utveckling kort och lång sikt Aktiveten avser utveckla kort sikt: En bastjänst för inlämnade uppgifter (BTIU), som utgör tillsynsmyndigheternas och s delade anvisade mottagningsställe för inkommande handlingar och som stödjer lösningsmönstret för Utlämnande på medium för automatiserad behandling. o Anvisat mottagningsställe=en funktion där den som tillhandahåller en servicetjänst eller en bastjänst mottar handlingar, ankomstregistrerar dem och sänder kvittens. Aktiveten avser utveckla längre sikt. När andra myndigheter har publicerat API:er att integrera mot kan en sammansatt bastjänst för inlämnade uppgifter (SSBTIU) utvecklas. En sammansatt bastjänst som möjliggör egen hämtning till eget utrymme av tidigare inlämnade uppgifter samt initierar en diariehändelse om inkommen handling hos rätt tillsynsmyndighet eller vid inlämning automatiskt skapar diariehändelse där olika ärendeidentiteterna matchas. Bastjänst BTIU registrerar handlingens inkommandetidpunkt och lagrar inlämnade uppgifter på strukturerad form (det formulär som använts för insamlingen) och en PDFsammanställning över inlämnande uppgifter. Används eunderskrift vid inlämnandet lagras den också. För avsteg från detta, se vidare avsnitt Avsteg från BTIU målarkitektur. Den sammansatta bastjänsten SSBTIU lagrar ingen information. Både SSBTIU och BTIU ingår i den tekniska tjänst som håller endast som led i teknisk bearbetning eller lagring för tillsynsmyndigheternas räkning. Samtidigt är BTIU mottagnings- och lagringsställe för inkommande handlingar till där lösningsmönstret matchar Utlämnande på medium för automatiserad behandling. Behörigheter separerar åtkomsten till handlingar så att kommer åt handlingar inkomma till och respektive tillsynsmyndighet sina handlingar.

21 20 (45) 3.. Legalitetsprincipen erbjuder de nationella bastjänster BTSNA, BTAU, BTKL, BTIU och SSBTSNA samt den nationella e-tjänsten som tekniska tjänster utifrån sitt särskilda ansvar för att utveckla, följa upp och samordna arbetet med miljöinformationsförsörjning (Förordning (2012:989) med instruktion för ) och är en följd av den myndighetssamverkan på miljöområdet som pågått sedan 2014 inom ramen för IEDprogrammet och sedan 2016 inom ramen för s regeringsuppdrag Digitalt Först Smartare Miljöinformation. ansvarar i egenskap av teknisk tjänsteleverantör för att tillhandahålla det samlade tjänsteerbjudandet. Förordning (2018:471) om medelstora förbränningsanläggningar (FMF) genomför huvuddelen av direktiv 2015/2193/EU (MCP-direktivet) om begränsning av utsläpp till luft av vissa föroreningar från medelstora förbränningsanläggningar. Direktivet innehåller krav för utsläpp till luft av stoft, kväveoxider och svaveldioxid. Det finns också krav på registrering och att medlemsstaterna ska föra ett register över alla medelstora förbränningsanläggningar. FMF trädde i kraft den 1 juni Enligt 18 FMF ska den som driver eller avser att driva en medelstor förbränningsanläggning informera tillsynsmyndigheten om anläggningen. Informationen ska lämnas i en e-tjänst som tillsynsmyndigheten anvisar och innehålla vissa uppgifter. I s rapport om förslag till genomförande av MCP-direktivet ingår att utvecklar och tillhandahåller en nationell e-tjänst och en nationell databas där de inhämtade uppgifterna lagras för tillsynsmyndigheternas räkning. Databasen utgör den gemensamma tekniska lösningen för de register över medelstora förbränningsanläggningar som tillsynsmyndigheterna är skyldiga att föra. Enligt 21 FMF får en medelstor förbränningsanläggning inte vara i drift utan att vara registrerad. Hur bestämmelsen tillämpas framgår av övergångsbestämmelserna. Enligt 23 FMF ska tillsynsmyndigheten offentliggöra uppgifter ur registret på en webbplats som tillhör myndigheten och som allmänheten har tillgång till. Uppgifter om personnummer, födelsedatum och bostadsadresser får dock inte offentliggöras Personuppgiftsansvar Tillsynsmyndigheten, som bestämmer syfte och ändamål med hanteringen av anläggningsuppgifter MCP, är personuppgiftsansvarig för information som samlas in via de nationella e-tjänsterna och lagras i BTIU., som tillhandahåller en teknisk tjänst, blir personuppgiftsbiträde åt Tillsynsmyndigheten Avsteg från BTIU målarkitektur Juridiskt lösningmönster Då BTIU är en driftsatt tjänst har projektet utgått från att det juridiska lösningsmönstret är beskrivet korrekt och att andra kvalitetsegenskaper är säkerställda i redan driftsatt lösning.

22 21 (45) Inga underskrifter Då e-tjänsten GVU/MCP inte levererar stöd för underskrifter kommer följaktligen dessa inte att lagras. MCPD ställer inte krav på e-underskrifter, men i kommande versioner av BTIU behöver stöd för e-underskrifter utvecklas Strukturerad formulärdata. Detsamma gäller även inlämnade uppgifter på (semi)strukturerad form (förutom PDF). Det formulär som använts för insamling skickas inte med i form av XML-representation i GoS 1.0/MCP. BTIU sparar objekt och data i form av key-value-pairs. XML-representationen kommer att behöva utvecklas i kommande versioner. Notera1 att versionen (2.0) av BTIU som levereras i GoS 1.0/MCP stödjer lagring av XML (och PDF). Notera2 att kommande versioner för t.ex. inlämning av miljörapporter där det finns beroende till gällande regelverk/lagar är det nödvändigt att skicka med formulär-xml för att kunna hämta föregående års rapporter i sin helhet. Analyser under projektet pekar på att flödet och mellanlager blir ett annat asynkront via SHS-tjänsten Vidareförmedlingstjänst SSBTIU. Åtkomst via GUI istället för tekniskt gränssnitt/api. Tjänsten för Plastbärkassar i förvaltning anpassades till att även hantera inlämning av MCP-underrättelser. *Notera: BTIU anropas av SSBTSNA och inte av SSBTIU. Se även utvecklingsbehov längre sikt ovan Identitet och åtkomst BTAU release GoS 1.0/MCP BTAU tillhandahålls av för förvaring av handlingar endast som ett led i teknisk bearbetning eller lagring för de operativa tillsynsmyndigheternas räkning.

23 22 (45) BTAU utmaning framåt Användningsfallet ovan, P5 Hantera administrativa konton, påverkar lösningsmönstret i release GoS 1.0/MCP, eftersom delade konton (konton för hela verksamheten/organisationen/företaget) hanteras. Frågan är vilket juridiskt lösningsmönster som gäller för delade konton. Användaridentiteter för administratörer ska kunna läggas upp och kopplas till aktuellt verksamhetskonto. Likaså ska administratörskonton kunna avvecklas. Att avveckla administratörkonton handlar (minst) om att: - Stänga av administrativa användaridentiteter och alla de användaridentiteter som ärver rättigheter via den administrativa användaridentiteten. - Ta reda på om och vad som behöver bevaras i förhållande till den administrativa användaridentiteten. - Ta bort all överskottsinformation (gallring). Aktörsuppgifter är antagligen två delar: 1. En stödtjänst för teknisk funktionalitet med behörigheter, dvs drifts- och säkerhetsrelaterad information. 2. Ett verksamhetssystem, dvs nyttoinformation som används i ändamålen enligt avsnitt Hur ska detta diariehanteras? Jämför t.ex. med Skatteverkets tjänst för att ändra sitt personliga bankkonto kopplat till skattekontot för utbetalning. Vem är informationsägare här? Ska

24 23 (45) ändringen betraktas som en inkommen handling? Dvs, inkommen handling vid uppdatering av inrapportörs uppgifter, inkl. kontaktinformation (visitkortsinformation)? Ändras uppgifter frekvent blir det många inkomna handlingar. Idag uppdaterar också Tillsynsmyndigheten kontaktuppgifter för verksamhetsutövaren. Hur ska de få åtkomst till uppgifterna framdeles? Krävs separat överenskommelse/samtycke? Rekommendation Matcha juridiskt lösningsmönster för BTAU med Servicetjänst / Eget utrymme som beskrivs i Rättsliga förutsättningar för digitalt i första hand, [ref 4] se även avsnitt nedan om Förstudie om kontaktuppgifter för privatpersoner Mina kontaktuppgifter. Eget utrymme tillhandahålls som en service åt användaren. Ingen annan ska få insyn i det material som användaren har där. Utrymmet ska samtidigt, genom stöd och service, såsom förifyllnad, automatiska och logiska avstämningar, hjälptexter, etc. underlätta för användaren att upprätta och ge in korrekta och fullständiga ansökningar, deklarationer och andra handlingar. Det förekommer också utrymmen som ger stöd åt användare utan att något skickas in till den som tillhandahåller utrymmet. Utkast och liknande handlingar förblir användarens egna handlingar och blir inte att anse som allmänna enligt tryckfrihetsförordningen eller inkomna enligt förvaltningslagen så länge de finns i utrymmet och kriterierna för sådant utrymme är uppfyllda. Uppgifter som finns där ska inte heller annars riskera att röjas genom åtgärder av myndigheten eller myndighetens personal. Genom egna utrymmen skapas således en allmän tillit till elektroniska tjänster samtidigt som de erbjuder en tillräcklig säkerhet för användaren och förenklar dennes vardag. Det innebär t.ex. att tillsyns- och/eller prövningsmyndigheter inte direkt ska hantera verksamhetsutövarens aktörsuppgifter. De ska endast kunna hantera sina egna aktörsuppgifter och uppgifter kopplade till anläggningen via maskin-maskin kommunikation. Notera att även om tillsyns- och/eller prövningsmyndigheter inte direkt ska hantera verksamhetsutövarens aktörsuppgifter kommer aktörsuppgifternas giltighet indirekt att hanteras, se även beskrivningen i avsnitt ovan. Om BTAU är ett eget utrymme kan en framkomlig väg för myndigheterna att ändå få ta del av uppgifter vara att företagarna/personerna i BTAU, ger sitt samtycke till att uppgifter (främst kontaktuppgifter) får användas av myndigheterna i situationer då myndigheter behöver ha korrekta roll- och kontakt-uppgifter för att de ska kunna fullgöra sina respektive åtaganden gällande företagen. Rättsfiguren (kombinationen av rättsregler, händelser och fakta) för delar av aktöruppgifter kan liknas vid ett serviceskede, dvs. ett skyddat förlopp där en användare hanterar uppgifter för att service ska kunna ges enligt förvaltningslagen. Ingen utomstående avses då ha insyn (notera utan samtycke) i de uppgifter som behandlas och det sker inte heller någon ärendehandläggning.

25 24 (45) Om aktörer är (och kan vara?) informationsägare i analogi med eget utrymme (se även Checklistetest för BTAU infoägarskap, [ref 12],) skulle en framkomlig väg kunna vara endast uttag med stöd av Utlämnande på medium för automatiserad behandling inkl. samtycke enligt ovan även om det är konflikt med beskrivningen i avsnitt ? Förstudie om kontaktuppgifter för privatpersoner Mina kontaktuppgifter? Se förstudie Förstudie om kontaktuppgifter för privatpersoner Mina kontaktuppgifter, [ref. 6]. Där nämns Rättsliga förutsättningar för genomförande och Modell kring eget utrymme för privatpersonens egen administration av kontaktuppgifter. Från slutsatsen hämtas följande citat. Den juridiska analys som utförts under förstudien har inte kunnat påvisa tillvägagångssätt som med stor sannolikhet inte skulle medföra risk för offentliggörande. Det verkar här som lagstiftningen på ett paradoxalt sätt försvårar eller kanske till och med omöjliggör införandet av en frivillig delningstjänst för kontaktuppgifter. Vi avvaktar därefter behov av bättre juridiska förutsättningar/lagändring bevaka/förbereda , se [ref. 7]. I ett nyläge kunde BTAU spegla beskrivningarna i förstudierapportens avsnitt b där det beskrivs: Ett alternativ skulle kunna vara att använda eget utrymme för en individs kontaktuppgifter. I så fall måste emellertid individen sannolikt själv lämna ut uppgifterna ur utrymmet för att innehållet inte ska bli allmän handling. Tjänstekonsumenterna använder delningstjänsten på ett sådant sätt att det krävs svar direkt, utan att en reaktion från den registrerade individen kan avvaktas. Det är idag ännu inte prövat i domstol om individens utlämnande av uppgifter från Eget utrymme får ske genom automatiserad behandling av regler som den enskilde upprättat och förvarar i tjänsten. Dessa regler skulle kunna vara samtycke med tillhörande beskrivande texter i e-tjänster Rättspraxis Se Eget utrymme är numer accepterat i lagmotiv men vilka juridiska krav ställs på eget utrymme?, [ref 1], där följande text återfinns. I propositionen (2016/17:198 s. 16) har regeringen anfört att det finns stöd i praxis för att myndigheter tillhandahåller digitala tjänster som uppfyller kraven i 2 kap. 10 första stycket TF. Regeringen har därvid hänvisat till RÅ 1994 ref. 64 och HFD 2011 ref. 52 samt förklarat att myndigheternas möjlighet att själva besluta om utformningen av sina tjänster innebär att de kommer att kunna utveckla och anpassa sina tjänster efter eventuell ytterligare rättspraxis. Samtidigt har regeringen noterat att det inte finns vägledande avgöranden som ger tydligt besked, i fråga om vilka av de egna utrymmen som myndigheter tillhandahåller, som uppfyller kraven enligt 2 kap. 10 första stycket TF. Regeringen har emellertid hänvisat till en dom den 26 oktober 2015 av Kammarrätten i Stockholm (mål nr ) där handlingar som förvarats i en CV-databas hos Arbetsförmedlingen, ansetts vara förvarade hos myndigheten endast som led i teknisk bearbetning eller teknisk lagring för annans räkning. Som ytterligare exempel på att juridiken här har brister, se även Juridik som stöd för förvaltningens digitalisering, [ref. 8], där följande text återfinns Exempel: De ärendeslag som hanteras inom en och samma myndighet kan spänna över ett stort och mångfacetterat område. Om personuppgifter som enskilda lämnat till myndigheten inom ramen för ett

26 25 (45) ärendeslag ska kunna behandlas inom ramen för ett annat ärendeslag behöver det finnas rättsligt stöd i dataskyddsregleringen för behandlingen för det nya ändamålet Frågor att beakta Vilken information avseende åtkomst är eventuellt nyttoinformation och behovet av en mottagningsfunktion: 1. Det är svårt att påvisa att objektet "Representationsuppdrag" i BTAU, som innehåller uppgifter om hur företagarna delegerar sina uppgifter mot myndigheterna, är en information som myndigheterna har behov av. I olika situationer är naturligtvis kontaktuppgifter av intresse, men de skulle kunna inhämtas från andra håll. 2. En annan oklar frågeställning är till vilken myndighet åtkomstuppgifterna ska inkomma. Samma persons kontaktuppgifter kan ju t. ex. relateras till flera anläggningar i olika län/kommuner. Till vilket län/kommun ska uppgifterna då inkomma? 3. Delegering av uppgifter är något myndigheterna inte bör ha något att göra med. Delegeringen bör därför sannolikt inte ses som en inkommen handling till myndighet där myndigheten måste ta beslut om delegeringen är korrekt, varken manuellt eller automatiskt Personuppgiftsansvar Från Verksamhetsutveckling inom e-förvaltning 3.0, [ref 2], hämtas följande text. Sammanfattning: De aktörer som berörs av it-baserade tjänster och tillhörande kanaler för att nå egna utrymmen eller transportkanaler för att ge in handlingar behöver klargöra mellan sig vem eller vilka som har personuppgiftsansvaret för respektive del och vad ansvaret innebär i olika avseenden, bl.a. säkerhetsmässigt och när underleverantörer anlitas. Om en tjänst kan bygga på att samtycke ges för personuppgiftsbehandling eller för att sekretessreglerade uppgifter ska få lämnas ut måste rutinerna för samtycke utformas så att giltiga samtycken uppkommer. Vidare från [ref 2]. Att särskilt observera: En myndighet som tillhandahåller eget utrymme åt enskilda bör införa sådana tydliga förbud för befattningshavare mot att ta del av eller annars använda innehållet i enskilds eget utrymme att den som bryter mot förbudet gör sig skyldig till dataintrång. Det kan emellertid också behövas ett skydd för material som blir tillgängligt för den som arbetar med utveckling och drift av egna utrymmen så att han eller hon inte får röja uppgifter som finns i ett sådant utrymme. I verksamhet för enbart teknisk bearbetning eller teknisk lagring för någon annans räkning gäller också en bestämmelse om förbud mot att lämna ut handlingar och om tystnadsplikt för befattningshavare (40 kap. 5 OSL). Skyddet gäller visserligen bara för uppgift om en enskilds personliga eller ekonomiska förhållanden men det är från år 2018 inte längre begränsat till personuppgifter även t.ex. företagsuppgifter skyddas (se prop. 2016/17:198). Här betraktar projekten det som beställning ur s servicekatalog och är redan reglerat.

27 26 (45) BTAU, BTIU, BTSNA Se Lösningsbeskrivning_MCP_juridik_v1.0, [ref 3], för beskrivning av bl. a. personuppgiftsansvaret. Tillsynsmyndigheten, som bestämmer syfte och ändamål med hanteringen av anläggningsuppgifter MCP, är personuppgiftsansvarig och att som tillhandahållare av en teknisk tjänst blir personuppgiftsbiträde åt Tillsynsmyndigheten. 4. Informationsperspektiv Övergripande informationsmodell med fokus på anläggning : (Notera: svenska begrepp visas detta gäller informationsmodeller, för datamodeller ska svenska vara alias då engelska termer matchande Inspire används som r egel.) 4.1. Övergripande beskrivning Bastjänsterna är informationskällor som innehåller uppgifter inom ett antal områden: anläggningar, aktörer, och koder. En bastjänst innehåller en databas samt viss logik bl.a. för anrop och valideringar. Tjänsterna anropas med fråga-svarstyp maskin-till-maskin där uppgifter om anläggningar med tillhörande kodlistor och aktörsuppgifter kan efterfrågas samt uppdateras av behörig användare för tjänsten.

28 27 (45) För att underlätta användning av bastjänsterna finns en sammansatt bastjänst etablerad. Den sammansatta bastjänsten har logik för att anropa flera bastjänster, och hålla ihop transaktioner så att alla delar genomförs eller rullas tillbaka vid fel detaljerad beskrivning i Tjänstebeskrivning Bilaga API-beskrivning SSBTSNA, [ref 14]. Den sammansatta bastjänsten exponeras utåt så att olika kategorier av användare, även utanför kan använda den. De enskilda bastjänsterna exponeras enbart via den sammansatta bastjänsten, alternativt genom andra sammansatta bastjänster som kan tillkomma i framtiden Hantering av versioner och historiska data Bastjänsterna ska innehålla historiska data. Det ska vara möjligt att hämta de uppgifter som gäller/gällde vid en viss tidpunkt i dåtid, nutid och i viss mån även framtid med data som lagts in i förväg. Databasen är uppbyggd så att inlagda instanser av respektive objekt aldrig tas bort vid förändringar. De ersätts istället av nya instanser, vilket möjliggör hämtning av historiska data och också att i förväg lagra kommande förändringar. Vid arbete med data behövs då tydliga sökkriterier som alltid returnerar rätt instans av ett objekt, eftersom det kan finnas flera instanser lagrade. Följande kriterier styr att rätt instans returneras: Start- och end date anger inom vilket tidsintervall en instans av ett objekt är gällande. Det finns alltid bara en instans av objektet som gäller vid varje tidpunkt. Uppgiftsstatus anger den inlämnade uppgiftens läge i processen. Den kan vara inkommen, granskad eller borttagen. Borttagen uppgift visas normalt inte i sökningar. Teknisk status anger i vilket tillstånd utrustningen och platsen är vid en viss tidpunkt, men påverkar inte vilka objekt som hämtas vid en sökning, om man inte specifikt väljer att ange kriterier för teknisk status. Legal status finns också på vissa objekt, men påverkar inte vilka objekt som hämtas vid en sökning. För de fysiska objekten verksamhetskomplex, anläggningsplats, installation och installationsdel är den instans där efterfrågat datum ligger mellan start och end-date den som hämtas vid utsökningar. Om instansen gäller tills vidare är inte end-date satt. Data som lagras i andra tabeller - som status, geografi, och koder - ska kopplas till instansen. Det betyder att man måste ha med alla uppgifter som ska gälla i anropet som skapar den nya instansen. Geografi, adress och koder som kopplats till tidigare instanser gäller inte längre. De måste vara med i anropet även om uppgiften i sig är oförändrad Beskrivning Bastjänst för anläggningsuppgifter (BTSNA) Syfte BTSNA är en bastjänst som innehåller uppgifter om anläggningar och tekniska installationer som är involverade i miljöfarlig verksamhet Funktion BTSNA har information om anläggningar i flera nivåer: Verksamhetskomplex, Anläggningsplats, Installation och Installationsdel. Alla lagrade objekt får unika ID. De får

29 28 (45) dels ett ObjektID och dels får objekt av ovanstående typ dessutom ett Inspire-ID som används vid rapportering till EU samt vid publicering av geodata. Detta ger möjlighet att koppla beskrivande information till rätt nivå i modellen. Den beskrivande information som anges på respektive nivå är geodata, adresser, administrativa uppgifter och miljörelaterade koder av olika slag. Installationsdel är olika bestyckat med attribut beroende på vilken typ av installationsdel det är. Pannor och utsläppspunkter av olika slag har en grunduppsättning av information, men utöver detta har t.ex. MCP-pannor ett tiotal attribut som är specifika för denna typ av installationsdel. Verksamhetskomplex, installation och anläggningsplats är däremot i stort sett helt generella Beskrivning av databasmodell 4.4. Beskrivning Bastjänst för aktörsuppgifter (BTAU) Syfte BTAU är en bastjänst som innehåller uppgifter om de organisationer och företag (aktörer) och personer som är involverade i tjänster som erbjuds. En persons eller aktörs uppdrag definierar vilken roll denne har och förhållandet till andra objekt. Ett representationsuppdrag kan innehålla rättigheter att behandla data i någon eller några tjänster, men det måste inte vara så (se t.ex. uppdraget Kontaktperson ) Funktion För att förstå hur BTAU är tänkt att användas är funktionen beskriven i form av User stories. Det finns tre typer av representationsuppdrag: Aktörsuppdrag

30 29 (45) En aktör är en juridisk person som verkar i relation till verksamhetskomplex (eller annat objekt). User story: Som aktör ska jag kunna ha uppdrag i förhållande till ett eller flera verksamhetskomplex för att avspegla ansvarsförhållanden. Acceptanskriterier: Varje verksamhetskomplex ska ha en aktör med rollen verksamhetsutövare och en aktör med rollen tillsynsmyndighet kopplade till sig. Exempel: SSAB (aktör) är verksamhetsutövare för Oxelösunds stålverk (verksamhetskomplex), och Länsstyrelsen Södermanlands län (aktör) är tillsynsmyndighet. Personuppdrag En person (fysisk) kan ha uppdrag gentemot ett verksamhetskomplex. User story: Som person vill jag kunna ha uppdrag i förhållande till ett eller flera verksamhetskomplex så att det framgår vem som har ansvar för olika uppgifter. Acceptanskriterier: När man hämtar information om en anläggning ska det framgå vem som är kontaktperson. En person som har behörighet som uppgiftslämnare ska kunna rapportera för ett verksamhetskomplex. Exempel: Peter Persson (person) är uppgiftslämnare för Oxelösunds stålverk och har rättighet att rapportera för detta verksamhetskomplex. Administrationsuppdrag En fysisk person kan ha i uppdrag att administrera en aktör. (För att arbeta i den typen av uppdrag krävs att det finns en e-tjänst för administration av aktörer, vilket inte ingår i GoS 1.0/MCP-releasen). User story: Som person med administratörsroll vill jag kunna administrera alla uppdrag som gäller en viss aktör så att självservice uppnås, och myndigheter slipper en onödig administrativ börda. Acceptanskriterier: Det ska alltid finnas minst ett administratörsuppdrag kopplat till varje aktör. Administratören kan administrera uppdrag av alla slag som kopplade till aktuell aktör.

31 30 (45) Administratören kan även lägga upp en annan administratör om han vill lämna över sin administratörsroll. Administratören kan inte ändra sin egen roll. Det måste någon annan administratör göra. Exempel: Det är Hugo Bylund som är administratör för SSAB, och är den som har lagt upp Peter Persson som uppgiftslämnare för Oxelösunds stålverk. Han kan vid behov lägga upp en ny uppgiftslämnare parallellt med Peter och om han så önskar avsluta Peters uppdrag Vid förändringar i data Uppgifter i andra bastjänster, t.ex. uppgifter om verksamhetskomplex i BTSNA ska kunna ändras utan att uppgifter i BTAU berörs. Om uppgifter i något objekt i BTAU ändras ska kopplingarna mellan objekt i BTAU och kopplingar till objekt i andra bastjänster, t.ex. BTSNA bibehållas Beskrivning av databasmodell

32 31 (45) Beskrivning av anrop Se dokumentet Tjänstebeskrivning Bilaga API-beskrivning SSBTSNA, [ref 14] Beskrivning Bastjänst för Kodlistor (BTKL) Syfte BTKL är en bastjänst som innehåller kodlistor av olika typ som ska kunna användas av olika formulär. BTKL är utformad för att kunna hantera förändringar i kodlistors innehåll över tid. Det ska vara möjligt att retroaktivt arbeta med formulär som har gällt tidigare och i dessa ska de kodlistevärden som gällde då formuläret var aktuellt presenteras Funktion BTKL har skapats utifrån följande funktionella krav: 1. BTKL ska innehålla de kodlistor som är generella och används i flera tjänster. 2. Som administratör ska jag kunna lägga till nya kodlistor, inklusive de värden som ska gälla. 3. Som administratör ska jag kunna lägga till nya värden som gäller från ett visst datum i en befintlig lista. 4. Som administratör ska jag kunna ta bort ett värde ur en lista from ett visst datum. 5. Som uppgiftslämnare ska jag kunna hämta olika versioner av en kodlista med hjälp av att ange kodlistans ID alternativt namn, samt datum, så att t.ex. en listruta i ett formulär som gäller för fjolåret innehåller de värden som gällde då. 6. Som uppgiftslämnare ska jag kunna hämta ett värdes benämning på engelska. 7. Som uppgiftslämnare ska jag kunna hämta ett värdes alternativa benämning på svenska. 8. Som uppgiftslämnare ska jag kunna hämta ett värdes beskrivande text. 9. Som uppgiftslämnare ska jag kunna hämta kodlistor med flera nivåer, t.ex. för län som har kommuner som underindelning. Om län är valt ska endast kommuner inom valt län vara valbara. 10. (Krav som tillkommit, och ännu inte realiserats. En kodlista ska endast kunna administreras av en utpekad ägare och en övergripande systemadministratör.) Datamodell för kodlistor

33 32 (45) Det är möjligt att välja ut en kodlista, hämta alla de värden som är gällande och visa dem som valbara alternativ i ett formulär. Om kodlistan har flera nivåer kan man välja ut värden som är sorterade under ett visst värde som valts (tabellen värderelation ovan), t.ex. alla kommuner som är sorterade under ett län Beskrivning av sammansatt bastjänst (SSBTSNA) Övergripande beskrivning Sammansatt bastjänst för samlade nationella anläggningsuppgifter (SSBTSNA) innehåller ett sammanhållet API för åtkomst till data i bastjänsterna. SSBTSNA håller samman transaktioner så att alla delar genomförs eller rullas tillbaka vid fel. SSBTSNA döljer viss funktionalitet för anropande part. T.ex. kan ett uppdrag skapas genom ett anrop, men i realiteten krävs att det sker kontroll att berörd person eller aktör finns i BTAU, annars skapas personen eller aktören, och först när dess objekt-id har returnerats skapas själva uppdraget. Här sker även loggning av transaktioner detaljerad beskrivning i Tjänstebeskrivning Bilaga API-beskrivning SSBTSNA, [ref 14]. Förutom åtkomst till bastjänsterna BTSNA, BTAU, och BTKL kan Bastjänst för inlämnade uppgifter (BTIU) anropas. BTIU är en befintlig tjänst som hanterar inkommande uppgifter från andra e-tjänster, men har anpassats något för att kunna hantera även MCP-underrättelse och registrering.

34 33 (45) Funktion SSBTSNA tar emot anrop via sitt API. Tjänsten anropar i sin tur de berörda bastjänsterna. I vissa fall vidarebefordras inkommande anrop, och i andra fall krävs flera anrop till underliggande bastjänster för att åstadkomma efterfrågad funktion. Tjänsten svarar via API om anropet har lyckats eller ej. Om anropet har misslyckats återställer SSBTSNA alla påbörjade bastjänstanrop. Anrop loggas Omgivning I huvudsak ska SSBTSNA anropas från e-tjänster och handläggarsystem internt och externt. SSBTSNA ska i sin tur kommunicera med bastjänster. I dagsläget finns ett undantag, som antas vara tillfälligt. BTIU får idag svar från tillsynsmyndigheter som kan leda till att status för anläggningar i BTSNA ska ändras. I nuläget anropar BTIU SSBTSNA för att åstadkomma detta. Detta är ett avsteg från arkitekturen, som förväntas återställas i och med att tillsynsmyndigheternas handläggarsystem börjar anropa via API Beskrivning av datamodell Datamodell för API beskrivs i Tjänstebeskrivning SSBTSNA, och Kontraktdokumentation SSBTSNA, [ref 14] Beskrivning av anrop Anrop och svar beskrivs i Tjänstebeskrivning SSBTSNA, [ref 14] Beskrivning av integrationer till andra applikationer Bastjänsterna är passiva komponenter i en arkitektur där andra system och komponenter ska kunna läsa och uppdatera bastjänsternas data med hjälp av API-anrop Kontrakt Se Tjänstebeskrivning Bilaga API-beskrivning SSBTSNA, [ref 14]. 5. Tekniskt perspektiv Syftet med detta kapitel är förutom det tekniska perspektivet av projektstatus och arkitektur att matcha Obligatoriska artefakter vid milstolpar och Avsteg från teknikstrategi med motiveringar. I avsaknad av aktuell teknikstrategi antas att beskrivningarna här matchar följande citat från IT Strategi: "Utveckla och tillgängliggör en ändamålsenlig arkitektur för digital samverkan inom miljösverige" samt "Använd arkitekturstyrning och löst kopplade komponenter för återanvändning och effektiv utveckling". Nedan följer det tekniska perspektivet och hur det är konstruerat.

35 34 (45) 5.1. Arkitektur för tillgängliggörande AFT Hur hänger alla "e-tjänster" och bastjänster (BT/SSBT) ihop?

36 35 (45) 5.. GVU-MCP koncept och målbild

37 36 (45) För detaljerade beskrivningar rekommenderas bl.a. dokumentet Funktionsbeskrivning_steg P, [ref 17] Koncept tillfällig lösning åtkomst och behörighet GoS 1.0/MCP-release. En NV-ägd IdP har ännu inte realiserats. I den tillfälliga lösningen gör istället e- tjänsten/sammansatt bastjänst ett extra anrop mot Aktörs-tjänsten för att läsa upp rollerna och lagra dem i ett eget user -objekt. Det innebär att e-tjänsten gör behörighetsdelar av IdPjobbet men utanför SAML. Det är steg nr 4 ovan som istället för SAML-transport/paketering använder vanlig SOAP/XML där personnr är attribut/parametrar. Det som förloras är delad tillit/sso, men i vårt fall innebär det inga extra inloggningar och så länge alla bokomliggande system är i s kontroll kan tjänsteanropen göras pålitligt. Trafiken är skyddad med SSL/TLS Tillfällig API-säkerhetslösning För AFT bör API-säkerheten definieras för att säkerställa tillit, i sin enklaste form APInycklar. Det arbetet återstår, eftersom det prioriterades bort p g a tidsbrist. Lösningen IP låsning med SSL/TLS, bedömdes vara acceptabel.

38 37 (45) 5.3. E-tjänstens integration med extern part SSBTGU samt Navet Se konceptuellt diagram i avsnitt 5.2 ovan Navet E-tjänsten GVU/MCP anropar Navet via webserviceanrop och kommunikation mellan parterna i infrastrukturen krypteras med hjälp av TLS/HTTPS med domäncertifikat utfärdat av en betrodd certifikatutfärdare. För informationer om Navet, se Skatteverket och Navet hämta uppgifter om folkbokföring SSBTGU E-tjänsten GVU/MCP anropar SSBGTU via CGI:s konsumentadapter. Kommunikation mellan parterna i infrastrukturen krypteras med hjälp av TLS/HTTPS med domäncertifikat utfärdat av en betrodd certifikatutfärdare. Konsumentanslutningen autentiseras med hjälp av organisationscertifikat utfärdat av betrodd certifikatutfärdare. Organisationscertifikatet, som används även för SHS och koppling till Navet, uppdateras av CGI vid behov. E-tjänsten GVU/MCP anropar SNA-tjänsterna. I anropen skickas Personnummer med. För informationer om SSBTGU se Bolagsverket och t.ex. Anslutningsguide för itleverantörer Översikt lösning BTIU Bastjänst samt BTIU Webb Generellt tillåts ingen applikation direktåtkomst till bastjänsten BTIU och all kommunikation sker krypterat över HTTPS/SSL. *Notera: används även för Plastbärkasselösningen hos. BTIU API API:t är exponerat som en SOAP/XML tjänst. BTIU tjänsten är nedlåst och kan bara anropas från SSBSTNA, EF1 tjänsten* och från s interna nät. Tidigare version av BTIU tjänsten har anpassats för att ta hänsyn till nya roller och behörigheter, se avsnitt

39 38 (45) Webb GUI Webben består av en ASP.NET MVC applikation som idag bara används internt av s supportfunktion. Inför GoS 1.0/MCP-releasen anpassades GUI:t att hantera olika behörigheter och anropen mot BTIU- tjänsten nyttjar nu auktoriseringsfunktioner så att rätt information visas för rätt roll. Webb-delen har kompletterats med funktioner för SNA. USER DB En vanlig Asp.Net Membership databas, med username/epost + Lösenord och Roll. Tidigare var det bara Plastpåsehandläggare i detta system. För GoS 1.0/MCP-releasen har rollerna byggts ut så att det nu går att lägga in såväl s supportpersonal som användare på tillsynsmyndigheter vid behov. BTIU DB En enkel SQL Server databas där vi kan spara ner JSON objekt i key-value pairs och rena binärobjekt så som en fil (pdf, word, bild m.m.). Alla objekt har ett antal metadata-attribut för att beskriva dem. Objekten har också en tillhörighet som kan användas vid behörighetsfiltrering Förändringar av realiserad lösning för åtkomst och behörighet BTIU temporär lösning för GoS 1.0/MCP-release För systemdokumentation se BTIU Kontraktdokument, [ref 15] och BTIU Systemdokumentation, [ref 16]. Behörighetskonfigurationer lagras internt i BTIU (tabell/roll), vanliga username + password lagras i en databas för sök-btiu-webben.(notera att det är ett avsteg från AFT där BTAU är den tänkta platsen för behörighetskonfiguration för utpekade aktörer, dvs Tillsynsmyndigheterna i det här fallet). Rollerna är lokala för lösningen, som valdes p g a tidsbrist Tjänstebeskrivning Teknisk dokumentation SNA Se dokumentet Tjänstebeskrivning Teknisk Systemdokumentation SNA, [ref 13] Informationsutbytesflöden och metoder Se även dokumentet Tjänstebeskrivning Bilaga API-beskrivning SSBTSNA, [ref 14] Användningsfallsrealisering: Registrera anläggningsuppgifter i SNA Sekvensdiagrammet nedan visar översiktligt meddelandeflödet mellan de komponenter/bastjänster som samverkar för att realisera registrering av anläggningsuppgifter. Klassdiagrammet visar vilka komponenter/bastjänster som medverkar i realiseringen, samt hur dessa är sinsemellan relaterade

40 SW E D I SH E N V IR O N M EN T A L P R OT E C T IO N AG E NC Y kundtjanst@naturvardsverket.se Ärendenr: NV

41 40 (45) Figur 1: Sekvensdiagram för realisering av användningsfallet Registrera anläggningsuppgifter i SNA.

42 SW E D I SH E N V IR O N M EN T A L P R OT E C T IO N AG E NC Y kundtjanst@naturvardsverket.se Ärendenr: NV Figur 2: Klassdiagram för realisering av användningsfallet Registrera anläggningsuppgifter i SNA Registrera anläggningsuppgifter i SNA - detaljering I Figur 1 beskrivs mer i detalj kommunikationen mellan en klient och SSBTSNA. Sekvensdiagrammet illustrerar vilken typ av metoder som bör användas för att realisera olika verksamhetshetskrav på klientsidan. Det finns fler metoder än de som visas i diagrammen. Diagrammen skall verka som best practice för alla aktörer som vill utbyta information med SNA-systemet.

43 42 (45) Figur 2: Kommunikation mellan klient, t.ex. GVU, och SSBTSNA vid registrering av anläggningsuppgifter. Nedan beskrivs ett typexempel på hur kommunikationen bör ske mellan en SNA-klient och den yttre tjänsten för SNA, CompositeService (SSBTSNA), när en anläggning ska registreras för första gången. Flödet kan beskrivas enligt: Inloggning o 1. I klienten antas det ske någon typ av autentisering av slutanvändaren, exempelvis med bankid. o 2. Klienten frågar SNA om personen existerar i SNA. o 3. Om klienten finns registrerad, vilket vi antar här, hämtas Person-objektet till klienten och eventuella personuppgifter kan presenteras. Populering av drop-down-listor o 1. Slutanvändaren väljer att registrera nya anläggningsuppgifter. o 2. Klienten hämtar olika kodlistor för att bistå slutanvändaren i deras val genom att populera drop-down-listor, som t.ex listor för:

44 43 (45) BTKL_BranchCode_Maingroup BTKL_monitoring_authorities (Innehållande tillsynsmyndigheter) BTKL_Installation_Type BTKL_MCP_type Etc. o 3. Efter steg 2 kan nu slutanvändaren göra sina val och minst ange obligatorisk information samt ange viss information i tillhörande inmatningsfält. Här registrerar slutanvändaren kontaktperson och anläggningsuppgifter inklusive uppgifter om installationer och installationsdelar, väljer tillsynsmyndighet och verksamhetsutövare. Validering av inmatningsfält I det här steget skickas all anläggningsinformation klienten har samlat upp från slutanvändaren till SNA-systemet. Vidare gör klienten anrop till SNA för att skapa upp personer och aktörer som inte redan existerar i BTAU-databasen. SNA validerar nu all information via CompositeService. Valideringen innebär att en verifiera att obligatoriska parametrar har skickats med samt att personer och aktörer som återanvänds existerar i BTAU-databasen. Skapa objekt Om valideringarna är ok i föregående steg, kommer objekt att skapas upp i SNA-systemet, anläggningsuppgifter i BTSNA-databasen och person- samt aktörsuppgifter i BTAU-databasen. Skapa uppdrag och rapportera till BTIU I sista steget skapar CompositeService upp fyra uppdrag, se avsnitt Fel! Hittar inte referenskälla., som är knutna till a nläggningen som registreringen gäller för. CompositeService skickar sedan vidare en sammanställning av de registrerade uppgifterna från klienten till BTIU, för att berörda personer skall få notiser i form av mailutskick om att ändringar har skett.

45 44 (45) Uppdatera befintliga anläggningsuppgifter i SNA Figur 3: Kommunikation mellan klient, t.ex. GVU, och SSBTSNA vid uppdatering av anläggningsuppgifter. Här beskrivs uppdatering av befintliga anläggningsuppgifter. Endast skillnader relativt huvudflödet i Figur 2, där anläggningsuppgifter skapas för första gången, tas upp. Avvikelserna kan beskrivas i följande punktlista: Inloggning & Hämta uppdrag I det här steget sker även hämtning av slutanvändarens uppdrag, som denna är knuten mot, vilket görs genom att klienten anropar GetPersonalAssignments, Populera drop-down-listor I samband med att slutanvändaren har valt ett specifikt uppdrag som är knutet till en specifik anläggning i föregående steg, kan klienten nu hämta all anläggningsinformation samt person- och aktörsinformation genom att använda metoden GetActorsAndPersonsByFacilityId, se avsnitt. Uppdatera objekt I det här steget används en update-metod istället för create. Det är viktigt att klienten i det här steget sätter objectid korrekt på alla objekt som existerar sedan tidigare. Detta för att SNA inte ska tappa historiken, versionshanteringen.