Sentral Policy Basert Autorisasjonsløsning

Transkript

1 Sentral Policy Basert løsning Hvordan håndheve et felles regelverk i en fragmentert applikasjonsportefølge. 09/06/2015

2 Nordea created through a string of mergers Pre banks 1970 s 80 banks 1980 s 30 banks 1990 s 4 banks 2000 s 1 Nordea

3 Nordea is the largest financial services group in the Nordic and Baltic Sea region Q Nordea s home markets 11 million customers - 8 home markets - Approx. 10 million personal customers corporate customers, incl. Nordic Top 500 Distribution power - Approx. 800 locations in total - Approx. 7 million Netbank customers Financial strength - EUR 10.0bn in full year income (2013) - EUR 630bn of assets ( 2013) - EUR 29.2bn in equity capital (2013) - AA credit rating - Core Tier 1 capital ratio of 14.9% ( 2013) EUR ~39.7bn in market cap - One of the largest Nordic corporations - A top-10 European retail bank

4 All opinions in this document are mine and mine alone.

5 Autentisering Autorisasjon Hvem er du? Hva har du tilgang til?

6 Autorisasjon Uten sentral subjekt <a> autorisasjonsløsning Ønsker å utføre operasjon <b> På resurs <c> regler Tilganger logikk istrasjon av tilganger database Men hva om vi må forandre reglene?

7 Vi hadde et stort antall Proprietære, inkompatible, ustrukturerte løsninger. Og antallet økte jevnt!!! Fragmentert og ustrukturert Arkitektur

8 Så måtte vi forandre reglene Personopplysningsloven ble vekket opp av en 10 år lang dvale Banken måtte etterfølge kravene i løpet av kort tid Fjerne tilgang til kunde, for en ansatt eller gruppe av ansatte Gi tilgang til kunde, for kun en ansatt eller gruppe av ansatte Kunden har rett til å få en rapport over hvor mange og hvilke tidspunkt personlige opplysninger er blitt aksessert. (Innen rimelig tid ) 8

9 Så måtte vi forandre reglene i Norge 38 applikasjoner, på «alle» platformer, skrevet i «alle EDB epoker» (fra COBOL via.net til Java) Behovet i Norge: Samme evaluering / avgjørelse alle steder En sentral logg og rapportering Forenkle fremtidig endring av reglene 9

10 Så måtte vi forandre reglene OVERALT Banken hadde de samme behovene i hele konsernet: Interne krav og direktiver i konsernet Legale krav Fin granulær tilgang Kontekst bevist 10

11 En sentral policy basert autorisasjonsløsning Vi valgte å bygge en attributt basert autorisasjonsløsning ABAC Ved å bruke en internasjonal standard XACML: Fungerer på tvers av leverandører Moden og veldefinert protokoll Referanse arkitektur for sentral policy administrasjon 11

12 Forretningsregler ABAC gjør det mulig å håndheve forretningsregler ved hjelp av disse komponentene: Subjekt Handling Objekt Kontekst / miljø I samarbeid med forretningssiden kan IT uttrykke business regler i en IT policy. Ansatte kan se på kunder tilknyttet filialen den ansatte jobber i. 12

13 Business regler blir IT policyer ABAC gjør det mulig å håndheve business regler ved hjelp av disse komponentene: Subjekt Handling Objekt Kontekst / miljø I samarbeid med forretningssiden kan IT uttrykke business regler i en IT policy. Ansatte kan se på kunder tilknyttet filialen den ansatte jobber i. 13

14 Attributtene: Hva er de? Hvor er de? HR informasjon om ansatte Finans - organisasjon Kundesystemer informasjon om kunder RBAC og tilgangsgrupper Svarteliste / hviteliste / knus glasset Kontekst fra hvor / tidspunkt / hvilken klient. 14

15 Erfaringer: Attributter: En kan aldri endre betydningen av et attributt etter implementasjon. Navnestandard Dokumentasjon Eier Web basert verktøy Attributter og policyenes navn er en URL All informasjon om attributt / policy er tilgjengelig på URL 15

16 Web basert verktøy 16

17 Erfaringer Forretningsregler og Forvaltning Forretningsreglene var motstridende og måtte omskrives for å kunne defineres som IT policyer Klare definerte forretningsregler Identifisert eierskap og ansvarlige aktører Konsekvens og implikasjoner av forretningsreglene Prioritet / rekkefølge Ved konflikt, hvilken regel overstyrer en annen? I hvilken rekkefølge skal reglene evalueres? 17

18 Forretningsregler / Policyene må visualiseres: 18

19 Forvaltning: Roller og eierskap må plasseres i organisasjonen. Hvem eier en regel Hvem kan endre en regel Versjonskontroll Testing av endringer automatisert Branch / merge strategi 19

20 Vil vi fortsette å håndheve slik?

21 Eller bygge grunnlaget for en fremtid hvor vi har oversikt og kontroll på hvilke regler som blir håndhevet? PEP PEP PEP PEP PEP PEP PEP PEP PEP PEP Audit Log (LogI) PDP PRP PAP PIP PIP PIP

22 Vår visjon for tilgangskontroll: 22

23 Takk for oss! Spørsmål?