Trust

Salesforcessa Trust on tärkein arvo. Se on kaikkien sovellusalustan arkkitehtuuripäätösten perusta. Arkkitehtien Trust saavutetaan ainutlaatuisen kumppanuuden kautta: Salesforce tarjoaa turvallisen ja vaatimustenmukaisen sovellusalustan — infrastruktuurin, metadatan ja työkalut, jotka tekevät siitä omasi — samalla kun suunnittelet siihen perustuvia turvallisia ratkaisuja.

Tämä kumppanuus toimii jaetun vastuun mallin kautta, joka on kehys, joka jakaa turvallisuusvastuut selkeästi:

• Salesforce on vastuussa sovellusalustan tietoturvasta, mukaan lukien infrastruktuurista, korjausversioista ja vaatimustenmukaisuussertifikaateista.**
• Olet vastuussa sovellusalustan tietoturvasta, mukaan lukien kokoonpanosta, käyttöoikeuksien hallinnasta, mukautetusta koodista ja datan hallinnasta.******

Tämä divisioona on tärkeä, koska se määrittää arkkitehtuurin vastuullisuuden. Salesforce käyttää usean vuokralaisen arkkitehtuuria, jossa tuhannet organisaatiot jakavat infrastruktuurin. Sovellusalusta tarjoaa vahvoja suojausasetuksia infrastruktuuritasolla. Arkkitehtuuripäätöksesi määrittävät, ansaitseeko tietty ratkaisu sidosryhmien luottamuksen.

Jaetun vastuun malli sallii sinun suunnitella turvallisia ratkaisuja, kun taas fyysinen tietoturva, verkkojen suojaus, sovellusalustan korjaus ja infrastruktuurin salaus hoidetaan puolestasi. Tämä sallii sinun keskittyä sellaisten turvallisten ratkaisujen suunnitteluun, jotka perustuvat tähän perustaan (esimerkiksi henkilöllisyyden ja käyttöoikeuksien hallinta, tietoturva, integroinnin tietoturva, turvalliset kehitystavat, vaatimustenmukaisuus ja säännösten noudattaminen sekä vahinkotapahtumien vastausominaisuudet).

Trust-luottamuksen laiminlyönti yhdistelmien teknisen velan aikana. Puuttuva salausstrategia muuttuu kalliiksi korjaukseksi, kun sääntöjä muutetaan. Ei-hallitusta integraatiosta tulee haavoittuvuus, kun tunnukset vaarantuvat. Trustin rakentaminen alusta alkaen on aina edullisempaa kuin sen asentaminen myöhemmin.

Trust kattaa neljä arkkitehtonista ulottuvuutta, jotka toimivat yhdessä yhtenäisesti:

• Suojausasetukset suojaavat järjestelmiä ja dataa
• Henkilöllisyyden hallinta hallitsee käyttöoikeuksia
• Yksityisyyden suojauskäytännöt kunnioittavat käyttäjäorganisaatiota
• Vaatimustenmukaisuuskehykset täyttävät lakisääteiset velvollisuudet

Kaikkia neljää ulottuvuutta varten suunnittelevat arkkitehdit luovat ratkaisuja, jotka ansaitsevat ja ylläpitävät Trustia avoimuuden, hallinnan ja kestävyyttä.

Agenttien aikakaudella Trust ulottuu luotettuun kontekstiin, jossa agentit toimivat. Luotettu konteksti tarkoittaa, että agentit pääsevät käsiksi hallittuun ja vahvistettuun dataan, jolla on selkeät henkilöllisyyden ja käyttöoikeuksien rajat, mikä sallii tekoälyjärjestelmien päättää ja toimia käyttäjien puolesta samalla, kun ne ylläpitävät tietoturvaa, auditoitavuutta ja vaatimustenmukaisuutta. Luotetun kontekstin suunnitteleminen on tärkeää Agent Enterprise -arkkitehtuurille.

Tämä pilari määrittää sovellusalustan tietoturvan perustason, johon kaikki Salesforce-ratkaisut ovat riippuvaisia. Agenttien Trust -pilari perustuu tähän perustasoon käsitelläkseen itsenäisten agenttien ominaisia riskejä, kuten kehotteita, toimintojen hallintaa ja tietoja, joita agentit voivat käyttää harkinnan aikana. On tärkeää suunnitella ensin perustaso ja sitten kerros agenttikohtaiset ohjaimet käyttämällä Agenttic Trust -ohjeita.

Tämä pilari liittyy läheisesti muihin kehysjärjestelmään liittyviin asioihin.

• Luotettavuus riippuu infrastruktuurista, joka kestää hyökkäyksiä ja toipuu rikkomuksista.
• Operational Excellence vaatii turvallisia käyttöönottoputkia ja vahinkotapahtumien vastauskykyjä.
• Yksityisyys vaatii datan ja algoritmisten päätösten läpinäkyvää ja eettistä käsittelyä.

Yhdessä nämä pilarit muodostavat yhtenäisen, ratkaisuihin keskittyvän lähestymistavan, johon organisaatiot voivat Trustin kaikkein luottamuksellisimmissa toiminnoissaan.

Jaetun vastuun mallissa Salesforcen ja arkkitehtien täytyy täyttää vastuunsa ylläpitääkseen Trustia. Nyt tutustumme tarkemmin siihen, mitä kunkin osapuolen täytyy varmistaa.

Salesforce on vastuussa sovellusalustan ja sen globaalin infrastruktuurin suojaamisesta, mukaan lukien:

• Datakeskuksen käyttöoikeuksien ohjaimet, valvonta ja ympäristönsuojaukset
• Hyperforcen perustana oleva pilvipalveluntarjoaja (esimerkiksi AWS, Azure tai Google Cloud, riippuen instanssista) käsittelee fyysisen datakeskuksen tietoturvan delegoidun vastuun kautta. Salesforcen infrastruktuurin ja alikäsittelijöiden dokumentaatio osoittaa kunkin palvelun tarjoajan ja alikäsittelijät.

• Verkkokerroksen suojausasetukset, mukaan lukien DDoS-suojaus ja uhkien havaitseminen
• Liikenteen salaus liikenteessä (TLS 1.2+) ja levossa (tavallisesti AES-256)

• Haavoittuvuuksien vastaus ja sovellusalustan korjausversion käyttöönotto Salesforcen kautta (lisätietoja suojausohjeista on kohdassa security.salesforce.com)
• Käyttöjärjestelmän ja infrastruktuurin suojauksen hallinta

• Sertifikaatit ja sertifikaatit: Salesforce ylläpitää SOC 1/2/3-, ISO 27001/27017/27018-, FedRAMP-valtuutusta (alueena Government Cloud Plus ja MuleSoft Government Cloud, ei kaupallinen usean vuokralaisen alusta) ja PCI DSS Level 1 -vahvistusta.
• Sääntelytuen: Tämä koskee palveluja, joihin sovelletaan HIPAA-todennusta liiketoimintaan liittyvillä sopimuksilla (Business Associate Agreements, BAA) tai GDPR:n noudattamisohjelmilla.
• Lisätietoja on kohdissa Trust.salesforce.com ja compliance.salesforce.com.

• Työntäjän eristysarkkitehtuuri: Jaettu metadataan perustuva ydin osioi kunkin organisaation datan ja metadatan organisaatiotunnuksen perusteella, joten yksi organisaatio ei voi käyttää toisen organisaation tietueita, vaikka ne toimisivat molemmat jaetussa infrastruktuurissa. Ydin noudattaa erottamista jokaiselle kyselylle, ei kokoonpanon kautta, jota sinun täytyy ylläpitää.
• Infrastruktuuritason salaus paikallisesti ja varmuuskopioinfrastruktuuri: Perusalustan lisensseihin sisältyy Classic Encryption (AES-128 tarjoaa vain mukautettuja tekstikenttiä). Shield Platform Encryption vaatii erillisen lisenssin (AES-256 sallii sinun tuoda oman avaimen ja tarjoaa vakiomuotoisia ja mukautettuja kenttiä, tiedostoja ja liitteitä).

Nämä ohjaimet varmistavat, että sovellusalusta pysyy turvallisena, luotettavana ja vaatimustenmukaisena.

Sinä olet vastuussa datasi, kokoonpanosi ja toimintoprosessiesi suojaamisesta.

• Identiteetti ja liitos: Kun käytät kertakirjautumista (SSO) ja monimenetelmäistä todennusta (MFA), sinun täytyy vahvistaa käyttäjän henkilöllisyys.
• Käyttöoikeusrajoitus: Teknisesti IP-osoitealueet ja kirjautumisajat rajoittavat, miten ja milloin identiteetit muodostavat yhteyden.
• Pienimmän etuoikeuden periaate (PoLP): Käytä PoLP-käyttöoikeutta myöntääksesi käyttöoikeudet vain rooleille, profiileille ja käyttöoikeusjoukoille, joita tarvitaan yksittäisten työtehtävien suorittamiseen.
• Elinkaaren hallinta: Käytä käyttäjien elinkaaren hallintaa ja käyttöoikeuksien uudelleensertifiointia koskevia ohjeita.

• Käytä datan luokittelua, peittämistä ja objektin/kentän/tietuetason suojausta
• Noudata CRUD-käyttöoikeuksia ja jakosääntöjä
• Omista, testaa ja ota käyttöön organisaatiosi datan palauttamiseen tarkoitettu todennettu strategia varmistaaksesi, että tietojen katoaminen tai korjaaminen pysyy hallitsemallasi tavalla.

• Käytä API-todennusta (esimerkiksi OAuth 2.0 tai JWT) ja nimettyjä tunnuksia.
• Ota käyttöön erilliset integraatiokäyttäjät PoLP-käyttöoikeusjoukoilla, jotta kunkin integraation käyttöoikeudet on rajoitettu ja niitä voi tarkastaa erikseen ihmiskäyttäjiltä.
• Suojaa päätepisteet ja ulkoisen järjestelmän vahvistus.

• Käytä Event Monitoring-, Audit Trails- ja Security Information and Event Management (SIEM) -integraatioita.
• Noudata vahinkotapahtumien vastausmenetelmiä ja tietoturvatarkistuksia.

• Käytä suojattuja mukautettuja koodeja (esimerkiksi Apex tai Lightning) ja syötettyjen tietojen vahvistusta.
• Suorita Apex käyttäjätilassa, jotta objektien, kenttien ja jako-oikeudet noudatetaan koodissa.
• Noudata injektioiden ehkäisyä ja turvallisia kehitystapoja.

• Ylläpidä ratkaisujen vaatimustenmukaisuutta.
• Noudata yksityisyys-/suostumusten hallinta- ja datan säilytyskäytäntöjä.

Jotkin vastuut vaativat yhteistyötä:

• Turvallisuusvahinkotapahtuman vastaus: Molemmat osapuolet osallistuvat havainto- ja vastaustoimintoihin.
• Haavoittuvuuksien hallinta: Salesforce korjaa sovellusalustan, arkkitehtit korjaavat mukautetun koodin.
• Turvallisuuden valvonta: Yhdistä sovellusalustan luomat suojaussignaalit arkkitehtuurin analyysiin.
• Yhteensopivuustodistukset: Salesforce sertifioi sovellusalustan (esimerkiksi SOC, ISO ja FedRAMP Government Cloudille); arkkitehtit omistavat sen perustana olevat objektit — mukautetut objektit, koodit, integraatiot ja kokoonpanot — sertifioidun tilan sisällä todistaakseen vaatimustenmukaisuuden auditointia varten.
• Identiteetin liitos: Salesforce luottaa arkkitehtuurin henkilöllisyydentarjoajan esittämiin vahvistuksiin. Arkkitehtit ylläpitävät tarjoajan ja tarjoajan ja Salesforcen välistä Trust-suhdetta.
• Avainten hallinta: Salesforce käyttää Bring Your Own Key -salausta käyttääkseen salauspalvelua, kun taas arkkitehtit luovat, kierrättävät ja mitätöivät datan suojaavan avainmateriaalin.

Jokainen tämän asiakirjan suunnitteluperiaate, aiheosio ja tarkistusluettelokohde edustaa arkkitehtuurin vastuuta. Jaetun vastuun malli kuvaa, mitä sinun täytyy suunnitella ja määrittää luodaksesi Trustia Salesforce Platformissa.

Rajoitus kattaa myös lakisääteiset velvollisuudet. Salesforce ylläpitää sovellusalustan sertifikaatteja ja sertifikaatteja ja suojaa infrastruktuurin rikkomuksilta. Arkkitehdit ovat vastuussa datasi ja toimivaltasi koskevista velvollisuuksista (esimerkiksi: mitä lakeja sovelletaan, miten tietoja luokitellaan, mitä säilytysaikoja ja suostumuksia säännellään ja miten havaitset ja raportoit rikkomuksia hallitsemastasi datasta). Käyttöönottojesi säännösten vastaisesti arkkitehtien täytyy määrittää kyseisten velvollisuuksien (esimerkiksi säilytysaikojen ja ilmoitusten määräajat) taustalla olevat tiedot käyttöönottosi säännösten perusteella, koska ne saattavat vaihdella lainkäyttöalueen mukaan ja muuttua ajan myötä.

Käytä näitä periaatteita opastaaksesi sovellusalustan tietoturvaa koskevia arkkitehtonisia päätöksiä.

