Hva betyr tjenesteorientert arkitektur for sikkerhet? Torbjørn Staff Architecture Innovation Group Accenture, its logo, and High Performance Delivered are trademarks of Accenture.
Agenda Arkitekturevolusjonen Praktiske utfordringer Tilgangskontroll i kontekst Standarder for policy Hvorfor trenger vi et policy-språk? 2
Arkitekturevolusjonen SOA - fra siloer til tjenesteorientering Silo Monolittiske systemer Duplisering av data og funksjonalitet Lite integrasjon mellom systemene System X System Y System Z P2P Komponentorientering for økt gjenbruk Distribuert med tette tekniske koblinger Lav endringstakt Komponent X Komponent A Komponent Y Komponent B Komponent Z SOA Veldefinerte kontrakter Løse koblinger Høy endringstakt Tilbyder X Konsument A Konsument B Tjenestebuss Tilbyder Y Tilbyder Z
Arkitekturevolusjonen SOA-sikkerhet - fra perimeter til policy B2B Perimeter-sikkerhet realisert med brannmurer Teknologiorientert XMLDSIG, XMLENC, WS-Security etc Fokus på behov ved kommunikasjon med eksterne partnere RBAC Delvis identitetsdrevet Rolle-basert, grovkornet tilgangskontroll Statisk konfigurasjon og manglende forsyning Policy Policy-drevet sikkerhetsarkitektur WS-Policy og XACML Aggregering av policy er fra underliggende systemer Understøtter dynamisk integrasjonsplattform
Referansemodell Tjenesteorientering helt ut til brukerflaten.. User Interaction Services Governance Enterprise Platform Information Model Business Domain Entities Business Events Standardized Entities Enterprise Entities Activity Services Web Application Screens Orchestration and Choreography Services Business Services Capability Services Information Services Web Application Widgets Business Processes Event Handlers Batches Entity Services Master Data Services Business Rules Technical Framework Capabilities Infratructure Services Management and Operations Services
Referansemodell i et større virksomhetsperspektiv
Referansemodell og i forretningsperspektivet
Referansemodell eller litt forenklet
Praktiske utfordringer (1/2) Informasjonsbeskyttelse Sikker transportkanal vs krav til beskyttelse av meldingskonvolutten? Identifisering og autentisering Identifisere sluttbruker eller system? Behov for føderasjon av brukeridentiteter?
Praktiske utfordringer (2/2) Tilgangskontroll Grovkornet eller finkornet tilgangskontroll? Styre tilgang basert på identifisering av system, eller sluttbruker? Komposisjon og sammensatte tjenester Hvordan håndtere komposjoner som ikke er autonome?
2 Praktiske utfordringer Håndheve tilgang til tjenester Tjenestekonsument A 1 Tjenestekonsument B Håndheve tjenestespesifikasjon og policy Service Gateway 3 1 Konsument initierer forespørsel mot tilbyder/produsent 2 Service Gateway implementerer et Policy Enforcement Point (PEP) for å håndheve policy. Kan løses vha en tjenestebuss/esb, xml-appliance eller enklere reverse-proxy 3 Produsent mottar forespørsler kun fra autoriserte konsumenter. Tjenestetilbyder X Tjenestetilbyder Y Tjenestetilbyder Z Introdusere PBAC for Policybased Access Control??
Vi trenger kontekst
XACML beskriver modeller for dette
Generell modell for policy-orientering Abstrakte funksjoner definert i XACML Subjekt(er) Policy Enforcement (PEP) Handling(er) Ressurs(er) Policy Administration (PAP) Policy Decision (PDP) Policy Information (PIP)
Generell modell for policy-orientering med attributter som gir kontekst Subjekter Sluttbruker System Autentiseringsnivå Handlinger Opprett, Les, Oppdater, Slett, Kjør Miljø Fysisk lokasjon Kanal Subjekt(er) Policy Enforcement (PEP) Handling(er) Ressurs(er) Attributter Attributter Policy Administration (PAP) Policy Decision (PDP) Policy Information (PIP) Ressurser Prosesser og aktiviteter Tjenester og applikasjoner Informasjon og data Klassifisering og metadata
Generell modell for policy-orientering hele modellen fra XACML
Policy-dokumenter og standarder Interaksjonspolicy Policy for autentisering Policy for meldingsbeskyttelse (signering og kryptering) Tilgangspolicy Policy for tilgangskontroll Policy for sporbarhetslogging WS-SecurityPolicy XACML 17
Hvorfor trenger vi standarder for dette?
Flere praktiske utfordringer Dagens løsninger har ingen standardiserte ressursdefinisjoner konfigurasjon lar seg ikke eksternalisere administrasjon og forsyning skalerer ikke gir ikke tilstrekkelig presisjon
mens standardiserte policy er..tilbyr et kanonisk språk for å uttrykke policy..gir en rikere representasjon av subjekter og ressurser..muliggjør fleskibel tilgangskontroll i riktig kontekst..kan komponeres og aggregeres..muliggjør interoperabilitet på tvers av produkter og verktøy med sentralisert forsyning
XACML Tilbyr: Kanonisk språk for å uttrykke tilgangspolicy er Generell protokoll for å spørre om tilgangsbeslutninger Mangler: Ingen binding av den generelle protokollen til bærende protokoll eller meldingskonvolutt Ingen integrasjon med WS-Policy eller resten av WS-*
Spørsmål 22
Eks: sentralisert forsyning Partners nett Partners ytre brannmur Din ytre brannmur DMZ Din indre brannmur Din virksomhets interne nett Tjenestekonsumenter Tjenestetilbydere WS-Security Gateway PEP Internet PEP PEP PEP WS-Policy XACML Policy 2007 Accenture. All rights reserved. 23
Praktiske utfordringer Håndheve tilgang til data Interaction Services ASYS BSYS Governance Enterprise Platform ActivityService X Orchestration and Choreography Services Batch Business Services BusinessService X BusinessService Y Information Services Technical Framework Capabilities Infratructure Services Management and Operations Services EntityService A LegacyService B Repository A Repository B Repository C