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 apmācībām.

Entītiju un attiecību diagramma

ERD - bibliotēkas piemērs (lasītājs, izsniegums, grāmata)

ERD - bibliotēkas piemērs Lasītājs izņem nulli vai vairākus izsniegumus. Katrā izsniegumā ir viena vai vairākas grāmatas, ko glabā starptabula LOAN_ITEM ar salikto primāro atslēgu. Grāmata var būt nulle vai vairākos izsniegumos. MEMBER PK member_id full_name : varchar email : varchar joined_on : date LOAN PK loan_id FK member_id loaned_on : date returned_on : date? BOOK PK book_id isbn : varchar(13) title : varchar author : varchar LOAN_ITEM PK, FK loan_id PK, FK book_id copies : int starptabula "daudzi pret daudziem" izņem satur tiek izsniegta tieši viens nulle vai vairāki viens vai vairāki PK primārā atslēga FK ārējā atslēga ? var būt tukšs

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 klašu diagramma - transportlīdzekļu hierarhija

UML klašu diagramma - transportlīdzekļi Abstraktā klase Vehicle ar apakšklasēm Car un Truck. Abas manto Vehicle laukus un metodes, un katrai ir savi papildu lauki un metodes. «abstract» Vehicle - vin : String - year : int # mileage : double + start() : bool Car - seatCount : int - bodyStyle : BodyStyle + openSunroof() + engageCruise() Truck - payloadKg : int - axleCount : int + loadCargo(kg : int) + tilt(up : bool) mantošana: apakšklase ir virsklases veids slīpraksts un «abstract»: objektu tieši izveidot nevar -privāts #aizsargāts (arī apakšklasēm) +publisks

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

Konceptuālais → loģiskais → fiziskais modelis (noliktava)

Trīs datu modeļa slāņi Viens noliktavas piemērs trīs slāņos: konceptuālajā noliktavā ir plaukti un plauktos preces, loģiskajā tās ir tabulas ar atslēgām un starptabulu, fiziskajā - PostgreSQL komandas. Konceptuālais Biznesa skats - ko glabājam Noliktava ir Plaukts glabā Prece 1 N N M Tikai lietas un saites. Bez datu tipiem un atslēgām. Saprot arī bizness. Loģiskais Tabulas un atslēgas - jebkurai RDBMS Shelf PK shelf_id : int FK warehouse_id : int code : string(10) Item PK item_id : int sku : string(40) weight_g : int ShelfItem PK shelf_id, item_id FK shelf_id FK item_id quantity : int "Daudzi pret daudziem" - starptabula. Fiziskais PostgreSQL - konkrēts dzinējs CREATE TABLE item ( item_id serial PRIMARY KEY, sku varchar(40) NOT NULL UNIQUE, weight_g int CHECK (weight_g > 0) ); CREATE INDEX idx_item_sku ON item (sku); Tipi, ierobežojumi un indeksi konkrētajam dzinējam. Shelf un ShelfItem - tāpat, ar FOREIGN KEY.

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 - restorāna pasūtījums ar uzticamības robežām

DFD - restorāna pasūtījums Klients izvēlas ēdienu, pasūtījuma process aprēķina summu un nodod to maksājumam, kas jautā karšu tīklam atļauju. Apstiprināts pasūtījums nonāk krātuvē, un no tās čeks pāriet virtuves zonā gatavošanai. Divas uzticamības robežas: pasūtījumu sistēma un virtuve. Uzticamības robeža: pasūtījumu sistēma Uzticamības robeža: virtuve Klients ārēja puse Karšu tīkls ārēja puse 1.0 Pasūtījums 2.0 Maksājums 3.0 Gatavošana D1 pasūtījumi izvēle summa maksājuma pieprasījums apstiprinājums apmaksāts pasūtījums čeks virtuvei ārēja puse process datu krātuve datu plūsma uzticamības robeža

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 “uzticamī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 - no nenormalizētas līdz 3NF

Normalizācija - filmu noma

UNF Nenormalizēta tabula

Viena nomas tabula, kā to varētu pierakstīt kladē.

rental_idrenterphonemovies
1Alice2000 1111Matrix, Inception
2Bob2000 2222Heat
3Alice2000 1111Tenet

Problēma: vienā šūnā ir vairākas filmas, tāpēc nevar atrast vai saskaitīt vienu filmu.

1NF Katrā šūnā viena vērtība

Katra filma savā rindā. Atslēga tagad ir divas kolonnas kopā: rental_id + movie_id.

rental_idmovie_idrenterphonetitle
1M1Alice2000 1111Matrix
1M2Alice2000 1111Inception
2M3Bob2000 2222Heat
3M4Alice2000 1111Tenet

Problēma: renter un phone atkarīgi tikai no rental_id, bet title - tikai no movie_id, t.i. no daļas atslēgas. Tāpēc Alises dati atkārtojas katrā viņas filmas rindā (daļēja atkarība).

2NF Nekas nav atkarīgs no daļas atslēgas

Katru faktu pārceļ uz tabulu, kuras atslēgai tas tiešām pieder.

rentals
rental_idrenterphone
1Alice2000 1111
2Bob2000 2222
3Alice2000 1111
rental_movies
rental_idmovie_id
1M1
1M2
2M3
3M4
movies
movie_idtitle
M1Matrix
M2Inception
M3Heat
M4Tenet

