← Atpakaļ uz Izglītošanos
DIAGRAMS · MODELING · THREAT

📐 Sistēmu modelēšana - vizuāli piemēri

Septiņas datu un sistēmu modelēšanas metodes ar diagrammām. Piemēri ir izdomāti, paredzēti mācībām.

Entītiju un attiecību diagramma

ERD - Library Domain (Member · Loan · Book)

ERD - Library domain Member, Loan, Book entities with cardinalities. MEMBER PK member_id full_name : varchar email : varchar joined_on : date status : enum LOAN PK loan_id FK member_id loaned_on : date due_on : date returned_on : date? BOOK PK book_id isbn : varchar(13) title : varchar author : varchar copies_available : int LOAN_ITEM FK loan_id FK book_id · copies: int 1 : N borrows N N PK Primary Key FK Foreign Key ⋯ junction / bridge ? nullable

Kad lietot

Pašā sākumā, kad jāsaprot, kādas lietas (entītijas) sistēmā ir un kā tās savā starpā saistītas - vēl pirms tabulu veidošanas.

Saistīts standarts

Chen ERD (1976), Crow's Foot notation, IDEF1X. Bieži ievada datu vārdnīcas (data dictionary).

Ierobežojumi

Nerāda ne gala tabulas, ne biznesa likumus. “Daudzi pret daudziem” saites vienmēr jāsadala ar starptabulu.

Objektorientētā klašu diagramma

UML Class - Vehicle Hierarchy

UML Class - Vehicle hierarchy Abstract Vehicle with Car and Truck subclasses showing visibility and inheritance. «abstract» Vehicle - vin: String - year: int # mileage: double + start(): bool Car - seatCount: int - bodyStyle: enum + openSunroof() + engageCruise() Truck - payloadKg: int - axleCount: int + loadCargo(int) + tilt(bool) extends extends ▷ tukšs trīsstūris = mantošana - privāts # aizsargāts + publisks «abstract» = nevar instancēt

Kad lietot

Projektējot objektorientētu kodu - lai redzētu klases, to laukus, metodes un mantošanu vēl pirms rakstīšanas.

Saistīts standarts

OMG UML 2.5.1. Ietver arī sequence, state, activity un deployment diagrammas.

Drošības piezīme

private/protected nav drošības siena - kods tos var apiet (piem., Java reflection). Īsta drošības robeža ir atsevišķi procesi vai servisi.

Trīs slāņu datu modeļa transformācija

Conceptual → Logical → Physical (Inventory)

Three-Layer Modeling Conceptual, logical and physical models side-by-side. CONCEPTUAL Biznesa skats - bez tehnikas Warehouse Shelf Item holds Tikai entītijas. Nav datu tipu. Nav atslēgu. Biznesa valoda. → LOGICAL Strukturēts - bez konkrēta DB Item PK item_id : int sku : string(40) description : text weight_g : int ShelfPlacement PK placement_id : int FK shelf_id, item_id quantity : int Atslēgas + tipi definēti. Bez konkrēta dzinēja. Der jebkurai RDBMS. → PHYSICAL Konkrēts SQL - PostgreSQL CREATE TABLE items ( id SERIAL PRIMARY KEY, sku VARCHAR(40) UNIQUE NOT NULL, description TEXT, weight_g INT CHECK (weight_g > 0), created_at TIMESTAMPTZ DEFAULT now() ); CREATE INDEX idx_sku ON items(sku); Dzinēja-specifisks SQL. Indeksi, constraints, tipi.

Kad lietot

Lai pakāpeniski no biznesa skata nonāktu līdz gatavai datubāzes shēmai. Katrs slānis paredzēts citam lasītājam - biznesam, arhitektam, DBA.

Saistīts standarts

ANSI/SPARC three-schema architecture (1975). Mūsdienās: dbt staging→intermediate→mart slāņi seko līdzīgam principam.

Ierobežojumi

Mazos projektos konceptuālo slāni bieži izlaiž - bet tieši tas neļauj biznesa loģikai iestrēgt datubāzes shēmā.

Datu plūsmas diagramma · 1. līmenis

DFD - Restaurant Order (with trust boundary)

DFD - Restaurant ordering Level-1 DFD with trust boundary separating customer zone and kitchen. ⟪ Trust Boundary ⟫ Customer-facing zone ⟪ Trust Boundary ⟫ Back-of-house (kitchen) Customer [External] Card Network [External] 1.0 Take Order 2.0 Charge Card 3.0 Cook Meal D1: Orders (queue) order total + card authorize approval ticket External Process Data Store Trust boundary

Kad lietot

Lai redzētu, kā dati plūst starp cilvēkiem un sistēmām un kur tie glabājas. Tas ir pamats draudu modelēšanai.

Saistīts standarts

Yourdon/DeMarco notation. Mūsdienās - Microsoft Threat Modeling Tool, OWASP pytm, draw.io DFD šablons.

Drošības piezīme

