Teknisen arkkitehtuurin yleiskatsaus IT-tiimeille, jotka arvioivat AccessPointia

Last updated: August 09, 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 (v2.0.67).

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
  • Kantelut ja muutoksenhaut — kantelun 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
  • AI Assist (valinnainen) — Azure OpenAI -pohjaiset ehdotukset ja luonnostelu, jotka toimivat kokonaan asiakkaan omassa tilauksessa: asiakirjayhteenvedot, tekoälyn peittoehdotukset, faktoihin perustuva luonnostelu, vastaanottoseulonta, arvioinnin vastausten esitäyttö, semanttinen haku ja kaksoiskappaleiden tunnistus, säädöstietoinen tapauskohtainen avustaja (Kysy AccessPointilta — napsautettavat viittaukset, tallennetut keskustelut, Oma tapauskanta -tila), "Kysy AccessPointilta" -datavastaukset, lainkäyttöalueen toimintaopas, joka perustaa prosessivastaukset, automaattikäännös ja päivittäinen tiivistelmä — kaikki vuokraajakohtaisesti valittavissa, kirjattuna vain metatietoina, tietuekohtaisen tekoälyaktiviteetin ilmoituksen kera

Kaikki moduulit ovat lainkäyttöaluepakettien 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 override,          │         │  (222 tables, 3,410 fields)            │
│   optional)                  │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.ReadBasic.All  │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         │  (opt-in) Azure OpenAI                  │
        │  Calendars.Read      │         │  (opt-in) Azure Document Intelligence   │
        │  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.23.2 Asiakkaan SharePoint Online / Teams Käyttöliittymä kaikille rooleille
