Xavfsizlik arxitekturasi

Endi arxitektor uchun eng xavfli va eng muhim mavzulardan biri:

Security architecture - systemni faqat "login-parol" bilan himoyalash emas, balki butun architecture darajasida xavflarni kamaytirish.

Bu bo‘limda ichida quyidagilar bor: Zero Trust Architecture, Threat Modeling, Service-to-service mTLS, PKI & certificate management, Compliance frameworks.

1. Security Architecture nima?

Oddiy developer ko‘pincha security’ni shunday tushunadi:

Login qildik
JWT berdik
Endpointga @PreAuthorize qo‘ydik
Bo‘ldi

Arxitektor esa kengroq qaraydi:

Kim kimga ishonadi?
Qaysi data sensitive?
Qaysi servis qaysi servisni chaqira oladi?
Token o‘g‘irlansa nima bo‘ladi?
Database leak bo‘lsa zarar qancha?
Internal network ichidagi servislar ham tekshiriladimi?
Secretlar qayerda saqlanadi?
Audit log bormi?
Xavf oldindan model qilinganmi?
Compliance talablar bormi?

Security architecture - bu:

Identity
+ Authentication
+ Authorization
+ Network security
+ Data protection
+ Secrets management
+ Threat modeling
+ Audit
+ Compliance
+ Incident response

2. Security Architecture nega kerak?

System kattalashganda security faqat koddagi filter emas.

Masalan:

Frontend → API Gateway → Backend → Database

Kichik projectda bu oddiy ko‘rinadi. Lekin production’da savollar chiqadi:

Frontend tokenni qayerda saqlaydi?
API Gateway requestni tekshiradimi?
Backend har requestda permission tekshiradimi?
Service ichki networkda ochiqmi?
Database internetga ochiq emasmi?
Backup shifrlanganmi?
Logs ichida token yoki parol yo‘qmi?
Admin panelga kim kira oladi?

Security architecture shu savollarga aniq javob beradi.

3. Security’ning asosiy prinsiplari

1. Defense in Depth

Bitta himoya yetarli emas. Bir nechta qatlam bo‘lishi kerak.

WAF
 ↓
API Gateway
 ↓
Authentication
 ↓
Authorization
 ↓
Input validation
 ↓
Service-to-service security
 ↓
Database access control
 ↓
Encryption
 ↓
Audit log

Agar bitta qatlam buzilsa, keyingisi himoya qiladi.

2. Least Privilege

Har user, service yoki process faqat o‘ziga kerakli minimal huquqqa ega bo‘lishi kerak.

Yomon:

report-service database’da hamma table’ni o‘qiy oladi va o‘zgartira oladi

Yaxshi:

report-service faqat kerakli read-only view/table’larni o‘qiydi

Yomon:

developer production DB admin passwordini biladi

Yaxshi:

temporary access
approval
audit
read-only
time-limited permission

3. Secure by Default

Default holatda hamma narsa yopiq bo‘lishi kerak.

Endpoint default yopiq
Network default deny
Admin action default restricted
Service credential default minimal
Public bucket default forbidden

Yomon yondashuv:

Avval hammasini ochamiz, keyin kerakmasini yopamiz

To‘g‘ri yondashuv:

Avval hammasini yopamiz, keyin keraklisini ochamiz

4. Never Trust Input

Har qanday input xavfli deb qaraladi:

HTTP request body
Query param
Header
JWT claim
File upload
Message broker event
Webhook
Admin panel input
CSV import

Misol:

Frontend validation bor = backend validation shart emas

Bu noto‘g‘ri. Frontend validation UX uchun. Backend validation security uchun.

4. Zero Trust Architecture

Zero Trust nima?

Zero Trust degani:

"Internal network ichida bo‘lsa ham, avtomatik ishonma."

Oldingi model:

Company network ichida bo‘lsa → ishonchli
Tashqi internetdan bo‘lsa → xavfli

Zero Trust modeli:

Har request tekshiriladi
Har service identity’ga ega
Har access minimal
Har action audit qilinadi
Network ichida bo‘lsa ham ishonilmaydi

Oddiy misol

Yomon internal model:

Order Service → Payment Service
Ichki networkda, demak authentication kerak emas

