Teknisen arkkitehtuurin yleiskatsaus IT-tiimeille, jotka arvioivat AccessPointia

Last updated: July 12, 2026 by Steve

Tekninen arkkitehtuuri

Tämä asiakirja tarjoaa teknisen yleiskatsauksen AccessPoint-alustasta ratkaisuarkkitehdeille, kyberturvallisuusinsinööreille ja IT-johtajille, jotka arvioivat tuotetta organisaatiolleen. Se pohjautuu AccessPoint Solution Architecture Guideen (v1.4.1).

Alustan yleiskatsaus

AccessPoint on Microsoft 365:n ja Azuren päälle rakennettu tietopyyntöjen ja tietosuojan hallinta-alusta. Se sai alkunsa rekisteröidyn tietopyyntöjen (subject access request, SAR) hallintatyökaluna ja on kasvanut integroiduksi ATIP-/tietosuojatoimiston kokonaisuudeksi, joka kattaa koko pyynnön elinkaaren sekä ympäröivän tietosuojaohjelman. Se toimii kokonaan organisaatiosi omassa Microsoft 365- ja Azure-vuokraajassa: ajonaikana ei ole ulkoisia palvelimia, tietokantoja eikä kolmannen osapuolen pilvipalveluriippuvuuksia, ja kaikki tiedot pysyvät ympäristössäsi sinun hallinnassasi.

Alusta on jäsennelty moduuleiksi, jotka jakavat yhteisen identiteetin, RBAC:n, ilmoitusjärjestelmän, tarkastuksen ja raportoinnin selkärangan:

  • Tietopyynnöt — ATI-/FOIA-/GDPR-vastaanotto, haltijan tehtävänjako, asiakirjojen tarkastus ja peittäminen, vastauksen paketointi sekä lakisääteinen raportointi
  • Tietosuoja-arvioinnit — konfiguroitava PIA-/AIA-/Security-arviointimoottori
  • Tietosuojapoikkeamat ja tietoturvaloukkaukset — vastaanotto, rajaaminen, vahingon riskin arviointi ja ilmoitusvelvollisuuden työnkulut
  • Valitukset ja muutoksenhaut — valituksen elinkaari osapuolineen, lakisääteisine määräaikoineen ja tutkintoineen
  • Tietosuojan riskirekisteri — ISO 31000 -tyyliset riskit, käsittelysuunnitelmat ja keskeiset riski-indikaattorit
  • Käsittelytoimien selosteet (ROPA) — GDPR Article 30 -tietueet ja rekisterin vienti
  • Sitoumusrekisteri — seurattavat tietosuojasitoumukset aikatauluineen ja tarkistuspisteineen

Kaikki moduulit ovat konfigurointipakettien ohjaamia, eikä staattista alkudataa käytetä.

Keskeiset ominaisuudet:

  • Vuokraajanatiivi — otetaan käyttöön SharePoint Framework (SPFx) -ratkaisuna ja Azure PaaS -palveluina olemassa olevassa vuokraajassasi
  • Ei Power Platform -riippuvuuksia — Dataverse-, Power Automate- tai Power Apps -lisensointia ei tarvita
  • Tietojen suvereniteetti — kaikki tiedot sijaitsevat Azure-vuokraajasi määritetyssä maantieteellisessä sijainnissa
  • Ei toimittajan ajonaikaista pääsyä — julkaisija ei voi käyttää tietojasi normaalin toiminnan aikana
  • Kiinteähintainen lisensointi — osastokohtainen lisensointi ilman käyttäjäkohtaista mittausta
  • Sisäänrakennettu tietosuoja — haltija- ja avustajaroolit on rakenteellisesti eristetty pyytäjän ja rekisteröidyn henkilötiedoista
  • Määritys koodin sijaan — pyyntötyypit, poikkeuskoodit ja valintakentät ovat datapohjaisia
  • Monikielisyys suunnitteluperiaatteena — kolmitasoinen käännösjärjestelmä, joka tukee 11 kieltä

Arkkitehtuurikaavio

