snore snore snore

Jitterbit sikkerhedsforanstaltninger

Gælder den 8. december 2022

Sidst opdateret: 6 / 1 / 2021


De centrale sikkerhedsforanstaltninger, som Jitterbit implementerer for at beskytte klientdata, er beskrevet i dette bilag til Jitterbit-sikkerhedsforanstaltninger:

Jitterbit sikkerhedspolitik

Dette dokument om sikkerhedsforanstaltninger fra Jitterbit ("sikkerhedspolitikken") skitserer de administrative, tekniske og fysiske foranstaltninger, som Jitterbit påtager sig for at beskytte klientdata mod uautoriseret adgang eller offentliggørelse. Jitterbit er blevet vurderet til at opfylde kravene i SOC 1, SOC 2, ISO 27001, US HIPAA Privacy and Security, California Consumer Privacy Act (CCPA) og EU GDPR regler. Jitterbit har en skriftlig informationssikkerhedsplan for at implementere vilkårene i denne sikkerhedspolitik, som gennemgås og godkendes årligt af dets øverste ledelsesteam. Der henvises til denne sikkerhedspolitik i og er en del af din klientaftale med Jitterbit ("Aftalen"). I tilfælde af enhver konflikt mellem vilkårene i Aftalen og denne Sikkerhedspolitik, er denne Sikkerhedspolitik gældende med hensyn til dens emne. Udtryk med stort bogstav, der er brugt, men ikke defineret i denne sikkerhedspolitik, har de betydninger, der er angivet i aftalen eller i dokumentationen.

Privacy-by-design: Jitterbit holder aktivt databeskyttelse og privatliv i tankerne ved hvert trin; dette omfatter interne projekter, produktudvikling, softwareudvikling og it-systemer.

Privatliv som standard: Når først Jitterbit frigiver et produkt eller en tjeneste til offentligheden, anvendes strenge privatlivsindstillinger som standard uden manuel input fra brugeren. Derudover opbevares, behandles og/eller transmitteres personoplysninger, som brugeren har afgivet for at muliggøre et produkts optimale brug, kun i det tidsrum, der er nødvendigt for at levere produktet eller tjenesten, i overensstemmelse med definerede standarder.

1. Adgang og administration af klientdata

1.1 Klienten kontrollerer adgangen til sin konto i Jitterbit-applikationen via bruger-id'er, adgangskoder og to-faktor-godkendelse.
1.2 Jitterbit-personale har ikke adgang til ukrypterede klientdata, medmindre klienten giver adgang til sin Jitterbit-konto til sådan Jitterbit-personale. "Jitterbit-personale" betyder Jitterbit-medarbejdere og Jitterbit-autoriserede individuelle underleverandører.
1.3 Jitterbit bruger kun klientdata efter behov for at levere Jitterbit-applikationen og support til klienten, som angivet i aftalen.
1.4 Klientapplikations- og projektmetadata genereret af Jitterbit-applikationen hostes kun af Jitterbit i Jitterbit-applikationens produktionsmiljø og kun inden for den region, hvorfra den stammer (dvs. USA-data forbliver i USA, EU-data forbliver i EU og APAC-data i APAC-regionen).
1.5 Jitterbit skal oprette og vedligeholde flowdiagram(r), der angiver, hvordan klientdata flyder gennem Jitterbit-applikationen. Jitterbit skal levere sådanne flowdiagram(r) efter Kundens rimelige anmodning.

2. Logisk adskillelse af klientdata

2.1 Jitterbit Harmony isolerer klientdata ved at bruge:

  • Secure DB Architecture -separeret database og adskilt skemaarkitektur
  • Sikre forbindelser eller tabeller – Pålidelige databaseforbindelser
  • Kryptering – skjuler kritiske data, så de forbliver utilgængelige for uautoriserede parter, selvom de kommer i besiddelse af dem. Se venligst afsnit 16 for flere detaljer.
  • Filtrering: Brug af et mellemliggende lag mellem en lejer og en datakilde, der fungerer som en si, der får det til at se ud for kunden, som om dens data er de eneste data i databasen.
  • Adgangskontrollister – for at bestemme, hvem der kan få adgang til data i Jitterbit-applikationen, og hvad de kan gøre med dem.

3. Jitterbit Application Infrastructure Access Management