• Ota nolla Trust käyttöön kaikissa kerroksissa. Älä koskaan oleta Trust verkkosijainnin, käyttäjien tuttuuden tai järjestelmän alkuperän perusteella. Vahvista jokainen käyttöoikeuspyyntö erikseen tietojen, sovellusten, integraatioiden ja infrastruktuuritasojen todennuksella, valtuutuksella ja salauksella. Usean vuokralaisen arkkitehtuuri tarkoittaa, että jaat infrastruktuurin tuhansien organisaatioiden kanssa, joten verkosto, jolla ratkaisusi toimii, ei ole alue, jota voit pitää luotettuna. Vahvista jokainen pyyntö sen omien arvojen perusteella — eli henkilöllisyyden, valtuutuksen ja kontekstin perusteella — sen sijaan, että luottaisit siihen sen alkuperästä.
• Myönnä oletusarvoisesti vähiten käyttöoikeuksia. Myönnä käyttäjille, integraatioille ja automatisoiduille prosesseille niiden käyttötarkoituksen saavuttamiseksi tarvittava käyttöoikeustaso. Aloita rajoittavimmilla asetuksilla — eli yksityisillä organisaationlaajuisilla oletusasetuksilla (OWD) ja vähimmäiskäyttöoikeuksilla — ja laajenna niitä tarkoituksellisesti dokumentoitujen liiketoimintavaatimusten perusteella. Käytä nelikerroksista käyttöoikeusmallia (organisaatio → objekti → kenttä → tietue), jotta jokainen kerros rajoittaa yllä olevia kerroksia tarkemmin.
• Toteuta puolustus syvällisesti. Kerro useita suojausasetuksia, jotta yhden ohjaimen virhe ei vaaranna koko järjestelmää. Yhdistä ennaltaehkäisevät ohjaimet (esimerkiksi CRUD/FLS-vaatimusten ja transaktioiden suojauskäytännöt, jotka estävät toiminnot), detektiiviset ohjaimet (esimerkiksi Event Monitoring) ja interaktiiviset ohjaimet (esimerkiksi transaktioiden suojauksen vaiheittainen todennus ja ilmoitus). Suunnittele jokainen kerros niin kuin sen vieressä olevat kerrokset saattaisivat epäonnistua. Muista, että kenttätason suojaus suojaa dataa, vaikka jakosäännöt olisivat liian sallittuja.
• Integroi tietoturva suunnittelun mukaan. Integroi uhkien mallinnus, tietoturvavaatimukset ja hallitse vahvistusta arkkitehtuurin kaikkiin vaiheisiin alustavaan käsitykseen jatkuvaan kehitykseen. Suorita Spoofing-, Tampering-, Repudiation-, Information Disclosure-, Denial of Service- ja Elevation of Privilege (STRIDE) -uhkien mallinnus ennen rakentamisen aloittamista. Tietoturva määrittää teknologian valinnan ja suunnittelupäätökset.
• Upotettu tietoturva automaatioon. Rakenna suojausasetuksia automatisoituihin myyntiputkeihin, kokoonpanomalleihin ja sovellusalustan oletusasetuksiin. Salesforce-koodin analysoija CI/CD:ssä havaitsee haavoittuvuudet ennen käyttöönottoa. Configuration-as-code noudattaa tietoturvan perustasoja. Upotettu tietoturva varmistaa yhdenmukaisuuden ja sallii tietoturvan skaalautua ratkaisun monimutkaisuuden mukaan.
• Suunnitellaan yksityisyyttä varten. Lisää tietoturvakäytäntöjä alustavaan arkkitehtuurin vaiheeseen. Suunnittelu datan minimointiin (kerää vain tarvittavat tiedot), käyttötarkoituksen rajoittamiseen (rajaa käyttöoikeudet työtehtävien mukaan), suostumusten hallintaan (pakottaa tarkkoja, käyttötarkoitusta koskevia suostumuksia) ja datan aiheen oikeuksiin (salli käyttöoikeuksien, korjausten, poistamisen ja siirrettävien työnkulkujen suorittaminen lakisääteisten aikajanojen mukaisesti).
• Suunnittelu jäljitettävyydelle. Tee jokaisesta seuraavasta toiminnosta kohdistettavissa ja rakennettavaksi faktan jälkeen ennen kuin luotat sen poikkeavuuksien havaitsemiseen. Varmista, että datan, käyttöoikeuksien ja kokoonpanon muutokset tallennetaan kirjausketjuihin, kenttähistoriaan ja tapahtumalokeihin, ja säilytä kyseiset tietueet peukaloimattomassa tallennustilassa. Seurattavuus on havainnon, valvonnan ja vastuullisuuden edellytys. Muista — et voi tutkia, mitä ei koskaan tallennettu.
• Suunnittelu vahinkotapahtumien vastaukselle. Suunnittelu havaittavuutta varten tapahtumien valvonnan kautta ja reaaliaikaista interventiota varten transaktioiden suojauskäytäntöjen avulla. Ota käyttöön nopeat vastaukset dokumentoitujen toimenpiteiden ja eristysrajoitusten avulla. Tukee palautusta varmuuskopiointivaihtoehtojen ja valvontakäsittelyn avulla. Testaa vastauksia työpöytäharjoituksilla ja rikkomusten simuloinneilla.

Arkkitehdit ovat vastuussa ratkaisujen suojaamisesta Salesforcen tarjoamalla alustalla.

Salesforcen kanssa vuorovaikuttavat työkuormat suoritetaan yhä useammin ydinsovellusalustan ulkopuolella — integrointipalvelut, mukautetut sovellukset ja headless-asiakkaat kutsuvat usein Salesforce API -rajapintoja, usein käyttäjän puolesta. Salesforce paljastaa sovellusalustan ominaisuudet API-rajapintoina, työkaluina ja komentoina (esimerkiksi Salesforce Headless 360). Riippumatta siitä, kuka käyttää näitä sovelluksia, arkkitehti omistaa Trust rajan, jossa hän tapaa Salesforcen määrittääkseen, miten hän todentaa itsensä, mitä identiteettiä ja käyttöoikeuksia hänellä on, mitä salaisuuksia hänellä on ja mitä tietoja rajat ylittävät.

Alla kuvattuja periaatteita sovelletaan mihin tahansa säiliöön perustuvaan integraatioalustaan (esimerkiksi MuleSoft CloudHub).

Kun ulkoinen asiakassovellus todentaa itsensä nimetyksi käyttäjäksi, Salesforcen sovellusalustan suojausmalli otetaan automaattisesti käyttöön — objektien käyttöoikeudet, kenttätason suojaus ja jakosäännöt noudatetaan samalla tavalla kuin selaimessa. Käyttäjäkohtainen todennus kattaa kaikki kyseisen yksityishenkilön käyttöoikeuksiin tehdyt kutsut ja säilyttää kirjausketjun, mikä tarkoittaa, että käyttäjän valtuuden kumoaminen välittömästi poistaa asiakassovelluksen kyvyn toimia heidän puolestaan. Pidä tätä mieluummin jaetun palvelun tilin sijaan, kun työ tehdään tietylle käyttäjälle.

Suunnittele raja puolustuksellisesti, koska useille käyttäjille valtuuksia sisältävä asiakassovellus keskittää Trustin ja muuttuu hyökkääjälle arvokkaaksi välityspalvelimeksi: Yksi varastettu OAuth-valtuus voi käyttää kaikkien asiakassovelluksen tarjoamien käyttäjien tietoja. Tämä ei ole oletusarvoista. Salesloft Drift -tapahtumassa vuonna 2025 hyökkääjät varasivat OAuth-valtuuksia ja käyttävät niitä päästäkseen käsiksi Salesforce-dataan sadoissa organisaatioissa.

• Lisää käyttäjän identiteetti, älä yhdistä sitä. Käytä käyttäjäkohtaista todennusta tai OAuth 2.0 -valtuuden vaihtoa siirtääksesi käyttäjän henkilöllisyyden eri palveluiden välillä (katso lisätietoja kohdasta Agent Identity ja todennus), jotta kompromissit rajoittuvat yhden käyttäjän asiayhteyteen kaikkien käyttäjien sijaan.
• Käsittele OAuth-asiakassovelluksen tunnuksia ja päivitysvaltuuksia ensisijaisena kohteena. Tallenna ne hallittuun salaisuuksien myymälään, kierrä ne usein ja ylläpidä suunnitelmia välittömästi kumottavaksi. Valvo API:n käyttöä poikkeavien kuvioiden varalta, jotka osoittavat välityspalvelimen hyökkääjälle.
• Minimoi vaikutusalue molemmilla puolilla. Rajoita Ulkoisen asiakassovelluksen (ECA) OAuth-vaikutusalueet ja integraatiokäyttäjän Salesforce-käyttöoikeudet toiminnon vaatimiin vähimmäismääriin, jotta vaarantunut asiakassovellus ei voi siirtyä asiaankuuluvaan dataan.
• Rajoituksen hallinta ulkoisten asiakassovellusten kautta. ECAs määrittävät, miten ulkoinen sovellus todentaa itsensä, mitkä kulut ovat sallittuja ja mitä vaikutusalueita sovelletaan – suunnittele heille uusia integraatioita (lisätietoja on kohdassa Todennusarkkitehtuuri).

Ole varovainen, jos asiakassovellus suoritetaan agenttikäyttäjänä tai integraatiokäyttäjänä: nämä identiteetit voivat toimia korkeassa kontekstissa — usein ulkoisia järjestelmiä vastaan, jotka eivät noudata Salesforcen käyttöoikeusasetuksia — joten yllä kuvatun käyttöoikeus- ja valvontasuunnitelman käyttäminen pitää sen voimassa.

Kun integraatiot suoritetaan säiliöalustassa, säiliötason eristämistä pidetään itsessään tietoturvatoimenpiteenä: jokainen sovellus suoritetaan erillisessä säiliössä, jossa sovellusten välillä ei ole jaettu suoritusaikaa tai muistia.

Tämä eristys tarjoaa:

• Työnantajan rajojen rajoitus: Vaarantuneet sovellukset eivät voi käyttää dataa tai resursseja samassa ympäristössä olevista naapurisovelluksista. Jokaisella säiliöllä on erillinen tiedostojärjestelmä ja prosessitila. Noudata verkoston eristämistä palomuurin ja TLS-kokoonpanon avulla ja rajoita lähtevää liikennettä erikseen sen sijaan, että luottaisit sallittuihin oletusasetuksiin.
• Syvällinen puolustus: Säiliöiden eristys lisää suojauskerroksen sovellustason hallintojen ulkopuolelle. Vaikka sovelluksen koodissa olisi haavoittuvuuksia, säiliöiden rajat rajoittavat räjähdyksen sädettä.
• Yhteensopivuuden segmentointi: Säännellyt työkuormat (esimerkiksi PCI ja HIPAA) voidaan eristää erillisissä säiliöissä, mikä estää yhteensopimattomien työkuormien yhdistämisen.

Usean sovelluksen ympäristöjä suunnittelevien arkkitehtien täytyy luottaa säiliöiden eristämiseen tehtävien ja suojauksen toimialueiden erottamiseksi toisistaan. Kortin omistajan tietoja käsittelevien finanssipalveluiden integraatioiden täytyy toimia erillisissä säiliöissä markkinointiintegraatioista, jopa samassa ympäristössä.

Säiliöiden välinen liikenne tulisi salata ja yhteistä TLS-palvelua (mTLS) tulisi käyttää, kun sääntelykehys vaatii todennusta molemmin puolin:

Miten se toimii:

• Määritä TLS-konteksti ottaaksesi valinnaisen yhteisen TLS:n (mTLS) käyttöön saapuville yhteyksille tarvittaessa.
• Käytä sovellusalustan tason SSL-protokollaa asiakassertifikaattien todennuksella suojellaksesi sovellusalustan palveluiden ja replikoiden välistä viestintää.
• Määritä TLS-konteksti ottaaksesi mTLS:n käyttöön tarvittaessa sääntelykehyksissä.
• Hallitse sertifikaatteja sovellusalustan sertifikaattien myymälän kautta, jotta niiden elinkaari ja peruutukset pysyvät keskitetyinä.
• Noudata verkkojen eristysrajoituksia, jotka estävät säiliöiden välisen valtuuttamattoman liikenteen.

Sovellusalustan kerroksessa olevan liikenteen salaaminen tarjoaa syvällisiä tietoja datan siirrosta. Vaikka sovellustason HTTPS-protokolla olisi määritetty väärin, säiliöliikenne pysyy salattuna.

Säiliöiden, jotka muodostavat yhteyden paikallisiin järjestelmiin VPN:n kautta, täytyy rakentaa arkkitehtuuri tietojen siirtämisen suojaamiseksi:

• Tunnelin salaus: Reititä kaikki säiliöiden ja paikallisten järjestelmien välinen liikenne salatun VPN-tunnelin kautta. Tämä koskee sovellustason TLS:ää riippumatta. Syvällinen puolustus varmistaa, että luottamukselliset tiedot salataan kahdesti.
• Verkon segmentoinnin noudattaminen: VPN-tunnelien käytännöt rajoittavat, mihin paikallisiin verkkoihin säiliöt voivat päästä. Vaarantuneet säiliöt eivät voi siirtyä valtuuttamattomiin sisäisiin järjestelmiin VPN:n sallimien verkkojen ulkopuolella.
• Yhteensopivuustodistus: VPN-salaus on hyväksytty mekanismi, jolla voidaan suojata dataa, joka siirretään pilviympäristöihin ja niistä. HIPAA-, PCI-DSS- tai SOX -ohjaimet tarkastavat auditoijat odottavat, että hybridien integraatioiden salaus on dokumentoitu siirrettäessä.

Arkkitehtien täytyy suunnitella VPN-käytäntöjä, jotka käyttävät vähiten etuoikeutettua verkkoa. Markkinointiintegraation säiliöitä ei tulisi reitittää sisäisille rahoitusjärjestelmille, vaikka molemmat olisivat käytettävissä VPN:n kautta.

Tyhjät toimialueet (esimerkiksi integraation API-rajapintojen mukautetut URL-osoitteet) vaativat, että arkkitehdit hallitsevat TLS-sertifikaatteja luotettuina Trust

Tyhjät toimialueet (esimerkiksi integraation API-rajapintojen mukautetut URL-osoitteet) vaativat, että arkkitehdit hallitsevat TLS-sertifikaatteja luotettuina Trust.

• Sertifikaattien elinkaaren automatisointi: Ota sertifikaattien automatisoitu uusiminen ja käyttöönotto käyttöön. Vanhentuneet sertifikaatit rikkovat integraation Trustin. Asiakkaat hylkäävät yhteydet, joilla on sertifikaatin vahvistusvirheitä.
• Sertifikaatin kumoamisen suunnittelu: Suunnittele sertifikaattien kierrättäminen tietoturvahyökkäyksille. Vaarantuneet yksityiset avaimet vaativat sertifikaattien nopean uudelleen myöntämisen ja käyttöönoton kaikilla alueilla.
• Sarjojen sarjan kokoonpano: Vanhat TLS-kokoonpanot (TLS 1.0/1.1 ja heikot salaukset) epäonnistuvat vaatimustenmukaisuuden auditoinneissa. Noudata TLS 1.2+-protokollaa (minimivaatimus) ja kohdista sertifikaattien ja asiakassovellusten kokoonpanot organisaation suojauskäytäntöihin.
• Sertifikaattien läpinäkyvyyden kirjaaminen: Modernit TLS-sertifikaatit lähetetään julkisiin sertifikaatin läpinäkyvyyslokeihin (CT) sertifikaatin myöntäjien toimesta. Jokainen CT-loki palauttaa Allekirjoitettu sertifikaatin aikaleiman (SCT), joka on salaustodistus lokiin tallentamisesta ja jonka CA upottaa sertifikaattiin X.509v3-laajennuksen kautta. Arkkitehtien tulisi valvoa CT-lokien luvatonta sertifikaatin myöntämistä toimialueilleen käyttämällä palveluita, kuten crt.sh tai automatisoitua hälytystä.

Sertifikaattien virheellinen hallinta vaikuttaa suoraan Trust asemaan:

• Vanhentuneet sertifikaatit: Aiheuttaa todennusvirheitä, jotka näytetään käyttökatkoksina. Valvonnan täytyy sisältää hälytysten lähettäminen yli 30 päivää ennen vanhenemista, jotta uusintatyönkulut voivat alkaa.
• ** Itse allekirjoitetut sertifikaatit:** Katkaise ulkoisten asiakkaiden Trust. Tuotanto-integraatiot vaativat sertifikaatteja, jotka ovat allekirjoittaneet luotetut sertifikaatin myöntäjät (CA).
• Wildcard-sertifikaatin laajentaminen: Viittaa liian leveisiin yleismerkkisertifikaatteihin (esimerkiksi *.company.com), jotka luovat suuren räjähdyssäteen, jos ne vaarantuvat. Kapea-alueisia sertifikaatteja suositaan per integraation toimialue.

Säiliöiden käyttöönottoryhmien täytyy noudattaa datan sijainti- ja vaatimustenmukaisuusvaatimuksia.

