Suojaa, säilytä ja todista

🌐 Saatavilla myös 28 kielellä

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Español (México) · Français (Canada) · Deutsch (Schweiz)

Kuva on luotu tekoälyllä

Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Moduuli 6/6 luvussa Tietojen laatu ja hallinta, Data Architect -kurssin luku 5. Jokainen moduuli on itsenäinen. Edellinen: Suostumus ja oikeus tulla unohdetuksi · Seuraava: seuraava luku, Perustiedot ja identiteetti

Kysymys, johon tämä moduuli vastaa: Miten suojaat tiedot, säilytät ne niin kauan kuin vaaditaan ja todistat sen?

Olemme asettaneet omistajat ja käytännöt, pitäneet huonot tiedot ulkona, kirjoittaneet sanaston, jäljittäneet alkuperän, luokitelleet sen, millä on väliä, opetelleet lait ja mallintaneet suostumuksen. Nyt meidän on pyöritettävä sitä. Tietoja saapuu, niitä käytetään, kopioidaan ja muutetaan, ne vanhenevat, ja lopulta osan niistä on lähdettävä. Ja jonain päivänä joku pyytää: todista, mitä tapahtui.

Hallinta seuraa tietoja

En ajattele tietojen hallintaa yhtenä ominaisuutena. Ajattelen sitä, mitä tiedoille tapahtuu siitä hetkestä, kun ne tulevat sisään, siihen asti, kun olemme valmiita niiden kanssa:

Keruu → Luokittelu → Suojaus → Käyttö → Säilytys → Poisto → Auditointi

Ei seitsemän teknistä prosessia: seitsemän kysymystä, joihin arkkitehtuurin on vastattava. Keruu ja luokittelu on jo käsitelty: pidä kalliit virheet ulkona (moduuli 2) ja tiedä, mitkä tiedot ovat arkaluonteisia (moduuli 3). Luokittelu ratkaisee, mitä kussakin myöhemmässä vaiheessa tapahtuu, joten tämä moduuli jatkaa siitä.

Click to enlarge

Seitsemän kysymystä tietojen elinkaaren aikana. Työkalut tukevat käytäntöä; ne eivät määrittele sitä.

Suojaus: sovita kontrolli tietoihin

Kuka voi nähdä sen, muuttaa sitä, vastaanottaa sen? Pitäisikö se salata, peittää tuotannon ulkopuolella, voiko sen viedä ulos, pääseekö agentti siihen käsiksi? Tässä Salesforcen tietoturvasta tulee osa tietojen hallintaa: jakaminen, objekti- ja kenttäkäyttöoikeudet, salaus, peittäminen, integraatioiden pääsy. Niistä aiheista riittää kokonaisiin kursseihin, joten en opeta niitä uudelleen. Hallinnan näkökulma: suojaus seuraa luokittelua ja käytäntöä. Jokainen kenttä ei tarvitse samaa suojausta, jokainen käyttäjä ei samaa pääsyä, eikä jokainen alavirran järjestelmä jokaista kenttää.

Salaus on kontrolli, ei vaatimustenmukaisuus

Säännellyille tiedoille levossa olevien tietojen salaus voi olla pakollista, ja kantani on, että Shield on vastaus keskeisiin sääntelyvaatimuksiin kuten siihen. Shield Platform Encryption salaa kentät ja tiedostot levossa. Mutta ”salasimme sen, joten noudatamme vaatimuksia” on väärin kahdesti. Salaus on yksi kontrolli muiden joukossa: pääsy, säilytys, auditointi, suostumus, valvonta, minimointi ja poisto. Ja sillä on toiminnallisia kompromisseja, jotka otetaan huomioon suunnittelussa heti alussa. Oletusarvoisella probabilistisella menetelmällä salattua kenttää ei voi käyttää SOQL:n WHERE-, GROUP BY- tai ORDER BY-lausekkeissa eikä tiedonhallinnan suodattimissa; deterministinen salaus luopuu hieman vahvuudesta, jotta kentällä voi suodattaa. Salatut kentät eivät voi ohjata ehtoihin perustuvia jakamissääntöjä, eikä luettelonäkymiä voi lajitella niiden mukaan (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). Salaus ei siis ole valintaruutu lopussa. Se on arkkitehtuuripäätös. Tietoturvaluku menee syvemmälle.