Problēma: rentals tabulā phone ir atkarīgs no renter, nevis no rental_id: rental_id → renter → phone. Ja Alise nomaina tālruni, tas jālabo katrā viņas nomā (tranzitīva atkarība).

3NF Nekas nav atkarīgs no citas neatslēgas kolonnas

Īrnieks kļūst par savu tabulu, un noma uz to atsaucas ar ārējo atslēgu.

renters
renter_idnamephone
R1Alice2000 1111
R2Bob2000 2222
rentals
rental_idrenter_id
1R1
2R2
3R1
rental_movies + movies
…
kā 2NF solī

Rezultāts: katrs fakts glabājas vienā vietā. Tālruņa maiņa ir viena rinda, un nav ievietošanas, labošanas un dzēšanas anomāliju.

Īss likums: katra kolonna ir atkarīga no atslēgas (1NF), no visas atslēgas (2NF) un ne no kā cita kā atslēgas (3NF).

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

1NF, 2NF un 3NF - Codd (1970-1971), BCNF - Boyce un Codd (1974), 4NF un 5NF - Fagin. Praksē parasti apstājas pie 3NF vai 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 konteineru līmenis - laikapstākļu prognožu platforma

C4 konteineru līmenis - laikapstākļu platforma Lietotājs atver tīmekļa paneli, kas izsauc prognožu API. API lasa un raksta laikrindu datubāzē, saņem mērījumus no ārēja sensoru tīkla un pats pieprasa attēlus no ārēja satelītattēlu piegādātāja. Ārējās sistēmas atrodas ārpus sistēmas robežas. Lietotājs [persona] Sistēma: laikapstākļu prognozes Tīmekļa panelis [pārlūka lietotne] prognožu grafiki, staciju karte Prognožu API [REST serviss] apkopo datus, aprēķina prognozes Laikrindu DB [TSDB] mērījumi, vēsturiskās prognozes Sensoru tīkls [ārēja sistēma] lauka stacijas Satelītattēli [ārēja sistēma] piegādātāja API lieto [HTTPS] JSON [HTTPS] lasa un raksta sūta mērījumus [MQTT] pieprasa attēlus [HTTPS] sistēmas robeža ārēja sistēma C4 līmeņi: konteksts → konteineri → komponentes → kods

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.

Draudu modelēšana - Microsoft (1999)

STRIDE - draudi pa DFD elementiem

STRIDE - draudu modelēšana DFD elementi ar tiem piemērojamām STRIDE draudu kategorijām. Lietotājs [ārēja entītija] S, R Auth serviss [process] S T R I D E pieteikšanās dati T, I, D User Table (argon2 hash) [datu krātuve] T, R, I, D vaicājums T, 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) -✓-✓✓-

Četri jautājumi - draudu modelēšanas ietvars

JautājumsRezultātsRīks šajā ceļvedī
Ko mēs veidojam?Sistēmas modelis ar uzticamības robežāmDFD, C4
Kas var noiet greizi?Draudu saraksts katram elementamSTRIDE
Ko mēs ar to darīsim?Pasākums, atbildīgais un termiņš katram draudammazināt, pieņemt, novērst, pārnest
Vai paveicām labi?Pārbaude, ka pasākumi ieviesti un modelis atbilst sistēmaitesti, pārskats pēc izmaiņām

Shostack A. (2014) Threat Modeling, Threat Modeling Manifesto (2020). Modelis nav vienreizējs dokuments - to atjauno, kad mainās arhitektūra.

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 - citas pieejas.

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.

Saīsinājumi

Ceļvedī lietotie saīsinājumi: oriģinālais nosaukums un ko tas nozīmē.

ERD
Entity-Relationship Diagram - entītiju un to saistību diagramma.
UML
Unified Modeling Language - modelēšanas valoda programmatūras diagrammām.
DFD
Data Flow Diagram - datu plūsmas diagramma.
PK / FK
Primary Key / Foreign Key - primārā atslēga / ārējā atslēga, kas norāda uz citu tabulu.
1NF / 2NF / 3NF / BCNF
Normal Forms - normālformas - pakāpes, kā tabulas atbrīvo no dublētiem datiem.
OLTP / OLAP
Online Transaction / Analytical Processing - ikdienas darījumu sistēmas / analītikas sistēmas.
DBA
Database Administrator - datubāzu administrators.
RDBMS
Relational Database Management System - relāciju datubāzu sistēma (PostgreSQL, MySQL).
C4
Context, Containers, Components, Code - arhitektūras diagrammu modelis četros līmeņos.
STRIDE
Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege - sešas draudu klases.
PASTA / LINDDUN
Citas draudu modelēšanas metodes; LINDDUN - privātuma draudiem.
IDOR
Insecure Direct Object Reference - piekļuve svešam ierakstam, nomainot identifikatoru.
MITM
Man-in-the-Middle - uzbrucējs starp abām pusēm, kas lasa vai maina datus.
RCE
Remote Code Execution - uzbrucējs var palaist savu kodu serverī.
ANSI/SPARC
Trīs shēmu (ārējā, konceptuālā, iekšējā) datubāzu arhitektūra (1975).
TSDB
Time-Series Database - laikrindu datubāze (sensoru mērījumi).
MQTT
Viegls ziņojumu protokols IoT ierīcēm.