• GDPR-tietojen residenssi: GDPR vaatii riittävää suojausta henkilötiedoille, jotka lähtevät Euroopan unionista (EU), mutta ei EU:n käyttöönotosta sellaisenaan. Integraatioiden käyttöönotto EU-alueella pitää säiliötietojen ja tietojen käsittelyn säännösten rajoissa, mikä on suora tapa täyttää tämä vaatimus. EU:n ulkopuolella tapahtuvat siirrot ovat edelleen sallittuja riittävyyttä koskevan päätöksen, vakiosopimuslausekkeiden (SCC) tai sitovien yrityssääntöjen (BCR) perusteella.
• Datan lokalisointisäännöt: Tietojen lokalisointivaatimuksia käyttävät maat ovat: Venäjä (Federal Law 152-FZ ja pakollinen tallennus) ja Kiina (PIPL/CSL CIIOs), jotka saattavat vaatia säiliöiden käyttöönottoa maassa. Intian DPDP-laki vuodelta 2023 käyttää mustaluettelon lähestymistapaa, joka ei määritä yleistä maiden sisäistä tallennustilaa. Tietojen siirrot ovat sallittuja mihin tahansa maahan, ellei sitä ole rajoitettu erikseen hallituksen ilmoituksella. Arkkitehtien täytyy ymmärtää lainkäyttöalueisiin liittyvät säännökset.
• Rajojen väliset datan siirtojärjestelmät: Kun tarvitaan monialueellista käyttöönottoa, mutta datan täytyy ylittää rajat, arkkitehtien täytyy ottaa käyttöön SCC- tai piilokopiointijärjestelmät tai muut lakisääteiset siirtomekanismit.
• Yhteensopivuuden sertifikaatin kohdistus: Säiliöiden käyttöönottoryhmien täytyy vastata Salesforcen vaatimustenmukaisuussertifikaatteja. FedRAMP:n valtuuttamat työkuormat vaativat yhdysvaltalaisen alueellisen käyttöönoton. Jos käytät HITRUST-sertifioituja integraatioita, sinun täytyy varmistaa, että käyttöönottoalue kuuluu aktiivisen HITRUST-vahvistuksen vaikutusalueeseen.

Alueellisten käyttöönottojen päätökset ovat arkkitehtien vastuulla, jotka vaikuttavat suoraan säännösten noudattamiseen. Finanssitiimit voivat vaatia vain Yhdysvaltojen käyttöönottoa SOX-ohjaamille integraatioille. Terveydenhuollon tiimit saattavat vaatia HITRUST-sertifioituja alueita henkilökohtaisten terveystietojen (PHI) käsittelyyn.

Säiliöt vaativat käyttöoikeuden tunnuksiin, API-avaimiin ja salausavaimiin. Arkkitehtien täytyy suunnitella salaisuuksien hallintaprosesseja, jotka estävät altistumisen:

• Ei kovakoodattuja salaisuuksia: Älä koskaan upota tunnuksia sovelluksen koodiin tai kokoonpanotiedostoihin, jotka on otettu käyttöön säiliöissä. Käytä sovellusalustan hallitsemia salaisuuksien myymälöitä.
• Salaisuuden sovellusalustan hallitsema injektio: Ratkaise salaisuudet suorituksen aikana sovellusalustan hallitusta myymälästä (enkä säilytä niitä tiedostojärjestelmässä) ja merkitse kokoonpanoarvot, joissa tunnukset on suojattu, niin että niitä ei näytetä lokeissa tai konsolissa.
• Salaisuuksien kierrättäminen: Suunnittele integraatiot käsitelläksesi kierrätettyjä salaisuuksia tarkasti. OAuth-valtuuksien päivityskuvioiden, API-avainten kierrätyksen työnkulkujen ja tietokannan salasanan muutosten ei tarvitse vaatia säiliöiden uudelleenkäyttöä.
• Pienin käyttöoikeus salaisuuksille: Myönnä säiliöille käyttöoikeus vain heidän tehtäväänsä vaadittuihin salaisuuksiin. Markkinointiintegraatioiden ei tulisi käyttää finanssijärjestelmän tunnuksia, vaikka ne olisivat samassa ympäristössä.

Paljastetut salaisuudet ovat yleisiä integraation suojaustapahtumia. Arkkitehtien täytyy suunnitella salaisuuksien käsittelyprosesseja, jotka voivat säilyttää koodin tarkastukset, lokit, virheviestit ja mittaristojen valvonnan ilman tunnusten vuotoa.

Salesforce-rajan sovellukset luovat auditointitapahtumia, jotka täyttävät vaatimukset vaatimustenmukaisuuden kirjaamiseksi lokiin:

• Pyyntöjen/vastausten kirjaaminen: Kirjaa API-pyynnöt, vastaukset ja reitityspäätökset lokiin. Vaatimustenmukaisuustiimit käyttävät näitä lokeja käyttöoikeustarkastuksissa määrittääkseen, kuka käytti mitä tietoja milloin.
• Virheiden ja poikkeusten kirjaaminen: Tallentaa säiliön lokien suojaustapahtumat (esimerkiksi todennusvirheet, hylätyt valtuutukset ja virheelliset sertifikaatit). SIEM-integraatio sallii reaaliaikaisen tietoturvan valvonnan.
• Lokien säilytyskäytännöt: Arkkitehtien täytyy määrittää säilytysajat, jotka täyttävät lakisääteiset vaatimukset. Nämä vähimmäisvaatimukset on määritetty säännöksellä, ne vaihtelevat kehysjärjestelmän mukaan ja ne muuttuvat ajan myötä, joten niiden täytyy johtaa hyvin ylläpidetyistä vaatimustenmukaisuuden lähteistä, jotka vahvistavat jokaisen luvun säännösten mukaisesti kovakoodattavien arvojen sijaan.
• Lokien salauksen ja käyttöoikeuksien ohjaimet: Auditointilokit saattavat sisältää luottamuksellista metadataa. Lokit täytyy salata paikallisesti ja niiden käyttöoikeudet täytyy hallita vain valtuutetulle tietoturva- ja vaatimustenmukaisuushenkilöstölle. Riittämätön kirjaaminen estää vahinkotapahtumien tutkimisen ja epäonnistuu vaatimustenmukaisuuden auditoinneissa. Arkkitehtien täytyy tasapainottaa lokien kirjaaminen (esimerkiksi suorituskyvyn vaikutus ja tallennuskustannukset) vaatimustenmukaisuuden ja tietoturvan tutkimisen tarpeisiin nähden.

Uhkien mallinnuksen täytyy olla osa ratkaisujesi suunnittelua, eikä erillistä ennen tai jälkeen tapahtuvaa vaihetta. Kun sinulla on ehdokassuunnitelma, josta voit pohtia, sinun täytyy mallinntaa sen mahdolliset uhat — ja tutkia malli uudelleen, kun se kehittyy, joten tietoturva muokkaa arkkitehtuuria sen sijaan, että sitä mukautettaisiin uudelleen. Vaikka Salesforce hallitsee infrastruktuurin tietoturvaa (esimerkiksi verkon suojausta, käyttöjärjestelmän koventamista ja haavoittuvuuksien hallintaa), sinun täytyy tunnistaa sovellustason riskit kokoonpanossasi, integraatioissasi ja mukautetussa koodissasi. Sovella STRIDE-kehystä (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) Salesforce-kohtaisiin uhkien vektoreihin, jotka on lueteltu alla. Tunnista Trust rajat, joissa data ylittää järjestelmät, verkot tai käyttöoikeustasot.

Sovella STRIDE-kehystä näihin Salesforcelle tarkoitettuihin uhkien mallinnuksessa huomioitaviin asioihin:

• Monien organisaatioiden datakulut luovat lisää Trust-rajoja, jotka vaativat erillisen todennuksen ja valtuutuksen jokaisella ylityksellä.
• Ulkoiset integraatiot käyttävät API-rajapintoja ja välitysohjelmistoja, mikä saattaa johtaa hyökkäysvektoreihin, jotka ohittavat sovellusalustan suojausasetukset.
• Mukautetut Apex- ja Lightning-komponentit vaativat suojattua koodausanalyysiä injektio-, XSS- ja käyttöoikeuksien valvontaa varten.
• Experience Cloud -sivustot laajentavat hyökkäysalueen todentamattomille tai helposti todennetuille käyttäjille.
• Kolmansien osapuolten koodi ja ISV-koodi (esimerkiksi hallitut paketit, AgentExchange-listat, yhdistetyt sovellukset, kolmansien osapuolten liittimet, asiakaspuolen JavaScript-kirjastot ja ulkoiset tekoälypalvelut, joita agenttisi kutsuvat) on toimitusketjuvektori, joka ylittää Trust-rajan asennuksen aikana tai suorituksen aikana.

Kolmansien osapuolten ja ISV-koodit ovat osa Trust-rajoitustasi.

Hallitut paketit tai AgentExchange-viiteluettelot suoritetaan organisaatiossasi niille myöntämilläsi käyttöoikeuksilla, joten niiden suojausasetuksesta tulee tietoturvasi, kun asennat ne. Salesforce-suojaustarkastus tarkastaa jokaisen paketin ennen kuin se saapuu AppExchangeen tai AgentExchangeen. Omistat kaiken tämän portin jälkeen:

• Paketin arvioiminen omien tietojen luokittelun ja riskien suhteen
• Myöntää sille vähiten käyttöoikeuksia, joita sen dokumentoitu toiminto vaatii
• Pidä se ajan tasalla julkaisijan julkaisujen avulla
• Voit myös valvoa sen toimintoja käyttämällä samoja Event Monitoring- ja Audit-ohjaimia, joita käytät omalle koodillesi.

Käytä suojausasetuksia ratkaisupalkin jokaiselle kerrokselle. Pidä mielessäsi, että yhden kerroksen ohittaminen ei saa paljastaa koko järjestelmää.

Suunnittele jokainen kerros niin kuin ylä- ja alakerrokset saattaisivat epäonnistua. Muista, että useat itsenäiset ohjaimet parantavat kestävyyttä.

Nollatason Trust estää epäsuoran Trust verkon sijainnin tai aiemman todennuksen tilan perusteella. Jokaisen pyynnön täytyy olla itsenäisesti todennettu ja valtuutettu.

Nollaa Trust seuraaviin kohteisiin:

• Käyttäjien käyttöoikeudet jatkuvalla vahvistuksella MFA:lla, istuntokäytännöillä ja ehdollisella käyttöoikeudella asiayhteyden perusteella (esimerkiksi IP, laite, aika ja toimintatapa)
• Integroi yhteydet jokaisen kutsun OAuth-valtuuden vahvistuksen kautta, sertifikaatteihin perustuva yhteinen TLS ja IP-allowlisting
• Järjestelmän välinen viestintä suoran todennuksen kautta, joka koskee myös luotettuja sisäisiä järjestelmiä
• Datan käyttöoikeudet CRUD- ja FLS-vahvistuksen kautta kaikille kyselyille ja operaatioille riippumatta puhelun asiayhteydestä

Suojausresurssien inventaario on tietoturvasuunnittelun input-arvo: Voit käyttää vain uhkakuvien mallia, käyttää vähiten käyttöoikeuksia ja valvoa ensin luetteloitua hyökkäyspinta-alaa, joten tietoturvaan liittyvien omaisuuksiesi seuraaminen kuuluu siihen kuuluviin suunnittelupäätöihin. Tämä on erillään operatiivisen kokoonpanon hallinnasta, jota Operational Excellence kattaa (esimerkiksi organisaation versiointiasetusten ja kokoonpanon kaatumisen havaitseminen toimintavakautta varten). Toisin sanoen huolenaihe on suppeampi: mitkä omaisuudet aiheuttavat tietoturvariskejä ja miksi?

Ylläpidä ajankohtaista inventaariota kaikista tietoturvaan liittyvistä omaisuuksista, mukaan lukien mukautetut objektit, joihin sisältyy luottamuksellisia tietoja, ulkoisten järjestelmien integraatiot, julkiset API-rajapinnat, etuoikeutetut tilit, tuotanto-käyttöoikeuksien myönnytykset ja asennetut paketit, joilla on korkeammat käyttöoikeudet.

Suojausresurssiesi inventaarioon tulisi sisältyä:

• Mukautetut objektit ja kentät, jotka sisältävät luottamuksellisia tai rajoitettuja tietoja
• Integraation päätepisteet ja todennusmekanismit
• Käyttäjät, joilla on korkeat käyttöoikeudet (esimerkiksi kaikkien tietojen muokkausoikeus, kaikkien tietojen tarkasteluoikeus ja käyttäjien hallintaoikeus)
• Vain API -integrointikäyttäjät ja niiden käyttöoikeudet
• Ulkoiset asiakassovellukset (ECA) ja niiden OAuth-vaikutusalueet sekä kaikki organisaatiossa edelleen olevat yhdistetyt vanhat sovellukset
• Asennetut AgentExchange-paketit ja niiden käyttöoikeudet
• Experience Cloud -sivustot ja niiden todennus- ja ulkoiset jakomallit
• Mukautetut Apex ja parannetut jakotilat
• Kiinnitä erityistä huomiota vanhoihin luokkiin: API-versiossa 66.0 tai sitä vanhemmalla koodi, joka ohittaa jakolausekkeen, palauttaa oletusarvoisesti arvon "ilman jakamista" (esimerkiksi järjestelmätila, joka ohittaa suorittavan käyttäjän tietueen käyttöoikeuden). Pidä mielessäsi, että API-versiosta 67.0 (Summer '26) ohitettu lauseke palauttaa oletusarvoisesti arvon ”jaettu” ja tietokantaoperaatiot suoritetaan käyttäjätilassa. Olemassa olevat luokat säilyttävät kuitenkin vanhan toimintatavan, kunnes ne on koottu uudelleen versiossa 67.0 (tai uudempana) — joten aiemmista versioista siirrettyjen ilmoittamattomien luokkien arvo pysyy hiljaa korotettuna.

Sinun vastuullasi on suunnitella ja määrittää henkilöllisyyden hallintaohjelmia, jotka käyttävät vähiten käyttöoikeuksia.

Nyt tutustumme tarkemmin siihen, miten voit suunnitella ja määrittää ohjaimia oikein PoLP:n avulla.

Salesforce käyttää käyttöoikeuksien hallintaa neljän eri kerroksen kautta: organisaatio, objekti, kenttä ja tietue. Sinun täytyy suunnitella ratkaisuja, jotka hyödyntävät kaikkia neljää kerroksia tarkoituksella. Ydinkäyttöoikeuksien hallinta perustuu myöntämiseen, mikä tarkoittaa, että käyttöoikeus on additiivinen, ja käyttäjille täytyy myöntää se joka kerros päästäkseen tietueeseen. Ydinsovellusalustalla ei ole yleistä "hylkää korvaukset sallittu" -sääntöä, joten et voi käyttää kohdennettua hylkäämistä kumotaksesi käyttöoikeuden jo myönnettyyn laaja-alaiseen myöntöön.

sallitut korkeammat kerrokset eivät maksa rajoitusta, mutta ne kasvattavat vaivaa: Organisaationlaajuisten oletusasetusten tai objektien käyttöoikeuksien laajentaminen ajoissa tarkoittaa, että voit luottaa kenttätason suojaukseen ja jakokokoonpanoon estääksesi käyttöoikeuksia, joita ei olisi koskaan pitänyt myöntää.

Rajoitussäännöt ja mykistävät käyttöoikeudet ovat kaksi sisäänrakennettua poikkeusta, jotka vähentävät käyttöoikeuksia, mutta ne on rajoitettu rajoitetusti — rajoitussäännöt tietueen tason suodattamiseen ja mykistäminen käyttöoikeusjoukkoryhmässä myönnettyihin käyttöoikeuksiin — eivät yleistä hylkäämiskerrosta.

Määritä luottamuksellisia tietoja sisältävien objektien OWD-arvoon Yksityinen. OWD-tietueiden avaaminen Julkinen vain luku -tilaan — puhumattakaan Julkinen luku/kirjoitus — paljastaa tietueet laajasti ja heikentää kykyäsi rajoittaa käyttöoikeuksia myöhemmin ilman mahdollisesti merkittävää uudelleenrakennusta. Yleisin Trust kypsissä organisaatioissa johtuu sallituista OWD-arvoista, jotka on määritetty ensimmäisen käyttöönoton aikana.

Tietuakerros noudattaa grant-then-restrict-mallia, jota kuvataan usein jako-pyramidina: OWD:t määrittävät rajoittavien perustasojen ja roolihierarkian, jakosäännöt ja manuaalisen jaon avoimet käyttöoikeudet ylöspäin. Kaksi ohjainta kääntävät kulun ottamaan käyttöoikeuden pois sen sijaan, että myöntäisivät sen, ja molemmat kannattaa suunnitella tarkoituksella.

• Rajoitussäännöt suodattavat, mitä käyttäjät voivat nähdä tietueissa, joihin heillä on jo käyttöoikeus, joten käyttäjät, joilla on laaja objektien käyttöoikeus, näkevät edelleen vain säännön sallimat osajoukot.
• Piilotettavien käyttöoikeuksien mykistäminen vähentää käyttöoikeusjoukkoryhmän tiettyjä käyttöoikeuksia, jotta voit kerätä käyttöoikeuksia uudelleenkäytettävistä ryhmistä ja poistaa sitten tietoja, joita tietyllä populaatiolla ei tulisi olla.
• Noudata näitä sääntöjä, kun vain apurahapohjaiset kerrokset pakottaisivat sinut joko liialliseen provisiointiin tai käyttöoikeuksien pilkkomiseen useisiin kapeisiin käyttöoikeusjoukkoihin.

Noudata MFA-todennusta (monimenetelmäinen todennus) kaikille käyttäjille, jotka kirjautuvat tuotantoympäristöihin käyttöliittymän kautta, jonka Salesforce määrittää sovellusalustan vaatimukseksi. Tämä vaatimus ei koske Vain API -käyttöoikeutta: JWT-haltijan tai asiakassovelluksen tunnusten kulkuja käyttävät integraatiot ovat vapautettuja, joten sinun täytyy suojata kyseiset integraatiot sertifikaattien hallinnalla ja IP-rajoituksilla. Laajenna MFA-vaatimuksia koskemaan etuoikeutettuja toimintoja.

SSO-kertakirjautumiselle (kertakirjautuminen) suositaan SAML 2.0- tai OpenID Connect -protokollia. Määritä istuntokäytännöt tasapainottaaksesi tietoturvan ja käytettävyyden:

• Istunnon aikakatkaisu: Määritä istuntojen aikakatkaisut käyttäjien käyttöoikeustasojen mukaisesti (korkean oikeutuksen tilien lyhyemmät aikakatkaisut vähentävät valvomat istunnot aiheuttavia riskejä).
• IP-rajoitukset: Ota rajoitukset käyttöön pääkäyttäjien profiileille ja integraatiokäyttäjille.
• Kirjautumisajat: Rajoita palvelutilit odotettuihin toiminta-aikoihin.
• Laitteen aktivointi: Luota Salesforcen natiivilaitteiden aktivointiin (henkilöllisyydenvahvistus sisäänkirjautumisille tuntemattomista laitteista) ja lisää MFA- ja IP-rajoituksia korkean oikeuden tilille. Laitteen natiivi Trust -asetus noudatetaan ulkoisen henkilöllisyydentarjoajan kautta.
• Ip-istunnon lukitus: Lukitse istunnot IP-osoitteeseen, josta ne ovat peräisin, jotta varastettua istuntotunnusta ei voi toistaa toisesta verkkosijainnista. Tämä tiukentaa tietoturvaa, mutta lisää jännitystä mobiilikäyttäjille ja voi rikkoa automatisoituja integraatioita — jos lukitseminen ei ole mahdollista, noudata tiukkoja sisäänkirjautumisen IP-alueita profiilitasolla käyttämällä korvaavaa asetusta ”Käytä sisäänkirjautumisen IP-alueita jokaiselle pyynnölle”.
• Korkea vahvistus -istunnot: Vaadi istunnon Suuri vahvistus -suojaustaso istunnon suojaustason käytäntöjen ja käyttöoikeuskäytäntöjen avulla luottamuksellisille toiminnoille (kuten raporttien käyttämiseen tai IP-alueiden hallintaan), jotta tavallinen sisäänkirjautuminen ei voi yksinään saavuttaa tehokkaita toimintoja. Lightning Experiencessa ei tueta vakiomuotoisen istunnon nostamista korkeaan vahvistukseen pyytämällä MFA-todennusta uudelleen, joten tämä käytäntö koskee vakiomuotoisen istunnon käyttäjiä, jotka estetään lukitusta toiminnosta sen sijaan, että heitä pyydettäisiin nostamaan sitä.
• Istuntoevästeiden suojaus: Vaadi HttpOnly-attribuutti, jotta komentosarjat eivät voi lukea istunnon tunnusevästeitä, ja lukitse istunnot toimialueeseen, jossa niitä käytettiin ensimmäistä kertaa istunnon kaappauksen estämiseksi.
• Integrointikäyttäjien Vain API -käyttöoikeus: Rajoita integraatio- ja palvelutilit käyttämään Vain API -todennusta Vain API -käyttäjä -käyttöoikeudella, jotta he eivät voi kirjautua sisään käyttöliittymästä. Kohdista uusille kokoonpanoille Minimum Access - API Only Integrations -profiili Salesforce Integration -käyttäjälisenssillä. Vanha Salesforce API Only Systems Integration -profiili ei ole käytettävissä Spring '24 -julkaisusta alkaen provisioiduissa organisaatioissa, joten suunnittele uudet integraatiot nykyisen profiilin perusteella vanhentuneen profiilin sijaan.

Valitse API-todennukselle integraatiokuvioon sopivat OAuth 2.0 -kulut:

• JWT-haltijan kulku: Käytä tätä palvelinpalvelin-integraatioissa, jotka suoritetaan integraatiokäyttäjänä (sertifikaatteihin perustuvat, suositeltu luotetuille ympäristöille).
• Verkkopalvelinkulku (valtuutuskoodi, PKCE): Käytä tätä verkkosovelluksille, jotka vaativat käyttäjän valtuutuksen, ja palvelinpalvelin-integraatioille, joiden täytyy ylläpitää tiettyä käyttäjäkontekstiä (päivitysvaltuuksien säilyttäminen palvelinpuolella välttyäksesi selaimen toistuvilta kehotteilta).
• Valtuutuskoodin kulun toistamisen muuttaminen turvalliseksi: Noudata PKCE-asetusta, jotta kukaan muu kuin sen pyytänyt asiakassovellus ei voi lunastaa kaapattua valtuutuskoodia, ja kierrättää päivitysvaltuuksia — jokaisen käytön yhteydessä annetaan uusi ja edellinen mitätöidään — jotta varastetulla päivitysvaltuudella on kapea voimassaoloaika. Peruutetun valtuuden uudelleenkäyttö vaarantaa signaalien käytön.
• Headless Identity Authorization Code and Credentials -kulku (PKCE:llä): Käytä tätä todennäköisesti headless-asiakassovelluksille, joilla ei ole selainta ja jotka täytyy suorittaa tietyn käyttäjän asiayhteydessä — uudelleenohjaukseen perustuva verkkopalvelinkulku olettaa, että niillä ei ole selainta.
• Laitekulku (headless-laitteille): Huomaa, että 28. elokuuta 2025 alkaen Salesforce on pysyvästi estänyt oletusarvoisen yhdistetyn Salesforce CLI -sovelluksen OAuth 2.0 -laitekulun. Käytä sen sijaan Web Server -kulkua (sf-organisaation sisäänkirjautumissivun verkko) tai JWT Bearer -kulkua (sf-organisaation sisäänkirjautumisen jwt) CLI- ja CI/CD-työkaluille.

Älä käytä Käyttäjänimi/salasana-kulkua. Salesforce on estänyt sen oletusarvoisesti Summer '23 -julkaisussa tai sen jälkeen luoduille organisaatioille ja julkaissut tämän kulun poistosuunnitelmat. Olemassa olevien integraatioiden, jotka edelleen luottavat Käyttäjänimi/salasana-kulkuun, tulisi siirtyä JWT-haltijan kulkuun tai asiakastunnusten kulkuun nyt, eikä käsitellä siirtoa lykättynä teknisenä velkojana.

Nämä kulut määritetään integraatiotasi edustavalle sovelluksen rekisteröinnille. Salesforce siirtää tämän rekisteröinnin yhdistetyistä sovelluksista ulkoisiin asiakassovelluksiin (ECA) Spring '26 -julkaisusta alkaen: uusien yhdistettyjen sovellusten luominen ei ole oletusarvoisesti käytössä, ja ECA on rakenne uusien integraatioiden suunnittelemiseen. Olemassa olevat yhdistetyt sovellukset ovat edelleen asennettuja, mutta kun organisaatio on siirretty, ne eivät käsittele todennusta enää, joten siirto otetaan huomioon, kun tarkastetaan, miten integraatiot todentavat, eikä käsitellä yhdistettyjä sovelluksia pysyväksi malliksi.

Sen lisäksi, että valitset todennuskulun, luo erillinen hallinta, johon sovellukset voivat muodostaa yhteyden:

• Yksi rekisteröinti per integraatio: Rekisteröi jokaiselle uudelle integraatiolle oma Ulkoinen asiakassovellus ja jokaiselle olemassa olevalle erillinen yhdistetty sovellus. Erillinen rekisteröinti, joka kattaa vain kunkin integraation vaatimat OAuth-vaikutusalueet sen sijaan, että se jakaisi yhden laajan rekisteröinnin useille, pitää kunkin integraation käyttöoikeudet itsenäisesti tarkastettavissa ja kumottavissa.
• Esivaltuuta käyttöoikeus erikseen (suositus): Määritä Ulkoisen asiakassovelluksen Sallitut käyttäjät -käytännöksi "Pääkäyttäjän hyväksymät käyttäjät esivaltuutetaan", jotta pääkäyttäjä myöntää käyttöoikeuden profiilien ja käyttöoikeusjoukkojen kautta sen sijaan, että hän antaisi käyttäjien valtuuttaa itsensä. Pääkäyttäjät määrittävät tämän suoraan Määritykset-valikosta, ja Salesforce suosittelee sinua määrittämään, kuka voi muodostaa yhteyden.
• API-käyttöoikeuksien hallinta (kireämpi, sallittujen luetteloihin perustuva): API-käyttöoikeuksien hallinta rajoittaa pääkäyttäjien hyväksymät käyttäjät vain sallittuihin yhdistettyihin sovelluksiin tiukempien asetusten osalta. Sen ottaminen käyttöön vaatii pyynnön Salesforce-asiakastukeen, joten suunnittele kyseinen vaihe, kun suunnittelet sitä sen sijaan, että käsittelisit sitä itsepalvelun asetuksena.

Älä koskaan upota tunnuksia koodiin, kokoonpanotiedostoihin tai versioiden hallintaan. Käytä nimettyjä ja ulkoisia tunnuksia hallitaksesi todennusta keskitetysti kierrätysominaisuuksien avulla.

Toisin kuin perinteinen käyttäjien todennus, agentit tarvitsevat erillisiä identiteettimalleja, ja oikea malli riippuu siitä, tarjoako agentti työntekijöitä vai ulkoisia käyttäjiä. Henkilöllisyyden suunnitteleminen oikein on agenttien tietoturvan perusta: se määrittää, mitä tietoja agentti voi käyttää ja mitä toimintoja hän voi käyttää.

Nyt tutustumme tarkemmin sisäisiin ja ulkoisiin agentteihin. nts.

• Työntekijöiden agentit (sisäiset): Suorita tehtäviä sisäänkirjautuneen käyttäjän asiayhteydessä. Ne perivät käyttäjän lisenssit, käyttöoikeusjoukot, kenttätason suojauksen ja jakosäännöt, joten agentin identiteettiä ei provisioida erikseen eikä olemassa oleva suojauskehys hallitse, mitä agentti voi tehdä.
• Asiakasagentit (ulkoiset): Vuorovaikuta julkisten kanavien kautta ja toimi erillisinä agenttikäyttäjinä, erikoistuneina integraatiokäyttäjinä — äläkä julkisten sivustojen vieraskäyttäjinä. Kun agentti toimii erillisinä integraatiokäyttäjinä, hän voi suorittaa taustatoimintoja ja käyttää tietoja (joita todentamattomat vieraskäyttäjäprofiilit eivät voi), mutta hän on edelleen sidottu erillisiin käyttöoikeuksiin. Kun luot asiakasagentin, tarjoa uudelle agenttikäyttäjälle vähimmäismäärä käyttöoikeuksia ja myönnä vain sen toimintojen vaatimat käyttöoikeudet.

Jos agentin työ kattaa useita palveluita, jaa käyttäjän henkilöllisyys kullekin palvelun siirtymiselle sen sijaan, että se laskeutuisi takaisin jaettuun tai vieraskäyttäjän henkilöllisyyteen. Salesforcen OAuth 2.0 -valtuuden vaihto -kulku tukee seuraavaa:

Asiakassovellus esittää käyttäjän olemassa olevan henkilöllisyydentarjoajan valtuuden, ja Apex vaihtokäsittelijä kartoittaa sen Salesforce-käyttäjälle ja myöntää Salesforce-käyttöoikeusvaltuuden, joten alkuperäisen käyttäjän konteksti seuraa pyyntöä sen sijaan, että se tiivistettäisiin palvelutiliksi. Valvo agenttien toimintaa Event Monitoringin avulla ja käytä agentin käyttäjäidentiteettiä havaitaksesi poikkeavia toimintoja.

Oikean mallin valitseminen riippuu yhteyden käynnistäjästä ja siitä, kenen asiayhteydessä työ suoritetaan.

Yleiset yhteysskenaariot kartoitetaan suositeltuihin lähestymistapoihin seuraavalla tavalla:

Suunnittele roolihierarkioita datan käyttötarpeiden ympärille (joiden käyttäjät tarvitsevat pääsyn muiden omistamiin tietueisiin) — ei hallinnon raportointikaaviota. Anna roolihierarkian syvyyden noudattaa todellisia datan käyttöoikeussuhteita sen sijaan, että lisäisit tasoja, jotka eivät myönnä ylimääräistä käyttöoikeutta, koska jokainen taso lisää jako-laskennan ylimääräisiä kustannuksia — tämä huomio on tärkeämpi organisaatioissa, joissa on yksityiset OWD-asetukset ja suuret datamäärät.

Käyttöoikeusjoukot ja käyttöoikeusjoukkoryhmät vähentävät profiilien lisääntymisen tarvetta tarjoamalla joustavia lisäoikeuksia. Myönnä toiminnallisia käyttöoikeuksia käyttöoikeusjoukkojen ja käyttöoikeusjoukkoryhmien avulla profiilien sijaan, jotka pitävät käyttöoikeudet additiivisina ja tarkastettavissa. Profiilit ovat edelleen tarpeen: sisäänkirjautumisaikojen ja IP-rajoitusten lisäksi ne hallitsevat sivuasettelun kohdistusta, tietuetyyppien oletusasetuksia ja sovelluksen näkyvyyttä. Käsittele profiileja käyttöoikeusmallin pysyväksi osaksi, äläkä välttämättömänä rakenteena.

Transaktioiden suojauskäytännöt eivät ole osa perustasoa, vaan ne ovat lisäominaisuus, joka täydentää ydinvaltuutusmallia: yllä olevat identiteetti-, rooli-, profiili-, käyttöoikeusjoukko- ja jako-ohjaimet luovat jo turvallisen valtuutustilan itse, ja transaktioiden suojaus lisää siihen reaaliaikaisen asiayhteydentarjouksen. Määritä käytäntöjä havaitaksesi ja estääksesi poikkeavia toimintatapoja, mukaan lukien joukkolataukset, jotka ylittävät tavalliset kuviot, sisäänkirjautumiset odottamattomista maantieteellisistä alueista ja käyttöoikeuksien muutokset muutosikkunoiden ulkopuolella.

Suojausasetukset sisältävät saatavuuden kompromisseja, jotka ovat arkkitehtuurin vastuulla. Liian laaja IP-rajoitus voi lukita lailliset käyttäjät verkoston muutoksen aikana, ja liian aggressiivinen transaktioiden suojauskäytäntö voi estää kelvollisia liiketoimintatoimintoja — joten rajoita nämä ohjaimet todelliseen riskiin, aseta heidät Vain valvonta -tilaan ennen niiden käyttöönottoa ja suunnittele keskeytyspolku, kun ohjaus epäonnistuu.

Oma vastuusi: Suunnittele roolihierarkia, luo käyttöoikeusjoukkoja ja määritä transaktioiden suojauskäytäntöjä.

Perinteinen rooleihin perustuva käyttöoikeuden hallinta) myöntää käyttöoikeuksia käyttäjän roolin perusteella. ABAC (attribuutteihin perustuva käyttöoikeuden hallinta) tekee valtuutuspäätöksiä datan, käyttäjän ja asiayhteyden attribuuttien perusteella.