Älä kopioi tuotannon riskiä sandboxiin

Tuotanto on lukittu. Sitten joku päivittää full sandboxin, ja kehittäjillä, testaajilla, alihankkijoilla ja testi-integraatioilla on nyt kopiot oikeista henkilötiedoista, joita he eivät koskaan tarvinneet. Ympäristö muuttui; tietojen arkaluonteisuus ei. Salesforcen peittotyökalut ovat olemassa juuri tätä varten. Huomaa muutos: Data Mask -hallittu paketti saavuttaa palvelunsa päättymisen 31.12.2026, ja sen seuraaja on Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). Mutta työkalu tukee käytäntöä, ja kysymys tulee ensin: tarvitseeko tämä ympäristö oikeita arkaluonteisia tietoja lainkaan? Jos realistiset, ei-arkaluonteiset tiedot riittävät testaukseen, se on parempi vastaus.

Käyttö: lupa ei koske vain ihmisiä

Käyttäjät, integraatiot, analytiikka, kumppanit, automaatio ja agentit käyttävät kaikki tietoja. Suostumus (moduuli 5), omistajuus (moduuli 1) ja luokittelu (moduuli 3) kohtaavat tässä ajon aikana. Pitäisikö tämän käyttäjän nähdä vastaanottajan puhelinnumero? Pitäisikö tämän integraation saada se, tai Snowflaken, tai tämän agentin groundingina (ankkurointina dataan)? Vastaus ei voi olla ”no, teknisesti se pystyy”. Siinä on kyvyn ja hallinnan ero: arkkitehtuuri päättää, pitäisikö sen.

Säilytys: kaiken säilyttäminen ikuisesti ei ole neutraalia

Monilla organisaatioilla on vahingossa syntynyt säilytyskäytäntö: ikuisesti. Kukaan ei päättänyt sitä; tallennustilaa oli, joten tiedot jäivät. Mutta tietojen säilyttäminen maksaa tallennustilaa ja suorituskykyä, laajentaa tietosuoja- ja tietoturva-altistusta, lisää selvitysvelvoitteita ja antaa sinulle enemmän paikkoja etsiä, kun joku pyytää tulla unohdetuksi. Kustakin tärkeästä luokasta: miksi sitä säilytetään, kuinka kauan, mikä käynnistää ajan kulumisen, onko lakisääteinen vähimmäisaika tai tietosuojan enimmäisaika, ja mitä tapahtuu lopussa: arkistointi, poisto, tunnisteettomaksi tekeminen?

Eikä arkistointi ole sama asia kuin säilytyksen ratkaiseminen. ”Arkistoimme sen.” Katosiko säilytysvaatimus? Tietosuojavaatimus? Tietoturva? Muutit sitä, missä tiedot asuvat, et sitä, mitä ne ovat. Arkisto tarvitsee pääsynhallinnan, säilytys- ja poistosäännöt, selvityksen ja auditoinnin. Siirrä henkilötiedot arkistoon, jonka kaikki unohtavat, niin hallinta muuttui juuri huonommaksi.

Poisto: elinkaari tarvitsee uloskäynnin

Poistaminen ei ole vain yksittäisiä tietosuojapyyntöjä varten. Tiedot saavuttavat säilytysaikansa lopun; väliaikaiset tietueet elävät käyttötarkoitustaan pidempään; arkistot vanhenevat; prosessi tekee tiedoista tunnisteettomia tietyn ajan jälkeen. Mitä tahansa käytäntö sanookin, arkkitehtuuri tarvitsee uloskäynnin, ei keruu → tallennus → lisää tallennusta → tallennus ikuisesti. Ja kuten moduuli 5 osoitti, Salesforce-tietueen poistaminen ei riitä, kun kopioita on muualla.

Historiakin on tietoa

Joskus nykyinen arvo ei riitä. Kumppanin virallinen nimi, asiakkaan luokitus, suostumuksen tila, taloudellinen attribuutti: liiketoiminnan tai sääntelijän voi olla tarpeen tietää, mikä se oli aiemmin, milloin se muuttui ja kuka sen muutti. Se historia on tietoa, ja se tarvitsee oman säilytyspäätöksensä.

