Microsoft 365 – Fjerntilgang uten VPN

Virtuelle private nettverk har tjent oss godt siden midten av 1990-tallet. Nettverksprotokollene som ligger til grunn, har utviklet seg og blitt mer standardiserte og sikrere over tid, men kjernekonseptet er uendret: Det etableres en kryptert nettverstunnel mellom eksterne noder for å overføre trygg applikasjonstrafikk på tvers av upålitelige mellomliggende nettverk. Nå er det på tide å erstatte VPN som kobler eksterne brukere til bedriftsnettverk, med mer moderne løsninger. De justerer dynamisk brukertilgang basert på kontekstuell informasjon om bruker, enheter, nettverket, systemet og målressurser – for mange et første skritt på reisen mot sikkerhetskonseptet Null tillit.

Tradisjonelle VPN er egentlig ingen sikkerhetsverktøy, men redskap for fjerntilgang. Styringen av identiteter er som regel for svak og grovmasket. Fra et ressursperspektiv er tilgangskontrollene statiske, som gir for bred nettverkstilgang. VPN krever økt administrativ innsats og er tungvint for sluttbrukere. Du må åpne opp porter mot Internett, som utgjør en risiko. Med jevne mellomrom avdekkes det sårbarheter i VPN-serverne som utnyttes av angripere. Det er ett enkelt inngangspunkt til lokalnettet som opprettholder en avleggs sikkerhetsperimeter. Med dagens trussellandskap er det meningsløst å ha en sånn portal inn i virksomheten.

Moderne fjerntilgang

Vi kan ikke lenger anta at alt innenfor bedriftsnettverket er trygt. Vi aner ikke hvem som ber om tilgang, venn eller fiende. Brukerkontoer kan være kompromittert, endepunkter infisert. Vi må eksplisitt validere tilliten til brukere og enheter. I hovedsak er det to sikkerhetsutfordringer med VPN:

• Svak autentisering – VPN benyttes enkelte ganger med kun brukernavn og passord, ellers som regel med bare grunnleggende multifaktor-autentisering (MFA). Det mangler innebygd støtte for eksplisitt validering av integriteten til brukere og enheter, kombinert med trusselintelligens, adaptive faresignaler knyttet til pålogginger og endepunktsdeteksjon og respons (EDR).
• Full nettverkstilgang– VPN tillater ofte brukere (og angripere med stjålet legitimasjon) full port- og protokolltilgang til hvor som helst på lokalnettet. I dag ønsker vi å segmentere det, dele det inn i soner, for å redusere angrepsflaten og minske skadeomfanget ved et angrep.

Det første og enkleste trinnet er å konfigurer Azure Active Directory (AD) for VPN-autentisering. Organisasjoner med Microsoft 365 har allerede Azure AD og kan sette opp betinget tilgang for å gi uttrykkelig validering av sterk brukerautentisering og integrering av enhetssignaler fra Intune og Microsoft Defender for Endpoint (MDE). Selv om det ikke løser utfordringen for VPN som gir full nettverkstilgang, vil det i betydelig grad gjøre det vanskeligere for cyberkriminelle å utføre et angrep. Med integrerte tjenester i Microsoft 365 blir det enklere å overvåke fjerntilgangen.

Neste trinn er å publisere lokale apper til Internett med Azure AD Application Proxy, så de kan nås direkte via URLer eller i My Apps-portalen. Dette gjør det mulig for brukere enkelt å få tilgang til applikasjonene uten at de behøver være på nettverket. Det reduserer også skaden en angriper med stjålen brukerlegitimasjon kan påføre virksomheten. VPN-logger gir ofte god innsikt i hvilke apper som anvendes mest, så du kan prioritere appene som skal publiseres. VPN og Application Proxy kan operere side om side mot de samme applikasjonene, så du kan få til en smidig, rullende overgang.

Hybride skyapplikasjoner

Med Azure AD App Proxy blir lokale applikasjoner til hybride skyapper. Du publiserer dem via offentlige nettadresser. Brukere aksesserer appene fra Internett. Du må ikke åpne brannmurporter for innkommende trafikk; Application Proxy-koblingene bruker kun utgående koblinger og lytter til tjenesten i skyen over portene 80 og 443. Brukere gis adgang like enkelt og trygt som om de jobber med Microsoft 365. Det er støtte for:

• Nettapper som bruker integrert Windows-autentisering
• Nettapper med hode- eller skjema-basert autentisering
• Applikasjoner som publiseres via Remote Desktop Gateway
• SharePoint lokalt

Brukere logger på via web med samme brukernavn som i Microsoft 365 eller Azure og kan benytte en HTML-basert klient. Det er støtte for integrert engangspålogging (SSO – single sign-on). Om brukere først er logget på Microsoft-skyen, trenger de ikke å gjør det på nytt. Fjerntilgangen får på den måten de mest moderne autentiseringsmetodene, så som passordløst med Windows Hello for Business, Microsoft Authenticator og FIDO2-nøkler.

Fordelen er at dette er transparent for brukere, samtidig som de slipper å stri med å opprette et VPN. Alle sikkerhetsmekanismer i Azure AD er tilgjengelige, så som betinget tilgang, passord- og identitetsbeskyttelse pluss overvåking. Du behøver ikke tilpasse applikasjonene. Løsningen er lekende lett å sette opp, administrere og vedlikeholde. Brukere behøver ikke å komme inn i bedriftsnettverket når de befinner seg utenfor. Er de innenfor, anbefales det at de går utenom Azure AD App Proxy. Etter hvert bør det ikke være behov for brukere flest å logge seg på et internt bedriftsnettverk lenger. Du kan segmentere nettverket med servere og publisere applikasjonene til et annet lokalnett der brukerne befinner seg. Sånn får du ett og samme policybeslutningspunkt for interne og eksterne tilganger – et sentralt moment for Null tillit.

