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:

• Autentificare obligatorie. Toate cererile HTTP necesită autentificare.

• Autentificare în memorie. Un utilizator implicit (user) cu o parolă generată aleatoriu, afișată în loguri la pornirea aplicației.

• Protecție CSRF. Este activată implicit pentru a preveni atacurile de tip Cross-Site Request Forgery.

• Formular de login standard. Este disponibil la /login, cu suport pentru logout la /logout.

PRO: Personalizare

• Definirea unui SecurityFilterChain personalizat. în Spring Security 6, WebSecurityConfigurerAdapter a fost înlocuit de SecurityFilterChain pentru o configurare mai flexibilă.

• Implementarea autentificării JWT. JWT este un bilet de acces semnat digital care conține atât informații despre utilizator și roluri, cât și o semnătură secretă. Este compus din trei bucăți: algoritmul de criptare, informațiile (ex: nume utilizator, mărime pantof) și cheia. Cheia se decodează cu un bean de JwtDecoder. În ambele versiuni — Spring Boot 2 și 3 — NimbusJwtDecoder este utilizat implicit atunci când se setează issueruri. În Spring Boot 3, ca și în 2, definirea manuală a unui JwtDecoder este necesară doar dacă dorim o configurare personalizată.

• Controlul accesului bazat pe roluri (RBAC). Utilizăm adnotări precum @PreAuthorize("hasRole('ADMIN')") pentru a restricționa accesul la anumite metode.

• Configurarea CORS. Pentru a permite sau restricționa accesul din diferite origini.

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ă:

• Tokenul este verificat la fiecare request (stateless).

• Are o durată de viață scurtă.

• Nu conține date sensibile.

• Poate fi revocat (blacklist / refresh logic).

• Și mai ales: dacă îl folosim într-un ecosistem unde nimeni nu e de încredere.

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

• Autentificare puternică: JWT semnat + validare atentă + expirare scurtă.

• Autorizare detaliată: roluri, permisiuni, scopes. (@PreAuthorize("hasAuthority('PRODUCT:WRITE')") este mai granular decât hasRole('ADMIN')) .

• Micro-segmentare internă: serviciile interne comunică doar dacă sunt autentificate (mTLS / tokenuri de serviciu).

• Limitarea privilegiilor: un utilizator logat vede doar datele proprii; un administrator nu poate șterge fără un al doilea pas de validare.

• Monitorizare și auditare continuă: logarea cererilor.

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

• Presupunem că dacă JWT-ul este semnat, totul este ok.

• Lăsăm tokenul să trăiască 24h: un atacator are o zi întreagă.

• Nu verificăm semnătura corespunzător. Dacă folosim doar issueruri, putem avea atacuri de tip Falsificare DNS sau Man-in-the-Middle. Dacă folosim basic jwk-seturi putem avea parte de clasica eroare umană.

• Fără loguri: Zero Trust înseamnă și detectare.

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.