Zuletzt aktualisiert: 6 / 1 / 2021

Die wichtigsten Sicherheitsmaßnahmen, die Jitterbit zum Schutz von Kundendaten umsetzt, sind in diesem Anhang zu Jitterbit-Sicherheitsmaßnahmen beschrieben:

Jitterbit-Sicherheitsrichtlinie

Dieses Dokument zu Jitterbit-Sicherheitsmaßnahmen (die „Sicherheitsrichtlinie“) beschreibt die administrativen, technischen und physischen Maßnahmen, die Jitterbit ergreift, um Kundendaten vor unbefugtem Zugriff oder Offenlegung zu schützen. Jitterbit wurde bewertet, um die Anforderungen von SOC 1, SOC 2, ISO 27001, US HIPAA Privacy and Security, California Consumer Privacy Act (CCPA) und EU-DSGVO-Regeln zu erfüllen. Jitterbit verfügt über einen schriftlichen Informationssicherheitsplan zur Umsetzung der Bestimmungen dieser Sicherheitsrichtlinie, der jährlich von seinem Senior Management Team überprüft und genehmigt wird. Auf diese Sicherheitsrichtlinie wird in Ihrer Kundenvereinbarung mit Jitterbit (die „Vereinbarung“) verwiesen und sie wird Teil davon. Im Falle eines Konflikts zwischen den Bedingungen der Vereinbarung und dieser Sicherheitsrichtlinie gilt diese Sicherheitsrichtlinie in Bezug auf ihren Gegenstand. Großgeschriebene Begriffe, die in dieser Sicherheitsrichtlinie verwendet, aber nicht definiert werden, haben die in der Vereinbarung oder in der Dokumentation festgelegte Bedeutung.

Datenschutz durch Design: Jitterbit berücksichtigt bei jedem Schritt aktiv den Datenschutz und die Privatsphäre; dazu gehören interne Projekte, Produktentwicklung, Softwareentwicklung und IT-Systeme.

Datenschutz standardmäßig: Sobald Jitterbit ein Produkt oder eine Dienstleistung für die Öffentlichkeit freigibt, werden standardmäßig strenge Datenschutzeinstellungen angewendet, ohne dass der Benutzer manuell eingreifen muss. Darüber hinaus werden personenbezogene Daten, die vom Nutzer zur Verfügung gestellt werden, um eine optimale Nutzung eines Produkts zu ermöglichen, nur für den Zeitraum gespeichert, verarbeitet und/oder übermittelt, der für die Bereitstellung des Produkts oder der Dienstleistung gemäß festgelegter Standards erforderlich ist.

1. Zugriff und Verwaltung von Kundendaten

1.1 Der Kunde kontrolliert den Zugriff auf sein Konto in der Jitterbit-Anwendung über Benutzer-IDs, Passwörter und Zwei-Faktor-Authentifizierung.
1.2 Mitarbeiter von Jitterbit haben keinen Zugriff auf unverschlüsselte Kundendaten, es sei denn, der Kunde gewährt diesen Mitarbeitern von Jitterbit Zugriff auf sein Jitterbit-Konto. „Jitterbit-Personal“ bezeichnet Jitterbit-Mitarbeiter und von Jitterbit autorisierte einzelne Subunternehmer.
1.3 Jitterbit verwendet Kundendaten nur soweit erforderlich, um die Jitterbit-Anwendung und den Support für den Kunden bereitzustellen, wie in der Vereinbarung vorgesehen.
1.4 Von der Jitterbit-Anwendung generierte Clientanwendungs- und Projektmetadaten werden von Jitterbit nur in der Produktionsumgebung der Jitterbit-Anwendung und nur innerhalb der Region gehostet, aus der sie stammen (d. h. US-Daten bleiben in den USA, EU-Daten bleiben in der EU und APAC-Daten in APAC-Region).
1.5 Jitterbit erstellt und pflegt Flussdiagramme, die angeben, wie Kundendaten durch die Jitterbit-Anwendung fließen. Jitterbit stellt solche Flussdiagramme auf angemessene Anfrage des Kunden zur Verfügung.

2. Logische Trennung von Kundendaten

2.1 Jitterbit Harmony isoliert Kundendaten durch Verwendung von:

• Sichere DB-Architektur – getrennte Datenbank und getrennte Schemaarchitektur
• Sichere Verbindungen oder Tabellen – Vertrauenswürdige Datenbankverbindungen
• Verschlüsselung – verschleiert kritische Daten, sodass sie für Unbefugte unzugänglich bleiben, selbst wenn sie in ihren Besitz gelangen. Weitere Einzelheiten finden Sie in Abschnitt 16.
• Filterung: Verwendung einer Zwischenschicht zwischen einem Mandanten und einer Datenquelle, die wie ein Sieb wirkt und es dem Kunden so erscheinen lässt, als wären seine Daten die einzigen Daten in der Datenbank.
• Zugriffskontrolllisten – um festzulegen, wer auf Daten in der Jitterbit-Anwendung zugreifen kann und was sie damit tun können.

3. Zugriffsverwaltung für die Jitterbit-Anwendungsinfrastruktur

3.1 Der Zugriff auf die Systeme und die Infrastruktur, die die Jitterbit-Anwendung unterstützen, ist auf Mitarbeiter von Jitterbit beschränkt, die einen solchen Zugriff im Rahmen ihrer beruflichen Verantwortung benötigen.
3.2 Der Zugriff auf System- und Anwendungsprotokolle ist ausschließlich autorisiertem Jitterbit-Personal vorbehalten, um die Jitterbit-Anwendung zu unterstützen, Probleme zu identifizieren und zu verbessern.
3.2 Eindeutige Benutzer-IDs, Passwörter und Zwei-Faktor-Authentifizierungsdaten über eine VPN-Verbindung werden Jitterbit-Mitarbeitern zugewiesen, die Zugriff auf die Jitterbit-Server benötigen, die die Jitterbit-Anwendung unterstützen.
3.3 Die Serverpasswortrichtlinie für die Jitterbit-Anwendung in der Produktionsumgebung geht über die PCI-DSS-Passwortanforderungen hinaus.
3.4 Zugriffsrechte von getrenntem Jitterbit-Personal werden umgehend deaktiviert. Die Zugangsberechtigungen von Personen, die in Stellen mit eingeschränkten Rechten wechseln, werden entsprechend angepasst.
3.5 Der Benutzerzugriff auf die Systeme und die Infrastruktur, die die Jitterbit-Anwendung unterstützen, wird vierteljährlich überprüft.
3.6 Zugriffsversuche auf Systeme und Infrastruktur, die die Jitterbit-Anwendung unterstützen, werden von Jitterbit protokolliert und überwacht.
3.7 AWS-Sicherheitsgruppen haben standardmäßige Deny-All-Richtlinien und aktivieren nur geschäftlich erforderliche Netzwerkprotokolle für ausgehenden und eingehenden Netzwerkdatenverkehr.
3.8 Firewalls – Jitterbit verwendet eine von AWS bereitgestellte Sicherheitsgruppen-Firewall hinter einem Load Balancer, um den Zugriff und den Datenverkehr zu und von Infrastruktur-Hosts zu kontrollieren.
3.9 Angriffserkennung – Jitterbit überwacht sein IDS von Lacework.net

4. Risikomanagement

4.1 Der Risikomanagementprozess von Jitterbit orientiert sich an NIST 800-30
4.2 Jitterbit führt das ganze Jahr über technische und nichttechnische Risikobewertungen verschiedener Art durch, darunter Bewertungen und Tests durch sich selbst und Dritte, automatisierte Scans und manuelle Überprüfungen.
4.3 Die Ergebnisse der Bewertungen, einschließlich formeller Berichte, sofern relevant, werden den Informationssicherheitsbeauftragten und Datenschutzbeauftragten gemeldet. Ein Sicherheitsausschuss tritt zweiwöchentlich zusammen, um Berichte zu überprüfen, Kontrollmängel und wesentliche Änderungen in der Bedrohungsumgebung zu identifizieren und der Geschäftsleitung Empfehlungen für neue oder verbesserte Kontrollen und Strategien zur Bedrohungsminderung zu unterbreiten.
4.4 Änderungen an Kontrollen und Strategien zur Bedrohungsminderung werden auf risikoadjustierter Basis bewertet und für die Implementierung priorisiert.
4.5 Bedrohungen werden auf verschiedene Weise überwacht, darunter Bedrohungsinformationsdienste, Anbieterbenachrichtigungen und vertrauenswürdige öffentliche Quellen.

5. Schwachstellen-Scanning und Penetrationstests

