CRM-data tuntuu rauhalliselta, kunnes token alkaa liikkua itsestään.
Myyntitiimit tallentavat yhteyshenkilöiden nimet, uusimissignaalit, putkihuomautukset, tukikontekstit, kumppanihistorian, puheluyhteenvedot, hinnoittelun, hankintailmoitukset ja ostajien vastalauseet yhteen paikkaan. Tästä järjestelmästä tulee tulojen muisto. Kun yhdistetty SaaS-sovellus saa laajan pääsyn kyseiseen muistiin, riski siirtyy itse sovelluksen ulkopuolelle.
Kesäkuussa 2026 Hacker News raportoi, että Salesforce poisti Klue Battlecards -sovelluksen integroinnin käytöstä epäilyttävän OAuth-tunnustoiminnan jälkeen, joka on saattanut sallia luvattoman pääsyn asiakastietoihin Klue-yhteyden kautta. Myöhemmin Klue kertoi löytäneensä luvatonta toimintaa, joka vaikutti osaan sen integrointiinfrastruktuuria ja että hyökkääjä pääsi sisäänsä integraatiopalveluun yhdistetyn vanhan tunnistetiedon kautta.
Ostajille tärkeä asia on suora. Julkisissa raporteissa ei kuvattu Salesforce-alustan haavoittuvuutta. He kuvasivat kolmannen osapuolen integraatiopolun. Tämä on se osa, jota monet yritykset kaipaavat tietoturvatarkastuksen aikana.
Hyväksytystä integraatiosta voi tulla ovi.
Mitä julkinen raportointi sanoo
Salesforcen mukaan yritys poisti Klue Battlecardsin ja Salesforcen välisen yhteyden suojellakseen asiakkaita havaittuaan sovellukseen liittyvää epätavallista toimintaa. Hacker News lainasi Salesforcen sanoja, että ongelma rajoittui Klue-sovelluksen yhteyteen eikä johtunut Salesforcen sisällä olevasta haavoittuvuudesta.
Klue sanoi, että tapaus alkoi vaarantuneesta integraatiopalveluun liittyvästä vanhasta tunnistetiedosta. Sieltä hyökkääjä sai OAuth-tunnukset, joita käytettiin Kluen yhdistämiseen kolmansien osapuolien alustoihin, mukaan lukien Salesforce. Klue sanoi, että se peruutti asiaan liittyvät valtuustiedot ja tunnukset, poisti luvattoman koodin, pysäytti etäkäytön, poisti käytöstä mahdollisesti vaikuttaneet integraatiot ja aloitti laajemman tutkimuksen.
Huntress sanoi, että sen Salesforce-tililtä kopioidut tiedot sisälsivät yrityskontakteja, hintatarjouksia sekä myyntiin liittyviä tietoja ja viestejä. Huntress sanoi myös, että uhkatietoihin, salasanoihin, maksukorttitietoihin ja sen agenttiin tai telemetriaan liittyviin teknisiin tietoihin ei ollut vaikutusta. Myöhemmin raportoitu, että Huntressiin liittyvät tiedot ilmestyivät vuotosivustolle, ja Huntress vahvisti, että lähetetty 3,4 Gt:n tietojoukko oli laillinen ja rajoitettu Salesforcen CRM-tietoihin.
Datadog Security Labs kuvaili mallia Kluen toimitusketjuhyökkäykseksi Salesforce-instanssia vastaan. Sen mukaan Klue hälytti asiakkaita 13. kesäkuuta 2026 sen jälkeen, kun Salesforcen ja Gongin OAuth-tunnukset oli jo kerätty ja automatisoidut API-puhelut alkaneet. ReliaQuest raportoi, että vastustaja todennettiin vaarantuneen Klue-integraatiopalvelutilin kautta, loi OAuth-tunnisteita ja käytti sitten automaattisia komentosarjoja tehdäkseen kyselyitä Salesforce REST API-päätepisteistä lähes 24 tunnin ajan.
Se riittää määrittelemään liiketoiminnan oppitunnin. SaaS-riski piilee nyt kolmannen osapuolen valtuuuksissa, vanhentuneissa palveluvaltuuksissa, sovellusapurahoissa, API-kyselymalleissa ja tunnuksen käyttöiässä.
Kuinka polku toimi
OAuth on suunniteltu antamaan yhden sovelluksen toimia luvalla toisen sisällä. Käyttäjä tai järjestelmänvalvoja myöntää käyttöoikeuden. Sovellus vastaanottaa tokeneja. Nämä tunnukset antavat sovelluksen kutsua APIs:ta kysymättä salasanaa joka kerta.
Tuo suunnittelu on hyödyllinen. On myös vaarallista, kun tunnus ylittää todellisen liiketoiminnan tarpeen, kun yhdistetyllä sovelluksella on tarvittavaa laajempi käyttöoikeus tai kun integroinnin omistajaa kohdellaan vähäriskisenä, koska se on tuttu.
Julkinen raportointi Kluen tapauksesta viittaa tuttuun ketjuun:
- Integraatioinfrastruktuuriin liitetyistä perinteisistä valtuuksista tuli ensimmäinen jalansija.
- Hyökkääjä käytti tätä jalansijaa saavuttaakseen OAuth-tunnukset.
- Tokenit mahdollistivat pääsyn yhdistettyihin asiakasympäristöihin.
- Automaattiset komentosarjat kyselivät Salesforce-tietoja tavallisten API-polkujen kautta.
- Toiminta näytti integraatioliikenteeltä, kunnes joku esitti terävämmän kysymyksen.
Tästä syystä OAuth-tarkistus tarvitsee erilaisen ajattelutavan kuin tavallinen käyttäjätilin tarkistus. Ihmiskäyttäjällä on tehtävänimike, johtaja, kirjautumismalli, laite ja näkyvä työnkulku. Yhdistetyllä sovelluksella on usein laaja käyttöoikeus, korkea pysyvyys, rajoitettu käyttäytymisen seuranta eikä luonnollista päivittäistä omistajaa.
Tili voi olla hiljaa kuukausia, jolloin siitä tulee yrityksen äänekkäin riski.
Miltä vahinko näyttää
Julkinen raportointi antaa useita konkreettisia vaikutusalueita.
Ensimmäinen on CRM-tietojen paljastaminen. Yrityskontaktit, nimet, sähköpostit, puhelinnumerot, osoitteet, tarjoukset, tukitapaustiedot, sopimustiedot ja myyntiin liittyvät viestit voivat riittää vahingoittamaan yritystä. Rikollinen ei tarvitse salasanatietokantaa aiheuttaakseen vahinkoa. CRM-konteksti voi edistää tietojenkalastelua, laskupetoksia, kumppanina esiintymistä, sijoittajien painostusta, kilpailijoiden tiedustelua ja kiristystä.
Toinen on neuvottelualtistus. Myyntitiedot osoittavat, mistä ostajat välittävät. Hintatiedot osoittavat alennuslogiikan. Mahdollisuustietueet osoittavat uusimisen ajoituksen. Tukimuistiinpanot osoittavat turhautumista. Kaikkea tätä voidaan käyttää työntekijöiden ja asiakkaiden painostamiseen viesteillä, jotka tuntuvat todellisilta.
Kolmas on sosiaalisen manipuloinnin seuranta. Jos hyökkääjä tuntee asiakkaan, tilivastaavan, uusimispäivämäärän, ostajan huolenaiheen ja viimeisen tukiaiheen, seuraava sähköposti näyttää vähemmän satunnaiselta. Se voi kuulostaa tavalliselta keskustelulta.
Neljäs on maineeseen kohdistuva paine. Yritys voi ehkä sanoa, että salasanat ja maksukortit eivät kuuluneet soveltamisalaan, ja se voi olla totta. Ostaja kuulee edelleen toisen viestin: kolmannen osapuolen liitin saavutti yritysdatan. Tämä herättää kysymyksiä asiakkailta, kumppaneilta, hankintatiimeiltä, vakuutuksenantajilta ja johdolta.
Viides on todiste velkaa. Merkkitapahtuman jälkeen yritys tarvitsee vastauksia nopeasti:
- Millä yhdistetyillä sovelluksilla oli pääsy?
- Mitä kohteita kysyttiin?
- Mitä peltoja vietiin?
- Keitä asiakkaita koskettivat?
- Mitkä tunnukset peruutettiin?
- Mitkä integraatiot poistettiin käytöstä?
- Mitkä lokit säilytetään?
- Mitkä säätimet estävät toistuvan toiminnan?
Jos yritys ei pysty vastaamaan näihin kysymyksiin, tapaus jatkuu myynti- ja lakikeskusteluissa vielä pitkään teknisen eristämisen jälkeen.
Miksi tämä pelottaa vakavia ostajia
Pelottava osa on tavallinen pinta.
Useimmat SaaS-ympäristöt sisältävät vuosia yhdistettyjä sovelluksia. Markkinointityökalut, myynnin mahdollistavat työkalut, tukityökalut, rikastustyökalut, analytiikkatyökalut, tietovarastot, tekoälyavustajat, puheluiden tallentimet, BI-liittimet, varmuuskopiointityökalut, matalakoodiautomaatit ja integrointialustat pyytävät käyttöoikeutta. Monet saavat sen. Harvemmat menettävät sen, kun alkuperäinen projekti päättyy.
Ajan myötä SaaS-tilasta tulee varjoalue. Palomuuri voi olla vahva. MFA voi olla vahva. Työntekijän laitteita voidaan hallita. Silti kolmannen osapuolen OAuth-tunnus voi kävellä sivusisäänkäynnin läpi, koska yritys on hyväksynyt sen kuukausia tai vuosia sitten.
Pienet yritykset tuntevat tämän asiakkaiden luottamuksen kautta. Yksi tapaus voi hidastaa yrityskauppoja. Ostajat pyytävät todisteita siitä, että integraatiot on inventoitu, rajattu, valvottu ja peruutettu, kun ne ovat vanhentuneet.
Keskisuuret yritykset tuntevat tämän hankintojen kautta. Kumppani pyytää luetteloa yhdistetyistä SaaS-työkaluista. Turvallisuus pyytää käyttöoikeuksia. Lakimies kysyy, kuka käsittelee mitäkin tietoja. Myynti kysyy, milloin kauppa voi siirtyä.
Yritysyritykset tuntevat tämän mittakaavassa. Sadat osastot ja työkalut luovat tuhansia apurahoja. Yhdestä heikosta integraatiosta voi tulla tie dataan, jota johtajat luulivat ensisijaisen alustan suojaavan.
Tekninen sana on OAuth. Liikesana on paljastaminen.
Mitä joukkueiden pitäisi nyt tarkastaa
Aloita täydellä yhdistettyjen sovellusten mainosjakaumalla. Vie kaikki asennetut Salesforceen yhdistetyt sovellukset, OAuth-avustukset, integrointikäyttäjät, palvelutilit, päivitystunnisteluokka ja kolmannen osapuolen hallinnoimat paketit. Sisällytä Gong, HubSpot, Slack, Google Workspace, Snowflake, tukipöydät, rikastustyökalut ja tekoälytyökalut, joissa ne koskettavat CRM-tietoja.
Sijoita sitten räjähdyksen säteen mukaan. Liitin, joka voi lukea tilejä, yhteystietoja, liidejä, tilaisuuksia, tapauksia, mukautettuja objekteja ja tiedostoliitteitä, kuuluu ylimpään tasoon. Liitin, jossa on päivitystunnuksia ja jolla ei ole aktiivista omistajaa, kuuluu ylimpään tasoon. Lentäjälle asennettu ja hengissä pidetty liitin kuuluu ylimpään tasoon.
Tarkista laajuudet. Monet integraatiot saavat laajan pääsyn, koska se oli helpompaa asennuksen aikana. Siitä syntyy hiljainen vastuu. Tulotyökalu harvoin tarvitsee jokaista esinettä ikuisesti. Raportointityökalu tarvitsee harvoin kirjoitusoikeutta. Vanhentunut integraatio on poistettava.
Tarkista tunnukset ja istunnot. Peruuttamisen on oltava todellinen. Hallintakonsolin valintaruutu on heikompi kuin todisteet siitä, että tunnukset, päivitystunnukset, istunnot ja yhdistettyjen sovellusten käyttöoikeudet on mitätöity. Kun tapaus koskee myyjää, kysy, mitä hän peruutti ja mitä sinun on peruutettava paikallisesti.
Tarkista lokit normaalin näköisen väärinkäytön varalta. Kluen tapauksessa raportointi kuvasi API-kyselyitä ja automaattisia käyttäjäagentteja. Ryhmän tulee etsiä epätavallista kyselymäärää, off-hour API purskeita, uusia lähdeverkkoja, objektien luettelointia, joukkosivutusta ja pääsyä infrastruktuurista, joka ei vastaa toimittajan normaalia jalanjälkeä.
Tarkista hälytykset. Monet tunnistusohjelmat varoittavat työntekijöiden mahdottomasta matkustamisesta eivätkä hälytä integraatiotileistä, jotka keräävät täyden objektiluettelon. Sillä erolla on merkitystä. Integrointitilit tarvitsevat käyttäytymisen perusviivat, datamäärän kynnykset ja muutoshälytykset.
Tarkista sopimukset ja tapahtumapolut. Jos toimittajalla on OAuth-tunnuksia ympäristöäsi varten, sopimuksessasi ja käyttöönottopolussasi tulee kertoa, kuinka tunnukset tallennetaan, kuinka niitä kierrätetään, miten sinulle ilmoitetaan, kuinka nopeasti ne voidaan peruuttaa, mitä lokeja ne säilyttävät ja mitä tapahtuu, kun heidän oma infrastruktuurinsa vaarantuu.
Ohjauskartan ostajat haluavat nähdä
Yritysostajat pyytävät harvoin täyttä raakavientiä CRM-tietoturvakonsolista. He pyytävät yksinkertaisempaa vastausta, joka todistaa kypsyyden. Parhaassa vastauksessa on viisi osaa.
Käyttöoikeusvarasto tulee ensin. Yrityksen tulisi näyttää, mitkä yhdistetyt sovellukset voivat lukea tai kirjoittaa CRM-tietoja. Luettelon tulee sisältää omistaja, toimittaja, liiketoiminnan tarkoitus, laajuudet, tietoluokat, viimeinen tarkistuspäivä ja poistopolku.
Laajuuskuri tulee toiseksi. Jokaisella sovelluksella tulee olla syy jokaiselle tärkeälle luvalla. Laajat käyttöalueet, kuten täysi API-käyttö, offline-käyttö, kirjoitusoikeudet, vientioikeudet ja käyttöoikeudet mukautettuihin objekteihin, tarvitsevat vahvemman perustelun.
Valvonta tulee kolmanneksi. Vakava ostaja haluaa tietää, että API-käyttöä valvotaan. Tiimin tulee valvoa volyymia, objektien yhdistelmää, epätavallisia kyselymalleja, lähteen muutoksia, käyttäjäagentin muutoksia ja pääsyä toimittajan normaalin toimintamallin ulkopuolelle.
Peruuttamisvalmius on neljäs. Yrityksen pitäisi pystyä peruuttamaan kolmannen osapuolen integraatio nopeasti rikkomatta koko tulotiimiä. Tämä edellyttää nimettyjä omistajia, dokumentoituja varaosia ja testattua prosessia.
Todisteet tulevat viidenneksi. Tarkastuksen jälkeen yrityksen tulee pitää kirjaa. Kuvakaappaukset, vienti, vaihtoliput, lokikyselyt, tunnuksen peruutustietueet ja uudelleentestausmuistiinpanot ovat tärkeitä, koska ne lyhentävät myynti- ja huolellisuuskeskusteluja.
Tämä ohjauskartta on ero epämääräisen turvavastauksen ja ostajan valmiin vastauksen välillä.
Kysymykset tulojohtajien tulee kysyä
CRM-tietoturva kuuluu tulojen johtamiseen. Liikevaihtojohtajien tulisi ymmärtää riski, koska tiedot kuuluvat myyntiliikkeeseen.
Kysy, mitkä tulotyökalut voivat lukea putkia ja yhteystietoja. Kysy, mitkä työkalut voivat viedä mahdollisuuden huomautuksia. Kysy, onko entisillä lentäjillä vielä pääsy. Kysy, voivatko tekoälyavustajat nähdä herkän sopimuksen kontekstin. Kysy, voivatko kumppaniintegraatiot lukea liitteitä. Kysy, onko jokaisella integraatiolla omistaja, joka työskentelee edelleen yrityksessä.
Kysy, mitä tapahtuisi, jos myyjä ilmoittaisi tunnuksen väärinkäytöstä tänään. Kuka poistaisi sovelluksen käytöstä? Kuka puhuisi asiakkaille? Kuka tarkastaisi lokit? Kuka kertoisi myyntiin, mitkä kaupat vaikuttivat? Kuka tuottaisi puhtaan vastauksen hankintoihin?
Nämä kysymykset ovat epämiellyttäviä. Se on pointti. Yrityksen tulee tuntea paine harjoituksissa eikä aktiivisen kiristysviestin aikana.
Turvallisempi SaaS hyväksyntäpolku
Uusien SaaS-työkalujen tulee läpäistä lyhyt turvaportti ennen kuin ne saavat CRM-käyttöoikeuden.
Portin tulee määritellä liiketoiminnan tarve, tarkat vaadittavat tiedot, luvan laajuus, tunnuksen käyttöikä, toimittajan tallennusmalli, tapahtumailmoituspolku, asiakkaan käytettävissä oleva kirjaus ja omistaja yrityksen sisällä.
Portin tulee myös määrittää uloskäynti. Jokainen integrointi tarvitsee poisto- tai tarkistuspäivämäärän. Jokainen lentäjä tarvitsee automaattisen siivouksen. Jokainen toimittajan muutos vaatii vahvistuksen. Jokainen korkean riskin lupa tarvitsee toisen henkilön hyväksymään sen.
Sen portin ei tarvitse hidastaa liiketoimintaa. Sen pitäisi nopeuttaa liiketoimintaa estämällä tulevaisuuden sekaannukset. Myyntityökalu, jonka hyväksyminen kestää kaksi ylimääräistä päivää, on halvempi kuin myyntityökalu, joka aiheuttaa kahden kuukauden ostajan huolen.
Tekoälyyn yhdistetyille tulotyökaluille sama tie tiukenee. Jos työkalu pystyy lukemaan puhelujen transkriptioita, CRM-muistiinpanoja, tukihistoriaa tai ostajien vastalauseita, se käsittelee arkaluontoista yritysmuistia. Se ansaitsee seuranta- ja poistosäännöt ensimmäisestä päivästä lähtien.
Mitä sertifioinnin pitäisi kattaa
SaaS- ja CRM-integraatioääriviivalle StOFU Security Certification voi nimetä tarkan laajuuden. Tämä soveltamisala voi sisältää Salesforceen yhdistetyt sovellukset, palvelutilit, OAuth-avustukset, kolmannen osapuolen tulotyökalut, CRM-tietoja koskettavat tekoälyavustajat, vientipolut, valvontasäännöt ja peruutustodisteet.
Sertifikaatissa ei pitäisi väittää, että jokainen myyjä maailmassa on turvallinen. Siinä tulee kertoa, mitä tarkasteltiin, mitä riskejä havaittiin, mitkä korjaukset tarkistettiin ja kuinka kauan tulosta voidaan käyttää. Monille SaaS-muodoille jopa 12 kuukauden voimassaoloaika on käytännöllinen, kun materiaalimuutokset käynnistävät aikaisemman tarkistuksen. Uuden suuren riskin toimittajan, suuren CRM-käyttöoikeuksien muutoksen, uuden tekoälytyönkulun tai tietomallin muutoksen pitäisi avata ääriviiva uudelleen aikaisemmin.
Näin sertifioinnista tulee hyödyllistä. Se luo elävän vastauksen. Yritys voi näyttää asiakkaille ja sijoittajille, että tulotietopolku on tarkistettu, että vanhentunut käyttöoikeus poistettiin, vaarallisia laajuuksia on vähennetty ja että tunnuksen väärinkäyttöä valvotaan.
Kuinka SToFU taistelee tätä riskiluokkaa vastaan
SToFU käsittelee SaaS-integraatioita osana suojausääriviivaa. Tarkastus ei pysähdy sovelluskoodiin tai pilvitiliin. Se sisältää reitit, joilla yritystiedot siirtyvät kolmannen osapuolen työkalujen, palvelutilien, API-asiakkaiden, tunnuksien, automaatioiden ja tekoälyavusteisten työnkulkujen kautta.
Tässä riskiluokassa keskitymme viiteen tuotteeseen.
Ensin rakennetaan yhdistetty pääsykartta. Kartta näyttää mitkä työkalut voivat saavuttaa mihin järjestelmiin, mitä laajuuksia niillä on, mitä tietoluokkia ne koskettavat ja kuka omistaja voi perustella pääsyn.
Toiseksi tarkistamme tunnuksen ja identiteetin asennon. Näitä ovat OAuth-alueet, päivitystunnuksen toiminta, sovellusten hyväksymissäännöt, palvelutilin suunnittelu, ei-ihmisidentiteetin omistajuus, ehdollinen käyttöoikeus, toimittajan lähdemallit ja peruutustyönkulut.
Kolmanneksi testaamme väärinkäyttöpolkuja. Hyödyllinen arvostelu kysyy, mitä rikollinen voisi kysyä tunnuksella, mitkä tiedot olisivat hyödyllisiä kiristykseen, kuinka nopeasti se voitaisiin vetää, mitkä lokit sen näyttäisivät ja mitkä hälytykset laukaisivat.
Neljänneksi tuemme korjaamista. Tämä voi tarkoittaa laajuuksien vähentämistä, vanhentuneiden sovellusten poistamista, integraatiotilien jakamista, hälytysten lisäämistä, hyväksyntöjen tiukentamista, tunnuksen vaihtamisen pakottamista, vahvemman toimittajan todisteen vaatimista tai suojakaiteiden lisäämistä CRM-vientien ympärille.
Viidenneksi varmistamme sulkemisen. Kun havainnot on korjattu, testaamme uudelleen. Jos ääriviiva on riittävän puhdas ostajan, sijoittajan, kumppanin tai hankinnan tarkasteluun, voimme myöntää StOFU-turvasertifikaatin, jossa on tarkistettu laajuus, korjaustodisteet, tarkistuspäivämäärä ja voimassaoloaika.
Sertifikaatilla on merkitystä, koska ostajat tarvitsevat selkeän esineen. Heidän on tiedettävä, mitä tarkasteltiin, mitkä riskit suljettiin ja kuinka kauan vastausta voidaan käyttää.
Käytännön vastaussuunnitelma
Jos yrityksesi käyttää Salesforce-, Gong-, HubSpot- tai vastaavia tulojärjestelmiä, toimi asianmukaisesti.
Varasto ensin. Luettele kaikki yhdistetyt sovellukset ja palvelutilit. Määritä omistaja. Poista kaikki ilman omistajaa.
Vähennä pääsyä toiseksi. Rajaa toiminta-alueita työnkulun edellyttämään minimiin. Erillinen lukuoikeus ja kirjoitusoikeus. Poista vanhat pilotit, passiiviset toimittajat ja unohdetut automaatiot.
Peruuta ja kierrä kolmanneksi. Kierrä korkean riskin integraatioita. Peru vanhentuneet päivitystunnukset. Vahvista, että sekä toimittajapuoli että oma puoli ovat muuttuneet.
Hunt neljäs. Hae API-lokeista objektiluetteloiden luetteloita, suuria kyselyitä, epätavallista sivutusta, epäilyttäviä käyttäjäagentteja, työajan ulkopuolella tapahtuvaa vientiä, outoja lähdeverkkoja ja pääsyä arkaluonteisiin mukautettuihin objekteihin.
Lisää todisteet viidenneksi. Säilytä viennit, aikaleimat, kuvakaappaukset, sääntömuutokset, lokikyselyt ja sulkemismuistiinpanot. Todisteet ovat hyödyllisiä asiakkaiden kyselyissä ja vakuutustarkistuksessa.
Todista kuudes. Puhtaalla tuloksella on liikearvoa vain silloin, kun se voidaan näyttää. Turvallisuussertifikaatti tekee teknisestä sulkemisesta päätöksen artefaktin.
Ostajan kysymys
Seuraava yritysostaja esittää terävämmän kysymyksen. He kysyvät, kuinka yrityksesi hallitsee kolmannen osapuolen pääsyä yritystietoihin. He kysyvät, kuinka nopeasti vanhentuneet integraatiot poistetaan. He kysyvät, valvotaanko palvelutilejä. He kysyvät, voidaanko CRM:stäsi tehdä kyselyitä suuressa mittakaavassa ilman, että kukaan huomaa.
Nuo kysymykset ovat reiluja.
Yritys, joka voi vastata niihin, voittaa nopeuden. Yritys, joka ei voi vastata niihin, maksaa viiveellä.
Kluen ja Salesforcen kotelo on signaali. Tokenit ovat nyt osa hyökkäyspintaa. SaaS-integraatiot ovat nyt osa kehää. Tietoturvatarkastuksissa on osoitettava, että tulotietoja kuljettavia liiketoimintajärjestelmiä valvotaan, valvotaan ja ne ovat valmiita tarkastettavaksi.
SToFU auttaa yrityksiä tekemään tästä todisteesta totta.
Lähteet
- The Hacker News: Salesforce Disables Klue App Integration After OAuth Token Abuse Exposes Customer Data
- Klue: An Update on Recent Klue Security Incident
- Huntress: Klue Breach Investigation
- Datadog Security Labs: Detecting the Klue supply chain attack in Salesforce instances
- ReliaQuest: Integration Abused in CRM Data Theft