Customer's Microsoft 365 Tenant          Customer's Azure Subscription
┌──────────────────────────────┐         ┌─────────────────────────────────────────┐
│                              │         │                                         │
│  SPFx Web Part               │         │  Azure App Service (Linux)              │
│  (SharePoint Online /        │──HTTPS──│  ASP.NET Core 10 Web API               │
│   Teams Personal App /       │  (JWT)  │    ├─ Entra ID JWT validation          │
│   Teams Tab)                 │         │    ├─ Role-based authorization          │
│                              │         │    ├─ PII filter middleware             │
│  Installed from AppSource    │         │    ├─ User upsert from JWT claims      │
│  or Tenant App Catalog       │         │    ├─ License validation middleware    │
│                              │         │    └─ Syncfusion document conversion   │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL + Client ID)       │         │  (~186 tables, ~2,900 fields)          │
│                              │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.Read.All       │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         └─────────────────────────────────────────┘
        │  Calendars.Read      │
        │  AiEnterprise…Read   │  ← M365 record capture (delegated + app-only Copilot)
        └──────────────────────┘

Komponentti-inventaario

Komponentti Teknologia Otettu käyttöön Tarkoitus
SPFx Web Part TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 Asiakkaan SharePoint Online / Teams Käyttöliittymä kaikille rooleille
Teams App Teams manifest v1.19, sovellusversio 1.0.0 Asiakkaan Teams-hallintakeskus Henkilökohtainen sovellus, määritettävä välilehti, aktiviteettisyötteen ilmoitukset syvälinkityksellä
Web API C# / ASP.NET Core 10, .NET 10 (~87 ohjainta, ~88 palvelua) Asiakkaan Azure App Service (Linux) Liiketoimintalogiikka, tietojen käsittely, asiakirjojen käsittely
Tietokanta SQL Server (DacPac) Asiakkaan Azure SQL Database Relaatiotietovarasto (~186 taulua, ~2 900 kenttää)
Blob Storage Azure Blob Storage Asiakkaan Azure Storage Account Asiakirjatiedostojen tallennus
Valvonta Application Insights + Log Analytics Asiakkaan Azure-tilaus Telemetria, diagnostiikka, hälytykset
AI Search (valinnainen) Azure AI Search Asiakkaan Azure-tilaus Asiakirjasisällön kokotekstihaku; provisioidaan vain, kun deployAiSearch=true

Mitä julkaisija operoi

Palvelu Tarkoitus
Realizer Platform Lisenssiavainten myöntäminen ja validointi (asiakastietoja ei välitetä)
AppSource Listing SPFx-paketin jakelu
Azure Marketplace Listing Azure-infrastruktuurin käyttöönottomalli
Teams App Package Teams-manifestin jakelu (sivulataus tai organisaation sovelluskauppa)

Asiakastietoja ei välitetä eikä tallenneta mihinkään julkaisijan operoimaan palveluun.

Toiminnalliset moduulit

Kaikki moduulit toimivat yhden Web API:n / SPFx-web-osan sisällä ja jakavat yhteisen identiteetin, RBAC:n, kommentoinnin, ilmoitusjärjestelmän, Oma päivä -näkymän, tarkastuksen, tuntikirjauksen ja tarkastustyönkulun sekä raportoinnin selkärangan. Kukin on datapohjainen konfigurointipakettien kautta.

Moduuli Yhteenveto
Pyynnöt (ATIP/SAR) Pyynnön vastaanotto → haltijan tehtävänjako → keräys → vastaus. Konfiguroitavat tyypit, tilat, numerointi, kalenterit ja SLA:t.
Asiakirjat ja peittäminen Fasettipohjainen asiakirjatyötila: tunnisteet, sähköpostiperheet, lukemisen seuranta, tallennetut näkymät, Syncfusion-esikatselu, peittämisputki poikkeuksineen ja XFDF-edestakaisine siirtoineen, vastauksen paketointi.
Pyytäjät / yhteystiedot Ensiluokkainen uudelleenkäytettävä pyytäjän identiteetti, vastaanottovirran hallinta, maksut ja vahvistus, yhdistäminen; konsultaatiot; kirjeenvaihdon laadintatyökalu henkilötietopalomuurilla.
Tietosuoja-arvioinnit Konfiguroitava PIA-/AIA-/Security-moottori: mallipohjat, seulontakyselyt, osioiden delegointi, pisteytys/tasoitus, riskirekisteri, sulkemis-/valvontaviranomaisyhteenvedot.
Tietosuojapoikkeamat / tietoturvaloukkaukset Poikkeaman vastaanotto, rajaaminen, vahingon riskin arviointi, säädöskohtaiset ilmoitusvelvollisuussäännöt, korjaavat toimet.
Valitukset ja muutoksenhaut Valituksen elinkaari: osapuolet, lakisääteiset määräajat, tutkittavaksi ottaminen, tutkinta, näkemysten tarkastelu.
Riskit ja sitoumukset ISO 31000 -riskirekisteri riskinottohalukkuudella, KRI:llä ja käsittelytehtävillä; sitoumusrekisteri aikatauluineen ja tarkistuspisteineen.
ROPA / tietosuojan kohteet Uudelleenkäytettävät ohjelmat/järjestelmät GDPR Article 30 -tietueineen ja rekisterin vienti.
Tarkastukset Konfiguroitava peräkkäinen/rinnakkainen tarkastus- ja hyväksyntämoottori, jota käytetään uudelleen kaikissa tapausentiteeteissä.
Raportointi ja tarkastus Kiinteät raportit, mukautettava raporttien laadintatyökalu, tilastolliset vuosiraportit, SLA-/johdon koontinäytöt, hash-ketjutettu tarkastusloki ja oikeuskelpoiset todistepaketit.
Konfiguraatio ja alusta Konfigurointipaketin tuonti, vuokraaja-asetukset, mukautetut roolit/oikeudet, ominaisuuskytkimet, mukautetut kentät, 11 kielen käännöstaulut.