5.1 Schwachstellen-Scans mit handelsüblichen Tools werden automatisch vierteljährlich und ad hoc auf Systemen durchgeführt, die für den Betrieb und die Verwaltung der Jitterbit-Anwendung erforderlich sind. Die Schwachstellendatenbank wird regelmäßig aktualisiert.
5.2 Scans, die Schwachstellen erkennen und die von Jitterbit definierten Risikokriterien erfüllen, werden regelmäßig durchgeführt; prioritätsbasierte Benachrichtigungen werden mit dem Sicherheitspersonal geteilt und adressiert.
5.3 Mögliche Auswirkungen von Schwachstellen, die Warnungen auslösen, werden von Mitarbeitern bewertet.
5.4 Schwachstellen, die Warnungen auslösen und für die Exploits veröffentlicht wurden, werden dem Sicherheitsausschuss gemeldet, der geeignete Abhilfemaßnahmen festlegt und überwacht.
5.5 Das Sicherheitsmanagement überwacht oder abonniert vertrauenswürdige Quellen von Schwachstellenberichten und Bedrohungsinformationen. 5.6 Penetrationstests durch einen unabhängigen externen Experten werden mindestens einmal jährlich durchgeführt.
5.7 Von Jitterbit Security durchgeführte Penetrationstests werden das ganze Jahr über regelmäßig durchgeführt.
5.8 Jitterbit Harmony Der Code wird von internem und externem Personal mit Open-Source- und kommerziellen Tools überprüft. Entdeckten Schwachstellen werden Kritikalitätsstufen zugewiesen und schnell behoben, je nach dargestelltem Risiko und Abhilfemöglichkeiten.

6. Fernzugriff und drahtloses Netzwerk

6.1 Jeglicher Zugriff auf die Jitterbit-VPCs (z. B. Entwicklungs- und Produktionskonten) erfordert eine Authentifizierung über eine sichere Verbindung über zugelassene Methoden wie VPNs und wird durch gegenseitige Zertifikatsauthentifizierung und Zwei-Faktor-Authentifizierung erzwungen.
6.3 Jitterbit-Firmenbüros, einschließlich LAN- und Wi-Fi-Netzwerke in diesen Büros, gelten als nicht vertrauenswürdige Netzwerke und erfordern für den Zugriff eine erfolgreiche Authentifizierung beim VPN in den AWS-Konten. Nur ein Mitglied des IT-Supportteams darf sicher aus der Ferne auf das Firmennetzwerk zugreifen, um die Firewall zu unterstützen. phones und andere Infrastruktur.
6.4 Jitterbit verfolgt eine Richtlinie, Kundendaten nicht auf lokalen Desktops, Laptops, Mobilgeräten, gemeinsam genutzten Laufwerken, Wechselmedien sowie auf öffentlich zugänglichen Systemen zu speichern, die nicht unter die administrative Kontrolle oder Compliance-Überwachungsverfahren von Jitterbit fallen.

7. Speicherort der Jitterbit-Anwendung

7.1 Kundendaten werden in den verfügbaren Jitterbit-Anwendungsregionen gespeichert: USA, EU und AP; die US-Cloud repliziert sich nicht mit der EMEA-Cloud (oder AP-Cloud) oder umgekehrt. Jede Region innerhalb der USA repliziert zwischen jeder anderen US-Region.

8. Systemereignisprotokollierung

8.1 Überwachungstools und -dienste werden verwendet, um Systeme zu überwachen, einschließlich Netzwerk-, Serverereignisse und AWS-API-Sicherheitsereignisse, Verfügbarkeitsereignisse und Ressourcennutzung.
8.2 Jitterbit-Infrastruktur Sicherheitsereignisprotokolle werden in einem zentralen System gesammelt und vor Manipulation geschützt. Protokolle werden für 12 Monate gespeichert.
8.3 Jitterbit Harmony Anwendungsprotokolle werden in einem zentralen System gesammelt und vor Manipulation geschützt. Protokolle werden 90 Tage lang gespeichert

9. Systemadministration, Malware-Prävention und Patch-Management

9.1 Jitterbit hat Systemverwaltungsverfahren für Systeme erstellt, implementiert und verwaltet, die auf Kundendaten zugreifen, die Industriestandards erfüllen oder übertreffen, einschließlich, aber nicht beschränkt auf Systemhärtung, Patchen von Systemen und Geräten (Betriebssystem und Anwendungen) und ordnungsgemäße Installation von Bedrohungserkennungssoftware, Malware Prävention und tägliche Signatur und heuristische Aktualisierungen derselben.
9.2 Der Internetzugang der Mitarbeiter wird mit eingeschränktem Zugriff auf Websites auf der schwarzen Liste geprüft.
9.3 Jitterbit Security überprüft US-Cert und andere neue Ankündigungen von Schwachstellen wöchentlich und bewertet ihre Auswirkung auf Jitterbit basierend auf einem von Jitterbit definierten Risikokriterium, einschließlich Anwendbarkeit und Schweregrad.
9.4 Anwendbare US-Cert- und andere als „hoch“ oder „kritisch“ eingestufte Sicherheitsupdates werden innerhalb von 30 Tagen nach der Patch-Veröffentlichung behoben.