Teams App Teams manifest v1.19, versio lukittu yhteen SPFx-ratkaisun ja ApiVersion.Current -arvon kanssa (CI leimaa) 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 (~103 ohjainta, ~124 palvelurajapintaa) Asiakkaan Azure App Service (Linux) Liiketoimintalogiikka, tietojen käsittely, asiakirjojen käsittely
Tietokanta SQL Server (DacPac) Asiakkaan Azure SQL Database Relaatiotietovarasto (221 taulua, 3 410 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 sekä semanttinen vektorihaku (asiakirjat + tapausindeksi); provisioidaan vain, kun deployAiSearch=true
Azure OpenAI (valinnainen) Azure OpenAI Service Asiakkaan Azure-tilaus AI Assist — faktoihin perustuva luonnostelu, ehdotukset, semanttinen haku, tapausavustaja (Kysy AccessPointilta); hallitun identiteetin todennus (ei API-avaimia), provisioidaan vain, kun AI Assist on otettu käyttöön
Document Intelligence (valinnainen) Azure AI Document Intelligence (prebuilt-read) Asiakkaan Azure-tilaus OCR pelkkää kuvaa sisältäville skannauksille sisältöhakua, kaksoiskappaleiden tunnistusta, yhteenvetoja ja peittoehdotuksia varten; hallitun identiteetin todennus, provisioidaan vain, kun deployDocumentIntelligence=true

Mitä julkaisija operoi

Palvelu Tarkoitus
Realizer Platform Lisenssin validointi, Teams-ilmoitusten välityspalvelu, SPFx:n API-osoitteen tunnistus, Teamsin henkilökohtaisen välilehden älykäs reititin sekä käyttöönoton jälkeinen Viimeistele asennus -sivu (asiakkaan tapaustietoja ei välitetä)
AppSource Listing SPFx-paketin jakelu
Käyttöönottomalli Bicep/ARM-malli Azure-taustajärjestelmälle, otetaan käyttöön yhdellä napsautuksella Azure-portaalista asiakkaan tilaukseen
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 lainkäyttöaluepakettien 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, kansiot, sähköpostiperheet, lukemisen seuranta, tallennetut näkymät, päätösperusteinen kaksoiskappaleiden tunnistus, Syncfusion-esikatselu, peittämisputki poikkeuksineen ja XFDF-edestakaisine siirtoineen, etsi ja peitä -kuviot, sääntöpohjaiset ja tekoälyn peittoehdotukset, aiempien pyyntöjen peittojen uudelleenkäyttö, vastauksen paketointi kirjelomakkeen yhdistämisellä.
Pyytäjät / yhteystiedot Ensiluokkainen uudelleenkäytettävä pyytäjän identiteetti, vastaanottovirran hallinta, kevytmielinen/häiritsevä-käytöksenhallintatyötila, maksut ja vahvistus, yhdistäminen; konsultaatiot; kirjeenvaihdon laadintatyökalu henkilötietopalomuurilla.
Tietosuoja-arvioinnit Konfiguroitava PIA-/AIA-/Security-moottori: mallipohjat, seulontakyselyt, osion tehtävänanto, pisteytys/tasoitus, riskirekisteri, sulkemis-/valvontaviranomaisyhteenvedot.
Tietosuojapoikkeamat / tietoturvaloukkaukset Poikkeaman vastaanotto, rajaaminen, vahingon riskin arviointi, säädöskohtaiset ilmoitusvelvollisuussäännöt, korjaavat toimet.
Kantelut ja muutoksenhaut Kantelun 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, katalogiohjattu mukautettu raportinmuokkain (Report Studio -koontinäytöt), tilastolliset vuosiraportit, SLA-/johdon koontinäytöt, hash-ketjutettu tarkastusloki ja oikeuskelpoiset tapauksen tarkastusviennit.
AI Assist (valinnainen) Azure OpenAI -pohjaiset ehdotukset ja luonnostelu: yhteenvedot, peittoehdotukset, faktoihin perustuva luonnostelu, vastaanottoseulonta, haltijaehdotukset, arvioinnin esitäyttö ja johdonmukaisuustarkistukset, semanttinen haku ja kaksoiskappaleet, säädöstietoinen tapausavustaja — Kysy AccessPointilta (napsautettavat viittaukset, kirjeen valmistelu, tallennetut keskustelut) — sekä Oma tapauskanta- / salkkuavustaja, lainkäyttöaluepaketin alustama lainkäyttöalueen toimintaopas, Kysy AccessPointilta -raportointi, päivittäinen tiivistelmä ja kiinnikurontikooste, riskiportfolio- ja käytösanalyysi. Ominaisuuskohtaiset vuokraajakytkimet; kirjaus vain metatietoina (avustaja voi lisäksi tallentaa omistajakohtaisia yksityisiä keskusteluja).
Konfiguraatio ja alusta Lainkäyttöaluepaketin tuonti (1 Universal Baseline -paketti + 106 lainkäyttöaluepakettia, mukaan lukien tyyppikohtaiset automaattiset oletetun epäämisen tilat ja valinnainen tekoälyn perusta), 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 sekä valinnaiset AI Search-/Azure OpenAI-/Document Intelligence -resurssit) 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. Pakollinen käyttöönottotyypin valinta suojaa uudelleenkäyttöönottoja: Uusi asennus luo SQL-palvelimen Entra-ensin-periaatteella (käyttöönoton suorittavasta pääkäyttäjästä tulee ensimmäinen Entra-pääkäyttäjä, Entra-pohjainen todennus alusta asti — SQL-tunnusta ei ole koskaan olemassa), kun taas Päivitä olemassa oleva asennus säilyttää operaattorin sovellusasetukset eikä koske tietokannan käyttöoikeuksiin. 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, varmistaa uudelleen SQL:n pelkän Entra-todennuksen (varmistus — malli soveltaa sen), myöntää Microsoft Graph -oikeudet hallitulle identiteetille (skriptattu vaihtoehto julkaisijan Viimeistele asennus -sivulle), määrittää valinnaisen SharePointin tallennusentiteetin API-osoitteen ohituksen ja hyväksyy SPFx:n API-oikeuspyynnöt. Jokainen vaihe voidaan ohittaa itsenäisesti.