3.1 Adgang til de systemer og infrastruktur, der understøtter Jitterbit-applikationen, er begrænset til Jitterbit-personale, som kræver sådan adgang som en del af deres jobansvar.
3.2 Adgang til system- og applikationslogfiler er begrænset til autoriseret Jitterbit-personale udelukkende med det formål at understøtte, identificere problemer og forbedre Jitterbit-applikationen.
3.2 Unikke bruger-id'er, adgangskoder og to-faktor-godkendelsesoplysninger over en VPN-forbindelse tildeles til Jitterbit-personale, der kræver adgang til Jitterbit-servere, der understøtter Jitterbit-applikationen.
3.3 Serveradgangskodepolitik for Jitterbit-applikationen i produktionsmiljøet overstiger PCI-DSS-adgangskodekravene.
3.4 Adgangsrettigheder for adskilte Jitterbit-personale deaktiveres omgående. Adgangsrettigheder for personer, der overgår til job, der kræver reducerede privilegier, justeres i overensstemmelse hermed.
3.5 Brugeradgang til de systemer og infrastruktur, der understøtter Jitterbit-applikationen, gennemgås kvartalsvis.
3.6 Adgangsforsøg til de systemer og infrastruktur, der understøtter Jitterbit-applikationen, logges og overvåges af Jitterbit.
3.7 AWS-sikkerhedsgrupper har afvis-alle standardpolitikker og aktiverer kun forretningskrævede netværksprotokoller til udgående og indgående netværkstrafik.
3.8 Firewalls – Jitterbit bruger en AWS-leveret sikkerhedsgruppe-firewall bag en load balancer til at kontrollere adgang og trafik til og fra infrastrukturværter.
3.9 Intrusion Detection – Jitterbit overvåger sin Lacework.net IDS

4. Risikostyring

4.1 Jitterbits Risk Management-proces er modelleret efter NIST 800-30
4.2 Jitterbit udfører tekniske og ikke-tekniske risikovurderinger af forskellig art i løbet af året, herunder selv- og tredjepartsvurderinger og -test, automatiserede scanninger og manuelle anmeldelser.
4.3 Resultater af vurderinger, herunder formelle rapporter, hvor det er relevant, indberettes til informationssikkerhedsansvarlige og databeskyttelsesansvarlige. En sikkerhedskomité mødes hver anden uge for at gennemgå rapporter, identificere kontrolmangler og væsentlige ændringer i trusselsmiljøet og komme med anbefalinger til nye eller forbedrede kontroller og trusselsreduktionsstrategier til den øverste ledelse.
4.4 Ændringer i kontroller og trusselsreduktionsstrategier evalueres og prioriteres til implementering på et risikojusteret grundlag.
4.5 Trusler overvåges på forskellige måder, herunder trusselsefterretningstjenester, leverandørmeddelelser og betroede offentlige kilder.

5. Sårbarhedsscanning og penetrationstest

5.1 Sårbarhedsscanninger ved hjælp af værktøjer af kommerciel kvalitet udføres automatisk kvartalsvis og ad hoc på systemer, der er nødvendige for at drive og administrere Jitterbit-applikationen. Sårbarhedsdatabasen opdateres løbende.
5.2 Scanninger, der opdager sårbarheder, der opfylder Jitterbit-definerede risikokriterier, udføres regelmæssigt; prioritetsbaserede meddelelser deles med sikkerhedspersonale og adresseres.
5.3 Potentielle konsekvenser af sårbarheder, der udløser advarsler, evalueres af personalet.
5.4 Sårbarheder, der udløser advarsler og har offentliggjorte udnyttelser, rapporteres til sikkerhedskomitéen, som bestemmer og overvåger passende afhjælpningsforanstaltninger.
5.5 Sikkerhedsstyring overvåger eller abonnerer på betroede kilder til sårbarhedsrapporter og trusselsintelligens. 5.6 Penetrationstest af en uafhængig tredjepartsekspert udføres mindst årligt.
5.7 Penetrationstest udført af Jitterbit Security udføres regelmæssigt i løbet af året.
5.8 Jitterbit Harmony kode gennemgås af internt og eksternt personale ved hjælp af open source og kommercielle værktøjer. Opdagede sårbarheder tildeles kritiske niveauer og afhjælpes hurtigt i henhold til den præsenterede risiko og afhjælpningsmuligheder.

6. Fjernadgang og trådløst netværk

6.1 Al adgang til Jitterbit VPC'erne (f.eks. udviklings- og produktionskonti) kræver godkendelse gennem en sikker forbindelse via godkendte metoder såsom VPN'er og håndhæves med gensidig certifikatgodkendelse og tofaktorautentificering.
6.3 Jitterbit-virksomhedskontorer, inklusive LAN- og Wi-Fi-netværk på disse kontorer, anses for at være upålidelige netværk og kræver vellykket godkendelse til VPN'en i AWS-kontiene for at få adgang. Kun ét medlem af IT-supportteamet har tilladelse til sikker fjernadgang til virksomhedens kontornetværk for at understøtte firewallen, phones og anden infrastruktur.
6.4 Jitterbit opretholder en politik om ikke at gemme klientdata på lokale desktops, bærbare computere, mobile enheder, delte drev, flytbare medier, såvel som på offentlige systemer, der ikke falder ind under Jitterbits administrative kontrol eller overholdelsesovervågningsprocesser.

