MOX og datasikkerhed

Fra Den Fælleskommunale Rammearkitektur
Skift til: Navigation, Søgning
Laboratorium-label.png
MOX og datasikkerhed
Status-2.png
V. 7173
Om Status

Baggrund

Frederiksberg kommune(FK) gennemfører i Q1 2015 projektet 'Beskedfordeler' med det formål at analysere sikkerhed i beskedfordeling. Konkret omhandler projektet beskeder til/fra Organisationskomponenten - altså personfølsomme data. Projektet analyserer anvendelsen af SAML i et asynkront mønster.

Det bærende princip er, at en MOX agent via Token behandler opdatering af Organisation med rettigheder for den pågældende bruger, der foretager opdateringen af Organisation. Projektet er motiveret af et andet FK projekt LoRa Organisationsservice.

Status

Igangværende

Kontaktpersoner

Marius Hartmann, it og forretningsarkitekt, Frederiksberg kommune.

Beskrivelse

FK valgt en SAPA strategi som betyder at alle sagsbærende systemer skal på SAPA fra 2018. Dette betyder, at et større antal vidtforskellige systemer skal integreres med STS. Man kan forvente, at en del af disse systemer ikke har udviklet snitflade til STS - og da man som tommelfingerregel kan gå ud fra, at en traditionel integration koster fra T100 til T250 - så er der potentielt så markante investeringer i vente, at det kan påvirke kommunens målsætning for anvendelsen af SAPA.

Det er derfor nødvendigt, at forfølge en strategi, der dels nedbringer forventede udgifter til integrationer, dels opnår størt mulige gevinster ved de investeringer der foretages til integrationer. FK forventer, at det giver bedst mening, at anvende MOX-integrationer for systemer, der ikke kan håndtere beskeder, idet der da kan opnås fordele vdr. løst koblede arkitektur.

Formål

Projektet Beskedfordeler har 2 overordnede målsætninger:

  1. Effektivisering
  2. Datasikkerhed

Genstandsfelt

Til undersøgelsen anvendes LoRa Organisationsservice baseret på standard for Organisation og implementeret med JAVA og PostgreSQL på en RabbitMQ beskedfordeler. En OpenSAML agerer IP Token udsteder. Det kan derfor forudsættes, at systemerne har trust vha. føderation.

Anvendte principper

Følgende designprincipper anvendes

Område Princip Implikation
RabbitMQ Agent skal modtage besked, afsende besked exchange anvendes, beskrevet i MOX vejledninger
Beskeder En besked med et objekt skal være selvbærende
Metadata Kontekst skal altid med på alle objekter En besked kender sit objekts afhængigheder
Klassifikation Alle objekttyper er opmærket med Klassifikation
Besked Alle properties fra Beskedformatet skal findes i AMQP-beskeden Vi supplerer de begrænsede Properties i AMQP vha. Application Headers
Besked Properties på besked ej hard coded En klasse bør have metode, der sætter Properties+Application Headers
Echo off En mekanisme skal sikre at man ikke laver loop, dvs abonnerer på sin egen besked
MOX klasse Indkapsle REST i agenten PostgreSQL stored procedures behandles som metode, så der ikke skal tales 2 sprog(Python+Plsql)
MOX MOX agerer på vegne af en bruger MOX anvender brugerens rettigheder
Besked Besked består af
  1. Kuvert
  2. Metadata
  3. Objekt

Beskedformatet findes, men skal mappes til AMQP's beskedformat vha.

  • Properties
  • Application Header

PHP eksempel:

  • man skriver til en Exchange via standard properties + application headers som er 'selvvalgte' dvs dem kan vi bruge til extra info.

Begreber

Følgende begreber er defineret

Begreber Forkortelse Forklaring
it-system IS fx. et sagsbehandlingssystem
FK Organisation FKO Organisationskomponent som agere datakilde for Frederiksberg autoritative organisationsoplysnigner
Organisatorisk Funktion OF Den arbejdsopgave eller rolle som varetages
Bruger B Navnet på en bruger i Organisation
Organisatorisk Enhed E En afdeling/enhed i organisationen fx. it-afdelingen
Organisatorisk Funktion OF En arbejdsopgave som fx. relaterer en bruger/afdeling sammen med et it-system
Klassifikation K Autoritativ kilde til begreber som anvendes af systemer eller processer fx. KLE
Identity Provider IP En autoritativ kilde til autorisationer
Token Token Adgangsgivende property/xml dokument udsted af en IP
Besked Besked Format for datapakker som håndteres af en Beskedfordeler

Gevinster

Effektivisering

Integrationsvilkår til Støttesystemer(STS) kravstiller om Beskedfordeling og tillader anvendelse af MOX som integrationsmønster. Anvendelse af MOX som integration til STS medfører samme obligatoriske krav som andre snitflader. KL vil i samarbejde med Kombit udarbejde disse krav, så fx. SAML understøttelse iagttages.

MOX er en strategisk interessant løsning for kommunerne, idet MOX både kan medføre besparelser på snitflader, men også transformere eksisterende gamle systemer til løst koblede systemer, der kan håndtere beskeder. Betydningen af at transformere eksisterende systemer til at have rammearkitekturegenskaber er væsentlig både set ifht. forpligtelser ifbm. opdatering af Sags- og Dokumentindeks, men også for kommunens langsigtede råderum ifht ændringer af systemlandskabet.

MOX udbygger systemernes kapabilitet til at håndtere rammearkitekturegenskaber som vil modne FK lokale dataarkitektur til at arbejde med distribuerede objekter, som vil skabe mulighed for, at høste de effektiviserings- og kvalitetsgevinster som er indlejret i rammearkitekturens opdeling mellem opgaver, processer og byggeblokke.