Graph-käyttöoikeudet myönnetään yleensä julkaisijan Viimeistele asennus -sivun kautta — käyttöönotto tuottaa finishSetupUrl-tulosteen, jonka asiakkaan Entra-pääkäyttäjä avaa myöntääkseen kaikki hallitun identiteetin tarvitsemat oikeudet yhdellä idempotentilla ajolla (suoritetaan uudelleen päivitysten jälkeen uusien oikeuksien saamiseksi).

Käyttöönotto on oletuksena tietoturvakovennettu: TLS 1.3, FTPS pois käytöstä, SCM/FTP-perustodennus pois käytöstä, HTTP/2 käytössä ja Microsoft Defender for SQL päällä oletuksena (voidaan poistaa käytöstä). 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öaluepaketin.

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. PermissionService:   │
     │                              │     resolve roles +      │
     │                              │     permission grants    │
     │                              │                          │
     │     ◄── 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ä Minkä tahansa Entra-vuokraajan myöntäjä — muodot https://login.microsoftonline.com/{tenantId}/v2.0 (v2) ja https://sts.windows.net/{tenantId}/ (v1) validoidaan; tokenin tid-vaatimus ohjaa vuokraajakohtaista rajausta
Sovellusrekisteröinti Julkaisijan operoima monivuokraaja-sovellus, hyväksytty erikseen kunkin asiakasvuokraajan toimesta (ei asiakaskohtaista sovellusrekisteröintiä hallittavaksi tai kierrätettäväksi); julkaistu laajuus access_as_user; ei asiakassalaisuutta. Asiakasvuokraajien välinen eristys pakotetaan validoidulla tid-vaatimuksella sekä lisenssi-/tilaustarkistuksella

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 (palvelin luodaan Entra-ensin-periaatteella; SQL-tunnusta ei ole koskaan olemassa)
  • Azure Blob Storage — DefaultAzureCredential (hallittu identiteetti tuotannossa)
  • Microsoft Graph API — ManagedIdentityCredential sovellusoikeuksilla
  • Valinnaiset tekoälyresurssit (AI Search, Azure OpenAI, Document Intelligence) — pelkän hallitun identiteetin todennus, paikallinen/avaintodennus pois käytöstä

Azure kierrättää hallitun identiteetin tunnistetiedot automaattisesti.

Valtuutus ja RBAC

AccessPoint toteuttaa hienojakoisen, vuokraajakohtaisesti muokattavan käyttöoikeusmallin, joka tallennetaan Azure SQL:ään ja pakotetaan API-kerroksessa jokaisessa pyynnössä: tuotteen määrittelemä luettelo atomisista käyttöoikeuskoodeista (esim. request.modify, document.view, redaction.approve, request.view.pii) ryhmitellään rooleiksi, ja jokainen ohjaintoiminto on portitettu käyttöoikeuskoodilla.

Roolityyppi Roolit Huomiot
Järjestelmärooli Administrator (ainoa sisäänrakennettu vakiorooli) Sisältää aina kaikki luettelon käyttöoikeudet — lasketaan luettelosta, ei tietokantaan alustettuna — joten sitä ei voi koskaan lukita ulos; muuttumaton eikä poistettavissa.
Suhderoolit Reviewer, Custodian, Contributor, Reader, Advisor Tuotteen määrittelemät käyttöoikeuspaketit, jotka myönnetään automaattisesti ja kohdekohtaisesti työ-/yhteistyösuhteiden perusteella (Custodian-tehtävänanto, Contributor-tehtävä, tarkistus, Advisor-/Reader-jäsenyys). Ei suoraan määritettävissä, rajattu liittyvään tietueeseen, eivätkä koskaan sisällä pyynnön esittäjän henkilötietoja.
Vuokraajaroolit esim. Request Coordinator (toimitetaan Universal Baseline -paketin mukana), sekä mahdolliset mukautetut roolit Täysin muokattavat käyttöoikeuspaketit, joita hallitaan kohdassa Asetukset > Roolit ja käyttöoikeudet. Koordinaattori-/vastaavatyyppiset roolit ovat kokonaan vuokraajakohtaisesti määritettyjä — paketin mukana toimitettava Request Coordinator on käytännössä tietopyyntö- ja tietosuojavastaavan rooli.
Rooli Näkee pyynnön esittäjän henkilötiedot Tyypillinen käyttöoikeus Tyypillinen käyttäjä
Administrator Kyllä Kaikki (kaikki luettelon käyttöoikeudet) IT-ylläpitäjä, järjestelmän omistaja
Request Coordinator (vuokraajarooli) Kyllä Hallinnoi pyyntöjä, tehtävänantoja, mustauksia, kirjeenvaihtoa Tietopyyntö- ja tietosuojavastaava
Reviewer Ei Luku + tarkistuksessa olevien pyyntöjen mustaushuomioiden merkitseminen/ratkaiseminen Oikeudellinen neuvonantaja, laadunvarmistus
Advisor Ei Luku + mustausten tarkastelu/merkitseminen (ei koskaan soveltaminen tai hyväksyminen) Konsultoiva neuvonantaja, asiantuntija
Custodian Ei Omat tehtävänannot ja niiden asiakirjat Osaston asiakirjavastaava
Contributor Ei Omat tehtävät ja niiden asiakirjat Asiantuntija
Reader Ei Vain luku -oikeus liittyviin pyyntöihin ja jaettuihin asiakirjoihin Valvonta, tarkastus