Tavallinen kenttähistorian seuranta seuraa enintään 20 kenttää objektia kohden ja säilyttää muutoksia enintään 18 kuukautta, ja enintään 24 kuukautta vain API:n kautta, Data Loaderilla tai queryAll()-kutsulla (Field History Tracking Overview (opens in a new tab)). Ja pitkistä tekstikentistä se kirjaa vain sen, että kenttää muokattiin, ei sitä, mitä siinä luki: aukko, jos se on näyttösi. Field Audit Trail, osa Shieldiä tai erikseen ostettava, seuraa enintään 200 kenttää objektia kohden ja säilyttää historian siihen asti, kunnes poistat sen, arkistossa, jota käytetään API:n kautta (Field Audit Trail (opens in a new tab)). Kantani: tavallinen kenttähistoria on oletus; käytä Field Audit Trailia, kun sääntely tai compliance-velvoite vaatii pidempää, todistettavaa historiaa. Ei siksi, että ”auditointi kuulostaa hyvältä”.

Auditointi ja valvonta eivät ole sama asia

Kenttähistoria vastaa kysymyksiin valittujen kenttien muutoksista. Laajemmat kysymykset (kuka kirjautui, kuka vei tietoja ulos, mitä API:a kutsuttiin, kuka katsoi mitäkin) ovat valvontaa, ja se on Event Monitoring. Kokemukseni mukaan sitä tarvitaan tyypillisesti säännellymmillä asiakkailla, ja tässä on tämän luvun vahvin kantani: ota se käyttöön ennen kuin tarvitset sitä, ja ohjaa tapahtumat etukäteen säilöön, kuten Splunkiin tai muuhun SIEM-järjestelmään.

Tässä syy. Tapahtumalokitiedostoja säilytetään ilman lisäosaa 1 päivä, ja vain joistakin tapahtumatyypeistä; Shieldin tai Event Monitoring -lisäosan kanssa oletuksena 30 päivää ja enintään 365 päivää, jos pidennät säilytystä (Event Monitoring FAQ (opens in a new tab)). Kaikki vanhempi on poissa, ellet vienyt sitä ulos. Eikä maksullisia lokeja voi hakea miltään sopimustasi edeltävältä ajalta (sama FAQ): lisäosan ostaminen välikohtauksen jälkeen ei tuo menneisyyttä takaisin. Niinpä yksi pahimmista keskusteluista, joita arkkitehti voi käydä, menee näin: ”Voimmeko nähdä, mitä tapahtui kuusi kuukautta sitten?” ”Emme.” ”Miksi ei?” ”Emme tallentaneet sitä.” Et halua törmätä ongelmaan ja huomata vasta silloin, ettet ole tallentanut ja säilyttänyt niitä tapahtumia. Siinä vaiheessa vastaus on yksinkertaisesti poissa.

Click to enlarge

Ota se käyttöön ennen kuin tarvitset sitä.

Mutta älä heilahda toiseen ääripäähän: ”kirjataan kaikki”. Mitä yrität todistaa? Mitkä tapahtumat ovat tärkeitä, kuka niitä tarvitsee, kuinka kauan, kuka saa lukea lokeja, ja voiko lokeissa itsessään olla arkaluonteisia tietoja? Lokitus luo tietoja, ja nekin tiedot tarvitsevat hallintaa. Ja näyttö tarvitsee omistajan: kuka omistaa säilön, käy läpi hälytykset, tarkistaa, että säilytys toimii, huomaa, että syöte lakkasi hiljaa toimimasta kolme kuukautta sitten? Tekniikka ilman omistajuutta ei ole hallintaa; olemme taas moduulin 1 omistajassa, vastuuhenkilössä ja ylläpitäjässä.

Todista kontrolli, älä pelkkää konfiguraatiota

”Vastaanottajan tiedot ovat vain pysähdykselle määrättyjen tiimien käytettävissä.” Mistä tiedämme? Tietoturvakonfiguraatio näyttää, mitä pitäisi tapahtua. Operatiivinen näyttö (kuka sitä todella käytti, epätavalliset viennit, integraatio, joka hakee sitä, muutetut pääsynhallinnat) näyttää, mitä tapahtui. Hyvä hallinta tarvitsee usein molempia.