Bu xavfli. Agar attacker bitta servisni buzsa, butun internal network bo‘ylab yurishi mumkin.

Zero Trust:

Order Service → Payment Service
mTLS bilan service identity tekshiriladi
Token/scope tekshiriladi
Network policy ruxsat berishi kerak
Request audit qilinadi

Zero Trust elementlari

Java/Spring Boot’da Zero Trust qanday ko‘rinadi?

External request:
User JWT/OIDC token bilan keladi
API Gateway tokenni tekshiradi
Backend permission tekshiradi

Internal request:
Service A Service B’ni chaqiradi
mTLS orqali identity tekshiriladi
Service token yoki client credentials ishlatiladi
Network policy ruxsat beradi

5. Authentication vs Authorization

Authentication

Authentication - bu "siz kimsiz?" degan savol.

Misollar:

Login/password
OTP
OAuth2
OpenID Connect
Biometric login
Client certificate
Service account

Authorization

Authorization - bu "sizga buni qilish mumkinmi?" degan savol.

Misollar:

User login qildi, lekin admin panelga kira oladimi?
Agent faqat o‘z mijozlarini ko‘ra oladimi?
Supervisor faqat o‘z regionidagi agentlarni ko‘ra oladimi?
Reportni export qilishga permission bormi?

Farqi

Katta xato:

User login qilgan = hamma narsaga ruxsat

Bu security bug.

6. RBAC va ABAC

RBAC - Role-Based Access Control

Huquqlar role orqali beriladi.

ADMIN
SUPERVISOR
AGENT
ACCOUNTANT

Misol:

ADMIN → hamma narsani boshqaradi
SUPERVISOR → agentlarni ko‘radi
AGENT → faqat o‘z orderlarini yaratadi

Spring Security’da:

@PreAuthorize("hasRole('SUPERVISOR')")
@GetMapping("/agents")
public List<AgentDto> getAgents() {
    return service.getAgents();
}

RBAC muammosi

Real biznesda role yetmasligi mumkin.

Masalan:

Supervisor faqat o‘z regionidagi agentlarni ko‘rsin.
Agent faqat o‘ziga biriktirilgan customerlarni ko‘rsin.
Manager faqat o‘z filialidagi orderlarni approve qilsin.

Bu yerda faqat role yetarli emas. Context kerak.

ABAC - Attribute-Based Access Control

ABAC’da qaror attribute’lar asosida qabul qilinadi:

user.role
user.regionId
user.branchId
resource.ownerId
resource.status
request.time
request.ip

Misol:

User role = SUPERVISOR
User region = Tashkent
Agent region = Tashkent
→ ruxsat bor

User role = SUPERVISOR
User region = Tashkent
Agent region = Samarkand
→ ruxsat yo‘q

Java’da permission check misol

public void checkCanViewAgent(UserPrincipal user, Agent agent) {
    if (user.hasRole("ADMIN")) {
        return;
    }

    if (user.hasRole("SUPERVISOR")
            && user.regionId().equals(agent.regionId())) {
        return;
    }

    throw new AccessDeniedException("Not allowed to view this agent");
}

Arxitektor darajasida muhim fikr:

Role tekshirish yetarli emas. Resource-level authorization ham bo‘lishi kerak.

7. Threat Modeling

Threat Modeling nima?

Threat modeling - systemga qanday hujumlar bo‘lishi mumkinligini oldindan tahlil qilish.

Savol:

Kim hujum qilishi mumkin?
Nimani himoya qilyapmiz?
Qaysi yo‘ldan kirishi mumkin?
Agar kirsa zarar qancha?
Buni qanday kamaytiramiz?

Threat modeling codingdan oldin yoki architecture design paytida qilinsa eng foydali.

STRIDE modeli

Threat modeling uchun mashhur model - STRIDE.

Misol: Sales Agent app uchun STRIDE

1. Spoofing

Xavf:

Boshqa odam agent bo‘lib login qilishi
JWT token o‘g‘irlanishi
Fake device orqali request yuborilishi

Yechim:

Strong authentication
Short-lived access token
Refresh token rotation
Device binding ehtiyotkorlik bilan
Suspicious login detection

2. Tampering

Xavf:

Agent order summasini requestda o‘zgartirib yuboradi
Customer ID’ni almashtirib, boshqa customerga order yozadi
Location data fake yuboradi

Yechim:

Backend business validation
Resource ownership check
Server-side price calculation
Audit trail
Signed request faqat zarur bo‘lsa

Muhim qoida:

Narx, discount, permission kabi muhim narsalarga frontenddan ishonilmaydi.

3. Repudiation

Xavf:

Agent "men order yaratmaganman" deydi
Admin "men userni block qilmaganman" deydi

Yechim:

Audit log
User ID
Timestamp
IP/device info
Old value / new value
Immutable log storage muhim actionlar uchun

4. Information Disclosure

Xavf:

Agent boshqa region customerlarini ko‘rib qo‘yadi
Token logga chiqib ketadi
Report orqali sensitive data chiqadi
Backup leak bo‘ladi

Yechim:

Resource-level authorization
Data masking
Encryption
Log sanitization
Access control
Backup encryption

5. Denial of Service

Xavf:

Login endpointga ko‘p request
Report export endpoint DB’ni ezadi
File upload orqali storage to‘ldirish

Yechim:

Rate limiting
Captcha yoki OTP limit
Async report generation
File size limit
Request timeout
Queue limits

6. Elevation of Privilege

Xavf:

Agent admin endpoint chaqiradi
JWT ichidagi role o‘zgartiriladi
IDOR orqali boshqa user data’si olinadi

Yechim:

JWT signature validation
Server-side permission check
Object ownership validation
Admin endpoint isolation
Least privilege

8. API Security

Public API himoyasi

Har public endpoint uchun savollar:

Authentication kerakmi?
Authorization kerakmi?
Rate limit bormi?
Input validation bormi?
Sensitive data response’da chiqmayaptimi?
Error message ortiqcha ma’lumot bermayaptimi?
Audit kerakmi?

IDOR xavfi

IDOR - Insecure Direct Object Reference

Yomon endpoint:

GET /orders/1001

Agar user 1001 o‘rniga 1002 qilib boshqa user orderini ko‘rsa - bu IDOR.

Yomon kod:

@GetMapping("/orders/{id}")
public OrderDto getOrder(@PathVariable Long id) {
    return orderService.findById(id);
}

Bu yerda ownership tekshiruvi yo‘q.

Yaxshi:

@GetMapping("/orders/{id}")
public OrderDto getOrder(@PathVariable Long id,
                         @AuthenticationPrincipal UserPrincipal user) {
    return orderService.findByIdForUser(id, user);
}

Service ichida:

public OrderDto findByIdForUser(Long orderId, UserPrincipal user) {
    Order order = orderRepository.findById(orderId)
            .orElseThrow(NotFoundException::new);

    permissionService.checkCanViewOrder(user, order);

    return mapper.toDto(order);
}

9. JWT Security

JWT ko‘p ishlatiladi, lekin noto‘g‘ri ishlatilsa xavfli.

JWT ichida nima saqlash mumkin?

Yaxshi:

{
  "sub": "user-123",
  "roles": ["AGENT"],
  "iat": 1716200000,
  "exp": 1716200900
}

Yomon:

{
  "password": "123456",
  "passport": "AA1234567",
  "cardNumber": "8600..."
}

JWT shifrlanmagan bo‘lishi mumkin, faqat imzolangan bo‘ladi. Shuning uchun sensitive data JWT ichida bo‘lmasligi kerak.

JWT best practices

Access token qisqa muddatli bo‘lsin
Refresh token alohida saqlansin
Refresh token rotation ishlatilsin
JWT signature har doim tekshirilsin
alg=none kabi zaif konfiguratsiyalardan saqlaning
Issuer va audience tekshirilsin
Token blacklist/revocation strategy kerak bo‘lsa rejalashtirilsin

Access token va refresh token

Mobile app uchun ehtiyot bo‘lish kerak:

Refresh token secure storage’da saqlansin
Logout bo‘lsa refresh token invalidate qilinsin
Device yo‘qolsa token revoke qilish imkoni bo‘lsin

10. OAuth2 va OpenID Connect

OAuth2 nima?

OAuth2 - authorization framework. Ya’ni bir application boshqa applicationga cheklangan access oladi.

Misol:

Google account orqali login
GitHub account orqali login
Payment provider API’ga access

