Tietoturvamallit
Lue lisää Well-Architected Trust -ominaisuudesta → Datan suojaus ja yksityisyys
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Datan luokitteluskeema | ✅ Luokitteluskeema, joka on dokumentoitu tasoilla (Julkinen, Sisäinen, Luottamuksellinen, Rajoitettu) ✅ Jokaiselle luokittelutasolle tarjotut liiketoimintaesimerkit ✅ Luokittelujärjestelmä, joka noudattaa lakisääteisiä velvollisuuksia (HIPAA, PCI DSS, GDPR) ✅ Datamallintajat, jotka on koulutettu käyttämään luokittelua yhdenmukaisesti suunnittelun aikana ✅ Uudet kentät, jotka on luokiteltu osana datan mallinnusprosessia, ei takautuvasti |
| Kenttätason luokittelu | ✅ Luokittelua käytetään kenttätasolla, ei vain objektitasolla ✅ Yhden objektin kentillä voi olla eri luokitukset ✅ Kenttätason suojaus vastaa luokittelun eroavaisuuksia ✅ Luokittelemattoman datan oletusarvo on korkein sopiva suojaustaso ✅ Luokittelu määrittää suojausasetukset (salaus, käyttöoikeus, säilytys) |
| Mukautetut objektit ja kentät | ✅ Kaikilla mukautetuilla objekteilla on dokumentoitu datan luokittelu ✅ Luottamukselliset kentät (palkka, SSN, PHI, maksutiedot), jotka on luokiteltu luottamuksellisiksi tai rajoitetuiksi ✅ Julkiset kentät (yrityksen nimi, verkkosivusto), jotka on dokumentoitu julkisiksi ✅ Kenttäkuvauksissa kaapattu luokittelun metadata ✅ Luokitus tarkastettu koodin tarkastuksen ja ARB:n aikana |
| Vakio-objektit | ✅ Vakiomuotoisen objektin kentät, arvioidaan luokitteluskeeman perusteella ✅ Shield Platform Encryption käytössä rajoitetuille vakiokentille ✅ Luottamuksellisten vakiokenttien kenttätason suojaus ✅ Raportit ja luettelonäkymät suodatetaan estääkseen luottamuksellisten vakiokenttien näyttämisen |
| Integrointidata | ✅ Tiedot kulkevat ennen käyttöönottoa luokiteltujen integraatioiden läpi ✅ Ulkoisen järjestelmän tietojen luottamuksellisuus arvioitu ja dokumentoitu ✅ Integraation päätepisteet Rajoitettujen tietojen käytön sertifikaatteihin perustuva todennus ✅ Tietojen luokittelu säilytetään järjestelmän rajojen yli |
| Vaatimustenmukaisuuden kartoitus | ✅ HIPAA PHI -kentät tunnistettu ja merkitty rajoitetuksi ✅ PCI-kortinpitäjien dataa vältetään Salesforcessa aina, kun se on mahdollista — tokenisoidaan maksusiltapalvelun kautta vaikutusalueen vähentämiseksi; jos se täytyy tallentaa, käytä PCI DSS -ohjaimissa salattuja mukautettuja kenttiä ✅ GDPR:n tunnistamat henkilötiedot, joihin sovelletaan yksityisyysasetuksia ✅ SOX-rahoitustiedot on luokiteltu ja niiden tehtävät on eroteltu |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Yhtenäinen suojaus | ⚡️ Sama suojaus kaikille kentille luottamuksellisuudesta riippumatta ⚡️ Alhaisen arvon dataa on ylikäytetty (resurssien tuhlaaminen), kun taas arvokkaita tietoja ei ole tarpeeksi suojattu ⚡️ Julkisia yritystietoja käsitellään samalla tavalla kuin PHI- tai maksukorttitietoja ⚡️ Jokainen kenttä salattu “vain turvallisuuden vuoksi” ilman luokittelun perustelua |
| Retroaktiivinen luokitus | ⚡️ Tiedot, jotka on luokiteltu tuotantoympäristöön käyttöönoton jälkeen ⚡️ Luottamukselliset tiedot, jotka on löydetty vaatimustenmukaisuuden auditoinneista suunnittelun tarkastusten sijaan ⚡️ Tiedot luokitellaan vain tietoturvahyökkäysten jälkeen ⚡️ Oletusarvo on kehitysvaiheessa “Luokittelu selviää myöhemmin”. |
| Vain objektitason luokittelu | ⚡️ Koko objektit luokitellaan yhdenmukaisesti, kun kenttien luottamuksellisuus on eri ⚡️ Objektitason käyttöoikeus myönnetty ilman kenttätason suojausta luottamuksellisille kentille ⚡️ Kaikilla Tili- tai Yhteyshenkilö-objektien kentillä oletetaan olevan sama luokitus ⚡️ Objektien käyttöoikeudet, joita käytetään ainoana käyttöoikeuksien hallintana luottamuksellisten objektien kanssa |
| Kanta-asiantuntemus | ⚡️ Luokitus ei-asiakirjaton, olemassa vain tärkeimpien ihmisten Knowledgessa ⚡️ Kehittäjät luottavat ”vain tietämään”, mitkä kentät ovat luottamuksellisia ⚡️ Kaikkien datamallintajien käytettävissä ei ole kirjoitettua luokittelujärjestelmää ⚡️ Uudet tiimin jäsenet perehdyttiin ilman luokittelukoulutusta |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Salaus paikallisesti | ✅ Kaikki infrastruktuuritasolla Hyperforcen kautta salattu data ✅ Shield Platform Encryption käytössä rajoitetulle datalle ✅ Salaustapa (todennäköisyyksiin perustuva, deterministinen, merkkikokoriippuvainen deterministinen) valittuna kyselyn ja yksilöllisyyden vaatimusten perusteella ✅ Datamallin suunnittelun aikana arvioidut salauksen kompromissit |
| Shield Platform Encryption -strategia | ✅ Todennäköisyyksiin perustuva salaus käytetään useimmille rajoitetuille kentille (tukee kaikkia kyselytoimintoja) ✅ Deterministinen salaus, jota käytetään kentille, jotka vaativat tarkkoja WHERE-lausekkeita tai yksilöllisyyttä ✅ Merkkikokoriippuvainen deterministinen käytössä, kun tapausten erottaminen on tärkeää liiketoimintalogiikalle ✅ Salatun kentän toimintatapa testattu ennen tuotantoympäristön käyttöönottoa ✅ Kaavakentät viittaavat asianmukaisesti käsiteltyihin salattuihin kenttiin (siirretty tarvittaessa Apexiin) |
| Avainten hallinta | ✅ Avainten kierrättäminen dokumentoitu ja automatisoitu ✅ Tärkeimmät tuhouskenaariot, joita testattiin katastrofien palautuksen aikana ✅ Asiakkaan hallitsemien avainten (BYOK) vaatimustenmukaisuuden arviointi, joka vaatii erillisen avainten hallinnan ✅ Asiakirjoitetut tärkeimmät kumoamismenettelyt ✅ Salausavaimen elinkaari hallittu vaatimustenmukaisuuden vaatimusten mukaisesti |
| Salaus siirron aikana | ✅ TLS 1.2 tai uudempi vaaditaan kaikille integraatioille ✅ Sertifikaatteihin perustuva yhteinen todennus integraatioille, jotka käsittelevät rajoitettua dataa ✅ HSTS-otsikot, jotka on määritetty Experience Cloud -sivustoille estääksesi protokollan alentamisen ✅ TLS-sertifikaatin vanhenemista valvotaan ja automaattista uusimista määritetään ✅ Heikot salaukset ja protokollat poistettu käytöstä |
| Koodi ja kokoonpano | ✅ Tunnuksia ei koskaan upotettu koodiin, kokoonpanotiedostoihin tai versioiden hallintaan ✅ Nimetyt tunnukset ja ulkoiset tunnukset, joita käytetään todennuksen hallintaan keskitetysti ✅ Arkkitehtuuriin perustuvat Credential Rotation -ominaisuudet ✅ Nimettyjen tunnusten abstrakti todennus koodista, joka ottaa päivitykset käyttöön ilman koodimuutoksia |
| AppExchange | ✅ Paketin suojausvaatimukset arvioidaan ennen asennusta ✅ Salatut kentät ovat pakettien käytettävissä vain liiketoimintatarkoituksessa ✅ Pakettien datan käyttöoikeuskuvioita valvotaan Event Monitoringin avulla ✅ Paketit, jotka vaativat käyttöoikeuden rajoitettuihin tietoihin, jotka on tarkastettu tehostetusti |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Salaus ilman arviointia | ⚡️ Todennäköisyyksiin perustuva salaus käytössä kaikissa kentissä ilman testausta ⚡️ Tuotantoympäristössä olevat kriittiset raportit epäonnistuvat, koska salattuja kenttiä ei voi aggregoida ⚡️ Salaus otettu käyttöön kaavakenttien lähteille ilman ymmärryksen vaikutusta ⚡️ SOQL LIKE -kyselyissä käytetyt kentät salattuina siirtymättä deterministiseen salaukseen |
| Upotetut tunnukset | ⚡️ Koodiin, mukautettuihin asetuksiin tai versioiden hallintaan upotetut tunnukset ⚡️ Apex kovakoodatut API-avaimet, salasanat ja sertifikaatit ⚡️ Lähdekoodin hallintasäiliöihin sitoutetut tunnukset ⚡️ Mukautettuun metadataan tai mukautettuihin asetuksiin tallennetut tunnukset ilman salausta |
| Heikot tai vanhat protokollat | ⚡️ TLS 1.0 tai 1.1 hyväksytty (vanhentunut ja haavoittuvainen) ⚡️ Käyttäjänimi/salasana OAuth-kulku sallittu, kun JWT-haltija on käytettävissä ⚡️ Itse allekirjoitetut sertifikaatit hyväksytään tuotanto-integraatioissa ⚡️ Sertifikaatin vahvistus poistettu käytöstä “integroinnin tekemiseen” |
| Ei avainten hallintaa | ⚡️ Shield Platform Encryption käytössä ilman avainten kierrättäviä toimenpiteitä ⚡️ Ei dokumentoituja avainten tuhoutumisskenaarioita ⚡️ Oletusavaimet, joita käytetään arvioimatta asiakkaan hallitsemia avaimia vaatimustenmukaisuutta varten ⚡️ Avainten kierrätys- ja peruutustoimenpiteitä ei ole koskaan testattu |
| Ylisalaus | ⚡️ Julkinen tai sisäinen luokittelutiedot salattu, mikä lisää kustannuksia ilman etua ⚡️ Shield Platform Encryption käytössä kaikille kentille, mikä aiheuttaa tarpeetonta monimutkaisuutta ⚡️ BYOK käytetään, kun vaatimustenmukaisuus ei vaadi sitä (lisää toiminnalliset ylimääräiset kustannukset) ⚡️ Salaus pakollinen, jos datan luokittelu ei oikeuta sitä |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Sandbox-strategia | ✅ Rajoitettua dataa ei koskaan siirretä kehitys- tai testausympäristöihin ✅ Sandboxin osittainen kopiointi ei sisällä rajoitettuja objekteja ja kenttiä ✅ Sandbox-mallit määrittävät, mitkä objektit ja kentät sisällytetään ympäristötyypin mukaan ✅ Data Mask määritetty sandboxeille, jotka vaativat tuotantoympäristöön perustuvaa dataa |
| Data Mask -säännöt | ✅ Data Mask -säännöt piilottavat luottamukselliset kentät säilyttäen tietojen ominaisuudet ✅ Kuviot ylläpitävät viite-eheyttä (sama input-arvo tuottaa saman peitetyn output-arvon) ✅ Sähköpostiosoitteet peitetään, mutta ne pysyvät voimassa testausta varten ✅ Puhelinnumerot peitetään, mutta ne säilyvät käypiä ✅ Päivämäärät siirretään yhdenmukaisesti suhteellisten suhteiden ylläpitämiseksi ✅ Numeeriset kentät satunnaisesti todellisissa arvoalueissa |
| Synteettinen data | ✅ Kehitysympäristöt käyttävät synteettistä datan luontia ✅ Synteettisellä datalla on realistisia ominaisuuksia, jotka mahdollistavat tehokkaan testauksen ✅ Kehitykseen ei tarvita koskaan tuotantodataa ✅ Testaa datan luomista automaattisesti kehitysputkissa |
| Muut kuin tuotantoympäristöt | ✅ Tuotantodataa ei kopioida koskaan henkilökohtaisiin kehitysorganisaatioihin ✅ Näytön kaappaukset ja esittelyt käyttävät peitettyä tai synteettistä dataa ✅ Koulutusympäristöt käyttävät synteettistä dataa tai vahvasti peitettyä tuotantodataa ✅ Toimeksisaajan ja toimittajan käyttöoikeudet ei-tuotantotietoihin, jotka on rajoitettu Vain yrityskäyttö -luokitteluun |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Tuotantodataa sandboxeissa | ⚡️ Täydet sandboxit päivitetään peittämättömillä tuotantodateilla kehitystä varten ⚡️ Rajoitettu data kopioidaan kehittäjien sandboxeihin helpottamiseksi ⚡️ Kehittäjät myönsivät laajan käyttöoikeuden tuotanto-data-sandboxeihin ⚡️ Sandboxit päivitetään luottamuksellisilla tiedoilla “koska testaaminen on helpompaa todellisella datalla” |
| Ei synteettistä dataa | ⚡️ Tuotantodataan luotettu vain kaikille testeille ⚡️ Ei synteettistä datan luomista kehitysympäristöille ⚡️ Oletetaan, että “tarvitsemme todellista dataa” arvioimatta synteettisiä vaihtoehtoja ⚡️ Manuaaliset testitiedot, jotka luodaan, kun generointia voidaan automatisoida |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Datan minimointi | ✅ Kerätään vain määritettyihin liiketoimintatarkoituksiin tarvittavat tiedot ✅ Jokainen kenttälisäys, jota haetaan “mitä arkkitehtuuripäätöstä tämä data vaatii?” ✅ Tiedot, jotka eivät enää tarjoa keruutarkoitusta, poistettu ✅ Valinnaiset kentät on merkitty selkeästi ja ei pakollisiksi ilman liiketoimintaperusteita ✅ Historiallisten tietojen säilyttäminen linjassa lakisääteisen perusteen kanssa, ei “säilytä kaikki ikuisesti” |
| Käyttötarkoituksen rajoitus | ✅ Käyttöoikeusjoukot rajoittavat tietojen käyttöä työn käyttötarkoituksen perusteella ✅ Markkinointikäyttäjät eivät voi käyttää tukitapausten lisätietoja ilman asiakirjoitettua perustelua ✅ Myyntikäyttäjät eivät voi käyttää asiakaspalveluhistorioita, ellei työ vaadi sitä ✅ Toimintojen välinen datan käyttö vaatii suoran hyväksynnän ja valvonnan ✅ Käyttöoikeusjoukkojen kuvauksissa kuvattu käyttötarkoitus |
| Suostumusten hallinta | ✅ Yksittäisellä tasolla kerätty suostumus markkinointia, analyysiä ja valinnaista käsittelyä varten ✅ Suostumus on tarkka (tarkoituskohtainen), ei binäärinen suostumus ✅ Suostumusten peruutustyönkulut leviävät integroituihin järjestelmiin ✅ Suostumusten päätöksiä seurataan aikaleimalla, versiolla ja mekanismilla ✅ Suostumusten käyttöliittymä selittää selkeästi, mihin käyttäjä suostuu |
| Datan aiheen oikeudet | ✅ Käyttöoikeuspyyntöjen työnkulut tarjoavat datan kopioita käyttöönottosi määräaikojen mukaisesti ✅ Korjaustyönkulut korjaavat virheitä kirjausketjulla ✅ Poisto-työnkulut poistavat dataa, jos se on lakisääteisesti sallittu (huomioi säilytyskäytännöt) ✅ Siirrettävyyden työnkulut vievät dataa koneellisesti luettavassa muodossa ✅ Datan aiheen oikeuksien työnkulut, joita testataan säännöllisesti aikajanojen vahvistamiseksi ✅ Työnkulkujen automatisointi varmistaa, että lakisääteiset aikataulut täyttyvät yhdenmukaisesti |
| Yksityisyyden hallinta | ✅ Tietoturvaa koskevia asetuksia noudatetaan teknisesti, ei vain käytännön kautta ✅ Jakosäännöt käyttävät käyttötarkoituksen rajoitusta ✅ Kenttätason suojaus suojaa luottamuksellisia attribuutteja ✅ Kirjausketjut sieppaavat yksityisyyttä koskevia tapahtumia ✅ CI/CD-putkissa vahvistetut yksityisyysasetukset |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Kerää kaikki | ⚡️ “kerää kaikki mahdolliset tiedot, saatamme tarvita niitä joskus” -menetelmä ⚡️ Kentät, jotka on lisätty ilman asiakirjoitettua liiketoimintatarkoitusta ⚡️ Tietoja säilytetään määrittämättömästi ilman säilytyksen perustelua ⚡️ Valinnaiset tiedot, jotka kerätään tekemällä kentistä pakollisia |
| Täysi suostumus | ⚡️ Yksittäinen ”hyväksy ehdot” -suostumus kaikille käyttötarkoituksille ⚡️ Markkinointi suostumus yhdistettynä palvelutoimitukseen yhdessä valintaruudussa ⚡️ Suostumus tekee kaiken tai ei mitään, kun tarkoitukset on erotettavissa ⚡️ Suostumus on haudattu 20 sivun ehtoihin |
| Käytäntö ilman pakotetta | ⚡️ Yksityisyyden suojauskäytäntö kuvaa ihanteellisia käytäntöjä, joita ei noudateta teknisesti ⚡️ Käyttäjien koulutus, jota käytetään asiattomien tietojen käytön estämiseksi ⚡️ Yksityisyysperiaatteet, jotka on dokumentoitu ilman teknisiä asetuksia ⚡️ Käytännön vaatimustenmukaisuus oletetaan ilman valvontaa ja vahvistusta |
| Manuaaliset datan aiheiden pyynnöt | ⚡️ GDPR/CCPA-pyynnöt käsitellään manuaalisilla IT-lippuilla, jotka kestävät kuukausia ⚡️ Ei asiakirjoitettuja käyttöoikeuksia, korjauksia, poistamista tai siirrettävyyttä koskevia toimenpiteitä ⚡️ Pyynnön täydennysikkuna, jossa käyttöönottosi sääntelyjoukot puuttuvat ⚡️ Pyydä, että tarkastuksissa löytyneitä työnkulkuja ei ole olemassa |
| Liiallinen datan jakaminen | ⚡️ Laaja tietojen käyttöoikeus myönnetty eri osastoissa ilman käyttötarkoituksen perusteluja ⚡️ Markkinointi myönsi pääsyn tukitapauksen lisätietoihin ⚡️ Myynnit sallivat pääsyn asiakaspalveluhistorioihin ilman dokumentoitua tarvetta ⚡️ Julkinen luku/kirjoitus OWD, jota käytetään henkilötietoja sisältäville objekteille |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Hyperforcen alueellinen käyttöönotto | ✅ Hyperforce provisioitu organisaatio täyttää datan residenssin vaatimukset ✅ Tietojen tallentaminen ja käsittely tapahtuu vaadituissa maantieteellisissä rajoissa ✅ Alueelliset vaatimukset, jotka on dokumentoitu ja vahvistettu ennen provisiointia ✅ Usean alueen vaatimukset, jotka käsitellään usean organisaation arkkitehtuurin avulla tarvittaessa |
| Datakulkujen kartoitus | ✅ Datakulku kartoittaa asiakirjan, josta data on peräisin, siirretään ja sijaitsee ✅ Rajat ylittävät datan siirrot, jotka on tunnistettu ja arvioitu säännösten mukaisesti ✅ Vakiosopimuslausekkeet tai velvoittavat yrityssäännöt kansainvälisille siirroille ✅ Sijaintien vaatimustenmukaisuuden perusteella arvioidut datan siirtopolut, ei vain tallennustila |
| Datan residenssin vaikutusalue | ✅ Datan tallennustila (mikä Hyperforce) ✅ Datan käsittelysijainti (laske alueet) ✅ Varmuuskopiosijainti ✅ Lokien ja kirjauslokien tallennustila ✅ Integraation siirtopolut arvioidaan rajat ylittävälle datan siirrosta varten |
| Usean organisaation arkkitehtuuri | ✅ Usean organisaation arkkitehtuuri, jota käytetään, kun sääntelyvaatimuksia ei voida täyttää yhdessä organisaatiossa ✅ Jokainen organisaatio, joka on provisioitu tietojensa asiaankuuluvalle alueelle ✅ Integrointikuvio noudattaa datan sijaintirajoituksia ✅ ADR-raporteissa dokumentoidut toiminnan monimutkaisuuden kompromissit |
| Vaatimustenmukaisuuden vahvistus | ✅ Lainkäyttöalueen dokumentoimat datan residenssien vaatimukset ✅ Hyperforce valinta vahvistettu vaatimusten perusteella ennen provisiointia ✅ Säännölliset auditoinnit vahvistavat, että tiedot säilyvät vaadittujen rajojen sisällä ✅ Asuntosääntöjen muutokset käynnistävät arkkitehtuurin tarkastuksen |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Asumisvalvonta | ⚡️ Vaatimustenmukaisuustarkastuksissa havaitut datan residenssin rikkomukset ⚡️ Organisaatiot, jotka on provisioitu arvioimatta alueellisia vaatimuksia ⚡️ Oletetaan, että “pilvi on pilvi” ilman datan sijaintien säännöksiä ⚡️ Oleskeluoikeudet, jotka lisättiin tarkastamatta oleskeluoikeuksia |
| Kuljetus ei huomioi asuinpaikkaa | ⚡️ Vain tallennustila huomioidaan, kun kuljetuspolkuja ei huomioida ⚡️ Vaatimustenmukaisuuden rajojen ulkopuolisten alueiden kautta reititetty data ⚡️ Ei-yhteensopivissa alueissa käytetty integraation välitysohjelmisto ⚡️ Varmuuskopiot, joita säilytetään eri alueilla kuin ensisijainen data |
| Tarpeeton moniorganisaatio | ⚡️ Usean organisaation arkkitehtuuri, jota käytetään, kun yksi Hyperforce sisältävä organisaatio riittää ⚡️ Toiminnan monimutkaisuus, lisenssien kustannukset ja integraation kokonaiskustannukset kerrottuna ilman lakisääteistä tarvetta ⚡️ Usean organisaation toteuttama “vain turvalliseksi” ilman tiettyä vaatimusta ⚡️ Useita organisaatioita käytetään oletusarvoisesti, kun datan luokittelu- ja käyttöoikeusasetukset riittävät |