Flytter du noen av applikasjonene opp i skyen, fører det ikke til endringer i brukertilgangen. Du sparer omkostninger ved at du ikke trenger foreta endringer i infrastrukturen eller sette opp en gateway inn. Med fjernarbeid er det viktig at ansatte har trygg tilgang til appene de trenger, uansett hvor de jobber fra. I grafikken ovenfor nevnes IaaS, Infrastructure as a Service (infrastruktur som tjeneste). Det kan være dine egne apper som kjører på virtuelle maskiner lokalt, i Azure eller hos tredjeparter, som Google Cloud Platform (GCP) eller Amazon Web Services (AWS). Som en sikkerhetsekspert en gang uttrykte det: «Det er likegyldig hvor applikasjonsserverne befinner seg, på et annet kontinent eller i en romferge – om man ser bort fra responstiden.»

Brukersesjon

1. Etter at brukeren har fått tilgang til applikasjonen via et endepunkt, blir brukeren omdirigert til Azure AD-påloggingssiden. Hvis du har konfigurert retningslinjer for betinget tilgang, kontrolleres spesifikke betingelser for å sikre at du overholder organisasjonens sikkerhetskrav.
2. Etter en vellykket pålogging sender Azure AD et token til brukerens klientenhet.
3. Klienten sender tokenet til Application Proxy-tjenesten, som henter brukerhovednavnet (UPN) og sikkerhetsprinsipalnavnet (SPN) fra tokenet.
4. Application Proxy videresender forespørselen, som plukkes opp av Application Proxy-koblingen.
5. Koblingen utfører eventuell tilleggsgodkjenning som kreves på vegne av brukeren (avhengig av autentiseringsmetode), ber om det interne endepunktet til applikasjonsserveren og sender forespørselen til den lokale applikasjonen.
6. Svaret fra applikasjonsserveren sendes gjennom koblingen til Application Proxy-tjenesten.
7. Svaret sendes fra Application Proxy-tjenesten til brukeren.
   
   

Støtte for apper og protokoller

Azure AD Application Proxy dekker tre brukerscenarioer:

• Pre-autentisere tilgangen med Azure AD, som innbefatter alle innebygd identitetsbeskyttelse
• Gi direkte adgang til appene uten godkjennelse av Azure AD. Så kan man lokalt la tilgangen være uautorisert, eller man kan benytte webskjema-autentisering, også kjent som form-basert.
• Publisere apper med RD Gateway (eksternt skrivebord)

Det er rik støtte for oversettelse av autentiseringsprotokoller. Kerberos sørger for tosidig verifisering av brukere og server i Windows AD-nettverk. OpenID Connect (OIDC) er et identitetslag bygget på toppen av OAuth 2.0-rammeverket. OIDC tar seg av brukerautentisering, mens OAuth 2.0 dreier seg om ressurstilgang og deling. Security Assertion Markup Language (SAML) er en åpen standard for utveksling av autentiserings- og autorisasjonsdata mellom parter, en identitetsleverandør og en tjenesteleverandør. WS-Federation er en protokoll som lar en bruker få tilgang til ressurser og tjenester på flere sikkerhetsdomener eller nettverk så sant et tillitsforhold er etablert. HTTP headers støtter flere autentiseringsmekanismer for å kontrollere tilgangen til sider og andre ressurser, basert på 401-statuskoden.

Moderne applikasjonskontroll og publisering

I utgangspunktet må du innlemme alle skyapplikasjoner i Azure AD for enkel engangspålogging (SSO). Du bør publisere alle lokale apper med Azure AD App Proxy. Så skal du overvåke og begrense adgangen til applikasjonene med Conditional Access App Control (CAAC) – Appkontroll i kombinasjon med betinget tilgang, noe som krever Microsoft Defender for Cloud Apps (MDCA). Det sikrer sesjonene og gir deg finmasket kontroll over apper, tilganger og data. Alt dette til sammen sørger for en holistisk tilnærming til sikkerheten i hele virksomheten.

Sette opp Azure AD App Proxy

Du konfigurerer apper i Enterprise applications i portalen for Azure Active Directory (AD). Du gir den et navn, angir intern adresse og ekstern nettadresse. Du bruker typisk sikker HTTPS mot Internett. Om du velger msapproxy.net, legges det automatisk til et SSL/TLS-sertifikat. For eget domene må du skaffe deg et offentlig sertifikat og importere det i Azure. Du har valget mellom pre-autentisering av Azure AD eller slippe datastrømmen rett gjennom og la lokalt AD ta seg av godkjenningen.

Lokalt kjører disse to tjenestene. For feiltoleranse bør du installerer minst to koblinger på forskjellige servere. Noen øyeblikk etter at agentene er installert, vil du se dem under Services.

Avsluttende ord

To typer VPN-løsninger som absolutt fortsatt har livets rett, er ikke berørt her. Den ene er forbruker-VPN som sikrer personvern ved nettbruk. Den andre er sted-til-sted-VPN som erstatter dedikerte vidstrakte nettverk (WAN) på tvers av atskilte geografiske lokasjoner. Om du følger anbefalingene her, vil du i betydelig grad kunne styrke sikkerheten i virksomheten din. Du får et sentralt punkt der policyer avgjøres, og flere distribuerte punkter som håndhever policyene. Du stoler ikke på noe, men verifiserer det alltid. Du gir akkurat de tilgangene som er nødvendige. Du reduserer angrepsflaten. Dette er de tre stikkordene for Null tillit.