Toteutuspisteet:

  1. [RequirePermission(code)]-attribuutit — dynaaminen käytäntötarjoaja yhdistää jokaisen ohjaintoiminnon luettelon käyttöoikeuskoodiin
  2. PermissionService — ratkaisee kutsujan tosiasialliset käyttöoikeudet (vakiotyyppiset roolit yhdistettynä kohdekohtaisiin suhdemyönnytyksiin), objektikohtaisin tarkistuksin pyynnön/asiakirjan/tehtävänannon/tehtävän tasolla
  3. Resurssitason omistajuustarkistukset — esim. Contributor pääsee käsiksi vain omiin tehtäviinsä; Custodian vain omiin tehtävänantoihinsa
  4. PiiFilterMiddleware — poistaa pyynnön esittäjän henkilötietokentät JSON-vastauksista jokaiselta kutsujalta, jolla ei ole view-requestor-PII-käyttöoikeutta

Kaikki API:n kirjoituspäätepisteet pakottavat käyttöoikeudet 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). Vakiotyyppiset roolimääritykset on rajattu (globaali, pyyntö-, tehtävänanto- tai tehtävälaajuus), valinnaisesti määräaikaisia, eikä suhderooleja koskaan kirjata vakiomäärityksinä — ne johdetaan kohdekohtaisesti taustalla olevista työtietueista. Ensimmäinen järjestelmään pääsevä käyttäjä alustetaan Administrator-roolilla, ja palvelinpuolen suoja estää viimeisen aktiivisen pääkäyttäjän poistamisen.

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
API-osoitteen ohitus (valinnainen) SharePoint Tenant Storage Entity Asiakkaan M365-vuokraaja (ensisijainen tunnistus tapahtuu julkaisijan API-tunnistuspäätepisteen kautta)
Tekoälyhaun indeksit, yhteenvedot, OCR-tuloste (valinnainen) Azure AI Search / Azure SQL Asiakkaan Azure-tilaus

Mikä ylittää vuokraajan rajat