OpenID Connect nima?

OpenID Connect - OAuth2 ustiga qurilgan authentication layer.

Ya’ni user kimligini aniqlash uchun ishlatiladi.

OAuth2 = access delegation
OIDC = login / identity

Enterprise architecture’da

Ko‘p korxonalarda:

Keycloak
Okta
Auth0
Azure AD
Google Identity

kabi Identity Provider ishlatiladi.

Architecture:

User
 ↓
Identity Provider
 ↓
Access Token / ID Token
 ↓
API Gateway
 ↓
Backend Services

Spring Boot’da backend ko‘pincha Resource Server bo‘ladi:

Backend token bermaydi
Backend tokenni tekshiradi
Identity Provider token beradi

11. Service-to-Service Security

Microservices yoki distributed system’da faqat user request emas, service requestlar ham himoyalanishi kerak.

Yomon:

Order Service → Payment Service
Hech qanday authentication yo‘q

Yaxshi:

Order Service → Payment Service
mTLS + service identity + authorization policy

Service identity

Har service o‘z identity’siga ega bo‘lishi kerak:

order-service
payment-service
notification-service
report-service

Payment Service shuni tekshiradi:

Kim meni chaqiryapti?
order-service bunga haqlimi?
report-service payment create qila oladimi?

12. mTLS

mTLS nima?

Oddiy TLS’da client serverni tekshiradi:

Client → Server
Client server certificate’ni tekshiradi

mTLS - mutual TLS da esa ikkala tomon bir-birini tekshiradi:

Client serverni tekshiradi
Server clientni tekshiradi

Ya’ni service-to-service communication’da juda foydali.

Misol

Order Service Payment Service’ni chaqiradi
Payment Service certificate orqali Order Service ekanini tekshiradi
Order Service ham Payment Service certificate’ini tekshiradi

Bu identity beradi.

mTLS qachon kerak?

mTLS foydali:

Microservices ko‘p bo‘lsa
Internal networkga ishonilmasa
Sensitive service communication bo‘lsa
Zero Trust yondashuvi bo‘lsa
Compliance talab qilsa
Service mesh ishlatilsa

Kichik monolith’da shart emas. Lekin external integrationlar uchun TLS albatta kerak.

13. PKI va Certificate Management

PKI nima?

PKI - Public Key Infrastructure

Certificate’larni yaratish, tarqatish, yangilash, bekor qilish va ishonch zanjirini boshqarish tizimi.

PKI ichida:

Certificate Authority
Public key
Private key
Certificate
Trust chain
Revocation
Rotation

Certificate management nega qiyin?

Certificate muddati tugaydi.

Agar renewal bo‘lmasa:

Service-to-service communication to‘xtaydi
API ishlamay qoladi
Mobile app backendga ulana olmaydi
Webhooklar fail bo‘ladi

Shuning uchun certificate lifecycle avtomatlashtirilishi kerak.

Nimalar boshqariladi?

TLS certificate
mTLS client certificate
Internal CA
Certificate rotation
Private key storage
Certificate revocation
Expiry monitoring

Arxitektor savollari

Certificate’larni kim beradi?
Private key qayerda saqlanadi?
Rotation avtomatikmi?
Muddati tugashidan oldin alert bormi?
Compromised certificate qanday revoke qilinadi?
Internal CA bormi yoki external CA ishlatiladimi?

14. Secrets Management

Secretlar:

DB password
JWT signing key
OAuth client secret
API token
Encryption key
Private key
Webhook secret

Bular hech qachon quyida bo‘lmasligi kerak:

Git repository
Telegram chat
Excel file
Docker image ichida
Plain .env production serverda
Loglarda

Yaxshi yechimlar

HashiCorp Vault
AWS Secrets Manager
GCP Secret Manager
Azure Key Vault
Kubernetes Secrets + encryption at rest
Sealed Secrets / SOPS for GitOps

Secret rotation

Secretlar vaqti-vaqti bilan almashtirilishi kerak.

Masalan:

DB password 90 kunda almashadi
JWT signing key rotation bor
API token compromise bo‘lsa revoke qilinadi

Architecture’da rotation rejalashtirilmasa, keyin production’da juda og‘riqli bo‘ladi.