Katra “uzticības robeža” ir vieta, kur jāpārbauda, kas tu esi (autentifikācija), ko drīksti (autorizācija) un vai dati ir derīgi (validācija). No tās sākas STRIDE.

Relāciju normalizācija · Unnormalized → 3NF

Normalization - Movie Rentals

Normalization - Movie rentals Unnormalized table normalized to 1NF and then 3NF. ❌ Unnormalized rental_id | renter | movies 1 | Alice | Matrix, Inception, Dune 2 | Bob | Heat, Drive 3 | Alice | Tenet ⚠ Multivalues vienā šūnā ⚠ Īrnieka vārds dublēts → 1NF 1NF - Atomiskas vērtības rental_id | movie_id | renter | movie_title 1 | M1 | Alice | Matrix 1 | M2 | Alice | Inception 1 | M3 | Alice | Dune 2 | M4 | Bob | Heat 2 | M5 | Bob | Drive ⚠ 'renter' atkarīgs tikai no rental_id (partial dep.) ↓ Sadalīt atsevišķās tabulās (2NF + 3NF) rentals PK rental_id: int FK renter_id: int rented_at: datetime ✓ Nav partial dep. renters PK renter_id: int name: varchar email: varchar ✓ Nav transitive dep. rental_items PK id: int FK rental_id, movie_id late_fee: decimal ✓ Atomisks, bez dublētiem movies PK movie_id: int title: varchar year: int ✓ Viena atbildība Katra tabula = viens skaidrs mērķis - nav dublētu datu, nav update/insert/delete anomāliju

Kad lietot

Sistēmās, kur datus bieži maina un dublēšanās rada kļūdas (OLTP). Datu noliktavās (OLAP) bieži dara pretējo - apzināti dublē ātruma dēļ.

Saistīts standarts

Codd, 1NF–6NF (1970+). Boyce-Codd Normal Form (BCNF) - stingrāka par 3NF. Praktiski apstājas pie 3NF/BCNF.

Ierobežojumi

Par daudz normalizācijas = daudz JOIN = lēnāka sistēma. Praksē sāk ar 3NF un denormalizē tikai tad, ja mērījumi to prasa.

C4 arhitektūras modelis · 2. līmenis (Container)

C4 Container - Weather Forecast Platform

C4 Container - Weather Platform Container view of synthetic weather platform with web app, API, time-series DB, external sensors. Public User [Person] «System: Weather Forecast Platform» Web Dashboard [Browser SPA] Forecast charts, station map Forecast API [REST service] Aggregations, model predictions Time-series DB [TSDB] Readings, historical forecasts Sensor Network [Field stations] «external» Satellite Imagery [Provider API] «external» uses [HTTPS] JSON/REST read/write MQTT HTTPS poll C4 Levels: Context → Container → Component → Code | ⋯ = external system outside our boundary

Kad lietot

Lai aprakstītu sistēmas arhitektūru augstā līmenī. “Container” līmenis rāda atsevišķi palaižamās daļas - servisus, datubāzes, ārējās sistēmas.

Saistīts standarts

Simon Brown, c4model.com. arc42 ietvars (sec. 5 = Building Block View) bieži lieto C4 līmeņu vietā.

Drošības piezīme

Sistēmas robeža ir pirmā vieta, kur pieraksta, kā notiek autentifikācija, kur beidzas TLS un kurā sistēmā glabājas audita žurnāli.

Threat modeling · Microsoft, 1999

STRIDE - Per-element Threat Categories

STRIDE - Threat modeling DFD elements annotated with applicable STRIDE threat categories. User [External Entity] S · R Auth Service [Process] S T R I D E creds T · I · D User Table (argon2 hash) [Data Store] T · R · I · D STRIDE kategorijas: S Spoofing - uzdošanās par citu (account takeover, sertifikātu viltošana) T Tampering - datu izmaiņa (DB ieraksts, MITM injekcija) R Repudiation - darbības noliegšana (nepilnīgs audita žurnāls) I Information disclosure - datu noplūde (TLS trūkums, error stack traces) D Denial of service - pieejamības zaudēšana E Elevation of privilege - RCE, IDOR, role bypass
DFD elements S T R I D E
External Entity (user, sistēma ārpus robežas) ✓-✓---
Process (services, lambdas, mikropakalpojums) ✓✓✓✓✓✓
Data Store (DB, faili, S3 bucket) -✓✓✓✓-
Data Flow (HTTP/TCP, queue, IPC) -✓-✓✓-

Kad lietot

Pēc DFD - iziet cauri katram elementam un pārbaudīt, kuri sešu veidu draudi (STRIDE) tam der. Katram atrastam draudam pieraksta, kā to mazināt.

Saistīts standarts

Microsoft Threat Modeling Tool, OWASP pytm. MITRE ATT&CK papildina ar reālajām taktikām. PASTA, LINDDUN - citi piegājieni.

Drošības piezīme

STRIDE neaptver biznesa loģikas kļūdas, kriptogrāfijas vājumus vai piegādes ķēdi. Tāpēc to bieži apvieno ar OWASP Top 10 un MITRE ATT&CK.