Ydinjakomalli ilmaisee useimpien vaatimusten käyttöoikeudet täysin. Valitse erillinen ABAC, kun käyttöoikeuden täytyy noudattaa datan luokittelua, jota tietueen jako ei voi ilmaista: Data 360 ABAC tarjoaa tämän tunnisteiden ja annotaatioiden avulla.

Data 360 ABAC toimii seuraavin tavoin:

• Tunnisteisiin perustuvat käytännöt, jotka määrittävät käyttöoikeussääntöjä datan objekteihin sovellettujen tunnisteiden perusteella (esimerkiksi Henkilöllisyyden tunnistettavat tiedot (PII), Talous-, Terveydenhuolto- ja Luottamukselliset tunnisteet).
• Dataobjekteihin sovelletaan annotaatioita tukemaan käytäntöihin perustuvia valtuutuspäätöksiä.
• Uuden ja olemassa olevan organisaation oletusarvoinen Salli kaikki -käytäntö, joka täytyy poistaa erikseen, jotta hallintakäytännöt ovat tarkkoja.

Sen ensisijainen arkkitehtuurin käyttö on tietojen luokittelun noudattaminen — katso lisätietoja siitä, miten luokittelutasot edistävät ABAC-säännösten noudattamista kohdasta Tietoturva ja yksityisyys.

Tämä tarkkuustaso aiheuttaa toiminnan kustannuksia. Ydintoiminto vastaa kysymykseen "Kuka näkee tämän tietueen ja miksi?" pienestä, tarkastettavasta sääntöjen joukosta (OWD:t, roolihierarkiat ja jakosäännöt), kun taas ABAC luo vastauksensa arvioinnin aikana datatunnisteiden, käyttäjäattribuuttien ja asiayhteyden yhdistelmästä, joten tehokasta käyttöä on vaikeampi ymmärtää ja valvoa, kun käytäntöjä ja tunnisteita kerätään.

Noudata auditointia suunnittelun vaatimuksena: sovella tunnisteita johdonmukaisesti, pitää käytäntöjoukko pienenä ja nimettynä sen käyttämän luokittelun perusteella ja säilyttää kyvyn rakentaa uudelleen syy, miksi käyttäjä saavutti tietyn tietueen. Varaa ABAC-arvo luokitteluun perustuville tapauksille, joita tietuekohtainen jakaminen ei voi todella ilmaista, sen sijaan, että käsittelisit sitä omistukseen perustuvan mallin yleisenä korvaajana.

Tunnista ja suojaa tilit, joilla on korkeat käyttöoikeudet, mukaan lukien järjestelmänvalvojat, integraatiokäyttäjät ja automatisoidut prosessitilit. Nämä tilit ovat hyökkääjien tärkeitä kohteita.

Käytä parannettuja asetuksia kriittisille vaikutustilille.

• Vaadi tietojen kalasteluvastainen MFA
• Rajoita sisäänkirjautumisen IP-osoitealueet tunnettuihin pääkäyttäjäsijainteihin
• Ota sisäänkirjautumishälytykset ja käyttöoikeuksien muutostiedot käyttöön
• Suorita säännöllisiä käyttöoikeustarkistuksia ja dokumentoituja vahvistuksia korkean oikeutuksen tileille, joiden yleisyys riippuu organisaation riskien toleranssista ja vaatimustenmukaisuudesta
• Ylläpidä katkoviivojen toimenpiteitä hätätilanteessa ja käytön jälkeisessä auditoinnissa

Integraatio- ja palvelutileille:

• Käytä OAuth-kulkuja, älä koskaan käyttäjänimi/salasana-kulkuja
• Ota IP-rajoitukset käyttöön
• Toteuta tunnusten kierrätysaikatauluja
• Seuraa poikkeavia API-käyttökuvioita Event Monitoringin avulla

Oma vastuusi: Tunnista kriittiset tilit, käytä parannettuja asetuksia ja suorita neljännesvuosittaisia tarkastuksia.

Suunnittele automatisoituja prosesseja tarjotaksesi käyttäjille asianmukaiset alustavat käyttöoikeudet, säätääksesi käyttöoikeuksia roolien muuttuessa ja poistaaksesi provisioinnin nopeasti, kun käyttöoikeutta ei enää tarvita.

Toteuta System for Cross-Domain Identity Management (SCIM) -järjestelmä henkilöllisyydentarjoajilta saatuun automatisoituun provisiointiin. SAML tai OpenID Connect Just-in-Time -provisiointi on vaihtoehto, joka luo käyttäjän ensimmäisellä sisäänkirjautumisella, mutta se ei kumoa käyttäjien provisiointia. Toisin sanoen SCIM on elinkaaren selkäranka, ei sen vastainen vaihtoehto.

Henkilöllisyyden elinkaariin sisältyy:

• Provisiointi: Luo tilejä, joilla on peruskäyttöoikeus, joka vastaa työtehtäviä, jotka HR-järjestelmätapahtumat käynnistävät.
• Käytä säätöjä: Myönnä lisäoikeuksia, kun roolit laajenevat, ja kumoa käyttöoikeudet, kun roolit muuttuvat.
• Ajanjakson uudelleensertifiointi: Tarkasta ja vahvista käyttöoikeudet neljännesvuosittain.
• Deprovisiointi: Kumoa käyttöoikeus välittömästi, kun työ päättyy tai roolit eivät vaadi enää Salesforcen käyttöoikeutta.

Ota käyttöön käyttöoikeuksien uudelleensertifiointiprosesseja, kun päälliköt tarkastavat ja vahvistavat tiiminsä käyttöoikeudet säännöllisesti. Tarkastusten yleisyys perustuu riskien ja vaatimustenmukaisuuden vaatimuksiin.

Oma vastuusi: Toteuta SCIM, suunnittele provisioinnin työnkulut ja suorita neljännesvuosittainen uudelleensertifikaatti.

Tietojen erottamista useisiin organisaatioihin pidetään joskus pelkästään kustannus- tai asumispäätöksenä. Arkkitehtuurisesti kyseessä on tietoturvamerkintä, ja hallintavaikutukset kuuluvat käyttöoikeuksien suunnitteluusi.

Eristys on tärkein etu. Erilliset organisaatiot tarjoavat mahdollisimman vahvan rajapinnan datajoukkojen välillä. Ei ole olemassa kollektiivista jakomallia eikä ristiinvuokralaisten käyttöoikeuksia, mutta on olemassa selkeä sääntelylinja lainkäyttöalueille, jotka vaativat sellaista. Sama raja pilkkoo hallinnan. Kaikki käyttöoikeuksien hallinnat, joita sinun täytyy ylläpitää vain kerran yhdessä organisaatiossa (esimerkiksi käyttöoikeusjoukkojen rakenne, roolihierarkia, kriittisten vaikutusten tilien koventaminen, terveystarkastuksen perustasot, tapahtumien valvonta ja SIEM-korrelaatio) kerrottuna organisaatiokohtaisesti, mikä tarkoittaa, että niiden on säilytettävä yhdenmukaisuus kaikissa. Organisaatioiden välinen häiriö luo oman hyökkäysalueensa, koska käyttöoikeus, joka tiukennetaan yhdessä organisaatiossa ja puuttuu toisessa, luo epäjohdonmukaisuuden, jonka hyökkääjät voivat löytää ja hyödyntää. Organisaatioiden väliset integraatiot lisäävät todennettuja Trust, joita ei ollut ennen. Jokainen organisaatioiden välinen integraatio on yhteys, jota sinun täytyy suojata ja valvoa.

Tästä syystä on tärkeää punnita eristyksen etu hallintajärjestelmän kerrointa vasten ennen kuin jaat organisaation. Varaa useita organisaatioita tapauksille, joissa kovaa lokalisointia koskevaa toimeksiantoa tai asiakkaan sopimuksellisen eristämisen vaatimusta ei voida todella täyttää yhdessä organisaatiossa. Kun otat sen käyttöön, sinun täytyy suunnitella käyttöoikeusmallin, valvonnan ja kokoonpanon perustasot, jotta niitä sovelletaan identtisesti kaikissa organisaatioissa alusta alkaen.

Oma vastuusi: Käsittele usean organisaation päätöstä tietoturvan kompromissina, äläkä vain kustannuksena. Kun useita organisaatioita tarvitaan, noudata käyttöoikeuksien hallinnan, valvonnan ja terveystarkastuksen perustasoja yhdenmukaisesti kaikissa organisaatioissa ja suojaa organisaatioiden väliset integraatiot Trust rajoina.

Sinun vastuullasi on luokitella data, määrittää salaus ja suunnitella yksityisyysasetuksia.

Nyt tutustumme tarkemmin tietojen ja yksityisyyden suojaamiseen.

Sinun täytyy tuntea datasi, jotta voit luokitella datasi oikein. Ylätason arkkitehtuuritehtävä on ymmärtää yrityksesi toimialue ja ylläpitää datan sanakirjaa, joka kattaa, mitä tietoja sinulla on, mitä se tarkoittaa ja missä luottamukselliset tiedot sijaitsevat. Voit luokitella — tai suojata — vain ensin tunnistamiasi tietoja.

Laadi datan luokittelujärjestelmä, joka edistää asiaankuuluvia suojausasetuksia. Luokittelun otsikko ei suojaa mitään. Käytät ohjaimiin syötettä, joten jokainen kohdistamasi luokitus täytyy kartoittaa konkreettiseen salaukseen, käyttöoikeuksiin, säilyttämiseen tai valvontaan. Datan mallinnuksen aikana tehdyt luokittelupäätökset vaikuttavat suoraan salausvaatimuksiin, käyttöoikeuksien hallintaan, säilytyskäytäntöihin ja vaatimustenmukaisuuden velvoitteisiin.

Salesforcessa käytämme nelitasoista järjestelmää, joka tarjoaa kehyksen, jota voit mukauttaa organisaatiosi lakisääteisiin vaatimuksiin ja liiketoimintatarpeisiin. Monet yritykset käyttävät samankaltaisia malleja, jotka vastaavat toimialan standardeja (esimerkiksi ISO 27001 ja NIST). Tietyn toteutuksesi tulisi vastata vaatimustenmukaisuutta koskevia velvoitteitasi (esimerkiksi HIPAA-, PCI DSS-, GDPR- ja toimiala-asetuksia) ja liiketoimintaympäristöäsi.

Käytä luokittelua kenttätasolla. Yksi tilitietue voi sisältää Julkinen-kenttiä (esimerkiksi yrityksen nimet), Luottamukselliset-kenttiä (esimerkiksi yrityksen tuotto) ja Rajoitettu-kenttiä (esimerkiksi sosiaaliturvatunnukset). Kenttätason suojauksen täytyy vastata näitä eroavaisuuksia.

Luokittelua voidaan käyttää attribuutteihin perustuvalla käyttöoikeuksien hallinnalla, joka lukee kohdistamasi tunnisteet ja käyttää käyttöoikeussääntöjä. Tämä on metadataan perustuva kerros, joka täydentää OWD- ja jakosääntöjä.

ABAC:n tasaaminen luokittelujärjestelmääsi sallii sovellusalustan:

• Rajoita Rajoitettu- tai Luottamuksellinen-tunnisteena merkittyjen tietojen käyttöoikeuksia itse luokituksesta, äläkä objektin mukaan ylläpidetystä jakosäännöstä.
• Säädä käyttöoikeuksia, kun tietueen luokitus muuttuu ajan myötä. Viimeksi merkitty Regulated-tunnisteeksi saatu tietue perii tiukemmat käyttöoikeudet ilman sääntöjen manuaalista muutosta.
• Yhdistä datan attribuutteja (esimerkiksi luokitus ja luottamuksellisuus) käyttäjäattribuutteihin (esimerkiksi osasto ja tyhjentäminen) ja kontekstiin (esimerkiksi aika ja sijainti) yhdessä valtuutuspäätöksessä.

Suunnittele ABAC-käytännöt tämän järjestelmän mukaisiksi siten, että kentän luokittelu Rajoitettu-tyyppiseksi on toiminto, joka määrittää sen käyttöoikeudet ja pitää täytäntöönpanon ankkurina luokitteluun sen sijaan, että säilyttäisi jakosääntöjä erikseen.

Oma vastuusi: Määritä luokittelukäytäntöjä, kouluta datamallintajia, luokittele kenttiä suunnittelun aikana, määritä ohjaimia ja kohdista ABAC-käytäntöjä luokittelutasojen mukaan, jotta tunnisteet edistävät käytäntöjen noudattamista.

Aloita käyttämällä tietoja, joita sovellusalusta tarjoaa jo jokaiselle organisaatiolle. Tyhjässä oleva data salataan oletusarvoisesti. Hyperforce käyttää määrätason salausta, joka suojaa koko tallennustilan yhdellä Salesforcen omistamalla ja hallitsemalla avaimella. Tämä perustasosi on aina ajan tasalla ja läpinäkyvä ratkaisullesi, mutta se toimii määrätasolla (ei kenttäkohtaisesti), joten avaimen elinkaaren sisällä salauksen ja hallinnan valinta riippuu sovellusalustasta, ei sinusta.

Kun tämä perustaso ei voi täyttää vaatimustenmukaisuuden, sopimusten tai datan luokittelun velvoitetta, käytä Shield Platform Encryptionia. Tarkalleen ottaen, kun tarvitset jonkin kolmesta kohteesta, joita määrätason salaus ei tarjoa:

• Avaimen elinkaaren hallinta, jotta voit luoda, kierrättää ja kumota avainmateriaalia itse
• Valittavuus, jonka perusteella vakiokentät, mukautetut kentät, tiedostot ja liitteet salataan paikallisesti
• Kyky estää Salesforcea käyttämästä tietoja.

Rajoitetut tiedot ja tiedot, jotka ovat sääntelyvalmiiden avainten hallintaoikeuksien alaisia (esimerkiksi HIPAA, PCI DSS ja GDPR), ovat tavallisia käynnistimiä. Perustaso kattaa jo kaiken muun infrastruktuuritason suojauksen.

Shield Platform Encryption salaa kenttätasolla, ja se tarjoaa kaksi skeemaa, jotka vaihtavat tietoturvaa kyselytason kanssa.

