TSM - Zero Trust în Java

Denisa Lupu - Java Software Developer @ msg systems Romania

Fără dar și poate ne adâncim într-o eră în care devine tot mai ușor să folosim tehnologia, dar și părțile ei "întunecate". Într-o societate tot mai marcată de atacuri cibernetice și breșe de securitate, trebuie să recunoaștem că încrederea în tehnologie este supraevaluată. Ca prim pas spre o lume mai sigură cibernetic, există concepte care să ne protejeze de asta: Arhitectura Zero Trust (ZTA).

Într-o lume în care microserviciile comunică între ele mai des decât adolescenții pe TikTok, presupunerea că orice actor din rețea este de încredere nu este doar naivă, este și periculoasă. Din fericire, pentru cei dintre noi care ne construim API-urile cu Spring Boot, avem la dispoziție unelte puternice (și destul de fail-safe până la proba contrarie) pentru a dormi liniștiți cu gândul la siguranța aplicațiilor și, cel mai important, a datelor noastre: Spring Security, JSON Web Tokens (JWT) și o doză sănătoasă de paranoia.

Zero Trust Architecture - de la filosofie la cod

Până ajungem să-l punem efectiv în practică, acest concept de programare implică o filozofie la care se aderă cu ușurință - cum este și cu Clean Code. În forma sa cea mai simplă, înseamnă să nu avem încredere în nicio relaționare cu aplicația noastră înainte de a verifica "cu ochii noștri". Se aplică utilizatorilor, dispozitivelor, aplicațiilor. Fiecare request este o potențială amenințare până la proba contrarie.

Pentru a proteja aceste ținte de REST API-uri care deschid drumul către logica și datele sensibile ale unei aplicații, avem nevoie de mai mult decât un firewall, pentru că și requesturile verificate pot avea intenții "răuvoitoare", ca un musafir pe care îl invităm în casă, dar aflăm prea târziu că are pantofii murdari.

Aici intervin Spring Security și JWT.

Spring Security este un bodyguard digital, căruia nici măcar nu trebuie să-i dăm multe instrucțiuni pentru a face basicul de protecție. Aduce cu sine un pachet întreg de beneficii și prevenții pe care îl putem gestiona sau personaliza, dar pe care îl putem și strica.

BASIC: Ce face Spring Security "din fabrică" Adăugând doar dependența de spring-boot-starter-security avem:

PRO: Personalizare

Anti-Tutorial - Focul cu care să nu ne jucăm în configs

Spring Security ne oferă puterea să protejăm, dar și libertatea să greșim. Acestea ar fi, în experiența mea, cele mai comune capcane în configurarea SecurityFilterChain:

1. Dezactivăm CSRF pentru toate cererile... pentru că "nu merge POST-ul"

http.csrf(AbstractHttpConfigurer::disable);

Intenția bună: "Nu mai dă aplicația 403."

Ce se întâmplă de fapt: Lăsăm aplicația deschisă la CSRF dacă folosim sesiuni. Un atacator poate executa cereri în numele unui utilizator logat. Când este (mai) ok: doar dacă aplicația e stateless, cu JWT sau tokenuri în header.

2. Dăm liber la tot traficul cu permitAll()

http.authorizeHttpRequests(

http.authorizeHttpRequests(
 auth -> auth.requestMatchers(“/**”).permitAll()
);

Intenția bună: "Să meargă toate requesturile"

Ce se întâmplă de fapt: backendul este complet expus. Dacă aplicația este în producție, o să apară și pe Reddit.

Fix:

.requestMatchers(“/auth/**”, “/public/**”)
.permitAll()
.anyRequest()
.authenticated()

3. JWT cu chei simple

.sessionManagement(

   session->session.sessionCreationPolicy(
    SessionCreationPolicy.ALWAYS)
)

Intenția bună: "Să fim siguri că fiecare utilizator are sesiunea lui."

*Ce se întâmplă de fapt: adăugăm sesiuni pe un sistem care ar trebui să fie stateless*.

Fix:

.sessionManagement(
  session -> session.sessionCreationPolicy(
    SessionCreationPolicy.STATELESS))

4. Dezactivăm tot

.csrf(AbstractHttpConfigurer::disable)
.headers(AbstractHttpConfigurer::disable)
.cors(AbstractHttpConfigurer::disable);

Intenția bună: "Testăm local fără să ne încurce chestii de securitate."

Ce se întâmplă de fapt: dezactivăm protecții importante (X-Frame-Options, X-Content-Type-Options etc.).

Fix: selectivitate

http.headers(
  headers -> headers.frameOptions(
    HeadersConfigurer.FrameOptionsConfig::sameOrigin)
);

5. Adăugăm filtrul JWT, dar nu-l plasăm corect

http.addFilter(jwtAuthFilter);

Intenția bună: "L-am adăugat, gata, easy."

Ce se întâmplă de fapt: dacă nu rulează înainte de UsernamePasswordAuthenticationFilter, JWT-ul poate fi ignorat complet.

Fix:

http.addFilterBefore(
  jwtAuthFilter, 
  UsernamePasswordAuthenticationFilter.class
);

JWT-ul este popular și util, dar este doar un instrument într-un sistem mai mare. De fapt, JWT nu ne protejează împotriva accesului neautorizat - doar ne spune cine cere accesul. Cine primește tokenul are acces atâta timp cât este valid.

În paradigma Zero Trust, JWT-ul este doar un pașaport — dar noi suntem la vamă (care nu este în Schengen) și trebuie să verificăm validitatea acelui pașaport: datele din el, autenticitatea, contextul.

De aceea, Spring Security și JWT sunt eficiente doar dacă:

Cum aplicăm Zero Trust într-o aplicație Spring:

Cum să trăim o viață (aplicație) riscantă:

Zero Trust este precum Clean Code: o ideologie care ne face viața și cariera mai ușoară - nouă și altora. Importantă este credința în cât mai multe "reguli" ale ideologiei și urmarea lor.

Cum ar spune orice matematician care se respectă: dacă vrem stabilitate, trebuie să tindem spre 0.