15. Data Protection

Encryption in transit

Tarmoq orqali ketayotgan data shifrlanishi kerak:

HTTPS
TLS for database connection
mTLS for service-to-service
TLS for Kafka/RabbitMQ/Redis zarur bo‘lsa

Encryption at rest

Diskda turgan data ham himoyalanishi kerak:

Database disk encryption
Backup encryption
Object storage encryption
Log storage encryption

Field-level encryption

Ayrim fieldlar application darajasida alohida shifrlanishi mumkin:

passport number
card token
medical information
private documents

Password hashing

Password hech qachon plain yoki reversible encryption bilan saqlanmaydi.

To‘g‘ri:

BCrypt
Argon2
PBKDF2

Yomon:

MD5
SHA-1
plain text
Base64

Base64 encryption emas. Faqat encoding.

16. Logging va Audit Security

Oddiy log

Log debugging uchun:

request received
payment provider timeout
order created

Audit log

Audit log accountability uchun:

Kim?
Qachon?
Nima qildi?
Qaysi resursga?
Oldingi qiymat?
Yangi qiymat?
Qaysi IP/device?

Audit kerak bo‘ladigan actionlar

User login/logout
Password change
Role/permission change
Admin action
Payment status change
Customer delete/update
Report export
Sensitive data view
Token revoke

Loglarda chiqmasligi kerak

password
access token
refresh token
OTP
card number
passport data
private key
JWT full value
authorization header

Yomon:

log.info("Login request: {}", request);

Agar request ichida password bo‘lsa, logga chiqadi.

Yaxshi:

log.info("Login attempt for username={}", request.username());

17. Compliance Frameworks

Compliance nima?

Compliance - ma’lum standart yoki qonun talablari bo‘yicha ishlash.

Misollar:

ISO 27001
SOC 2
PCI DSS
GDPR
HIPAA

Hammasi har projectga kerak emas. Lekin arxitektor qaysi biri kerakligini bilishi kerak.

ISO 27001

Information Security Management System.

Ko‘proq kompaniya darajasidagi security boshqaruvi:

Risk management
Access control
Asset management
Incident management
Policy/procedure
Audit

SOC 2

Cloud/SaaS kompaniyalarida ko‘p uchraydi.

Asosiy trust principles:

Security
Availability
Processing integrity
Confidentiality
Privacy

Agar enterprise mijozlarga SaaS sotilsa, SOC 2 talab qilinishi mumkin.

PCI DSS

Payment card data bilan ishlasangiz kerak bo‘ladi.

Muhim qoida:

Karta ma’lumotlarini o‘zingiz saqlamaslik eng yaxshi strategiya.

Payment provider tokenization ishlating:

Payme/Click/Stripe/etc. karta bilan ishlaydi
Sizda faqat payment token/status saqlanadi

GDPR

Personal data bilan ishlash qoidalari.

Muhim prinsiplar:

Data minimization
Consent
Right to access
Right to deletion
Purpose limitation
Retention
Privacy by design

O‘zbekiston loyihasida ham bu prinsiplar foydali, ayniqsa xalqaro bozorga chiqish rejalansa.

18. Security Architecture Patterns

1. API Gateway Security

Client
 ↓
API Gateway
 ↓
Backend Services

API Gateway vazifalari:

TLS termination
Rate limiting
Authentication pre-check
Request size limit
IP allow/deny
Routing
WAF integration
Basic threat protection

Lekin muhim:

Gateway tekshiradi, lekin backend ham authorization qilishi kerak.

Gatewayga to‘liq suyanib qolish xato.

2. BFF - Backend for Frontend

Mobile app va web app uchun alohida backend facade.

Mobile App → Mobile BFF → Core Services
Web App    → Web BFF    → Core Services

Foyda:

Mobile uchun maxsus API
Token handling markazlashadi
Frontendga ortiqcha internal data chiqmaydi
Security policy aniqroq bo‘ladi

3. Token Exchange

External user tokenni internal service tokeniga almashtirish.

User JWT → API Gateway/BFF → Internal service token

Bu orqali internal service’lar external tokenni hamma joyga tashib yurmaydi.

4. Network Segmentation

Hamma servis ham hamma servisga ulanmasligi kerak.