Datasikkerhed

Da kommunen ventes at anvendes Beskedfordeling for persondata ifbm. Organisation, vil det højne sikkerheden, at undersøge konverteringskrav for eksisterende systemer, til at kunne håndtere sikkerhed. Formålet med undersøgelse er at sikre at aftagersystemer for organisationsdata kun har adgang til de objekter som har ret til, samt at der arbejdes på vegne af en bruger dvs. at dataudvekslingen foregår på baggrund af en arbejdsopgave som brugeren har ret til at udføre. Dette princip er afgørende for at nedbringe anvendelsen af systembrugere i.e. automatiserede processer af ikke-personer og vil have den fordel, at ændringer i systemlandskabet vil være lettere og sikrere grundet overblik over arbejdsopgaver.

Støttesystemernes obligatoriske krav til adgangstyring og integration bliver 'fødselhjælper' til en udvikling af kommunens lokale rammearkitektur. Rollebaseret adgangsstyring(RBAC) er et væsentligt skridt henimod højere sikkerhed på kommunens systemer, man kan lidt enkelt sige, at RBAC styrer sikkerhed på vertikalen - altså bundet til et systems afgrænsning. Men når rammearkitekturen lægger op til tværgående processer, hvorved forskellige systemer og faggrupper involveres i et foranderligt it-landskab. Så kan det blive en analytisk samt tidsmæssig udfordring at håndtere sikkerheden. Projektet undersøger om der er mulighed for at indføre horisontale niveauer af sikkerhed ved at tilføje adgangstyring på objektniveau fx. ved at håndtere sikkerhed i beskeder. Dette vil -hvis det viser sig praktisk/performancemæssigt muligt- understøtte adgangsstyring på delprocesser uafhængigt af system baseret på den udførende brugers rettigheder, også selvom der er tale om en automatiseret proces på vegne af brugeren.

Modernisering

Udover at få bekræftet sikkerhed ved beskeder, kan kommunen opnå gevinster ved at indføre datasikkerhed på objekter, i kraft af den modernisering af eksisterende systemer anvendelse af MOX vil medføre.

Når et system gøres i stand til at håndtere SAML samt anføre ansvarlig bruger for transaktioner nedbringer det antallet af systembrugere(ikke-personer). Dette medfører en forenkling af systemarkitekturen som potentielt kan flytte ÅV fra teknisk opsætning og overvågning af systembrugere til rollemodellering og automatisering af processer. MOX vil udover at kunne modernisere systemers egenskaber ifht at udstille funktioner også kunne anvendes til at håndtere Token-baseret adgangsstyring på disse systemer - og dermed forenkle kommunens administration af adgangsstyring på systemniveau og overflødiggøre særskilte integrationer for brugerstyring.

Udeståender

Fase 2 spørgsmål

Det undersøges

  1. Organisationsservice kun kan opdateres af bruger med rettigheder
  2. En besked kan indeholde et Token.
  3. En besked kan ikke udføres såfremt Token er udløbet
  4. Håndterer fornyelse af en Token for en bruger med rettigheder
  5. Hvordan man håndterer en gyldig Token for en bruger uden rettigheder (kan måske forekomme, hvis en bruger får ændret rettigheder efter en Token er udstedt)
  6. Hvorledes en Token kan veksles til en Ticket i tilfælde af et system, der ikke forstår SAML, men istedet understøtter Oauth
  7. Kryptering af indhold i en besked
  8. (CRUX) hvorledes et asynkront mønster applikerer et synkront paradox i kraft af at modtager (principielt) ikke er kendt for en besked - og Token derfor ikke kan udstedes til en kendt bruger

Use cases

Stories

  • Forudsætning: MOX oprettet som IS i O
  • Forudsætning: B1 oprettet i FKO med OF
  • Forudsætning: K oprettet i FKO
  • B1 opretter B2
  • B1 opretter OE1
  • B! opretter OE2 under OE1
  • B1 flytter OE2 på niveau med OE1
  • B1 opretter IS1
  • B1 opretter OF1
  • B1 tilknytter OF1 til B2
  • B1 tilknytter OF1 til OE1
  • B1 opretter OF2
  • B1 tilknytter OF2 til OE1
  • B1 tilknytter OF2 til IS1
  • B1 tilknytter IS1 til OE2
  • B1 tilknytter B2 til OE2

og

  • B2 kan få adgang til IS1 via Token (!epic)

Epic for do.

  1. B1 logger på kommunens netværk og får en Token for sin logon.
  2. B1 vil igangsætte et forløb og en agent skal bruge IS1
  3. Token videreføres i beskeden
  4. Attributserver spørger O om B1 rolle i IS1
  5. O henter rollemapning fra K
    1. Hvem er han, hvilken rolle har han i kommunen, hvilken restriktion, hvordan er rollen mappet til IS1,
  6. Arbejdet udføres i IS1, IS1 logger.

Future work

Ønske: indholdet i en besked kan krypteres

Formål:

  • nu har vi styr hvem der er hvem
  • hvad de må på systemerne
  • styr på hvilke systemer
  • styr på tokens og validitet
  • at uvedkommende ikke kan læse beskeder som de ikke har rettigheder til


Policy for sikkerhed på beskeder ifht security areas skal udvikles

  1. Fortroligt - kun til trustede parter på beskedfordeleren
  2. Systemlandskabet kendes, følger regler - men ruten beskeder tager kendes ikke
  3. Systemlandskabet kendes ikke og ruten beskeder tager mellem systemer kendes ikke


Governance skal udvikles

  • Trustede parter gives en nøgle til afkryptering af beskeder.