API säkerhet och möjligheter

Transkript

1 API säkerhet och möjligheter API arkitektur för ökad flexibilitet och snabbhet, samt API Management för kontroll på åtkomst till organisationens alla API:er och WebServices Del1: Mulesofts API LED arkitektur och Center 4 Enablement som målbild. Vad är det och varför starta resan nu? Vilka möjligheter ger det? Del 2: Hur och varför ska man ha kontroll på åtkomst, behörigheter och upptäcka intrångsförsök till WebService och API:er till organisationens olika system? Presentation och demo av API Management.

2 API arkitektur för ökad flexibilitet och snabbhet, samt API Management för kontroll på åtkomst till organisationens alla API:er och WebServices Del 1: Mulesofts API-led Connectivity och Center 4 Enablement som målbild. Vad är det och varför starta resan nu? Vilka möjligheter ger det? Del 2: Hur och varför ska man ha kontroll på åtkomst och behörigheter till WebService och API:er till organisationens olika system? Presentation och demo av API Management.

3 API-led Connectivity The Next Step in the Evolution of SOA API-led connectivity is the integration approach that will provide the speed organizations are looking for. It provides an approach for connecting and exposing assets. With this approach, companies can deliver today s projects faster than ever before while also building an infrastructure to increase productivity on future projects and an enterprise ready for change.

4 API-led Connectivity Det vi vill uppnå med API:er (generellt): Lös koppling Utbytbarhet Opåverkade Klient Klient Klient Stabilt! API Skilj på: API (gränssnittspecifikation) Implementation (applikation) Förändra Implementation System System Lägg till / Ta bort / Byt ut / Uppgradera

5 API-led Connectivity Ett vanligt misstag är att spegla bakomliggande systems funktionalitet och datamodell i API:et Förändring i eller byte av system kommer med därmed att påverka API:et och klienterna. Utforma API:et utifrån generaliserad funktionalitet och generaliserad data. Idealt en helt generell och standardiserad (kanonisk) datamodell

6 API-led Connectivity MuleSoft förespråkar integrationer via flera API-skikt

7 API-led Connectivity Process-skiktet Verksamhetsorienterade tjänster (ex: Lägg order, sök kund, skicka faktura, etc) Även sammansatta tjänster (ex: Lägg order inkl skapa kund) Idealt med kanoniska datamodeller enligt ovan

8 API-led Connectivity System-skiktet Primärt implementera API:er mot system som saknar egna (bra) API:er. Inga krångliga systemspecifika kopplingar i process-skiktet. Lösa en gång och återanvända via system-api. Vill tillämpa API-management funktionalitet som t ex behörighet. Även proxa befintliga API:er för att nyttja API-Manager Även hantera t ex behörighet mot backend-system på ett ställe. Kanske externt, klient-certifikat, kryptering o dyl

9 API-led Connectivity Experience-skiktet Det som är mest nytt i MuleSofts modell Anpassa API efter klient, mer lättanvänt och ändamålsenligt. T ex sammansatta operationer, mindre datamängder, färre dynamiska argument Andra policies mm i API-manager. T ex externt experience-api på internt process-api. Annars många gånger utmärkt att använda process-skiktet direkt.

10 API-led Connectivity Tre skikt med HTTP-API:er plus systemkoppling är ett potentiellt prestandaproblem. Tillämpa modellen friare, betrakta som logiska skikt, inte strikt HTTP-API. Utöver HTTP kan varje skikt även ha andra ingångar som VM (intern Java), synkrona (icke-persistenta) JMS-köer, mm. Samma operationer och datamodell. Tappar API-management-funktionalitet!

11 API-led Connectivity Genom att bygga tjänster/api:er mot affärsobjekt och system får vi över tid en mängd återanvändbara resurser att bygga tillämpningar på. Nya sammansatta/anpassade API:er kan snabbt byggas på befintliga API:er för att möta nya behov.

12 API-led Connectivity Vi bygger ett applikationsnätverk!

13 API-led Connectivity En pionjär: Stort logistikföretag Slutet 90-talet (före web services och SOA som känt begrepp) Funktionalitet skulle ut på webben (boka transporter, söka försändelser, o s v) Princip: All webbifierad funktionalitet skulle byggas som återanvändbara tjänster som kunde anropas över http med väldefinierade standardiserade gränssnitt. Lade grunden för ett applikationsnätverk!

14 API-led Connectivity Att bygga och använda ett applikationsnätverk kräver (bl a): Kontroll på användning Vem använder vad? Behörighet SLA:er Belastning Mm API-Management Kunskap och verktyg för att hitta, använda och bygga API:er API-dokumentation/register Testmöjligheter Verktyg för design och implementation av API:er Självservice: ICC/Center of Excellence (CoE) Center for Enablement (C4E)