10. Jitterbit-Sicherheitsschulung und Jitterbit-Personal

10.1 Jitterbit unterhält ein Sicherheitsbewusstseinsprogramm für Jitterbit-Mitarbeiter, das eine Erstausbildung, fortlaufende Sensibilisierung und individuelle Bestätigung der Absicht des Jitterbit-Personals zur Einhaltung der Unternehmenssicherheitsrichtlinien von Jitterbit bietet. Neue Mitarbeiter absolvieren eine Erstschulung zu Sicherheit, HIPAA, CCPA und GDPR, unterzeichnen eine proprietäre Informationsvereinbarung und unterzeichnen digital die Informationssicherheitsrichtlinie, die die wichtigsten Aspekte der Jitterbit-Informationssicherheitsrichtlinie abdeckt.
10.2 Alle Mitarbeiter von Jitterbit erkennen an, dass sie für die Meldung tatsächlicher oder vermuteter Sicherheitsvorfälle oder -bedenken, Diebstähle, Verstöße, Verluste und unbefugte Offenlegung von oder Zugriff auf Kundendaten verantwortlich sind.
10.3 Alle Mitarbeiter von Jitterbit müssen die jährliche Sicherheitsschulung zufriedenstellend absolvieren. Periodische Erinnerungen und proaktive Phishing-Schulungen werden regelmäßig bereitgestellt.
10.4 Jitterbit führt im gesetzlich zulässigen Umfang im Rahmen des Jitterbit-Einstellungsverfahrens kriminalpolizeiliche Überprüfungen durch.
10.5 Jitterbit stellt sicher, dass seine Subunternehmer, Lieferanten und andere Dritte, die im Zusammenhang mit den Jitterbit-Anwendungen direkten Zugriff auf die Kundendaten haben, die geltenden Datensicherheitsstandards einhalten, wie sie von Jitterbit in Richtlinien und Verfahren definiert sind, was eine Kombination aus ISO ist 27001/27002, NIST 800-53, CIS, CSA und CERT, HIPAA und GDPR-Anforderungen.

11. Physische Sicherheit

11.1 Die Jitterbit-Anwendung wird in AWS gehostet und alle physischen Sicherheitskontrollen werden von AWS verwaltet. Jitterbit überprüft den AWS SOC 2 Typ 2-Bericht jährlich, um angemessene physische Sicherheitskontrollen sicherzustellen.

12. Benachrichtigung über eine Sicherheitsverletzung

12.1 Eine „Sicherheitsverletzung“ ist (a) der unbefugte Zugriff auf oder die Offenlegung von Kundendaten oder (b) der unbefugte Zugriff auf die Systeme innerhalb der Jitterbit-Anwendung, die Kundendaten übertragen oder analysieren.
12.2 Jitterbit wird den Kunden unverzüglich innerhalb von zweiundsiebzig (72) Stunden nach einer bestätigten Sicherheitsverletzung schriftlich benachrichtigen.
12.3 Eine solche Benachrichtigung beschreibt die Sicherheitsverletzung und den Stand der Untersuchung von Jitterbit. 12.4 Jitterbit wird geeignete Maßnahmen ergreifen, um die Sicherheitsverletzung einzudämmen, zu untersuchen und zu mildern.

13. Notfallwiederherstellung

13.1 Jitterbit unterhält einen Notfallwiederherstellungsplan („DRP“) für die Jitterbit-Anwendungen. Der DRP wird jährlich getestet. 13.2 Die Jitterbit-Anwendung wird in verschiedenen AWS-Regionen als eigenständige Bereitstellungen verwaltet, die als Teil der DRP-Strategie des Kunden eingesetzt werden können. Um die überregionale Verfügbarkeit der Jitterbit-Anwendung für Disaster-Recovery-Zwecke effektiv zu nutzen, ist der Kunde für Folgendes verantwortlich:
13.2.1 Anfordern zusätzlicher Jitterbit-Anwendungskonten in verschiedenen Regionen zur Unterstützung des DRP-Programms. 13.2.2 Verwalten der Datenreplikation über die entsprechenden Regionen hinweg.
13.2.3 Konfiguration und Verwaltung seiner Jitterbit-Konten.
13.2.4 Verwalten von Sicherungs- und Wiederherstellungsstrategien.