Kokeen jälkeen: mitä tekoäly muuttaa. Kun agentit siirtyvät vastaamisesta toimimiseen, hallinta tarvitsee näyttöä siitä, mitä agentti näki, mitä se päätti tai tuotti ja mitä se teki, sekä siitä, kuka tai mikä sen käynnisti ja minkä käytännön alla. Lokimekanismit muuttuvat; vaatimus ei: jos autonominen toiminta on tärkeää, suunnittele nyt, miten rekonstruoit sen myöhemmin.

Steve Trucking: elinkaari yhdessä kentässä

Otetaan vastaanottajan puhelinnumero. Keruu: se saapuu kumppanin kuormaluettelossa (manifest); tarkista, että se on käyttökelpoinen siellä, missä prosessi sitä tarvitsee. Luokittelu: henkilötieto. Suojaus: vain ihmiset ja järjestelmät, joilla on operatiivinen tarve, saavat sen, ja tiimit näkevät sen vain omilla pysähdyksillään ja vain sinä päivänä. Käyttö: tiimi koordinoi toimituksen; viestintä käyttää sitä hyväksyttyyn tarkoitukseen; agentti käyttää sitä vain, jos käytäntö sallii. Säilytys: niin kauan kuin hyväksytty liiketoiminta- ja tietosuojakäytäntö sanoo. Poisto tai tunnisteettomaksi tekeminen: kun se aika päättyy tai pätevä pyyntö saapuu, jokaisesta järjestelmäkartan kopiosta. Auditointi: säilytä näyttö siitä, että kontrollit ja toimet tapahtuivat.

Otetaan nyt jakelukeskuksen koodi. Kerää se tarkasti, luokittele se ei-arkaluonteiseksi viitetiedoksi, suojaa se tavallisella operatiivisella pääsyllä, käytä sitä laajasti, säilytä sitä liiketoiminnan tarpeen mukaan ja auditoi muutokset, jos niillä on väliä. Sama elinkaari, eri kontrollit. Sitä varten luokittelu on olemassa.

Hallinta ei ole koskaan valmis

Uusi säädös ilmestyy. Uusi järjestelmä tai integraatio luo uuden kopion. Tiimi keksii uuden kentän. Uusi alusta otetaan käyttöön. Agentti saa pääsyn. Säilytyssääntö muuttuu. Uusi vähittäiskauppakumppani tulee mukaan. Arkkitehtuuri liikkuu, ja hallinta liikkuu sen mukana. Tavoite ei ole täydelliset tiedot, loputtomat kontrollit tai hallinta-asiakirja, jota kukaan ei lue. Tavoite on harkitut päätökset tiedoista, rakennettuina arkkitehtuuriin.

Mitä arkkitehti tässä päättää

• Mitä suojauskontrolleja kukin tietoluokka saa luokittelun, käytännön ja todellisen käytön perusteella, salauksen kompromissit mukaan lukien.
• Kuinka kauan tietoja ja niiden historiaa säilytetään, mikä käynnistää ajan kulumisen ja mitä tapahtuu lopussa.
• Milloin tavallinen kenttähistoria riittää ja milloin sääntely edellyttää Field Audit Trailia.
• Mitä tapahtumia tallennetaan, missä näyttöä säilytetään alustan säilytysajan jälkeen ja kuka sen omistaa.
• Miten arkkitehtuuri todistaa tärkeät ihmisten, integraatioiden ja agenttien toimet jälkikäteen.

Tämä luku alkoi yhdestä ajatuksesta: tietojen hallinta suunnitellaan orgiin, sitä ei kirjoiteta sen viereen. Omistajat päättävät käytännöt, ja arkkitehdit panevat ne täytäntöön. Pidä huonot tiedot ulkona siellä, missä sillä on väliä. Tiedä, mitä tietosi tarkoittavat, mistä ne tulivat ja kuinka arkaluonteisia ne ovat. Kunnioita lakeja, mallinna suostumus, hallitse, minne henkilötiedot menevät. Suojaa, säilytä ja poista käytännön mukaan. Ja tallenna näyttö ennen kuin kukaan pyytää sitä, koska kuusi kuukautta välikohtauksen jälkeen on kamala hetki huomata, että näyttö oli olemassa vain kolmekymmentä päivää.

Lue lisää

• Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) ja Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Field History Tracking Overview (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Field Audit Trail (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).