Todennäköisyyksiin perustuva salaus on vahva ja oletusarvoinen järjestelmä, mutta sen avulla salattuja kenttiä ei voi käyttää suodatusehdoissa, lajittelussa tai aggregaattifunktioissa (esimerkiksi MAX(), MIN() ja COUNT_DISTINCT()-funktioissa).

Deterministinen salaus sallii tarkan vastaavuuden suodattamisen raporteissa, luettelonäkymissä ja SOQL WHERE -lausekkeissa — jotka ovat merkkikokoriippuvaisia tai ei merkkikokoriippuvaisia — vähemmän vahvasti, koska sama pelkkä teksti tuottaa aina saman salaustekstiä.

Suosittelemme salaamaan todennäköisyyksiin perustuvalla skeemalla oletusarvoisesti ja varaamaan deterministisen salauksen tietyille kentille, jotka sinun täytyy suodattaa tai lajitella. Arvioi nämä kompromissit datan mallinnuksen suunnittelun aikana, mukaan lukien vaikutukset kaavakenttien viitteisiin, raporttien aggregointiin ja SOQL-toimintoihin.

Asiakkaan hallitsemilla avaimilla on kaksi erillistä muotoa:

• Bring Your Own Key (BYOK) sallii sinun luoda avainmateriaalia Salesforcen ulkopuolelta — käyttämällä omia kryptokirjastojasi, yrityksen avainten hallintajärjestelmää tai laitteiston suojausmoduulia — ja toimittaa sen alustaan.
• Vain välimuisti -avainpalvelu säilyttää datan salausavaimesi avainpalvelussa, jota hallitset. Salesforce noutaa sen tarvittaessa sen tallentamisen sijaan.

Molemmat lomakkeet sallivat sinun kierrättää ja tuhota avainmateriaalia omalla aikataulullasi. Avainmateriaalin tuhoaminen tekee sen suojaamista tiedoista palauttamattomia, mikä on tehokas, tarkoituksellinen hallinta rutiinin sijaan. On myös tärkeää dokumentoida avaimien kierrättäminen ja peruuttaminen.

Kaikkien integraatioiden täytyy käyttää TLS 1.2 -protokollaa tai sitä uudempaa (Salesforce-sovellusalusta käyttää tätä), mutta sinun täytyy ottaa käyttöön sertifikaatteihin perustuva yhteinen todennus integraatioille, jotka käsittelevät Rajoitettu data -ominaisuutta (käyttämällä omaa kokoonpanoasi).

Oma vastuusi: Päätä, missä sovellusalustan määrätason perustaso riittää ja missä vaatimustenmukaisuus-, sopimus- tai luokittelupyyntö vaatii Shield Platform Encryptionin, valitse sitten salaustavat, valitse ja käytä asiakasohjaama avainstrategia ja ota sertifikaatteihin perustuva todennus käyttöön luottamuksellisille integraatioille.

Suojele luottamuksellisia tietoja muissa kuin tuotantoympäristöissä käyttämällä strategioita, jotka estävät rajoitetun datan pääsyn sandboxeihin.

• Osittainen sandboxin kopiointi ei sisällä sandboxien päivityksiin liittyviä rajoitettuja tietoja.
• Datan peittosäännöt sekoittavat sandboxien luottamuksellisten kenttien arvoja käyttämällä kuvioita, jotka säilyttävät datan ominaisuudet.
• Synteteettistä datan luomista sovelletaan kehitysympäristöihin, jotka eivät koskaan vaadi tuotantodataa.
• Sandbox-mallit määrittävät, mitkä objektit ja kentät sisällytetään kuhunkin sandbox-tyyppiin.

Vaatimustenmukaisuuden testausta varten suunnittelu on arkkitehtuurin vastuulla. Rakenna kehitys- ja testaussykliä synteettisille tiedoille, joilla on realistisia ominaisuuksia, jotta tiimit voivat vahvistaa tuotantoympäristöä vastaavia ehtoja, kun taas säännelty data pysyy sen tuotantoympäristössä.

Oma vastuusi: Suunnittele sandbox-strategia, määritä Data Mask -sääntöjä ja luo synteettisiä testitietoja.

Suunnittele ratkaisuja, jotka kunnioittavat käyttäjien yksityisyyttä arkkitehtonisten päätösten avulla.

• Datan minimointi: Kerää tietoja, joita tarvitaan vain määritettyihin liiketoimintatarkoituksiin. Haasta jokainen kenttälisäys kysymällä: "Mikä arkkitehtisuunnitelma vaatii nämä tiedot?" Muista, että turvallisin tieto on data, jota et koskaan kerää.
• Käyttötarkoituksen rajoitus: Suunnittele datan käyttöoikeuskuvioita, jotka rajoittavat käyttötarkoituksia teknisesti. Käytä käyttöoikeusjoukkoja ja jakosääntöjä rajoittaaksesi tietojen käyttöoikeuksia työtehtävän käyttötarkoituksen perusteella. Esimerkiksi markkinointikäyttäjien ei tulisi käyttää tukitapausten lisätietoja, ellei heidän työnsä sitä vaadi.
• Suostumusten hallinta: Ota suostumusten seuranta käyttöön yksittäisellä tasolla markkinointia, analyysiä ja valinnaista datan käsittelyä varten. Suunnittele suostumusten peruutusten työnkulut, jotka leviävät integroituihin järjestelmiin. Toisin sanoen suostumus on tarkka ja käyttötarkoituskohtainen.
• Datan aiheen oikeudet: Rakenna työnkulkuja käyttöoikeuspyynnöille (esimerkiksi tietojen kopioiden antaminen), korjauksille (esimerkiksi virheiden korjaaminen), poistamiselle (esimerkiksi tietojen poistaminen, kun se on lakisääteisesti sallittu) ja siirrettävyydelle (esimerkiksi koneluettavaksi muodoksi vieminen). Suunnittele nämä työnkulut suoritettavaksi kunkin hallintakehyksen määrittämän vastauksen määräajan sisällä. Nämä määräajat vaihtelevat lainkäyttöalueen mukaan — ja niitä muutetaan säännöllisesti — joten on tärkeää parametroidaksesi työnkulun palvelutasosopimuksen ylläpidetystä vaatimustenmukaisuuden lähteestä ja vahvistaaksesi jokaisen ajanjakson säännösten mukaisesti (enkä yhden arvon kovakoodattamisen sijaan).

Oma vastuusi: Suunnittele datamalleja minimoinnin avulla, määritä käyttöoikeuksia käyttötarkoituksen perusteella, toteuta suostumusten työnkulkuja ja laadi datan aiheiden oikeuksien automatisointi.

Datan residenssi on arkkitehtoninen päätös, jonka teet ennen provisiointia, et asetusta, jonka muutat myöhemmin. Hyperforce tarjoaa alueellisen käyttöönoton — mutta vain alue, jossa Salesforce toimii — ja organisaation sijainti on kiinteä provisioinnissa. Sinun vastuullasi on määrittää kunkin tietoluokan sijainti, vahvistaa, onko sopiva alue saatavilla, ja suunnitella tietojen siirtojärjestelmät, jotka ylittävät oikeutetusti rajat.

Sen sijaan, että säilytettäisiin oletusarvoisesti maassa, on tärkeää luokitella oleskeluoikeutesi ennen aloittamista.

• Pakollinen lokalisointi. Pieni joukko lainkäyttöalueita vaatii, että tietyt tiedot säilyvät kansallisten rajojen sisällä (joskus tämä koskee vain säänneltyjä sektoreita). Kun Salesforce ei toimi maassa sijaitsevassa alueessa, natiivisäiliö ei voi täyttää tehtävää yksinään, joten tarvitset datan sijainnin peittokuvan tai erillisen organisaation kyseisille tiedoille. Koska tämä luettelo saattaa vaihdella, on tärkeää vahvistaa kyseinen toimeksianto hallittavan asetuksen mukaisesti.
• Vastuun perustuvat kehykset. Useimmat järjestelmät eivät määritä lokalisointitehtävää. He ovat tyytyväisiä alueelliseen hubiin, jolla on asianmukainen rajat ylittävä siirtomekanismi. Näissä tapauksissa päätös perustuu alueeseen, joka minimoi viiveen ja yksinkertaistaa vaatimustenmukaisuutta.

Kun data ylittää rajan, tärkeintä on tietoisuus ennen kokoonpanoa. Toisin sanoen sinun täytyy tietää, mitä siirtoja tapahtuu ja minkä lakisääteisen perusteen perusteella, ja suunnitella käyttöoikeudet siten, että dataa hallitaan loppuun asti. Kun ne ovat olemassa, riittävyyttä koskevat päätökset vaikuttavat vähiten. Sidonnaiset yrityssäännöt (BCR) ja vakiosopimuslausekkeet (SCC) kattavat useimmat jäljellä olevat siirrot. Käytä suostumusta vain viimeisenä keinona.

Yhdistä siirtomekanismi rajoittavaan tietueen käyttöoikeuteen (esimerkiksi yksityiset OWD:t ja käyttötarkoituksen mukainen jakaminen), jotta sallittu siirto ei tule liian laajoiksi. Asiakirjojen datakulkujen kartat näyttävät kunkin tietoluokan alkuperän, siirron ja sijainnin. Tarkasta ne uudelleen, kun säännökset tai paikalliset saatavuudet muuttuvat.

Oma vastuusi: Luokittele asumisvelvollisuudet tietoluokittain, vahvista alueellinen saatavuus ennen provisiointia, valitse siirtomekanismeja (riittävyyttä, BCR/SCC-arvoja) rajat ylittäville kuluille ja dokumentoi datakulkukartat.

Sinun vastuullasi on suunnitella ratkaisuja, jotka ylläpitävät sovellusalustan tarjoamaa vaatimustenmukaisuutta.

Tämä ohje on suuntaviivainen. Sääntelyvaatimukset vaihtelevat lainkäyttöalueen mukaan ja muuttuvat ajan myötä. Sinun täytyy aina tarkastaa tiettyjä velvollisuuksia hallittavasta säännöstä (esimerkiksi sovellettava sääntö, valvontaviranomainen tai Salesforcen vaatimustenmukaisuusdokumentaatio) käyttöönottoa varten.

Salesforce ylläpitää laajoja vaatimustenmukaisuussertifikaatteja (saatavilla osoitteesta trust.salesforce.com ja compliance.salesforce.com): SOC 2 Type II, ISO 27001, FedRAMP (Government Cloud -tuotteille), HIPAA, PCI DSS ja alueelliset sertifikaatit. Nämä sertifikaatit kattavat Salesforcen vastuut sovellusalustan infrastruktuurille ja jaetuille palveluille.

Sovellusalustan sertifikaatit vähentävät vaatimustenmukaisuuden taakkaa, mutta ne eivät poista rakenteellista vastuuta. Mukautettujen objektien, Apex, integraatioiden ja kokoonpanojen täytyy ylläpitää sovellusalustan tarjoamaa vaatimustenmukaisuutta.

Oma vastuusi: Suunnittele ratkaisuja, jotka ylläpitävät vaatimustenmukaisuutta, ja dokumentoi, miten arkkitehtuuri täyttää lakisääteiset vaatimukset.

• Ota Shield Platform Encryption käyttöön kaikille kentille, jotka sisältävät suojattuja terveystietoja (PHI).
• Jos haluat noudattaa HIPAA-säännöksiä, ota käyttöön kenttien kirjausketju säilytyskäytännöillä noudattaaksesi HIPAA:n tietueiden säilytysvaatimuksia. Vahvista tämänhetkinen ajanjakso hallitun asetuksen perusteella.
• Määritä tapahtumien valvonta havaitaksesi valtuuttamattomia PHI-käyttöoikeuskuvioita.
• Ota käyttöön kaikki HIPAA-suojaussäännön vaatimat tekniset suojausasetukset, mukaan lukien käyttöoikeuksien hallinta, kirjauslokien kirjaaminen ja siirron suojaus.

• Ota käyttöön tehtävien erottaminen (SoD) käyttöoikeusjoukkojen rakenteiden avulla estääksesi yksittäisiä käyttäjiä luomasta ja hyväksymästä finanssitransaktioita.
• Jos käytät PCI-ympäristöä, vältä koko ensisijaisten tilien (PAN) tallentamista Salesforceen minimoidaksesi PCI DSS -yhteensopivuuden vaikutusalueen.
• Käytä maksusiltapalvelun tokenisointia aina, kun se on mahdollista.

• Suunnittele GDPR:lle ja LGPD:lle suostumusten hallinta, joka kerää tarkkoja, käyttötarkoitukseen liittyviä suostumuksia.
• CCPA/CPRA noudattaa tilauksen perumisen mallia. Tarjoa selkeitä mekanismeja, joilla voit kieltäytyä henkilötietojen myynnistä tai jakamisesta tarkemman käyttötarkoitukseen perustuvan suostumuksen sijaan.
• Laadi datan aiheiden oikeuksien työnkulkuja, jotka on suoritettu kunkin kehyksen vastauksen määräaikaan mennessä ja jotka on vahvistettu säännösten mukaisesti.
• Ota käyttöön datan säilytysautomaatio, joka tyhjentää tiedot, kun suostumus vanhenee.

• Käytä Salesforce Government Cloudia hallittaville töille.
• Toteuta Salesforce-kokoonpanoon kartoitettuja NIST 800-53 -ohjaimia.
• Ota jatkuva valvonta käyttöön tapahtumien valvonnan kautta, joka reititetään hallituksen SIEM-infrastruktuuriin.

Oma vastuusi: Määritä Shield, Field Audit Trail, tehtävien erottaminen, suostumusten hallinta ja datan säilyttäminen lakisääteisten vaatimusten perusteella.

Tietoturvaa ja yksityisyyttä koskevat säännökset vaihtelevat lainkäyttöalueittain merkittävästi — ja tietyt velvollisuudet muuttuvat nopeasti — joten tämä taso vaatii päätöksenteon maakohtaisen taulukon sijaan.

Nämä kaksi arkkitehtuurivaihtoehtoa ovat paikkamääritys ja rajat ylittävä siirto, jotka on kuvattu kohdassa Tietosuoja ja yksityisyys.

Näiden sääntöjen noudattamiseksi sinun täytyy:

• Luokittele missä tietoluokkien täytyy sijaita
• Varmista ennen provisiointia, että sopiva alue on olemassa
• Suunnittele laillinen siirtomekanismi rajan ylittävälle datalle.

Lisätietoja päätöskehyksestä on kohdassa Datan sijainti ja suvereniteetti.

Kaikkia tämän ulkopuolisia tietoja pidetään ajankohtaisina lukuina (esimerkiksi mitä suostumusmallia lainkäyttöalue käyttää, datan aiheeseen liittyvän pyynnön määräaika, ajanjakso, josta ilmoittaa sääntelyviranomaisille tai asiaankuuluville yksityishenkilöille rikkomuksen jälkeen, ja tarkastustietueiden vähimmäissäilytysaika). Nämä luvut on määritetty säännöksissä, ne vaihtelevat kehyksen mukaan ja ne muutetaan valvojien aikatauluihin.

Älä kovakoodaa niitä tässä. Sinun täytyy määrittää seuraavat vaiheet käyttöönottosi säännösten perusteella — tai ylläpidetyn vaatimustenmukaisuuden lähteen perusteella, joka mainitsee sellaisen — ja koostaa suunnittelusi liiketoimintajalanjälkesi pienimpään ikkunaan.

Alla on suunnittelun kestävät arkkitehtoniset vaikutukset.