14. Jitterbit-Sicherheitskonformität, Zertifizierungen und Bescheinigungen von Drittanbietern

14.1 Jitterbit beauftragt akkreditierte Dritte mit der Durchführung von Audits und der jährlichen Bestätigung verschiedener Konformitäten und Zertifizierungen, darunter:
14.1.1 SOC 2-Bestätigungsbericht
14.1.2 SOC 1-Bestätigungsbericht
14.1.2 HIPAA-Compliance-Bericht für Geschäftspartner
14.1.3 DSGVO-Compliance-Bericht
14.1.4 Zusammenfassung des Penetrationstestberichts
14.1.5 Zusammenfassung des Schwachstellenbewertungsberichts
14.1.6 ISO 27001-Bestätigungsbericht
14.1.7 CCPA-Compliance-Bericht für das California Privacy Act

15. Jitterbit Cloud und lokaler Agent

15.1 Jitterbit Harmony Cloud wurde unter Berücksichtigung der höchsten Sicherheitseinstellungen entwickelt, sodass selbst einfache Implementierungen (niedrigere Sicherheitsanforderungen) von dieser „eingebrannten“ Hochsicherheit profitieren können.
15.2 Jitterbit bietet eine Implementierungsoption (Local Agent) für Kunden, die sensible Daten außerhalb der Jitterbit-Cloud-Infrastruktur und hinter ihrer eigenen Firewall und ihrem eigenen Unternehmensnetzwerk verarbeiten möchten.

16. Datenverschlüsselung

16.1 Verschlüsselung von Kundendaten im Ruhezustand Harmony: Harmony Cloud-Daten werden im Ruhezustand mit einem AES-256 FIPS 140-2-Algorithmus verschlüsselt. Weitere Einzelheiten finden Sie im Jitterbit Harmony Architektur- und Sicherheits-Whitepaper unter: https://success.jitterbit.com/display/DOC/Jitterbit+Security+and+Architecture+White+Paper
16.2 Verschlüsselung von Kundendaten bei der Übertragung nach/von Harmony: Harmony Cloud-Daten werden während der Übertragung mit HTTPS (TLS 1.2), SSH und/oder IPsecSsEC verschlüsselt. Weitere Einzelheiten finden Sie im Jitterbit Harmony Architektur- und Sicherheits-Whitepaper unter:https://success.jitterbit.com/display/DOC/Jitterbit+Security+and+Architecture+White+Paper

17. Pflichten des Kunden

17.1 Der Kunde ist für die Verwaltung seiner eigenen Benutzerkonten und Rollen innerhalb der Jitterbit-Anwendung und für den Schutz seines eigenen Kontos und seiner Benutzeranmeldeinformationen verantwortlich. Der Kunde wird die Bedingungen seiner Vereinbarung mit Jitterbit sowie alle anwendbaren Gesetze einhalten.
17.2 Der Kunde wird Jitterbit unverzüglich benachrichtigen, wenn ein Benutzerzugang kompromittiert wurde oder wenn der Kunde mögliche verdächtige Aktivitäten vermutet, die die Sicherheit der Jitterbit-Anwendung oder des Kundenkontos beeinträchtigen könnten. Der Kunde darf ohne die ausdrückliche vorherige schriftliche Zustimmung von Jitterbit keine Sicherheitspenetrationstests oder Sicherheitsbewertungsaktivitäten durchführen.
17.3 Bei Jitterbit-Anwendungen, die nicht von Jitterbit gehostet werden, ist der Kunde für die Aktualisierung seiner Jitterbit-Client-Software verantwortlich, wann immer Jitterbit ein Update ankündigt.
17.4 Kunden sind für die Verwaltung einer Backup-Strategie in Bezug auf Kundendaten verantwortlich.
17.5 Kunden, deren Kundendaten PCI, PHI, GDPR, PII oder andere sensible Daten enthalten, sollten die von Jitterbit bereitgestellte IP-Whitelisting und Multi-Faktor-Authentifizierung (MFA) in der Jitterbit-Anwendung implementieren und die Verwendung des lokalen Agenten mit zusätzlicher eingeschränkter Protokollierungskonfiguration in Betracht ziehen .