7. Jitterbit-applikationsplacering

7.1 Klientdata gemmes i de tilgængelige Jitterbit-applikationsregioner: USA, EU og AP; den amerikanske sky kopierer ikke med EMEA-skyen (eller AP-skyen) eller omvendt. Hver region i USA replikerer mellem hinanden i USA.

8. Systemhændelseslogning

8.1 Overvågningsværktøjer og -tjenester bruges til at overvåge systemer, herunder netværk, serverhændelser og AWS API-sikkerhedshændelser, tilgængelighedshændelser og ressourceudnyttelse.
8.2 Jitterbit-infrastruktur Sikkerhedshændelseslogfiler indsamles i et centralt system og beskyttes mod manipulation. Logs opbevares i 12 måneder.
8.3 Jitterbit Harmony applikationslogfiler samles i et centralt system og beskyttes mod manipulation. Logfiler opbevares i 90 dage

9. Systemadministration, Malware-forebyggelse og Patch Management

9.1 Jitterbit har skabt, implementeret og vedligeholder systemadministrationsprocedurer for systemer, der får adgang til klientdata, der opfylder eller overstiger industristandarder, herunder uden begrænsning, systemhærdning, system- og enhedspatching (operativsystem og applikationer) og korrekt installation af trusselsdetektionssoftware, malware forebyggelse og daglige signatur- og heuristiske opdateringer af samme.
9.2 Medarbejdernes internetadgang revideres med begrænset adgang til sortlistede websteder.
9.3 Jitterbit Security gennemgår US-Cert og andre nye meddelelser om sårbarheder ugentligt og vurderer deres indvirkning på Jitterbit baseret på et Jitterbit-defineret risikokriterium, herunder anvendelighed og alvor.
9.4 Gældende US-Cert og andre sikkerhedsopdateringer vurderet som "høj" eller "kritiske" behandles inden for 30 dage efter udgivelsen af ​​programrettelsen.

10. Jitterbit Security Training og Jitterbit Personale

10.1 Jitterbit vedligeholder et sikkerhedsbevidsthedsprogram for Jitterbit Personale, som giver indledende uddannelse, løbende bevidsthed og individuel Jitterbit Personale-anerkendelse af hensigten om at overholde Jitterbits virksomheds sikkerhedspolitikker. Nyansatte gennemfører indledende uddannelse i sikkerhed, HIPAA, CCPA og GDPR, underskriver en proprietær informationsaftale og underskriver digitalt informationssikkerhedspolitikken, der dækker nøgleaspekter af Jitterbits informationssikkerhedspolitik.
10.2 Alt Jitterbit-personale anerkender, at de er ansvarlige for at rapportere faktiske eller formodede sikkerhedshændelser eller bekymringer, tyverier, brud, tab og uautoriseret offentliggørelse af eller adgang til klientdata.
10.3 Alt Jitterbit-personale er forpligtet til at gennemføre årlig sikkerhedstræning på tilfredsstillende vis. Periodiske påmindelser og proaktiv phishing-træning leveres regelmæssigt.
10.4 Jitterbit udfører kriminel baggrundsscreening som en del af Jitterbit ansættelsesprocessen, i det omfang det er lovligt tilladt.
10.5 Jitterbit vil sikre, at dets underleverandører, leverandører og andre tredjeparter, der har direkte adgang til klientdataene i forbindelse med Jitterbit-applikationerne, overholder de gældende datasikkerhedsstandarder som defineret af Jitterbit i politik og procedurer, som er en kombination af ISO 27001/27002, NIST 800-53, CIS, CSA og CERT, HIPAA og GDPR krav.

11. Fysisk sikkerhed

11.1 Jitterbit-applikationen hostes i AWS, og alle fysiske sikkerhedskontroller administreres af AWS. Jitterbit gennemgår AWS SOC 2 Type 2-rapporten årligt for at sikre passende fysiske sikkerhedskontroller.

12. Meddelelse om sikkerhedsbrud

12.1 Et "Sikkerhedsbrud" er (a) uautoriseret adgang til eller videregivelse af klientdata eller (b) uautoriseret adgang til systemerne i Jitterbit-applikationen, der transmitterer eller analyserer klientdata.
12.2 Jitterbit vil underrette Kunden skriftligt uden unødig forsinkelse inden for tooghalvfjerds (72) timer efter et bekræftet Sikkerhedsbrud.
12.3 En sådan meddelelse vil beskrive sikkerhedsbruddet og status for Jitterbits undersøgelse. 12.4 Jitterbit vil træffe passende foranstaltninger for at begrænse, undersøge og afbøde sikkerhedsbruddet.