Tietovirta Suunta Mitä välitetään Tarkoitus
Lisenssin validointi API → Publisher Platform Entra-hallitun identiteetin token (tokenin tid-vaatimus tunnistaa vuokraajan), API:n versio ja API:n oma perusosoite (itserekisteröinti web-osan tunnistusta varten) Aktiivisen tilauksen validointi; vastaus sisältää myös AccessPointin uusimman julkaistun version, jotta Asennus-paneeli voi näyttää "Päivitys saatavilla" -ilmoituksen (vain versionumerot — ei käyttö- tai tapaustietoja)
API-osoitteen tunnistus SPFx → Publisher Platform Bearer-token (vain vuokraajatunnusvaatimus) Asiakkaan API:n perusosoitteen ratkaiseminen, kun tallennusentiteetin ohitusta ei ole asetettu
Sähköposti-ilmoitukset API → Microsoft Graph Sähköpostin sisältö Mail.Send-kautta Ilmoitusten lähettäminen jaetusta postilaatikosta
Teams-ilmoitukset (valinnainen — kytkettävissä / poistettavissa kokonaan) API → Publisher Platform → Microsoft Graph Aktiviteettityyppi, vastaanottajan + vuokraajan GUID-tunnukset, ilmoituksen otsikko-/esikatseluteksti, toimivan käyttäjän nimi, pyyntönumero, tietuetunnus (syvälinkki) Teams-aktiviteettisyöteilmoitusten lähettäminen (välitetään julkaisijan monivuokraajayrityssovelluksen kautta, koska sendActivityNotification-kutsun on tultava sovellukselta, joka omistaa Teams-manifestin). Tämä on ainoa ilmoituskanava, joka poistuu vuokraajasta — sähköposti ja sovelluksen sisäinen syöte toimittavat samat ilmoitukset vuokraajan sisällä. Katso Teams-ilmoitusten tietojenjako
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
  • AI Assist -kehotteet ja -vastaukset — kun AI Assist on otettu käyttöön, Azure OpenAI -resurssi toimii asiakkaan omassa tilauksessa ja alueella; Microsoft ei kouluta malleja sisällöllä, eikä kehotteiden/vastausten sisältöä tallenneta (vain käyttömetatiedot, budjettimittaria ja tapauksen tarkastusviennin tekoälyn osallisuuden ilmoitusta varten)
  • Sovelluksen sisäiset ja sähköposti-/Outlook-ilmoitukset — sovelluksen sisäinen syöte tarjotaan asiakkaan omasta API:sta; sähköposti lähetetään asiakkaan omasta jaetusta postilaatikosta Mail.Send-toiminnon kautta. Kumpikaan ei kulje julkaisijan kautta. Vain valinnainen Teams-aktiviteettisyöte lähettää mitään tietoa vuokraajan ulkopuolelle, ja sekin voidaan minimoida tai poistaa kokonaan (alla)

Teams-ilmoitusten tietojenjako (valinnainen)

Tietosuvereniteettilupauksen mukaisesti ainoa vuokraajan tieto, joka poistuu rajan yli ilmoituksia varten, on valinnainen Teams-aktiviteettihyötykuorma — ja sekin voidaan minimoida tai poistaa kokonaan. Jokainen ilmoitus toimitetaan enintään kolmella kanavalla; kaksi niistä pysyy aina vuokraajan sisällä (sovelluksen sisäinen syöte, joka tarjotaan asiakkaan API:sta, ja sähköposti/Outlook, joka lähetetään asiakkaan omasta jaetusta postilaatikosta). Teams-aktiviteettisyöte on mukavuustoiminto: oletustilassaan asiakkaan API lähettää POST-pyynnöllä pienen hyötykuorman julkaisijan monivuokraajasovellukselle, joka kutsuu Graphin sendActivityNotification-toimintoa (jonka on tultava sovellukselta, joka omistaa Teams-manifestin). Julkaisija ei tallenna mitään siitä ja kirjaa vain vastaanottajan + vuokraajan GUID-tunnukset.

Kentät oletusarvoisessa (julkaisijan välittämässä) Teams-hyötykuormassa — ja mitä Minimoi-kytkin poistaa:

Kenttä Sisältää Henkilötietoa? Poistaa Minimoi?
tenantId / recipientUserId Vuokraajan + vastaanottajan Entra-GUID-tunnukset Ei — tunnisteita Ei (reititys)
activityType Kiinteä manifestin enum-arvo (esim. assignmentCreated) Ei Ei
previewText / topicText Esikatselu + otsikko (tehtävänannon/tehtävän nimi, ilmoitusteksti) Mahdollisesti (vapaa teksti) Kyllä → paikkamerkki
actorName Toimivan henkilöstön jäsenen näyttönimi Kyllä — henkilönimi Kyllä → ”AccessPoint”
requestNumber Pyynnön viitekoodi Ei — viite Ei (konteksti)
relatedEntity + relatedRecordId Tietuetyyppi + GUID (syvälinkki) Ei — tunnisteita Ei (syvälinkki)