Käyttöönottomalli

AccessPoint käyttää jaettua käyttöönottomallia. SPFx-web-osa asennetaan Microsoft AppSourcesta (tai vuokraajan App Catalogista), Teams-sovelluspaketti asennetaan sivulatauksena tai organisaation sovelluskaupan kautta, ja Azure-taustajärjestelmä otetaan käyttöön asiakkaan omaan tilaukseen jommallakummalla seuraavista menetelmistä:

  • Azure-portaali (suositeltu) — kaikkien Azure-resurssien (App Service, SQL, Blob Storage, Application Insights) käyttöönotto yhdellä napsautuksella ARM:n/Bicepin kautta. API otetaan käyttöön zipdeploy-toiminnolla ARM-käyttöönoton aikana; koodi ladataan kerran julkaisijan CDN:stä ja tallennetaan asiakkaan App Serviceen ilman ajonaikaista ulkoista riippuvuutta. Asiakas säilyttää resurssiryhmän täyden omistajuuden.
  • Bicep-malli + PowerShell-skripti (manuaalinen) — organisaatioille, joilla on tiukka muutoksenhallinta. Deploy to Azure -painike tai Deploy-AccessPoint.ps1 ottaa käyttöön infrastruktuurin, määrittää SQL:n pelkän Entra-todennuksen, myöntää Microsoft Graph -oikeudet hallitulle identiteetille, määrittää SharePointin vuokraajan tallennusentiteetit ja hyväksyy SPFx:n API-oikeuspyynnöt. Jokainen vaihe voidaan ohittaa itsenäisesti.

Käyttöönotto on oletuksena tietoturvakovennettu: TLS 1.3, FTPS pois käytöstä, SCM/FTP-perustodennus pois käytöstä ja HTTP/2 käytössä. API sisältää oman tietokannan DacPac-paketin ja soveltaa sen käynnistyksen yhteydessä migraatiopalvelun kautta käyttäen DacServices.Deploy(upgradeExisting: true) -komentoa — tämä ei tee mitään jo ajantasaisessa skeemassa ja tuottaa additiivisen, ei-destruktiivisen deltan skeeman muutoksen jälkeen (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). Migraation lopputulos näkyy /api/health-päätepisteen kautta. Käyttöönoton jälkeen pääkäyttäjä myöntää suostumuksen Realizer-yrityssovellukselle (Teams-ilmoitukset), määrittää lähettäjän postilaatikon ja tuo lainkäyttöaluekohtaisen konfigurointipaketin.

Todennus ja identiteetti

AccessPoint käyttää Microsoft Entra ID:tä ainoana identiteetin tarjoajana. Sovelluskohtaisia käyttäjätilejä tai salasanoja ei ole. SPFx-web-osa hankkii JWT-tokenin API-yleisölle AadHttpClient-luokan kautta; API validoi myöntäjän, yleisön, allekirjoituksen ja voimassaolon jokaisessa pyynnössä. Vuokraajassa määritetyt MFA- ja Conditional Access -käytännöt ovat täysimääräisesti voimassa.