15 API-led Connectivity Center for Enablement (C4E): Mål: Decentralisera IT-kapabiliteter utan att ge avkall på styrning, genom att: Förse intressenter (verksamheten) utanför IT med återanvändbara resurser som låter dem skapa lösningar (som IT annars skulle ha gjort). Reducera tiden för dessa lösningar genom API:er som löser stora delar av behoven. Säkerställa säkerhet i lösningar genom att bygga in säkerhet i API:erna. Frigöra resurser inom IT för mer strategiskt arbete. Minimera tid från idé till leverans genom att tillhandhålla återanvändbara komponenter, mallar och riktlinjer.

16 API-led Connectivity

17 API-led Connectivity

18 API arkitektur för ökad flexibilitet och snabbhet, samt API Management för kontroll på åtkomst till organisationens alla API:er och WebServices Del 1: Mulesofts API-led Connectivity och Center 4 Enablement som målbild. Vad är det och varför starta resan nu? Vilka möjligheter ger det? Del 2: Hur och varför ska man ha kontroll på åtkomst och behörigheter till WebService och API:er till organisationens olika system? Presentation och demo av API Management.

19 API-Management Proxa befintliga API:er Applicera regler på API:er via administrativt gränssnitt Styra åtkomst (inloggning, API-nyckel) Tillämpa SLA:er Begränsa trafik API-register med versionshantering Kontroll på API-användning Klientapplikationer Anropsstatistik - > analysmöjligheter Larm API-portaler dokumentation och åtkomst för klienter

20 API-Management MuleSoft Anypoint Platform

21 API-Management Proxa befintliga API:er: Peka ut API, Mule proxy-applikation genereras. Ger management-funktionalitet på befintliga API:er och möjlighet till alternativa exponeringsvägar. T ex skapa ett managerbart system-api på ett befintligt API i ett verksamhetssystem, eller ett externt behörighetsstyrt API ovanpå ett internt process-api. Se upp! Att proxa as is ger inte lös koppling.

22 API-Management Applicera regler, s k policies, exempel: Rate limiting: Begränsa antalet anrop per tidsenhet (avvisa) Throttling: Begränsa, sätt anrop i kö IP black/white-list Kräv registrering av klienter och API-nyckel Knyt policies och klienter till SLA-nivåer Kräv inloggning: LDAP OATH Custom: Definiera egna policies (Mule-flows), tillgängliga för applicering via API-mgr

23 API-Management API-register och portaler: Alla API:er och versioner registreras i API-manager -> API-register Kan skapa privat (intern/inloggning) eller publik utvecklarportal för varje API/version där API:erna kan dokumenteras till valfri nivå. Inklusive API-specifikation med testmöjligheter Via portaler kan klienter ansökan om tillgång

24 API-Management Statistik, analys och larm: Alla anrop registreras Standardiserade och anpassningsbara sammanställningar för analys Anrop per klient, länder, plattformar; andel lyckade/fel, o s v Larm I API-manager (API-ägare/administratörer) och via epost (intressenter) T ex om anrop bryter mot policies, hög belastning/låg prestanda, felkoder i returen

25 API-Management Demo

26 API-Management API-manager en del i Anypoint Platform a k a Mule Enterprise Alternativ för Mule Community? Pulsen har valt WSO2

27 Varför API Management? Möjliggöra applikationsnätverk och API LED arkitektur genom att: Styra och säkra upp åtkomst Styra behörigheter Upptäcka och förhindra intrångsförsök i system Spårbarhet och statistk på användning Säkra och integrerade digtala informationsflöden

28 Varför en ny component i PCIP? Mule API Management är en Enterprise funktion och kostar pengar Pulsen har utvärderat ett alternativ för dem som vill gå med en OpenSource strategi och som passar i vår arkietktru med Mule, mfl. komponenter Säkra och integrerade digtala informationsflöden

29 Kriterier för val av produkt Text, förslag på disposition 1. Behov/problem och önskade effekter 2. Lösning 3. Uppnådda effekter 4. Erfarenheter från införande 5. Hur kommer man ingång? Säkra och integrerade digtala informationsflöden

30 Följande produkter har analyserats Mule API Manager WSO2 Fusio Tyk Amazon Kong API Ubrella Apigee APIaxle Microsoft Azur SmartBear/SwaggerHub Säkra och integrerade digtala informationsflöden

31 +30 Kriterier vid utvärdering OnPrem Cloud Grafisk verktyg HA Pris Support Global marknad och tillväxt Lokal marknad och tillväxt Analytics Role base access control GDPR ready Performance monitoring Caching Swagger support/openapi Specification RAML YAML Blueprint Authentication Docker Wmware Linux Windows Mac Cloud Govern Publish API Developer Portal Developer Community Manage scale API traffic Monitor and Monetize Autoscaling Real time debugging Java, net.

32 Vårt val Säkra och integrerade digtala informationsflöden

33 ???

34 Hur kommer man igång? Indentifera befintliga WebServices och API:er Vart finns det behov att öka säkerhet? Vart finns det behov av statistik och spårbarhet? Vart finns det behov att tillgängliggöra API:er vid kommande projekt och upphandlingar? Tänk stor Börja smått BÖRJA! = POC Säkra och integrerade digtala informationsflöden

35 Tack för att ni lyssnat!