Pyytäjän henkilötietoja ei koskaan ole hyötykuormassa — pyytäjän nimi-/sähköpostikenttää ei ole, ja Custodian-/Contributor-ilmoitukset on joka tapauksessa tyhjennetty henkilötiedoista jo ylävirrassa. Kaksi hallintaa tiukentaa tätä edelleen:

  • Minimoi (Notifications:TeamsMinimalPayload, vuokraaja-asetus) korvaa kentät previewText, topicText ja actorName neutraaleilla paikkamerkeillä, joten nimet, otsikot ja vapaa teksti eivät koskaan poistu vuokraajasta — vain reititys-/syvälinkkitunnisteet poistuvat. Manifestin muutosta ei vaadita.
  • Poista kokonaan (Notifications:TeamsRelayMode=Direct) saa asiakkaan API:n kutsumaan Graphin sendActivityNotification-toimintoa itse omalla hallitulla identiteetillään, jolloin mikään hyötykuorma ei koskaan saavuta julkaisijaa. Tämä edellyttää TeamsActivity.Send-sovellusroolia API:n hallitulle identiteetille sekä Teams-manifestin webApplicationInfo.id-arvon osoittamista asiakkaan omaan sovellukseen — katso Käyttöönotto-opas.
Tila Hyötykuorma julkaisijalle Henkilötieto/vapaa teksti poistuu vuokraajasta Käyttöönottovaiva
Oletusvälitys Kyllä (yllä olevat kentät) Nimet/otsikot, ellei minimoitu Ei mitään
Minimointikytkin Kyllä (vain tunnisteet) Ei Yksi kytkin
Suora (itse isännöity) välitys Ei Ei MI-myöntö + manifestin muokkaus
Teams pois käytöstä Ei Ei (vain sähköposti + sovelluksen sisäinen) Ei mitään

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 miltä tahansa kutsujalta, jolla ei ole view-requestor-PII-käyttöoikeutta (Custodianeilla, Contributoreilla, Readereilla, Reviewereillä ja Advisoreilla ei koskaan ole sitä), palvelinpuolella, riippumatta siitä, mitä asiakaspää pyytää. Poistettavat kentät: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, sekä edustajan identiteetti-/yhteystietokentät ja henkilöllisyyden vahvistamiseen liittyvät muistiinpanot.

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 tuottaa oikeuskelpoinen tapauksen tarkastusvienti (aiemmin ”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

Yksi RetentionService-moottori poistaa vanhentuneet tietueet viidestä rekisteristä — pyynnöt, arvioinnit, poikkeamat, kantelut ja itsenäiset tietosuojariskit — ohjattuna tyyppikohtaisella RetentionPeriodMonths + RetentionStartPoint -parilla (NULL = säilytys toistaiseksi, oletusarvo). Tietueet, joiden ei tule vanhentua, on suljettu pois rakenteen vuoksi (Voimassa-tilassa oleva arviointi, Hyväksytty riski, tapaukseen ankkuroitu riski), ja vanhentunut tietue, josta toinen avoin tapaus on yhä riippuvainen, hylätään palvelinpuolella; kelpoisuus arvioidaan uudelleen puhdistushetkellä. Kun tietue puhdistetaan, moottori poistaa tietokantatietueiden lisäksi asiakirjablobit, muunnetut PDF:t, merkinnät ja vientipaketit Blob Storagesta. RetentionPurgeLog tallentaa, mitä poistettiin, milloin ja kenen toimesta — EntityName tunnistaa, mistä rekisteristä tietue oli peräisin, sen numeron, tyypin, sulkemispäivän ja asiakirjamäärän tilannekuvan ohella — vaatimustenmukaisuustason jäljen, joka säilyy tietojen poistamisen jälkeenkin eikä itse koskaan puhdistu.

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
→