13. Katastrofeinddrivelse

13.1 Jitterbit opretholder en Disaster Recovery Plan ("DRP") for Jitterbit-applikationerne. DRP testes årligt. 13.2 Jitterbit-applikationen administreres i forskellige AWS-regioner som selvstændige implementeringer, som kan bruges som en del af klientens DRP-strategi. For effektivt at bruge den tværregionale tilgængelighed af Jitterbit-applikationen til gendannelsesformål, er klienten ansvarlig for følgende:
13.2.1 Anmodning om yderligere Jitterbit Application-konti i forskellige regioner for at understøtte sit DRP-program. 13.2.2 Håndtering af datareplikering på tværs af relevante regioner.
13.2.3 Konfiguration og styring af sine Jitterbit-konti.
13.2.4 Håndtering af backup- og gendannelsesstrategier.

14. Jitterbit-sikkerhedsoverholdelse, certificeringer og attester fra tredjepart

14.1 Jitterbit hyrer akkrediterede tredjeparter til at udføre revisioner og attestere forskellige overholdelse og certificeringer årligt, herunder:
14.1.1 SOC 2 Attestationsrapport
14.1.2 SOC 1 Attestationsrapport
14.1.2 HIPAA-overensstemmelsesrapport for forretningsforbindelser
14.1.3 GDPR Compliance-rapport
14.1.4 Sammenfatning af penetrationstestrapport
14.1.5 Sammendrag af rapport om sårbarhedsvurdering
14.1.6 ISO 27001 Attestrapport
14.1.7 CCPA Compliance Report for California Privacy Act

15. Jitterbit Cloud og lokal agent

15.1 Jitterbit Harmony Cloud er designet med de højeste sikkerhedsindstillinger i tankerne, så selv simple implementeringer (lavere sikkerhedskrav) kan drage fordel af denne "indbyggede" høje sikkerhed.
15.2 Jitterbit giver en implementeringsmulighed (lokal agent) til klienter, der vælger at behandle følsomme data uden for Jitterbits cloud-infrastruktur og bag deres egen firewall og firmanetværk.

16. Datakryptering

16.1 Kryptering af klientdata i hvile på Harmony: Harmony Cloud-data er krypteret i hvile med en AES-256 FIPS 140-2-algoritme. For flere detaljer, se Jitterbit Harmony Arkitektur og sikkerhed hvidbog på: https://success.jitterbit.com/display/DOC/Jitterbit+Security+and+Architecture+White+Paper
16.2 Kryptering af klientdata under transport til/fra Harmony: Harmony Cloud-data krypteres under transport ved hjælp af HTTPS (TLS 1.2), SSH og/eller IPsecSsEC. For flere detaljer, se Jitterbit Harmony Arkitektur og sikkerhed hvidbog på:https://success.jitterbit.com/display/DOC/Jitterbit+Security+and+Architecture+White+Paper

17. Kundens ansvar

17.1 Kunden er ansvarlig for at administrere sine egne brugerkonti og roller i Jitterbit-applikationen og for at beskytte sin egen konto og brugerlegitimationsoplysninger. Kunden vil overholde vilkårene i sin aftale med Jitterbit samt alle gældende love.
17.2 Kunden vil straks underrette Jitterbit, hvis en brugerlegitimationsoplysninger er blevet kompromitteret, eller hvis Kunden har mistanke om mulige mistænkelige aktiviteter, der kan have en negativ indvirkning på sikkerheden af ​​Jitterbit-applikationen eller Kundens konto. Kunden må ikke udføre nogen sikkerhedsgennemtrængningstest eller sikkerhedsvurderingsaktiviteter uden udtrykkeligt forudgående skriftligt samtykke fra Jitterbit.
17.3 For Jitterbit-applikationer, som ikke hostes af Jitterbit, er klienten ansvarlig for at opdatere sin Jitterbit-klientsoftware, hver gang Jitterbit annoncerer en opdatering.
17.4 Kunder er ansvarlige for at administrere en backup-strategi vedrørende Kundedata.
17.5 Klienter, hvis klientdata inkluderer PCI, PHI, GDPR, PII eller andre følsomme data, bør implementere Jitterbit-leveret IP-hvidlisting og multi-factor authentication (MFA) i Jitterbit-applikationen og overveje brugen af ​​den lokale agent med yderligere begrænset logningskonfiguration .

Har du spørgsmål? Vi er her for at hjælpe.

Kontakt os