User (Browser)                SharePoint Online           AccessPoint API
     │                              │                          │
     │  1. Load SPFx web part       │                          │
     │─────────────────────────────►│                          │
     │                              │                          │
     │  2. AadHttpClient.getClient()│                          │
     │  (SPFx acquires token for    │                          │
     │   api://<client-id> audience)│                          │
     │                              │                          │
     │  3. API call + Bearer token  │                          │
     │──────────────────────────────┼─────────────────────────►│
     │                              │                          │
     │                              │  4. Validate JWT:        │
     │                              │     - Issuer (Entra ID)  │
     │                              │     - Audience (api://)  │
     │                              │     - Signature          │
     │                              │     - Expiry             │
     │                              │                          │
     │                              │  5. UserUpsertMiddleware: │
     │                              │     Extract claims →     │
     │                              │     Upsert Users table   │
     │                              │                          │
     │                              │  6. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│
Parametri Arvo
Identiteetin tarjoaja Microsoft Entra ID (Azure AD)
Protokolla OAuth 2.0 / OpenID Connect
Tokenin tyyppi JWT Bearer
Yleisö api://<client-id> ja <client-id> (sekä v1- että v2-tokenit hyväksytään)
Myöntäjä https://login.microsoftonline.com/{tenantId}/v2.0 ja https://sts.windows.net/{tenantId}/
Sovellusrekisteröinti Yksivuokraajainen (AzureADMyOrg); julkaistu laajuus access_as_user; ei asiakassalaisuutta

Hallittu identiteetti

App Service käyttää järjestelmälle määritettyä hallittua identiteettiä todentautuakseen taustajärjestelmän palveluihin, joten sovellukseen ei tallenneta asiakassalaisuuksia tai varmenteita:

  • Azure SQL Database — pelkkä Entra-todennus (SQL-salasanatodennus on poistettu käytöstä)
  • Azure Blob Storage — DefaultAzureCredential (hallittu identiteetti tuotannossa)
  • Microsoft Graph API — ManagedIdentityCredential sovellusoikeuksilla

Azure kierrättää hallitun identiteetin tunnistetiedot automaattisesti.

Valtuutus ja RBAC

AccessPoint toteuttaa sovellustason roolipohjaisen pääsynhallinnan, joka on tallennettu Azure SQL:ään ja pakotettu API-kerroksessa jokaisessa pyynnössä.

Rooli Näkee pyytäjän henkilötiedot Hallinnoi pyyntöjä Hallinnoi tehtävänantoja Lähettää asiakirjoja Tyypillinen käyttäjä
Pääkäyttäjä (Administrator) Kyllä Vain määritys Ei Ei IT-ylläpitäjä, järjestelmän omistaja
SAO Kyllä Kyllä Kyllä Ei Tietopyyntö- ja tietosuojavastaava
Tarkastaja (Reviewer) Kyllä Vain luku Vain luku Ei Oikeudellinen neuvonantaja, laadunvarmistus
Haltija (Custodian) Ei Ei Omat tehtävänannot Ei Osaston asiakirjavastaava
Avustaja (Contributor) Ei Ei Ei Omat tehtävät Asiantuntija
Lukija (Reader) Ei Vain luku Vain luku Ei Valvonta, tarkastus

Toteutuspisteet:

  1. API:n valtuutuskäytännöt — ASP.NET Coren [Authorize(Policy = "...")] -attribuutit jokaisessa ohjaintoiminnossa
  2. RoleAuthorizationHandler — tarkistaa UserRoles-taulusta todennetun käyttäjän roolijäsenyyden
  3. ResourceOwnerAuthorizationHandler — validoi resurssitason omistajuuden (esim. avustaja voi käyttää vain omia tehtäviään)
  4. PiiFilterMiddleware — poistaa pyytäjän henkilötietokentät JSON-vastauksista rajoitetuilta rooleilta (haltija, avustaja, lukija)

Kaikki API:n kirjoituspäätepisteet pakottavat roolit palvelinpuolella ohjaintasolla. Asiakirjan uudelleenluokittelu on laajuustietoinen — käyttäjä, joka keräsi asiakirjan, on ainoa, joka voi luokitella sen uudelleen — ja kun pyyntö on suljettu, sen objektikaavion muutokset palauttavat HTTP 409:n, lukuun ottamatta pientä joukkoa tarkoituksellisia poikkeuksia (sulkemisen jälkeinen kirjeenvaihto, säilytyksen puhdistus ja uudelleenavaus). Roolit ovat laajuudeltaan rajattavissa tiettyihin resursseihin (globaali, pyyntö-, tehtävänanto- tai tehtävälaajuus). Ensimmäinen järjestelmään pääsevä käyttäjä alustetaan sekä Pääkäyttäjä- että SAO-roolilla.

Tietojen sijainti ja suvereniteetti

Kaikki tiedot sijaitsevat asiakkaan Azure-vuokraajassa käyttöönoton aikana valitulla alueella. Tietoja ei välitetä eikä tallenneta muille alueille, ellei asiakas nimenomaisesti määritä Azuren georeplikointia.

Kanadan liittovaltion ministeriöt: GC-kohtaisia tietojen sijaintivaatimuksia, ITSG-33-kontrollikartoitusta ja GC Cloud Guardrails -vaatimustenmukaisuutta varten katso GC-turvallisuuskontrolliviite.

Asiakastietojen sijainnit

Tietotyyppi Tallennussijainti Hallitsee
Pyyntötietueet, käyttäjätiedot, tarkastusketju Azure SQL Database Asiakkaan Azure-tilaus
Ladatut asiakirjat Azure Blob Storage Asiakkaan Azure-tilaus
Sovelluksen telemetria Application Insights / Log Analytics Asiakkaan Azure-tilaus
SPFx-web-osan resurssit SharePoint CDN Asiakkaan M365-vuokraaja
Vuokraajan määritys (API URL, Client ID) SharePoint Tenant Storage Entities Asiakkaan M365-vuokraaja

Mikä ylittää vuokraajan rajat

Tietovirta Suunta Mitä välitetään Tarkoitus
Lisenssin validointi API → Publisher Platform Lisenssiavain (opaakki merkkijono), vuokraajatunnus Aktiivisen tilauksen validointi
Sähköposti-ilmoitukset API → Microsoft Graph Sähköpostin sisältö Mail.Send-kautta Ilmoitusten lähettäminen jaetusta postilaatikosta
Teams-ilmoitukset API → Publisher Platform → Microsoft Graph Aktiviteettityyppi, esikatseluteksti, vastaanottajan tunnus, malliparametrit Teams-aktiviteettisyöteilmoitusten lähettäminen (välitetään julkaisijan monivuokraajayrityssovelluksen kautta, koska sendActivityNotification-kutsun on tultava sovellukselta, joka omistaa Teams-manifestin)
Käyttäjäprofiilin haku SPFx → Microsoft Graph Käyttäjähakukyselyt Henkilövalitsin, käyttäjien ratkaiseminen

Mikä ei koskaan poistu vuokraajasta

  • Pyyntötietueet ja pyytäjän henkilötiedot
  • Ladatut asiakirjat
  • Tarkastushistoria
  • Määritystiedot (pyyntötyypit, mallipohjat, numerointi)
  • Roolimääritykset

Salaus

Siirron aikana

Yhteys Protokolla Minimi-TLS
Selain → App Service HTTPS (pakotettu, httpsOnly: true) TLS 1.3
SPFx → App Service HTTPS (pakotettu SharePoint-kontekstin toimesta) TLS 1.3
App Service → Azure SQL TDS salauksella (Encrypt=True) TLS 1.2+
App Service → Blob Storage HTTPS (hallittu identiteetti) TLS 1.2+
App Service → Microsoft Graph HTTPS TLS 1.2+

App Service pakottaa TLS 1.3:n vähimmäisvaatimuksena etuovella (TLS 1.0/1.1/1.2 hylätään); lähtevät yhteydet Azuren taustajärjestelmän palveluihin neuvottelevat TLS 1.2:n tai uudemman.

Levossa

Tietovarasto Salaus Avainten hallinta
Azure SQL Database Transparent Data Encryption (TDE) Microsoftin hallinnoimat avaimet (oletus) tai asiakkaan hallinnoimat avaimet (CMK)
Azure Blob Storage Storage Service Encryption (SSE), AES-256 Microsoftin hallinnoimat avaimet (oletus) tai asiakkaan hallinnoimat avaimet (CMK)
Application Insights Alustan salaus Microsoftin hallinnoimat avaimet

Sovellustaso

Ominaisuus Mekanismi
Asiakirjankatselimen tokenit ASP.NET Core Data Protection (WOPI-tyylinen token, 15 minuutin TTL, vuokraajan ristiintarkistus jokaisella anonyymillä katselukutsulla)
Vahvistuksen sähköiset allekirjoitukset Allekirjoittajan ja aikaleiman SHA-256-tiiviste tallennettuna tarkastuskenttiin

Sisäänrakennettu tietosuoja

AccessPoint toteuttaa rakenteellisia tietosuojakontrolleja, jotka pakotetaan API-kerroksessa, ei vain käyttöliittymässä.

Henkilötietosuodattimen väliohjelmisto

Vastaustason väliohjelmisto sieppaa kaikki JSON-vastaukset ja poistaa henkilötietokentät käyttäjiltä, joilla on rajoitettu rooli (haltija, avustaja, lukija), palvelinpuolella, riippumatta siitä, mitä asiakaspää pyytää. Poistettavat kentät: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

Ilmoitusten henkilötietojen piilotus

Kun ilmoituksia lähetetään haltijoille tai avustajille, pyytäjän henkilötiedot korvataan paikkamerkkitekstillä itse ilmoituksen sisällössä — vaikka ilmoitusmalli sisältäisi henkilötietojen yhdistämiskenttiä.

Haltijan/avustajan eristys

  • Haltijat näkevät vain heille osoitetut pyynnöt ja työskentelevät puhdistettujen ohjeiden pohjalta
  • Avustajat näkevät vain heille osoitetut tehtävät
  • Kumpikaan rooli ei voi hakea, selata tai käyttää pyyntöjä oman laajuutensa ulkopuolelta

Lokitus, valvonta ja tarkastus

Application Insights

Kaikki API:n telemetria lähetetään asiakkaan Application Insights -instanssiin:

Signaali Mitä tallennetaan
Pyyntöjäljet HTTP-metodi, polku, tilakoodi, kesto, korrelaatiotunnus
Riippuvuusseuranta SQL-kyselyt, Blob-operaatiot, Graph API -kutsut (kesto, onnistuminen/epäonnistuminen)
Poikkeukset Käsittelemättömät poikkeukset pinojäljityksineen
Mukautetut mittarit Pyyntöjen käsittelyajat, asiakirjojen muunnosajat

Tarkastusketju

AccessPoint ylläpitää kattavaa tarkastusketjua AuditHistory-taulussa (Azure SQL), johon kirjataan entiteettityyppi, entiteettitunnus, toiminto (Create, Update, Delete, StatusChange), kentän nimi, vanha/uusi arvo, valinnainen muutoksen syy (tallennetaan tilasiirtymissä kuten sulkeminen ja uudelleenavaus), todennettu käyttäjä sekä UTC-aikaleima. Tarkastustietueet ovat muuttumattomia — niitä ei voi muokata tai poistaa API:n kautta.

Hash-ketjutettu tarkastusloki

Kenttätason tarkastusketjun lisäksi peukaloinnin paljastava, vain lisäävä AuditLedger (SHA-256-hash-ketju) tallentaa toiminnot kaikissa moduuleissa. Eheys voidaan tarkistaa palvelinpuolella, ja pyyntöä varten voidaan viedä oikeuskelpoinen todistepaketti.

Optimistinen samanaikaisuus

Korkean kilpailun entiteeteillä (Requests, Documents, CustodianAssignments) on kullakin SQL Serverin ROWVERSION-samanaikaisuustoken. Asiakaspää palauttaa rivin version päivityksen yhteydessä; jos toinen kirjoittaja on muuttanut riviä sillä välin, tallennus hylätään HTTP 409 -virheellä ("Concurrent edit detected" eli samanaikainen muokkaus havaittu) sen sijaan, että se ylikirjoitettaisiin hiljaisesti.

Säilytyksen puhdistusloki

Kun tietueita puhdistetaan säilytyskäytännön mukaisesti, puhdistus poistaa tietokantatietueiden lisäksi asiakirjablobit, muunnetut PDF:t, merkinnät ja vientipaketit Blob Storagesta. RetentionPurgeLog-taulu tallentaa, mitä poistettiin, milloin ja kenen toimesta — vaatimustenmukaisuustason jäljen, joka säilyy tietojen poistamisen jälkeenkin.

Log Analytics ja hälytykset

Application Insightsin taustalla on Log Analytics -työtila, jonka säilytysaika on määritettävissä (oletus 90 päivää; määritettävissä 30–730 päivää). Tiedot voidaan viedä Microsoft Sentineliin tai olemassa olevaan SIEM-järjestelmään. Bicep-käyttöönotto sisältää kaksi oletusmittarihälytystä App Servicelle:

Hälytys Vakavuus Ehto Aikaikkuna
Palvelinvirheet 2 (Varoitus) HTTP 5xx -määrä > 5 5 minuuttia
Korkea latenssi 3 (Tiedoksi) Keskimääräinen vasteaika > 5 sekuntia 15 minuuttia

Asiakkaat voivat mukauttaa kynnysarvoja ja lisätä toimintaryhmiä (sähköposti, SMS, webhook) Azure-portaalissa.

←
Previous AccessPointin käytön aloittaminen
Next GC-turvallisuuskontrolliviite
→