• Yksinumeroisina päivinä mitattua datan aiheiden pyyntöjen määräaikaa ei voida täyttää ad hoc -manuaalisella prosessilla, joten sinun täytyy automatisoida DSR-täydennys missä tahansa lyhytaikaisessa lainkäyttöalueessa. Käytä Experience Cloudia syötteeseen, Service Cloudia tapausten seurantaan, Privacy Centeria havaintoon ja kulkua täydennykseen.
• Rikkomuksen ilmoitusikkuna on liian tiukka improvisoitavaksi, joten sinun täytyy laatia rikkomuksen vastauksen työnkulku etukäteen. Määritä Event Monitoringin poikkeussäännöt, esimääritetyt roolit, esimääritetyt sääntely- ja datan aiheiden ilmoitukset sekä eskalointipolku, joka olettaa, että hiilijalanjälkesi on tarkimpi. Yksittäiset ilmoitukset käynnistyvät tavallisesti korkean riskin määritelmällä, joten sinun täytyy sisällyttää työnkulkuun riskien arviointi.
• Jotkin lainkäyttöalueet vaativat tai suosittelevat tarkastuslokien maakohtaista säilyttämistä — ja niiden vähimmäismäärät kattavat useita vuosia — joten sinun täytyy mitata SIEM-säilytys vähintään hiilijalanjälkesi sisällä ja vahvistaa, voivatko lokit poistua lainkäyttöalueelta.

Oma vastuusi: Suunnittele sijainti ja siirto tietoturvaa ja yksityisyyttä kohti, automatisoi DSR- ja rikkomusten käsittely -työnkulut hiilijalanjälkesi tiukimpien määräaikojen mukaisesti ja vahvista jokainen lainkäyttöaluekohtainen numero tämän oppaan arvojen sijaan.

Suunnittelu jatkuvalle vaatimustenmukaisuuden vahvistukselle aikakatkaisun sijaan.

• Security Health Check arvioi kokoonpanon Salesforcen tietoturvan perustasojen perusteella ja tarjoaa riskipisteitä. Suorita tarkastuksia säännöllisesti valvoaksesi Salesforcen tietoturvan perussuositusten noudattamista. Pidä pistemäärä 80 % tai korkeammalla (Erittäin hyvä tai Erinomainen bands).
• Event Monitoring tallentaa yksityiskohtaisia lokeja käyttäjien toiminnoista, API-kutsuista, todennustapahtumista ja datan käyttöoikeuskuvioista. Reititä tapahtumalokitiedostot ulkoiseen SIEM-järjestelmään säilyttääksesi ne pitkällä aikavälillä, mikä ylittää natiivin säilytyskriteerit.
• Transaction Security arvioi tapahtumat ja vakuutukset reaaliajassa, ja se voi estää tapahtumia, vaatia MFA:n nostamista tai ilmoittaa sinulle käytännön rikkomuksista.

On tärkeää automatisoida käyttöönottoputkien vaatimustenmukaisuuden tarkastukset varmistaaksesi, että käyttöönotot eivät heikennä käyttöoikeusmalleja, poista tarkastusasetuksia käytöstä tai tuo käyttöön yhteensopimattomia kokoonpanoja.

Oma vastuusi: Suorita terveystarkastus neljännesvuosittain, reititä Event Monitoring -ominaisuus SIEM:ään, määritä transaktioiden suojauskäytäntöjä ja automatisoi vaatimustenmukaisuuden vahvistus CI/CD:ssä.

Suunnittele seurantastrategioita, jotka perustuvat vaatimustenmukaisuuden vaatimuksiin, tutkimistarpeisiin ja säilytysehtoihin.

Jos käytät säänneltyjä ympäristöjä, ota Event Monitoring käyttöön ulkoisella SIEM-integraatiolla lokien pitkäaikaista säilyttämistä ja järjestelmien välistä korrelaatiota varten. Suunnittele kenttien kirjausketjun käytännöt, jotka kattavat kaikki rajoitetut ja luottamukselliset kentät, joihin sovelletaan tietueiden säilyttämistä koskevia sääntelyvaatimuksia.

Oma vastuusi: Ota kenttien kirjausketju käyttöön luottamuksellisille kentille, reititä Event Monitoring -ominaisuus SIEM-järjestelmään ja määritä transaktioiden suojauskäytännöt.

Sinun vastuullasi on integroida tietoturva koko kehitysvaiheessa, äläkä myöhemmin.

Integroi tietoturvakäytäntöjä mahdollisimman aikaisessa kehitysvaiheessa. Uhkien mallinnus arkkitehtuurin vaiheen aikana estää suunnittelutason haavoittuvuudet. Toiminnallisten vaatimusten lisäksi kaapatut tietoturvavaatimukset estävät sinua käsittelemästä tietoturvaa harkiten.

Suojausvirheiden korjaaminen maksaa huomattavasti enemmän, kun ne havaitaan tuotantoympäristössä, eikä suunnittelun tai kehityksen vaiheissa. Suunnittelutason suojausvirhe, joka havaitaan arkkitehtuurin tarkastuksen aikana, saattaa kestää vain yhden keskustelun korjaamisen. Kun sama virhe löytyy kuitenkin tuotantoympäristössä, se vaatii uudelleenarkkitehtuuria, datan siirtoa, vaatimustenmukaisuuden korjaamista ja mahdollisen rikkomuksen ilmoitusta.

Siksi käytämme työvuorojen vasemmanpuoleista suojausta, joka keskittyy:

• Uhkien mallinnus ennen suunnittelun viimeistelyä
• Käyttäjien tarinoiden suojausvaatimukset
• Suojatun koodauksen koulutus kehittäjille
• Staattinen analyysi, joka on integroitu IDE-organisaatioihin
• Suojaukseen keskittyvät koodin tarkastukset
• Automatisoitu tietoturvatestaus CI/CD:ssä
• Suojauksen vahvistus ennen tuotantoympäristön käyttöönottoa

Oma vastuusi: Suorita uhkien mallinnusta, kouluta kehittäjiä, integroi Code Analyzer CI/CD-tiedostoon ja vaadi tietoturvasta riippuvaisia koodin tarkastuksia.

On tärkeää suunnitella puolustusmenetelmiä yleisimpiä haavoittuvuuksia vastaan Salesforce-kontekstissa. Katsotaanpa tarkemmin, miten kartoitamme Salesforcen 2025 OWASP Top 10 -listalle.

• A01:2025 - Käyttöoikeuksien hallinta rikki: Ota CRUD ja kenttätason suojaus (FLS) käyttöön ohjelmallisesti kaikissa Apex käyttöoikeuksissa.
  • API-versiossa 67.0 tai sitä uudemmassa Apex suoritetaan oletusarvoisesti käyttäjäkontekstissa, mikä tarkoittaa, että nykyisen käyttäjän käyttöoikeudet ja FLS noudatetaan koodin suorituksen aikana.
    • WITH SECURITYENFORCED poistettiin, mikä aiheuttaa koontivirheen. Korvaa kaikki olemassa olevat käyttötavat arvolla WITH USER_MODE. Sovellusalusta käyttää käyttöoikeutta vakiokäyttöliittymässä.
  • Järjestelmätila on oletusarvoisesti API-versio 66.0 tai sitä vanhempi. Käytä SOQL-kyselyissä WITH USERMODE tai DML-operaatioissa Security.stripInaccessible().
• A01:2025 - Asiakaspuolen datan API-rajapinnat: Lightning Data Service ja UI API noudattavat automaattisesti suorittavan käyttäjän FLS-, CRUD- ja jakoasetuksia, joten niihin perustuva komponentti perii oletusarvoisesti vähiten käyttöoikeuksia.
  • Tämä suojaus menetetään, kun komponentti kutsuu mukautettua Apexia. Imperatiivinen Apex pakottaa käyttöoikeuden vain, kun se suoritetaan käyttäjätilassa, joten luokka, joka on ilmoitettu ilman jakamista, toimii paetaulukkona, joka ohittaa mallin hiljaa.
  • Käytä datan käyttämiseen Lightning Data Servicea ja käyttöliittymän API-rajapintaa.
  • Sinun täytyy vahvistaa CRUD, FLS ja jakaminen uudelleen jokaiselle komponentista lähetetylle Apex.
• A02:2025 - Suojausvirhe: Valvo kokoonpanon heikentymistä tietoturvan perustasosta terveystarkastuksella.
  • Poista Vieraskäyttäjä-käyttöoikeus käytöstä Experience Cloud -sivustoilta (elleivät asiakirjoitetut liiketoimintaperusteet edellytä sitä erikseen).
• A05:2025 - Injektio: 2025 Injection -luokka kattaa SOQL/SOSL-injektion ja sivustojen välisen komentosarjan (XSS).
  • Käytä kyselyn injektiossa sidottuja muuttujia kaikille dynaamisille kyselyille. Älä koskaan ketjuta käyttäjien syöttämiä tietoja suoraan kyselymerkkijonoihin. Sovellusalustan parametroidut kyselymekanismit välttävät ruiskutuksen riskiä, kun niitä käytetään oikein.
  • SOQL- tai SOSL-injektiot rajoitetaan lukemaan, joka paljastaa tietueita tai kenttiä, joita soittaja ei pitäisi voida käyttää laajentamalla kyselyehtoja. Koska nämä kielet lukevat dataa, kun kirjoitukset suoritetaan erillisten DML-toimintojen kautta, tämä luo käyttöoikeuksien hallinnan ja luottamuksellisuuden riskin, koska se yhdistetään, kun objektin ja kentän käyttöoikeuksia ei sovelleta kyselyyn.
  • XSS:lle Lightning tarjoavat automaattisen suojan LWC- renderöintijärjestelmän kautta.
  • Aura-komponenteille ja Visualforcelle sinun täytyy käyttää sovellusalustan koodausfunktioita (esimerkiksi HTMLENCODE, JSENCODE ja URLENCODE), kun renderöit dynaamista sisältöä.

Oma vastuusi: Ota CRUD/FLS käyttöön mukautetussa koodissa, käytä koodausfunktioita, käytä sidottuja muuttujia ja valvo kokoonpanovirtoja.

Suunnittele CI/CD-putket, jotka sisältävät suojaus portteja jokaisessa vaiheessa. Suojaus täytyy automatisoida, jotta se skaalataan kehitysnopeudella.

Nyt tutustumme tarkemmin myyntiputken suojausvaiheisiin.

• Lähteiden hallinta käyttää haarojen suojaussääntöjä, jotka vaativat koodin tarkastuksia. Päähaarojen tai allekirjoitettujen sitoumusten suoria sitoumuksia ei ole.
• Staattinen analyysi käyttää Salesforce Code Analyzeria, joka sisältää PMD-, ESLint- ja RetireJS-tiedostoja injektio-, XSS- ja suojaamattoman kuvion havaitsemiseen.
• Tietoturvatarkistus käyttää SAST-työkaluja ja salaisuuksien tunnistusta estääkseen tunnusten sitouttamisen ja riippuvuuksien haavoittuvuuksien skannauksen.
• Käyttöoikeuksien vahvistus käyttää automatisoituja vertailutapoja tarkastaakseen käyttöoikeuksien muutokset tietoturvan perustasojen perusteella, mikä lähettää hälytyksiä käyttöoikeuksien laajentamisesta.
• Käyttöönottosiltaet keskeyttävät käyttöönoton kriittisten tietoturvatietueiden perusteella, jotka vaativat tietoturvatiimin hyväksynnän käyttöoikeuksien laajentamiseen käytettäviä muutoksia varten.
• Käyttöönoton jälkeinen valvonta käyttää Event Monitoring -hälytyksiä poikkeaville toiminnoille käyttöönottojen jälkeen.

Oma vastuusi: Integroi Code Analyzer CI/CD-tiedostoon, määritä haaratoimiston suojaus, ota käyttöön käyttöönottoportaalit ja vahvista käyttöoikeudet automaattisesti.

Kattava tietoturvatestaus sisältää useita tekniikoita, jotka käsittelevät eri haavoittuvuusluokkia. Nyt tutustumme tarkemmin kuhunkin strategiaan.

• Staattinen analyysi suorittaa Salesforce Code Analyzerin kehittäjien IDEs-organisaatioissa välittömästi palautetta varten ja CI/CD-putkissa automaattisina portteina. Staattinen analyysi tunnistaa lähdekoodin haavoittuvuudet suorittamatta sovellusta.
• Penetration Testing suorittaa penetration-testejä mukautetuille sovelluksille, jotka ovat alttiina epäluotettaville käyttäjille, erityisesti Experience Cloud -sivustoille ja julkisille API-rajapinnoille.
  • Staattiset analyysiraportit ovat aina pakollisia AppExchange ja AgentExchange-suojaustarkastukselle.
  • Dynaaminen skannausraportti (lähennystesti) on pakollinen, kun ratkaisu integroi kolmannen osapuolen verkkosovelluksen tai palvelun.
  • Penetraation testaaminen simuloi hyökkääjien tekniikoita live-sovelluksia vastaan.
• Tietoturvaan keskitetyt yksikkötestit kirjoittavat Apex-testejä, jotka vahvistavat käyttöoikeuksien valvontaa käyttämällä käyttäjiä eri käyttöoikeusprofiileilla. On tärkeää varmistaa, että CRUD/FLS-valvonta estää valtuuttamattoman käytön.
• Riippuvuuksien skannaus valvoo AgentExchange-paketteja ja JavaScript-kirjastoja tunnettujen haavoittuvuuksien varalta. On tärkeää tilata asennettujen pakettien suojausohjeet.

Oma vastuusi: Suorita Code Analyzer, suorita syöttötestiä, kirjoita suojausyksikkötestejä ja skannaa sidonnaisuuksia.

Salesforcessa tietoturva- ja datavahinkotapahtumien vastaaminen keskittyy tietoturvarikkomusten, valtuuttamattomien käyttöoikeuksien ja haitallisen datan tuhoamisen havaitsemiseen, säilyttämiseen ja palauttamiseen. Vahinkotapahtumien vastaustiimit toimivat rinnakkain kahden naapuripilarin kanssa, joilla on toisiaan vastaavat vastuut:

• Operational Excellence kattaa vahinkotapahtumien hallinnan toimintamallin (esimerkiksi vakavuustasot, puheluiden kierrättäminen, eskalointi ja vahinkotapahtumien jälkeinen tarkastus)
• Luotettavuus kattaa saatavuuden palautuksen RTO- ja RPO-kohteisiin nähden, mukaan lukien varmuuskopio- ja katastrofien palautustrategia.

Arkkitehtinä sinun vastuullasi on suunnitella tietoturvahyökkäysten havaittavuus, reagointi ja palautus.

Havaittavuus on arkkitehtoninen ominaisuus, johon sinun täytyy suunnitella se erikseen. Ilman kattavaa valvontaa tietoturvahyökkäyksiä ei välttämättä havaita pitkältä aikaväliltä.

On tärkeää toteuttaa havaitseminen useiden kanavien kautta.

• Event Monitoring kaappaa raaka-tapahtumalokeja, jotka kattavat sisäänkirjautumiset, raporttien ja datan viennit, käyttöoikeuksien muutokset ja API-kutsut. Sinun täytyy tunnistaa poikkeavat tapahtumat, jotka vaativat transaktioiden suojauskäytäntöjä tai SIEM-korrelaatiota lokien päälle, jotka määrität havaintologiikan määrittämiseksi.
• Transaktioiden suojauskäytännöt arvioivat tapahtumat reaaliajassa ja estävät epäilyttävät toiminnot. Sinun täytyy määrittää nämä käytännöt.
• Määritysloki seuraa sovellusalustan tarjoamia hallinnollisia muutoksia, mutta sinun täytyy valvoa niitä.
• Mukautetun sovelluksen kirjaaminen lokiin kaappaa tietoturvaan liittyvät tapahtumat Apexissa, jotka sinun täytyy ottaa käyttöön.