report-service → payment-service: forbidden
order-service → payment-service: allowed
public internet → database: forbidden

Kubernetes’da NetworkPolicy bilan qilinadi.

19. Spring Boot Security Architecture

Java/Spring Boot backend uchun amaliy qatlamlar:

1. HTTPS
2. API Gateway / Nginx
3. Spring Security filter chain
4. JWT/OIDC validation
5. Method-level authorization
6. Resource-level permission check
7. Input validation
8. Business rule validation
9. Repository/database access
10. Audit log

Spring Security misol

@Configuration
@EnableMethodSecurity
public class SecurityConfig {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .csrf(csrf -> csrf.disable())
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers("/actuator/health/**").permitAll()
                        .requestMatchers("/api/admin/**").hasRole("ADMIN")
                        .anyRequest().authenticated()
                )
                .oauth2ResourceServer(oauth2 -> oauth2.jwt())
                .build();
    }
}

Lekin bu yetarli emas. Service layer’da resource check ham kerak:

@PreAuthorize("hasRole('SUPERVISOR')")
public AgentDto getAgent(Long agentId, UserPrincipal user) {
    Agent agent = agentRepository.findById(agentId)
            .orElseThrow(NotFoundException::new);

    permissionService.checkCanViewAgent(user, agent);

    return mapper.toDto(agent);
}

20. Mobile App Security

Supervisor va Sales Agent kabi Android app’larda alohida e’tibor kerak.

Xavflar

APK reverse engineering
Token o‘g‘irlanishi
Root qilingan device
Fake location
MITM attack
Old app version ishlatilishi
API endpointlarni bevosita chaqirish

Himoya

HTTPS majburiy
Certificate pinning ehtiyotkorlik bilan
Secure storage for tokens
Short-lived access tokens
Refresh token rotation
Root/jailbreak detection faqat qo‘shimcha signal sifatida
Backend-side validation
App version policy
Rate limiting
Device/session management

Muhim:

Mobile app ichidagi har qanday logicni attacker ko‘rishi va o‘zgartirishi mumkin. Shuning uchun muhim qaror backend’da bo‘lishi kerak.

Masalan:

Discount hisoblash
Permission check
Order total
Agent territory check
Payment status

bular backend’da tekshiriladi.

21. File Upload Security

File upload xavfli joy.

Xavflar:

Malicious file
Huge file upload
Wrong content type
Path traversal
Public bucket leak
Virus/malware
Executable upload
Image metadata leak

Yechimlar:

File size limit
Allowed MIME types
Extension validation
Content sniffing
Random file name
Private bucket by default
Pre-signed URL
Virus scan kerak bo‘lsa
Image metadata strip
Direct execution forbidden

Yomon:

/uploads/{originalFileName}

Yaxshi:

/files/2026/05/random-uuid.jpg

22. Rate Limiting va Abuse Protection

Rate limit kerak bo‘ladigan endpointlar:

/login
/otp/send
/password/reset
/report/export
/file/upload
/search
/public APIs

Misol:

Login: 5 attempt / minute / IP
OTP: 3 request / 10 minutes / phone
Report export: 5 request / hour / user
Search: 60 request / minute / user

Rate limiting Redis bilan qilinishi mumkin.

23. Security Monitoring

Security faqat oldini olish emas, aniqlash ham.

Kuzatiladigan signallar:

Failed login spike
Multiple OTP requests
Token reuse
Refresh token anomaly
Admin action spike
Unusual report export
Access denied spike
High 401/403 rate
New country/device login
Large file upload attempts

Bular alertga ulangan bo‘lishi kerak.

24. Incident Response

Security incident bo‘lsa, oldindan plan kerak.

Savollar:

Kim javobgar?
Qanday aniqlaymiz?
Qaysi tokenlarni revoke qilamiz?
Qaysi secretlarni rotate qilamiz?
Loglar qayerda?
Backup bor?
Mijozlarga xabar berish kerakmi?
Forensics uchun data saqlanadimi?

Minimal incident response flow:

Detect
 ↓
Contain
 ↓
Eradicate
 ↓
Recover
 ↓
Postmortem
 ↓
Prevent recurrence

25. Real loyiha misoli: Sales Agent / Supervisor

Architecture:

Supervisor Android App
Sales Agent Android App
        |
HTTPS
        |
Nginx / API Gateway
        |
Spring Boot Backend
        |
PostgreSQL
Redis
MinIO/S3
RabbitMQ

Security strategy

Authentication

OIDC/Keycloak yoki Spring Authorization Server
Access token qisqa muddatli
Refresh token rotation
Device/session management

Authorization

ADMIN
SUPERVISOR
AGENT

Supervisor → faqat o‘z regionidagi agent/customer/order
Agent → faqat o‘ziga biriktirilgan customer/order
Admin → global access

API protection

HTTPS only
Rate limiting
Input validation
Request size limit
Central error handling
No sensitive data in error response

Data protection

PostgreSQL encryption at rest
Backup encryption
Sensitive fields masking
Password hashing with BCrypt/Argon2
No tokens/passwords in logs

Audit

Login
Order create/update
Customer update/delete
Role change
Report export
Admin actions

File upload

MinIO/S3 private bucket
Pre-signed URL
File size/type limit
Random file names

26. Security checklist

Authentication OIDC/JWT bilan aniqmi?
Access token qisqa muddatlimi?
Refresh token rotation bormi?
Authorization resource-level tekshirilyaptimi?
IDOR himoyasi bormi?
Role va permission modeli aniqmi?
Sensitive data JWT ichida emasmi?
Secretlar Gitda emasmi?
Password BCrypt/Argon2 bilan hash qilinganmi?
HTTPS majburiymi?
Internal service access cheklanganmi?
Rate limiting bormi?
File upload xavfsizmi?
Audit log bormi?
Token/parol logga chiqmayaptimi?
Backup shifrlanganmi?
Security monitoring bormi?
Incident response plan bormi?

27. Katta xatolar

1. Faqat frontendga ishonish

Button yashirilgan = user bu actionni qila olmaydi

Noto‘g‘ri. API baribir tekshirishi kerak.

2. Faqat role tekshirish

hasRole('SUPERVISOR')

yetmaydi. Supervisor qaysi region/resource ustida action qilayotganini ham tekshirish kerak.

3. JWT ichiga sensitive data qo‘yish

JWT decode qilinishi mumkin. Ichiga passport, password, phone verification code, karta ma’lumoti qo‘yilmaydi.

4. Secretlarni Gitga qo‘yish

Bu eng og‘ir xatolardan biri. Git tarixidan ham o‘chirish qiyin.

5. Internal networkga ko‘r-ko‘rona ishonish

Microservices ichki networkda bo‘lsa ham, authentication/authorization kerak.

6. Audit log yo‘qligi

Admin kimning permissionini o‘zgartirgani noma’lum bo‘lsa, incident tekshirish qiyinlashadi.

28. Arxitektor qaror tartibi

Security architecture tanlashda tartib:

1. Assetlarni aniqlash
2. Sensitive data’ni ajratish
3. Threat modeling qilish
4. Authentication model tanlash
5. Authorization model tanlash
6. Network boundary chizish
7. Data protection strategiyasini belgilash
8. Secrets management tanlash
9. Audit va monitoring qo‘shish
10. Incident response plan qilish
11. Compliance talablarini tekshirish

29. Yakuniy formula

Security Architecture =
Identity
+ Access Control
+ Threat Modeling
+ Network Protection
+ Data Protection
+ Secrets Management
+ Audit
+ Monitoring
+ Incident Response
+ Compliance

Eng muhim xulosa:

Security architecture - "hacker kirmasin" degani emas. Hacker kirishga urinsa, system qancha zarar ko‘radi, qanchalik tez aniqlaymiz va qanchalik tez tiklanamiz - mana shu arxitektor darajasidagi savol.

Java/Spring Boot loyihalar uchun amaliy start:

HTTPS only
+ OIDC/JWT
+ short-lived access token
+ refresh token rotation
+ RBAC + resource-level authorization
+ input validation
+ rate limiting
+ secure secrets
+ encrypted backups
+ audit logs
+ no sensitive data in logs/JWT
+ security monitoring
+ incident response plan

Arxitektor sifatida eng muhim savol:

"Biz kimga, nimaga va qaysi sharoitda ishonamiz - va bu ishonch buzilsa nima bo‘ladi?"