2024-11-12 Truselsmodel

"I gamle dage"

Den sikkerhedsmæssige tilgang jeg har læst meget om i forhold til en traditionel monolittisk applikation er:

the walled garden (Markeret med en rød linje)

Billedet er fra propertylistings

Alt ekstern kommunikation med appen skulle først passere en sikkerhedsmur. Når denne var krydset, blev al trafik derefter betragtet som pålidelig, hvilket tillod fri adgang internt i systemet.

Dette er efterhånden en saga blot.

For det første kan appen nu være distribueret hvilket gør at muren, som før dækkede hele vejen rundt om hele appen, nu kun indeholder en del af appen.

The walled garden er ikke længere en brugbar metode

En Ny tilgang

I en distribueret app, som vi har lavet i vores projekt løste vi denne nye udfordring med følgende tiltag.

Vi vidste allerede til at starte med grundet at vi skulle have et distribueret system at noget af sikkerheden vil ligge i en eventuel API og/eller en API-Gateway

Gateway

Vi benyttede os af en API-Gatewayfor at skabe en fælles kontaktflade for de kald der opstod til den bagvedliggende API (og måske på sigt flere API'er)

I vores gateway gjorde vi følgende tiltag for at styrke sikkerheden i vores backend:

1. Vi implementerede en default Authentication og Authorization i gateway
2. Vi udliciterede ansvaret for bruger oprettelse og administration af dette til Supabase. Vi vil senere bruge den JWT token , som Supabase laver, til at bekræfte brugerne gennem vores system.

Fordele ved Gateway'en

Fordelene ved at have en gateway i vores projekt gør at vi kunne have et fælles sted hvor al trafikken ind i vores API kunne autoriseres.

Vi vil kunne load balance vores strøm af trafik gennem systemet.

Vi vil kunne lave bedre monitorering.

Ulemperne ved Gateway'en

Der vil opstå et single point of failure.

Der vil opstå øget kompleksitet.

Den vil kunne øge latency og sænke ydeevnen.

Versionering kan blive en udfordring.

Refleksioner om gateway

Vi valgte at lave vores gateway selv. Til dels fordi at jeg skulle lære hvordan den bruges og opsættes.
Et argument, og et godt et, kan være at udeligere ansvaret for dette til en tredjepart, her kommer store spillere ind som AWS, GOOGLE etc. på banen. Disse udbydere har services der kan lave en gateway løsning bedre end vi kan.

Men de er dog stadig lavet af mennesker(for nu), så i overvejelsen af hvilken tredjepart man indgår samarbejde med kan man overveje følgende:

• Hvordan leverer de sikkerheden i deres løsning?
• Hvilke muligheder er der for Autorisation og autentificering?
• Hvad er prismodellen?
• Er der funktioner som fx load balancing og caching?
• Bliver man bundet til udbyderen?

Hvad ligger kunden værdi på?

Inden jeg går videre med implementeringen er det vigtigt at man som udvikler kan oplyse kunden om det sikkerhedsudfordringer som en app, som de ønsker, står over for.

Til dette kan man gøre brug af en risiko analyse:

kilde: risikoanalyse fra center for ledelse

I vores tilfælde bruger vi som sådan ikke personfølsom data i vores Projekt VitaHus, men i tilfælde af at dette blev nødvendig vil en sikkerhedstrussel som dette emne sagtens kunne ende i det røde felt.

Dette vil dermed skabe en prioritering i forhold til hvad det er som skal sikres først i udviklingen af systemet og give kunden et struktureret overblik over sikkerheden/sårbarhederne i deres system inden koden er skrevet.

Dette vil gøre 3 ting:

1. Kunden vil føle sig sikker i forhold til samarbejdet med os som programmører.
2. Kunden vil kunne fokusere på det der giver værdi for dem.
3. Det vil være betydeligt billigere at udvikle appen.

Authentication og Authorization

Vi sørgede for at når der kom et kald til vores gatewayså skulle det være autoriseret for at kunne benytte sig af vores endpoints.
I forhold til OWASP API top 10 så rammer denne tilgang flere af punkterne i top 10'en.
Blandt andet:
Broken Authentication
Broken Function Level Authorization
Broken Object level Authorization

Forbedringer

Der hvor vi kunne gøre det bedre var at præcisere endnu mere i forhold til hvad det er for data som den specifikke bruger skal have rettighed til når de laver et kald.
Det er en dialog som vi som udviklere skal tage tidligt i processes. Hvis dette ikke bliver gjort er der større tilbøjelighed til at gå med en default løsning for at få det til at fungere.

Er det nok som almindelig bruger at have adgang til dto'er?

Dette vil gøre at vi levede bedre op til OWASP API top 10.

Supabase

I starten af vores projektbrugte vi Auth0, til at holde styr på Auth-delen af vores projekt. Vi fandt dog ud af at Auth0er brugbart hvis man ønsker at appen skal kunne tilgå på en anden måde en vi ønskede.
Derfor skiftede vi til at benytte Supabasei stedet.
Vores Frontend team implementerede en route i vores front der fik lavet en JWT tokenhos Supabasesom vi så brugte til at verificere brugeren i voresgateway.

Ud fra ovenstående kan man argumentere for at vi har benyttet os af princippet Zero Trust.

For vores vedkomne er dette mere held end en faktisk overvejelse.

Tanker og Refleksioner

Meget af det jeg har læst om it sikkerhed i og omkring microservices har været meget omfattende.
Dette bakkes op i bogen af Building Microservices af Sam Newman. Han udtrykker det på følgende måde for at lette byrden for programmører:

Overlad det du kan overlade - til andre.

Med dette mener han at microservices er sådan et bæst at arbejde med at hvis man selv skulle lave alt fra bunden vil det hurtigt kunne blive alt for stor og ikke mindst dyr en mundfuld.

Gateway

Den gateway jeg har opsat til projektet, implementeret med Yarp, er meget funktionel og sikkerhedsmæssigt utilstrækkelig. Så hvorfor ikke benytte sig af nogen der har lavet en løsning allerede?

Ovenstående har allerede gode løsninger der kan tage hånd om flere af de udfordringer vi allerede er stødt på i vores app, rent sikkerhedsmæssigt.

Ved at udlicitere ansvaret for den del af vores app til en ekstern provider vi vi hurtigere kunne komme frem til den værdi som vores kunde har efterspurgt.

Vi vil hurtigere kunne levere en MVP som leverer den værdi som kunden har bedt om, og ikke mindst er mere sikker.

IT-Sikkerhed fra start

Vi brugte feature driven design fra start og forsøgt så hurtigt som muligt at få skabt en MVP i forhold til at få skabt den værdi som kunden ønskede.

Set fra et sikkerhedsperspektiv, er dette ikke optimalt.

Men i forhold til min læring vidste jeg ikke bedre. Jeg startede med at lære om microservice arkitektur og havde i denne sammenhæng ikke fokus på sikkerheden i systemet.

Sikkerheds aspektet kom først senere, og da det kom var der store dele af systemet der skulle laves om.