Reititä Event Monitoring -lokeja SIEM-alustoille korreloidaksesi yrityksen tietoturvatelmetrian kanssa. Suunnittele hälytyssääntöjä, jotka havaitsevat epäilyttäviä kuvioita ja minimoivat myös vääriä positiivisia tietoja käyttäytymisen perustasoilla.

Oma vastuusi: Reititä Event Monitoring -ominaisuus SIEM:ään, määritä transaktioiden suojauskäytäntöjä, ota käyttöön mukautettu loki ja määritä toimintatavan perustasot.

On tärkeää dokumentoida arkkitehtoniset päätökset, jotka tukevat vahinkotapahtumien vastausta ennen vahinkotapahtumien tapahtumista.

• Eristysrajat suunnittelevat ratkaisuja eristääkseen vaarantuneet komponentit häiritsemättä kriittisiä liiketoimintatoimintoja. Sinun täytyy määrittää käyttöoikeusjoukon kumoaminen, IP-rajoitusten muutokset ja istunnon lopettaminen tarjotaksesi nopean eristysominaisuuden.
• Oikeudellinen säilyttäminen käyttää tapahtumien valvontaa tarjotakseen yksityiskohtaisia toimintolokeja (alustan ominaisuus). Kenttien kirjausketju säilyttää datan muutoshistorian kokoonpanosi perusteella. Suunnittelulokit reititetään muuttumattomaan tallennustilaan, jotta hyökkääjät eivät voi muokata arkkitehtuuria.
• Palautustoimenpiteet dokumentoivat testatut palautusprosessit yleisimmille vahinkotapahtumatyypeille. On tärkeää vahvistaa varmuuskopioiden eheys säännöllisesti. Sinun täytyy tietää palautusajan tavoite (RTO) ja palautuspisteen tavoite (RPO) tietoturvahyökkäysten skenaarioissa.
• Viestintätyönkulut suunnittelevat ilmoitusmekanismeja, jotka toimivat vahinkotapahtumien aikana (esimerkiksi kaistan ulkopuoliset viestintäkanavat, valmiiksi luodut mallit ja eskalointitoimenpiteet, jotka eivät riipu mahdollisesti vaarantuneista järjestelmistä).
• Haavoittuvuuksien paljastuskanava on tarkoitettu julkisille Experience Cloud -sivustoille. Se tarjoaa ulkoisille tutkijoille dokumentoidun ja valvotun tavan ilmoittaa sinulle tietoturvaongelmista RFC 9116 security.txt -standardissa julkaistun ilmoituskäytännön kautta. Ulkoinen raportti on usein vahinkotapahtuman ensimmäinen signaali, joten on tärkeää luoda tämä syöttöpolku osana arkkitehtuuria, josta olet vastuussa.

Oma vastuusi: Asiakirjojen eristystoimenpiteet, lokien reitittäminen muuttumattomaan ulkoiseen tallennustilaan, palautustoimenpiteiden testaaminen neljännesvuosittain, kaistan ulkopuolisen viestinnän luominen ja haavoittuvuuksien paljastuskanavan julkaiseminen julkisille sivustoille.

Salesforcessa on tärkeää valmistella vastauskykyjä sovellusalustakohtaisille skenaarioille.

• Vaarantuneet käyttäjätilit havaitaan Event Monitoringin sisäänkirjautumisaikojen kautta (esimerkiksi odottamattoman maantieteellisen sijainnin, epätavalliset ajat ja uudet laitteet). Kun tilit vaarantuvat, jäädytä käyttäjä, pakotta tunnusten nollaus, tarkasta määritysloki ja tietojen käyttöoikeuslokit määrittääksesi kompromissin ajanjakson.
• Joukkodatan suodatus havaitaan Event Monitoring -raporttien viennillä ja API-tietojen käyttöoikeuksien määrän poikkeavuuksilla. Kun tietoja suodatetaan, kumoa istunnot välittömästi, rajoita käyttöoikeuksia ja tunnista asiaankuuluvat tietueet ja luokittelutasot.
• Valtuuttamaton koodin käyttöönotto havaitaan käyttöönoton valvonnan ja määrityslokien kokoonpanon muutosten kautta. Kun valtuuttamaton koodi otetaan käyttöön, peruuta käyttöönotto välittömästi ja tarkasta kaikki muutokset vaarantuneesta käyttöönoton tunnuksesta.
• Oikeuksien eskalointi havaitaan määrityslokien valvonnan kautta käyttöoikeuksien muutoksille, jotka ovat hyväksyttyjen muutosikkunoiden ulkopuolella. Kun käyttöoikeudet eskaloidaan, kumoa eskaloidut käyttöoikeudet välittömästi ja tarkasta käyttöoikeuksien parannuksella suoritetut toiminnot.

Oma vastuusi: Dokumentoi sovellusalustakohtaisten skenaarioiden vastausmenetelmät, määritä valvonta havaitaksesi kunkin skenaarion ja testaa toimenpiteitä työpöytätoimintojen avulla.

Vahinkotapahtuman jälkeen on tärkeää suorittaa arvioimaton vahinkotapahtuman jälkeinen tarkastus, joka keskittyy arkkitehtuurin parannuksiin. Sinun täytyy dokumentoida, mitä tapahtui, miksi olemassa olevat ohjaimet eivät voineet estää tai havaita vahinkotapahtumaa ja mitä arkkitehtonisia muutoksia tarvitaan tulevien riskien vähentämiseksi.

Vahinkotapahtuman jälkeisten tarkastusten tavoitteet:

• Määritä vahinkotapahtuman aikajana ja hyökkääjien tekniikat.
• Tunnista vahinkotapahtuman käynnistäneet hallintavirheet.
• Dokumentoi kaikki vahinkotapahtuman paljastamat arkkitehtuurin heikkoudet.
• Priorisoi riskin vähentämiseen perustuva korjaus.
• Jaa oppitunteja eri tiimeille.
• Päivitä havaintosäännöt ja vastausmenetelmät.

On tärkeää seurata vahinkotapahtumien tilastoja pitkältä aikaväliltä määrittääksesi havaittavan keskiarvoisen ajan (MTTD), vastauksen keskiarvoisen ajan (MTTR) ja vaikutuksen vaikutusalueen.

Oma vastuusi: Suorita vahinkotapahtuman jälkeinen tarkastus ajoissa, dokumentoi ADR-parannukset, seuraa MTTD- ja MTTR-trendejä ja jaa oppitunteja.

Käytä tätä tarkistuslistaa arkkitehtuurin tarkastuksissa, ennen tuotantoympäristön käyttöönottoa ja säännöllisesti jatkuvaa arviointia varten. Jokainen kohde edustaa Salesforce-arkkitehtuurin vastuuta.

Jaettu vastuu

• Dokumentoi kaikki Salesforcen suojaamat kohteet (esimerkiksi infrastruktuuri, sovellusalusta ja vaatimustenmukaisuussertifikaatit).
• Dokumentoi kaikki, mitä sinun täytyy suojata (esimerkiksi kokoonpano, käyttöoikeus, mukautettu koodi ja datan hallinta).
• Tunnista jaetut vastuualueet (esimerkiksi vahinkotapahtumien vastaus, haavoittuvuuksien hallinta ja valvonta).
• Ilmoita vastuusta sidosryhmille ja toteutustiimeille mahdollisimman selkeästi ja ytimekkäästi.

Tietoturva-arkkitehtuuri

• Suorita uhkien mallinnus loppuun käyttämällä STRIDE-metodologiaa ennen kuin aloitat rakentamisen.
• Käytä datalle, sovellukselle, identiteetille ja integraatiokerroksille syvällisiä puolustusasetuksia.
• Käytä nollatason Trust-periaatteita, jotka vaativat suoran vahvistuksen jokaiselle käyttöoikeuspyynnölle.
• Ylläpidä tämänhetkistä suojausresurssien inventaariota, joka kattaa luottamukselliset tiedot, integraatiot, API-rajapinnat ja etuoikeutetut tilit.
• Asiakirjojen tietoturva-arkkitehtuurin päätökset ADR-järjestelmissä, mukaan lukien uhkien analyysi ja hallinnan perustelut.
• Suojele Headless-asiakkaita ja asiakkaita Salesforce Trust -rajan puolesta propagoimalla käyttäjäkohtaisia identiteettejä pool-valtuuksien sijaan.
• Tallenna, kierrä ja vähiten oikeutettuja OAuth-tunnuksia ulkoisten asiakassovellusten kautta.
• Jos käytät säiliöön perustuvia integraatioita, käytä säiliöiden eristämistä tietoturvarajoituksena, salaa säiliöiden välinen ja hybridipalveluiden VPN-liikenne mTLS:llä (kun kehysjärjestelmä vaatii sitä) ja kohdista käyttöönottoryhmät datan asuin- ja vaatimustenmukaisuussertifikaatteihin

Identiteetin ja käyttöoikeuksien hallinta

• Määritä OWD-arvo Yksityinen objekteille, jotka sisältävät luottamuksellisia tietoja.
• Varaa Julkinen vain luku -asetus objekteille, joiden laaja lukuoikeus on dokumentoitu vaatimus.
• Ota MFA käyttöön kaikille tuotanto-käyttöliittymän käyttöoikeuksille ja sovella etuoikeutettujen tilien laitteistoturva-avaimia. Vain API -integraatiot, jotka käyttävät JWT Beareria tai asiakassovelluksen tunnuksia, ovat vapautettuja.
• Toteuta SSO käyttämällä SAML 2.0- tai OpenID Connectia vahvalla henkilöllisyydentarjoajan todennuksella.
• Käytä kaikkien API-todennusten OAuth 2.0 -todennusta (JWT Bearer preferred). Älä käytä koskaan upotetuille tunnuksille OAuth 2.0 -todennusta.
• Myönnä käyttöoikeudet käyttämällä käyttöoikeusjoukkoja, jotka perustuvat dokumentoituihin vähimmäisvaltuuksien vaatimuksiin.
• Käytä tehostettuja asetuksia kriittisille tilille (esimerkiksi IP-rajoitukset, sisäänkirjautumishälytykset ja käyttöoikeuksien säännölliset tarkastukset).
• Suorita säännöllisiä käyttöoikeustarkistuksia käyttämällä dokumentoitua todistusta korkean oikeutuksen tileille, joiden yleisyys riippuu organisaation riskien toleranssista ja vaatimustenmukaisuudesta.
• Automatisoi henkilöllisyyden elinkaari SCIM-provisioinnin ja 90 päivän pysyvän tilin tunnistuksen avulla.
• Suorita työntekijäagentteja sisäänkirjautuneen käyttäjän asiayhteydessä ja provisioi asiakkaan agenteille oma, vähiten etuoikeutetut agenttikäyttäjät. Älä koskaan tee näin julkisen sivuston vieraskäyttäjälle.
• Toteuta JWT agenttien todennukselle käyttämällä agenttien esiintymien ja bottien määritelmien tunnisteita.
• Määritä ABAC-käytäntöjä, jotka noudattavat datan luokittelua ja yhdenmukaisia metadatan merkintästandardeja.

Datan suojaus ja yksityisyys

• Luokittele kaikki tiedot ja käytä kullekin luokittelutasolle sopivia suojausasetuksia.
• Ota Shield Platform Encryption käyttöön rajoitetulle datalle käyttämällä dokumentoitua avainten hallintaa.
• Vaadi TLS 1.2+ kaikille integraatioille, joilla on sertifikaatteihin perustuva todennus rajoitetulle datalle.
• Estä rajoitettuja tietoja pääsemästä muihin kuin tuotantoympäristöihin peittämällä niitä tai jättämällä ne pois.
• Ota suostumusten hallinta käyttöön tarkkojen käyttötarkoituskohtaisten seuranta- ja peruutustyönkulkujen avulla.
• Laadi datan aiheiden oikeuksien työnkulkuja, jotka suoritetaan kunkin hallintakehyksen vastauksen määräaikaan mennessä. Nämä tulisi koostaa liiketoimintajalanjälkesi pienimpään ikkunaan ja parametrisoida lainkäyttöalueittain ylläpidetystä vaatimustenmukaisuuden lähteestä, jossa jokainen numero on vahvistettu säännösten mukaisesti.
• Dokumentoi datan residenssin vaatimukset ja vahvista Hyperforce tasaus.

Yhteensopivuus ja säännösten noudattaminen

• Vahvista sovellusalustan sertifikaatit, jotka täyttävät toimialaasi koskevat lakisääteiset vaatimukset.
• Ota Event Monitoring käyttöön SIEM-reitityksellä säilyttämistä varten, joka ylittää natiivin säilytyrajoitukset.
• Määritä kenttien kirjausketju kattamaan rajoitetut kentät varmistaaksesi, että säilytys noudattaa sääntelyyn liittyviä vähimmäisvaatimuksia.
• Pidä tietoturvan terveystarkastuksen pisteet 80 % tai korkeammalla (Erittäin hyvä tai Erinomainen nauha) ja dokumentoi mahdolliset poikkeukset.
• Automatisoi yhteensopivuuden vahvistus CI/CD-putkille, jotka rikkoutuvat kriittisten rikkomusten aikana.
• Toteuta transaktioiden suojauskäytäntöjä poikkeavuuksien havaitsemiseen ja niihin reagoimiseen reaaliajassa.

Turvallisen kehityksen elinkaari

• Suorita uhkien mallinnus suunnitteluvaiheen aikana (ennen kuin teet merkittäviä rakennusinvestointeja).
• Ota CRUD/FLS käyttöön kaikissa Apex.
• Luota käyttäjätilan automaattiseen käyttöönottoon API-versiolle 67.0 tai sitä uudemmille tai käytä WITH USERMODE- tai stripInaccessible()-funktiota API-versiolle 66.0 tai sitä vanhemmille.
• Älä käytä SECURITYENFORCED-funktiota, joka poistettiin API-versiosta 67.0.
• Suorita Salesforce Code Analyzer CI/CD:ssä, kun kriittiset havainnot estävät käyttöönoton.
• Vaadi koodin tarkastuksia tietoturvatietoisilta tarkastajilta kaikista tuotantoympäristön muutoksista.
• Suorita syöttötestauksia kaikille julkisille sovelluksille ja Experience Cloud -sivustoille.
• Vahvista ja sanaloi kaikki käyttäjän syöttämät tiedot, jotka estävät syöttämisen SOQL-, SOSL- ja HTML-kontekstissa.

Suojaustapahtuman vastaus

• Suunnittele Event Monitoring -hälytyssääntöjä havaitaksesi epäilyttäviä kuvioita käyttäytymisen perustasoilla.
• Reititä lokit muuttumattomaan ulkoiseen tallennustilaan oikeudellista säilyttämistä varten.
• Dokumentoi ja testaa vahinkotapahtumien vastausmenetelmiä sovellusalustakohtaisille skenaarioille.
• Suorita virheettömiä vahinkotapahtumien jälkeisiä tarkastuksia ADR-osoitteiden avulla tallentaaksesi arkkitehtonisia parannuksia.
• Seuraa MTTD- ja MTTR-tilastoja tunnistaaksesi havaintojen ja vastausten aukkoja.

Jaa palautetta hyvin rakennetusta kehysjärjestelmästä.